What should organisations do when developers are shipping more code than security can review?

Why This Matters for Security Teams

When development throughput exceeds manual review capacity, the risk is not only missed findings. It is also inconsistent enforcement, delayed triage, and a widening gap between what policy says and what the delivery pipeline actually permits. For software-heavy organisations, this becomes a governance problem as much as a technical one. NIST Cybersecurity Framework 2.0 frames this as an ongoing risk management issue, not a one-time gate, which is the right lens for fast-moving engineering environments.

The practical failure mode is simple: security teams end up reviewing sampled changes while unsafe patterns continue to move through automated builds, dependency updates, and deployment workflows. That means the real control point shifts from human approval to pipeline design, identity trust, and policy logic. If those controls are weak, security becomes advisory rather than preventative.

In practice, many security teams encounter this only after a release train has already normalised exceptions, rather than through intentional control design.

How It Works in Practice

The response is to move from manual checking to control automation embedded in the software delivery path. That usually means code scanning, secret detection, dependency policy checks, signed build artefacts, and deployment rules that stop high-risk changes before they reach production. Security review still matters, but it should focus on exceptions, material risk, and control tuning rather than acting as the primary bottleneck.

There is no universal standard for where every control belongs in the pipeline, but best practice is evolving toward policy-as-code and identity-bound automation. Build systems, CI runners, deployment tools, and release bots should have tightly scoped Non-Human Identity permissions. That reduces the chance that a compromised pipeline identity can approve, sign, or deploy unreviewed code. This is where identity security and DevSecOps intersect: the identity of the automation is part of the trust model.

• Block secrets in source code and fail builds when credentials are detected.
• Enforce dependency allowlists or risk scoring for packages with poor provenance.
• Require signed commits or signed artefacts where the environment supports it.
• Limit build and deployment permissions to the minimum required for each pipeline stage.
• Route only exceptional cases to humans, instead of every change.

For control design, the NIST Cybersecurity Framework 2.0 is a useful anchor because it ties governance, protection, and detection together across the full delivery lifecycle. If the engineering environment is highly automated, CISA guidance on secure software development and supply chain practices is also relevant, especially for provenance, dependency trust, and release integrity. The same logic applies to agentic tooling: if an AI system can generate or modify code, its actions need the same policy checks and identity constraints as any other privileged automation.

These controls tend to break down when organisations use multiple build systems with inconsistent identity boundaries because policy enforcement becomes fragmented and exception handling turns into a shadow approval process.

Common Variations and Edge Cases

Tighter pipeline controls often increase release friction, requiring organisations to balance delivery speed against assurance depth. That tradeoff is real, especially for product teams shipping many small changes each day. The answer is not to remove control, but to place it where it scales better than human review.

In high-change environments, current guidance suggests using risk-based review thresholds: routine low-risk changes flow automatically, while higher-risk changes trigger extra checks or human approval. This works best when the policy engine can distinguish between code paths, dependency sources, and deployment targets. If the same mechanism governs every repository and environment, teams usually create workarounds rather than better security.

Edge cases matter. Regulated environments may need stronger evidence of approval, segregation of duties, or change traceability. Legacy systems may not support signed artefacts or modern policy enforcement, so compensating controls become necessary. AI-assisted coding also introduces new variance: output may be syntactically valid but semantically risky, so review should include dependency trust, privilege boundaries, and output validation rather than only code style.

Where release velocity is highest, the main question is not whether security can review everything, but which controls can reliably operate at machine speed. That is usually the point where policy, identity, and pipeline telemetry must work together.

Related resources from NHI Mgmt Group

• Why do runtime security issues often survive static code review?
• What should organisations review before relying on low-code IGA workflows?
• Should organisations let AI write remediation code directly from security findings?
• What do organisations get wrong about source code security?