Every CISO eventually gets asked the same question by the board: "How does our security compare to our peers?" It is a reasonable question with no straightforward answer. Security maturity is not a single number, and comparing organizations with different architectures, threat models, and risk appetites requires nuance that a simple ranking cannot provide.
That said, benchmarking is valuable when done correctly. It reveals blind spots, justifies investments, and provides directional guidance for program development. The key is choosing the right framework, the right metrics, and the right peer group.
The Major Maturity Models
BSIMM (Building Security In Maturity Model)
BSIMM is an empirical model based on observations of real software security programs. It measures 122 activities across 12 practice areas, grouped into four domains: Governance, Intelligence, SSDL Touchpoints, and Deployment.
BSIMM's strength is that it is descriptive, not prescriptive. It tells you what other organizations are doing, not what you should be doing. The annual BSIMM report provides statistical data on activity adoption rates across industries, making it useful for peer benchmarking.
The limitation is that BSIMM participation requires a formal assessment by a licensed assessor, which is expensive and time-consuming.
OWASP SAMM (Software Assurance Maturity Model)
SAMM is a prescriptive model that defines maturity levels for 15 security practices across five business functions: Governance, Design, Implementation, Verification, and Operations. Each practice has three maturity levels with specific criteria.
SAMM is free, open source, and self-assessable. It provides roadmaps for improvement and is designed for organizations that want to build a program from scratch. The limitation is that self-assessments are subjective and difficult to compare across organizations.
Custom Frameworks
Many organizations build custom maturity frameworks tailored to their specific needs. These typically incorporate elements of BSIMM, SAMM, and NIST CSF, with industry-specific additions.
Custom frameworks are useful for internal tracking but poor for peer benchmarking because no two organizations measure the same things.
Choosing Your Peer Group
The most common benchmarking mistake is comparing against the wrong peers. A 50-person startup should not benchmark against a Fortune 500 bank. A healthcare company should not benchmark against a gaming studio. Meaningful benchmarks require peer groups matched on:
Industry. Regulatory requirements, threat landscapes, and risk appetites vary dramatically by industry. Financial services, healthcare, and defense have very different security expectations than retail, media, or education.
Organization size. Security budgets, team sizes, and program maturity correlate strongly with organization size. Benchmark against organizations of similar revenue and employee count.
Software intensity. A software company with 500 developers has a fundamentally different security challenge than a manufacturing company with 500 employees and 10 developers. The ratio of development to security staff matters more than absolute numbers.
Architecture complexity. Organizations running cloud-native microservices face different security challenges than those running monolithic on-premises applications. Benchmark against organizations with similar architectural patterns.
Metrics That Actually Matter
Maturity model scores provide a high-level picture, but operational metrics provide actionable benchmarking data. Focus on metrics that are:
- Objectively measurable (not based on self-assessment)
- Comparable across organizations (not dependent on unique architecture)
- Indicative of security outcomes (not just process compliance)
Vulnerability Management Metrics
Mean time to remediation (MTTR) by severity. How long does it take to fix a critical vulnerability from discovery to deployment? Industry benchmarks vary: financial services organizations typically target under 15 days for critical CVEs, while other industries may target 30 days.
Vulnerability escape rate. What percentage of vulnerabilities are discovered in production versus in pre-production environments? Lower escape rates indicate more mature shift-left programs.
SLA compliance rate. What percentage of vulnerabilities are remediated within the defined SLA? This measures process discipline, not just speed.
Supply Chain Security Metrics
SBOM coverage. What percentage of production applications have current, accurate SBOMs? Leaders in this area approach 100%. Most organizations are below 50%.
Dependency freshness. What percentage of dependencies are within one major version of the latest release? Stale dependencies accumulate vulnerabilities.
Known vulnerability exposure. At any given time, how many known vulnerabilities exist in your dependency tree? Track this as a density metric (vulnerabilities per project or per 1000 dependencies).
Process Metrics
Security testing coverage. What percentage of applications undergo SAST, DAST, SCA, and manual testing? Most organizations have strong SAST coverage but weak SCA and manual testing coverage.
Policy gate adoption. What percentage of CI/CD pipelines include automated security gates? Organizations with mature programs enforce gates on all pipelines.
Security training completion. What percentage of developers complete security training annually? This is a lagging indicator but useful for benchmarking program breadth.
Conducting the Benchmark
Step 1: Self-Assessment
Before comparing to peers, establish your baseline. Measure your current state against the chosen framework and collect operational metrics for the past 12 months. Be honest. Inflated self-assessments defeat the purpose.
Step 2: Data Collection
Gather peer data from:
- BSIMM annual reports (aggregated industry data)
- Verizon DBIR (breach statistics by industry)
- Industry-specific ISACs (Information Sharing and Analysis Centers)
- Vendor benchmark reports (Snyk, Synopsys, and Veracode publish annual state-of-security reports)
- Peer conversations (CISOs in the same industry often share metrics informally)
Step 3: Gap Analysis
Compare your metrics against peer benchmarks to identify gaps. Categorize gaps as:
- Critical gaps where you are significantly below peer median and the gap represents material risk
- Improvement opportunities where you are below peer median but the gap does not represent immediate risk
- Strengths where you are at or above peer median
Step 4: Roadmap Development
Translate gaps into a prioritized improvement roadmap. Focus on critical gaps first, and estimate the investment (budget, headcount, tools) needed to close each gap. Use peer benchmarks to justify the investment to leadership.
Common Pitfalls
Measuring activities instead of outcomes. Having a vulnerability scanning program is not meaningful if 80% of findings are never remediated. Measure outcomes (MTTR, escape rate) alongside process adoption.
Benchmarking too broadly. Global averages hide industry-specific patterns. A financial services company that benchmarks against the global average may feel good about its program while being significantly behind its actual peers.
Treating maturity as a destination. Maturity level 3 on a framework is not a finish line. The threat landscape evolves, and maturity must evolve with it.
Ignoring organizational context. A high-risk organization with low maturity needs rapid investment. A low-risk organization with moderate maturity may be appropriately resourced. Context determines whether a benchmark gap is urgent.
How Safeguard.sh Helps
Safeguard.sh provides the operational metrics that make benchmarking actionable: SBOM coverage rates, vulnerability remediation timelines, dependency freshness scores, and policy gate compliance across your portfolio. These metrics are collected automatically from your development pipeline, eliminating the manual data collection that makes benchmarking a quarterly chore. With continuous metric tracking, you can measure progress against peer benchmarks in real time rather than in annual snapshots.