Legal is asking for SBOMs? Good. That means someone finally read a headline. But before you start generating a pile of useless JSON to make them happy, you need to understand what an SBOM actually gives you, and more importantly, what it absolutely does not.
First, let's be blunt: an SBOM is a bill of materials, not a security guarantee. It's a list of ingredients. If your vendor provides it, it tells you what's *supposed* be in the binary. It does not, by itself, prove that the binary you're running matches that list. That's where signing and attestations come in, and most tooling today fails to connect these pieces properly.
You have a few starting points, each with massive caveats:
* **If you're using the tool's official package manager (e.g., `cargo install`, `go install`, `npm install`):**
* You can generate an SBOM *after the fact* with a scanner like Syft or Trivy. This tells you what *you think* you pulled down, based on the dependency graph resolved at install time. It does **not** verify the upstream source wasn't compromised. If the registry serves you malicious code, your SBOM will be a neatly formatted list of components inside your new problem.
* Example: running Syft on a Rust binary you built:
```bash
syft packages:path/target/release/your_tool -o cyclonedx-json > sbom.json
```
This output is a guess. It's reconstructing dependencies from Cargo.lock and the binary. It's useful, but it's not proof of integrity.
* **If you're fetching pre-compiled binaries from a GitHub release or a vendor website:**
* You are at the mercy of their build process. An SBOM provided by them is a claim. You must **verify the attestation**. Did they sign the SBOM? Was the SBOM generated from the same workflow that produced the binary? Look for a `.att` or `.sig` file alongside the release. Without a signed attestation linking the SBOM to the exact binary hash, the SBOM is just a pretty document.
* Most projects don't do this. You'll likely have to generate your own SBOM from the binary, which brings you back to the first point: you're documenting what you have, not what you were supposed to get.
The critical gap everyone ignores: SBOM generation and cryptographic verification are two separate steps in most pipelines. You need to demand signed provenance. For example, a proper workflow should give you something like this chain:
1. Binary built in an isolated, ephemeral environment.
2. SBOM generated *in that same environment*, right after build.
3. Both the binary and the SBOM hashed, and those hashes signed (see: in-toto attestations, Sigstore).
4. You verify the signature, then verify your downloaded binary matches the hash in the attestation. *Then* you can trust the associated SBOM.
Without that chain, you're just giving legal a paperwork exercise that provides zero real assurance against supply chain attacks. Start by asking your tool vendors for **signed attestations**, not just SBOMs. If they can't provide them, your SBOM process is starting from a position of fundamental distrust, and you should document that risk accordingly.
-- Dave
-- Dave
Absolutely spot on about the gap between a post-install SBOM and actual trust. That registry compromise scenario is the nightmare that's missing from most compliance checklists.
You mentioned attestations - that's the key piece most teams miss. I've been messing around with generating in-toto attestations for my own Rust tools, and linking them to the SBOM from `cargo auditable`. Even a self-signed attestation, if you've got a verifiable build pipeline, is miles better than a lone JSON file. It at least proves the SBOM matches *something* you built intentionally.
But yeah, handing Legal a signed attestation for a homemade tool just gets you a blank stare. They want a vendor's piece of paper, even if it's meaningless.
build and break
You're right about the blank stare. Legal wants a checkbox marked, not a verifiable chain of evidence. The problem is when the checkbox becomes the whole compliance regime.
I've seen teams burn cycles on attestations for internal tools, then turn around and accept a vendor's PDF "certificate of compliance" without a second thought. The supply chain risk is completely asymmetric.
So you build a perfect, auditable pipeline for your own code, and your biggest risk is still some third-party binary with a nice letterhead.
Compliance is security.
Exactly. The asymmetry is brutal. We'll generate an in-toto attestation for our own model-serving container, but then just accept a vendor's SBOM PDF for a critical inference optimization library. The library's SBOM lists its dependencies, but how do we know the compiled binary matches it? We don't.
It gets worse with ML. A vendor's "certified" model file has no SBOM for its training data lineage or the preprocessing code. So you have a verifiable chain for your wrapper, and a black box of potential poisoning or bias risks in the actual model.
The real trouble starts when Legal thinks the checkbox *is* the risk managed.
Model theft is the new SQL injection.
You nailed the core problem: an SBOM is a snapshot of intent, not proof. That registry compromise warning is the kicker.
In my homelab, I run most tools in Docker. Even if you pull a tagged image, you're trusting the build server. I've seen images where the Dockerfile on GitHub doesn't match the layers in the actual published image. Syft will give you an SBOM for the image you have, but like you said, it's just a list of what's in your potentially poisoned container.
You have to start with policy: no binaries from random `curl | bash`, only from repos we can at least pin. Even then, you're hoping.
My firewall rules are worse than yours.
Finally read the headline is right. They're asking because some regulation now mentions SBOMs, not because they understand them.
Your point about post-install SBOMs is the core disconnect. Legal thinks it's a receipt proving what they bought. It's actually just the vendor's declared packing slip. The goods in the box could be anything.
Starting with Syft on a container is fine for a list, but the real question is: does your procurement policy even require a *signed* SBOM from the vendor? If not, you're just making your own list of potentially bad parts.