AppSec vs. DevSecOps, and what that means for developers

Traditional application security is different in two key ways from what has come to be known as DevSecOps. First, modern software companies are integrating application security into their DevOps pipelines, so security becomes part of the flow. Second, it’s also about DevOps being built into application security.

Patrick Carey, who leads product strategy in the Software Integrity Group at security solutions provider Synopsys, explained these differences. By building application security into your automated development environment, he said, security “is initiated through events, rather than necessarily a phase where somebody at the end of the line, whose job it is to make sure that you didn’t screw up and code a vulnerability,” does the testing.

On the other side of that coin, building DevOps into AppSec, eliminates the gates created by traditional DAST or pen-testing tools, creating instead guardrails that allow the team to move forward with relatively low friction but to stay on track. In the traditional gated pass-fail system, “if you fail you got your vulnerability report that just said you know there were a bunch of vulnerabilities, but oh, by the way we can’t tell you exactly where those are in your code; your developer’s going to have to go figure that out.”

Building DevOps into AppSec, he continued, means you have to have tools that can be used earlier in the development workflow, in developers’ IDEs, but also in their code management systems and their build tools. Carey stressed that what’s really important is to do risk-based analysis to determine the right types of tests to run on specific parts of the code, at the right time. “That,” he said, “is what will really make it compatible with a DevOps high-speed flow.”

Carey said the state of the industry today is more about building AppSec into DevOps, integrating traditional tools into the pipeline. But, he pointed out, because traditional AppSec tools weren’t built for that model, teams are running into three main problems. 

The first is what he called pipeline friction, where a traditional AppSec tool, once hooked into a CI/CD pipeline, could take two hours to do an analysis, while the build pipeline is generally running on a three-minute end-to-end build. “So you have an inherent mismatch there in terms of throughput rate so teams will run into where they’ll get the scripting in place to to invoke a scan, and then they find that that immediately cripples their pipeline. That’s a problem that the teams are grappling with and can stall a lot of DevSecOps initiatives,” he explained.

The second problem, he noted, is the slow pace of developer adoption of traditional testing tools in general.  “I was asked once, you know what, what are developers looking for in security tools and my immediate comment was, well, they’re not,” he said. “They generally try and avoid [testing tools] like the plague,” because they recognize that the tools have historically caused friction.  

Finally, there is the issue of vulnerability overload, he said. “If you’re familiar with the outputs of traditional AppSec tools they can produce a pretty high incident rate of false positives,” he said. Things that the tool flags as potentially being vulnerabilities but turn out after investigation not to be are “real killers” for teams because of the time wasted. 

“If a pipeline friction is about actually crippling the automated portion of DevOps the vulnerability overload is crippling the human portion of that developer workload,” Carey explained. 

To get developers to adopt security into their work, Carey said organizations are moving from a model that imposes it from above, “moving away from the stick and more towards the carrot.”

It is important to enable developers to do their security work in their IDEs and other DevOps tools. “You’ve got to bring the application security to them,” Carey said. “They don’t want to move to somebody else’s UI and then go and look in that interface to do the security analysis, and then come back to the IDE. You’ve got to meet them where they are; as much as possible you need to make the AppSec analysis invisible to them.”

Synopsys is tackling the problem with its own Code Sight tool, which is a free plug-in to the IDE that connects to the company’s static analysis and software composition analysis tools and its e-learning capabilities, which offer a kind of on-the-job training for developers who haven’t been trained in software security.

Code Sight identifies vulnerabilities and bugs while the developer is coding. It can perform efficient scanning in the background, and it meters how much of the CPU it’s consuming so it’s not perceived as slowing down developers’ machines. 

“Let’s just show them the security issues they need to deliver so we don’t highlight the fact that it’s SCA and SaaS so much as, ‘When you’re working on this project, here are the security issues that we’re finding.’ And Code Sight can point developers to the line of code that’s problematic, offer remediation guidance, and even allow them to take a short course through e-learning so they can come up to speed in that type of vulnerability and how to fix it.”

“Again,” Carey said, “it’s trying to make it seamless and integrated into their existing environment rather than waiting on another solution that they have to go and interact with separately.”

 

Content provided by SD Times and Synopsys

The post AppSec vs. DevSecOps, and what that means for developers appeared first on SD Times.

from SD Times https://ift.tt/37HWl4p