BSIMM (Building Security In Maturity Model): BSIMM – Tutorial (about 60 minutes)

The Building Security In Maturity Model (BSIMM, pronounced "bee simm") is a yardstick for software security programmes. It is built from what real organisations actually do, not from what experts think they should do. Security leaders, application security engineers, engineering managers and auditors use it to describe their software security work in a shared vocabulary, to compare it with more than a hundred other organisations, and to decide where to invest next. After this tutorial you will be able to explain how the model is organised, read a BSIMM scorecard, run a simple self-assessment and turn the result into a sensible improvement plan.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is BSIMM16, the sixteenth annual release, published by Black Duck Software, Inc. in January 2026 (the press release is dated 4 February 2026). It is based on assessment data from 111 organisations and describes 128 activities in 12 practices and four domains. For the first time in the model's history, BSIMM16 made no changes to the framework itself: the 128 activities and their levels are the same as in BSIMM15, and only the data, the activity descriptions and the analysis were refreshed. The model is updated every year, so check whether a newer edition has appeared before you rely on the numbers here; no BSIMM17 had been announced when this tutorial was checked. BSIMM was started in 2008 by Cigital and Fortify, passed to Synopsys when Synopsys bought Cigital in 2016, and moved to Black Duck when the Synopsys Software Integrity Group became the independent company Black Duck Software in October 2024. The report is released under the Creative Commons Attribution-ShareAlike 3.0 licence. BSIMM is a descriptive benchmark, not a standard you certify against. Verified 2026-10-29 against the BSIMM16 report, the Black Duck BSIMM pages and the BSIMM16 press release.

Who it is for: application and product security engineers, security champions, engineering and DevOps leads, CISOs and security programme managers, quality and compliance staff, and consultants who need to describe or improve how an organisation builds secure software.

Prerequisites: none. A general idea of how software is built and released (requirements, design, coding, testing, deployment) helps. Every BSIMM term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why BSIMM is descriptive rather than prescriptive and what that means for how you use it.
You will be able to name the four domains and twelve practices of the software security framework and say what each practice covers.
You will be able to read an activity identifier such as SM1.4 and explain what BSIMM levels do and do not mean.
You will be able to describe the roles in a software security initiative, especially the software security group and security champions.
You will be able to outline how a BSIMM assessment collects evidence, awards credit and produces a scorecard.
You will be able to build a simple scorecard for your own organisation and turn it into a prioritised plan.
You will be able to relate BSIMM to OWASP SAMM, the NIST SSDF, ISO/IEC 27034 and ISO/IEC 27001.

Lesson 1 – Origins, purpose and scope

The problem BSIMM set out to solve

By the mid-2000s most large software organisations knew they had a software security problem. Vulnerabilities such as injection flaws, broken authentication and insecure configuration kept appearing in products and websites, and fixing them after release was expensive and embarrassing. Many companies had started some kind of programme to "build security in": a small team of security experts, a static analysis tool, a penetration test before major releases, maybe a secure coding course. What nobody could answer with confidence was a simple management question: are we doing enough, and are we doing the right things compared with everyone else?

Plenty of methodologies existed, and each one described an ideal process. They disagreed on vocabulary, on order and on emphasis, and almost none of them were based on systematic observation of what successful organisations did. A security leader who wanted to justify a budget, or a board that wanted to know whether its programme was normal, had little real data to work with.

An observational model

In 2008 a small group of software security practitioners from Cigital and Fortify, among them Gary McGraw, Sammy Migues and Brian Chess, took a different approach. Instead of writing down what organisations ought to do, they interviewed the people in charge of software security at nine firms that were known to run effective programmes. They recorded every distinct security activity they found, grouped the activities into a framework, and checked their scorecards with each firm. The first version, published in 2009, contained 110 activities. That empirical method is the defining feature of BSIMM to this day: an activity appears in the model only because several real organisations were observed doing it.

This makes BSIMM a descriptive model. It tells you what is common, what is rare and how programmes of different ages and industries tend to look. It does not tell you that you must do any particular activity, and it does not claim that the most common activities are automatically the most valuable for you. The authors repeat this point often: BSIMM is a measuring stick, not a roadmap, a checklist or a compliance framework. Using it well means combining the data with your own risk picture and business objectives.

Growth over sixteen editions

The study has been repeated and extended every year. The data pool grew from 9 firms in the first study to well over 100, peaked at around 130 in the BSIMM11 to BSIMM14 period, and stood at 111 firms in BSIMM16. The membership changes every year because new firms are assessed and firms whose data has not been refreshed are removed: for BSIMM16, 16 firms were added and 26 dropped. The 111 BSIMM16 participants together reported about 3,700 software security group members, about 6,500 security champions, more than 220,000 developers and about 91,000 applications, with an average programme age of 5.6 years. Participants come mainly from North America, with smaller groups from Asia-Pacific and Europe, and cover verticals such as independent software vendors, financial services, FinTech, technology, cloud, healthcare, insurance and Internet of Things.

The model has evolved as the data changed. Since 2008, 19 activities have been added and one original activity was dropped because it was effectively a duplicate, giving today's 128. Many more activities have moved between levels as they became more or less common. Recent additions reflect how software is now built: activities about open source risk, software bills of materials, cloud security controls, protecting development toolchains and development endpoints, and setting standards for adopting new technologies such as AI.

Scope: what BSIMM covers and what it does not

BSIMM covers an organisation's software security initiative as a whole: governance, people, process and technology involved in building, buying, deploying and operating software securely. It is not limited to one product, one team or one development method; participants use waterfall, agile and DevOps approaches, on-premises and cloud. It does not cover general IT security (for example identity management for office staff or physical security) except where it touches software, such as host and network hardening for deployed applications. It contains no technical controls for specific languages or platforms, and it does not grade the security of a particular application. A firm with a high BSIMM score can still ship a vulnerable product, and a low score does not prove that products are insecure. BSIMM measures the breadth of the programme, not the quality of individual pieces of code.

Lesson 2 – Key concepts and vocabulary

Software security has always suffered from inconsistent terminology, and one of BSIMM's contributions is a common vocabulary. The terms below are used throughout the rest of this tutorial.

Software security initiative (SSI) – the organisation-wide programme that plans, carries out, measures and improves software security activities in a coordinated way. Many companies call it their application security programme, product security programme or DevSecOps programme.
Software security group (SSG) – the internal team (sometimes a single person at the start) whose job is to lead and facilitate software security. Every BSIMM16 participant has one, and the report argues that an SSI without an SSG is very unlikely to succeed across a portfolio.
Security champions – developers, testers, architects, cloud or DevOps engineers and similar people outside the SSG who take an active interest in security and help it scale into their teams. Older BSIMM editions called this group the satellite; the report now prefers the industry term champions.
Secure software development lifecycle (SSDL) – any software lifecycle that has security checkpoints and activities built into it. BSIMM does not prescribe a particular SSDL.
Software security framework (SSF) – the basic structure underneath BSIMM: four domains, each holding three practices, which in turn hold the activities.
Domain – one of the four top-level groupings of the SSF: Governance, Intelligence, SSDL Touchpoints and Deployment.
Practice – one of twelve groupings of related activities, three per domain, such as Code Review or Training.
Activity – the smallest unit of the model: a specific action carried out or facilitated by the SSG, such as using automated code review tools. Activities can be viewed as preventive, detective, corrective or compensating controls in a risk management framework.
Level – a label of 1, 2 or 3 attached to each activity within its practice, based on how often the activity is observed across the data pool. Level 1 activities are common; level 3 activities are rare.
Capability – a set of activities, possibly from several practices, that work together to deliver one security function, for example everything needed to manage open source risk.
Data pool – the anonymised assessment data from the current participants, which is the basis for every statistic in the annual report.
Participants – the firms whose assessments are in the current data pool.
Scorecard – a table listing every activity, showing which ones were observed in an organisation, usually next to the number of participating firms that perform each activity.
BSIMM score – the number of activities credited to an organisation, out of the 128 in the current model. It measures breadth, not quality.
Vertical – an industry segment (for example FinTech or healthcare) used to compare an organisation with peers that face similar risks and regulation.

Two of these terms are easy to misunderstand. First, an activity being observed is not the same as an activity being attempted. Credit requires that the work is done with enough coverage across the software portfolio, enough formality to be repeatable, and enough depth to manage the risk it addresses. Second, BSIMM levels belong to activities, not to organisations. There is no such thing as "a BSIMM Level 2 company". This differs from capability maturity models such as CMMI, where an organisation is appraised at a maturity level, and it is one of the most common sources of confusion for newcomers.

Lesson 3 – Structure of the software security framework

Four domains, twelve practices

The framework arranges the 128 activities into four domains of three practices each. The domains follow a simple logic: you need to organise and steer the effort (Governance), to build up knowledge that the rest of the programme reuses (Intelligence), to examine the software and its development artefacts (SSDL Touchpoints), and to connect with the people who run and maintain software once it is deployed (Deployment).

Figure 1 – The BSIMM software security framework: four domains, each containing three practices, which together hold the 128 activities.

Governance

Governance practices organise, manage and measure the initiative, and they include staff development.

Strategy & Metrics (SM) – planning the initiative, publishing the SSDL, defining security checkpoints (gates) and the governance around them, educating executives, publishing metrics and using them to drive change, building a champions programme, and, at the rarer end, integrating software supply chain risk management.
Compliance & Policy (CP) – identifying the regulatory, contractual and privacy obligations that apply to software, turning them into a software security policy, tracking controls for compliance, and including security terms in vendor contracts.
Training (T) – awareness training, on-demand and role-specific courses, onboarding, events, support for champions, and expertise offered through open collaboration channels such as chat communities.

Intelligence

Intelligence practices produce collections of organisational knowledge that the rest of the initiative draws on.

Attack Models (AM) – classifying data and software, identifying likely attackers, gathering attack intelligence, and building attack patterns and abuse cases. This is where much of the threat modelling knowledge lives.
Security Features & Design (SFD) – creating reusable, approved security features (such as authentication or cryptography components), engaging with architecture teams, and approving secure design patterns.
Standards & Requirements (SR) – writing security standards, running a security portal where guidance is published, translating compliance constraints into requirements, identifying and controlling open source, and setting standards for technology stacks and new technologies.

SSDL Touchpoints

Touchpoints are the analysis and assurance activities applied to specific development artefacts and processes. The name comes from the idea of "touching" the lifecycle at key points with security work.

Architecture Analysis (AA) – reviewing security features and designs, ranking applications by risk, and running a defined design review process, led first by the SSG and later by engineering teams.
Code Review (CR) – manual and automated review of source code, custom rules for tools, top-N bug lists, and central defect reporting.
Security Testing (ST) – security testing within quality assurance: boundary value testing, tests driven by security requirements, integrating dynamic ("opaque-box") tools, fuzzing, and abuse-case tests.

Deployment

Deployment practices connect the initiative to traditional network security and software maintenance groups, because configuration and operating environment have a direct effect on software security.

Penetration Testing (PT) – using external and internal penetration testers, feeding results into defect management, and scheduling periodic tests across the portfolio.
Software Environment (SE) – host and network hardening, cloud security controls, secure deployment configurations, code integrity, containers and orchestration, bills of materials, and protecting development toolchains and endpoints.
Configuration Management & Vulnerability Management (CMVM) – working with incident response, feeding defects found in operations back to engineering, emergency response, operations software inventory, vulnerability disclosure handling, bug bounties and crisis simulations.

Activity identifiers

Each activity has a short identifier made of three parts: the practice abbreviation, the level, and a sequence number within that level. CR1.4 is a Code Review activity at level 1 (using automated code review tools); SM3.5 is a Strategy & Metrics activity at level 3 (integrating software supply chain risk management). Practices hold different numbers of activities, from seven each in Penetration Testing and Security Features & Design to thirteen each in Strategy & Metrics, Software Environment and Configuration Management & Vulnerability Management.

Because the level is part of the identifier, an activity's identifier changes when it moves between levels. For example, implementing cloud security controls was introduced at level 3 in BSIMM9, was later numbered SE2.6, and since BSIMM13 has been SE1.3. This matters when you read other documents that cite BSIMM: the NIST Secure Software Development Framework (SSDF) cites BSIMM12 identifiers, and the BSIMM16 report includes a table that gives current numbers for the 16 SSDF tasks affected by 13 level moves since then. Always note which BSIMM edition an identifier comes from.

How levels are assigned and how they change

Within each practice, activities are sorted into three levels by how often they are observed in the data pool. Level 1 activities are seen most often and are usually straightforward and widely applicable. Level 2 activities are less common and usually need more coordination. Level 3 activities are rare, often harder to implement and not always applicable. Brand-new activities always start at level 3, because when they are added nobody has yet been credited with them.

Figure 2 – BSIMM levels describe how often an activity is observed, so activities enter at level 3 and move between levels as observation rates change.

Every year the authors look at observation rates and decide whether any activity should move. Some move up as practice spreads: cloud security controls became the first activity to travel all the way from level 3, through level 2, to level 1. Others move down as they fall out of fashion or become absorbed into culture: maintaining a top-N list of possible attacks started at level 1 and is now at level 3, and enforcing secure coding standards fell from more than half of firms in the first study to almost none. BSIMM16 is the first edition in which nothing moved; the authors decided to let some trends develop further rather than move activities on weak evidence.

The consequence for you is important. A level tells you how common an activity is today, not how valuable or advanced it is. A level 3 activity might be rare because it is new and spreading, because it suits only some industries (such as code protection for software shipped to devices), or because it is fading away. A level 1 activity is popular, which suggests most initiatives find it useful, but popularity is not a requirement.

Lesson 4 – How BSIMM works in practice

Three parts of the BSIMM

It helps to think of BSIMM as three connected parts. The framework (the domains, practices and activities) gives the structure. Individual assessments measure real organisations against that structure and generate data. The long-term study analyses the anonymised data each year and publishes the annual report, which in turn updates the framework when activities are added or moved. Your own use of BSIMM sits on this cycle: you are measured against the framework, and you compare yourself with the data pool.

Figure 3 – How the framework, individual assessments and the long-term study feed each other, and where an organisation's scorecard and plan come from.

Roles in a software security initiative

BSIMM data shows that successful initiatives share a recognisable set of roles.

Executive sponsor. Initiatives with lasting firm-wide impact have a senior executive who is accountable for software security and who empowers the SSG. In BSIMM16 the nearest executive to the SSG is a CISO in about half of firms, with CTOs, CIOs, CSOs and others making up the rest.
SSG leader. The person who runs day-to-day software security. Titles vary widely, from Head of AppSec to Director of Product Security.
The SSG itself. A dedicated group that may be corporate, inside engineering, or a hybrid. SSGs are organised in different ways: as a service provider, as a policy setter and verifier, mirroring business units, as a hybrid of policy and services, or as a matrixed team of experts. The median SSG in BSIMM16 has about ten people, but sizes range from one to several hundred.
Security champions. People embedded in engineering teams who carry part of the security work, act as a sounding board for proposed changes and spread practices bottom-up. BSIMM data shows a strong association between champions and higher scores: almost all of the top-scoring fifth of BSIMM16 firms have champions, compared with less than a third of the bottom fifth. The report is careful to say this is a correlation; the data cannot show which causes which.
Other stakeholders. Builders (developers and architects), testers, operations and administrators, product owners and managers, governance, risk, compliance, legal and privacy specialists, and procurement and vendor management all have a part. Software security is cross-departmental by nature.

Emerging, maturing and enabling initiatives

The report describes three broad states of an SSI. These are descriptive, not formal grades.

An emerging initiative has an initial strategy, a small and resource-constrained SSG, a set of foundational activities (often the most commonly observed ones) and a roadmap for roughly the next 18 months. It usually relies on compliance requirements or executive mandates to get engagement. BSIMM16 firms whose programme was 18 months old or less averaged a score of about 32.
A maturing initiative has an established team, defined ways of working with stakeholders and a documented approach tied to executive expectations. It focuses on scaling: reducing friction, automating, extending into supply chain and incident response, and testing earlier and more often (the report calls this "shift everywhere").
An enabling initiative makes the secure path the easiest path for everyone, uses data from testing and operations to drive improvements, and treats policy and standards increasingly as code inside engineering pipelines.

Getting an emerging initiative started

For organisations starting out, the report suggests a sequence of efforts, each linked to particular activities. In paraphrase:

Create an SSG, even of one person, and give it resources and a mandate.
Document the SSDL and make sure every stakeholder knows what is expected of them.
Inventory the applications in the SSG's remit, including key characteristics such as language, architecture, open source used, owners and where they run, and rank them by risk.
Make sure the infrastructure the software runs on is hardened, because good software on badly secured hosts or cloud accounts is still exposed.
Deploy defect discovery: automated static and dynamic testing for coverage, plus expert testing such as external penetration tests for the highest-risk applications.
Manage the defects found, logging them in one place and tracking them to closure, with an exception process for risks that are accepted.
Publish and promote the process, both top-down through policy and standards and bottom-up through engineering pipelines and community channels.

Although this looks like a sequence, many of the efforts run in parallel and repeat. The report also warns young initiatives not to try to implement too many activities at once: organisations can only absorb a limited amount of technology, hiring and cultural change at a time.

The "Top 10" and common core

Each report lists the most frequently observed activities across all firms. In BSIMM16 this "Top 10" actually contains 12 activities because of ties. They include creating or working with incident response, implementing security checkpoints and associated governance, ensuring host and network security basics, using automated code review tools, using external penetration testers, identifying privacy obligations, boundary value testing in QA, creating a software security policy, reviewing security features, unifying regulatory pressures, creating a security portal and identifying open source. The authors suggest every initiative should at least consider these, while stressing that "consider" does not mean "must adopt".

Lesson 5 – Assessment, scoring and the absence of certification

There is no BSIMM certification

BSIMM has no certification scheme, no accredited certification bodies, no pass mark and no organisational maturity rating. Nobody "complies with" BSIMM. What exists is measurement: an organisation is assessed, receives a scorecard showing which activities were observed, and compares that scorecard with the data pool. Claims such as "BSIMM certified" or "BSIMM Level 3 organisation" are misunderstandings of the model and should be challenged.

Official BSIMM assessments

Formal BSIMM assessments are carried out by BSIMM assessors at Black Duck (previously Synopsys and Cigital). The process is interview-based: assessors hold in-depth conversations, in person wherever possible, with the SSG and with people in engineering, quality assurance, operations, legal, compliance, training, incident response and other relevant groups. They look for the existence of each activity and ask how it is performed, how widely, how consistently and with what resources. They then examine documents, processes and other artefacts to confirm what they heard. An activity is credited only when it is performed with sufficient coverage across the organisation, sufficient formality to be repeatable and consistent, and sufficient depth to manage the associated risk.

The outputs typically include a scorecard of all 128 activities, comparisons with the whole data pool and with the organisation's vertical (for example charts of coverage in each practice), and a report of strengths and gaps. Black Duck also sells follow-on services that turn the results into a prescriptive improvement plan; these are commercial offerings built on top of the model, not part of it. The anonymised data from each assessment of a whole initiative is added to the data pool, which is how the annual study is produced. Assessments of individual business units are increasingly common but are not added to the pool reported each year. The report says the BSIMM team has assessed 283 firms since 2008.

Self-assessment

Because the report and activity descriptions are freely available, any organisation can build its own scorecard. The report's quick guide describes the method, which is summarised in Figure 4.

Figure 4 – Building and using a BSIMM scorecard: interview, verify evidence, credit activities, compare, plan and re-measure.

The key steps are these:

Understand the mandate. Decide what the initiative is expected to achieve, who sponsors it, who is responsible and accountable, which metrics executives need, and which software portfolio is in scope.
Interview broadly. No single person knows everything about a modern initiative. Cover the SSG, champions, engineering, QA, operations and security testing, and add cloud, privacy, training, reliability, AI and other teams as needed. Keep each interview short and focused on the activities relevant to that person's role.
Demand evidence. Award credit only when artefacts show that the activity really happens with enough depth and breadth.
Choose a scoring scale. A simple 1 or 0 per activity matches the official approach. Some organisations use low, medium and high, or a percentage, to capture partial coverage. Be consistent from one measurement to the next.
Consider several scorecards. One aggregated scorecard is usually enough, but separate scorecards for business units or application teams can reveal uneven maturity.

A self-assessment is useful for planning, but it is not comparable in rigour with an independent assessment: internal teams tend to give themselves the benefit of the doubt, and the result is not added to the data pool. Treat comparisons between a self-assessed score and published averages as approximate.

Reading a score and a scorecard

A BSIMM score is simply the count of credited activities. In BSIMM16 the most common score band was 31 to 40, and individual scores ranged from 12 to 101. Firms that have been measured several times and have older initiatives tend to score higher. The score is useful for tracking your own progress over time and for a rough comparison with peers, but it has clear limits:

It counts breadth, not effectiveness. Two firms with the same score can manage risk very differently.
All activities count equally, although their cost and value differ greatly.
A higher score is not automatically better. An activity that does not fit your risks or technology adds cost without benefit.
The data pool is a self-selected group of organisations willing to invest in assessment, so its averages describe that group, not all software companies.

The scorecard is more informative than the score. Look first at the most common activity in each practice: if your organisation does not perform it, ask why. Sometimes there is a good reason (for example, penetration testing is done in-house, so the external testing activity is not needed); sometimes it reveals a real gap. Then look at practices where you are far below your vertical, and at activities your stakeholders consider essential whatever their popularity.

BSIMM in regulatory and customer contexts

Because BSIMM activities read like controls, governance, audit and legal teams find them easy to understand. Many firms use their scorecard to explain their software security posture to customers, partners and regulators. BSIMM is also one of the most frequently cited references in the NIST SSDF (SP 800-218 version 1.1, February 2022), which United States federal software suppliers attest against. That makes BSIMM a practical bridge: a firm that maps its scorecard to SSDF tasks can show which tasks it already performs. A draft Revision 1 of SP 800-218 (SSDF version 1.2) was published for comment in December 2025, so check NIST for the current status of that revision before relying on any mapping.

Lesson 6 – Worked example

This example follows a fictional company, Kestrel Health Software, through a first BSIMM self-assessment and the year that follows. The numbers are invented for illustration.

The situation

Kestrel builds a cloud platform for hospital scheduling and patient messaging. It has about 600 developers in 40 teams, roughly 120 applications and services, and a two-person application security team that reports to the CISO. Large hospital customers have started sending long security questionnaires, one prospective customer has asked for evidence of a secure development lifecycle, and the board wants to know whether Kestrel's investment in software security is "normal for the industry". The CISO decides to use BSIMM to answer that question with data rather than opinion.

Step 1 – Mandate and scope

The CISO and the chief technology officer agree on the mandate: the initiative should reduce the risk of exposing patient data through software defects, support customer assurance requests, and prepare for possible regulatory requirements. The scope is all customer-facing software and the internal tools that build and deploy it, but not office IT. The application security lead is named SSG leader. Executives ask for three metrics: share of applications with automated testing in the pipeline, age of open critical security defects, and progress against the BSIMM-based plan.

Step 2 – Interviews and evidence

The SSG leader reads the activity descriptions, then interviews 14 people over three weeks: the SSG, three engineering managers, two architects, the QA lead, the site reliability lead, the incident response manager, the privacy officer, the head of procurement, and two developers who informally help their teams with security. Each interview covers only the practices relevant to that person. For every claim, the SSG leader asks for an artefact: a policy document, a pipeline configuration, a sample of tickets, a training record, a penetration test report.

Several claims do not survive the evidence check. One team runs a static analysis tool, but only 6 of 40 teams do, so the automated code review activity is not credited yet. The security portal exists but has not been updated for two years, so it is credited only after discussion because teams still use it daily. A threat modelling session was held once for a single product, which is not enough coverage for design review credit.

Step 3 – The scorecard

Kestrel uses simple 1 or 0 scoring. The result is 29 credited activities. Strengths are in Compliance & Policy (privacy obligations, a software security policy, vendor security terms) and in Deployment (cloud security controls, host hardening, incident response cooperation, external penetration tests). Gaps cluster in SSDL Touchpoints and Training: no consistent automated code review, no risk ranking of applications, no defined design review process, no security tests in QA automation, and awareness training only at onboarding.

Comparing with the BSIMM16 data, the SSG leader notices that Kestrel does not perform four activities that are the most common in their practices, including implementing security checkpoints with associated governance and using automated code review tools. A score of 29 is close to the average for young initiatives, which matches Kestrel's situation: it has had a security team for just over a year. Compared with the healthcare vertical, Kestrel is relatively strong on compliance and weaker on testing.

Step 4 – Deciding what matters

The SSG leader resists the temptation to simply chase the most popular missing activities. Instead, each gap is checked against Kestrel's risks and objectives:

Automated code review across all teams: high priority, because it addresses the most likely source of patient data exposure and supports customer assurance.
Security checkpoints in the release process with tracked exceptions: high priority, because without gates the new testing results would not change anything.
Risk ranking of applications: high priority and cheap, because it tells the small SSG where to spend scarce expert time.
A security champions programme: medium priority, but with long lead time, so it starts now. Two developers are already acting informally as champions.
Operating a bug bounty: deliberately postponed. Kestrel already runs external penetration tests and wants a better handle on known defects before inviting outside researchers.
Code protection against reverse engineering: not applicable for now, because Kestrel ships no client software that runs on customer devices.

Step 5 – The plan and the first year

The plan has four quarters. In the first, the SSG ranks all 120 applications by data sensitivity and exposure, and adds static analysis and open source scanning to the shared pipeline template so that new services get them by default. In the second, it introduces a release checkpoint for the top-ranked applications: critical findings must be fixed or formally accepted by a named risk owner. In the third, it launches a champions programme with one volunteer per team, monthly meetings and a chat channel where the SSG answers questions. In the fourth, it runs design reviews for the ten highest-risk applications using a simple defined process and starts adding security test cases to QA automation for those applications.

Fifteen months after the first scorecard the SSG leader repeats the interviews with the same method. The score rises to 41. More importantly, the executive metrics show that 85 percent of applications now have automated testing in the pipeline and that critical defects are fixed far faster. The board receives a one-page summary: the scorecard compared with the previous year and with the healthcare vertical, the risks addressed, and the next set of priorities. When a hospital customer asks for evidence of secure development, Kestrel shares a short description of its SSDL, its activities mapped to the NIST SSDF, and its improvement trend, without ever claiming to be "BSIMM certified".

What the example shows

The value came from the structure of the conversation as much as from the number. BSIMM gave Kestrel a vocabulary to describe its programme, a disciplined way to collect evidence, a realistic picture of what peers do, and a repeatable measurement for showing progress. The decisions, however, were driven by Kestrel's own risks: the model informed the plan, it did not dictate it.

Lesson 7 – Relationship to other standards and frameworks

BSIMM is often used alongside other models. The most important distinction is between descriptive models, which report what organisations do, and prescriptive models or standards, which state what organisations should do or must do.

Framework	Owner	Nature	Structure	How it relates to BSIMM
BSIMM	Black Duck Software	Descriptive benchmark built from observed practice; free report under a Creative Commons licence	4 domains, 12 practices, 128 activities, levels by observation frequency	Measures what an initiative does and compares it with a data pool of real firms; no certification
OWASP SAMM (Software Assurance Maturity Model) version 2	OWASP Foundation	Prescriptive, open maturity model for self-assessment and roadmaps	5 business functions (Governance, Design, Implementation, Verification, Operations), 15 practices, maturity levels 1 to 3 per practice	Tells you what good looks like at each level and how to improve; often used with BSIMM, which shows what peers actually do
NIST SSDF (SP 800-218)	NIST	Set of recommended secure development practices and tasks, outcome-based	Four groups: prepare the organisation, protect the software, produce well-secured software, respond to vulnerabilities	Cites BSIMM as a reference for many tasks; a BSIMM scorecard can be mapped to SSDF tasks to support supplier attestation
ISO/IEC 27034 (Application security)	ISO and IEC	International standard series on integrating security into application lifecycle processes	Organisation normative framework, application security controls, application security management process	Prescribes processes and controls; BSIMM can show which related activities are already in place
ISO/IEC 27001 (Information security management)	ISO and IEC	Certifiable management system standard for information security	Management system clauses 4 to 10 plus an Annex A reference control set, including secure development controls	Covers the whole organisation; BSIMM provides much more detail on the software part and can feed evidence for secure development controls

BSIMM and OWASP SAMM

BSIMM and SAMM first appeared in the same year, 2009, and are the two best-known software security maturity models. They look similar at a glance, since both have roughly a dozen or more practices grouped into high-level areas and three levels. The difference is philosophical. SAMM describes recommended practices and defines maturity levels that an organisation progresses through, with a free toolkit for self-assessment. BSIMM describes observed activities and assigns levels by frequency. Many organisations use SAMM to define a target and BSIMM to sanity-check that target against what peers really do, or they use one as the main model and map to the other for communication.

BSIMM and the NIST SSDF

The SSDF is a concise set of practices that United States federal agencies expect software producers to follow, and producers selling to the federal government attest to them. The SSDF references BSIMM more than almost any other source. BSIMM gives far more granular, data-backed detail, while the SSDF gives the authoritative list of outcomes. When you map between them, remember the identifier changes described in Lesson 3: SSDF version 1.1 cites BSIMM12 numbers.

BSIMM and management system standards

ISO/IEC 27001 asks for an information security management system and includes secure development among its reference controls, but it says little about how to run a software security programme at scale. BSIMM fills that gap with concrete activities and peer data. Neither replaces the other: an ISO/IEC 27001 certificate says the management system meets the standard, while a BSIMM scorecard says which software security activities are in place. The same is true of sector requirements such as the PCI Secure Software Standard or medical device and automotive cybersecurity standards: they set requirements; BSIMM helps you see how your programme compares when you organise to meet them.

Common pitfalls and best practices

Common pitfalls

Treating BSIMM as a checklist. Trying to implement all 128 activities, or all the popular ones, wastes effort on activities that do not fit your risks and overwhelms young teams.
Confusing activity levels with organisational maturity. Describing a company as "BSIMM Level 2" or chasing level 3 activities because they sound advanced misreads what levels mean.
Claiming certification or compliance. BSIMM has no certification; claiming it misleads customers and damages credibility.
Generous self-scoring. Crediting activities that one team performs once, or that exist only on paper, inflates the score and hides real gaps.
Equating score with security. A high count of activities does not prove products are secure, and all activities are weighted equally whatever their value.
Mixing editions. Comparing activity identifiers or averages from different BSIMM editions without checking for level moves and data pool changes.
Interviewing only the security team. The SSG alone cannot describe what engineering, operations, procurement and legal actually do.

Best practices

Start from the mandate. Agree what the initiative must achieve and for whom before you score anything, then judge gaps against those objectives.
Insist on evidence. Credit an activity only when artefacts show adequate coverage, formality and depth, and record why each decision was made so the next measurement is consistent.
Use the data to ask questions. When you lack the most common activity in a practice, investigate why rather than adding it automatically.
Invest in people as well as tools. Build an SSG with engineering and communication skills, and grow a security champions programme to scale.
Automate the basics. Put testing, open source checks and policy rules into shared pipelines so that secure behaviour becomes the default.
Re-measure on a fixed cadence. Repeat the scorecard every 12 to 18 months with the same method and show the trend to executives.
Combine models deliberately. Use BSIMM for benchmarking, and a prescriptive model or regulation for targets and obligations, with a clear mapping between them.

Summary and key takeaways

BSIMM is a descriptive model of software security initiatives, built since 2008 from assessments of real organisations; the current edition, BSIMM16 (January 2026), covers 111 firms and 128 activities.
The software security framework has four domains (Governance, Intelligence, SSDL Touchpoints, Deployment), each with three practices.
Activity levels 1 to 3 express how commonly an activity is observed, not how mature an organisation is; identifiers change when activities move.
Successful initiatives have an accountable executive, a dedicated software security group and, very often, a security champions programme.
A BSIMM assessment is interview-based and evidence-checked; credit requires adequate coverage, formality and depth, and the result is a scorecard, not a certificate.
The score counts activities and is best used to track your own progress and to prompt questions, not as a measure of product security.
Good use of BSIMM combines peer data with your own risks: prioritise gaps that matter to your mandate and re-measure every 12 to 18 months.
BSIMM complements prescriptive models and standards such as OWASP SAMM, the NIST SSDF, ISO/IEC 27034 and ISO/IEC 27001.

Reflection questions

Think of your own organisation. Who would you need to interview to build an honest BSIMM scorecard, and which of those people would you find hardest to reach?
Pick one practice from Figure 1. Which of its activities do you believe your organisation performs, and what artefact would you show an assessor to prove each one?
Your score turns out to be well below the average for your vertical. How would you explain this to executives without either alarming them or dismissing the gap?
Choose an activity that is rarely observed. Under what circumstances would it be the right priority for your organisation even though few peers perform it?
How would you combine BSIMM with a prescriptive framework or regulation that applies to your products, and what would each one contribute to your plan?