• Home
  • BVSSH
  • Engineering Enablement
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Percentage of Services Scanned

Description

Percentage of Services Scanned measures the proportion of production and pre-production services that are regularly scanned for vulnerabilities, misconfigurations, or security risks using automated tools. It’s a foundational metric for assessing your security coverage and identifying potential blind spots.

This metric helps ensure your systems are proactively assessed for known risks—rather than waiting for incidents or third-party disclosures.

How to Use

What to Measure

  • % of services (e.g. APIs, microservices, applications, infrastructure) scanned with one or more automated tools (e.g. SAST, DAST, SCA, container scanners).
  • Segment by environment (e.g. production, staging) or service criticality.

Formula

Percentage of Services Scanned = (Number of Services Regularly Scanned / Total Number of Services) x 100

Instrumentation Tips

  • Maintain a complete service inventory with tagging for criticality and ownership.
  • Integrate scanning tools into build and deploy pipelines.
  • Set scan frequency thresholds (e.g. weekly, per deployment) to define "regular."

Why It Matters

  • Risk visibility: Unscanned services can contain critical vulnerabilities or misconfigurations.
  • Security baseline: Provides a measurable floor for secure development practices.
  • Audit & compliance: Demonstrates due diligence in vulnerability management.
  • Shift-left readiness: Shows how security tooling is integrated into pipelines and developer workflows.

Best Practices

  • Automate scans in CI/CD with clear fail/pass thresholds and feedback loops.
  • Apply different scan types (e.g. SAST, DAST, SCA, infra scans) based on service type.
  • Track coverage over time and include it in team dashboards and OKRs.
  • Set coverage goals and address gaps as part of engineering planning.
  • Pair scans with triage processes and SLAs for remediation.

Common Pitfalls

  • Incomplete or outdated service inventory leads to inaccurate coverage.
  • Scanning only the most visible or high-traffic services.
  • No alerting or follow-up process after vulnerabilities are found.
  • Scans are run but ignored (e.g. no integration with backlog or SRE).

Signals of Success

  • All critical services scanned regularly with results tracked and addressed.
  • Scan coverage is part of SDLC health checks and release readiness.
  • Developers engage with results and remediation is timely.
  • Vulnerability discovery rate declines over time while scan coverage rises.

Related Measures

  • [[Compliance Coverage]]
  • [[Vulnerability Detection Rate]]
  • [[Secrets Exposure Rate]]
  • [[Time to Remediate Vulnerabilities]]
  • [[Access Review Coverage]]

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering