Lightning Q&A: DevSecOps in five with Maya Kaczorowski

Last month, GitHub Supply Chain Security Product Manager Maya Kaczorowski explained what DevSecOps is and security best practices for development teams. We had some follow up questions, so we asked her back for a lightning Q&A—a quick deep dive on why DevSecOps matters for developers, and how to apply it to the developer workflow. 

First things first: we’ve heard the term DevSecOps before, and thanks to your post, we have a better idea of what it means. But we can all benefit from learning more on this. What is DevSecOps again?

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 security of the application.

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? 

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.

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?”

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.

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?

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.

Why is DevSecOps important?

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 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.

You’ve convinced us. How do we implement DevSecOps for our teams?

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.So, what’s the first step you should take towards DevSecOps?

• 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.

Thanks so much for your insight on DevSecOps. Sounds like we’ve got some work to do. Any resources you can share to help teams get started? 

Sure, here are a few of my favorites:

• How to 10x Your Company’s Security, Without a Series D talk by Clint Gibler from BSidesSF 2020
• DevSecCon community and resources, including past talks
• Awesome DevSecOps roundup from DevSecOps.org
• Building Secure and Reliable Systems book from Google

Looking for more easy ways to keep your code secure? Stay tuned for upcoming posts in this series or check out Maya’s recent GitHub Talk, Shipping fast with a secure software supply chain.