Most vault programs track only the credentials already onboarded, producing a numerator without a denominator. Vault coverage — unique credentials matched to a managed vault divided by all credentials detected across connected systems — is the missing metric that lets IAM and Security teams measure actual policy compliance. GitGuardian detects credentials across source control, CI/CD, cloud, and collaboration tools, deduplicates them by value using hashed fingerprints, and reconciles them against connected vaults without storing the actual secrets. This surfaces three risk states: vaulted and contained, vaulted but copied elsewhere, and never vaulted. The metric supports PCI DSS 4.0 compliance (enforced from March 2025), executive reporting, and remediation prioritization. GitGuardian's 2025 research found 28.6 million new hardcoded secrets on public GitHub, with 64% of secrets confirmed valid in 2022 still valid years later.
Table of contents
Who owns vault coverage in your organizationWhy secrets end up outside the vaultHow to measure vault program effectivenessHow to calculate vault coverageWhy a vaulted secret can still be exposedWhy vault coverage matters for compliance and the boardHow to report vault coverage to executivesCommon Questions About Vault CoverageQuestions this post answers
How do I calculate vault coverage for my secrets management program?
Vault coverage equals unique credentials matched to a managed vault divided by unique credentials detected across all connected sources. The numerator comes from your vault inventory; the denominator requires active discovery across source control, CI/CD pipelines, cloud environments, and collaboration tools, since credentials move through engineering systems without a central registration event. A credential appearing in multiple locations counts once after deduplication. Teams tracking machine credential risk across sprawling environments follow vault coverage discussions like this on daily.dev.
Can a secret stored in a vault still be exposed?
Yes. A credential correctly stored in a vault such as Azure Key Vault or Delinea Secret Server can still carry risk if an active plaintext copy exists in a code repository, CI/CD variable, or Kubernetes manifest. Vault storage and containment are separate states. IAM teams should review vault coverage alongside the unmanaged-copy rate to distinguish credentials that are vaulted and contained from those that are vaulted but still copied elsewhere. Developers remediating credential sprawl alongside vault adoption track these distinctions on daily.dev.
When did PCI DSS 4.0 enforcement of hardcoded credential requirements start?
PCI DSS 4.0 policy on hardcoded application and system account credentials began being enforced in March 2025. A discovery-based vault coverage metric can support a PCI DSS assessment, and the list of unmatched credentials behind that metric can drive remediation. A raw stored-secret count alone cannot confirm whether an organization has met those standards. Security engineers navigating PCI DSS 4.0 credential requirements stay current on daily.dev.