Because they assume code will wait long enough for a human checkpoint to matter. In ADLC, changes can be generated, modified, and replaced repeatedly before a traditional gate is reached, so the control loses timeliness. The risk is not only missed findings, but governance that arrives after the code has already moved on.
Why human checkpoints lose force in ADLC
Pull request reviews and release gates are built around a stable sequence: code is changed, reviewed, and then allowed forward. ADLC breaks that assumption. The thing being reviewed may be regenerated, rewritten, or superseded before the gate is reached, so the checkpoint no longer sits at the decision point that matters.
That makes the control less about stopping change and more about documenting a moment in a fast-moving pipeline. If the artefact can continue to evolve after review, the review becomes a snapshot rather than a real approval boundary.
In practice, the weakness is timeliness, not the concept of review itself. A human checkpoint can still be useful, but only when it is close enough to execution to affect what actually ships.
What changes when code is not the final object anymore
ADLC introduces a moving target. A request may represent one intermediate version, while the real risk sits in the next generated variant, the merged dependency, the prompt-derived change, or the release artifact produced after the review closed. The control point is displaced from the asset that ultimately executes.
That is why traditional gates often fail to see the most important drift: policy-approved code can still become unsafe later, and unsafe code can be replaced with something different after the gate has already been satisfied. The review may have been correct for the version it saw and still be ineffective for the version that runs.
This also changes how teams should think about evidence. The question is not whether a pull request was reviewed, but whether the final runtime object, including generated or post-review modifications, still matches what was approved.
How to make gates meaningful again in fast-moving delivery
Effective controls in ADLC need to be attached to the last trustworthy boundary, not the most familiar one. That usually means checking the release artifact, the deployment event, the signed package, or the enforced policy at execution time instead of relying only on an earlier code review.
Operationally, the strongest controls are those that can compare what was approved with what is actually being promoted. If the delivery path allows the object to change after review, the gate should verify integrity, provenance, and policy compliance at the point of release, not just at the point of commit.
Teams also need to treat human review as one signal among several, not as the final safeguard. For example, supply-chain checks, immutable builds, and deployment-time enforcement reduce the chance that a late-stage change slips past a control that was never designed for rapid regeneration.
Risk and Threat Considerations
When review and release controls lag behind the pace of change, they create a false sense of assurance. The main exposure is not only an unsafe change passing review, but a later modification or replacement that escapes the review boundary entirely.
Failure mechanism: The attacker, or even the normal ADLC workflow, can introduce new content after review, causing the approved object and the executed object to diverge. Once the gate is no longer adjacent to the actual release event, governance can be bypassed by timing, regeneration, or replacement.
Impact: Teams may believe a control has validated the shipped code when it has only validated an earlier draft. That widens the window for policy drift, malicious insertion, and undetected unsafe releases.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5, OWASP SAMM and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | ADLC weakens review gates on changing code, so secure delivery controls apply. |
| Recommendation — Validate release artifacts and enforce integrity checks before promotion. | ||
| NIST SP 800-53 Rev 5 | SA-10 — Developer Configuration Management | The question is about controls losing effectiveness as code changes rapidly before approval. |
| SI-7 — Software, Firmware, and Information Integrity | Late modification and replacement are integrity problems at release time. | |
| Recommendation — Tie approvals to controlled baselines and verify the promoted artifact matches what was reviewed. Verify software integrity at deployment, not only during code review. | ||
| OWASP SAMM | DS — Deployment Security | Release gates in ADLC are a deployment-security problem because timing and promotion are the failure point. |
| Recommendation — Move controls to the deployment boundary where the shipped artifact is still observable. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Artifact provenance and immutability are central when reviewed code can be replaced before release. |
| Recommendation — Require provenance and signed artifacts so promotion can only use trusted builds. | ||
Practitioner Guidance
What to prioritise: Anchor controls to the last immutable or attestable artifact in the delivery path. If you cannot prove the released object is the reviewed object, the gate is advisory rather than protective.
What to verify: Check whether the review system, build system, and deployment system all reference the same artifact identity, hash, or signature. If they do not, treat the release control as incomplete.
Decision rule: If the object can still be regenerated or altered after human approval, add release-time verification and integrity checks before relying on the review outcome.
Practitioner takeaway: In ADLC, the control that matters is the one that still sees the final object, not the one that merely saw an earlier version.
Related resources from NHI Mgmt Group
- How should security teams keep pull request reviews effective when changes touch multiple parts of a codebase?
- Why do organisation-wide access reviews become less effective when they stay limited to ERP?
- Why do periodic access reviews become less effective as environments become more automated?
- When does secrets discovery become insufficient on its own?