What breaks when manual code review is the main control for CI/CD security?

Manual review breaks down when release volume, dependency churn, and attacker speed exceed human capacity. It cannot reliably catch malicious packages, risky workflow changes, or privilege misuse before execution. In practice, teams end up approving too much by exception, which leaves the pipeline exposed and makes remediation slower after a compromise is already in motion.

Why This Matters for Security Teams

Manual code review is useful, but it is a weak primary control for CI/CD security because it depends on human attention, context, and time. That creates a mismatch with modern delivery pipelines, where code, dependencies, build steps, and secrets can change many times a day. Security teams often assume reviewers will notice malicious intent, but the more common failure mode is that risky changes look routine enough to pass.

This matters because CI/CD is not just source code. It includes workflow definitions, build runners, package registries, signing keys, tokens, and deployment permissions. If review is the main gate, then the control is only as strong as the person reviewing the smallest diff under the most pressure. Current guidance from the NIST Cybersecurity Framework 2.0 emphasises risk-based protection and continuous improvement, which is a better fit than relying on one human checkpoint alone.

Practitioners also underestimate how often attackers target the process rather than the application. A harmless-looking workflow edit, dependency substitution, or token exposure can be enough to turn a secure repository into a compromised delivery path. In practice, many security teams encounter CI/CD abuse only after a pipeline has already executed untrusted code, rather than through intentional pre-deployment detection.

How It Works in Practice

Manual review can still play a role, but it should be one layer in a broader control stack. The goal is to automate high-confidence checks, reserve human review for exceptions, and make dangerous changes harder to approve without extra scrutiny. That usually means treating pipeline security like a supply chain problem, not just a code-quality problem.

At a minimum, teams should combine review with branch protection, signed commits or attestations, dependency scanning, secret scanning, and policy enforcement on workflow files. Build and deploy permissions should be limited to the smallest possible set of identities, including human users and Non-Human Identities that operate CI/CD tooling. Where privileged automation exists, it should be governed like any other high-value identity. This is where NHI controls and zero trust principles from NIST SP 800-207 become directly relevant.

• Use automated scanning for dependencies, secrets, IaC, and workflow syntax before review.
• Require protected approvals for changes to build, deploy, and release paths.
• Separate duties so the person who writes pipeline logic is not the only approver.
• Validate provenance for artifacts and package sources before execution.
• Monitor runner behaviour, token use, and permission escalation as detection signals.

For teams that manage software supply chain risk more formally, the CISA software bill of materials guidance is a useful reference point for dependency visibility, while OWASP CI/CD Security guidance helps translate the controls into pipeline design choices.

These controls tend to break down when organisations run highly dynamic monorepos with self-hosted runners, broad maintainer access, and no enforced policy layer, because review becomes too slow to stop changes that execute automatically.

Common Variations and Edge Cases

Tighter CI/CD control often increases delivery friction, requiring organisations to balance release speed against the risk of unauthorised pipeline changes. That tradeoff is real, especially for engineering teams that ship frequently or rely on ephemeral build infrastructure. Best practice is evolving, but there is no universal standard that says manual review alone is sufficient for any mature pipeline.

Some environments still rely heavily on manual approval because they have low release volume, simple build paths, or strong segregation between developers and operators. Even then, review should focus on exceptional changes, such as modifications to workflow files, signing processes, package sources, or secret-handling logic. Routine application code should be supported by automated checks that are consistent, repeatable, and difficult to bypass.

The biggest edge cases arise when the pipeline itself is part of the attack surface. Self-hosted runners, reusable workflows, third-party actions, and injected build credentials can all create privilege pathways that a reviewer may not recognise from the diff alone. Where agentic automation is involved, the identity and permissions of the tool-consuming process matter as much as the code it runs. In those cases, organisations should treat pipeline identities, credentials, and execution rights as governed assets rather than implementation details. The NIST AI Risk Management Framework is also relevant where automated code generation or AI-assisted change production feeds directly into release workflows.

Manual review is most defensible when it is narrow, high-signal, and backed by technical enforcement. It is least effective when used as a substitute for policy, provenance, and continuous control.

Related resources from NHI Mgmt Group

• What breaks when teams rely only on code review and CI to confirm a security patch worked?
• What breaks when secrets are stored in code and CI/CD tools?
• What breaks when perimeter security is treated as the main trust control?
• What breaks when identity logging is treated as the main security control?