CISA's updated SBOM minimum elements have arrived, incorporating over 90 public comments. You're now faced with four new required fields: Component Hash Algorithm, Component License, SBOM Tool Name, and SBOM Generation Context. The question is, which implementation path suits your organization?
Here's how to decide.
The Decision You're Facing
You need to generate SBOMs that meet the updated minimum elements. The choice isn't whether to implement them, supply chain security requirements are mandatory, but how to implement them across your software portfolio.
Choosing the wrong path wastes engineering time generating SBOMs nobody can use. The right path provides actionable supply chain visibility that reduces risk.
Key Factors That Affect Your Choice
Your software composition matters more than your team size. Three variables drive your implementation strategy:
What percentage of your codebase is open-source versus proprietary? Open-source components need different tooling than custom code you build in-house.
Are you shipping AI models or ML components? These require SBOM generation at training time, not just build time.
Who needs to consume your SBOMs? Internal security teams have different requirements than customers or regulators.
Path A: Build-Time SBOM Generation
Choose this if: You're shipping compiled applications with well-defined dependency trees, your build pipeline already runs in CI/CD, and you control the deployment environment.
This path works when you can answer "yes" to these questions:
- Do you use package managers that lock dependencies (npm, Maven, pip with requirements.txt)?
- Can you modify your build scripts without approval from 15 people?
- Are your SBOMs primarily for internal security scanning?
Implementation steps:
Add SBOM generation to your existing CI/CD pipeline. Tools like Syft or CycloneDX can run as a build step and output the four new minimum elements automatically.
Configure your SBOM tool to capture Component Hash Algorithm. This isn't optional anymore, you need cryptographic verification that the component in your SBOM matches what you actually deployed. SHA-256 is the baseline; some teams use SHA-512 for higher-security contexts.
Set SBOM Generation Context to "build" and capture your tool name. When someone finds a vulnerability in six months, they'll need to know whether your SBOM reflects what you built or what you deployed.
Gotcha: Build-time SBOMs miss runtime dependencies. If your application downloads plugins, connects to external APIs, or loads dynamic libraries, you're generating an incomplete picture. Path C might be better.
Path B: Vendor-Provided SBOMs
Choose this if: You're primarily consuming third-party software, you don't have source code access, and you need SBOMs for compliance documentation rather than active vulnerability management.
This path makes sense when:
- Your software stack is 70%+ commercial off-the-shelf (COTS) products.
- You're responding to customer SBOM requests, not generating them for internal use.
- Your vendors already provide SBOMs (or claim they will).
Implementation steps:
Create an SBOM intake process. When you evaluate new vendors, require SBOMs that include all four new minimum elements. Component License matters here, you need to know if that vendor dependency includes GPL code that could affect your licensing obligations.
Don't accept "we'll send you an SBOM" as sufficient. Specify the format (SPDX or CycloneDX), require the SBOM Tool Name so you can verify it wasn't hand-written in Excel, and set a delivery timeline (within 48 hours of purchase, not "eventually").
Build an SBOM repository. You can't manage what you can't find. Store vendor SBOMs in a searchable system so when Log4Shell 2.0 drops, you can identify affected products in minutes, not days.
Gotcha: Vendor SBOMs are only as good as vendor honesty. You're trusting them to accurately report their dependencies. If supply chain security is critical (medical devices, critical infrastructure, defense), combine this path with your own verification scanning.
Path C: Runtime SBOM Generation
Choose this if: Your applications have dynamic dependencies, you're running containerized workloads, or you need to track what's actually running in production versus what you built.
This path fits when:
- You deploy containers that pull base images with unknown components.
- Your application ecosystem includes microservices that change independently.
- You need to reconcile build SBOMs with production reality.
Implementation steps:
Deploy runtime SBOM tools that scan running containers or processes. These tools inspect loaded libraries, active network connections, and filesystem contents to build a complete dependency map.
Set SBOM Generation Context to "runtime" or "deployed" to distinguish these from build-time SBOMs. When you're investigating an incident, you need to know whether the SBOM reflects theoretical dependencies or actual ones.
Schedule regular regeneration. Runtime SBOMs go stale fast. Container images get updated, dependencies change, and what you scanned last month might not match what's running today. Weekly regeneration is a reasonable baseline for most teams.
Gotcha: Runtime scanning can impact performance. Test your SBOM generation tools in staging before you run them in production, especially if you're scanning high-throughput services.
Summary Matrix
| Factor | Build-Time (Path A) | Vendor-Provided (Path B) | Runtime (Path C) |
|---|---|---|---|
| Best for | Custom applications with locked dependencies | COTS-heavy environments | Dynamic, containerized workloads |
| SBOM accuracy | High for declared dependencies | Depends on vendor honesty | Highest, reflects actual state |
| Engineering effort | Medium (one-time pipeline change) | Low (vendor does the work) | High (ongoing scanning) |
| Component Hash verification | Automatic during build | Manual verification needed | Automatic from running system |
| License compliance | Requires manual review | Vendor should provide | Discovers undeclared components |
| Update frequency | Every build | On vendor release schedule | Configurable (daily to weekly) |
You don't need to pick just one path. Most organizations run Path A for their custom code, Path B for commercial software, and Path C for production verification. The updated minimum elements work across all three, you just need to set SBOM Generation Context correctly so consumers know what they're looking at.
The Component Hash Algorithm requirement changes the game. It's no longer sufficient to list dependencies; you need cryptographic proof they match what you claim. That single field turns SBOMs from documentation into verifiable security artifacts.
Start with the path that covers your largest risk surface. If you ship custom applications, that's Path A. If you're assembling commercial components, that's Path B. If you're running Kubernetes clusters with 50 microservices, that's Path C. You can add the other paths later, but get one working first.
