BSIMM
BSIMM
Building Security In Maturity Model — a software security maturity measurement model
1. Overview: A Data-Driven Security Maturity Model That Measures and Benchmarks Real Corporate Security Activities
flowchart LR
A["Subjective assessment of SW security activities<br/>No industry comparison baseline<br/>Unclear improvement direction"] --"Observation and measurement<br/>based on real data"--> B["4 domains, 12 practices<br/>122 activities systematized"] --"Industry benchmarking<br/>gap analysis"--> C["Data-driven<br/>security investment decisions"]
style A fill:#FFEBEE,stroke:#D32F2F,color:#000
style B fill:#E3F2FD,stroke:#1976D2,color:#000
style C fill:#E8F5E9,stroke:#388E3C,color:#000
Definition: A data-driven maturity model built by Synopsys (formerly Cigital) by observing and measuring the actual software security activities of hundreds of organizations across finance, fintech, healthcare, and technology. It classifies an organization’s software security program into 4 domains, 12 practices, and 122 activities, and is a descriptive framework that compares an organization against the industry average to show its current level and improvement direction.
Characteristics: (Observational) Measures and compares activities actually being performed in the industry, not idealized goals. (Descriptive benchmarking) While OWASP SAMM offers a prescriptive roadmap, BSIMM specializes in descriptive benchmarking. (Reflects latest trends) Participant data is updated annually or biennially, automatically reflecting the latest industry trends.
2. Core Structure of BSIMM
A. The 4 Domains and 12 Security Practices
flowchart TD
subgraph GOV["Governance"]
direction LR
G1["Strategy & Metrics<br/>(SM)"]
G2["Compliance<br/>& Policy (CP)"]
G3["Training<br/>(T)"]
end
subgraph INT["Intelligence"]
direction LR
I1["Attack Models<br/>(AM)"]
I2["Security Features<br/>& Design (SFD)"]
I3["Standards &<br/>Requirements (SR)"]
end
subgraph SSDL["SSDL Touchpoints"]
direction LR
S1["Architecture<br/>Analysis (AA)"]
S2["Code Review<br/>(CR)"]
S3["Security<br/>Testing (ST)"]
end
subgraph DEP["Deployment"]
direction LR
D1["Penetration<br/>Testing (PT)"]
D2["Software<br/>Environment (SE)"]
D3["Configuration Mgmt<br/>& Vulnerability (CMVM)"]
end
style GOV fill:#E3F2FD,stroke:#1976D2,color:#1E3A5F
style INT fill:#F3E5F5,stroke:#7B1FA2,color:#4A148C
style SSDL fill:#FFF3E0,stroke:#F57C00,color:#E65100
style DEP fill:#E8F5E9,stroke:#388E3C,color:#1B5E20
| Domain | Practice Code | Practice Name | Core Purpose |
|---|---|---|---|
| Governance | SM | Strategy & Metrics | Operating the SSG (Software Security Group) and establishing security metrics |
| CP | Compliance & Policy | Managing security policy and compliance requirements | |
| T | Training | Building developer and security team capability through training | |
| Intelligence | AM | Attack Models | Threat intelligence and attack pattern analysis |
| SFD | Security Features & Design | Providing reusable security components and patterns | |
| SR | Standards & Requirements | Establishing security standards and coding guidelines | |
| SSDL Touchpoints | AA | Architecture Analysis | Architecture security review and threat modeling at design time |
| CR | Code Review | Security code review and use of static analysis tools | |
| ST | Security Testing | Risk-based security testing, DAST, fuzzing | |
| Deployment | PT | Penetration Testing | Penetration testing and red-team operations |
| SE | Software Environment | Production environment security hardening, OS hardening | |
| CMVM | Configuration Mgmt & Vulnerability | Vulnerability management and patch process operations |
B. Benchmarking Based on Real Measured Data
flowchart LR
subgraph R1[" "]
direction LR
B1["Current-state measurement<br/>Observe and record whether<br/>12 practices/122 activities are performed<br/>Score calculation"]
B2["Industry comparison<br/>Compare against average scores<br/>of peer companies by sector/size<br/>Spider chart visualization"]
end
subgraph R2[" "]
direction LR
B3["Gap analysis<br/>Identify areas below industry average<br/>Derive priority improvement tasks<br/>Determine investment priority"]
B4["Roadmap development<br/>Short-term and mid/long-term goals<br/>Resource allocation plan<br/>Annual re-measurement"]
end
style B1 fill:#E3F2FD,stroke:#1976D2,color:#000
style B2 fill:#F3E5F5,stroke:#7B1FA2,color:#000
style B3 fill:#FFF3E0,stroke:#F57C00,color:#000
style B4 fill:#E8F5E9,stroke:#388E3C,color:#000
style R1 fill:none,stroke:none
style R2 fill:none,stroke:none
BSIMM vs. OWASP SAMM Comparison
| Comparison Item | BSIMM | OWASP SAMM |
|---|---|---|
| Approach | Descriptive — observes and measures activities actually performed | Prescriptive — presents idealized goals and a roadmap |
| Data basis | Based on measured data from hundreds of companies | Based on industry best practices |
| Benchmarking | Direct comparison against industry average | Measures an absolute maturity level |
| Number of activities | 122 observable activities | 90 security activities |
| License | Paid (provided by Synopsys) | Open source (free) |
| Complementary use | Use BSIMM to diagnose current state → use SAMM to build the improvement roadmap |
3. Expected Benefits and Practical Application of Adopting BSIMM
| Category | Key Expected Benefit | Application & Practical Use |
|---|---|---|
| Objective diagnosis | Objectively gauge software security level against the industry average | Track security maturity trend and industry standing via annual BSIMM assessment |
| Investment justification | Persuade leadership on data-driven security investment priorities | Secure SAST budget using evidence such as “CR (code review) score lower than competitors” |
| SSG operation | Systematize Software Security Group (SSG) activities | Establish SSG roles, KPIs, and reporting structure based on the BSIMM SM practice |
| DevSecOps integration | Integrate SSDL touchpoint domains (AA, CR, ST) with CI/CD automation | Embed code review and security testing activities as pipeline gates |