Customer code security scanning

Customers deploy their own code to Launch, so Launch inherits their dependency trees and, occasionally, their secrets. Nothing in the platform looked at what was being shipped — a leaked key or a known-vulnerable package went live the same as anything else.

The constraint that shaped everything: a scan can never be the reason a customer's deploy fails. If the scanner is slow, wrong, or down, the deploy still goes out.

I split it into two planes. The build plane is an isolated evidence collector inside the deployment agent — it gathers an SBOM (Syft over the installed tree, scoped to the customer's project) and candidate secrets, under a hard 300-second execution cap, and is fail-open by contract. The analysis plane is a dedicated Go service that does the matching against vulnerability databases using embedded warm-database matching and localised advisory mirrors in each of the three clouds.

It is provider-agnostic across file upload, GitHub and external Git deployments, and I structured delivery into six independently releasable slices — foundation, exposed files, leaked secrets, platform misconfigurations, dependency and licence vulnerabilities, then continuous rescanning — so value ships before the whole system exists.

Before any product code existed I answered the question everything else depends on: can Trivy and osv-scanner run as embedded Go libraries rather than shelled-out binaries, and what does the warm-database memory floor cost per build? That number decides whether scanning can run inline in the build container or must run out of band.

Then the dual-engine assumption. The plan was Trivy for dependencies plus Gitleaks for secrets, on the theory that they were complementary. A code-level diff of the two rulesets showed a 74% rule-ID overlap; what looked like complementary coverage was mostly rule-name drift. I recommended Trivy-only with exact-value environment-variable correlation — the approach Netlify takes — which removes a second engine, dual suppression files and a class of high-entropy false positives before any of that became technical debt.