After Log4Shell: How to Build an SBOM Program from Scratch in 2022

Step 1: Start with a Discovery Audit

Before implementing any tooling, understand the scope of what you are dealing with. Catalog your software portfolio: how many applications, services, and products does your organization build and deploy? What languages and ecosystems are involved (JavaScript/npm, Python/PyPI, Java/Maven, Go, Rust, .NET/NuGet)? What build systems are in use? Who owns each application? This inventory is the foundation for everything that follows.

Step 2: Choose Your Starting Tools

For organizations starting from zero in 2022, the pragmatic approach is to begin with open source tooling to understand the problem space, then evaluate commercial platforms based on what you learn. Start with Syft for SBOM generation and Grype for vulnerability scanning — both free, well-maintained, and covering most ecosystems. This gives you hands-on experience with SBOMs before committing to a vendor.

Step 3: Integrate Into CI/CD

The most important architectural decision in your SBOM program is that generation must be automated and continuous. An SBOM that is generated manually once per quarter is not a security tool — it is a compliance artifact that will be stale within days. Every release build should generate a fresh SBOM and store it alongside the build artifact. Every pull request should trigger a vulnerability scan against the current dependency state.

Step 4: Define Your License Policy

Work with your legal team to define which licenses are approved, restricted, and banned for your organization. A typical starting policy: MIT, Apache 2.0, BSD, and ISC are approved; LGPL and MPL require legal review; GPL and AGPL are banned for distributed products. Once defined, implement this policy as code in your SCA tool so that builds automatically fail when policy-violating licenses are introduced.

Step 5: Establish Continuous Monitoring

SBOM generation at build time catches vulnerabilities known at the time of release. But new CVEs are published every day — a component that was safe when you deployed it may become vulnerable tomorrow. Continuous monitoring compares your deployed SBOMs against the latest vulnerability intelligence and alerts you when new risks emerge. This capability transforms SBOM from a point-in-time snapshot into an active security control.

Step 6: Plan for the Regulatory Horizon

If you sell to federal agencies, FDA-regulated industries, or have significant EU market exposure, your SBOM program is also a compliance program. Align your SBOM format and data quality with the NTIA minimum elements (published July 2021). Store SBOMs with version history so you can respond to agency requests for historical component data.