Your product is built on hundreds of open-source packages. What is your software supply-chain security story?

The full executive answer

The controls, layer by layer, all verifiable in the repository. Reproducible builds: every dependency version is pinned in a lockfile, and CI installs with the locked, clean-install command — meaning the exact bytes we tested are the exact bytes we ship, and a maliciously updated package version cannot slip in silently between test and deploy. Continuous monitoring: a dependency vulnerability audit runs in CI at high severity on every push, and automated dependency-update tooling — Dependabot — is configured on the repository, so patches arrive as reviewable pull requests that must pass the full five-stage gate like any other change; a compromised or breaking update gets caught by 3,577 tests and the type-checker before production.

Secrets hygiene, which is the other half of supply chain: no secrets in the repository — environment variables only, with a documented public/server-side split; the CI pipeline deliberately runs with dummy credentials, so even a fully compromised CI run has nothing real to exfiltrate — a design decision written into the pipeline file itself. Server-only packages are isolated from the client bundle, so server dependencies never ship to browsers.

Mapped honestly against SLSA — the industry's supply-chain maturity ladder: version control, scripted builds, locked dependencies and CI-enforced verification are in place; the known gaps are that the vulnerability audit is currently advisory rather than build-blocking, and we do not yet generate a signed SBOM — a machine-readable software bill of materials — or signed provenance attestations for builds. Both are scheduled hardening items ahead of enterprise procurement, because your security questionnaire will rightly ask for the SBOM.