Shift-Left Security: Adding SBOM and Supply Chain Scanning to Your CI/CD Pipeline

Status: DRAFT

In 2020, a compromised update to SolarWinds' Orion software reached 18,000 customers — including multiple US government agencies. The attackers didn't exploit a zero-day vulnerability. They compromised the build pipeline and injected malicious code that was then signed, packaged, and distributed by the vendor itself.

The package looked legitimate because it was built by the legitimate build system. This is a supply chain attack, and they have increased by 742% in three years. The defense is knowing exactly what is in your software — and that starts with an SBOM.

What an SBOM Is and Why It Matters

An SBOM (Software Bill of Materials) is a machine-readable inventory of every component in your software: every library, every transitive dependency, every version number, every license.

Without an SBOM, when Log4Shell dropped in December 2021, teams had no systematic way to answer the question "do we have Log4j in our codebase?" They ran grep across repos, checked package.json files manually, and asked developers. It took days to know for certain.

With an SBOM generated at build time, the answer takes thirty seconds: query the SBOM for Log4j, get a list of every service version, fix them in order of exposure.

This is why the US government now mandates SBOMs for software sold to federal agencies, and why enterprise customers increasingly require them before software procurement.

The Four Layers of Supply Chain Security

A complete shift-left security setup has four distinct layers:

Each layer catches a different class of problem. None of them alone is sufficient.

Layer 1: SAST in the CI Pipeline

Static Application Security Testing (SAST) analyzes code for security vulnerabilities without running it. Add it to your CI pipeline as a step that runs on every pull request:

For secrets scanning — preventing API keys, database passwords, and tokens from being committed — add GitLeaks:

Block PRs from merging if either of these steps finds a HIGH or CRITICAL severity finding. Be cautious with auto-blocking on MEDIUM — the false positive rate is high enough to frustrate developers.

Layer 2: Dependency Scanning

Every npm install or pip install brings in dozens of transitive dependencies you didn't explicitly choose. Any of them can have known vulnerabilities.

For Node.js projects, also run:

The philosophy: fail CI on CRITICAL and HIGH severity CVEs with a fix available. Warn on HIGH with no fix available (don't block — a CVE with no patch available just means you need to watch it). Let MEDIUM and LOW through with a report.

Layer 3: SBOM Generation

Generate the SBOM at build time, when you know exactly what went into the artifact. The two dominant SBOM formats are SPDX and CycloneDX — CycloneDX has better tool ecosystem support and is what most teams use.

In your CI pipeline:

Grype takes the SBOM as input and checks every component against vulnerability databases. This is better than scanning the image directly because it runs faster and produces more accurate results.

Layer 4: Container Image Scanning

Before the image is pushed to your registry, scan it for OS-level vulnerabilities:

The key pattern: scan before push. If the scan fails, the image never reaches your registry, and it can never be deployed.

Complete Pipeline Integration

Here is the complete GitHub Actions workflow for a production microservice at a company like Razorpay:

Signing Images with Cosign

Once you are generating and scanning SBOMs, the next step is signing your images so consumers can verify they haven't been tampered with:

Add verification to your Kubernetes admission webhook (using Kyverno or OPA Gatekeeper) so unsigned images are rejected at deploy time, not just at build time.

Production Implementation Guidelines

Start with secret scanning and dependency auditing — these have the highest signal-to-noise ratio and the fewest false positives. Get engineers comfortable with security failures in CI before adding SBOM generation and image signing.

Store SBOMs in a dedicated artifact store (Grype's --db-file or a dedicated S3 bucket with naming convention sbom/{service}/{version}.json). When a new CVE drops, you need to query your SBOMs to find which services are affected — this is only possible if SBOMs are centrally stored and named consistently.

Set a policy: any CRITICAL CVE with a fix available must be patched within 72 hours. Any CRITICAL CVE with no fix available gets a documented exception with a remediation plan. Make this policy visible in your security dashboard, not buried in CI logs.

Trade-offs and Alternatives

The open-source stack (Syft + Grype + Trivy + Semgrep) covers all four layers and costs nothing. Snyk and similar platforms add managed policies, developer-friendly remediation advice, and centralized dashboards — worth the cost for teams that want managed tooling.

INFORMATION

📚 **References & Further Reading** * [Syft Documentation](https://github.com/anchore/syft) - SBOM generation tool * [Grype Documentation](https://github.com/anchore/grype) - Vulnerability scanner for SBOMs * [CISA SBOM Resources](https://www.cisa.gov/sbom) - US government SBOM guidance * [OpenSSF Scorecard](https://securityscorecards.dev/) - Automated supply chain security checks * [Cosign](https://docs.sigstore.dev/cosign/overview/) - Container image signing