Ever heard the expression, ‘The perfect is the enemy of the good?’
This sentiment is certainly true when it comes to application security testing.
DevSecOps teams can become so focused on removing every vulnerability, misconfiguration, or flawed line of code, that they can’t get a product or a feature release out the door.
According to a recent Gartner report, “Perfect application security isn’t possible and, in the misguided pursuit of zero-vulnerability applications, heavyweight security testing becomes an obstacle to the speed of digital business.”
Let’s dive into Gartner’s thoughts more closely, and discuss how an application security platform can help businesses to better prioritize to ensure risk reduction without negatively impacting developer velocity.
What is Zero-vulnerability?
First, let’s understand what we mean when we talk about zero vulnerability, not to be confused with zero-day vulnerability.
While a zero-day vulnerability is a security flaw which is unknown to the software developer or vendor, and as a result has no known fix or patch available, when we use the term zero vulnerability, we mean exactly what the term suggests – no flaws or vulnerabilities.
As such, an application which is zero-vulnerability has no risk at all.
Anyone who has ever worked in a software development environment knows that this ask is pretty much impossible.
No application can be truly zero vulnerability, due to a number of factors, including:
- Software complexity: Modern applications may have millions of lines of code, and provenance over this code can change over time. The more complex the code, the more likely there will be errors or vulnerabilities due to connected components.
- Attack landscape: The way threat actors behave and their Tools, Tactics and Procedures are changing all the time. Even previously secure code may become vulnerable to new exploits over time.
- Dependencies: Applications may rely on third-party libraries, registries, frameworks or modules to simplify development or to add functionality with greater ease. If a third-party component is vulnerable, so is the application which leverages it.
- Developer expertise: Developers are not security experts, and nor should they have to be. Even if the company has an extensive testing and code review regimen, vulnerabilities can still occur.
- Unknown vulnerabilities: As well as zero-day vulnerabilities, applications may interact with an external system such as the operating system or hardware. When changes occur there, developers may not have considered the impact.
- Usability: Developers may prioritize the UI of the software, and fail to balance the need for security with performance and usability. Security leaders need to consider whether features built to be user-friendly may open the environment to risk.
Despite the impossibility of a zero-vulnerability application, many organizations are still attempting to uncover this holy grail, and implement processes in their development environment which will allow apps to be totally risk-free.
This cannot help but slow down the pace of development, and negatively impact developer velocity. No wonder Gartner calls this pursuit “misguided”!
It’s no surprise to see that Gartner have found 41% of security leaders say a top three blocker to achieving good security outcomes is that software engineers often deprioritize security tasks in favor of delivery speed.
Finding a Balance: How to Prioritize to Enable a DevSecOps Culture that Works
Instead of attempting to find the route to create the mythical zero-vulnerability application, Gartner’s advice is to “Focus developers first on known vulnerabilities with the greatest risk and confidence levels by using tools that push prioritization features such as risk metrics.”
What do we mean by the greatest risk and confidence levels? In short, it means implementing risk-based prioritization that considers how likely it is that a security incident will occur, and maps that against the impact on the business. Items that fall in the top-right quadrant, as very impactful and very likely to occur should be prioritized for remediation.
Gartner suggests using risk factors including known vulnerabilities, the probability of the exploit, the health and reputational analysis you have, your specific attack surface, the operational impact of an attack on this asset, and the extent to which the application or code will be used.
One area to focus on according to Gartner is known vulnerabilities in third-party code. Developers often make heavy use of public repositories, registries and sources that provide them with pre-built components, libraries, containers and frameworks, and in the era of Generative AI, much more. Gartner notes that in this landscape, “custom code can become a minority percentage of the code in a modern application.” With this in mind, an application security platform needs to go further than scanning custom code, and include tools for automatically scanning third-party OSS packages, libraries, and any other third-party components in use.
Gartner’s checklist for assessing apps for known vulnerabilities include:
- The developers unit of work, including the VM, container and machine image.
- All source code for embedded OSS code that has known vulnerabilities
- All Operating System files, executables and dynamic link libraries and all platform files
- Third party commercial libraries and common applications
- Configuration vulnerabilities, including all processes and services running and ports open/closed.
Understanding how Checkmarx Uses Exploitability for Prioritization in Software Composition Analysis
At Checkmarx, we know that while the best practice may be to only use secure components and packages, in reality — not everything can be done at once, and there will always be a security backlog. We use the concept of exploitability to help developers with risk-based prioritization and the right metrics to recognize where efforts should be placed first. This means that crucial security efforts are far less likely to be deprioritized in favor of getting a release out the door, as teams are given the insight and vantage point to understand what’s really important.
First, we make sure to support metrics including Known Exploited Vulnerabilities (KEV) and Exploit Prediction Scoring System (EPSS). Similarly to the Gartner approach above, metrics like these weigh the likelihood of an exploit occurring based on risk factors such as vendor response and availability. A zero-day vulnerability would have an extremely high EPSS, while an exploit that has a known fix would be a lot lower, as just one example.
Checkmarx One also offers you the ability to visualize the Exploitable Path, uncovering exactly what’s being used by each software package. If for example there is a vulnerable element but you’re not using it in your configuration — you’re safe to deprioritize remediation for now. While we may always recommend using secure software packages, you can make smart decisions around how to manage your own level of risk, with all the information at your fingertips.
As well as scanning custom code using SAST, and implementing container security, IaC security and more, Checkmarx One is built to support DevSecOps teams with the evolving development landscape. As Gartner attest — the reliance on third-party software components is a large part of that. Checkmarx One’s Software Composition Analysis is more than just a catalog of software packages and their vulnerabilities, it gives you the visibility into exploitability so that you can implement a thorough risk-based prioritization strategy in your organization.
Stop looking for zero-vulnerability applications, and start uncovering the relevant-vulnerability applications with a demo of Checkmarx One.