Over the last 20 years, cybersecurity has changed a lot, but one thing has remained resistant to change: scanning resources for defects and fixing them. Now may be the time to hop off that scan-and-fix hamster wheel, argues Chris Romeo, CEO of the threat modeling company Devici, in a recent Security Table podcast.
"This pattern is just wrong. It's broken. We've seen a history of the challenges following this pattern does in working with developers."
—Chris Romeo
Travis McPeak, co-founder and CEO of the policy-as-code tools company Resourcely, seconded Romeo's call for a reset in commenting on Romeo's LinkedIn post on the subject.
"You're singing my song. Scan and fix sucks. We'll always be in reactive, vulnerability management hell. As an industry, we're pretty bad at vulnerability management. Sixty percent of breaches involve known vulnerabilities."
—Travis McPeak
But wait. Wasn't "shifting left" — moving security functions closer to the beginning of the application development lifecycle — supposed to derail the hamster wheel by averting security problems that needed fixing? "No," Romeo argues in his LinkedIn piece. "It just recommends starting the hamster wheel earlier," he wrote.
When will application security evolve? Experts say replacing scan-and-fix could remain elusive. But tools are emerging that could slow that hamster wheel and provide prioritization and automation.
[ See special report: The Evolution of App Sec | See Webinar: Why AST fails at supply chain security ]
Are RASP and IASP the answer?
What about using app sec tools that don't scan and fix, but rather view and block or allow? Could applying the techniques used by runtime application security protection (RASP) and interactive application security testing (IAST) tools be the answer?
Jeff Williams, co-founder and CTO of Contrast Security, said RASP actually does "fix" flaws, although it does it at a different — and better — location. For example, instead of trying to fix every SQL query everywhere (which will never happen), RASP adds a trust boundary to database access methods to detect when untrusted data modifies the meaning of a query — essentially the definition of a SQL injection attack, he explained.
"So with RASP, you get both visibility into who is attacking, what vectors they are using, which vulnerabilities they have discovered, and really strong protection against exploit. The typical 'fix' — replacing with a parameterized query — thwarts the attacks, but you get no visibility. And you have to modify all of the queries."
—Jeff Williams
Romeo said RASP and IAST won't work in practice as alternative to scan-and-fix, however.
"We’d have to embed static application security testing (SAST) into the runtime of the application, where it scans the code as it’s used and blocks the request if there was a code-based flaw. I’ve already talked myself out of this option for many reasons."
Those reasons include a hit on performance and the placement of a security control in a strange place, Romeo said.
What about an IDE solution?
Another place to break the scan-and-fix pattern might be in the integrated development environment (IDE).
"If we could introduce the scanning function into the IDE in real time, we should be able to sound a buzzer and get the developer to fix the problem in real time so we get away from the stack of issues."
—Chris Romeo
However, all that buzzing is likely to break developers' workflow and hurt their productivity, Romeo said. "This still doesn’t feel like the answer to our industry’s woes."
Paul Hodgkinson, a security specialist at GitHub Advanced Security, said that having security alerts and fixes in an IDE would be effective — but also pose problems.
"[Getting] consistency in using alerts in IDEs is very hard. You’ll never get 100% compliance in most teams. That means you always have to follow it up with checks in the code review pipeline, such as at [pull request] time or in [continuous integration] for those who don’t do [pull requests]."
—Paul Hodgkinson
Hodgkinson added that real-time scans have a trade-off of the usual triad of speed/quality/cost. "Deep SAST analysis with dataflow and taint, and accurate representation of the code takes time and is expensive in processing, relative to fast scans that can give you partial results," he wrote in response to Romeo's post.
"Some tools claim they can operate in your IDE but then farm the work off to a server and you eat the resulting costs. Some tools claim to operate in your IDE, but they're anemic cut-down tools that don't satisfy."
—Paul Hodgkinson
What about AI?
Artificial intelligence (AI) seems to be the answer to all the world's problems these days. Could AI offer an alternative to scan-and-fix? Might an AI tool scan and introduce PRs/fixes that relieve the ignored issues problem?
"[Even] with AI, we’re still talking about scan-and-fix. It's just fancy robot fixing."
—Chris Romeo
So what's so bad about scan-and-fix after all?
During the Security Table podcast, there was some pushback to Romeo's criticism of scan-and-fix from Izar Tarandach, a senior staff engineer at the monitoring and security platform Datadog.
"Scan-and-fix, by itself, is not a bad thing. It may generate results that are not optimal, but if you add context by understanding more and more about where that scan is happening, you're going to have shorter, prioritized, contextualized cycles of fix."
—Izar Tarandach
So rather than breaking the pattern — which still has value, especially as the knowledge we have gets better — "it becomes a problem of prioritization," Tarandach said.
Smarter app sec tools are emerging
ReversingLabs field CISO Matt Rose said the problem with the hamster wheel of scanning and fixing is its focus is on identification over remediation.
"Organizations are typically great at identification but less effective at remediation. The best way to address remediation is by having a clearly defined and understood security policy that defines what risks you care about and what risks are not important. This saves time, money, and resources."
—Matt Rose
The main problem with scan-and-fix is noise — lots of alerts, lots of false positives, lots of false negatives, said Matthew Coles, Product Security Engineer at Dell Technologies, during the roundtable.
The way you solve that is you make the results prioritized, more actionable — and less noisy, Coles said.
"So you need the tools to be smarter because that will reduce the noise and allow humans to make intelligent decisions about what to fix first. But you're not going to ever solve the problem because developers are introducing bugs into the system. Until that stops, you're going to have to have analysis."
—Matthew Coles
