Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
By prioritizing secure development alongside speed, DevSecOps helps you ship safer applications by making security part of your current DevOps pipeline.
DevOps, SecOps, now DevSecOps? While the DevOps we all know brings development and operations teams together, DevSecOps adds another process even high-performing DevOps teams can miss: security.
By prioritizing secure development alongside speed, DevSecOps helps you ship safer applications by making security part of your current DevOps pipeline. It’s more than checking off security vulnerabilities or sorting through false positives. Here’s how you can build a DevSecOps culture that makes a difference—for your code and customers.
Secure applications depend on developers fixing as many vulnerabilities as possible during code review before they can make it to production. But too often, security tools serve up false positives, forcing developers to spend time trying to fix vulnerabilities that don’t actually exist. We’ve heard time and time again: high false-positive rates are the top reason why developers struggle to tackle vulnerabilities while they build.
Constantly stopping to address these security concerns, only to find a false positive, forces developers out of their workflow. Instead, taking a developer-first approach to security means meeting your team within their workflow. The goal of a successful DevSecOps culture is to identify bugs and resolve them as you build—or “fail fast,” said Shamal Siwan, Lead DevOps Engineer/Solutions Architect at the California Department of Technology. “You fix it and you move forward, because guess what? It takes you a minute to solve that security issue in development when it could potentially take you hours or days to fix in production.”
Building trust between your security and DevOps teams isn’t just about deciding when and where you solve vulnerabilities—it’s about which results you prioritize and why. All bugs matter, but some bugs matter more.
When Facebook added high-quality static analysis results to their developer workflow, the fix rate reached an unprecedented 70 percent. Yet when the bugs were presented to the developers outside of their workflow as a list of problems to fix, the fix rate was zero. Why the drastic change? This speaks back to prioritizing a workflow that’s developer-first, but the real key here is the results themselves: delivering “high-quality results,” or reporting the bugs that had the most critical impact, equaled more bugs fixed over time. Developers knew they weren’t being served a list of false positives, and quickly incorporated bug fixes into their workflow. As the number of false positives went down, the number of real bugs being fixed went up.
False-positives happen. It’s what you do with them that can make or break your DevSecOps culture. For Jon Parise, Engineering Architect at Pinterest, automation has helped bridge the gap—ensuring that the right bugs are found, but also actually fixed. “With automated security updates not only are security vulnerabilities identified, but we’re presented with a solution that enables us to quickly fix the issue,” Parise explained. And their new approach has even impacted other non-DevSecOps teams: “This workflow has been a great reminder for us to constantly audit our internal software for similar vulnerabilities.”
Still, prioritizing high-quality bugs can be easier said than done. False positives have become part of software development—with many teams finding ways to simply work around them. If you’re overwhelmed by bad vulnerability reports, the easiest answer is to shut off vulnerability reporting entirely. If you can’t trust your static analysis, why resolve vulnerabilities at all?
Effective DevSecOps requires breaking through “bad habits” in your current software culture and finding new ways of working. The easiest place to start is with the tools your development and security teams can actually trust—or in Lead Cyber Security Engineer Sydney Sweeney’s case, tools their Dow Jones developers already know how to use. “Providing a similar developer experience from local development through deployment helps prevent passwords from being pushed into the code.”
Even in DevOps, security usually comes at the end of development—the final checkmark before going to production. Communication between security and DevOps teams is either issue-driven or incident-driven, and fixing security issues at the end of your software development lifecycle only adds stress around rescheduling sprint tasks and effort.
Instead of “us versus them,” make security part of development from the start, and encourage day-to-day collaboration between both teams. This can happen in small ways, like by integrating mandatory security checks into code reviews, or in bigger ways, such as building a unified workflow for processes like application security and CI/CD that are usually siloed. At Dow Jones, incorporating security from the first step makes DevSecOps a given, not a question. “We have our security controls baked into our pipelines all the way from the first line of code you’re writing,” said Chief Information Security Officer Miguel El Lakkis.
Security is a community responsibility. From managing open source dependencies to fixing the right bugs to protecting customer data, DevSecOps brings that shared responsibility to everyone in your organization—and ensures safer software at every step.
This post was also published on LinkedIn on April 28, 2020.
