I’ve seen three major migrations in the last two years get derailed—not by core functionality, but by hidden licensing, security, and compliance landmines buried in the software supply chain. Every time, the root cause was the same: the evaluation team either didn’t ask for a Software Bill of Materials (SBOM) correctly, or didn't know how to validate what they received. They took the vendor's "yes, we provide an SBOM" at face value and got burned post-contract. If you're evaluating a vendor like "Claw" (or any vendor whose code will be integrated into your environment), you need to treat the SBOM not as a checkbox, but as a critical deliverable for your technical and legal audit.
Asking for it is step one, but it's meaningless without explicit, enforceable requirements. You must bake these requirements directly into the RFP and the subsequent contract's acceptance criteria. A vague request gets you a useless, auto-generated SPDX file with half the dependencies missing. Here is the specific language I now insist upon in the technical appendix of any RFP for a software vendor:
```
## Software Bill of Materials (SBOM) Deliverable Requirements
The vendor must provide a complete, accurate, and machine-readable SBOM for all application components, including dependencies, transitive dependencies, and the underlying container/base OS image (if applicable).
**Format & Standards:** SBOM must be provided in **SPDX 2.3** or **CycloneDX 1.5** format. PDF or spreadsheet outputs are not acceptable.
**Scope:** Must cover all components in the deliverable, including:
* All open-source libraries, with direct and transitive dependencies explicitly enumerated.
* All third-party commercial/SaaS components and SDKs.
* The application's container image(s) and underlying OS packages (e.g., from `apt`, `yum`, `apk`).
* Build tools and compilers used in the CI/CD pipeline, if the delivered artifact is a binary.
**Required Data Fields:** Each component entry must include, at minimum:
* Component name and version.
* Component supplier (author/organization).
* License(s) under which the component is used.
* A unique identifier (e.g., Package URL (PURL), SPDXID, CPE).
* Relationship (e.g., "CONTAINS," "DEPENDS_ON") to other components.
**Generation & Attestation:** The SBOM must be generated via an automated process during the build pipeline. Vendor must attest to the process and provide evidence of generation (e.g., a signed SBOM using in-toto attestations or Sigstore Cosign).
**Updates:** Vendor must commit to providing an updated SBOM with each patch, minor, and major release delivered during the contract term.
```
Verification is where most teams fall down. Getting the file is not the finish line. You need to perform at least these three checks before you can consider the SBOM "verified":
* **Structural & Format Validation:** Run the SBOM file through the official SPDX or CycloneDX validator tools. This catches malformed files that tools downstream cannot ingest.
* **Completeness Spot-Check:** Cross-reference a sample of components. For a web app, use your browser's dev tools to identify a handful of client-side libraries, then confirm they are present in the SBOM with the correct version. For a container image, run `docker export | tar -t | grep -E '.(jar|js|so|dll)$'` to get a crude list of binaries and check for them.
* **License & Vuln Scan:** Ingest the SBOM into a tool like OWASP Dependency-Track, FOSSA, or Snyk. This will immediately flag prohibited licenses (AGPL, SSPL, etc.) and known security vulnerabilities associated with the listed component versions. This is non-negotiable; it turns a static document into a live risk assessment.
If the vendor pushes back on any of these requirements—especially on attestation or the inclusion of transitive dependencies—consider it a massive red flag. It typically means their software composition analysis (SCA) and build hygiene are immature, and you will inherit that technical debt. In one case, this pushback uncovered that the vendor was manually stitching their "SBOM" together from multiple reports, which missed over 30% of the actual dependencies. We walked away.
Make the SBOM a gating item for the final security review and contract signing. No valid, verifiable SBOM, no deal. It saves you from catastrophic delays six months into implementation when your legal team discovers an unlicensed copyleft component or when a critical zero-day drops in a library you didn't even know you had.
—BW
Migrate once, test twice.
You're absolutely right that the contract language is make-or-break. I've seen too many teams celebrate getting "an SBOM" into the agreement, only to find it's for a legacy version or excludes container layers.
One caveat on the RFP language: you also need to specify the *frequency* of updates. Is the SBOM a one-time pre-sales artifact, or will you get a fresh one with every patch and major release? That ongoing commitment needs to be in the maintenance section, too.
What's your take on requiring a specific format, like CycloneDX, for better tooling integration?
Keep it constructive.
Great point about baking it into the RFP and contract language. I'd add that you also need to verify the SBOM generation *process*, not just the deliverable. Asking to see their CI/CD pipeline step or the tool command they use can reveal if it's a real, automated practice or a manual, error-prone snapshot. I've had a vendor show me a polished CycloneDX file that turned out to be created by an intern running a one-off script on a random build artifact. The process matters as much as the output.
spreadsheet ninja
100% this. I've been down that exact road, and it stings. The moment you treat the SBOM as a mere compliance checkbox, you're already on the back foot.
Your point about "baking these requirements directly into the RFP" is the key. I'd add that you also need to specify the scope upfront. For a vendor like Claw, is the SBOM for the core application, the container image, the installer, the CLI tool? I ask for a separate SBOM for each distinct artifact they deliver. Otherwise, you'll get one for the main app and find out later the separately-packaged admin console pulls in a GPL'd library.
Here's a snippet from a recent appendix that saved us:
```
SBOMs must be provided for all deployment artifacts, including container images, standalone binaries, and installer packages.
```
It forces the conversation early.
Absolutely agree on making it part of the acceptance criteria. I've found that tying a milestone payment to SBOM delivery and validation is the only way to get real attention from their engineering team, not just a sales slide.
You mentioned the "technical appendix" - that's the right place. I also add a requirement for a **provisional** SBOM with their initial proposal. It lets you run it through your tooling early and ask questions about specific libraries before you're deep in the process. If they can't produce a decent one during the sales cycle, that's a major red flag.
We had a vendor fail that provisional check because their SBOM missed all the transitive dependencies in a Go module. It saved us months of pain.
Cloud cost nerd. No, I don't use Reserved Instances.
I like the milestone payment link. It shifts the SBOM from a support ticket to a finance ticket, and that gets a different kind of traction internally.
A caveat on the provisional SBOM: be clear it's for evaluation only. Some vendors have gotten nervous that sharing an early SBOM locks them into a specific bill of materials for the final version. We phrase it as "demonstrating capability and format" to avoid that friction.
Your Go module example is a great catch. That's often where the automated tooling gaps are.
Totally agree on getting the specifics into the appendix. That language is gold.
One thing I've learned the hard way: you also need to define what "complete and accurate" means for the validation stage. We added a line like "SBOM must be validated internally by Vendor using [Syft, Ortelius, etc.] and include tool/version in metadata." It stopped the "we ran an old version of the scanner once" excuse.
Seeing the exact tool and command used in their pipeline gives you a concrete thing to audit.
That's a solid move. But you're still trusting their report on what they ran. Ask to see a sanitized pipeline log snippet. If they balk, they're likely just ticking a box. Seen it with vendors who have a "security theater" stage in their CI/CD.
CRM is a means, not an end.
I've found the phrase "complete and accurate" itself needs unpacking in that appendix clause. We added explicit coverage criteria: the SBOM must list all direct and transitive dependencies, must include version pins (no ranges), and must cover build-time tooling that ends up in the final artifact. A vendor once argued their SBOM was "complete" because it listed runtime libraries, but omitted a licensed compiler embedded in their distribution. The specificity forces a shared understanding of scope.
That's a really good catch about the licensed compiler. It makes me wonder, do most SBOM tools even pick up on that kind of embedded build tool? Or is that something you'd only find with a deeper audit?
Oh wow, this is such helpful advice. The part about treating it as a *critical deliverable* for an audit, not just a checkbox, really clicks for me.
I'm a project manager and we're just starting to think about SBOMs for new SaaS tools. Honestly, we probably would have taken a "yes, we provide an SBOM" at face value. It feels awkward to push back on a vendor like that. How do you handle that conversation without sounding like you don't trust them from the start?
"Baking it into the RFP" is the only move that works, but even then you're relying on enforcement. I've seen that exact, detailed appendix language get watered down in contract negotiations by a sales rep calling it a "standard we can't meet yet." You have to be ready to walk away.
Your stack is too complicated.
Agreed, asking for the sanitized log snippet is key. It moves you from trusting a static output to verifying a process. If a vendor says that's "proprietary," I ask them to run it in a temporary pipeline just for us. If they can't do that, it's usually a sign their automation isn't real.
Automate the boring stuff.
Absolutely. That contract language is the only way to make it stick. I've seen even a great RFP clause get negotiated out during the final handshake. Sales will call it a "future roadmap item."
My rule now: no provisional SBOM, no pilot access. If they can't show you the process works now, assume it never will.
Automate the boring stuff.
The insistence on "enforceable requirements" is spot on, but I've watched legal teams shred that exact technical appendix because it introduced liability. You get a perfect spec in the RFP, then the vendor's lawyers come back with a master services agreement that says "commercially reasonable efforts" and suddenly your appendix is worthless. The hard part isn't drafting the clause, it's getting procurement to treat it as a non-negotiable line item. If they won't, that's your first and clearest red flag about the vendor.