A common mistake is assuming every change deserves the same review depth. In practice, high-volume delivery makes universal manual review unsustainable and ineffective. Teams should instead distinguish between routine changes and changes that alter security-relevant behavior, then automate checks for specific invariants such as authentication, authorization, and sensitive data placement.
Why This Matters for Security Teams
Architectural review in CI/CD is often treated like a single gate, but that mental model breaks down in high-frequency delivery. Security teams get into trouble when they review every pull request as if it were a one-off design decision, instead of asking which changes can alter trust boundaries, secret handling, deployment permissions, or production blast radius. That is why guidance aligned to the NIST Cybersecurity Framework 2.0 focuses on repeatable risk decisions, not blanket manual inspection.
The practical issue is that CI/CD pipelines are themselves part of the attack surface. A seemingly small workflow edit can expose tokens, weaken approval logic, or route artifacts into an unsafe environment. NHIMG research on the CI/CD pipeline exploitation case study shows how pipeline misuse becomes an access problem, not just a code quality problem. In practice, many security teams discover this only after a build credential, deploy token, or release path has already been abused rather than through intentional design review.
How It Works in Practice
Effective architectural review starts by classifying pipeline changes by security impact. Routine refactors, dependency bumps, and formatting updates usually need automated invariant checks. Changes that affect authentication, authorization, secret storage, artifact provenance, environment promotion, or runner trust deserve deeper review because they can change the system’s security architecture even when the application code looks minor.
A workable review model is to separate the pipeline into security-sensitive control points:
- Source control protections, including branch rules and reviewer requirements.
- Build-time trust, including runner identity, isolated execution, and secret injection.
- Artifact integrity, including signing, provenance, and release immutability.
- Deployment authority, including who can promote, override, or rollback.
That approach aligns with the NIST Cybersecurity Framework 2.0 emphasis on governance and risk-based controls, and it also fits NHIMG’s Guide to the Secret Sprawl Challenge, which highlights how uncontrolled credential growth turns routine pipeline tasks into persistent exposure. The architectural review should therefore validate invariants such as “no long-lived secrets in workflow files,” “deployment access is least privilege,” and “build outputs are traceable to a trusted source.”
One useful rule is to treat any change that introduces a new credential boundary or broadens runtime permissions as an architecture change, even if it appears operational. Current guidance suggests automating these checks through policy-as-code and targeted security tests, then reserving human review for the few changes that truly affect security design. These controls tend to break down when teams share runners across many projects because trust becomes ambiguous and one pipeline compromise can cross application boundaries.
Common Variations and Edge Cases
Tighter architectural review often increases release friction, so organisations have to balance speed against the cost of missing a security-relevant change. That tradeoff is especially visible in monorepos, ephemeral environments, and platform engineering teams where dozens of services share the same pipeline primitives.
There is no universal standard for this yet, but best practice is evolving toward tiered review. Low-risk changes can pass through automated checks for secret scanning, policy validation, and protected branch enforcement. Higher-risk changes, such as modifying deployment credentials, changing runner privileges, or introducing external actions and plugins, should trigger explicit security sign-off and a deeper design review. NHIMG’s Reviewdog GitHub Action supply chain attack is a reminder that trusted pipeline extensions can become the exact mechanism that expands exposure.
Security teams also miss edge cases where the pipeline is not the product team’s pipeline at all. Shared build infrastructure, reusable templates, and centrally managed release workflows can concentrate risk across many applications. In those environments, architectural review should focus less on the individual commit and more on the reusable control plane. The question is not whether a change is “small,” but whether it changes who can cause production impact, how secrets are handled, or what trust assumptions the pipeline now depends on.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Pipeline reviews should be risk-based, not blanket manual gates. |
| OWASP Non-Human Identity Top 10 | NHI-03 | CI/CD reviews often miss secret handling and credential lifecycle failures. |
| OWASP Agentic AI Top 10 | A-07 | Automated pipeline actions can create tool abuse and hidden privilege expansion. |
| CSA MAESTRO | CGR-2 | Shared CI/CD controls need governance over trust, provenance, and release authority. |
| NIST AI RMF | GOVERN | Security teams need accountable decision-making for pipeline risk changes. |
Define ownership, escalation, and approval criteria for security-impacting pipeline modifications.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
