Black Duck published its sixteenth annual Building Security In Maturity Model report — BSIMM16 — on February 4, 2026, and the headline number is stark: for the first time in the study's 16-year history, AI has overtaken every other force reshaping how organizations run their software security initiatives. The report is built from real assessment data, not survey opinions: 111 organizations across financial services, healthcare, technology, and independent software vendors, covering roughly 91,200 applications and 223,700 developers. It measures 128 observed activities across 12 practices in four domains — Governance, Intelligence, SSDL Touchpoints, and Deployment. Notably, BSIMM16 introduced zero structural changes to that framework, the first time that's happened in the model's history. For security leaders trying to figure out where their program stands and where the industry is heading on AI risk, SBOM mandates, and regulatory pressure, BSIMM16 is the most current data point available — but it also reveals exactly where a point-in-time maturity survey stops being enough.
What is BSIMM16 and what does it actually measure?
BSIMM16 is a descriptive benchmark, not a prescriptive standard — it documents what security activities real organizations are doing, then lets a company compare itself against that dataset. Black Duck (formerly Synopsys Software Integrity Group, spun out in 2022 and acquired by Clearlake Capital and Francisco Partners) conducts structured interviews with each participating firm and scores them against 128 activities spread across 12 practices: strategy and metrics, compliance and policy, training, attack models, security features and design, standards and requirements, architecture analysis, code review, security testing, penetration testing, software environment, and configuration management and vulnerability management. The output is a maturity score and percentile ranking rather than a pass/fail grade. That distinction matters — BSIMM tells you how your peers behave, not whether your actual codebase or supply chain is currently exposed. A firm can score in the 90th percentile on paper-based governance activities while still shipping unverified, unsigned dependencies into production.
What are the biggest findings in the BSIMM16 report?
The biggest finding is that AI adoption has become the single largest driver of change in application security programs, ahead of regulation, breach response, or DevOps velocity — a first in 16 years of data collection. Three specific shifts back that up: a 10% rise in teams using attack intelligence to track emerging AI-specific vulnerabilities, a 12% increase in organizations applying risk-ranking methods to decide where LLM-generated code is safe to deploy, and a 10% uptick in teams writing custom rules into automated code review tools specifically to catch issues unique to AI-generated code. Separately, SBOM production is up nearly 30% year over year, driven largely by vendors selling into the U.S. government and by lingering aftershocks from high-profile supply chain incidents. Taken together, the data shows security teams retrofitting existing controls — secure design review, policy enforcement, risk assessment — onto a development process that now includes machine-generated code at scale.
How is AI actually reshaping software security programs, according to the data?
It's reshaping them by forcing existing governance and review activities to expand their scope rather than by introducing entirely new categories of control. BSIMM16 found organizations are not building parallel "AI security" programs from scratch; they're bolting AI-aware checks onto the same 12 practices that already existed — for example, extending code review practices with custom static analysis rules for LLM-generated patterns, or extending architecture analysis to flag where AI-assisted code touches sensitive data flows. The report frames this as a maturity signal: mature programs absorb new risk categories into existing muscle memory instead of creating siloed initiatives. But the report is explicit that these are self-reported activity counts gathered through interviews conducted over the assessment period leading up to the report — it captures whether a control exists, not whether it caught anything. A team can report "risk-ranking for LLM-generated code" as an active practice without that practice having flagged a single unsafe merge in the preceding quarter.
Why is SBOM adoption surging, and is producing one enough?
SBOM adoption is surging because regulatory and procurement pressure has made it close to mandatory, but producing an SBOM is not the same as acting on what it reveals. The nearly 30% year-over-year increase BSIMM16 documents is concentrated among software vendors selling to federal agencies, where SBOM delivery has moved from "nice to have" from Executive Order 14028 discussions in 2021 to a standard contractual line item by 2026. The gap BSIMM16 doesn't close is what happens after the SBOM is generated: an inventory of components is only useful if it's continuously checked against new CVEs, license changes, and malicious package disclosures as they happen — not re-verified at the next annual assessment cycle. A static SBOM produced once and filed away answers "what did we ship" for a single point in time; it does nothing for the dependency that gets compromised eight months later.
What are BSIMM16's limitations as a benchmark for real security posture?
BSIMM16's core limitation is that it's an annual, interview-based snapshot of activities, not a continuous, evidence-based measurement of actual supply chain risk. Because assessments are conducted through structured conversations with security teams, the resulting maturity score reflects documented process and stated intent — training programs run, review gates defined, policies written — rather than live telemetry from build pipelines, package registries, or runtime environments. This is by design; BSIMM has never claimed to be a scanning tool. But it means two organizations can post identical BSIMM scores while one has automated, continuously enforced dependency and provenance checks on every commit and the other has a well-documented policy that's reviewed once a year. The 12-month cadence between assessments also means a firm's reported maturity can be stale the moment a new attack technique, a new AI coding assistant, or a new open-source vulnerability disclosure changes the threat model — which, given BSIMM16's own finding that AI is now the fastest-moving variable in the equation, is an increasingly common scenario.
How Safeguard Helps
Safeguard exists to close exactly the gap BSIMM16 surfaces: the space between a documented, annually-assessed security process and continuously verified supply chain reality. Where a BSIMM assessment tells you that your organization performs code review and produces SBOMs as documented activities, Safeguard verifies, on every build and every dependency update, that those controls are actually holding — cryptographically attested provenance for build artifacts, continuous scanning of the software bill of materials against live vulnerability and malicious-package feeds, and automated policy enforcement that blocks unverified or unsigned components before they reach production rather than flagging them in next year's assessment.
Concretely, that means teams already investing in BSIMM-style governance and SSDL touchpoints get a runtime layer underneath them: Safeguard ingests the SBOMs organizations are now producing 30% more often (per BSIMM16) and turns them into living risk data, re-checked continuously rather than filed away after generation. For the AI-driven shifts BSIMM16 documents — risk-ranking LLM-generated code, custom review rules for AI-authored patterns — Safeguard extends the same provenance and attestation model to AI-assisted commits, so "this code was flagged as AI-generated" becomes a verifiable, enforced signal in the pipeline rather than a manually maintained tag.
The practical outcome for security and platform teams: you can still run a BSIMM assessment to benchmark program maturity against peers, but you don't have to wait twelve months to find out whether a control degraded. Safeguard gives you the continuous, evidence-based half of the picture that a once-a-year interview-based model was never built to provide — so your supply chain security posture reflects what's true in your pipeline today, not what was true when the assessors last called.