DevSecOps puts software development and security on equal footing

Clarify roles, improve collaboration

As security and testing responsibilities shift left to developers, they take on more accountability for code quality. But developers already have a lot to do. How can they implement code checks in a practical, repeatable manner? It starts with clear communication from management and the security team to set expectations.

Adam Shostack

"Everyone feels that they are responsible [for security], but we don't have a clear delineation of responsibilities," said Adam Shostack, president of Shostack & Associates, a security consultancy in Seattle. "What do [developers] do to really ensure that their system is secure? And how does that set of things that they do match up with the set of things that a security-centered person thinks they should do?"

Software development and security teams must discuss and agree upon who owns which tasks and how they will address them. Incorporate the security team from the outset of a coding project to help developers assess third-party and open source components and libraries.

Through threat modeling, security can gather information on new vulnerabilities to inform developers' security tasks. When security engineers create a threat model, Shostack said, they put on their hacker hats to describe the kill chain of an application: how an attacker breaks into an app, persists within the app and then achieves their nefarious objectives. With threat models, security can share attacker patterns of behavior with developers, rather than dictate new developer security tasks without explanation.

"Security people should endeavor to build out this broad, deep knowledge about threats [and] countermeasures that we can supply to the DevOps teams as they're building features so that they get built the best way the first time," Shostack said.

Though, he added, developers should perform their own composition analysis to identify vulnerabilities; it helps inform them on which components to use. With composition analysis tools, developers can automate checks against vulnerability databases, such as the Common Vulnerabilities and Exposures list and National Vulnerability Database.

These exchanges create trust between software development and security staff, especially as the latter group will rely on regular coaching from the former. Coaching is especially crucial as time goes on, Shostack said, so developers prioritize unpatched vulnerabilities from sprint to sprint, rather than solely focus on in-demand features, ignore demands from the disconnected security team and let vulnerabilities pile up.

Security specialists should improve their general knowledge of programming and dev team objectives, Shostack recommended. Then, the security team can apply simple fixes that developers don't have time to tackle, with automated tests serving as a safety net.

"It can hurt a lot to walk in someone else's shoes, but it's worthwhile," he said. "You create a productive environment in which the answer is, 'Yes, let's fix that together.'"

Automate security checks, enhance visibility

Jeff Payne

In DevSecOps, software development teams automate security tests and scans early in the SDLC, which enables them to write feature code relatively unimpeded. The more effort a dev team puts in to add and remediate automated security checks, the more it will benefit the product in the long run. Vulnerabilities aren't static; they can, and will, change over time. Developers must be adaptable, but also promote defensive design and programming practices to produce high-availability apps.

"We're not going to successfully deliver secure applications until we build them to be secure," said Jeff Payne, CEO of Coveros, a consultancy based in Fairfax, Va. "From defensive design to secure coding practices to security testing at the code level, those things have to be integrated in, and we have to get developers to do them more regularly."

Developers should place highest priority on code quality. That means, first, that developers adhere to the organization's coding standards and requirements, then apply requisite scans during and after the build. Static analysis debugs code before it runs in an environment, while dynamic analysis puts the application in a runtime environment to assess issues within the context of the system. These security checks lead to hardened code, meaning opportunities for intrusion, and the blast radius of attacks, are minimized.

What do [developers] do to really ensure that their system is secure? And how does that set of things that they do match up with the set of things that a security-centered person thinks they should do?

Developers must also tackle vulnerability assessment, possibly with help from the security team. Both software development and security veterans know it's always easier, cheaper and less disruptive to find vulnerabilities before they reach production.

For complex and abstract application architectures, developers are on the hook to create visibility, Cahill said. The ESG report, published in August 2019, forecast that containers and serverless platforms will support 46% of all production applications within the next two years. Cloud-native and microservices-based apps limit access to things like APIs, so developers should collaborate with ops and security to provide secure insertion points right in the source code.

"[With serverless], because you don't have access to a network tap nor any way to install an agent, the insertion point to protect the use of serverless functions is in the source code," Cahill said. "That puts more of the onus on the developer to secure the use of serverless functions."

Developers should translate security vulnerabilities and concerns into logical tests that they can automate. You start with an abstract model of how an attacker is going to operate, translate it into some specific actions they might take and then write a test for that action, Shostack said.

Modern programming languages and frameworks, Shostack added, can reduce many vulnerabilities that exist in old code, such as buffer overflow attacks or cross-site scripting. In these scenarios, developers should make cross-language refactoring a priority.

DevSecOps tools must fit the delivery cycle

Tools help with DevSecOps adoption -- to a point.

The ESG report revealed tools can actually add to DevSecOps complexity. First, 73% of respondents said their organization uses too many specialized tools to adequately secure cloud-native apps. Second, respondents ranked "allows for automation of security controls via integration with existing DevOps tools" as the top driver of cloud-native application security controls product selection.

Developers already have a long DevOps toolchain, stretching from an integrated development environment like Microsoft Visual Studio to GitHub for version control, Jenkins for CI, and testing, task management and code review tools. Security tools should integrate into that existing DevOps workflow, not complicate developers' daily work.

"If you make the developer do manual steps, that's going to create friction," Cahill said. "DevOps tools integrate seamlessly with each other via APIs ... from delivery to integration to test [back] to delivery." It's like a conveyor belt, he said, and security can't break the conveyor belt.

When security tools integrate with the rest of the DevOps pipeline, it puts security throughout the SDLC.

"If you want developers code scanning, give them a tool that does composition analysis and static analysis vis a vis native integration with the dev tools they're already using," Cahill said.

Integration should be table stakes for vendor selection.

Start small with DevSecOps, he added. Begin with one Scrum team and one project. Work through the people, process and tool challenges, then improve upon them to establish security as code, an automatable set of security checks and processes that other teams can use. Repeatability is a path for scalability, he said, and the first Scrum team paves the way.