SBOM Shelter in the Dependency Storm: Building Resilience Brick by Brick

Josh Sokol, the creator of the open source governance and risk tool SimpleRisk, walks through how his project went from scattered, hand-tracked dependencies to automated software bill of materials (SBOM) generation. He starts with the project's early history, when the codebase held a few third-party libraries stored in several folders. By 2021 the sprawl had grown: multiple copies of jQuery, including one several years old, and no clear record of where each component lived or which license applied.

The middle of the talk covers the steps taken to regain control. The team first listed each component with its location, version and license, then moved PHP packages into Composer and JavaScript packages into Yarn. Dependabot added vulnerability alerts and pull requests for updates. In the CI/CD pipeline, GitHub workflows check licenses against an approved list, and CycloneDX tools generate an SBOM for each pull request, stored as a build artifact and merged into one file. Dependency-Track ingests the results to flag known vulnerabilities. Sokol also stresses pinning exact versions to avoid surprise breaking changes, and keeping vendored code in its own directory.

The closing takeaways are to move in small steps, to treat dependency updates as changes that need testing, and to expect customers and government buyers to ask for SBOMs. Sokol presents the SBOM as a practical way to show transparency and leadership to customers.