← Back to Blog

The DevSecOps Pipeline That Would've Stopped 61% of 2025's Supply-Chain Attacks


← Back to Blog

The DevSecOps Pipeline That Would've Stopped 61% of 2025's Supply-Chain Attacks

A production-grade DevSecOps pipeline architecture — SBOM generation, image signing, and keyless CI/CD — built around what actually caused last year's breaches.

Anas Rhimi
Anas Rhimi September 2026 • 6 min read

The DevSecOps Pipeline That Would've Stopped 61% of 2025's Supply-Chain Attacks

BLUF: Most 2025 supply-chain attacks didn't exploit zero-days — they walked through unguarded CI/CD pipelines, untrusted dependencies, and plaintext secrets in version control. A pipeline with SBOM generation, dependency scanning, and cryptographic image signing closes most of that door, and none of it requires exotic tooling.

Industry reporting puts the share of organizations that experienced a software supply-chain attack in 2025 at roughly 61%. That's not an edge case anymore — it's closer to a coin flip. If your CI/CD pipeline is just running tests and deploying artifacts, it's not a DevSecOps pipeline, it's a fast way to ship vulnerabilities.

The Architecture

Think of a modern pipeline as a series of security gates layered over your existing CI/CD flow, not a separate process bolted on afterward:

Stage Tool What It Prevents
Dependency scan Trivy Known CVEs in base images and packages
SBOM generation Syft Untracked/unknown components in production
Image signing Cosign Unverified or tampered images reaching the cluster
CI identity GitHub OIDC Long-lived static cloud credentials in CI secrets
Secrets External Secrets Operator Plaintext secrets committed to Git
Admission control Signature verification Unsigned images running in the cluster at all

Eliminating Static Credentials First

The single highest-leverage fix, and the cheapest one, is removing long-lived cloud credentials from CI entirely:

# GitHub Actions using OIDC instead of static AWS keys
permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789:role/ci-deploy-role
          aws-region: us-east-1

No static AWS keys sitting in GitHub secrets means there's no long-lived credential to leak in the first place — this alone eliminates one of the most common leak vectors in supply-chain incidents.

SBOM and Signing in Practice

# Generate an SBOM and sign the image before it's allowed to deploy
syft packages docker:myapp:latest -o cyclonedx-json > sbom.json
trivy image --exit-code 1 --severity CRITICAL,HIGH myapp:latest
cosign sign --key cosign.key myapp:latest

At the cluster's admission layer, verify the signature before the image is allowed to run at all — this is what turns "we scanned it once in CI" into "nothing unsigned runs in production, ever," which is the actual guarantee that matters.

Where This Fits With GitOps

If you're running ArgoCD for delivery, the SBOM/signing gate sits upstream of it — the image never gets built into a manifest ArgoCD would sync unless it passed scanning and signing. Git stays the single source of truth for what's deployed; the pipeline is the gate for what's allowed to become deployable in the first place.

The Compliance Angle

SBOMs stopped being optional paperwork in 2026 — tightening EU and US cyber regulations increasingly require them for audit and transparency purposes. Building SBOM generation into the pipeline from day one means compliance becomes a byproduct of good engineering practice instead of a separate scramble before an audit.

Bottom Line

None of this requires enterprise security tooling with a six-figure price tag. Trivy, Syft, and Cosign are open source, and GitHub OIDC is free. The barrier to a genuinely hardened pipeline in 2026 is mostly organizational will, not budget.

Need help implementing this? I help teams architect and scale this exact infrastructure. Explore my consulting and freelance services.