// Defense

Explore Software Supply Chain Security

The code you ship is mostly code you didn't write — that's the attack surface.

Open a minimal Express app in any editor and run a dependency count. Before you've written a single line of business logic, you've already imported 47-plus transitive packages — authors you've never heard of, maintainers you've never vetted, build hooks you've never read. Software supply chain security starts with sitting with that number until it stops feeling abstract. The 80–90% ratio isn't a statistic to memorize; it's a reorientation. AppSec curricula spend almost all their time on the 10–20% you wrote. Attackers have done the math on the rest.

This topic works through the full stack of the problem: why the transitive dependency graph is where risk actually hides, what dependency confusion and typosquatting look like in practice, why running Trivy on every build is a genuinely good idea that still leaves entire attack classes invisible, and what it takes to be able to answer the question practitioners now treat as the real bar — not 'did we scan for CVEs?' but 'where did this artifact come from, and can I prove it wasn't tampered with?' That means getting into SBOMs as maps rather than deliverables, artifact signing with Sigstore and cosign, SLSA provenance levels, and verification at deploy — because signing without a verification gate is theater.

Your CI/CD pipeline has secrets, network egress, and the right to push to production. That makes it production. One of the quieter goals of this topic is making that sentence feel obvious rather than surprising, so that when you're threat-modeling a system, you bring the build runners into the room automatically. The xz-utils story — a two-year social-engineering operation that embedded a backdoor in SSH infrastructure on millions of systems, nearly undetected — is the campfire story this community tells because it illustrates everything: a trusted name, a legitimate-looking update, and an attack surface that no CVE scanner would have caught.

// What a session feels like

You bring the questions. Nugget asks the next one.

You tell Nugget you thought pinning your dependencies secured the supply chain. It doesn't argue — it asks you to walk through what pinning actually guarantees. On the shared whiteboard, you sketch what happens during dependency resolution when a build tool reaches out to a public registry. Nugget draws the fork: reproducibility on one branch, integrity on the other. By the end you can state in one sentence why a pinned malicious version is still malicious, and why those are two different problems requiring two different answers.
You want to understand why 'we run Trivy on every build' isn't the full story. Nugget pulls a current write-up of a recent typosquatting incident from the web mid-session, and you work through it together: what a CVE scanner would have seen (nothing), what the package name looked like (convincing), what the postinstall hook did (already ran). You map the gap between known-vulnerability scanning and the malicious-package and build-compromise attack classes that don't show up in CVE databases at all.
You open a Docker Linux lab and run cosign against a container image, then deliberately break the verification step to see what an unverified deploy looks like in practice. Nugget walks you through reading the Sigstore transparency log entry — what the build provenance claim says, what SLSA level that corresponds to, and what an attacker would have needed to control to forge it. The session ends on the question practitioners use to check their own thinking: if your pipeline were compromised, at which step would you catch it?

// Pairs well with

Incident Response Non-Human Identity & Secrets Management Detection Engineering

Start exploring Software Supply Chain Security tonight — three topics free, no card.

Start a 30-day free trial