How a B2B SaaS Team Cut Supply-Chain Risk by Enforcing SBOMs, Sigstore Signing, and OPA Admission Policies
A 120-engineer SaaS company rebuilt its CI/CD pipeline around Syft SBOMs, Cosign signatures, and OPA Gatekeeper to block unsigned or unverified images from ever reaching production.
Security · advanced · 12 min read · 2127 words · By Sandip Das · Published
Composite scenario: built from common industry patterns; the figures are illustrative.
What this covers
- The Situation
- The Problem
- Constraints
- Options Considered
- The Solution
- Implementation
- Results
- What Went Wrong Along the Way
- Lessons Learned
- Apply It Yourself
Key numbers
| Metric | Before | After |
|---|---|---|
| Time to answer 'are we affected by CVE-X?' | 9–11 hours | Under 30 minutes |
| Images in production with verified provenance | 0% | 100% |
| SBOMs available on demand | 0 of 60 services | 60 of 60 services |
| Enterprise deals blocked by missing SBOM | 2 deals ($1.4M ARR) | 0 (both closed) |
| Mean time to detect tampered image in staging | Undefined | Under 5 minutes |
Key components
- Syft — Generates CycloneDX SBOMs from container images and attaches them as OCI referrer artifacts in the registry.
- Cosign (keyless) — Signs image digests using short-lived Fulcio certificates backed by GitHub Actions OIDC tokens, with entries recorded in Rekor.
- Rekor — Provides an immutable, publicly auditable transparency log of every signing event for post-hoc verification.
- OPA Gatekeeper — Enforces admission policies that block any pod whose image cannot be verified against a valid Cosign signature at deploy time.
- Trivy — Scans images for known CVEs during CI and fails the build on CRITICAL vulnerabilities with available fixes.
- Argo CD — Triggers Kubernetes deployments and routes all pod creation through the Gatekeeper admission webhook.
The Situation
This is a composite scenario assembled from patterns observed across multiple organisations; all figures are illustrative and chosen for internal consistency, not to represent any single company's experience.
The organisation is a 120-engineer B2B SaaS company delivering a data-integration platform to mid-market financial services customers. Engineering runs eight product squads plus a four-person platform team. The production stack is roughly 60 microservices deployed on three AWS EKS clusters (us-east-1, eu-west-1, ap-southeast-1). Images are built in GitHub Actions, stored in Amazon ECR, and deployed with Argo CD. Customers hold SOC 2 Type II and ISO 27001 requirements over the vendor, and two enterprise prospects had started asking for a software bill of materials (SBOM) as a procurement condition.
The platform team had been carrying a backlog item labelled "supply-chain hardening" for fourteen months. A near-miss in Q3—a dependency confusion attack that reached staging before a developer noticed the wrong package version—turned the backlog item into a P0 project.
The rest of this case study — the trade-offs, the scaling numbers and the build prompt — is available to LearnXops members. Create an account or see membership.
Topics: security, supply-chain, sbom, sigstore, kubernetes, opa
Related case studies
- AWS Keys Leaked to GitHub: The First 60 Minutes and the Clean-Up
- How a 120-Engineer SaaS Company Replaced Its Corporate VPN with Zero-Trust Access
- How a B2B SaaS Team Contained Prompt Injection Across an AI Agent With Live Tool Access
- How a B2B SaaS Team Eliminated Plaintext Secrets and Cut Credential Exposure Risk by 94%