BSIMM
a benchmark view of the Building Security In Maturity Model
BSIMM (Building Security In Maturity Model) is the long-running descriptive study of the activities that software security programmes actually run across a pool of participating organisations. Run BSIMM measurement cycles as structured records: catalogue the activities, capture the evidence per activity, score per-practice prevalence, compare against the study average, plan activity additions, and re-measure on annual cadence so the comparative position is a record rather than a one-off slide.
No credit card required. Free plan available forever.
BSIMM: a descriptive measurement of what software security programmes actually do
BSIMM (Building Security In Maturity Model) is the long-running descriptive study of the activities that software security programmes actually run in the wild. It is published by Black Duck (formerly Synopsys), refreshed annually based on a pool of participating organisations, and organised into twelve practices across four domains: Governance, Intelligence, SSDL Touchpoints, and Deployment. Where OWASP SAMM says what a software security programme should do at each maturity level, BSIMM reports what the programmes inside the study population observably do. The two are complementary rather than competing: SAMM is the prescriptive model the roadmap is built against; BSIMM is the descriptive benchmark the roadmap is measured against.
BSIMM is most useful when an organisation needs to talk about software security in comparative terms rather than absolute ones. A statement like “our programme is mature” is unfalsifiable. A statement like “we run forty-eight of the activities in the BSIMM catalogue, twelve more than the study average, and we are below average on Intelligence (Attack Models) where we plan to add three activities this cycle” is operational. The OWASP framework reference covers the headline risk taxonomy that an AppSec programme defends against; BSIMM measures the programme that does the defending.
The four BSIMM domains and the twelve security practices
BSIMM organises its observations into four domains, each containing three security practices, for a total of twelve practices. Each practice carries a catalogue of activities and a per-activity prevalence score across the study population. The domains are the unit of leadership communication; the practices are the unit of programme planning; the activities are the unit of measurement.
Governance
Practices: Strategy and Metrics, Compliance and Policy, Training
The strategic layer of the software security initiative. Governance covers the published strategy, the way the programme reports progress, the policy and regulatory commitments it answers to, and the training pipeline that equips engineering with the knowledge to deliver secure software. Governance activities tend to be the most visible to leadership, which is why low-prevalence Governance scores read as a programme that is operating without a mandate.
Intelligence
Practices: Attack Models, Security Features and Design, Standards and Requirements
The corporate-knowledge layer. Intelligence covers the attack patterns the programme expects to defend against, the secure design patterns and security features the engineering organisation reuses, and the standards and requirements that turn the attack model into a procurable specification. Intelligence activities are how a programme stops reinventing the same security review on every new system and how new teams inherit the work the programme has already done.
SSDL Touchpoints
Practices: Architecture Analysis, Code Review, Security Testing
The activities that touch the secure software development lifecycle inside engineering. SSDL Touchpoints covers the architecture analysis the programme runs on new and changed systems, the code review the programme runs on changes that matter, and the security testing layer that exercises the live system. These are the activities engineers see most directly and the ones where the programme either earns operational credibility or loses it.
Deployment
Practices: Penetration Testing, Software Environment, Configuration Management and Vulnerability Management
The activities that close the loop after release. Deployment covers the external penetration testing that exercises the released system, the operational software environment hardening that protects it in production, and the configuration management and vulnerability management workflows that turn discovered findings into closed records. Deployment activities are how a programme demonstrates that secure delivery survives contact with production.
For programmes that run authenticated DAST, SAST, and SCA as part of the SSDL Touchpoints (Security Testing) and Deployment (Vulnerability Management) practices, the authenticated scanning and code scanning features run those tests against the same engagement record that carries the BSIMM scorecard, so the activity-observed claim is backed by live scan output rather than a screenshot of a dashboard.
Activity prevalence: the measurement that makes BSIMM useful
BSIMM is descriptive because the question it answers is not “what should we do” but “what do programmes in the study population actually do”. The activity catalogue inside each practice is observable: a programme either runs the activity (with evidence to back the observation) or does not. The prevalence score per activity is the share of the study population that runs it. The headline BSIMM scorecard reports a per-practice activity count compared to the study-average count, the industry-vertical average count, and the highest count observed in the population, so the programme sees not only its absolute score but its comparative position.
- Activities are the unit of measurement; each activity in the BSIMM catalogue is recorded as observed or not observed per participating organisation, with evidence captured at the activity level rather than the practice level
- Practices roll up activities; the headline number reported per practice is an activity count, not a single maturity score, which is why BSIMM scorecards show a count distribution rather than a stacked bar of levels
- Domains roll up practices; the four domains (Governance, Intelligence, SSDL Touchpoints, Deployment) are how BSIMM communicates the shape of the initiative to leadership, with activity counts aggregated per domain
- Comparative position is the deliverable; the BSIMM scorecard is most useful when read against the study average, the industry vertical average, and the population-best, because the prevalence dimension is what BSIMM exists to surface
- Evidence per activity is what survives turnover; each observation should be backed by an artefact (training record, threat model, code review record, scanner output, deployment evidence) on a durable record rather than a screenshot of a slide
- Re-measurement on cadence is how the programme tracks progress; BSIMM is most useful when re-run annually so the activity count, the prevalence position, and the per-domain trajectory are recorded on a comparable basis from cycle to cycle
For deeper context on the findings discipline that backs the SSDL Touchpoints (Code Review, Security Testing) and Deployment (Vulnerability Management) activities, see the findings management workflow and the security findings deduplication guide, which together cover the data hygiene that turns scanner output into defensible activity-observed evidence at BSIMM measurement time.
How BSIMM compares to OWASP SAMM, NIST SSDF, and ISO 27001
BSIMM is rarely used in isolation. It is the comparative measurement layer that other frameworks depend on for context, or that pair with prescriptive models for a different audience. The contrast below is a working view, not a buyer comparison: the practitioner question is which frameworks to pair BSIMM with, not which to pick instead of it.
Descriptive vs prescriptive
BSIMM is descriptive: it reports the activities that participating organisations actually run, with a prevalence score per activity per practice. OWASP SAMM is prescriptive: it states what an organisation should do at Level 1, Level 2, and Level 3 in each practice. BSIMM tells you what your peers do; SAMM tells you what the model considers good. Most mature programmes pair the two: SAMM as the internal target operating model, BSIMM as the benchmark used to position the programme against a study population when buyers, regulators, or boards ask how the programme compares.
Twelve practices vs fifteen practices
BSIMM organises its observations into twelve practices across four domains (Governance, Intelligence, SSDL Touchpoints, Deployment). OWASP SAMM organises its model into fifteen security practices across five business functions (Governance, Design, Implementation, Verification, Operations). The taxonomies overlap heavily (training, threat modelling, architecture analysis, code review, security testing, defect management, and incident response appear in both) and the SAMM practice list can be read as a re-cut of the BSIMM practice list with the maturity-level dimension added.
Activity prevalence vs maturity level
BSIMM scores at the activity level: each of the activities catalogued in the data pool either is observed at the participating organisation or is not. The headline output is a per-practice activity count compared to the study average. SAMM scores at the practice level: each practice carries a Level 1, Level 2, or Level 3 score with an activity-stream split. A programme can use BSIMM activities as the input evidence for a SAMM maturity score, which is a common operating pattern when both frameworks are in scope.
Annual study vs vendor-neutral model
BSIMM is published by Black Duck (formerly Synopsys) and is updated annually based on the latest pool of participating organisations. OWASP SAMM is published by OWASP under a Creative Commons licence and is updated on the OWASP cadence. Programmes that want the benchmark dimension typically run BSIMM as the annual measurement and SAMM as the maturity model the roadmap is built against; the two are complementary because the question "what do peers do" and the question "what should we do" both deserve a structured answer.
Programmes that already operate under a prescriptive secure-development standard typically pair BSIMM with NIST SSDF (SP 800-218) as the regulator-facing practice list, with OWASP DSOMM as the pipeline-and-runtime maturity model where the build, deployment, hardening, and visibility planes are scored on their own four-level scale, with ISO 27001 Annex A.5 (organisational) and A.8 (technological) where the ISMS covers software development, and with SOC 2 Common Criteria where SaaS audit evidence is needed. The measurement is the comparative layer; the prescriptive standards are the policy layer; the audit frameworks are the evidence layer; and the same engagement record can carry all four.
BSIMM by role: how AppSec, security engineering, CISOs, and consultancies use it
BSIMM reads differently depending on which side of the programme you sit on. The comparative dimension makes it leadership-friendly; the activity catalogue makes it practitioner-friendly; the annual cadence makes it programme-friendly.
AppSec teams running BSIMM as the annual benchmark
AppSec teams use BSIMM to position the programme against the study population. The annual cycle is structured: catalogue the activities the programme runs, capture the evidence per activity, compare the activity count per practice against the study average, name the practices where the programme is materially behind the population, and plan the activity additions for the next cycle. The work product is a comparative-position document that leadership can read alongside the operational roadmap.
Security engineering teams using BSIMM as input to SAMM scoring
Security engineering teams that run SAMM as the internal maturity model use BSIMM as the input data layer. The BSIMM activity catalogue is observed once; the observations feed SAMM practice-level scoring (typically lifting a practice from Level 1 to Level 2 when an additional activity is added) and the roadmap is expressed in BSIMM activity terms because activities are easier to plan and budget against than abstract maturity levels.
CISOs and security program managers reporting to the board
CISOs and security program managers use BSIMM to give the board a comparative position rather than an abstract maturity claim. The reported number is the activity count per domain, the activity count per practice, and the comparative position against the study average or the vertical average. The cadence is annual, with quarterly progress checks on the activity additions the programme committed to in the cycle plan.
Security consultancies running BSIMM-style assessments for clients
Security consultancies that run BSIMM-style assessments for clients capture the activity-by-activity observations, the per-activity evidence, the comparative position against the relevant industry vertical, and the recommended activity additions in a single engagement record. The client portal exposes the same record to the buyer, so the assessment is a live document rather than a frozen PDF.
The persona-specific entry points are SecPortal for application security program leads (the canonical owner of an annual BSIMM measurement cycle and the per-application verification level mapping that sits underneath it), SecPortal for AppSec teams, SecPortal for security engineering teams, SecPortal for CISOs, and SecPortal for security program managers. Each anchors a different view of the same BSIMM measurement record.
The annual cycle: scope, observe, score, compare, plan, re-measure
A BSIMM measurement is most useful when it is run as a structured annual cycle rather than a one-time engagement. The cycle has six steps: scope the practices the programme is in scope for, observe the activities the programme runs (with evidence per observation), score the activity count per practice, compare against the study-average and vertical-average positions, plan the activity additions for the next cycle, and re-measure the following year on a comparable basis. The deliverable is not the scorecard; the deliverable is the comparative position and the activity additions the programme commits to.
For translating activity-additions into structured remediation work that supports the Deployment (Vulnerability Management) and SSDL Touchpoints (Security Testing) practices, see the remediation tracking workflow, the vulnerability finding state lifecycle, and the vulnerability prioritisation framework, which together cover the closure mechanics that distinguish an Intelligence-only programme from one with mature Deployment practices.
Where SecPortal fits in a BSIMM measurement cycle
SecPortal is the operating layer for a BSIMM measurement cycle. The platform holds the scope, the per-activity evidence, the per-practice activity count, the comparative-position note, the next-cycle activity additions, and the re-measurement record on one engagement, so the measurement is a live record rather than a long email thread with attached spreadsheets. For consultancies running BSIMM-style assessments on behalf of multiple clients, the security consulting workspace bundles the measurement record with branded client portals, so each client sees their own live activity catalogue and comparative position rather than a frozen PDF.
- Engagement management captures the BSIMM measurement cycle as a structured record covering the in-scope practices, the activity catalogue, the per-activity evidence, the comparative position against the study average, and the target activity set for the next cycle, so the measurement reads as a record rather than a slide deck
- Findings management stores the evidence that backs SSDL Touchpoints (Code Review and Security Testing) and Deployment (Configuration Management and Vulnerability Management) activities, with each finding carrying a CVSS 3.1 vector, a typed status across the FindingStatus enum (open, in_progress, resolved, verified, reopened, closed, false_positive), an owner-of-record, and the evidence that backs the practice activity count
- Code scanning runs SAST and SCA against connected GitHub, GitLab, and Bitbucket repositories under the OAuth connection, attaching findings to the engagement record so SSDL Touchpoints (Code Review) and Deployment (Vulnerability Management) activities score on live pipeline output rather than self-reported coverage
- Authenticated scanning runs DAST behind the login screen against the same engagement record, with credentials stored encrypted at rest, supporting SSDL Touchpoints (Security Testing) and Deployment (Penetration Testing) activities on a recurring schedule rather than a single annual exercise
- AI-assisted reports compose the BSIMM measurement summary, the per-domain analysis, and the comparative-position narrative from the underlying engagement record and findings, so the deliverable cites observed activities and evidence rather than starting from a blank template
- Compliance tracking lets one BSIMM measurement feed framework mappings to ISO 27001 Annex A.5 (Governance) and A.8 (Technological), SOC 2 Common Criteria (CC1, CC3, CC7, CC8, CC9), PCI DSS Requirement 6 (Secure Development), and NIST SSDF practices PO, PS, PW, and RV, so the measurement doubles as audit evidence without rebuilding the bundle per auditor
- Document management holds the BSIMM activity catalogue, the per-activity evidence references, the training records, the threat models, the code review records, the deployment artefacts, and the comparative-position note, so the measurement is reproducible at the next annual cycle and defensible under audit
- Activity log records the actor, the entity, the action, and the timestamp for every measurement event, with 30, 90, and 365-day retention windows and CSV export, so the audit trail behind the BSIMM scorecard is portable across audit cycles and personnel transitions
Looking for the engagement workflow that supports the measurement record itself? The penetration testing use case and the DevSecOps scanning use case capture how SecPortal turns Deployment (Penetration Testing) and SSDL Touchpoints (Security Testing) evidence into structured records covering scope, scanner output, findings, retests, and the deliverable.
For programme-level context on how maturity measurements fit into the wider security delivery operating model, see the security workflow orchestration research, the vulnerability management programme maturity model, and the enterprise security program maturity guide, which together cover the operating-model thinking that turns a BSIMM measurement into a sustained programme rather than an annual exercise that ends with the slide deck.
Key control areas
SecPortal helps you track and manage compliance across these domains.
Governance: Strategy and Metrics, Compliance and Policy, Training
The Governance domain covers the strategic layer of the software security initiative. Strategy and Metrics defines the published strategy and the way the programme reports progress. Compliance and Policy aligns the programme to internal policy and external regulation. Training equips engineering and security with the role-aware education that makes secure delivery a default. Governance scores often signal leadership engagement; low Governance counts read as a programme operating without an active mandate. Capture per-activity evidence (training records, published strategy, policy register, metrics dashboard) on the engagement record so the activity-observed claim has artefacts behind it.
Intelligence: Attack Models, Security Features and Design, Standards and Requirements
The Intelligence domain covers the corporate-knowledge layer of the programme. Attack Models defines the threats and abuser profiles the programme expects to defend against. Security Features and Design captures the secure design patterns and reusable security features the engineering organisation depends on. Standards and Requirements turns the threat model into procurable specifications. Intelligence is how a programme stops reinventing the same security review on every new system; low Intelligence counts read as a programme that re-runs the same conversation on every release. Capture per-activity evidence (threat model catalogue, reference architecture, requirement set) on the engagement record so Intelligence activities have durable artefacts.
SSDL Touchpoints: Architecture Analysis, Code Review, Security Testing
The SSDL Touchpoints domain covers the activities that touch the secure software development lifecycle inside engineering. Architecture Analysis runs design review against the threat model. Code Review runs security review on changes that matter. Security Testing exercises the live system with DAST, SAST, SCA, and manual review. These activities are the most visible to engineers and the ones where the programme either earns operational credibility or loses it. Capture per-activity evidence (architecture review records, code review records, scanner output, manual test reports) on the same engagement record that carries the BSIMM scorecard.
Deployment: Penetration Testing, Software Environment, Configuration Management and Vulnerability Management
The Deployment domain covers the activities that close the loop after release. Penetration Testing exercises the released system from an external perspective. Software Environment covers the production hardening, monitoring, and incident workflows that protect the system in operation. Configuration Management and Vulnerability Management turns discovered findings into closed records on a workflow that survives turnover. Deployment is how a programme demonstrates that secure delivery survives contact with production; low Deployment counts read as a programme that ships but does not close. Capture per-activity evidence (pentest reports, runbooks, vulnerability lifecycle records) on the engagement so the Deployment scorecard is reproducible at the next cycle.
Activity prevalence, scorecard, and the comparative position
BSIMM scores at the activity level: each activity in the BSIMM catalogue is observed or not observed per participating organisation. Practices roll up to activity counts; domains roll up to per-domain counts. The headline scorecard reports the programme activity count per practice alongside the study-average count, the industry-vertical average count, and the highest count observed in the population. Capture observations, evidence per activity, and the comparative position against the relevant study cuts on the engagement record so the BSIMM measurement is reproducible and defensible at the next annual cycle.
Measurement cycle: scope, observe, score, compare, plan, re-measure
A BSIMM measurement is most useful when it is a recurring cycle rather than a one-time engagement. Scope the practices the programme is in scope for. Observe the activities the programme runs, with evidence per observation. Score the activity count per practice. Compare against the study-average position. Plan the activity additions for the next cycle, with named owners and timelines. Re-measure the following year on a comparable basis. Capture each step on the engagement record so the measurement carries forward across cycles, personnel transitions, and audit cycles.
Related features
Orchestrate every security engagement from start to finish
Vulnerability management software that tracks every finding
AI-powered reports in seconds, not days
Compliance tracking without a full GRC platform
Find vulnerabilities before they ship
Test web apps behind the login
Monitor continuously catch regressions early
Document management for every security engagement
Every action recorded across the workspace
Run BSIMM measurement cycles as structured records
Catalogue activities, capture evidence, score per-practice prevalence, compare against the study position, and re-measure on annual cadence. Start free.
No credit card required. Free plan available forever.