Application security is one of the fastest-growing sectors of infosec, yet according to some experts, it's inefficient and out of date.
These skeptics point to arguably artificial divisions between the AppSec and Operations teams, to tools like static and dynamic application security testing (
SAST and DAST) that boost bug detection but not remediation, and — in a rebuke of apparent AppSec orthodoxy — the failure of "
shift-left," the attempt to get software developers to build in security early in the development process.
"
AppSec was, and still for the most part is, a development problem, and it's never really been brought into that production sphere," says Dave Lindner, CISO of Contrast Security. "The realities are stark. There's about three times more vulnerabilities found than can be fixed in a month's period, and if you start adding that up over time, we have these huge backlogs."
The solution, Lindner and Contrast Security Co-Founder and CTO Jeff Williams say, is to tear down the walls that separate the AppSec and
Operations teams and to let developers focus on writing code instead of worrying about security.
"The right way to break down these silos is to give Operations a great product that they can use for AppSec that's tightly coupled with the instrumentation-based
vulnerability detection," says Williams. "We want to bring those two worlds together."
Is traditional AppSec not keeping up?
A
recent report from Contrast found that on average, an application generates about 17 new vulnerabilities per month, but developers and AppSec teams fix only about six of those. Patch time for each flaw is about three months, and new AI-powered offensive techniques let attackers find flaws faster.
"The average [organization] has something like 1.1 million application and API vulnerabilities in their backlog," Williams says. "In a big enterprise with hundreds or thousands of applications, there are lots of new vulnerabilities every month, and they're only fixing six every month per app. So we're getting net 11 per month. If you scale that up, it adds up really fast."
So much code is being written so quickly that traditional application security, even with automated detection and remediation tools, is consistently falling behind the huge number of bugs found, argues Williams.
"Even though it seems like you're automating the problem, you're really not," says Williams. "You're generating tons of false positives that then need to be researched by people who know application security, so you're right back into the same bottleneck that you had before."
As to whether the widespread use of SAST, DAST and software composition analysis (SCA) helps application security, he scoffs.
"I don't know what advances in SAST and DAST you're really talking about, but those technologies came out in like 2001 to 2005 and they haven't advanced significantly," Williams says. "I'd say SCA is in the same boat. Something like 95% of findings made by SCA are not really exploitable in production for one reason or another."
Likewise, he feels that folding application security into the continuous integration/continuous delivery (
CI/CD) cycle doesn't result in many gains.
"It's nice to have tools integrated into CI/CD pipelines," Williams says, "but if they're throwing off tons of errors, then it's not really a pipeline, because you have to have this async process where you go off and research those vulnerabilities and investigate them."
Shift-left can knock you off balance
Shift-left, or moving up application-security testing earlier in the application-development process, "kind of failed," argues Lindner, because it made developers suddenly have to do the job of security analysts.
"It didn't really do anything other than shift the responsibility," he says. "Well, guess what? Developers have day jobs. They work for product, who works for customers."
That's not saying shift-left wasn't a nice idea, Lindner adds. Yet as is often the case, doing something is very different from thinking about it.
"We thought it would be great. 'Oh, do it in process and you'll just fix things faster,'" he explains. "But that wasn't the reality. None of the tools, none of the scanners out there work very well in process. It slows things down. They're not risk-based. I mean, it just became really, really messy. No one's talking about it anymore, because it just doesn't work."
As for the notion that fixing bugs earlier in the development process saves time and effort,
a 2016 academic paper found no substantial gains, as Williams cited in
a Forbes guest blog post.
"It is worth considering whether it's worth pushing security testing all the way left into the IDE [integrated development environment]," he wrote. "You lose a lot of context when you're only looking at source code."
Certain types of vulnerabilities and weaknesses are hard to catch early in the development cycle, Williams argued in the blog post, including
SQL injection, authentication and authorization flaws and weak
encryption algorithms.
"The best way to do the data flow analysis necessary to detect these vulnerabilities is to observe actual data flowing through a running application," he wrote.
Unfortunately, Williams also said in his Forbes post, "shift-left" doesn't mean what it used to, to the point where it doesn't mean much of anything at all.
"In my opinion,
'zero trust' and '
DevSecOps' are two prime examples of once-useful terms that were rendered virtually worthless as they became buzzwords through overuse and distortion of the initial concept," he wrote. "'Shift left' is another great example."
Breaking down the barriers
If SAST, DAST, SCA, CI/CD, shift-left and all sorts of automation can't help clear the AppSec bug-patching backlog, then what will? The first step is to recognize that AppSec shouldn't be restricted to the development process, Williams says.
"The application-security market is split," he says. "There's AppSec, which is mostly pre-production stuff. It's vulnerability management. There's scanner tools and teams and maturity models and process. And all that is one whole separate thing from application security in production, which has been predominantly WAFs," or
web application firewalls.
Why not let both sides of the house use the same tools and see the same data? Williams argues that this holistic approach, which he says Contrast's platform offers, will result in AppSec and Operations teams working more closely together and fixing issues faster and better.
"Rather than having those two things happen in a vacuum, where they're both doing their own separate process, we want to bring those processes together so they'll share the same triage and they're coordinating their response," he says.
"Imagine there's a new incident on an application or an
API," Williams posits. "You want two workflows to get started. You want a very fast workflow for the incident-response team to create an incident, stop the bleeding. Maybe they block an IP address or something."
"But," he adds, "they didn't fix the underlying vulnerability. If the attacker switches to another IP address, they can just keep on attacking. And so the other workflow is [for the AppSec team] to go fix that underlying vulnerability."
One factor that should speed this process in Contrast's platform, Williams says, is the Contrast Graph, a dynamic model of the relationships and dependencies among all the assets in an organization's entire system that helps Contrast's software quickly determine whether a potential vulnerability is actually exploitable.
By making this data visible to both the AppSec and Operations teams, the two will cooperate more. At least that's the theory.
"By giving them a shared model of reality, then they can talk in the same terms. They can use the same name for applications. They can use the same incident ID and issue ID," Williams says. "The issues and incidents are linked together. We're facilitating the communication."
