Frequent API updates create governance gaps in CI/CD security

At a glance

What this is: Salt argues that frequent API updates create a governance gap when CI/CD pipelines do not keep pace with testing, monitoring, and decommissioning.

Why it matters: This matters because API change velocity can weaken access control and lifecycle governance, which affects both application security and any NHI or token-based access that depends on those APIs.

By the numbers:

• Only 13% of organizations update their APIs daily.

Context

Frequent API updates are not just a release-management issue. They create a security governance problem when new endpoints, changed authorisation logic, and retired interfaces all move faster than the controls meant to verify them. In CI/CD environments, that gap can turn routine delivery into repeated exposure of sensitive data and access paths.

The identity angle is real because APIs often carry service credentials, delegated access, and machine-to-machine trust. When lifecycle controls are weak, the result is not only insecure code but unmanaged access boundaries for workloads, integrations, and tokens that continue to operate after the API changes around them.

Key questions

Q: Where does API security fail when release cycles move faster than testing?

A: It fails when teams assume a deployed API is still the same one they reviewed. Frequent updates can change object access, authentication, and endpoint exposure between checks, so periodic testing misses real production risk. The fix is to move validation into the CI/CD pipeline and verify each change before release.

Q: Why do shadow and zombie APIs increase security risk so quickly?

A: They extend machine-to-machine trust beyond the inventory and ownership controls that normally constrain access. Once an endpoint is no longer clearly owned, monitored, or retired, it can continue processing data without the same scrutiny as active services. Attackers exploit that gap because it often persists unnoticed for months.

Q: What do security teams get wrong about API authorisation?

A: They often secure the endpoint while ignoring the data returned by that endpoint. If the application returns full objects instead of purpose-specific fields, authorisation becomes too coarse to protect sensitive data. Effective control requires response filtering, data minimisation, and tests that catch unintended payload expansion.

Q: When should organisations prioritise API decommissioning over adding more monitoring?

A: When the main issue is endpoint sprawl and stale access paths, decommissioning should come first. Monitoring cannot fully compensate for an endpoint that should not exist, especially when retired APIs still carry permissions or outdated authentication logic.

Technical breakdown

Why rapid API change breaks security assumptions

APIs in CI/CD pipelines change faster than most assurance processes can track. Every deployment can alter request paths, object exposure, authentication logic, or downstream integrations, which means a control set based on periodic scans quickly becomes stale. Security as code helps because it places policy checks inside the delivery pipeline, but the real mechanism is continuous verification at build, test, and release stages. Without that, teams assume the API they approved is the same API that reaches production, which is often false.

Practical implication: Embed security checks into the pipeline itself so that every change is evaluated before release.

How shadow and zombie APIs expand the attack surface

Shadow APIs are undocumented interfaces that evade normal inventory and monitoring, while zombie APIs are retired or replaced endpoints that remain active. Both are dangerous because they often keep old authentication paths, residual permissions, or weak configurations long after the business has moved on. In practice, these endpoints persist because ownership is unclear and decommissioning is treated as optional rather than a lifecycle control. That turns API sprawl into an access-control problem as much as a discovery problem.

Practical implication: Maintain continuous discovery and formal retirement checks so inactive endpoints are removed, not merely ignored.

Why BOLA and excess data exposure are recurring failure modes

Broken object-level authorisation happens when an API lets a caller access objects it should not see, often because the endpoint validates identity but not object ownership. Excessive data exposure happens when responses return more fields than the client needs, which becomes worse when test coverage is rushed. These are not abstract app bugs. In fast CI/CD flows, they are repeatable governance failures because release pressure narrows the time available to verify authorisation logic and response minimisation.

Practical implication: Test authorisation and response shape explicitly, not just login success, before each release.

Threat narrative

Attacker objective: The attacker wants unauthorised access to data or functions exposed by an API that the organisation failed to govern across its lifecycle.

1. Entry occurs through a newly deployed or forgotten API endpoint whose exposure was not caught during CI/CD testing.
2. Credential or authorisation abuse follows when the endpoint accepts requests that bypass object-level access checks or rely on outdated auth logic.
3. Impact occurs when attackers use the live endpoint to retrieve sensitive data or exploit residual access in production.

Breaches seen in the wild

• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

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 lifecycle governance is now part of identity governance. When APIs carry service credentials and delegated access, change control is no longer only about code quality. It becomes a question of who or what can still authenticate after the endpoint has changed, which is why API lifecycle and NHI governance increasingly converge. Practitioners should treat API retirement, credential scope, and access review as one governance chain.

Shadow and zombie APIs are a governance failure, not just an inventory problem. Undocumented endpoints survive because organisations do not enforce ownership across the full API lifecycle. That creates a persistent trust boundary that nobody is actively defending, and it often leaves machine credentials or legacy auth paths in place. Practitioners should connect discovery to enforced decommissioning, not discovery alone.

Frequent release cycles expose the limits of periodic security review. The core weakness is the assumption that security can be checked after deployment and still be timely. In CI/CD, that assumption fails as soon as endpoints, authorisation rules, and integrations change between review windows. Practitioners should move assurance into the pipeline and make continuous validation the default control model.

BOLA is a policy failure as much as an application flaw. Broken object-level authorisation is often the visible symptom of missing object ownership rules, weak testing discipline, and incomplete API policy enforcement. The governance lesson is that authorisation must be tested at the resource level, not inferred from successful authentication. Practitioners should align API testing with the actual access decisions the business relies on.

Frequent API change creates what we would call API governance debt. Each unreviewed update adds another layer of uncertainty around exposure, ownership, and access scope. That debt compounds when decommissioning is delayed and monitoring remains static, because the organisation is managing yesterday’s API map against today’s traffic. Practitioners should reduce that debt through continuous discovery, policy testing, and lifecycle retirement controls.

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

What this signals

API governance debt: frequent releases create a backlog of unreviewed endpoints, auth rules, and residual permissions that security teams cannot clear with periodic assessment alone. The programme implication is straightforward: discovery, policy enforcement, and retirement must run continuously, not as separate projects.

The strongest control response is to bind API inventory, authorisation testing, and decommissioning into one operating model. Where APIs also carry service credentials or delegated access, that model should be treated as part of NHI governance, because stale endpoints often preserve stale trust.

Security teams should expect the hardest failures at the seams between development, identity, and operations. That is where CI/CD speed, access scope, and lifecycle ownership collide, and where a governance gap becomes a breach path.

For practitioners

• Embed security as code in the CI/CD pipeline Add policy checks for authentication, authorisation, schema validation, and risky configuration at each stage of delivery so insecure API changes never reach production.
• Continuously discover and classify live APIs Use automated discovery to identify shadow and zombie endpoints, then assign owners and risk ratings so unmanaged interfaces do not remain outside governance.
• Test object-level authorisation before release Build API-specific tests that verify object ownership, response filtering, and access scope rather than relying only on login or endpoint availability checks.
• Formalise API decommissioning Require removal of retired endpoints, revocation of residual permissions, and validation that old authentication paths are disabled before the service is considered closed.
• Prioritise high-risk endpoints for runtime monitoring Score APIs by recent change, sensitive data exposure, and traffic anomalies so monitoring effort follows the endpoints most likely to fail under release pressure.

Key takeaways

• Frequent API updates can create a control gap when testing, monitoring, and decommissioning do not keep pace with delivery.
• The main failure pattern is not just weak code, but unmanaged endpoints and residual access that stay live after business ownership has moved on.
• The most effective response is continuous lifecycle governance, with pipeline checks, discovery, and retirement controls tied to the same operating model.

Key terms

• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Zombie API: A zombie API is a deprecated or abandoned interface that remains accessible after the organisation believes it should be retired. It is risky because old permissions, secrets, or backend trust can survive the business purpose, turning legacy access into an active exposure.
• 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.
• API Governance Debt: API governance debt is the accumulation of weak, inconsistent, or missing controls around how APIs are designed, approved, documented, secured, and retired. It creates hidden risk over time. Technically, it includes gaps in authentication, authorization, versioning, inventory, ownership, logging, and policy enforcement that make APIs harder to trust and govern.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is a practical way for security practitioners to connect access governance with machine identity and lifecycle control.