This week, we have a guest post from Setu Kulkarni, VP of Strategy and Business Development at WhiteHat Security.

Applications have become one of the most critical, if not the most critical, business driver. Consequently, application security related risks are one of the most significant, if not the most significant business risks. With numerous technological advances comes the promise of increased efficiency and performance for business application but at the same time inadequate and ill-designed application security approaches are exposing organizations to risks. This is according to our latest Application Security Statistics Report, a comprehensive take on what’s working (and what’s not) in the world of application security.

The good news is that organizations are more aware than ever of their application security risks, with a 20% increase in the number of applications that organizations are testing.

The bad news is that remediation rates have fallen, which is a huge concern. The remediation rate for critical risks, for example, is 50.7% in the US and just 40.7% in Europe.

There are a couple of factors that could explain the low numbers. First, since we know organizations are testing more apps, they may not be increasing their investment in fixing vulnerabilities, decreasing the remediation rates. 

Second, we know there is a global shortage of application security professionals, meaning that organizations may have difficulties obtaining the skills and resources they need to keep up with remediation needs. 

Also hampering organizations’ ability to keep up with vulnerabilities are the embeddable components in the software supply chain. We found these components account for one third of all application security vulnerabilities. In fact, we saw a 50% increase in unpatched library vulnerabilities this year. This is a dangerous trend, as more open source and third-party software is embedded in organizations’ own applications. It also underlines the need for software vendors that provide these components to raise their security standards.

With these statistics in hand, it’s clear that organizations should make DevSecOps an integral part of their application development and delivery strategy. This means embedding security in their development and operations in a phased approach – one that offers a clear roadmap for comprehensively addressing the diverging needs of existing in-production applications and an increasing number of new applications coming online. 

It should also enable the implementation of application security in a programmatic manner with verifiable metrics for tracking success.

In the report, we identify three recommended metrics-driven phases that are proven to succeed in securing applications. In summary, they are: 

Phase 1 – Risk Discovery and Management 

Key metrics:

  • Window of Exposure – this metric represents the amount of time an application has a serious vulnerability that can be exploited to data breaches. As such, organizations should develop a Service Level Agreement (SLA) for “Window of Exposure” and aggressively try to reduce it for all their applications.
  • Time-to-Fix by Risk – this provides an industry baseline for how long it takes to fix a vulnerability and associates that with risk (to the organization). Developing an SLA for “Time-to-Fix by Risk” and working aggressively to reduce it for vulnerabilities in your applications is, therefore, critical.
  • Remediation Rate by Risk – this represents the percentage of vulnerabilities that are fixed, organized by level of risk. Therefore, develop SLAs and procedures/training to promote remediation efforts by taking a risk-based approach. Track the “DAST and SAST Remediation by Risk” metrics to see that the most serious vulnerabilities are being prioritized for remediation.

Phase 2 – Release Assurance 

Key metrics:

  • Average Time-to-Fix (SAST) – this metric provides an industry baseline for how long it takes to fix a vulnerability in general. Organizations should develop an SLA for this metric and aggressively try to reduce it for all vulnerabilities.
  • Remediation Rate by Risk – as with Phase 1, this represents the percentage of vulnerabilities that are fixed, organized by level of risk. Develop SLAs with procedures and training that promote remediation efforts by taking a risk-based approach. Track the “DAST and SAST Remediation by Risk” metrics to ensure the most serious vulnerabilities are being prioritized for remediation.
  • Vulnerability Prevalence by Class (SAST) – organizations are increasingly adopting open source and commercial off-the-shelf components to rapidly innovate. As such, the likelihood of inheriting vulnerabilities is higher than ever before. Baseline your development teams’ security goals by creating an SLA around reducing the most likely vulnerabilities by class.

Phase 3 – Developer Enablement

Key metrics:

  • Vulnerability Prevalence by Class (DAST and SAST) – use this to set up focused and recurring training for your development, operations and security teams. Track your teams’ progress by tracking Vulnerability Prevalence by Class for the applications they develop and evolve your training efforts to meet the evolving needs of your teams. 
  • DAST and SAST Remediation by Risk – use the “DAST and SAST Remediation by Risk” metric to baseline your teams’ goals. Develop SLAs and procedures/training that promote remediation efforts by taking a risk-based approach. Track the “DAST and SAST Remediation by Risk” metrics to see that the most serious vulnerabilities are being prioritized for remediation.


As Peter Drucker, the father of management thinking, once said: “If you can’t measure it, you can’t improve it.”

Unless and until you can measure something, you can’t make it better. Or, in our case, more secure. At each stage of the software lifecycle, capturing core metrics like those we outline in the DevSecOps approach will offer advanced insight into how applications are already at risk or can be exposed to risks, even when they are in production. These metrics offer the chance to make adjustments when they are far less costly to the organization.

Click here to read the full report and learn more.