Engineers who are moving from general DevOps work toward security-conscious delivery tend to ask the same set of questions. Where exactly should checks go? Will they slow the pipeline? Who owns them? What happens when one fails? This FAQ answers those questions as precisely as possible, focusing on one principle throughout: CI/CD security checks work best when each stage of the pipeline carries its own small control, rather than when everything is deferred to a single review just before production.
What problem are stage-level CI/CD security checks meant to solve?
The problem is late discovery. In a traditional setup, code moves through build, test and packaging with little or no security scrutiny, and then a security review or penetration test happens near release. Findings at that point are expensive: the code was written weeks ago, other work depends on it, and the release date is close. Teams face an unpleasant choice between delaying and shipping with known issues.
Placing a check inside each stage shifts discovery to the moment a problem is introduced. A leaked credential is caught at commit. A vulnerable library is caught when it is added. A misconfigured cloud resource is caught before it is provisioned. Each fix is smaller because it happens sooner.
Does this mean the final security review disappears?
No. A final review, or periodic specialist testing, still has a role. It catches classes of problems that only appear when the whole system is assembled, such as business-logic flaws or chained weaknesses across services. The difference is that it stops being the only safeguard. When earlier stages have already filtered out routine issues, the final review can focus on the subtle ones that genuinely need expert attention.
Which checks belong at which stage?
The exact mapping depends on the organisation, but a few placements are widely accepted:
- At commit and code review: secret detection and static analysis. These run on each change and give developers immediate feedback in their normal workflow.
- At build: dependency scanning and, increasingly, generation of a software bill of materials that records every component included.
- Before deployment: scanning of infrastructure-as-code templates, using a tool such as Checkov, to catch insecure defaults before they reach a real environment.
The guiding rule is to put each check where the relevant change first becomes visible. A dependency problem is visible at build; it makes little sense to wait until release to look for it.
Will adding checks to every stage slow the pipeline down?
It can, if done carelessly. Running a full, slow scan on every commit will frustrate developers. Well-designed pipelines avoid this by matching check depth to stage. Fast, targeted checks run on every change. Heavier analysis runs on merges to main branches or on a schedule. Results are cached where possible so unchanged components are not rescanned.
In practice, most teams find the net effect is faster delivery, not slower. The time spent on small checks is far less than the time previously lost to large, late rework.
Who owns each check?
Ownership should follow the stage. Developers own the response to findings at commit and code review, because they wrote the code. Platform or build engineers own build-stage scanning configuration. Infrastructure engineers own template scanning. A central security function typically defines the policies and thresholds, provides tooling, and handles escalations, but does not personally triage every finding.
This distribution matters. If one team owns all checks, it becomes a bottleneck, and the people who could fix issues fastest are not the ones seeing them.
What should happen when a check fails?
Clarity matters more than strictness here. Each check should have a defined outcome: block, warn, or record. Critical issues, such as an exposed production credential, should block immediately. Lower-severity findings might generate a warning and a ticket without stopping work. Teams that make every finding a hard block usually end up with developers seeking workarounds; teams that make nothing a block find that warnings are ignored.
Documenting these outcomes as policy, and enforcing them automatically, removes ambiguity. Policy engines such as Open Policy Agent are often used to express these rules in code so that release decisions are consistent.
How do container and orchestration platforms change the picture?
Containers add stages and artefacts that need their own checks: base images, image registries, cluster configuration and runtime behaviour. The same principle applies. Scan images when they are built, verify signatures when they are pulled, and review cluster manifests before they are applied. Our playbook on securing container orchestration pipelines goes deeper into the specifics, and our overview of protecting cloud infrastructure and data as a DevOps team covers the broader cloud context.
How should a team deal with false positives?
False positives are the fastest way to lose developer trust in stage-level checks. If a scanner raises twenty findings and eighteen are irrelevant, people stop reading the output. The remedy is active tuning. Suppress findings that have been reviewed and judged not applicable, record the reason alongside the suppression, and revisit suppressions periodically. Start new checks in warning mode for a short period so thresholds can be adjusted before they begin blocking work. A smaller set of checks that people trust is worth more than a larger set they ignore.
What about older pipelines that were never designed for this?
Legacy pipelines can adopt stage-level checks incrementally. There is no need to rebuild them first. Add a single non-blocking scan to an existing build step, observe its output for a few cycles, then promote it to blocking for critical findings only. Repeat for the next stage. The aim is steady progress without disrupting releases that teams depend on.
Are there regulatory reasons to work this way in Europe?
Increasingly, yes. Brussels has moved in this direction. Its Cyber Resilience Act, adopted in 2024, introduces security-by-design expectations for many products with digital elements, along with obligations around handling vulnerabilities over a product’s lifetime. The NIS2 Directive has also widened the range of organisations expected to manage cybersecurity risk systematically. Neither prescribes a specific pipeline design, but both favour processes in which security is demonstrably part of development rather than an afterthought. Stage-level checks, with their automatic records of what was scanned and when, produce exactly the kind of evidence such regimes reward.
This is general information, not legal guidance; organisations should confirm their own obligations with qualified advisers.
What skills does an engineer need to implement this?
The core skills are less exotic than many assume. An engineer needs to understand the pipeline well enough to know where each type of change appears, to configure and tune scanning tools, to read findings critically and separate real risk from noise, and to communicate fixes to the people who own the code. Familiarity with infrastructure-as-code and container platforms is increasingly expected. Our article on the skills DevOps engineers need this year places security alongside these other competencies.
How can an engineer learn this systematically?
Many learn it on the job, one incident at a time. A more efficient route is a curriculum designed around stage-by-stage security. DevSecOpsSchool, which provides DevSecOps certification and hands-on training, structures its programmes on exactly this idea: every phase of software delivery carries a built-in security control. Its role-based certifications are relevant here; the professional-level certification teaches engineers to make CI/CD jobs themselves run the scans, hunt for leaked credentials and verify compliance rules, whereas the architect-level certification covers multi-cloud design, policy-as-code and zero-trust approaches for those working at enterprise scale. Training is delivered through live online cohorts as well as in classrooms.
What is a sensible first step for a team starting today?
Start with the stage that produces the most expensive surprises. For many teams that is credentials: add automated secret detection to every repository and move existing secrets into a managed store. Next, add dependency scanning to builds. Then introduce a small set of written release rules and enforce them automatically. Each step is modest, and each removes a category of late-stage surprise. After a few months, the final review will look noticeably different: shorter, calmer and focused on the issues that truly need human expertise.
What is the one-sentence summary?
Put a small, appropriate security check inside each stage of the pipeline, so that problems are found where they start, and keep a final review only for the issues that genuinely require the whole system to be assembled.