You deploy one codebase to all tenants. A single poisoned dependency is a breach of every customer simultaneously. How do you defend the software supply chain?

The full executive answer

You've stated our own threat model back to us — our supply-chain register opens with almost that exact sentence: the single-deploy model makes a poisoned dependency high-blast-radius, so dependency hygiene is a security control, not a chore. The defence is a register of nine specific controls mapped to the SLSA framework — the industry's supply-chain maturity ladder — each with implementation, evidence, and an honest status. The path from source to running code: all changes flow through CI with ratchet gates; gitleaks blocks secret leakage; every dependency is pinned in a lockfile whose integrity is verified on every install — a tampered package fails the build; dependency-review blocks known-vulnerable packages at the pull request; CodeQL scans our code on every push.

On the artifact side — this is the part most startups skip — every build generates a CycloneDX Software Bill of Materials, and we cryptographically attest its build provenance through GitHub's attestation API, meaning there's tamper-evident proof of what was built, from what, by which pipeline. That's SLSA Level 2, self-assessed and honestly labelled as such in the register. Deploys are immutable and content-addressed with instant rollback, so if a poisoned build did ship, reversion is minutes.

The honest gaps, straight from our own register's status column: branch protection and required reviewers are owner-operational rather than technically ratcheted; canary/progressive rollout is platform-configured rather than automated; and dynamic scanning of the running app is a weekly advisory ZAP scan, not yet a blocking gate. And the irreducible truth — no SBOM stops a truly novel upstream compromise like xz-utils; what it buys is a minutes-not-weeks answer to "were we exposed?", which is the difference between a controlled disclosure and a panic.