As software supply chain risks grow (and applications grow ever more complex), it’s become increasingly important to build as much automation as possible throughout the SBOM management lifecycle.
Of course, there will always be manual elements to SBOM management. These include making decisions about preferred SBOM formats, creating policies that determine which metadata suppliers must include in their SBOMs, and so on. But using the right automated tools and workflows can go a long way toward unlocking the benefits of a comprehensive SBOM program — supplier risk management, regulatory compliance, software supply chain security, and more — without slowing down development or burdening engineering.
In this blog, we’ll break down the SBOM management lifecycle into eight key areas, with a focus on where automation can be built into each.
Step 1: Pick and Integrate an SBOM Management Tool
Start by choosing an SBOM tool that supports both generation (from source or binaries) and ingestion (from suppliers). For SBOM generation, integrate the tool into your GitHub repo or CI pipeline to produce SBOMs automatically on each build or release. Make sure the tool supports SPDX and CycloneDX, detects transitive dependencies, and works across all major ecosystems and languages.
For ingestion, look for the ability to upload supplier-provided SBOMs in both CycloneDX and SPDX.
Key Automations: Selecting a tool will of course be a somewhat manual process, but getting the right solution in place (that tightly integrates with your development environment) is vital to enabling the automations in future steps.
Step 2: Set Policies
Define policies that establish acceptable conditions for licenses, vulnerabilities, and supplier-provided SBOMs. These policies will serve as the guide for making SBOMs actionable and automatable.
- Licensing policies: Determine which licenses should always be accepted, flagged, and denied
- Vulnerability policies: Severity thresholds for vulnerabilities (e.g. fail builds on “critical”)
- SBOM policies: Decide which format, metadata, scope, unique identifiers, and dependency depth suppliers must include in the SBOMs they provide.
Key Automations: Your licensing and security policies will form the foundation for automated workflows that help address vulnerabilities and high-risk licenses. If your SBOM tool detects a license or vulnerability (associated with your SBOM) that conflicts with your policies, it should automatically be able to create an issue.
Additionally, tools that support SBOM ingestion policies will significantly cut down on the back and forth between the SBOM provider and consumer (since the provider will be able to see whether their SBOM is policy-conformant directly in the SBOM tool).
Step 3: Scan and Ingest
With policies in place, start building the inventory you’ll need for a complete, application-level SBOM. This includes both scanning your own projects and, if applicable, ingesting SBOMs from suppliers.
Scan your own codebase
Use the SBOM tool to scan your application’s codebase and identify all components.
Ingest SBOMs from suppliers
If you use third-party software or have external software suppliers, import the SBOMs they provide into your SBOM management tool. Feeding these supplier SBOMs into your tool lets you analyze them just like your own SBOM.
Key Automations: Several parts of the scanning and ingestion process are automatable. These include:
- You should have the ability to configure your SBOM tool to automatically scan your projects (and create your list of dependencies) directly from CI.
- Your tool should automatically create a list of licenses and associated vulnerabilities following your scan.
- Your SBOM tool should automatically populate a list of dependencies, licenses, and vulnerabilities after it analyzes an ingested SBOM.
Step 4: Combine into an Application-Level SBOM
Merge SBOMs from all sources into a single, application-level SBOM per release. This unified view is what customers and regulators typically expect.
A good tool will support grouping components by release and maintaining a full dependency tree across your software architecture. This gives you visibility into your entire software stack — both what you build and what you buy.
Key Automations: The key automation in this step is your tool’s ability to aggregate all sources into a single view in a matter of a few clicks. (As opposed to the painful process where you might have to manually select each individual dependency you want included.)
Step 5: Analyze and Act
This is the part of the SBOM lifecycle where the policies we previously discussed serve as a major unlock. Once your policies are in place, your tool should automatically be able to surface issues and take action.
Key Automations:
- As part of the SBOM generation process, your tool should be able to automatically create lists of associated security and licensing issues. These issues should be created based on your policies — e.g. an issue would be created if you have a rule prohibiting copyleft licenses.
- Similarly, your tool should be able to automatically create issue lists based on its analysis of supplier-provided SBOMs.
- If your SBOM tool is integrated into CI/CD, it can use the policies from step 2 to automatically enforce standards. For instance, a build can be failed or an alert raised if a newly introduced dependency has a critical vulnerability or a disallowed license
- If and when you close out issues (e.g. by updating a package version or if you determine a vulnerability doesn’t actually impact your code), your tool should automatically create VEX attestations so your SBOM consumers can understand their risk exposure.
Step 6: Configure the Output
Before distributing your SBOM to others, configure and fine-tune the SBOM document to meet the needs of your consumers and any applicable standards:
- Format: Choose SPDX or CycloneDX based on consumer requirements.
- Metadata: Decide what fields to include in the SBOM version.
- Dependency Depth: Determine whether your SBOM will list only direct dependencies or the full dependency tree.
Key Automations: The key automation in this step is the ability to quickly manage these configurations. Your tool should allow you to set format, metadata, and dependency depth in just a few clicks. Or, better yet, some tools (like FOSSA) come with pre-configured SBOM report structures that are explicitly designed for specific SBOM compliance requirements (e.g. the FDA’s).
Step 7: Generate & Share
Export your final SBOM, along with any applicable VEX statements. Share it securely via a portal, artifact repository, or encrypted channel — not over email. For instance, some platforms allow you to host SBOM files and invite specific partners or customers to access them under role-based access control and with encryption in transit and at rest. This way, only authorized recipients can view the SBOM, and you can even set time-limited access if appropriate.
Always ensure the recipient can ingest your chosen format and understands what the SBOM covers.
Key Automations: The key automation in this step is the ability to both generate and share your SBOM in just a few clicks. Specifically:
- SBOMs should be automatically updated when new scans are triggered.
- You should have the ability to securely share the updated SBOM document natively, within the SBOM tool itself (rather than having to download and email it).
- Integration with your ticketing system of choice (JIRA, Github Issues, etc.) to enable end-to-end SBOM automation
Step 8: Monitor and Manage Over Time
The final step of the SBOM lifecycle is the ongoing work of monitoring and management. This starts with having a process for keeping the SBOM updated over time (across new versions), and it includes continuously monitoring the SBOM for new associated vulnerabilities and/or licensing conflicts.
Key Automations: Automation is particularly critical for making ongoing SBOM management scalable and efficient. Here’s why:
- Regular SBOM Updates: Each time you release a new version of your application or update its dependencies, you’ll want to generate a fresh SBOM. Automate this in your CI/CD so that every build that goes to production has an associated SBOM.
- Supplier SBOM Updates: Similarly, if you rely on supplier-provided software, you should expect updated SBOMs from them whenever their software changes. Put processes in place (or get them connected to your SBOM tool of choice) with your suppliers so that whenever they issue an update or patch, they also provide an updated SBOM as well as dynamic notification of exploitability for net-new vulnerabilities released on existing SBOMs.
- Issue Monitoring and Management: Your tool should have built-in automation that alerts you if vulnerabilities are reported against the dependencies in your SBOM. The same holds true for potential license changes that conflict with your policies.
Learn More: SBOM Lifecycle Automation
For more information on SBOM management, consider checking out the following resources:
- Allan Friedman on 4 Stages of SBOM Management: Leading global SBOM and software transparency expert Allan Friedman analyzes several major SBOM compliance requirements.
- SBOM Policies in FOSSA: See how FOSSA’s SBOM management tool makes it easy for software providers and consumers to exchange SBOMs.
- FOSSA SBOM Management Demo: Get in touch with our experts to see how FOSSA can help your team or organization automate SBOM management.