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