Flaws and Vulnerabilities and Exploits – Oh My!

With the slew of terms that exist in the world of application security, it can be difficult to keep them all straight. “Flaws,” “vulnerabilities,” and “exploits” are just a few that are likely on your radar, but what do they mean? If you’ve used these words interchangeably in the past, you’re not alone. They’re easy to confuse with one another, likely because there’s a relationship between all of these terms, however, their distinction is real.

To give you a better idea of how to distinguish between these security issues and the different roles that they play within AppSec, let’s take a closer look at the similarities and differences between flaws, vulnerabilities, and exploits.

Flaws vs. Vulnerabilities

Flaws and vulnerabilities are perhaps the easiest two security defects to mix up, leading many security professionals to wonder what exactly is the difference between the two.

To put it simply, a flaw is an implementation defect that can lead to a vulnerability, and a vulnerability is an exploitable condition within your code that allows an attacker to attack. So, just because a flaw isn’t a vulnerability at the present moment, it doesn’t mean that it can’t become one in the future as environments and architectures change or get updated. Any updates to the architecture or changes in the function of your application can expose your application to attacks that were previously hidden.

Once someone has figured out a way to attack – or exploit – a flaw, the flaw becomes a vulnerability. If you’re still confused, think of it this way: all vulnerabilities are flaws, but not all flaws are vulnerabilities. All flaws have the potential to become vulnerabilities.

For some guidance when it comes to flaws, a helpful resource is MITRE’s Common Weakness Enumeration (CWE) list, which provides a common baseline standard for identifying different classes of weaknesses within application structures that can result in possible vulnerabilities.

Only when there is a realization of a structural defect that can allow for an attack to occur does a vulnerability arise. Vulnerabilities, similarly to flaws, are categorized by MITRE’s Common Vulnerabilities and Exposures (CVE) list. Generally, when we’re looking at CVE entries, these are recognized, publicly-known cybersecurity vulnerabilities within existing codebases. Additionally, you could reference the National Institute of Standards and Technology’s National Vulnerability Database (NVD), which is updated whenever a new vulnerability is added to the CVE dictionary of vulnerabilities. The NVD supplements the CVE list by conducting additional analysis on the vulnerabilities, and by determining the impact that vulnerabilities can have on an organization.

Exploits

“Exploit” is often used to describe weaknesses in code where hacking can occur, but in reality, it’s a slightly different concept. Rather than being a weakness in code, the term “exploit” refers to a procedure or program intended to take advantage of a vulnerability. Another way to think about it is this – an exploit is a vulnerability “weaponized” for a purpose, and this is because an exploit makes use of a vulnerability to attack a system.

So, to reiterate, rather than being the weakness in the code, an exploit is how you would attack that code. It allows an attacker to utilize the application’s logic against it in a way that was never intended by the developers.

As we can see, all of these concepts have their own unique differences, and yet, they are so closely tied together in the world of application security; flaws exist within a code base that’s being attacked, the flaw being that weakness, the vulnerability being the realization of it, and the exploit being how that vulnerability would be leveraged and attacked.

Testing Methods

Now that you have an understanding of the distinctions between these terms, you might be wondering how to test for flaws and vulnerabilities in your code. After all, step one is awareness, but step two is knowing how to find and prevent these defects from putting your data at risk.

Static Application Security Testing (or SAST) is going to help you find the flaws in your code that could be possible vulnerabilities. Static analysis estimates – but does not prove – the exploitability of these flaws so that you can prioritize which to fix first. Knowing whether or not these flaws are certain vulnerabilities takes more of an understanding of the context in which the application is being run and the architecture of the application.

Your next line of defense comes in the form of Dynamic Application Security Testing (DAST), and Manual Penetration Testing (commonly known as MPT). These testing methods are typically more familiar to developers, as they’ve historically been the common approaches for assessing against application vulnerabilities. Dynamic analysis and MPTs run against a live application, and because they’re testing the code behavior from the outside in, we can actually see if these vulnerabilities are exploitable.

The third type of assessment at your disposal is Software Composition Analysis (SCA). SCA focuses on identifying risks that might be introduced by open source code components and third party libraries. It does this by scanning against an inventory of known, documented vulnerabilities – like the National Vulnerability Database.

While each testing method has unique upsides and drawbacks, they all have their place within the software development lifecycle. By using all three together in an integrated manner, you’ll be able to assess when risk exists within an application, and furthermore, you’ll be protecting yourself at every stage within your SDLC.

To learn even more about these security defects discussed here, and how to remediate them once you’ve found them, check out this webinar.