Most software security programmes cannot say, with evidence, whether they are doing more or less than comparable organisations, and BSIMM exists to answer exactly that question. The Building Security In Maturity Model (BSIMM) is an observational benchmark: it records which software security activities real organisations actually perform, rather than prescribing what they should do. BSIMM16, published in January 2026, describes 128 activities observed across 111 organisations, grouped into 4 domains and 12 practices. This guide explains how the model is structured, how activity IDs and levels work, how to run a self-assessment or a formal assessment, how to use the results without turning them into a checklist, and where machine identities and secrets fit. It is for application security leads, software security group (SSG) managers and CISOs who need a defensible picture of their programme. For the broader choice between maturity models, see the AppSec Maturity Model guide.
Key takeaways
- Descriptive, not prescriptive: every BSIMM activity is in the model because multiple organisations were observed doing it; the model says what peers do, and you decide what fits your risk.
- Four domains, twelve practices: Governance, Intelligence, SSDL Touchpoints and Deployment, each with three practices, holding 128 activities in BSIMM16.
- Levels reflect frequency: level 1 activities are the most commonly observed, level 3 the rarest; new activities enter at level 3 because they have no observation history.
- The scorecard is the output: a per-activity record of what you do, compared with how many participating firms do it, which shows where you lead or lag peers.
- Use it with a prescriptive model: BSIMM tells you where you stand; OWASP SAMM, NIST SSDF or your own roadmap tell you what to build next.
What it is and who it applies to
BSIMM is published annually by Black Duck (formerly the Synopsys Software Integrity Group). Each edition is built from assessments of participating organisations, using direct interviews, evidence gathering and peer comparison. The publisher describes it as an observational, data-driven benchmark for software security initiatives (SSIs). It is voluntary: no regulation requires BSIMM, but many organisations use it to justify investment and to show progress to boards and customers.
Core vocabulary
| Term | Meaning in BSIMM |
|---|---|
| SSI (software security initiative) | An organisation-wide programme to instil, measure, manage and evolve software security activities in a coordinated way |
| SSG (software security group) | The internal group that carries out and facilitates software security work |
| Satellite | A group of individuals, often called security champions, organised and used by the SSG |
| Activity | An observed practice, identified by practice abbreviation, level and sequence number (for example SM1.1) |
| Scorecard | A management tool that records which activities an organisation performs and compares them with the participant population |
| Iteration | First assessment, first reassessment, and later reassessments, used to compare firms by programme age |
Who uses it
- Large software producers and regulated enterprises: to benchmark a mature SSG against peers and vertical averages.
- Organisations starting an SSI: to see which level 1 activities most peers have in place, as a sanity check on a first-year plan.
- Software suppliers: to give customers a structured description of their secure development programme, alongside attestations such as the CISA Secure Software Attestation Form Guide describes.
Structure and key requirements
BSIMM has no "requirements" in the compliance sense. Its structure is a framework of domains, practices and activities.
| Domain | Practice (abbreviation) | What it covers |
|---|---|---|
| Governance | Strategy & Metrics (SM) | Publishing the secure development process, security checkpoints (gates), executive education, metrics |
| Compliance & Policy (CP) | Regulatory and privacy obligations (for example identifying PII obligations), policy, vendor contract terms | |
| Training (T) | Role-based awareness and training, increasingly just-in-time and in-tool | |
| Intelligence | Attack Models (AM) | Attacker profiles, threat intelligence relevant to the organisation's software, abuse cases |
| Security Features & Design (SFD) | Secure-by-design patterns and approved security features, such as authentication and cryptography components | |
| Standards & Requirements (SR) | Security standards, secure coding standards, open source and component policy | |
| SSDL Touchpoints | Architecture Analysis (AA) | Security feature review and design review of applications |
| Code Review (CR) | Automated and manual code review | |
| Security Testing (ST) | QA-integrated security testing, edge and boundary testing, fuzzing | |
| Deployment | Penetration Testing (PT) | External and internal penetration testing and feeding results back |
| Software Environment (SE) | Host and network basics, cloud security controls, code integrity and protection | |
| Configuration Management & Vulnerability Management (CMVM) | Incident response for software, defect tracking, vulnerability handling after release |
Activity IDs and levels
An activity ID combines the practice abbreviation, a level and a sequence number. SM1.1 is "Publish process and evolve as necessary", a level 1 activity in Strategy & Metrics. SM1.3 is "Educate executives on software security", SM1.4 "Implement security checkpoints and associated governance", and SM2.2 "Enforce security checkpoints and track exceptions" (names from the BSIMM13 Foundations report). Levels are not maturity stages you must climb in order:
| Level | What it signals | Planning implication |
|---|---|---|
| 1 | Most commonly observed, usually most straightforward | Missing level 1 activities in an established SSI deserve a written reason |
| 2 | Less common, often needs more coordination across teams | Typical second-year and third-year investments |
| 3 | Rarest and usually hardest; new activities start here | Adopt where your risk justifies it, not to raise a score |
Activities move between levels across editions as observation rates change, and activity counts change too: BSIMM12 had 122 activities, BSIMM16 has 128. Always state the edition when you quote an ID or a score.
What has changed recently
- AI-generated code: the publisher reports organisations extending governance, review and policy activities to AI-generated code and AI-enabled development, folding AI into existing SSIs rather than running separate programmes. See the AI-Generated Code Review Guide.
- Software supply chain and SBOMs: SBOM use keeps rising, particularly among suppliers to the US government, driven by self-attestation requirements.
- Training: moving from periodic classroom sessions to continuous, role-specific and just-in-time enablement in developer tools.
Identity and NHI requirements
BSIMM does not have a practice for identity or secrets. Machine identities appear inside several practices, and an SSG that ignores them will miss some of the most exploited weaknesses in modern pipelines. The mapping below is NHI Mgmt Group's interpretation of where identity controls naturally sit, not BSIMM text.
| Practice | Identity and NHI activities to record against it |
|---|---|
| Standards & Requirements (SR) | A secure coding standard that bans hard-coded credentials and names the approved secrets store and token types |
| Security Features & Design (SFD) | Approved components for service-to-service authentication, workload identity federation and key management |
| Code Review (CR) | Secret scanning in pre-commit and pull request checks, with triage SLAs; see the Git Secret Scanning Guide |
| Architecture Analysis (AA) | Design review questions on which identities a service uses, their scope and how they are rotated |
| Software Environment (SE) | Cloud security controls covering CI/CD runner identities, short-lived deployment credentials and code signing keys; see the CI/CD Pipeline Identity Security Guide |
| CMVM | A software incident runbook that includes revoking and rotating leaked keys and tokens |
| Attack Models (AM) | Attacker profiles that include credential theft from repositories and build systems |
Leaked repository and pipeline credentials are a recurring root cause in breaches, and the Credential chaining guide shows how one exposed token leads to another. Recording these controls against BSIMM practices makes them visible in the same scorecard the board already sees.
Implementation steps
- Define the SSI boundary: decide which business units, products and suppliers are in scope. A scorecard for "the company" that really reflects one product line misleads.
- Name the SSG and satellite: record who owns software security and which champions exist per team; BSIMM interviews start here.
- Collect evidence before scoring: process documents, gate records, tool configurations, training records, pen test reports, defect data. An activity is credited when there is evidence it happens, not when a policy says it should.
- Score against the current edition: mark each activity as observed or not (or partial, if you use a graduated scale internally), using the edition's activity descriptions.
- Compare with peers: use the published observation counts, and vertical data where available, to find level 1 activities most peers perform that you do not.
- Choose a small set of targets: pick activities that address your actual risk, often 5 to 10 per year. Use a prescriptive model such as the OWASP SAMM Guide or the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide to define how to implement them.
- Pilot, then roll out: trial new activities (for example a security gate) with one or two teams, measure friction, then extend. Keep an exception process so a failed rollout can be paused without abandoning the activity.
- Reassess yearly: repeated assessments track progress; record the edition each time so changes in the model are not mistaken for changes in your programme.
Small versus large organisations: a team with one or two security engineers gains most from a light self-assessment against level 1 activities and a short target list, because the full model describes programmes with dedicated SSGs and many champions. Large organisations with several business units benefit from separate scorecards per unit, a formal assessment every one or two years, and vertical comparisons, since board questions are usually about peers in the same industry.
Self-assessment or formal assessment
| Approach | Strengths | Limits | Fits |
|---|---|---|---|
| Internal self-assessment | Cheap, fast, builds understanding in the SSG | Optimistic scoring; no confidential peer data beyond the published report | Early SSIs, annual internal check |
| Formal BSIMM assessment by the publisher | Interviews and evidence review by assessors; detailed report of strengths and gaps, a box plot against peers and a scorecard table; contributes to the dataset | Cost; assessor time from your staff | Large programmes, board-level benchmarking, customer assurance |
| Independent third-party review using the public model | Outside challenge to scoring | Not an official BSIMM assessment; peer comparison limited to published data | Mid-size programmes wanting assurance |
Evidence and assessment
Good evidence is generated by the process itself. The table lists examples of what an assessor would reasonably expect.
| Practice | Example evidence |
|---|---|
| SM | Published SSDL document with change history; gate records showing pass, fail and exceptions |
| CP | Register of regulatory and privacy obligations mapped to applications; security clauses in software vendor contracts |
| T | Training completion by role; in-tool guidance usage |
| AA | Design review records with findings and decisions |
| CR and ST | Tool configurations, scan coverage by repository, defect tickets raised from findings |
| PT | Pen test reports and evidence that findings fed back into standards or tooling |
| SE and CMVM | Cloud baseline policies, code signing records, software incident tickets, time-to-fix data |
Metrics that show the SSI is working
- Coverage: percentage of in-scope applications passing through each security gate.
- Level 1 gap count: number of level 1 activities not observed, tracked across reassessments.
- Time to remediate: median days to fix critical findings from code review, testing and pen tests.
- Exception ageing: number and age of open gate exceptions.
- Secrets exposure: secrets detected per 1,000 commits and median time to revoke.
See the AppSec Programme Metrics Guide for metric design.
Mapping to other frameworks
| Framework | Relationship to BSIMM |
|---|---|
| OWASP SAMM | Prescriptive, open model with maturity levels per practice; use it to define target states where BSIMM shows gaps |
| NIST SP 800-218 (SSDF) | Outcome-based secure development practices; useful as the requirement set behind attestations |
| NIST CSF 2.0 PR.PS-06 | "Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle": BSIMM provides the monitoring evidence |
| NIST CSF 2.0 ID.IM-01 | Improvements identified from evaluations: annual BSIMM reassessment is such an evaluation |
| NIST SP 800-53 SA-3, SA-8, SA-11, SA-15 | System development life cycle, security engineering principles, developer testing, development process and tools: map to SM, SFD, ST and CR, and SR |
| NIST SP 800-53 SR-4 | Provenance: supports SBOM and component activities under SR and SE |
| NIST CSF 2.0 GV.SC-01 | Supply chain risk programme: aligns with CP vendor terms and SR component policy |
Common pitfalls
- Treating the score as the goal: adding level 3 activities to raise a count, while basic gates are routinely bypassed.
- Policy credit without practice: scoring an activity because a standard exists, with no evidence that teams follow it.
- Comparing across editions blindly: activities are added, removed and relevelled each year, so a score change may reflect the model, not your programme.
- One scorecard for many programmes: averaging business units hides the weakest one; score them separately.
- No identity coverage: leaving secrets and pipeline credentials out because no BSIMM practice is named for them, even though repository and CI/CD credentials are frequent breach entry points.
- Benchmark without a roadmap: a scorecard with no chosen targets, owners and dates changes nothing.
Practitioner checklist
- Record the BSIMM edition used for every scorecard and comparison.
- Define the SSI boundary and score business units separately where they differ.
- Name the SSG owner and list security champions per team.
- Credit activities only with evidence, kept in one evidence register.
- Review every unobserved level 1 activity and record a reason or a plan.
- Map secrets, pipeline identities and signing keys to SR, SFD, CR, SE and CMVM activities.
- Pick 5 to 10 target activities a year, with owners, and define implementation through SAMM or SSDF.
- Report coverage, remediation time and exception ageing alongside the scorecard.
- Reassess annually and explain changes caused by the model, not the programme.
Standards and references
- Black Duck: BSIMM16 Report
- Synopsys: BSIMM13 Foundations Report
- Black Duck: BSIMM Assessment Datasheet
- Black Duck: The BSIMM16 Report, what today's software security programs are really doing
- Black Duck: BSIMM Software Security Activities
- NIST: SP 800-218 Secure Software Development Framework
- OWASP: Software Assurance Maturity Model
Related NHI Mgmt Group resources: AppSec Maturity Model · OWASP SAMM Guide · NIST Secure Software Development Framework (SSDF, SP 800-218) Guide · CI/CD Security Guide