Secure application development can create a lot of technology clutter in the form of false positives, vulnerability alerts, misconfigurations and other noise that distracts developers from more important tasks. Another form of clutter is security debt, a product of rushed development that builds up over time and makes systems and applications more vulnerable.
AppSec noise and how it annoys
We’ve gone into depth about AppSec noise in previous articles. For DevSecOps, alerts and false positives can represent a tedious and repetitive tasks that takes away from other aspects of development.
Tracking down false positives and other alerts takes personnel away from more valuable tasks, such as debugging actual security vulnerabilities, and may even add to security debt.
“There’s a lot of time wasted sifting through AppSec noise while threat actors work away in the background,” wrote Invicti’s Meghan McBee in a February 2023 blog post. “Teams run the risk of leaving actual severe threats on the table while they’re busy chasing phantom flaws.”
Static application security testing (SAST) tools and the first generation of dynamic application security testing (DAST) tools are notorious for creating “noise.” That’s because they flag every possible vulnerability or flaw without verifying that the flaw is real.
“SAST tools, in particular, have a reputation for flooding developers with security issues that, while technically accurate, are irrelevant in a specific context,” wrote Invicti’s Zbigniew Banach in an August 2022 blog post. “This requires tedious fine-tuning to prevent developers from being flooded with false positive reports.”
All this noise can overwhelm DevSecOps teams and let potentially serious vulnerabilities slip by. In a 2022 survey of 500 DevSecOps professionals commissioned by Invicti, 68% of respondents said they ignored possible security flaws flagged during testing at least once per week. Nearly all respondents — 97% — admitted that at least once per month, a vulnerability alert that they dismissed as a false positive turned out to be real.
As a recent Invicti white paper stated: “False positives can … directly influence application security. As developers and testers lose confidence in a vulnerability scanner that generates mostly false alarms, they might start routinely ignoring whole classes of issues from this tool.”
Piling up the security debt
Routinely ignoring possible vulnerabilities may cut down on development time, but it’s a sure-fire way to accumulate security debt.
What is security debt? It’s best to think of it as a subset of technical debt, a term coined by agile-software-development pioneer Ward Cunningham in the 1990s to describe the “cruft” that builds up when development teams take quick-and-dirty shortcuts and write imperfect code to get a product out the door.
The longer technical debt builds up, the harder it becomes to go back and rewrite all the code that should have been written properly in the first place. Eventually, the software product can no longer be improved and must be abandoned.
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite,” Cunningham wrote in 1992. “The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.”
Security debt occurs when developers fail to patch flaws during production or create workarounds rather than properly fixing a potential vulnerability. Security debt is worse than technical debt because it doesn’t just impede future development — it makes software more unsafe and at greater risk of being exploited as time goes on.
An often-cited example of technical debt is the Equifax data breach of 2017. The attackers exploited a known vulnerability in Apache Struts for which a patch had been issued two months previously, but which Equifax had not implemented.
“Whether there is an out-of-date library that you know you should really patch, or a poor handling of a parameter you have that bad feeling about,” pointed out Invicti’s Dan Murphy in an August 2022 blog post, “each of those tiny items of debt presents a potential weekend lost to an incident, or many, many hours wasted in a meeting poring over the details of a breach.”
Invicti’s McBee said security debt piles up not only because code is rushed to production without undergoing the proper checks and scans, but also because tools may be updated without checking third-party software dependencies and because siloed teams may not communicate or share knowledge.
“Over time, security debt can slow everything down, even and it sits there collecting dust as a potential backdoor for bad guys,” she wrote in February 2023. “Pushing code to production without going through the proper security checks and tools may seem like a time-saver but only adds to lingering debt in the long run.”
In our next article, we’ll discuss how to use next-generation DAST tools to cut down on DevSecOps clutter and lighten the security-debt load.
