Supply Chain Security

An SBOM tells you what is inside your software. It doesn’t tell you what is reachable, where it came from, where tainted data flows, or what happens to the rest of your estate when one component fails. Those are the questions attackers answer for you if you don’t answer them first.

These posts build from the problem to the tools I wrote because the budget for commercial ones never came. Read them in order, or jump to the part you need.

1. The problem: dependencies are your attack surface

• Threat Modeling Your Dependencies, Part 1: how one bad library can compromise an entire application.
• Threat Modeling Your Dependencies, Part 2: mitigating third-party component risk, including replacing the risky ones.
• Dependency Pruning and Tree Shaking: the cheapest dependency to secure is the one you removed.

2. Seeing risk as a graph

• Calculating Risk Across Project Real-estate using Graph Analysis: using PageRank to prioritise remediation by effective impact.
• Your SBOM Data Has Been Gathering Dust - Until Now: turning SBOMs into a graph you can actually query.
• Catasto: security tools see repositories, attackers see an estate. The case for estate-graph analysis.

3. Provenance: where it came from

• SLSA and Provenance: Your SBOM Says What’s Inside, This Says Where It Came From

4. The regulation catching up

• CRA, NIS2 and DORA for Engineers: what the three EU regimes mean for the people who build and ship software, and why the SBOM they rely on is weaker than it looks.

The Catasto tools

Catasto is named after the Italian land registry: a record of what exists, who owns it and where the boundaries are. Each tool answers one question about your estate.

scarno and src2sink ship with SLSA Build Level 3 provenance, so you can verify what you install.

Note to engineering leaders: if your supply chain programme is a CVE count on a dashboard, start with Catasto and Threat Modeling Your Dependencies. A count is a signal, not a strategy.

More is on the way. Stay tuned!