Zhivko Todorov
ALL CASE STUDIES

CASE 75 · CARDINAL · 2026

SLSACOSIGNPROVENANCEOIDC

Build provenance that the supply chain can actually verify.

An open-source vendor shipping binaries and container images to thousands of users had had two near-misses with dependency-substitution attacks. Customers had started asking, in writing, for SLSA-level provenance. We rebuilt the build pipeline to emit SLSA L3-compliant attestations.

INDUSTRY

Open source vendor

DOMAIN

PLATFORM

DELIVERED

2026

STACK

GITHUB ACTIONS OIDC·COSIGN·SLSA-GITHUB-GENERATOR·AWS KMS·SIGSTORE·ECR

RESULTS

What changed, by the numbers.

SLSA LEVEL

L3

BUILD PROVENANCE

CUSTOMER SECURITY ASKS

−74%

AUTO-SATISFIED

ARTIFACT TYPES COVERED

12

BINARIES + IMAGES + WHEELS

VERIFICATION TIME

< 2s

CLIENT-SIDE COSIGN VERIFY

HOW IT WENT

The near-misses had been benign — both caught by sharp-eyed users. But "got lucky twice" isn’t a security strategy. SLSA seemed appropriate, but the team had assumed it was a six-month project requiring a custom signing infrastructure.

GitHub Actions OIDC + SLSA GitHub Generator + Sigstore handles most of the work for free. We extended it with AWS KMS-backed signing keys (for the regulated-customer path that needed key custody) and explicit attestation generation for the non-container artifacts. Verification at the client side is a single cosign command.

Customer security questionnaires that used to take a senior engineer two days to answer now resolve in fifteen minutes — the answer is "here’s the provenance, here’s how to verify." The 74% reduction came mostly from auto-satisfied questions about build integrity.

READY WHEN YOU ARE

Let's get your AWS bill (and architecture) in order.

The discovery call is free. You walk away with at least one concrete idea — even if we never work together.

Or email directly →