DevOps aims to remove silos between developers and IT operations personnel to ensure faster software delivery. But, wait a sec. Where's the Sec?
DevOps teams are going back to the drawing board to roll security into their continuous development and deployment processes. When security comes only as one final prerelease check, silos aren't truly gone. Throughout the iterative process, a number of potential security vulnerabilities can pile up, resulting in a debugging delay that is counterproductive to DevOps.
DevSecOps infuses security into the CI/CD pipeline through culture change and a focus on automated and iterative methods. A DevSecOps approach begins with the understanding that security is a shared responsibility among everyone who works on a software project. It's a methodology, ultimately, that redefines software development and security roles, processes and technology, said Doug Cahill, analyst at Enterprise Strategy Group (ESG) in Milford, Mass.
"We're constantly writing code, constantly integrating, constantly delivering," he said. "The only way we're going to be able to have security keep pace at the speed of DevOps is if, one, [if everyone makes it] their responsibility and, two, we integrate and automate it."
DevSecOps is here to stay. Cahill authored an ESG report called "Leveraging DevSecOps to Secure Cloud-native Applications," in which the analyst firm surveyed 371 IT and cybersecurity professionals. Respondents claimed a 42% rate of DevSecOps adoption, and 66% expect to be there within two years. Thus, developers must adapt to take on more security responsibilities.
Evaluate how developer roles, processes and tools change in a DevSecOps model to be ready for adoption.
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.
"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
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.
Adam ShostackPresident of Shostack & Associates
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.