Notifications
Clear all
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.
NHIMG editorial — based on content published by Probely: Next-Level CI/CD: Embedding Security in Your DevOps Journey
By the numbers:
- Breached accounts rose nearly eight times year over year in 2024.
- More than 1.4 billion records were breached globally in May 2025.
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
Q: How should security teams govern credentials used by CI/CD pipelines?
A: Security teams should treat CI/CD credentials as production-grade machine identities and apply least privilege, short lifetimes, and continuous monitoring.
Q: Why do CI/CD pipelines create non-human identity risk?
A: CI/CD pipelines create non-human identity risk because they authenticate to other systems, carry secrets, and perform privileged actions automatically.
Q: What do teams get wrong about securing CI/CD integration?
A: The common mistake is assuming that one secure check early in the pipeline makes the whole delivery chain safe.
Practitioner guidance
- Separate build, sign, and deploy privileges Split pipeline permissions so no single job can both create and release production artefacts.
- Inventory every pipeline secret and token Map each credential to a workload owner, use case, expiry date, and revocation path.
- Apply short-lived credentials to automation paths Replace long-lived API keys and deployment tokens with ephemeral credentials wherever the platform supports them.
What's in the full article
Probely's full article covers the operational detail this post intentionally leaves for the source:
- Specific examples of where SAST, DAST, and dependency checks fit into a CI/CD workflow
- A step-by-step view of how to assess current pipeline gaps before choosing controls
- Practical guidance on making security part of the build process without disrupting delivery
- The article's discussion of Snyk API & Web integration and how it fits existing workflows
👉 Read Probely's analysis of secure CI/CD pipeline integration →
Secure CI/CD integration: where do security controls break down?
Explore further
18/08/2026 3:32 pm
CI/CD security is an identity governance problem disguised as tooling hygiene. The article is right that scanning alone is insufficient, but the deeper issue is that pipelines depend on service identities, secrets, and deployment permissions that need lifecycle control. From an NHI perspective, each pipeline token is a non-human identity with scope, owner, expiry, and revocation obligations. Practitioners should stop treating CI/CD as a build concern and start treating it as a governed identity surface.
A question worth separating out:
Q: How do teams know if agentic CI/CD controls are actually working?
A: Look for evidence that the agent cannot reach secrets, cannot mutate protected branches, and cannot execute shell commands outside its declared boundary. If telemetry shows attempted outbound calls, credential access, or policy violations being blocked or alerted on, the control is operating. If you only see clean workflow files, you do not yet know whether runtime guardrails are effective.
👉 Read our full editorial: Secure CI/CD integration is a control problem, not a tooling problem
