Teams often treat security coverage as a one-time rollout rather than a living capability that must match changing stacks and pipelines. The article argues that coverage should be measured across the engineering workflow, including repositories, languages, technologies, and third parties. A common mistake is relying on after-the-fact review instead of embedded detection and remediation.
Coverage is not the same as a checklist
Security coverage in CI/CD is often misread as “do we have the tool installed?” That misses the real question: whether security controls actually follow the engineering path as repositories, languages, build systems, package managers, deployment targets, and third-party dependencies change. Coverage should be measured by where security checks are embedded, where they are bypassed, and where they fail to keep pace with delivery.
A useful way to think about it is to measure coverage against the workflow, not against a one-time implementation event. If a team ships in multiple languages, uses different build runners, or relies on external actions and packages, each of those paths needs visibility. That is why pipeline coverage is closer to an operating property than a project milestone.
Teams also need to distinguish breadth from depth. A control can be present in every repository and still provide poor coverage if it only runs at the end of the pipeline, misses critical dependency sources, or cannot surface findings early enough for developers to act on them. In practice, NHI Mgmt Group’s Ultimate Guide to NHIs is a useful reminder that many delivery systems still leave secrets exposed outside managed controls, which makes pipeline reach more important than tool count.
Where measurement usually goes wrong
One common error is measuring by adoption instead of effective enforcement. Teams report that a scanner, gate, or policy exists, then assume the pipeline is covered. That hides the real failure modes: skipped jobs, permissive exceptions, unsupported languages, shadow pipelines, and manual release paths that never touch the control at all.
Another mistake is using after-the-fact review as a proxy for coverage. Review can help, but it is not the same as embedded detection and remediation. If findings arrive after code has already merged or artifacts have already been promoted, the control is measuring exposure, not preventing it. Coverage metrics should therefore reflect whether the pipeline can block, warn, or route issues while the work is still actionable.
Teams should also avoid over-valuing a single security layer. SAST, dependency scanning, secrets detection, IaC analysis, and artifact verification each cover different failure surfaces. If one of those domains is missing from a meaningful portion of the workflow, the overall number can look strong while the actual control set is fragmented.
For provenance and supply-chain integrity, SLSA is a better lens than raw tool presence because it forces teams to ask whether build integrity, provenance, and tamper resistance are actually protected. That same logic applies to CI/CD coverage: the question is not whether a control exists somewhere, but whether it governs the paths that matter.
How practitioners should measure it instead
Measure coverage by mapping controls to the complete delivery path and then checking for blind spots. A practical view includes repository coverage, pipeline coverage, runtime coverage for deployment artifacts, and third-party coverage for external actions, packages, and services that enter the build. Coverage should be tracked per technology stack, not just per team, because different stacks create different security gaps.
What to prioritise: start with the places where an issue can create the most immediate blast radius, such as secret leakage, unsigned or unverified build inputs, and unsafe third-party integrations. Then expand to the rest of the workflow so you can compare coverage across paths rather than celebrating isolated wins.
What to verify: confirm that findings are surfaced before merge or promotion wherever possible, that exceptions are time-bound, and that failed controls are not silently bypassed in alternate pipelines. Coverage is credible only when you can prove the control still runs on the paths developers actually use.
Practitioner takeaway: the best coverage metric is one that exposes drift, bypasses, and unprotected workflow variants, not one that merely counts how many tools were turned on.
Related resources from NHI Mgmt Group
- What do security teams get wrong about AI agents in CI/CD pipelines?
- What do security teams get wrong about architectural reviews in CI/CD pipelines?
- What do security teams get wrong about workload identity in cloud and CI/CD environments?
- What do teams get wrong about software visibility in CI/CD pipelines?
