DevSecOps Tools: Securing the Software Supply Chain

"Shift security left" gets repeated often enough that it's easy to nod along without a concrete picture of what it actually means day to day. The concrete version is simple: run security checks as early as possible in the pipeline, at commit time and build time, rather than waiting for a separate security team to review a finished application right before it ships. Here's what that actually looks like stage by stage, and which tools cover each one.

Stage 1: Secrets scanning, before code even merges

The single most common, most avoidable security incident is a developer accidentally committing an API key or database password directly into a Git repository. Tools like Gitleaks and TruffleHog scan commits (ideally as a pre-commit hook, and again in CI as a backstop) for patterns that look like credentials, and block the commit or fail the build before the secret ever reaches a shared branch.

# Example: Gitleaks as a CI step
- name: Scan for secrets
  run: gitleaks detect --source . --verbose

This is the cheapest possible security win available, since a leaked secret in Git history is genuinely difficult to fully remove later, and catching it before the commit is merged avoids that problem entirely.

Stage 2: Static analysis (SAST), on every pull request

SAST (Static Application Security Testing) tools analyze your source code directly, without running it, looking for known vulnerable patterns: SQL built via string concatenation instead of parameterized queries, use of known-insecure cryptographic functions, and similar. Semgrep and SonarQube are common choices here, both able to run as a pull request check and flag issues with the specific line of code responsible.

The key advantage of catching this at the PR stage is that the developer who wrote the code gets immediate, specific feedback while the context is still fresh in their head, rather than a vulnerability report landing weeks later disconnected from the original change.

Stage 3: Dependency scanning (SCA), for the code you didn't write

Most of any modern application's actual code is third-party dependencies, and vulnerabilities in those dependencies are extremely common. SCA (Software Composition Analysis) tools like Snyk, Dependabot (built into GitHub), and Trivy scan your package.json, requirements.txt, go.mod, or equivalent, cross-reference every dependency against known vulnerability databases, and flag anything with a known CVE, often with an exact version to upgrade to.

trivy fs .                    # scan a project's dependency manifests
trivy image myapp:1.4.0       # scan a built container image

Notice Trivy does both dependency scanning and image scanning, more on that next, since a lot of modern security tools deliberately cover multiple stages rather than being narrowly scoped to just one.

Stage 4: Container image scanning, before it ever ships

A container image bundles an entire OS layer plus your application and its dependencies, any of which can carry known vulnerabilities. Image scanners like Trivy and Grype unpack an image layer by layer and check every package inside against vulnerability databases, catching issues in the base image itself (an outdated Alpine or Debian base, for example) that dependency scanning alone would miss since it only looks at your application's declared dependencies, not the OS underneath them.

Running this as a required CI step, failing the build if a critical vulnerability is found, is what actually stops a vulnerable image from ever reaching a registry, rather than relying on someone remembering to check later.

Stage 5: Infrastructure as Code scanning, for Terraform and Kubernetes manifests

Misconfigurations in your infrastructure definitions (an S3 bucket left publicly readable, a security group open to the entire internet, a Kubernetes Pod running as root unnecessarily) are just as real a risk as vulnerable code. Checkov and tfsec scan Terraform (and Checkov also covers Kubernetes manifests and CloudFormation) for exactly this class of issue, before anything is ever applied to real infrastructure.

checkov -d ./terraform

Stage 6: Policy as code at admission time, on the cluster itself

Scanning catches problems before deployment, but you also want a backstop that can outright reject a non-compliant resource at the moment someone tries to deploy it. On Kubernetes, OPA Gatekeeper and Kyverno act as admission controllers, intercepting every resource creation request and rejecting anything that violates a defined policy ("no container may run as root," "every Pod must declare resource limits") in real time, regardless of whether it came through a pipeline with all the earlier checks or was applied directly with kubectl by someone bypassing the pipeline entirely.

Stage 7: Runtime and supply chain integrity

The newest layer of this stack focuses on what happens after deployment, and on proving an artifact hasn't been tampered with between build and deploy. Cosign (part of the Sigstore project) signs container images cryptographically at build time, so a cluster can verify at deploy time that the image is exactly what CI produced and hasn't been swapped for something else along the way. Generating an SBOM (Software Bill of Materials, via a tool like Syft) alongside every build gives you a complete, queryable record of every component in a given release, useful both for security audits and for quickly checking exposure when a new vulnerability is disclosed later.

Putting it together: a realistic pipeline

commit --> [secrets scan] --> PR --> [SAST + SCA] --> build --> [image scan] --> [sign image + SBOM] --> deploy --> [admission policy check]

No single tool in this list does everything, and that's by design, each one is narrowly scoped to catch a specific class of problem at the specific point where it's cheapest to fix. The goal of DevSecOps tooling isn't to bolt one big scanner onto the end of your pipeline, it's to distribute smaller, targeted checks across every stage so problems get caught close to where they were introduced.

If you're building out CI/CD pipelines that need to incorporate stages like these, the CI/CD quiz on OpsQuiz is a good way to check the pipeline fundamentals underneath it all.