TIL: How to ask for and verify SBOMs during the Claw vendor evaluation.

Just spent three months untangling a "modern" CRM platform that turned out to be a Frankenstein's monster of outdated, vulnerable OSS libraries. Their sales demo? All shiny UI and AI promises. The reality in production was a compliance nightmare.

Now I demand a Software Bill of Materials (SBOM) in every security and integration evaluation. Most vendors will claim they have one. Here’s how to ask for it and, more importantly, verify it’s useful.

**The Specific Request:**
Don't just ask for "an SBOM." Be precise. In your security questionnaire or RFP appendix, require:
* **Format:** SPDX or CycloneDX, in a machine-readable format (JSON, not a PDF screenshot).
* **Scope:** Must cover the entire application stack you're licensing, including all direct and transitive dependencies.
* **Freshness:** Generated within the last 30 days of your request, not a static document from a year ago.
* **Depth:** Must list components down to the package/version level, with declared licenses and CPE/PURL identifiers.

**Verification Steps (The Part Everyone Skips):**
Getting the file is step zero. You need to check it.

1. **Validate the file.** Use the CLI tools from the SPDX or CycloneDX projects to check it's valid.
```bash
# Example for CycloneDX BOM
cyclonedx-cli validate --input-file vendor_sbom.json --input-format json
```

2. **Check for critical vulns.** Pipe the SBOM into a vulnerability scanner. This is the non-negotiable step.
```bash
# Using grype with a CycloneDX SBOM
grype sbom:vendor_sbom.json -o table
```
A vendor providing an SBOM should have already done this. Ask for their most recent vulnerability scan report from a tool like Snyk or Mend. No report? Their process is theater.

3. **Spot-check for completeness.** Pick a major framework you know they use (e.g., React, Spring Boot, Log4j). Is it listed with its full dependency tree? If not, the SBOM generation is shallow and useless.

**Red Flags:**
* They provide a PDF.
* The SBOM only lists "primary" components, not transitive dependencies.
* It's older than your last major product release.
* They refuse to provide accompanying vulnerability reports, citing "security through obscurity."

This isn't about being difficult. It's about quantifying technical debt and security risk before you sign a contract. A vendor with a clean, transparent SBOM and a process to manage it has their engineering house in order. The ones that balk or hand-wave are hiding something, and you will pay for it later in integration headaches, failed security audits, or a breach.