Recent years have seen a sharp increase in the number of reported security vulnerabilities, along with quite a few notorious attacks on enterprise applications. Organizations have reacted by increasing their investment in AppSec and DevSecOps, including the widespread adoption of AST (application security testing) tools. While AST tools are an important step in achieving DevSecOps maturity, the focus on the detection of security vulnerabilities has also caused many organizations to accumulate a hefty security debt.
Security debt is a variant of technical debt. It refers to the accumulation of known security vulnerabilities in an organization’s software and infrastructure. As organizations increase their investment in application security, developers and security teams are bombarded with extensive lists of alerts and many vulnerabilities are left behind, resulting in a build-up of un-addressed vulnerabilities that leave them open to malicious attacks.
In 2016, Gartner predicted that through 2020, 99% of the vulnerabilities exploited in breaches will be ones that were known by security and IT professionals for at least one year. Currently, the accumulation of existing and known security vulnerabilities in an organization’s application layer continues to be a top concern for organizations. Attacks like the Equifax breach in 2017 prove that ignoring a known vulnerability or postponing its remediation is not the right way to deal with security debt.
Clearly, no one sets out to accumulate security debt. Rather, the challenge of addressing security debt usually creeps up on an organization as security and development teams struggle to stay on top of the constantly growing number of security vulnerabilities discovered in their systems. Unfortunately, a recent Ponemon Institute report found that security debt is a burden for many enterprise organizations today.
Over the past years, the rise in awareness of the risks of application security has heightened the security research community’s focus on analyzing code and uncovering and disclosing security vulnerabilities. The white hat hacker industry is booming both in the open source and commercial software development communities, and as a result, more vulnerabilities are discovered. One example is the exponential rise in the number of open source vulnerabilities over the past couple of years, due to increased research in the open source community and the software development industry.
On top of the rise in the number of disclosed security vulnerabilities, the use of application security tools also contributes to the rise in security alerts that teams are requested to deal with on a daily basis. Unfortunately, most application security tools are focused on the detection of security vulnerabilities in proprietary and open source components, while prioritization and remediation capabilities are usually missing. That means that teams get all of the security alerts, with very few means of speedy remediation.
Racing to keep up with the rapidly increasing pace of release cycles, it’s nearly impossible for security and development teams to address all of the security vulnerabilities detected in their code. Security debt is easily accumulated when there is no clear and defined policy for prioritization and remediation of vulnerabilities.
As the number of security alerts developers and security professionals must address continues to skyrocket, it’s becoming clear that detection is simply not enough. In order to reduce security debt security processes and tools must be shifted left, and be implemented throughout the SDLC.
In a recent survey of security professionals and developers, we learned that security pros are aware of this issue, and they consider security prioritization their number one challenge in managing their AppSec program.
In order to address rising security debt, security and development teams need to bridge the gap from detection to remediation. This requires them to focus on the security vulnerabilities that present the most risk, and keep their critical vulnerability count low.
Unfortunately, data shows that there is currently no industry standard or practice for vulnerabilities prioritization. Different teams prioritize security alerts based on a multitude of considerations and end up spending a lot of precious time deciding what to fix first.
Prioritizing security vulnerabilities remediation is complex work. When analyzing security vulnerabilities to decide what to fix first, it’s essential to create a methodology that focuses on the data that matters, going beyond the data that is the easiest or cheapest to access or resolve.
Once organizations adopt a vulnerabilities prioritization strategy that addresses the vulnerabilities that directly impact their systems, they can both narrow down the long list of security issues that they need to address, and also ensure that they are remediating the most critical risks fast, rather than wasting time trying to determine what to fix, or patching the vulnerabilities that are easiest to address.
The good news is that the application security testing tools market is full of automated solutions for the continuous detection of security vulnerabilities. The bad news is that most of these solutions don’t address effective automated prioritization and remediation.
Automating these critical and time-sensitive processes helps organizations save a lot of the time that they currently spend manually analyzing vulnerabilities, their dependencies, what they affect, and trying to assess how critical they are. The debates about what to fix first can be avoided and that valuable time can be spent on developing secure code.
An ounce of prevention is worth a pound of cure — this goes for the DevSecOps pipeline, too. When it comes to reducing security debt, prevention by way of secure coding can no longer be ignored. As security shifts left and developers take an active part in AppSec, advanced vulnerability detection and remediation tools should be integrated into developers’ native environments, so that threats and security risks are addressed as early as possible, when they are still relatively easy and less expensive to fix.
Reducing security debt requires a DevSecOps approach with all hands on deck. This means that ownership over security vulnerabilities management must be shared across teams. The number of vulnerability alerts that organizations are now faced with on a daily basis simply cannot allow a fractured approach to security.
In order to manage security debt, a vulnerability management policy must be adopted throughout the organization’s teams. Security must be addressed continuously throughout the DevSecOps pipeline, with security and development teams working together to ensure that critical vulnerabilities are mitigated as soon as possible.