Building Security In Maturity Model (BSIMM) is a descriptive model for observing and comparing software security activities across organisations. It helps teams benchmark practices such as governance, design review, testing, and vulnerability management. Practitioners use it to identify gaps and prioritise programme improvements, not as a compliance standard or pass-fail certification.
What BSIMM measures
BSIMM is useful because it measures what an organisation actually does in software security, rather than whether it has achieved a fixed certification outcome. That makes it well suited to benchmarking, internal maturity discussions, and prioritising improvement work across teams or business units.
Its value is in comparability. When organisations describe activities in the same model, they can see where practices are absent, inconsistent, or concentrated in only one part of the SDLC, which is harder to spot from ad hoc programme reviews alone.
For teams looking to place BSIMM alongside adjacent application security approaches, OWASP SAMM is a natural reference point because both are maturity-oriented and help structure software security improvement conversations.
How BSIMM is used in practice
Most practitioners use BSIMM as a measurement and planning lens, not as a pass-fail standard. It helps security, engineering, and leadership teams observe which activities are already present, where they are unevenly applied, and which areas need a programme roadmap rather than a one-time fix.
The model is especially helpful when organisations want to compare security practice across multiple teams, subsidiaries, or product lines. It creates a common vocabulary for governance, design review, testing, and vulnerability management without forcing every group into the same control stack.
That kind of comparison is most effective when paired with a broader software security programme. NHIMG’s Application Security Guide shows how maturity concepts connect to secure SDLC practices such as threat modelling, testing, triage, and programme ownership.
What BSIMM does and does not tell you
BSIMM describes observed practice, so it is strongest at showing breadth, consistency, and relative maturity. It does not, by itself, prove that software is secure, that a team is compliant, or that a control is effective in every context.
That distinction matters. A mature-looking programme can still have gaps in architecture, logging, dependency control, or response discipline, while a smaller programme may be highly effective in a limited environment. BSIMM is therefore best read as a capability lens, not as a security guarantee.
Used well, it helps leaders decide where to invest next. Used poorly, it can become a scorecard detached from engineering reality.
Where BSIMM fits among maturity models
BSIMM sits in the family of descriptive maturity models that help organisations understand current-state security capability and compare it with peers or target outcomes. Its focus is software security practice, so it complements broader governance, cloud, identity, or operational maturity models rather than replacing them.
For organisations that want a wider capability view, GRC Maturity Model provides a useful contrast because it frames governance and risk progression more broadly, while BSIMM stays closer to software security activity.
Where a team needs to align application security maturity with engineering delivery, NHIMG’s Application Security Guide also helps translate maturity observations into programme design choices.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, OWASP SAMM and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | BSIMM tracks software security practices that shape secure architecture and engineering maturity. |
| Recommendation — Use V15 to structure secure design and architecture expectations that BSIMM observations can benchmark. | ||
| OWASP SAMM | 1 — Governance | BSIMM is a maturity model for software security activities, closely aligned to SAMM's maturity structure. |
| Recommendation — Use SAMM to benchmark current software security practices and plan incremental maturity improvements. | ||
| NIST CSF 2.0 | GV.OC-01 — Organisational Context | BSIMM helps organisations compare software security practice against programme context and priorities. |
| Recommendation — Define software security maturity goals in line with organisational context and priorities. | ||
Practitioner Guidance
Governance implication: Treat BSIMM as a diagnostic input to programme ownership, not as evidence that security is “done”. The most useful outcome is usually a clearer prioritisation of which activities need standardisation, expansion, or executive sponsorship.
What to watch for: The model adds the most value when teams use it to compare practice across business units or product groups and then follow up with specific improvement actions. If it is used only to generate a score, its operational value drops quickly.
Practitioner takeaway: BSIMM is strongest when it drives a conversation about capability gaps, consistency, and investment, rather than serving as a reporting badge.
Related resources from NHI Mgmt Group
- How do security teams compare model cost, latency, and output quality across providers without building a separate evaluation workflow?
- How do security leaders know whether an identity maturity model is actually improving control?
- What breaks when organisations do not have a clear identity security maturity model?
- How should security teams move from partial security processes to a repeatable maturity model?