Key takeaways
- Most security frameworks start from first principles and tell an organisation what it should implement.
- BSIMM organises everything into a Software Security Framework (SSF): four domains, each containing three named practices, for twelve practices total, which in turn group the model's activities.
- By measured frequency across the data pool, which is the model's defining methodological choice.
- That AI's effect on real security programs is now measurable, not speculative — one of the clearest examples this guide found of a framework reporting on AI from its own live data rather than a vendor claim.
BSIMM (Building Security In Maturity Model) is not a checklist of recommended practices but a data-driven study: its current edition, BSIMM16 (2026), documents 128 real-world security activities — grouped into 12 practices across 4 domains — observed across a data pool of 111 participating firms, with each activity's maturity level set by how often it is actually seen in practice rather than by design. First published in 2008 as BSIMM1, the project is explicitly framed by its own report as "a descriptive model" of what effective software security initiatives actually do, not a prescriptive standard of what they should do, and it is updated and republished annually by Black Duck.
What problem does BSIMM solve, and how is it different from a standard?
Most security frameworks start from first principles and tell an organisation what it should implement. BSIMM instead starts from observation: structured, in-person-style assessments of real organisations' software security initiatives (SSIs), rolled up into a shared vocabulary and activity catalogue. The report's own history section explains the origin directly: in 2008, researchers "set out to gather data on the different paths that organizations take to address the challenges of securing software," interviewing firms "known to be highly effective in software security initiatives," to "gather details about their efforts, analyze the data, and publish their findings to help others." The result is a benchmark built from what a large, real sample of firms is actually doing this year — which is also why BSIMM is re-issued annually rather than published once and left static.
How is the BSIMM framework structured?
BSIMM organises everything into a Software Security Framework (SSF): four domains, each containing three named practices, for twelve practices total, which in turn group the model's activities. BSIMM16 confirms this structure directly, stating that "within the SSF, the 128 activities are organized into 12 BSIMM practices, which are held within four domains."
| Domain | Practices |
|---|---|
| Governance | Strategy & Metrics (SM) · Compliance & Policy (CP) · Training (T) |
| Intelligence | Attack Models (AM) · Security Features & Design (SFD) · Standards & Requirements (SR) |
| SSDL Touchpoints | Architecture Analysis (AA) · Code Review (CR) · Security Testing (ST) |
| Deployment | Penetration Testing (PT) · Software Environment (SE) · Configuration Management & Vulnerability Management (CMVM) |
Per the report's own terminology section, a domain is "one of the four categories the framework is divided into," a practice is "a grouping of BSIMM activities," and an activity is an "action or effort carried out or facilitated by the SSG [software security group] as part of a practice." Each activity also carries a short code — e.g. CMVM1.1, SM1.4 — combining its practice and assigned level.
How does BSIMM decide which level an activity belongs to?
By measured frequency across the data pool, which is the model's defining methodological choice. BSIMM16 states plainly: "we divide activities into levels per practice based on the frequency with which they're observed in our participants." Level 1 activities are "often straightforward and universally applicable" and "most observed" across BSIMM16's 111-firm data pool; level 2 activities are "less frequently observed" and "often more difficult to implement"; level 3 activities are "more rarely observed" and "usually more difficult to implement and not always applicable." A brand-new activity, with no observation history yet, is added directly at level 3 by convention — the report notes "new activities are added at level 3 because we don't yet know how common they are, so they start with zero observations."
What does BSIMM16's 2026 data actually show about AI and software security?
That AI's effect on real security programs is now measurable, not speculative — one of the clearest examples this guide found of a framework reporting on AI from its own live data rather than a vendor claim. BSIMM16 states "AI continued to be a major area of focus for all organizations in the last year," pointing to growth in [SR3.5] "Create standards controlling and guiding the adoption of new technologies" (an activity BSIMM15 introduced, where "AI is a major part of that for every firm where it was observed") and a 10% year-over-year increase in [AM1.5] "Gather and use attack intelligence." Separately, the report ties a 30% increase in [SE3.6] "Create bills of materials for deployed software" and over 40% growth in a related activity to US federal self-attestation requirements around software bills of materials — a regulatory, not an AI, driver, which the report is careful to distinguish.
BSIMM compared with OWASP SAMM
| BSIMM | OWASP SAMM | |
|---|---|---|
| Basis | Observed data from 111 real firms (BSIMM16) | Prescriptive, self-scored practice levels |
| Access | Framework skeleton published free annually; formal assessment is a paid service | Fully free, open, self-service |
| Level meaning | "How commonly is this observed" | "How sophisticated is this objective" |
| Best used for | Benchmarking against real industry peers | Tracking your own program's maturity over time |
See OWASP SAMM: the Software Assurance Maturity Model, explained for the companion, fully self-service model — the two are not mutually exclusive, and a firm can read BSIMM's published activity list as a free benchmark checklist while still using SAMM (or BSIMM's own paid assessment) for a scored self-evaluation.
How should a device or firmware team use BSIMM without commissioning a formal assessment?
Read the published activity skeleton as a gap list, not a scorecardBSIMM16's level-1 activities (e.g. "ensure host and network security basics are in place," "use automated code review tools") describe what the large majority of the 111 observed firms already do — a reasonable floor for any team shipping connected products. Pay attention to the Deployment domain specifically if you ship firmwareSoftware Environment and Configuration Management & Vulnerability Management (CMVM) activities — host/network hardening, bills of materials, incident response hooks — map directly onto firmware and device operational security, not just web application practice. Treat the AI-related growth activities as a signal, not a checkboxBSIMM16's own data shows real firms actively building AI-adoption standards and bill-of-materials practices right now; a team without either is measurably behind the 111-firm sample it reports against. Re-check the published skeleton annuallyBSIMM is explicitly "adjusted annually to keep it current," so a static read-once summary (including this guide) should be revisited against each year's new report.
CMVM and Software Environment are exactly the areas SoftWSP's device firmware security service targets directly: unpacking a shipped binary image, building a software bill of materials, matching components against published CVE, CISA KEV and FIRST EPSS data, and flagging hard-coded credentials, open debug services and unsigned update paths — with every automated finding reviewed by an engineer before it reaches you. See device firmware security.
This guide is based on a direct read of the BSIMM16 Report 2026 PDF (Black Duck), extracted and quoted from the source document rather than a secondary summary, supplemented by Black Duck's public BSIMM overview and service pages. BSIMM activity names, percentages and growth figures are as published in the BSIMM16 report and will be superseded by future annual editions; this guide is general information, not a substitute for reading the full report or commissioning a formal BSIMM assessment.
Sources
Frequently asked questions
What is BSIMM?
The Building Security In Maturity Model, a data-driven study of real-world software security practices first published in 2008. Per the BSIMM16 report's own framing, in 2008 "application security, research, and analysis experts set out to gather data on the different paths that organizations take to address the challenges of securing software," conducting in-person interviews with organisations known for effective security programs. The result, BSIMM1, is explicitly described as "a descriptive model" — it documents what real software security initiatives actually do, rather than prescribing what they should do. The current edition, BSIMM16, was published in 2026 and is maintained and distributed by Black Duck.
How is BSIMM structured, and what does BSIMM16 say about its own scale?
Around a Software Security Framework (SSF) organised into four domains — Governance, Intelligence, SSDL Touchpoints, and Deployment — each split into three named practices, for twelve practices total, per the BSIMM16 report's own terminology section. The twelve practices are: Strategy & Metrics, Compliance & Policy, Training (Governance); Attack Models, Security Features & Design, Standards & Requirements (Intelligence); Architecture Analysis, Code Review, Security Testing (SSDL Touchpoints); and Penetration Testing, Software Environment, Configuration Management & Vulnerability Management (Deployment). The report states that "within the SSF, the 128 activities are organized into 12 BSIMM practices, which are held within four domains," and that BSIMM16's data pool draws on 111 participating firms.
How are BSIMM's maturity levels assigned to each activity?
By observed frequency, not by design intent — a key difference from a prescriptive model. BSIMM16's own text states: "We divide activities into levels per practice based on the frequency with which they're observed in our participants, ... Level 1 activities (often straightforward and universally applicable) are those that are most observed across the data pool of 111 firms, level 2 activities ... are less frequently observed, and level 3 activities (usually more difficult to implement and not always applicable) are more rarely observed." New activities are added directly at level 3, since the model has no observation history for them yet.
What does BSIMM16 (2026) actually say about AI's effect on software security programs?
That AI adoption is a measurable, growing part of real firms' security activity, not a speculative trend. The report states "AI continued to be a major area of focus for all organizations in the last year," citing [SR3.5] "Create standards controlling and guiding the adoption of new technologies" (introduced in BSIMM15, with AI as "a major part of that for every firm where it was observed") and a 10% year-over-year growth in [AM1.5] "Gather and use attack intelligence." Separately, the report notes a 30% increase in [SE3.6] "Create bills of materials for deployed software" and over 40% growth in a related software-bill-of-materials activity, tied explicitly to US federal self-attestation and SBOM requirements rather than to AI.
How does BSIMM differ from a framework like OWASP SAMM?
BSIMM is observational and BSIMM16 notes a 111-firm data pool built from paid, structured assessments conducted against real organisations; BSIMM's own report describes it as reflecting "current software security efforts" that the model is "adjusted annually to keep it current." See [OWASP SAMM: the Software Assurance Maturity Model, explained](/guides/owasp-samm/) for the contrasting model — SAMM is free, open and explicitly designed for self-assessment against a fixed set of defined practice levels, with no underlying observational data pool behind the level definitions. A firm can use BSIMM's published skeleton and activity descriptions (freely available in the annual report) as a benchmark checklist without commissioning a formal assessment, but the levels themselves are calibrated from the real assessment data, not from a theoretical ideal.
What were BSIMM16's most commonly observed activities?
Per the report's own Table 1 ("Top Activities by Observation Percentage"), the most frequently observed activity across the 111-firm data pool was [CMVM1.1] "Create or interface with incident response" at 87.6%, followed by [SM1.4] "Implement security checkpoints and associated governance" at 82.6%, [SE1.2] "Ensure host and network security basics are in place" at 79.3%, and [CR1.4] "Use automated code review tools" and [PT1.1] "Use external penetration testers to find problems," tied at 78.5%. The report notes this year's list has 12 entries rather than 10 "due to observation rate ties."
In this cluster
