Should security teams embed testing in CI/CD or keep it as a separate review step?

Why CI/CD Is the Right Place for Testing Decisions

For security teams, the key question is not whether testing matters, but where it can actually influence developer behaviour and release outcomes. Embedded testing turns security checks into part of the delivery workflow, so findings appear while the code, pipeline and deployment context are still fresh. That makes it easier to correct issues before they become repeatable release patterns.

Separate review steps usually fail on timing and context. By the time a detached review completes, the change may already have merged, grown stale, or been copied into later work. In CI/CD, the same change can be evaluated against policy, dependency integrity, and release criteria before it reaches production, which is why the control belongs in the pipeline rather than beside it.

A SLSA alignment is a good fit here because CI/CD testing is not just about test execution, but about preserving build provenance and release integrity as code moves through the delivery chain.

What Embedded Testing Changes in Practice

Embedding testing in CI/CD changes the security model from periodic inspection to continuous enforcement. It allows teams to treat build and release events as checkpoints where policy can block unsafe code, require verification, or surface exceptions immediately. That is materially different from a separate review, which usually depends on someone remembering to route the change for scrutiny.

This also improves feedback quality. A failing check in a pipeline tells the developer exactly which commit, dependency, or configuration introduced the issue, which shortens the path to remediation. When testing is detached, the same issue is often harder to reproduce because the codebase, context, and related dependencies may already have shifted.

Embedded testing is especially important where delivery systems carry identity, secrets, or release authority. CI/CD pipelines often touch tokens, signing keys, package publishing rights, and deployment credentials, so the testing point is also the point where you can detect unsafe changes before they inherit those privileges. The difference is not only speed, but blast-radius control.

For teams managing pipeline trust, CI/CD Pipeline Identity Security Guide is directly relevant because the same workflow that runs tests also governs token permissions, OIDC federation, pinned actions, and trusted publishing.

When a Separate Review Still Makes Sense

A separate review step is not useless, but it is usually best treated as a complement to embedded testing, not a replacement. It can help for exceptional changes that need human judgement, for high-risk releases, or for policy decisions that cannot be reduced to an automated rule. It is also useful as an escalation path when a pipeline check fails in a way that needs manual interpretation.

The limitation is that separate review works best for exceptions, not as the primary control. If every change depends on a manual gate, teams tend to accumulate delay, inconsistent decisions, and shadow processes that bypass the gate when delivery pressure rises. At scale, that creates a false sense of assurance because the review exists on paper but no longer shapes release behaviour.

Pipeline security incidents show why the boundary matters. Compromised workflows, leaked credentials, and poisoned actions can turn the delivery system itself into an attack path, so testing only after the fact can miss the window where a malicious change first gains execution. reviewdog Action compromise 2025 is a strong example of how pipeline trust failures can expose secrets before downstream review can help.

Risk and Threat Considerations

Security teams that keep testing outside CI/CD often create a timing gap that attackers and risky changes can exploit. The longer a change travels before it is checked, the more likely it is to be merged, copied, or deployed with unsafe assumptions still intact. That increases both accidental release risk and the chance that a malicious change can blend into normal delivery activity.

Failure mechanism: Detached review introduces latency, weakens context, and makes it easier for unsafe code, poisoned dependencies, or compromised workflows to pass into later stages before enforcement occurs.

Impact: The organisation loses the ability to stop high-risk changes at the point of creation, which raises the likelihood of secret exposure, unauthorized release activity, and compromised build or deployment trust.

Practitioner Guidance

What to prioritise: Put automated security checks where they can fail the build or gate the release, then reserve manual review for exceptions, escalations, and judgment calls that automation cannot reasonably resolve. That gives you the best balance of consistency and speed.

What to verify: Confirm that the pipeline test is wired to an actual release decision, not just a notification stream. If a failed control can still be merged or deployed without a deliberate exception path, it is not acting as a real gate.

Common mistake: Treating “we have a security review” as equivalent to enforcement. A review that happens after the change has already travelled beyond the point of control is usually documentation, not prevention.

Practitioner takeaway: Embed testing in CI/CD when you want security to change delivery behaviour; keep separate review only for exceptions where human judgement adds something automation cannot.

Related resources from NHI Mgmt Group

• How should security teams implement API security testing in CI/CD pipelines?
• How should security teams implement runtime testing in CI/CD pipelines?
• How should security teams choose between Burp-style testing and CI/CD-native DAST?
• How should security teams implement behavioural testing for AI agents in CI/CD?