Application security analysis covers the methods used to identify and address vulnerabilities in software during and after development. Techniques include static and dynamic analysis, fuzz testing, reverse engineering, software composition analysis, and side-channel analysis.
Application Security Analysis
If we're developing some sort of application, or have software code that we're writing, then we're going to want to make sure that we are analyzing that for security holes, for security risks, for vulnerabilities. If we're developing code and writing software, then there is potential for a lot of security holes, so we need to make sure that we're doing that correctly.
If we're developing some sort of application, then we're working with code and we're executing code, and there might be a few different ways that we can scan this and be able to identify if there are some sort of vulnerabilities.
When it comes to application security, we could be doing static analysis. Static analysis is just when we're taking a look at the code and looking for vulnerabilities within the code. A lot of times it's great, because we can see all of the code and identify what is happening within that code. But it's not a perfect solution: there are times when there are vulnerabilities that only show up when it's actually being accessed, when it's actually being executed.
Dynamic analysis is when we actually run the code and we take a look and see if there are vulnerabilities when we're running the code. But the problem with this is that some of the code might not be running at any particular time, and if we don't trigger whatever it is that executes that portion of the code, it'll never get analyzed. So it's important to have both of these.
There's also package monitoring. A lot of these different codes and different software use a lot of different packages, and so there are other software components to it. What we want to do is make sure that those packages that are installed on a computer are monitored as well.
Typically what would happen with software development is that we would come up with some sort of objective of what we're trying to achieve, and from there we would architect some sort of design for our code, and then develop the code that would meet that design. Reverse engineering takes the opposite perspective: what it does is it takes the code, and then we analyze the code and then determine what is going to be the response of it. This is a way to implement some security, because we might unintentionally create some security holes, and by reverse engineering we can better understand what our code is doing and see if there are any holes in it.
Another practice that we can do to test out our code is something called fuzz testing, or fuzzing. The idea is that we are going to load up information into our program — it's going to actually be running — and we'll load up information into it to see how it responds. Even more specifically, it's weird information; it's information that you typically wouldn't put in there.
For instance, let's say first name is a data set that would expect just normal characters, and the same thing with last name, and maybe there's some sort of addresses, and there's a way that we form addresses and put it in there. But fuzz testing would be putting all sorts of random data into these fields — and whether it is on the front end, or maybe we're doing it on the back end, we're loading it up with just a bunch of strange information that typically would go into these fields, to see how it responds and see if there are any security holes that get developed because of this.
Another thing we should be analyzing is the software composition. A lot of times we're going to borrow or use code from other sources. There are a lot of free and open sources out there that we can utilize to make us more efficient when we're developing this code. So what we can do is go and find this code and then incorporate it into our own code.
Well, this causes a couple of problems. Number one is that this code might be a little bit of an unknown, so we're incorporating that into our code — and what is it going to do, how is it going to respond? The other thing is updates could happen to this later on in the future, and are we updating our own code?
There is the reverse of this also: our code that we're developing may call on other sources. So not necessarily integrated into our code, but it's actually calling other programs and other sources, and there are these dependencies. If our software has some sort of dependencies, what are the holes, what are the vulnerabilities of these dependencies, and what are the vulnerabilities of the communication with these dependencies?
There's something called a side-channel attack. It's where we observe behavior, and based off of that we can reverse engineer and figure out what the processes are, what the coding is, how this is set up.
A good example of this is that side-channel attacks happen a lot with cryptography attacks. What happens is if we observe this behavior of what's happening with cryptography and can reverse engineer that, now we know exactly what that code is doing, what that cipher is doing, and then perhaps crack that cipher. So this can be problematic.
The same thing is true with some code as you're developing it. Is somebody going to be able to reverse engineer, figure out what your code is doing, and then be able to leverage that, be able to take advantage of maybe some sort of vulnerability with how it's operating? So what we want to do is look at the side channel and do a side-channel analysis to determine: can you reverse engineer this and come up with the code?
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →