As we’ve heard from government and military IT leaders and decision-makers – from Nicolas Chaillan, the Chief Software Officer for the Air Force, to Katie Arrington, Chief Information Security Officer (CISO) for the Office of the Under Secretary of Defense for Acquisition – DevSecOps is the future of application and software development in the federal government and military.
This is particularly driven by the need to expedite application development so that it can keep pace with the speed of innovation, and to ensure that applications are secure in the face of increasingly numerous and sophisticated cyber threats.
But what is DevSecOps, and how is it fundamentally different from the traditional process of designing, testing, and launching software and applications? And what do government agencies and organizations need to do to embrace DevSecOps?
GitHub Supply Chain Security Product Manager, Maya Kaczorowski, was recently asked these questions for a “Lightning Q&A” on the GitHub Blog. Here is what she had to say:
Q: What is DevSecOps?
Maya Kaczorowski: DevSecOps is a mindset shift in how DevOps teams think about security. Rather than the security team being solely responsible for the security of an application, or all security requirements being validated after code is written, DevSecOps is about making all parties who are part of the application lifecycle accountable for the security of the application.
Q: That makes sense—it’s about sharing responsibility. The name seems to suggest it’s related to DevOps. If so, what’s the difference between DevOps and DevSecOps? Do we really need another abbreviation?
Maya Kaczorowski: Well, the same mindset shift that you’ve seen in the industry with a move towards DevOps in recent years is also what’s led to the move towards DevSecOps. There’s a parallel being drawn. In DevOps, everyone becomes accountable for outages, even if you don’t manage the infrastructure. In DevSecOps, everyone becomes accountable for vulnerabilities, even if you didn’t write the software.
The reason DevOps came about was a business need for fewer outages. If everyone has the tools to help prevent outages, and everyone is accountable for them, they should occur less. It’s incredibly hard to successfully transform a business process without a clear business need. Just like the goal of DevOps is to reduce outages, the goal of DevSecOps is to reduce security issues, such as data loss.
And, if you consider the CIA triad of confidentiality, integrity, and availability, you’ll notice that DevOps efforts to reduce outages directly address availability—so it’s no surprise to see these concepts combined. It may seem like just another abbreviation or industry buzzword, but naming it “DevSecOps” is a way to bring (and keep) security into the larger conversation about how we build software.
Q: So say we wanted to put all of this into practice. What is the DevSecOps methodology? How does this relate to another phrase we hear quite often, “shifting left?”
Maya Kaczorowski: DevSecOps is a mindset shift. Unfortunately, there’s no canonical list of DevSecOps practices (and so no magic product pills to buy) but rather, it’s about making changes to security practices by better including them in the software lifecycle.
In practice, to hold teams accountable for what they develop, processes need to “shift left” to earlier in the development lifecycle, to meet them where they are. This means moving security from being a final gate at deployment time to earlier step(s), and providing feedback to developers on the security of their application earlier—in development, at build time, and at testing. Providing this feedback in context means it’s easier for development teams to address issues without losing their flow, and means that issues are addressed more quickly.
Q: If DevSecOps is a change in mindset, not a specific methodology, that means there are many ways it might be implemented. What problem is it solving then? And what benefits do developers get from moving to DevSecOps?
Maya Kaczorowski: Broadly, DevSecOps addresses the concern of security teams being overstretched to deal with application security. The scarcity of application security professionals isn’t just true for your organization—it’s industry-wide. Security teams just aren’t big enough to address every security issue, and they never will be. By spreading knowledge and tools around, developers can also help address common security issues and leave the security experts to focus where they are most needed.
There’s not a specific technologic problem that DevSecOps fully addresses, though. Yes, the goal is fewer security issues. But we also know that nothing is ever fully secure. Rather than focusing on making your application perfectly secure, DevSecOps lets you better use your resources to address your security requirements and gives you the agility to quickly react when an issue does occur. If you can fix an issue quickly, or better yet, prevent an issue from occurring at all, you’re already realizing the benefits of DevSecOps.
Q: Why is DevSecOps important?
Maya Kaczorowski: DevSecOps makes security seem special, but the reality is that every function should be tightly integrated this way, at every step in the development process. If there’s one takeaway from the increasing industry hype of DevSecOps (and to a lesser extent, the adoption of DevSecOps), it’s the recognition that what we’re doing for application security today doesn’t work, because it doesn’t scale. It’s noticing a gap in resources to sufficiently address security issues, and proposing we could instead spread some of this responsibility around in order to achieve better application security.
Q: You’ve convinced us. How do we implement DevSecOps for our teams?
Maya Kaczorowski: As I mentioned earlier, there’s no canonical, widely accepted list of DevSecOps practices. This topic hasn’t been as extensively studied as DevOps. To help development teams take action on security issues, security controls and feedback needs to “shift left” to earlier in the development lifecycle—in development, at build time, and at testing. This can be many different controls, including different controls for your own code and third-party code, and depends where you’re starting from.
Q: So, what’s the first step you should take towards DevSecOps?
Maya Kaczorowski: If you have teams using different CI/CD pipelines, one of the best moves you can make for security (really!) is consolidating multiple tools so that there’s a clear way to ship code. That makes it easier to at least know what you’re shipping to production, and what controls are already in place.
If your teams already have a common pipeline, consider moving some controls left. Any step you take towards consolidating your toolchain matters—going from a penetration test to a static analysis tool, or from a JIRA ticket filed in production to an alert surfaced in an integrated development environment (IDE). This doesn’t mean you can, or should be, fully replacing any of your downstream tools. Rather, you’re making it easier to catch and address issues sooner.
And if you’re already far along the journey and beyond all this, then consider what else would make your developers’ lives easier, and improve your security: maybe it’s automatically validating configs, or providing a patched and maintained set of libraries.
To read the “Lightning Q&A” with Maya Kaczorowski in its entirety on the GitHub Blog, click HERE.
