In an increasingly interconnected world, the need for transparency in software development has become paramount. Software Bill of Materials (SBOM) generation is a critical activity in software development that enables organizations to understand the components within their software, identify vulnerabilities in third party open source components, manage Open Source Software (OSS) license risk and identify outdated open-source components. As more regulatory bodies, like CISA and NTIA, set forth guidelines, it’s essential to adhere to best practices in SBOM generation to maintain the highest quality standards. The practice is also being accelerated as governments and companies are demanding that their software suppliers provide a quality SBOM with software to provide them with confidence about the asset contents and any associated risks.

What Is An SBOM?

An SBOM is a detailed inventory of the components used within a software product. This list includes details of open-source components, third-party commercial components, and proprietary components. An SBOM can significantly improve the security and compliance posture of a software supply chain by providing visibility into potential vulnerabilities, license risks and other issues in the supply chain.

Best Practices for SBOM Generation

1. Automate SBOM Generation: Automating the creation of SBOMs during the CI/CD pipeline ensures that they are always up-to-date. Tools like syft and cdxgen, can be integrated into your DevSecOps workflows to automatically generate SBOMs as part of your build process.
Example:
syft app:1.4 -o cyclonedx-json > bom.json
cdxgen -r -o bom.json -p

Automation reduces human error and guarantees that SBOMs are consistently generated at every build stage. Furthermore, it facilitates timely updates which are critical for identifying and mitigating newly discovered vulnerabilities.

2. Include Comprehensive Component Data: An effective SBOM should minimum follow the NTIA minimum SBOM fields requirements. This includes the supplier name, component name, version of the component, other unique identifiers, dependency relationship, author of the SBOM data and a timestamp. It’s crucial to have a detailed record to identify vulnerabilities quickly and respond to security incidents.

Consider a company that identifies a high-severity vulnerability in one of its open-source components. By using a detailed SBOM, the security team can quickly pinpoint all the affected software versions and help developers to initiate the remediation processes quickly, and avoid a costly breach. Without an accurate SBOM, the team would have had to manually search through their software, increasing response time.

3. Ensure Data Accuracy: The quality of an SBOM is directly tied to the accuracy and completeness of the components. Validate and verify the components data to ensure that the SBOM accurately reflects the software components and their associated risks. This includes regularly updating SBOMs to reflect any changes or updates in the software.

Risks Associated with data inaccuracy in an SBOM

  • Vulnerability Exposure: Critical vulnerabilities may be overlooked, increasing the risk of exploitation.
  • Compliance Issues: Non-compliance with regulatory/customer requirements could result in fines or legal actions.
  • Delayed Incident Response: Slower identification of affected components can delay mitigation efforts.
  • Licensing Risks: Misidentification of open-source licenses can lead to legal and financial penalties.
  • Undermined Trust: Inaccurate SBOMs can damage stakeholder trust and the organization’s reputation.

Integrating SBOM analysis tools like OWASP Dependency-Track allows real-time monitoring of third-party components for newly discovered vulnerabilities. This tool cross-references your SBOM with databases of known vulnerabilities, and for the accurate vulnerability identification we have to ensure that SBOM data is accurate and actionable.

4. Implement Version Control for SBOMs: Like code, SBOMs should be version-controlled. This allows teams to track changes over time, audit historical data, and understand the evolution of the software components. OWASP Dependency-Track can track changes in an SBOM by managing SBOMs with different versions of the same component.

By managing SBOMs with different versions of the same component, teams can trace the origin of vulnerabilities and understand when a particular issue was introduced. Version control also facilitates faster incident response, as development teams can rollback or update components based on historical SBOM records.

5. Integrate with SBOM Analysis Tools: Tools like OWASP Dependency-Track will identify know vulnerabilities in Third-Party Open-Source components

6. Maintain An SBOM Across the Software Lifecycle: SBOMs are not just only generated in development phase; they should be maintained and updated throughout the software lifecycle, including post-deployment. This ensures that any new risks are identified and addressed promptly.

For example: A large enterprise continually updates its SBOMs across the complete Software Development Lifecycle. When a critical vulnerability is discovered in an open-source component, the team rapidly assesses all SBOM of the same build to identify in which stage of the Software Development Lifecycle. By maintaining SBOMs in various stages of the Software Development Lifecycle, the organization can mitigate the risk quickly.

7. Score SBOM Quality: Use tools like SBOM Scorecard, and sbomqs to assess the SBOM’s quality and to check whether your SBOM fulfills the minimum NTIA requirements.

Example:

sbomqs dtrackScore  -u <dt-host-url> -k <dt-api-key> <project-uuid>

sbomqs dtrackScore -u -k sbomqs dtrackScore -u “http://localhost:8080/” -k “IIcfPA9qc1F4IkQFa2FqQJoTwcfQI” bbd4434d-8062-4e59-a323-3b416701c948

sbom-scorecard score examples/bom.json

Scoring SBOM quality helps teams understand gaps in their SBOMs and improves the overall software supply chain security.

Conclusion

Generating a high-quality SBOM requires a combination of automation, adherence to industry standards and meticulous attention to detail. By following best practices and incorporating key fields as recommended by industry leaders like CISA and NTIA, organizations can significantly enhance their software security and maintain compliance with regulatory requirements.

Embracing SBOMs as a fundamental part of your software development process is not just a best practice; it’s a necessary step in safeguarding the integrity of your software supply chain.