This article is based on reporting originally published at TechBeacon, drawing on findings from BSIMM 10, a 92-page report published by Synopsys in 2019.
What Is BSIMM?
Synopsys launched the Building Security in Maturity Model—commonly abbreviated as BSIMM—in 2008 as a data-driven measuring stick for software security programs. Rather than prescribing how security should be done, BSIMM observes and catalogues what real organizations actually do, then presents those findings as a benchmark that other teams can use to assess and improve their own programs.
By the time BSIMM 10 was published in 2019, the project had grown to include 122 participating companies across eight verticals: cloud, Internet of Things, independent software vendors, high technology, healthcare, insurance, financial services, and retail. Among the participants were Aetna, Bank of America, Cisco, Fidelity, Johnson & Johnson, PayPal, and Verizon.
The Central Finding: DevOps Is Changing Security at Scale
The headline conclusion of BSIMM 10 is that DevOps adoption has reached a tipping point—one that is visibly reshaping how the software industry handles security. As the report’s authors Sammy Migues, John Steven, and Mike Ware wrote:
“The BSIMM data show DevOps adoption is now far enough along to affect the way we approach software security as an industry.”
Jim Routh, then head of enterprise information risk management at MassMutual, put it in operational terms:
“The current BSIMM data reflect how many organizations are adapting their approaches to address the new dynamics of modern development and deployment practices, such as shorter release cycles, increased use of automation, and software-defined infrastructure.”
BSIMM 10 catalogues 119 activities any organization can implement to improve software security. Three new activities were added in this edition specifically to reflect the impact of DevSecOps, and several activities from earlier editions were updated to reflect how modern DevOps teams are implementing them in practice.
Opening the Floodgates: Speed Forces Security Automation
The most direct way DevOps changes security is through velocity. Traditional waterfall development gave security practitioners the ability to insert mandatory gates at defined stages of the software development lifecycle—checkpoints that could not be passed until specific requirements were met. Continuous delivery pipelines have largely eliminated the window of time those gates depended on.
Caroline Wong, vice president of security strategy at Cobalt Labs, described the shift clearly: “In DevOps, everything is happening much faster.” The consequence, she explained, is a heavy pivot toward automation:
“So what’s happening is there’s a lot more focus on automation. As software is being developed, security controls are automatically being included at the same time.”
—Caroline Wong, Cobalt Labs
Matt Trevors, technical manager at the CERT Division of the Software Engineering Institute at Carnegie Mellon University, reinforced this view: “I’m not surprised BSIMM found the tangible connection between DevOps and security, because with old-style waterfall, you could have an 18-month project and not find out you have an issue until month 16.” In a DevOps model, the feedback loop is dramatically shorter, surfacing problems earlier when they are cheaper to fix.
DevOps is also influencing security at the infrastructure layer. Dan Hubbard, CEO of Lacework, noted a concrete example: “We see automation of items like vulnerability scanning on containers in build and runtime.” Container security—scanning images in CI pipelines and enforcing policies at runtime—is one of the clearest areas where DevOps tooling and security tooling have converged.
Engineer-Led Security Culture: Bottom-Up Pressure
A second significant finding in BSIMM 10 is the emergence of an engineer-led approach to security. Development teams are increasingly unwilling to accept the friction of top-down, governance-heavy security programs, and are instead building security into their own workflows.
Sammy Migues, principal scientist at Synopsys and one of the report’s authors, described what this looks like in practice:
“We are now seeing bottom-up changes that are forcing executive-level governance programs to change the way organizations do security. Almost every way they did business before has had to go through its own digital transformation to catch up with what DevOps is doing in the name of resilience and automation.”
Engineering-led security teams tend to exhibit a recognizable set of behaviors:
- Selecting and integrating their own security tools directly into the development workflow rather than relying on a separate security team to run assessments.
- Provisioning cloud infrastructure and virtual assets on demand, without waiting for centralized operations approval.
- Adhering to formal policy on approved open-source software, while simultaneously pulling in dozens or hundreds of additional open-source packages to build and operate systems and processes.
These teams do not abandon security governance—they reimplement it. The report describes this as a preference for “governance as code”: encoding security standards directly into automated pipelines rather than maintaining them as manual review steps in a separate risk workflow. As BSIMM 10 explains:
“This tends to result in engineers building security features and frameworks into architectures, automating defect discovery techniques within a software delivery pipeline, and treating security defects like any other defect.”
The gates and risk decisions that previously lived in separate governance workflows are not eliminated—they are modeled into software-defined workflows. The goals, however, often differ from those of traditional governance-driven groups: engineering-led teams tend to prioritize speed of feedback, automation coverage, and defect resolution rates over point-in-time compliance audits.
The Limits of “Shift Left”: Tools Built for Experts
Despite genuine progress, the BSIMM 10 data make clear that engineer-led security culture still has significant ground to cover. Jeff Williams, CTO and co-founder of Contrast Security, identified a critical failure mode in how the industry has pursued the “shift left” concept:
“A lot of people take ‘shift left’ to mean we should take the legacy tools that are used for security and push them to developers so they can do their own security. The problem is those tools were built for experts. Developers don’t have the skills to run those tools.”
—Jeff Williams, Contrast Security
The practical consequence, Williams added, is that developers will largely ignore or disable complex security tools when given the opportunity to do so. Shifting tooling left without investing in developer security education, tool usability, and workflow integration is unlikely to produce meaningful security improvements.
This is consistent with the broader message of BSIMM: improving software security almost always means changing how organizations work, and organizational change takes time. BSIMM describes itself as a “maturity model” precisely because meaningful progress requires sustained effort across people, process, and technology—not just the adoption of a new scanning tool.
Scale: The Professionals and Applications Behind the Data
The scope of BSIMM 10 gives the findings credibility that single-organization case studies cannot. The 119 activities documented in the report reflect the collective experience of approximately 7,900 software security professionals guiding the security efforts of nearly 470,000 developers working on more than 173,000 applications across 122 companies.
Carnegie Mellon’s Matt Trevors noted that the initiatives, domains, practices, and activities in BSIMM map broadly to those in the CERT Resiliency Management Model, lending the framework additional credibility:
“Any effort to do a data-driven model that shows companies how to build software with security in mind is A-plus in my book.”
—Matt Trevors, Carnegie Mellon CERT Division
Key Takeaways for DevOps and DevSecOps Teams
- Automate security controls in the pipeline. Manual security gates cannot keep pace with continuous delivery. Integrate SAST, DAST, dependency scanning, and container image scanning directly into CI/CD pipelines.
- Treat security defects like software defects. Tracking, prioritizing, and resolving security findings through the same workflow as functional bugs reduces the friction of remediation and keeps security visible to engineering teams.
- Implement governance as code. Encode compliance and security policy into automated checks rather than relying on separate manual review processes that operate outside the engineering workflow.
- Invest in developer-friendly tooling. Shifting security left is only effective if the tools developers are given are usable without deep security expertise. Noisy, expert-oriented tools will be ignored.
- Expect cultural change to take time. BSIMM’s maturity model framing is a reminder that sustainable security improvement is an organizational journey, not a one-time tool deployment.
The BSIMM framework and its annual reports are publicly available from Synopsys and remain one of the most data-grounded resources available to teams building or benchmarking a software security program.