The BSIMM16 report: What today’s software security programs are really doing—and why it matters

Why BSIMM matters

Unlike checklists, frameworks, or maturity models built by committee, BSIMM is grounded in measured reality. Every activity in the model exists because multiple organizations perform it as part of their software security program.

That distinction is critical. Improving software security almost always requires changing how an organization operates—something that happens incrementally, not overnight. BSIMM provides a common vocabulary and measuring stick that allows organizations to

• Benchmark software security initiative against peers
• Identify strengths, gaps, and improvement opportunities
• Track progress over time using repeatable measurement
• Build a defensible roadmap grounded in what works in practice

Key trends observed in the BSIMM16 report

As with prior releases, the BSIMM16 report highlights several notable shifts in how organizations are securing software today.

AI is changing the shape of software security programs

AI-assisted development and large language models are no longer edge cases—they are becoming part of everyday development workflows. The BSIMM16 report shows organizations beginning to adapt their security programs accordingly, expanding governance, review, and policy activities to account for AI-generated code and new classes of risk.

Rather than treating AI as something entirely separate, leading organizations are folding it into existing software security initiatives—applying familiar controls such as secure design review, policy enforcement, and risk assessment to AI-enabled development.

Building SBOMs to comply with U.S. government regulations remains a top priority

The BSIMM16 report shows a continued increase in the use of Software Bills of Materials (SBOMs), especially in organizations that provide software to the U.S. government. What began as a response to regulatory pressure and high-profile supply chain incidents is now becoming a standard practice within more mature SSIs. Leading organizations are integrating SBOM generation and consumption into their development and deployment pipelines, using them not only for compliance, but as a practical mechanism for understanding dependencies, assessing third-party risk, and responding more quickly to newly disclosed vulnerabilities.

Software security training is evolving

Software security training is evolving from periodic, classroom-style instruction to continuous, role-specific enablement embedded in daily development work. The BSIMM16 report shows that higher-maturity organizations are moving away from one-size-fits-all training in favor of targeted guidance delivered at the point of need, through secure design patterns, developer playbooks, and just-in-time education integrated into tools and workflows. Security knowledge is operationalized across the SDLC, reducing friction for developers while improving real-world security outcomes.