Topic starter
19/08/2026 3:28 pm
TL;DR: API security is widely present in CI/CD pipelines, but most organisations still scan weekly or daily rather than on every commit, according to Equixly’s analysis of current DevSecOps practice. The security gap is not awareness, but inconsistent control application across access, secrets, policy, and runtime validation.
Editorial analysis by NHI Mgmt Group, based on content published by Equixly: “How to build API security into your CI/CD pipeline: A DevSecOps playbook”.
By the numbers:
- 63% of organisations have integrated API security into their CI/CD pipelines.
- Only 12% run a security scan on every code commit.
- 67% of small and medium-sized enterprises report that DevSecOps practices are highly effective at improving their security postures.
Key questions
Q: What breaks when API security is not built into CI/CD pipelines?
A: Teams lose the ability to catch authorization flaws, schema abuse, and unsafe configuration changes before release.
Q: Why do over-permissioned pipeline identities increase API risk?
A: CI runners, service accounts, and deployment roles often act with more privilege than the task requires.
Q: What do security teams get wrong about developer and CI secrets?
A: They often treat these secrets as operational conveniences instead of high-value identities.
Practitioner guidance
- Define pipeline identity boundaries Assign each CI runner, service account, and deployment role the smallest permission set needed for its exact stage and environment.
- Move secrets to runtime injection Deliver API keys and tokens from a secure vault at execution time, and block any secret from being embedded in code, YAML, logs, or third-party actions.
- Add commit-level secret scanning Scan every commit for hardcoded credentials and stop repository contamination before secrets can reach build logs or ephemeral environments.
Bottom line: API security in CI/CD fails most often when organisations treat scanning as a periodic task instead of a continuous control across commit, build, test, and release stages.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:12 pm
API security in CI/CD is really identity security at pipeline speed. The article shows that the pipeline is full of security-relevant identities, from runners to service accounts to deployment roles, and each one can widen blast radius if over-scoped. The governance problem is not whether controls exist, but whether the right identity boundaries are enforced at the moment credentials are issued and used. Practitioners should treat pipeline identity scope as a first-class control domain, not a by-product of DevOps automation.
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:
Q: How should teams validate API security before production release?
A: They should test live behaviour, not only static specifications, and they should do it across roles, request sequences, and changing states. That is the only way to catch logic flaws such as broken object level authorisation and hidden endpoints. Continuous validation gives release gates evidence they can actually trust.
👉 Read our full editorial: API security in CI/CD exposes the gap between scanning and control