In our previous article, "How tech clutter complicates DevSecOps," we examined how false positives and other alerts can hamper application security and development, leading to shortcuts that add to security debt. Today we'll look at how to reduce this clutter and make your overall development environment more productive and more secure.
Tech clutter, noise and security debt
Older DevSecOps methods such as static application security testing (SAST) and the first generation of dynamic application security testing (DAST) are well known for generating a huge number of alerts, many of which will be for false-positive vulnerabilities, duplicated vulnerabilities or trivial matters.
This "noise" clutters up the workdays of DevSecOps personnel, forcing them to spend an inordinate amount of time on wild-goose chases just so that they can confirm that a false positive truly is one.
Because of this, DevSecOps teams have had to triage alerts by guessing which ones are not worth their time to follow up on. The unfortunate result is that genuinely dangerous vulnerabilities slip through the cracks.
Sixty-eight percent of DevSecOps professionals said they ignored potential security flaws at least once per week in a 2022 survey commissioned by Invicti. Almost all 500 respondents — a whopping 97% — admitted that at least once per month, a vulnerability alert they had dismissed as a false positive turned out to be real.
Needless to say, ignoring potential vulnerabilities, even out of necessity, adds to overall security debt.
Security debt consists of all those fudges and kludges — including unpatched minor vulnerabilities — that you've made over the years to just make sure things work but are in fact temporary solutions that ought to be fully resolved. The longer you wait to straighten out these workarounds, the harder it becomes to go back and make things right.
"Security debt is a buildup of quality control issues and flaws that make it more difficult to improve or build upon systems down the road because they include poorly executed workarounds and insecure design elements," wrote Invicti's Meaghan McBee in an August 2022 blog post.
McBee's definition would also apply to technical debt in general. But while technical debt makes systems eventually become unusable over a long period, security debt makes systems more vulnerable to exploits and attacks right away.
"Old debt tends to be dangerous when it comes to third-party components," said Dan Murphy, a distinguished architect at Invicti, in the same blog post. "Over time, more bad guys know about a key vulnerability, exploits become more readily available, and toolchains that automate the attack start to proliferate."
How proof-based scanning DAST cuts down on clutter and security debt
Newer DAST tools reduce the noise and take some of the guesswork out of vulnerability alerts by sifting out a fair number of false positives. For example, Invicti's modern DAST solution uses what the company calls "proof-based scanning" to automatically test and verify potential security flaws before generating alerts.
"You don't have to be Marie Kondo to declutter your web AppSec program – provided you use accurate DAST and build it into your workflows," wrote Invicti's McBee in a February 2023 blog post.
Invicti's DAST tool also incorporates some aspect of SAST code review so that it can peek inside the "black box" of the application being tested, an approach that is sometimes characterized as interactive application security testing (IAST).
Whatever the nomenclature, modern DAST tools let application-security-testing "shift left" in the software development life cycle (SDLC) so that potential flaws are worked out at an earlier stage, the accumulation of security debt is lessened and the software is more secure overall.
Other ways to cut down on security debt include "fuzzing" applications during development, which some modern DAST tools may incorporate, as well as having in-house developers keep lists of shortcuts they take during production. And even though DAST itself involves a fair amount of penetration testing, such testing should also be carried out routinely post-development on software that has already been deployed.
Because a large number of security weaknesses arise from third-party dependencies, a thorough inventory of all software assets, the use of a software composition analysis (SCA) tool to find dependencies, and a software bill of materials (SBOM) to list known components and dependencies can be very useful in identifying and reducing security debt.
"The path toward clearer and more effective security needs to be paved with modern scanning solutions that combine accuracy with automation to let your developers and security professionals cut through the clutter and work on the issues that matter most," wrote McBee in February 2023.
