Necessary but Not Sufficient – InApps 2022

“The number one misconception around DevSecOps is that it’s just sprinkling in a security tool,” said Matt Chiodi, chief security officer, public cloud, at Palo Alto Networks. There is no doubt that the right tools are an essential part of getting DevSecOps right, but they are not enough on their own. 

So what role do security tools play in improving development velocity, tightening security feedback loops and integrating security into the entire application lifecycle? I spoke with a number of security tool vendors about what is and is not solved by tooling. 

Automation, Prioritization, Communication

According to Hillary Benson, chief product officer at container security company StackRox, organizations need tools to tighten the feedback loop, increase automation and help prioritize which vulnerabilities to fix. “The concept of having a human in the loop every time you need to make a security judgment is just a non-starter these days,” she said. Security tools can be integrated with the CI/CD pipeline, and developers can get immediate feedback when a build has a security problem — and the build can be failed and prevented from progressing in the pipeline until the security problem is fixed, all without input from security.

Prioritization is also an important force multiplier. One of the challenges, as companies move to complex distributed microservice architectures, is that there can be a flood of alerts and potential vulnerabilities. Organizations have a limited number of security professionals and using security tools to prioritize means those professionals can focus on the most important fixes instead of getting bogged down.

“The first thing we do is that we can look at the list of vulnerabilities your scanners produce and reduce it by 50% to 80%,” explained Liran Tancman, CEO of cloud native security company Rezilion. “I think 70% of vulnerabilities are never loaded to memory or are not exploitable, so we reduce the number of vulnerabilities that developers have to fix.” 

“The concept of having a human in the loop every time you need to make a security judgement is just a non-starter these days.”

— Hillary Benson

There’s a third type of tool that’s not specific to security but is nonetheless crucial to success with DevSecOps: communication and collaboration tools. A major component of success with DevSecOps is better knowledge sharing between developers, security and operations. Tools that make that knowledge sharing possible, like Slack or Zoom, are critical to success with DevSecOps — though they are there to facilitate the underlying cultural changes DevSecOps requires.

“A tool will not cause two groups who’ve never spoken to each other to speak to each other and collaborate,” explained Rani Osnat, vice president of strategy and product marketing at cloud native application security company Aqua Security. “It won’t make organizational magic happen.”

It’s the organizational magic that’s often the trickiest for security professionals to get right. “When I was at Cisco, vendors would come in and ask ‘If I could solve an issue for you, what would it be?” remembered Rick McElroy, head of security strategy at Carbon Black. “I said, if you can solve these two issues, I’ll pay you all my money. It was paperwork and politics. Those are the two things that are always inhibitors for the security program and there’s no technical medicine for that.” 

Living in an Imperfect World

“There was a time when if there was a memory leak or something that might impact performance, we just wouldn’t let it out,” explained Tancman, of Rezilion. “One of the things that happened with DevOps is we are willing to live in an imperfect world so that we can push code faster. Security is still too often trying to get to a perfect situation instead of figuring out how we live in an imperfect world.” 

Tools can either feel like handcuffs or freedom, depending on both on the tool itself and on the organizational culture, it is part of. One hope security professionals have is that DevSecOps can help shift the perceptions of security’s role — to become more of a partner than a policeman. Ideally, the right tools can help build in the guardrails, feedback loops and redundancy so that the organization is protected even if developers don’t get things perfect. 

“How do we bring in the right guardrails that aren’t tollgates for security as part of the practice?” asked Derek Weeks, vice president at security automation company Sonatype. Developers want to write better code, and good security tools help them do so. “I think the tollgates are going away and the guardrails are replacing them.” Framing it as a way to increase code quality is a way to align incentives between developers and security. 

Who Uses the Tools?

Who are security tools for in a DevSecOps culture? “I think that the biggest change that’s happened in DevSecOps in recent years is more native DevSecOps tools are being built to serve the developer,” Weeks said. In contrast, in the past security tools were for security teams — that’s no longer the case in a DevSecOps environment. 

In the old world, security teams would run their tests on code before it went into production, using any security tools themselves. Based on the results of those tests, the team would send a list of things to fix back to the developers.

With DevSecOps, security teams are no longer the primary users of security tools. Part of the switch to DevSecOps is a change in roles for security professionals. Instead of being direct users of security tools themselves, DevSecOps often means that security professionals spend more time making security policies, configuring security tools to provide the right organizational guardrails and evaluating risk profiles.

Since developers are the primary users of security tools, it’s becoming increasingly important to make tools that fit into development workflows. “Developers want to be able to stay in their integrated development environments,” explained Chiodi. It’s important for security tools to speak the developers’ language, to integrate with IDEs and GitHub, to have native plugins that provide security feedbacks without forcing the developer to use a different workflow or leave their development environment. “This is where the cloud native security platforms and cloud native tooling can really help, because it doesn’t require developers to learn new tools or to create a new process,” Chiodi said.

Palo Alto Networks and Sonatype are sponsors of InApps.

Feature image by TheOtherKev from Pixabay.