The Current State of Open Source Security Compliance Tooling Is … Well, Sad.
summary
A recent study finds many generated SBOMs are invalid JSON and tools disagree on identifiers, with inconsistent CycloneDX outputs and mismatched package URL strings causing false positives and false negatives. An implemented aggregator, VulnerableCode, reuses Google OSV code and required two months to reconcile an NGINX advisory’s affected versions, showing provenance gaps. Proprietary feeds lock key security data behind paywalls; practical fixes include open reference data, reachability analysis, linking CVEs to working proofs‑of‑concept, and prioritization for CVSS≥7 (FedRAMP).
AI-written summary · about
chapters (8)
- 0:00Introduction and background
- 1:04Problems with compliance tools
- 3:51Data as the critical issue
- 8:30Community initiatives and solutions
- 9:15Handling false positives in compliance
- 12:22Prioritizing vulnerabilities effectively
- 15:29False positives and dependency fatigue
- 16:54Focus on runtime code, not dependency graphs
related talks
44mNavigating Open Source and Open Standards for Better Cybersecurity
27mSecuring Open Source With SBOM: From Visibility To Trust
52mCollaborating to Improve Open Source Security: How the Ecosystem Is Stepping Up
24mLessons from OSV: Vulnerability Management for Open Source
36mOur dependency on Open Source is scary. SLSA, SBOM and Sigstore to the rescue
41mBack to Security Basics: Evaluating, Consuming, and Contributing Open Source...
30mOpen Source Malware or a Vulnerability? The Philosophical Debate and How To Mitigate
12mKeynote: DevSecOps and the Art of Not Ending Up On the Front Page