The SBOM Mandate
With the introduction of Executive Order 14028, the US government began mandating SBOMs (Software Bill of Materials) for all vendors selling software to the federal government. This requirement has had a cascading effect throughout the software industry, particularly in compliance. From the EU's Cyber Resilience Act (CRA) to the NIST Cybersecurity Framework, SBOMs are set to become the standard for transparency in the software supply chain. If your organization hasn't adopted SBOMs yet, the clock is ticking.
Learn More
The SBOM Life Cycle
The SBOM life cycle consists of three parts: generation, distribution, and analysis. sbomify focuses on the distribution aspect. SBOMs are typically used by both internal and external stakeholders, such as customers. After speaking with CTOs and CSAs, it became evident that most SBOM distribution today is still done via email, reminiscent of how we used to email software patches in the 90s, which were then stored haphazardly on internal file shares. This approach introduces numerous issues, including unnecessary labor and the risk of working with outdated data. Distribution, also sometimes known as Transport, should be automated and seamlessly integrated into the CI/CD workflow, and this is precisely what sbomify offers.
Learn MoreThe SBOM Hub
SBOMs are as fresh as milk — they can change with every CI/CD run, depending on how dependencies (and sub-dependencies!) are managed. This makes it crucial to use a collaborative platform for SBOM management. Enter sbomify. Whether you're a software buyer or producer who are looking to set up an SBOM vendor portal, using sbomify will simplify your SBOM process.
You can seamlessly invite internal stakeholders to sbomify, allowing them to automatically access the most up-to-date SBOMs for your product, or even specific components for more granular control. These SBOMs can then be easily exported to third-party tools for further analysis, such as security or license audits.
Learn More
SBOMs Done Right
Building an SBOM for a simple microservice or dependency file is straightforward. However, this approach is far from representative of your entire product or service. Your backend likely consists of at least a handful of different services, potentially written in various languages and running in separate Docker containers. On top of that, there are probably front-end components that also need to be captured. Creating SBOMs that accurately reflect your entire product or service could result in generating at least a dozen SBOMs. Even with automated tools, sharing all of these with stakeholders can lead to confusion. At sbomify, we’ve addressed this by introducing hierarchical grouping through products, projects, and components.
Learn MoreLatest blog posts
GitHub Action module with Attestation
Over the last few weeks, we’ve made some significant updates to our GitHub Actions module. Since our last update, we’ve added a few new features.
Big update to our GitHub Action
In the last few weeks, we’ve worked hard on overhauling the sbomify GitHub Action based on customer feedback. The initial purpose of the GitHub Action module was merely...
How to generate an SBOM from a Docker container
A lot of people are asking about how one can generate an SBOM based on a Docker container. It seems to be a good idea, since a lot...