DEVOPSdigest

Debt. No matter how you slice it, debt is rarely a good thing. In the world of software development, security debt — the accumulation of unresolved flaws in code over time — poses an unrelenting challenge. As organizations increasingly move toward a DevSecOps model in which application security practices are introduced early and applied continuously throughout the SDLC, they are well positioned to decrease their security debt.

What's Behind Security Debt?

Security debt doesn't discriminate. It affects every industry and every type of organization, old and new. Organizations that have been around for any amount of time will have substantial security debt. Driven by the rapid pace of today's development cycles, security debt adds up quickly.

DevOps practices, which help fuel rapid, continuous development and delivery, can also increase the risk of vulnerable code. One recent report found nearly half of organizations surveyed push vulnerable code in order to meet a critical deadline. In addition to the potential security risk this introduces, this practice also increases security debt.

Like financial debt, security debt tends to grow exponentially. And it's difficult to reduce that debt if developers struggle to find and fix vulnerabilities in the CI/CD pipeline. It's a vicious circle that can pit security and dev teams against each other and puts the dev team in a tight spot as they juggle the need to develop new code and fix existing vulnerabilities.

The State of Software Security Report Vol. 11 (SOS 11) found 76% had at least one security flaw, but only 24% have high-severity flaws. That's a sign of progress — remediation rates are improving year over year. Our research showed 73% of discovered flaws were closed or remediated versus 52% in 2018 and 56% in 2019.

The top three most common flaw types remain consistent:

1. Information leakage

2. CRLF injection

3. Cryptographic issues.

Yet, fix rate is still a problem with half of security findings still open six months after discovery.

Is Security Debt Really All That Bad?

One school of thought suggests security debt isn't a big deal, either because those latent vulnerabilities will eventually get fixed or the code will become obsolete.

Data shows developers prioritize the most recently found flaws first, which is both good and bad. Developers run the risk of contributing to security debt when older flaws are stacked underneath newer issues. Not to mention, older flaws may be as or more severe than newer ones. Certainly, an older injection flaw is just as dangerous as a newly discovered one.

As time goes by, the probability of remediation drops significantly, and any unmitigated flaws join existing security debt. This can lead to more serious repercussions, namely, attacker motivation to discover and exploit latent vulnerabilities and the cost of a security breach. reducing security debt — fixing the backlog of known flaws — lowers overall risk. SOSS 11 found that older applications with high flaw density experience much slower remediation times, adding an average of 63 days to close half of flaws.

Strategies to Reduce Security Debt

Techniques for reducing security debt include regular scanning for new flaws and concerted investment in preventive and remediation measures, including tools and developer education.

By far the most effective of these techniques, application scanning, has been shown to improve median time to remediation (MedianTTR) significantly. Our research found frequent scanning can reduce the half-life (time to close half of security findings) by more than 3 weeks. Doing so at a regular cadence is correlated to a reduction in half-life by more than 2 weeks. And those that use static and dynamic scanning together fixed half of their flaws 24 days faster.

Application scanning usually includes static analysis, software composition analysis, and dynamic testing. DevSecOps practices rely on frequent scanning throughout the development cycle. Organizations that scan their code for security most frequently and regularly, fix security flaws 72% faster than those that scan less and less often.

In addition, organizations that automate security testing in the SDLC address half of their flaws 17.5 days faster than those that scan in a less automated fashion.

Ultimately, the best method for reducing security debt is to avoid creating it in the first place. As developers are increasingly tasked with shifting security left, it's critical they receive the proper security education to enable them to actually fix the flaws they're finding. However, half of organizations only provide developers with security training once a year or less.

For developers to improve their knowledge of code vulnerabilities, working in a hands-on application that allows them to find and fix real code, then apply that knowledge immediately to their work, is most effective. This type of practical, interactive training empowers developers to learn and retain secure coding skills that ultimately reduces security debt over time.

Left Is Best for Secure Code

That mountain of security debt will continue to grow unless businesses have practices built into the software process to get ahead of vulnerabilities and stifle security debt. By bridging the gap between security and development, testing earlier in the development process, and training developers to remediate flaws in their code, organizations can keep up with tamping down security debt.