Building Security In Maturity Model
Framework for measuring and improving software security practices. Measures activities across governance, intelligence, SSDL touchpoints, and deployment.
What BSIMM12 draws on
This framework pulls on all three pillars — which is why running them as three separate tools means reconciling three sets of evidence at audit time.
Compliance
Security
What your auditor cites,
and what produces the evidence
The regulator's text is quoted below in italic, exactly as written. What follows each one is what the platform records, detects, or proves — not a claim about your compliance status, which no tool can confer.
Code Repository Protection
Organizations MUST audit access to source code repositories and development databases.
A record of processing is only as good as the layer producing it. Real-time SQL auditing captures every statement against the data — the identity, the session, the client, the objects touched, the outcome — with no nightly batch window where activity goes unrecorded. Classification is what makes that a record of *regulated* data rather than a log of everything: it tells you which tables are in scope, so the register describes the processing you actually have to declare. Policy templates then produce it in the shape the framework asks for, instead of leaving you to assemble it from raw logs the week before an inspection.
Software Inventory
REQUIRES maintaining software inventory including binary and code provenance logs.
You cannot evidence a control over data you have not located. Discovery scans every connected store continuously and classifies what it finds against 200+ built-in patterns and 20+ categories, so the inventory reflects the estate as it is today rather than as it was at the last manual survey. Because the classification is what ranks the scanning and shapes the reports, it cannot quietly go stale without something visibly breaking.
Configuration Monitoring
Organizations MUST track and monitor changes to development and deployment configurations.
Change control fails at the evidence step far more often than at the approval step. Running SELECT 'CR:12345' WHERE 1 = 0 before a change ties every subsequent statement in that session to the request that authorised it — no agents, no application changes, no database configuration. Schema and configuration changes are captured as they happen, so an unapproved DDL is visible rather than discovered at the next review.
Security Metrics
REQUIRES collecting and publishing security metrics including audit log analysis.
A record of processing is only as good as the layer producing it. Real-time SQL auditing captures every statement against the data — the identity, the session, the client, the objects touched, the outcome — with no nightly batch window where activity goes unrecorded. Classification is what makes that a record of *regulated* data rather than a log of everything: it tells you which tables are in scope, so the register describes the processing you actually have to declare. Policy templates then produce it in the shape the framework asks for, instead of leaving you to assemble it from raw logs the week before an inspection.
What BSIMM12 covers
This instrument defines no data category of its own. A descriptive study of what software security programmes do. It measures activities, has no pass mark, and defines nothing about data.
How BSIMM12 is enforced
Every figure below is the ceiling the instrument publishes about itself, not a prediction of what anything would cost. Enforced by Nobody. It is an observational study, not a standard to be met.
A voluntary standard. No regulator enforces it.
BSIMM describes what a set of real software security programmes actually do, and scores yours against that distribution. There is no pass mark, no certificate, and no assessor with authority over you. It is a mirror, not a bar.
Treating a descriptive model as a compliance target is a common category error. A low score is information, not a finding.
Enforcement data reviewed August 2026. Several figures are indexed annually and move.
Built for BSIMM12,
not configured for it afterwards
DevSecOps Audit Policy
Monitor development lifecycle and source-code database access
BSIMM Assessment Evidence
Binary and code provenance logs for security assessment
Development Data Patterns
Identify source code, build artifacts, and secrets
Unauthorized Code Access
Alert on access to code repositories outside authorized patterns
Other Security frameworks
Walk into the BSIMM12 audit knowing the answer
228 cited requirements across 57 frameworks are mapped to the controls that evidence them. A fixed-fee gap assessment tells you which of them you can already prove today.