Security teams should enforce policy at merge and build time, not only after release. The most effective approach is automated analysis in the IDE and CI/CD pipeline, combined with quality gates that block code with high-risk findings. That shifts security left, reduces rework, and makes prevention part of normal delivery rather than an after-the-fact exception.
Why This Matters for Security Teams
Stopping insecure code before production is not just a developer convenience, it is a control problem. Once weak authentication, unsafe deserialisation, hardcoded secrets, or broken input handling ship, the security team inherits incident response, rollback pressure, and reputational damage. The practical goal is to make insecure code fail fast in the same workflow where it is introduced, rather than relying on manual review after the fact.
That requires policy enforcement at the merge request, build, and release stages, with clear criteria for when a finding is informational versus blocking. A mature programme usually combines static analysis, secret scanning, dependency checks, and targeted testing with approval rules that reflect application risk. NIST control families such as the NIST SP 800-53 Rev 5 Security and Privacy Controls support this approach by aligning secure development, configuration management, and risk-based authorisation to delivery pipelines.
Teams often get this wrong by treating pipeline scanning as a reporting exercise rather than a gate, which creates a false sense of control while insecure changes continue to ship. In practice, many security teams encounter the real risk only after an urgent release has already bypassed review, rather than through intentional prevention in the delivery path.
How It Works in Practice
The strongest pattern is layered enforcement. First, developers get immediate feedback in the IDE so obvious issues are caught before code is committed. Next, source control and CI/CD checks inspect the change set for high-risk patterns. Finally, release gates decide whether the build can proceed based on policy, ownership, and exception handling. Security teams should tune each control to the application class, because a customer-facing payment system and an internal utility do not deserve the same threshold.
In practice, the control stack usually includes:
- Static application security testing for vulnerable code paths and insecure APIs.
- Secret scanning to block tokens, API keys, and certificates from entering repositories.
- Software composition analysis to catch vulnerable dependencies and transitive packages.
- Infrastructure-as-code and container checks so misconfigurations are blocked before deployment.
- Automated policy rules that require human approval only for defined exceptions.
Framework guidance from OWASP’s Software Assurance Maturity Model and the NIST Secure Software Development Framework points in the same direction: define secure development practices, verify them continuously, and make evidence of compliance machine-readable where possible. The operational key is to convert findings into policy decisions, not just developer tickets. That means severity thresholds, ownership mapping, and exception expiry dates should be part of the pipeline, not managed in spreadsheets.
These controls tend to break down when release pipelines are fragmented across teams and tooling, because inconsistent enforcement lets developers route around the strictest checks.
Common Variations and Edge Cases
Tighter gates often increase delivery friction, requiring organisations to balance faster feedback against the risk of blocking legitimate work. Best practice is evolving here, and there is no universal standard for how many findings should fail a build, but the principle is consistent: only high-confidence, high-impact issues should stop production changes automatically.
One common edge case is legacy code, where large backlogs make full blocking unrealistic. In those environments, teams usually start with new code only, then expand coverage as technical debt falls. Another is third-party and generated code, where scanners may create noise that overwhelms engineers unless policy distinguishes trusted artifacts from custom application logic.
For highly regulated environments, release approval may also need evidence of segregation of duties, change control, and audit trails, not just security scan results. In cloud-native delivery, IaC and container findings can matter as much as application code, because insecure defaults in deployment templates can recreate the same exposure across many services. The OWASP Top 10 remains useful as a triage lens, but it should not replace application-specific risk assessment or ownership-based exceptions.
Where teams operate at scale, the real challenge is usually governance consistency, not scanner coverage. If one product line can override policy with informal approval while another must fix every critical issue, insecure code will simply move to the path of least resistance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Secure development practices need to be built into the delivery process. |
| NIST AI RMF | GOVERN | Risk ownership and policy are essential when automating security gates. |
| OWASP Agentic AI Top 10 | Automated code generation and agent tooling can introduce insecure changes. | |
| NIST SP 800-53 Rev 5 | SA-11 | Security testing must verify code and configs before production deployment. |
Treat AI-generated code like any other untrusted change and scan it before merge.
Related resources from NHI Mgmt Group
- How should security teams govern AI-generated code in production environments?
- How should security teams govern AI-generated code in production pipelines?
- How should security teams stop forked pull requests from reaching privileged GitHub Actions jobs?
- How should security teams limit the risk from AI agents that have access to production systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
