SBOM, OSV, and the number that matters more than zero

Federal procurement, defense customers, and enterprise diligence all ask the same four questions: What is in your software? What is its license posture? What was its known-vulnerability state at a given moment? Can you prove how it was built? Git history answers none of these.

We are the chain anchor, not the scanner. That single sentence decides what this product is and — more usefully — what it will never become.

Bundling scanners expands the maintenance surface without bound, creates fork drift, narrows license coverage, and asks a security team to replace a scanner they have tuned for three years. That is how you lose the deal.

The one exception, and why it moved

SecureGit bundles a vulnerability-database lookup client, not a scanner. Given a package and a version from an existing SBOM, it queries a public vulnerability database and returns known advisories. Stateless. No local database. No manifest parsing. No dependency-tree resolution. The customer already did the hard part when they generated the SBOM. This adds a search step, not an analysis step.

Four safety properties worth stealing

1. Opt-in, never default. The lookup is an explicit flag. A security tool making a surprise outbound request is a finding, not a feature.
2. The anchor never waits on the scan. If the lookup fails, the SBOM receipt still succeeds and the scan is recorded as degraded.
3. scan_completeness is a first-class field, 0 to 1. “0 CVEs” without completeness = 1.0 is not a clean bill of health.
4. Absence is not evidence of absence. If no vulnerability receipt exists, the correct reading is “no scan was run,” not “no vulnerabilities.”

<your-sbom-generator> | securegit sbom emit --with-osv-scan
securegit sbom rescan <receipt-id>