Skip to content
Codenotary
All posts

sbom.sh: Your Ultimate SBOM Management Solution

Introduction

Have you ever received an email informing you that the Software Bill of Materials (SBOM) you requested is ready? Whether it's from a vendor, an internal project, or your own team, receiving an SBOM can be a critical moment. However, navigating the world of SBOMs can be overwhelming, especially if you're unsure where to start.

Don't worry, we've got you covered. In this brief but comprehensive guide, we'll walk you through the basics of SBOMs, how to view them, ask essential questions, and where to go next. Plus, we'll introduce you to sbom.sh, a new service that simplifies SBOM management.

Brown Peach Illustrative GreetingsSlogans Banner Landscape (2)-1

Understanding Your SBOM

A Software Bill of Materials (SBOM) is a comprehensive list of third-party software components used in a software project. It typically includes open-source packages, libraries, commercially licensed components, and potentially even components with unique licenses. SBOMs are invaluable for understanding software dependencies, identifying security vulnerabilities, discovering unsupported software, and addressing architectural and support issues.

Your SBOM should include essential information like the component name, version, and license details. It may also contain additional data such as project URLs, descriptions, known vulnerabilities, and more. However, the quality and completeness of this information can vary due to evolving exchange formats and OSS scanners.

Different SBOM Formats

There are three main formats for sharing SBOMs: CycloneDX, SPDX, and free text files.

  • CycloneDX, created by the OWASP Foundation, is commonly found in files with names like bom.json, bom.xml, or with extensions like .cdx.json or .cdx.xml.

  • SPDX, developed by the Linux Foundation, can be identified by file names like .spdx, .spdx.json, or .spdx.rdf.xml.

  • Free Text, CSV, or Excel files are traditional formats that may contain SBOM information in less common formats, often designed for human review.

While many formats exist, we focus on the .json formats for CycloneDX and SPDX when it comes to sbom.sh. Please let us know if you need support for other formats.

How to View and Process SBOMs

The easiest way to gain insights from your SBOM is to use sbom.sh as it's a free and open-source tool that provides information about known vulnerabilities and license details for open-source components in SBOMs.

It supports CycloneDX files in JSON format, SPDX SBOMs in JSON format. If you receive a file in a different format, you can convert it or request your partner to provide it in a compatible format. There is also a container image ready for you, that has all the open-source tools built-in:
https://github.com/codenotary/sbom.sh-container

It contains, trivy, syft and grype for a smooth and simple SBOM generation for Git repos, Container images, or your local file system:

https://github.com/codenotary/sbom.sh-container#running-the-container

Visit sbom.sh to simplify your SBOM management with user-friendly tools and services.

Examining SBOMs Manually

While using a tool like sbom.sh is more convenient, you can also manually examine SBOMs by inspecting JSON or XML files in a text editor. Look for tags like "name," "version," "bom-ref" (URL or locator), and "license" to gather information about components. You can use this information to search for vulnerabilities and other relevant data online.

Nevertheless, sbom.sh makes your life easier and automatically runs a quality score using sbomqs.

What to Look for in Your SBOM

Now that you can view your SBOM, here are some critical questions to consider:

  • Is the SBOM legitimate, readable, and up-to-date?
  • Does it include transitive dependencies (dependencies of dependencies)?
  • Are there well-known vulnerabilities in the codebase?
  • Do you spot any open-source licenses that might conflict with your company's policies?
  • Is the SBOM complete and accurate?
  • Are there any unexpected software languages or missing components?

Collaboration and Feedback

After processing your SBOM, you may have questions or feedback for the team that provided it. You can request more information about security vulnerabilities or licensing issues found in the report. Effective communication with your supplier is essential for addressing potential vulnerabilities and improving supply chain management.

The unique URL for sharing comes in handy when it comes to collaboration - simply send the unique URL to your team. No signup or login is required.

Keep Demanding High-Quality SBOMs

Requiring SBOMs from your suppliers has several benefits, including encouraging them to implement Software Composition Analysis (SCA) scanning tools and CVE/Vulnerability Patch Management. A well-understood product is a more secure one, and by reviewing and providing feedback, you can help ensure the quality and security of the software components you rely on.

SBOM.sh Social Preview

Visit sbom.sh today and simplify your SBOM management process. Upload your SBOM JSON file, retrieve a unique URL, and access your SBOM data with ease. Whether you prefer using the curl command or your web browser, sbom.sh has you covered. Make SBOM management a breeze and don't miss out on the opportunity to streamline your software supply chain and enhance your security posture.

Get started with sbom.sh today and take control of your SBOMs like never before!