The most common mistake teams make with ci cd security tools is treating them as one big gate at the end of the pipeline instead of a set of checks distributed across stages. The right approach maps each control to the stage where it produces the fastest, cheapest signal — a secret scan at commit time, static analysis at build time, dependency and dynamic checks at test time, and posture checks at deploy time. Get the placement wrong and you either slow every merge to a crawl or catch problems so late that fixing them means reverting a release.
This post walks the pipeline stage by stage, naming the category of tool that belongs there and why, so you can audit your own setup against something more specific than "shift left."
What belongs at the commit stage?
Secret scanning and basic linting belong at commit time because they're fast enough to run on every push without annoying anyone. A pre-commit or pre-push hook that checks for hardcoded API keys, private keys, and cloud credentials catches the single most preventable class of incident — a secret pushed to a public or semi-public repo — before it ever reaches a shared branch. GitGuardian's own research has repeatedly found millions of secrets exposed on public GitHub each year, and the fix at this stage costs nothing more than amending a commit. Tools in this category typically run in under a second per file, which is the whole point: anything slower gets disabled by frustrated developers within a month.
What belongs at the build and pull-request stage?
Static application security testing (SAST) and software composition analysis (SCA) belong here, because this is the first point where the full codebase and its declared dependencies are visible together. SAST walks your own source for injection flaws, insecure deserialization, and hardcoded logic bugs; SCA cross-references your manifest files — package-lock.json, requirements.txt, pom.xml — against known-vulnerable package versions and flags outdated or malicious dependencies before they merge. This is also where license compliance checks fit, since a copyleft dependency slipping into a proprietary codebase is much cheaper to catch in a PR diff than after a customer's legal team asks about it. Safeguard's SCA and SAST/DAST modules both run at this stage against the actual diff, so reviewers see new findings, not a wall of pre-existing noise.
What belongs at the test and staging stage?
Dynamic application security testing (DAST) and container image scanning belong at the test stage, because both require something running to test against. DAST throws crafted requests at a live staging build to catch what static analysis structurally can't see — authentication bypasses, misconfigured headers, injection points that only manifest at runtime. Container scanning at this stage checks the built image, not just the Dockerfile source, catching vulnerable OS packages that got pulled in from a base image update between merges. This is also a natural place for infrastructure-as-code scanning, since Terraform or Kubernetes manifests destined for staging are final by this point and worth checking against misconfiguration rules before they touch real infrastructure.
What belongs at the deploy and release gate?
Policy evaluation belongs at deploy, not scanning. By the time code reaches a release gate, it should already have been scanned upstream — what the gate needs to do is aggregate that history and answer a yes/no question: does this build meet the org's risk bar? That means checking for open critical vulnerabilities without a waiver, confirming SBOM generation happened, and verifying no unreviewed license violations exist. Tools that try to run full scans at this stage instead of just evaluating already-collected results tend to become the pipeline's slowest, most-hated step — the one engineers route around with an emergency merge process that quietly becomes the normal process.
What belongs at runtime, after deploy?
Runtime protection and continuous monitoring belong after deploy, because they answer a different question than anything upstream: is this specific running instance actually being attacked right now, and has a new CVE been disclosed against something already in production? Runtime application self-protection (RASP), cloud workload protection, and ongoing re-scanning of deployed container images all live here. A dependency that was clean at merge time can have a critical CVE disclosed six months later, and only a runtime or continuously-rescanning tool will catch that without you re-running your whole pipeline.
How do you avoid tool sprawl across all these stages?
You avoid sprawl by picking platforms that cover multiple adjacent stages instead of one point tool per stage, because five vendors each owning one stage means five sets of findings, five dashboards, and five places a critical vulnerability can get lost between systems. A combined SCA plus SAST/DAST platform that shares one findings database across commit, build, and test stages lets a security team see the full lifecycle of a single vulnerability — where it was introduced, whether it was caught, and whether it's actually reachable in production — instead of reconciling exports from unrelated tools. Teams evaluating this consolidation often start with a head-to-head like our Safeguard vs Snyk comparison to see what a unified findings model looks like against a more fragmented toolchain.
FAQ
Do you need a different tool at every single stage?
No. Many platforms cover two or three adjacent stages with one engine and one findings database, which is usually better than five single-purpose tools that don't share context.
What's the single highest-value stage to start with if budget is limited?
The build/pull-request stage, because SAST and SCA there catch the largest volume of real, fixable issues before they cost anything to remediate.
Does adding more ci cd security tools always slow the pipeline down?
Only if they're placed wrong. A secret scan at commit and a policy check at deploy each add seconds; a full SAST re-scan bolted onto every commit hook is the kind of misplacement that adds minutes and gets disabled.
Where does SBOM generation fit into this stage map?
Typically at build (when dependencies are resolved) with verification again at the deploy gate, so the release gate can confirm an SBOM exists and matches what's actually shipping.