Why do CI/CD pipelines create outsized risk in application security programs?

Why This Matters for Security Teams

CI/CD pipelines are a concentration point for code, credentials, approvals, and deployment authority, which makes them a high-value target for both application attackers and supply chain adversaries. A weakness in a pipeline can bypass many of the controls that teams rely on later in the lifecycle, including code review, testing, and production change management. That is why application security cannot treat CI/CD as a supporting toolset; it is part of the attack surface and the trust boundary.

Security teams often focus on the application artifact and miss the systems that build it. If an attacker can modify pipeline logic, abuse a service token, or tamper with an artifact repository, they may not need to exploit the application itself. Current guidance from the NIST Cybersecurity Framework 2.0 supports treating this as a governance and protection problem, not just a DevOps efficiency issue.

In practice, many security teams encounter pipeline abuse only after a trusted deployment path has already been used to move malicious changes into production, rather than through intentional control design.

How It Works in Practice

CI/CD pipelines create outsized risk because they centralise privileged actions that would otherwise require manual intervention. A single pipeline can pull code, fetch dependencies, build images, sign artefacts, push to registries, run tests, and deploy to multiple environments. Each of those steps can introduce a separate trust dependency, and each dependency can be abused if identity, secrets, or approvals are weakly controlled.

For application security programs, the practical focus should be on the pipeline’s identity model, secret handling, artefact integrity, and promotion rules. That includes service accounts with narrowly scoped permissions, short-lived credentials where possible, protected branches, signed commits or attestations, and separation between build and deploy privileges. Security review also needs to cover third-party actions, reusable workflow templates, and dependency sources because modern pipelines often inherit trust from external components.

• Restrict who can modify pipeline definitions and shared build templates.
• Store secrets in dedicated secret managers, not in pipeline variables or repository settings.
• Require artefact signing and verification before promotion to higher environments.
• Log build, approval, and deployment events into monitoring and incident response workflows.

The control goal is to make pipeline abuse visible and difficult, not to assume that automated delivery is inherently safe. Mapping these practices to the NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it forces teams to separate access control, configuration management, and system integrity responsibilities. These controls tend to break down when the same account can change pipeline code, approve releases, and access production secrets because one compromise then spans the entire delivery chain.

Common Variations and Edge Cases

Tighter pipeline controls often increase operational overhead, requiring organisations to balance delivery speed against assurance and traceability. That tradeoff becomes more visible in fast-moving engineering environments, where teams want rapid releases but also need stronger separation of duties.

Best practice is evolving for ephemeral runners, infrastructure-as-code pipelines, and GitOps-style deployment models. In those environments, the main risk may shift from a traditional build server to the identity used by the runner, the permissions on the control plane, or the trust placed in automation tokens. There is no universal standard for this yet, so teams should document their own assumptions about who can modify workflow logic, approve releases, and rotate secrets.

There is also a real edge case when pipelines are multi-tenant or shared across business units. Shared tooling can improve consistency, but it can also create blast-radius problems if one project inherits another project’s permissions or build artefacts. For that reason, application security reviews should examine the pipeline as a governed production system, not just as an engineering convenience.

Related resources from NHI Mgmt Group

• Why do undiscovered APIs create outsized risk in application security programs?
• Why do misinterpreted exit codes create security risk in CI/CD pipelines?
• Why do install-time payloads in CI/CD environments create outsized risk for cloud and identity security?
• Why do untested security tools create more risk in CI/CD pipelines?