API security in CI/CD exposes the gap between scanning and control

At a glance

What this is: This article argues that API security in CI/CD fails when teams rely on periodic scanning instead of continuous controls across code, build, test, and release stages.

Why it matters: For IAM and NHI practitioners, the key issue is that pipeline identities, secrets, and token-scoped API access can become production risk when governance is applied late or unevenly.

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.
• 34 studies on API security in CI/CD pipelines identified four core defensive strategies.

Context

API security in CI/CD is a governance problem as much as a testing problem. The pipeline is where code, credentials, identity scopes, and deployment changes converge, so any gap in control timing can move a defect from source into production.

In this article, Equixly focuses on the mismatch between organisations that say they have adopted API security and the smaller subset that validate it continuously. That matters because pipeline identities, secret handling, and runtime authorisation are all part of the same control chain, not separate tasks.

The pattern is typical of modern DevSecOps programmes: broad adoption at the policy level, uneven execution in the operational layer.

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. In practice, that means broken object-level authorization, overexposed fields, and forgotten endpoints can reach production and stay there long enough to be exploited. The failure is not only technical. It is governance drift between development speed and control coverage.

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. That creates a larger blast radius if a token, workflow, or runner is compromised. Least-privilege identity design reduces the attacker’s ability to reuse pipeline trust against APIs, secrets, or deployment infrastructure.

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. In practice, developer laptops and CI runners are rich credential stores, and tokens that remain valid for long periods are ideal for republishing, impersonation, and downstream access. Secrets should be governed like privileged access, not cache data.

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.

Technical breakdown

Access control for CI runners and deployment identities

CI/CD pipelines depend on service accounts, runner identities, deployment roles, and API gateway permissions. If those identities are over-scoped, a compromise in one stage can become a release-channel compromise. Least privilege matters here because pipeline components often act on behalf of developers, build systems, and deployment automation at the same time. The article highlights over-permissioned GitHub Actions workflows and misconfigured IAM roles in cloud runners as recurring weaknesses. In practice, the security question is not whether the pipeline has identities, but whether each one is bound to a narrow task, a narrow environment, and a narrow time window.

Practical implication: map every pipeline identity to a specific task and remove permissions that are not required for commit, build, test, or deploy.

Secrets management and token exposure in the pipeline

API keys, tokens, and passwords become exploitable the moment they appear in code, scripts, logs, or environment variables. A vault reduces exposure, but it does not solve every leak path because secrets can still be committed, echoed, copied into third-party actions, or reused by machine identities that should not receive them. That is why the issue is not just storage, but lifecycle control around issuance, injection, and revocation. In NHI terms, a secret is a machine credential with a scope problem, not merely a hidden string. The safer pattern is runtime injection with strict provenance and short-lived access.

Practical implication: treat every pipeline secret as an NHI credential with explicit scope, runtime delivery, and immediate revocation paths.

Runtime validation catches API behaviour scanners miss

Build-time checks are useful, but they do not prove how an API behaves under real user states, multi-step workflows, or changing authorisation context. That is where logic flaws such as broken object level authorisation become visible. Traditional scans often inspect endpoints in isolation, while stateful testing exercises sequences of requests, roles, and sessions. The article also points out that undocumented shadow APIs and deprecated zombie APIs can evade static inventory and still remain reachable. Continuous runtime validation therefore closes the gap between declared security and observed behaviour.

Practical implication: validate authorisation and request sequences against live API behaviour, not only against static specifications.

Threat narrative

Attacker objective: The attacker aims to turn pipeline trust into production API access, secrets exposure, and control over deployment behaviour.

1. Entry begins when exposed API credentials, over-permissioned pipeline identities, or misconfigured runners create a path into the CI/CD environment.
2. Credential access follows through leaked tokens, hardcoded secrets, or credentials printed in logs and then reused against deployment or API endpoints.
3. Escalation occurs when the attacker uses that trust to alter pipeline behaviour, reach hidden endpoints, or trigger deployments with elevated permissions.
4. Impact is the release of insecure APIs into production, with potential misuse of tokens, authorisation bypass, and persistence through undetected workflow changes.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Continuous validation matters because API risk is behavioural, not just structural. Static scanning can confirm that a specification, secret store, or policy file exists, but it cannot prove how the API behaves across user states, request sequences, or hidden endpoints. That is the verification gap this article exposes: security posture collapses when teams assume declared controls equal operational controls. Practitioners need runtime evidence that authorisation and token handling still hold after each release.

Secret leakage in CI/CD is a lifecycle failure, not a vault failure. The strongest signal in the article is that secrets still escape through code, logs, third-party actions, and machine reuse even when teams deploy vault tooling. The named concept here is pipeline secret spillover, where the real failure is uncontrolled propagation around the vault boundary. Practitioners should govern how machine credentials move, not only where they are stored.

API security programmes will keep underperforming until they connect pre-deploy checks to post-deploy evidence. The article makes clear that weekly or daily scans are not enough when endpoints, authentication logic, and traffic patterns change with every release. In governance terms, the control problem is continuity: if testing stops at deployment, the organisation is blind to the state changes that introduce risk. Practitioners should align CI/CD controls with live validation and incident workflows, not treat testing as a one-time gate.

From our research library:

• 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.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Pipeline identity scope is now a control boundary, not an implementation detail. When runners, service accounts, and deployment roles carry more privilege than a single pipeline stage needs, compromise spreads from build activity into release authority. Practitioners should expect access review, secret governance, and deployment controls to converge around the pipeline identity layer.

Pipeline secret spillover: the real risk is not whether a vault exists, but whether credentials escape around it through code, logs, third-party actions, or reused machine identities. That means secret governance has to extend across issuance, injection, revocation, and observability, or the vault becomes only one containment point in a wider exposure path.

For practitioners

• 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.
• Validate live API authorisation flows Run stateful tests against preview, staging, and production traffic so broken object level authorisation and hidden endpoints are verified in context.

Key takeaways

• 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.
• The article’s core evidence shows a wide adoption gap between organisations that claim API security integration and those that validate every commit or every release.
• The practical fix is to govern identities, secrets, policy checks, and runtime authorisation as one pipeline control chain rather than separate security activities.

Key terms

• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Stateful API Testing: Stateful API testing exercises real request sequences, session changes, and user roles instead of checking endpoints one by one. It is useful when security depends on workflow context, because many authorisation flaws and hidden behaviours only appear after multiple related calls.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programme that builds, ships, and runs modern systems.