As Software Bill of Materials (SBOM) adoption efforts mature, a report recently released by the Cybersecurity and Infrastructure Security Agency (CISA) provides guidance to users in selecting suitable SBOM sharing platforms based on the amount of time, resources, subject-matter expertise, effort, and access to tooling available to them to implement a phase of the SBOM sharing lifecycle. The lifecycle has three phases: discovery, access, and transport.

A software bill of materials (SBOM) is a comprehensive, structured inventory of all components, libraries, and dependencies used within a software product or application. It typically includes information about the names, versions, and licensing details of each component.

Today, we’re excited to launch a few new features as part of our ongoing efforts in our Software Supply Chain Security solution. These developer-first tools help you gain a better understanding of your app’s supply chain, identify potential risks, and take the necessary steps to get ahead of them.

We are excited to share a new Bytesafe feature that will help you manage and secure your supply chain: the ability to import Software Bill of Materials (SBOM) files into Bytesafe. This enhancement, designed with our users' needs in mind, is a significant stride towards improved software supply chain security. It offers a solution to track current and potential vulnerabilities in your dependencies without sharing your proprietary source code or other sensitive data.

As the software bill of materials (SBOM) becomes ubiquitous for compliance and security purposes, what has previously been a nice-to-have option is fast becoming indispensable. If you want to do business with significant partners, such as public and federal organizations, and if you want to grow your business by floating your company or engaging in M&A activity, then you’re going to need SBOMs. This demand is driven by two key trends, one technical and the other legislative.

The Apache Log4j vulnerability has been making global headlines since it became public on 9th December 2021. The report stated that the vulnerability affects Apache log4j between versions 2.0 and 2.14.1 and is independent of the underlying JDK version. It was a full-blown security meltdown that resulted in hackers performing remote code executions and affected digital systems across the globe. In response, Apache implemented patch fixes, but some components remained unattended.