Topic starter
18/08/2026 2:50 pm
TL;DR: Breached accounts rose nearly eight times year over year in 2024, and more than 1.4 billion records were breached globally in May 2025, according to Probely, but the deeper issue is that security scans are still too often treated as one-off checkpoints rather than continuous pipeline controls. CI/CD security fails when governance is bolted on after development instead of being embedded across commit, build, and deployment stages.
Editorial analysis by NHI Mgmt Group, based on content published by Probely: “Next-Level CI/CD: Embedding Security in Your DevOps Journey”.
By the numbers:
- In May 2025, more than 1.4 billion records were breached globally.
Key questions
Q: How should teams stop treating CI/CD security as a one-time scan problem?
A: Treat CI/CD security as a continuous control problem.
Q: Why do CI/CD pipelines create secret governance risk?
A: Because they combine stored credentials, automated execution, and broad operational access in one place.
Q: What breaks when security scans are only run late in the delivery cycle?
A: When scans happen late, teams discover vulnerabilities after code has already moved far through the pipeline.
Practitioner guidance
- Embed security checks at every pipeline stage Move from one-off scanning to automated checks at commit, build, test, and deploy so risk is evaluated where it appears.
- Inventory and scope pipeline identities List every service account, token, certificate, and runner credential used in delivery, then assign a clear owner and minimum required privilege.
- Shorten the lifetime of delivery credentials Replace long-lived pipeline secrets with tightly scoped, revocable credentials that expire as soon as the workflow step ends.
Bottom line: CI/CD security fails when teams rely on isolated scans instead of continuous controls across the delivery pipeline.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:32 pm
Secure CI/CD is fundamentally a governance problem, not a tool-selection problem. The article is right to separate capability from control: scanning tools do not create security if they are used as periodic checkpoints. What matters is whether the pipeline has enforced ownership, scoped access, and continuous validation across commit, build, test, and release. Practitioners should judge CI/CD security by control coverage, not by how many tools are installed.
A few things that frame the scale:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
A: They should review whether the added component changes access scope, secret exposure, or the provenance of the build path. A trusted integration can still widen blast radius if its permissions are excessive or if its behavior changes unexpectedly. The control question is who can act, what they can reach, and how quickly access can be revoked.
👉 Read our full editorial: Secure CI/CD integration is a control problem, not a tooling problem