3 min read

Vulnerability or Defect?

AppSec tooling does not find any vulnerabilities, it finds defects. But when is a defect a vulnerability?
AppSec tooling does not find any vulnerabilities, it finds defects.

Even if you want to call it a vulnerability, vulnerabilities are Defects that are also exploitable as an added characteristic.

Why do tools use the word Vulnerability?

Mostly because it is impactful, defects don't have the same emergency reaction.

The boy who cried wolf felt this way

Sure some tools use the word 'Vulnerability' for findings, why is it a problem? If all defects are alarming, you lose trust in the tool/process, eventually you stop treating any defects as priority at all.

Alert fatigue

Until there is an exploit ready to take advantage of the issues found by our tools all we really know we have identified are code Defects.

To this day I have not seen any tools provide a working exploit, most penetration tests don't even provide working exploits!
Without an exploit for the issue we are not known to be vulnerable, and the likelihood of there being an exploit is unknown, not yet created, or not easily knowable. So a unlikely risk we are vulnerable if an exploit is non-trivial or non-existent.

Normalising AppSec bugs

It is important to make this distinction for an AppSec program, that we are addressing defects not vulnerabilities.

Addressing defects are already part of the engineer normal activities.
If there is a QA (Quality Assurance) capability, the organisation will have established a robust defect identification and remediation process. The QA team should already be accustomed to finding security defects like login related bugs or syntax related bugs from code quality tools.

Like any other defect in code, we should treat our AppSec tool findings the same way any developer treats defects. We debug the problem and ensure our application is behaving as intended, and has no unintended side-effects that can be checked with unit tests.

When is a defect a vulnerability?

While AppSec engineers normally focus efforts on securing applications where code is being written so defects never make it to productions systems - we cannot deny the reality that some defects will go unnoticed and potentially make our production applications vulnerable.

Figure 1 - Vulnerability or Defect in a typical SDLC

Many organisations will involve/require AppSec engineers in the Security Operations efforts that include deploying, configuring, and operating Endpoint Protection agents and Web Application Firewalls to name 2 main categories. An AppSec engineers' skills are also commonly required to triage a Penetration Test reports or the findings from Attack Surface Management or the many vulnerability tools (like Nessus). These, while actually Security Operations not AppSec, are where we see Vulnerabilities.

As shown in Figure 1 there is a tool category called SCA (Source Composition Analysis) which solely provides known vulnerabilities in third party code. These vulnerabilities are often reported as CVEs (Common vulnerabilities and Exposures) from various sources such as security researchers or vendor advisories.

Apart from these specific finding categories, explicitly where we see a CVE or have observed an exploit, the findings are simply code defects and not vulnerabilities.


Essentially the AppSec program must integrate with the existing defect remediation process of the organisation or suffer from a failure to be prioritised or even adopted by engineers.

Bottom line; A finding in any report is most likely not a vulnerability unless it has proven you are exploitable. It may call the finding whatever it wants to call it, but calling it a vulnerability does not mean they know you are vulnerable or even have any clue at all if what they found is even valuable to alert you about!

More than 99% of reports include findings that are misconfigurations that might be a compliance issue, but not a vulnerability. They may even be simply a false positive, or something that would make you vulnerable if the firewall was not blocking access to it or some other mitigating environmental context the report is ignorant to. Most of the time you are safe, and the defect needs to be investigated and triaged, which is never an activity any tool will provide on the market in 2021-22. Sometimes a good penetration tester will validate a finding and prove the defect is an exploitable vulnerability, but even most penetration testers just report findings without any proof of concept to show a working exploit.

And finally, if the scan report looks at code that has not yet been deployed to production systems you are certainly looking at defects not vulnerabilities. period. Because in AppSec and DevSecOps we are looking at potential vulnerabilities before they become a vulnerability! i.e. they are defects!