Notifications
Clear all
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.
NHIMG editorial — 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, but 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.
- Only 12% run a security scan on every code commit.
Questions worth separating out
Q: How should security teams implement API security testing in CI/CD pipelines?
A: Start by automating the endpoints that carry privileged actions, sensitive data, or access decisions.
Q: When does a CI/CD pipeline become a security risk?
A: A CI/CD pipeline becomes a security risk when it can accept unverified code, expose signing keys, or promote artifacts without strong controls on who approved the change.
Q: What breaks when API security testing stops at build time?
A: You miss stateful flaws that only appear when real users, roles, and request sequences interact with the live service.
Practitioner guidance
- Implement commit-level secret scanning Run secrets detection on every commit, not on a weekly schedule, and fail the pipeline when credentials appear in source, logs, or generated files.
- Scope pipeline identities to single-purpose roles Review CI runners, deployment service accounts, and workflow identities as non-human identities with narrowly defined permissions.
- Use policy-as-code gates before deployment Apply checks for insecure YAML, exposed tokens, weak authentication patterns, and overly permissive infrastructure definitions before code reaches staging or production.
What's in the full article
Equixly's full blog post covers the operational detail this post intentionally leaves for the source:
- Stage-by-stage implementation guidance for SAST, SCA, SBOM, IaC scanning, and API testing in the pipeline
- How to wire deployment gates to severity thresholds without blocking every release
- Runtime monitoring patterns for authentication, abuse detection, and post-release validation
- Practical examples of how Equixly fits into preview, staging, and production environments
👉 Read Equixly's guide to API security in CI/CD pipelines →
API security in CI/CD pipelines: are your controls keeping up?
Explore further
19/08/2026 4:12 pm
API security in CI/CD is now an identity governance problem, not just a testing problem. The article’s core message is that pipeline controls fail when teams treat scans as the control rather than the signal. CI runners, service accounts, and deployment tokens are non-human identities with authority, so their scope, rotation, and observability must be governed like any other privileged identity. The practitioner conclusion is simple: if the pipeline can deploy code, it can also deploy risk.
A question worth separating out:
Q: Who is accountable when API access controls fail?
A: Accountability should sit with the team that owns the API lifecycle, including design, deployment, access scope, and retirement. Security may set policy, but engineering and product owners must own the data and behaviour exposed by each interface. Without explicit ownership, APIs tend to outlive their controls and inherit stale permissions.
👉 Read our full editorial: API security in CI/CD exposes the gap between scanning and control
