A practical code security funnel starts with fast CI checks on changed code, then broader predeployment scans in CD, and finally scheduled scans for residual risk in production code. The goal is to catch the highest-value defects as early as possible while keeping developer friction low, then use later stages for deeper coverage, prioritisation, and compliance reporting.
How to Layer Code Security Checks Without Slowing Delivery
Code security checks work best as a funnel, not a single gate. CI should focus on fast feedback for changed code and the most likely defects, CD should expand coverage to what is about to ship, and scheduled scans should revisit deployed or dormant code paths that were not visible earlier. That structure reduces the chance that teams mistake one scan for complete assurance.
Teams often get into trouble when they treat every check as equally urgent. A slow or noisy control in CI can train developers to bypass it, while a weak predeployment scan can let risky changes move forward because the pipeline appears “covered.” NIST guidance on control layering is useful here because it reinforces the idea that different checks serve different assurance purposes, rather than one stage substituting for all others. In practice, many security teams discover coverage gaps only after a release has already introduced code that was never exercised in the same way during testing.
The practical question is not whether to scan, but which stage should answer which security question. CI is where teams want speed, clear signal, and minimal disruption. CD is where depth matters more because the release set is smaller and the business impact of a missed issue is higher. Scheduled scans are where teams catch drift, latent exposure, and issues introduced outside the normal commit path.
What Each Pipeline Stage Should Be Responsible For
CI checks should be narrow enough to run on every meaningful change. They are most effective when they validate obvious high-value issues such as dependency risks, secret exposure, insecure patterns in the diff, and policy violations that can be judged automatically. The intent is to stop easy-to-spot problems before they multiply, not to prove the codebase is secure.
CD checks should run after the codebase is assembled into a releasable unit, because they can evaluate broader context. At this point, teams can justify more expensive scanning, including deeper static analysis, container and artifact inspection, and checks that depend on build outputs rather than source files alone. If CI is the filter, CD is the assurance step before exposure.
Scheduled scans fill the longest gap in the funnel. They are valuable for code that changes outside the main delivery path, for legacy repositories that no longer get frequent commits, and for risk review after tool rules, libraries, or threat intelligence change. This is where teams detect residual risk, but they should expect more findings and longer triage cycles. A useful NIST SP 800-53 Rev 5 Security and Privacy Controls is to separate preventive checks from detective ones so the same control is not overburdened with every job.
- Use CI for fast, diff-based checks that fail early and are easy to interpret.
- Use CD for broader scans that benefit from release context and can tolerate more runtime.
- Use scheduled scans for retrospective coverage, trend analysis, and items that age into risk.
- Track false positives by stage, because a noisy CI check has a different cost profile from a noisy scheduled scan.
This model breaks down when teams let stage labels replace actual ownership, because a scan that nobody is accountable for will eventually become a checkbox.
Where the Funnel Needs Exceptions, Triage, and Rescan Logic
Tighter security gating often increases pipeline friction, requiring teams to balance release speed against the depth of assurance. That tradeoff matters most when the codebase includes multiple languages, generated artifacts, or third-party packages that do not behave consistently across scan types.
Some findings belong in CI because they are deterministic and actionable, while others are better deferred until CD or a scheduled run because they need more context or produce too much noise on every commit. Teams also need a clear rule for rescans: a finding that survives into the scheduled layer should not be treated as a duplicate of the earlier stage if the later scan covers different assets, build outputs, or dependency states.
Guidance versus consensus is still uneven on exact gating thresholds. There is broad agreement that critical issues should block high-risk releases, but there is not universal consensus on which severities belong in CI versus CD, or how much historical debt should remain visible without preventing delivery. The deciding factor should be whether the pipeline stage can produce a reliable, timely decision that the next team can act on.
For teams operating at scale, the key exception is not “more scanning,” but “better triage.” If every stage emits the same style of finding, the pipeline loses meaning and developers stop trusting the signal.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 16 — Application Software Security | Directly addresses secure SDLC checks across build and release stages. |
| Recommendation — Apply Control 16 to enforce staged security testing across the software delivery pipeline. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Code scans protect software integrity and reduce exposure of sensitive logic and secrets. |
| DE.CM — Security Continuous Monitoring | Scheduled scans and pipeline monitoring are continuous-detection activities. | |
| PR.IP — Information Protection Processes and Procedures | Staged CI/CD checks are an information protection process for secure development. | |
| Recommendation — Use PR.DS to protect code integrity and reduce sensitive-data exposure in delivery workflows. Use DE.CM to run recurring scans and monitor for newly introduced code risk. Use PR.IP to define consistent scan gates and exception handling across CI/CD. | ||
| MITRE ATT&CK | T1027 — Obfuscated Files or Information | Code security checks often need to detect obfuscation in source, packages, or artifacts. |
| T1552 — Unsecured Credentials | CI scans commonly target secrets and embedded credentials in code changes. | |
| Recommendation — Map obfuscation findings to T1027 and inspect for concealed malicious or risky code paths. Map exposed secrets to T1552 and remove embedded credentials from the delivery path. | ||
Practitioner Guidance
What to prioritise: Put the highest-confidence, lowest-latency checks in CI, because that is where developer behaviour is shaped. Reserve deeper analysis for CD and scheduled scans so early feedback stays usable.
Decision rule: If a control can reliably answer “would this change introduce an obvious unacceptable issue?” then it belongs early; if it needs build context, release artefacts, or time to aggregate evidence, move it later in the funnel.
What to verify: Confirm that each stage produces a different decision, not the same scan repeated three times. The most common failure is overlap without purpose, which adds runtime but not assurance.
What practitioners underestimate: Scheduled scans are not just backlog cleanup. They are the only place many teams notice issues that accumulate after deployment, especially when repos, dependencies, or policies drift between releases.
Practitioner takeaway: A good pipeline is stage-aware: CI filters, CD deepens confidence, and scheduled scans restore coverage where delivery cadence or code drift would otherwise hide risk.
Related resources from NHI Mgmt Group
- How should security teams secure Spring Boot applications across code, dependencies, and CI/CD pipelines?
- How should security teams govern machine credentials across cloud and CI/CD environments?
- How should security teams build a cryptographic inventory across cloud and CI/CD systems?
- How should teams enforce code signing across CI/CD pipelines?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
