How does Building Security In Maturity Model (BSIMM) work?

How BSIMM measures software security maturity

BSIMM works as an observation-based maturity model. It records what organisations actually do in software security, then compares those practices across governance, intelligence, and engineering activities. The point is not to certify compliance with a fixed standard, but to show where a programme is strong, where it is thin, and how its practice mix compares with peers.

That makes BSIMM useful when you need to understand programme shape rather than simply whether controls exist. It helps answer questions such as whether testing, design review, training, and vulnerability response are present in a balanced way, and whether the organisation is progressing through a mature set of activities instead of relying on a few isolated controls.

For teams building or benchmarking an application security programme, BSIMM is often read alongside broader appsec maturity guidance such as Application Security Guide because the practical value comes from turning observed programme gaps into a prioritised roadmap.

What BSIMM is measuring, and what it is not

BSIMM measures practice presence and depth. In practice, that means looking for evidence of activities like policy and strategy, threat analysis, security testing, code review, dependency management, and incident-informed improvement. The model is descriptive: it captures how software security is actually being run, rather than telling every organisation to adopt the same checklist in the same order.

That distinction matters. A prescriptive framework says what must be done. BSIMM says what mature organisations tend to do, and how those practices tend to cluster. For practitioners, that makes it a benchmarking and planning tool, especially when the goal is to compare a current programme with a broader market pattern and decide what should be added next.

BSIMM is also different from a pure audit view. It is less about proving a one-time control state and more about revealing programme behaviour over time. That is why it works well for identifying missing coverage between governance decisions, development workflows, and operational response, where weaknesses often appear as disconnected activity rather than a single broken control.

Within an appsec operating model, BSIMM fits naturally next to structured maturity approaches such as AppSec Maturity Model because both help teams move from ad hoc activity to a staged improvement plan, even though BSIMM’s method is observational rather than normative.

How practitioners use BSIMM to prioritise improvement

Practitioners usually use BSIMM in three ways. First, they benchmark the current programme against observed peer practice. Second, they spot gaps where a capability is missing, underused, or not yet embedded in the software lifecycle. Third, they sequence improvement work so the next investment addresses the biggest programme weakness, not just the loudest local issue.

That sequencing is important because BSIMM is most valuable when it changes prioritisation. If the programme already has strong testing but weak governance, the next step should not be another testing tool. If incident feedback is not flowing back into engineering, the gap is not merely technical. BSIMM helps expose those imbalances so leaders can fund the right work, assign owners, and measure whether the programme is becoming more coherent.

Many organisations also use BSIMM as a communication tool between security, engineering, and leadership. The model gives teams a common way to discuss whether they are building security into design, development, and operations, instead of treating security as a late-stage review function. That makes it especially useful for roadmapping and for explaining why a mature programme needs both preventive and responsive practices.

For teams already working on secure development, BSIMM is most effective when it informs decisions about process, ownership, and repeatability. Its real value is not the label of maturity itself, but the clarity it gives on what to improve next and what evidence shows the programme is becoming operational rather than aspirational.

Risk and Threat Considerations

BSIMM reduces risk by exposing where a software security programme is thin, uneven, or overly dependent on a few strong people. If an organisation only has pockets of secure coding or testing, the result is inconsistent assurance, which can leave design flaws, vulnerable dependencies, or weak release gates undiscovered until late in the lifecycle.

Failure mechanism: Teams can mistake the existence of a few security activities for programme maturity, while missing gaps in governance, feedback loops, or engineering adoption. That creates control blind spots, especially when vulnerable code reaches production faster than security review can keep up.

Impact: The organisation may keep shipping software with repeated weaknesses, slow remediation, and poor visibility into whether security investments are actually reducing exposure. Over time, that can increase exploitability, raise response cost, and make improvement efforts harder to defend.

Practitioner Guidance

What to verify: Check whether BSIMM findings are tied to real programme evidence, not just self-reported confidence. The strongest use case is when the assessment shows where security work is consistently embedded in engineering and where it still depends on heroics or informal coordination.

What to prioritise: Use BSIMM gaps to identify the smallest set of changes that will improve the whole programme, not just one team’s workflow. In practice, governance, testing, and vulnerability response should be assessed together because weakness in one area often reduces the value of the others.

Practitioner takeaway: BSIMM is most useful when it drives a roadmap, not a score. Treat it as a way to understand how security work really happens, then invest in the practices that make the programme repeatable, measurable, and resilient.

Related resources from NHI Mgmt Group

• Building Security In Maturity Model (BSIMM)
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?