Skip to content
Codenotary
All posts

Simplified SBOM Sharing with sbom.sh

In today's world of interconnected systems and applications, where software errors and vulnerabilities can have far-reaching consequences, it has become essential to prioritize software security. To mitigate the risks associated with software supply chain attacks, sharing Software Bill of Materials (SBOM) has gained significant momentum. This blog post will explore why sharing SBOMs is vital for software transparency and discuss how to generate SBOMs using sbom.sh efficiently.

Brown Peach Illustrative GreetingsSlogans Banner Landscape (1)

But first, let’s look at why sharing SBOM files is important:

Enhancing Software Transparency

The software supply chain is complex, involving various components from multiple vendors. By collecting and sharing SBOMs, organizations gain a comprehensive understanding of the software they are utilizing, including its dependencies, components, and versions. This transparency helps identify potential security vulnerabilities and manage any emergent risks effectively. That's also the reason why SBOM quality is very important. 

Rapid Vulnerability Response

SBOMs are valuable in quickly addressing security vulnerabilities. When a software vulnerability is discovered, sharing an SBOM allows affected parties to promptly identify and address the precise components or dependencies that need to be updated or patched. Consequently, this expedites the response time, reduces the potential for exploitation, and safeguards the software ecosystem.

Streamlining Compliance Efforts

With increasing regulatory requirements, such as Open Source Software (OSS) compliance and privacy regulations, SBOMs contribute to streamlining compliance efforts. By maintaining an up-to-date and accurate SBOM, organizations can quickly identify and manage any open-source components used, ensuring compliance requirements are met and mitigating any licensing or legal issues that might arise.

Fostering Trust and Collaboration:

Sharing SBOMs across the software supply chain promotes trust and collaboration. It enables organizations to demonstrate their commitment to security and transparency, fostering relationships based on trust with customers, vendors, and partners. Communication and collaboration regarding SBOMs facilitate open dialogues around vulnerability management, leading to more reliable, secure, and resilient software.

Using sbom.sh to Generate and Share SBOMs

Now that we understand the significance of SBOMs, let's explore a powerful tool, sbom.sh, an extremely simple cloud service, sponsored by Codenotary Inc (www.codenotary.com)  sbom.sh simplifies the collecting, analyzing, and sharing CycloneDX formatted SBOMs. 

CycloneDX is an open standard for generating and sharing SBOMs, including a  comprehensive list of all the components and dependencies used in building software.

It provides a standardized and machine-readable format for representing these components, their versions, and their relationships, allowing for better visibility and understanding of an application's supply chain.

The CycloneDX format supports a wide range of software components, including libraries, frameworks, modules, and even operating system binaries. 

To make sure the SBOM quality is good we use sbomqs.

Step-by-Step Guide on Using SBOM.sh

To use sbom.sh we first need one of a choice of tools that create SBOMs for either containers or Github repositories or from local directories. We like trivy a lot for this purpose. 

Trivy is an open-source vulnerability scanner that focuses specifically on container images and applications.  Other open source tools are syft, grype and many more are supported as well as long as they can produce a CycloneDX conform SBOM file. 

The easiest way to generate and send an SBOM to sbom.sh is using the all-in-one container image: codenotary/sbom.sh

You can find more information about the scripts and commands used here: https://github.com/codenotary/sbom.sh-container

As an example, generate and send an SBOM for the latest PostgreSQL container image using your local docker command is:

docker run codenotary/sbom.sh trivyimage postgres

If you have some tool already installed and a local SBOM file at hand, simply run:

curl -T someSBOM.json https://sbom.sh

In both cases, you get a unique URL as the command output that you can either use to download the SBOM file at any time in the future or to view it in the browser. That unique URL can simply be shared with anyone who should look or work with it.

You can also search, filter, and sort the vulnerabilities and components that are in that SBOM file:

 

Conclusion

Using sbom.sh is straightforward, thanks to its compatibility with various tools like Trivy, Syft, Grype, and more. Whether you're working with containers, GitHub repositories, or local directories, sbom.sh offers a convenient solution. With just a few simple commands, you can generate SBOMs and share them via unique URLs, allowing easy access and collaboration for all stakeholders. It empowers organizations to proactively manage and secure their software supply chains, promoting a safer and more transparent digital landscape. Embrace the power of SBOMs and sbom.sh to fortify your software against vulnerabilities and enhance the trust and collaboration within your software ecosystem.