This article is based on reporting originally published by Dark Reading on the BSIMM10 report, produced by Synopsys researchers.
What Is BSIMM?
The Building Security in Maturity Model (BSIMM) is a data-driven framework built from observing real-world software security initiatives (SSIs) across dozens of organizations. Now in its tenth edition, BSIMM10 reflects findings from 122 participating firms spanning multiple industries. It is produced annually by researchers at Synopsys.
Rather than prescribing a single path, the BSIMM functions as a measuring stick. Organizations can compare their own security activities against those of peers, identify gaps, and prioritize improvements based on what real-world firms are actually doing—not just theoretical best practices.
“You can identify your own goals and objectives, then refer to the BSIMM to determine which additional activities make sense for you.”
BSIMM10 Report
The Central Finding: DevOps Is Now Driving Security Culture
A decade ago, software security was primarily a differentiator for highly regulated industries—financial services, healthcare, defense—where governance-driven SSIs were built top-down to satisfy compliance requirements. BSIMM10 marks a meaningful departure from that model.
According to Sammy Migues, information security visionary at Synopsys and one of the report’s authors, a new wave of engineering-led security culture is now the dominant force shaping how organizations build and grow their security capabilities. Two converging pressures are driving this shift:
- Friction from existing SSIs: Legacy software security processes create unpredictable effects on delivery schedules, tense cross-team relationships, and heavy human-intensive workflows that slow development down.
- Demands of modern delivery models: Agile and DevOps practices place a premium on speed, automation, and continuous delivery—values that are often in direct conflict with traditional, gate-based security reviews.
The result is that engineering teams have begun building their own security capabilities rather than waiting on a central security group. Decisions that once required multi-person review meetings are now being automated. As Migues notes, “Anything that represents friction or opaqueness is sort of getting pushed aside. If security is too slow for the dev team, the dev team is going to do its own security.”
What This Means for Security Groups
BSIMM10 documents the rise of an organizational pattern in which security efforts originate organically within engineering teams rather than from a dedicated, centralized security group. Engineers take on role-specific security responsibilities—sometimes labeled informally as BuildSec, ContainerSec, or DeploymentSec—focusing on specific capabilities such as operations security or incident response before any formal security division is established.
This activity often happens outside the visibility of the central security department. Engineers are effectively assembling their own SSI piece by piece, handling tasks historically owned by dedicated security teams.
The implication for traditional security teams is stark. Security has long operated as a post-development gate: test the software once it is complete, then decide whether it is production-ready. In a DevOps context, that model is becoming obsolete. Security teams must become embedded in the application value stream—the continuous flow of development, testing, and delivery—or risk being bypassed entirely.
“If you’re not part of the value stream, you’re going to be ignored. You aren’t going to solve tomorrow’s security problems by hiring more security people.”
Sammy Migues, Synopsys
Three New Activities Added to BSIMM10
To reflect how firms are adapting security to the pace of modern software delivery, researchers added three new activities to BSIMM10:
- Software-defined life cycle governance — Managing security policy and controls through code and automation rather than manual process gates.
- Software-assisted monitoring of software-defined asset creation — Using automated tooling to monitor how infrastructure and application assets are created and configured in real time.
- Automated verification of software-defined infrastructure — Continuously verifying that infrastructure-as-code meets security requirements without requiring manual review of every change.
These additions reflect a broader industry shift: security controls are increasingly expressed and enforced as code, mirroring the infrastructure-as-code and policy-as-code patterns already common in DevOps engineering. Migues describes them as “direct offshoots of this new engineering-driven culture that’s sort of dragging security behind it.”
Organizational Complexity Determines the Difficulty
How hard it is to integrate security into a DevOps culture depends heavily on the complexity and homogeneity of an organization’s software portfolio. BSIMM10 makes a clear distinction here:
Homogeneous Environments
Organizations that have built their engineering culture around a relatively uniform technology stack have an easier time embedding security. Migues uses Netflix as an illustrative example: a company centered on a single core application and a unified development culture can shift security practices more effectively because everyone is working in the same context. Culture change in that environment is challenging but tractable.
Heterogeneous Environments
Large enterprises—a Fortune 500 bank, for instance—may maintain thousands of applications built on dozens of different technology stacks, managed by multiple independent development teams. A security practice that works well for one application may take years to propagate across the entire organization. Standardizing on a single approach is difficult when the underlying systems have little in common.
Smaller organizations often benefit from fewer heterogeneous environments by default. Fewer tech stacks mean security tooling and practices can be standardized more quickly, giving smaller teams an unexpected structural advantage over large enterprises.
Key Takeaways for DevOps and Security Teams
- Security must integrate into the value stream. Post-development security reviews are incompatible with continuous delivery pipelines. Security needs to shift left—and stay embedded throughout.
- Automation is not optional. Engineering-led security culture prioritizes automation. Security tooling that cannot integrate into CI/CD pipelines will be worked around.
- Central security groups must adapt their role. The SSG’s value increasingly comes from enabling engineering teams—providing guardrails, tooling, and expertise—rather than acting as a gate at the end of the pipeline.
- Hiring more security headcount is not the solution. The bottleneck is cultural and architectural, not a simple shortage of security personnel.
- Portfolio complexity is a real constraint. Organizations should assess their software portfolio’s homogeneity before benchmarking their progress against firms with very different environments.
The BSIMM10 report is available from Synopsys. Organizations looking to benchmark their own software security maturity can use it to identify which activities are common across the industry and which are performed only by the most advanced programs.