Why do code security controls need different treatment in CI and CD?

Why CI and CD Cannot Use the Same Security Thresholds

Continuous integration is designed to validate small, frequent changes quickly, so security controls there need to be narrowly targeted and low-friction. Continuous delivery or deployment runs later in the chain, after code has been assembled into a more complete release candidate, so it can absorb heavier analysis without interrupting developer flow as often. The difference is not just speed. It is also about signal quality, because a check that is useful on a merged build may be too noisy on a pull request.

That is why teams usually separate controls by purpose rather than cloning the same gate everywhere. In CI, the priority is to catch issues that are immediately attributable to the change set, such as insecure patterns, obvious dependency shifts, or policy violations that can be fixed before merge. In CD, the focus can expand to release-wide conditions such as packaging integrity, environment-specific misconfiguration, and interactions that only appear once components are combined. The NIST SP 800-53 Rev 5 Security and Privacy Controls catalogue is a useful reference point for that control-by-control thinking because it distinguishes control intent from pipeline timing. In practice, many security teams discover that a single threshold was overfitted to one stage only after developers begin bypassing or ignoring it.

How Security Checks Behave Differently Across the Pipeline

CI should be treated as the earliest practical checkpoint for developer feedback. The security objective is not to inspect every possible issue at maximum depth. It is to preserve confidence in fast iteration while preventing clearly risky changes from moving forward. That means the most effective CI controls are usually those that are deterministic, diff-aware, and easy to explain. Examples include secret detection on changed files, lightweight static analysis, dependency checks against the updated manifest, and policy checks that map directly to the change.

CD, by contrast, is closer to the actual release context. At that point, the system has more information available: build outputs, container images, infrastructure definitions, release metadata, and deployment targets. A control that would be too expensive or noisy in CI can become more meaningful here because it now sees the assembled artifact rather than a partial patch. This is especially important for security issues that emerge from composition, such as misaligned permissions, inherited configuration drift, or unsafe runtime assumptions.

• In CI, optimise for developer trust and quick remediation.
• In CD, optimise for release confidence and system-level validation.
• In CI, prefer checks that are directly attributable to the change.
• In CD, allow broader checks that depend on the full build and deployment context.

The practical distinction is that CI asks, "Did this change introduce something obviously unsafe?" while CD asks, "Is the release as assembled safe enough to ship?" This is also where teams should be careful about alert fatigue. A scan that is too broad in CI can become background noise, while a scan that is too shallow in CD can miss issues that only surface after packaging or orchestration. Where release pipelines include cloud or container delivery, the value of later-stage validation increases because the control can inspect the same artefact that will be deployed, not an intermediate form. If the pipeline does not preserve a stable artifact identity from build to release, that guidance breaks down.

Where the Trade-offs Show Up in Real Pipelines

Tighter controls in CI often increase developer interruption, so organisations have to balance immediate feedback against the risk of delaying merges with low-confidence findings. That trade-off becomes visible when teams try to run every expensive test on every commit. The result is usually slower pipelines, more overrides, and less respect for the control. A better approach is to reserve heavier checks for stages where they are more actionable and less disruptive.

There are also legitimate edge cases. Some highly regulated release paths require near-parity between CI and CD controls, but that is a governance decision, not a technical default. In other cases, a team may choose to run the same family of controls in both stages with different scopes: a fast CI rule for changed code only, then a deeper CD rule for the assembled application. That is a guidance-versus-consensus area because the exact split depends on release frequency, tolerance for false positives, and whether the pipeline supports immutable artifacts.

If the organisation cannot reliably trace what code, dependency set, or runtime configuration was promoted, the distinction between CI and CD loses much of its value. The control then needs to shift toward release integrity and provenance before it can be trusted as a security gate.

Risk and Threat Considerations

The main risk is control misplacement: if deep scanning is forced into CI, teams tend to bypass it; if shallow scanning is left in CD, release-stage weaknesses can slip through because the pipeline never evaluates the assembled system with enough context. That creates both operational exposure and security blind spots.

Failure mechanism: Attackers and failures both benefit from poor stage alignment. A control that is too noisy in CI trains developers to ignore it, while a control that is too limited in CD may miss composition issues, malicious dependency changes, or deployment-time misconfigurations that only appear after integration.

Impact: The result can be unsafe releases, weakened provenance, delayed detection of insecure artifacts, and reduced confidence in the pipeline as a trustworthy control boundary.

Practitioner Guidance

What to prioritise: Separate change-level checks from release-level checks. Use CI for fast, attributable findings and CD for broader assertions about the assembled release.

What to verify: Confirm that each control has a clear stage owner and a clear failure rule. If a finding cannot be acted on at that stage, it is usually in the wrong place.

Common mistake: Treating CI and CD as the same control surface. That usually creates either false positives in CI or blind spots in CD, and both outcomes erode trust in the pipeline.

Practitioner takeaway: The best pipeline security design aligns control depth with decision timing, so each stage asks only the question it is actually positioned to answer.

Related resources from NHI Mgmt Group

• How should teams implement code security controls in CI/CD pipelines?
• How should security teams implement asynchronous code controls in CI/CD pipelines to avoid race conditions and hidden failures?
• How do container security controls support identity governance in CI/CD?
• How should security teams govern software supply chain risk when CI/CD identities can publish code?