Talk about Software bills of materials or SBOMs has become even more prevalent in the wake of many supply chain attacks that have occurred in the past few years. Software supply chain attacks can target upstream elements of your software, like open source libraries and packages, and SBOMs are a way to understand what’s in your application or container images.But while SBOMs are a useful piece of information, there are plenty of questions teams are asking about them: Do we need an SBOM? What do we do with them once we produce them? How can I use them during a security incident?To answer these and other questions, let’s start with what an SBOM actually is.A software bill of materials is a comprehensive inventory of all of the software components and dependencies used in a software application or system. This enables security teams as well as developers to have a better understanding of the third-party resources and imports they are using, particularly when new vulnerabilities in open source packages are constantly being discovered. To protect your organization from these threats, you first have to know what you even have in your stack.Containers have become the de facto way that developers package and ship software in today’s cloud native landscape. In the context of containers and SBOMs, the equivalent of a software bill of materials in a container is a JSON file listing all the packages, libraries and components used in both the application and the surrounding container. This package.json file includes version information of all of these components, where the package is machine-readable, which is no less important.If we were to liken this to something we’re all familiar with, this JSON is almost like the nutrition label you’d find on packaged food, but for your containerized application. This JSON file is also a point-in-time artifact, meaning it is tied to a specific SHA256 digest of a container. This differs from mutable tags like latest, in that an SBOM for a mutable tag would change over time, but not for a specific SHA256 digest.Another important aspect that your package.json provides is all the historical information that is ultimately managed by git, giving you critical retrospective knowledge of what was running in your container in any given build. This will enable you to take action when a vulnerability is discovered by knowing what is in the containers that are currently running in production. This also makes the data easier to search for rapid inventory with zero-day attacks.The Log4j zero-day attack that occurred in December 2021 was believed to have affected over 100 million software environments and applications. CISA recognized this attack as a threat to governments and organizations across the world. Cyber Safety Review Board postmortem report on Log4j backed by OpenSSF and the Linux Foundation encouraged the industry to use software component tools such as SBOMs to reduce the time between awareness and mitigation of vulnerabilities.SBOMs will make it easier for companies to understand which version of containers they are running in production and how exposed their production systems are when a Log4j-type incident occurs. Like many areas of the software supply chain, there are plenty of excellent open source tools that can produce an SBOM for you, such as Syft, Trivy, BOM and CycloneDX, as well as others that provide commercial services.Below you’ll find an example of a slice of an SBOM from a Node container image from Docker Hub with over 1.4 billion pulls. We hopped into the Slim platform (portal.slim.dev/login) to search for the public Node image, analyzed the image for vulnerabilities, and then downloaded the SBOM directly off the platform in a CycloneDX JSON format.You can see the highlighted metadata that’s provided. A full example of an SBOM download would include all the associated components, packages, libraries, a short description of their purpose/use, publishers, distribution types and their dependencies.So this all begs the question we started out with: What do we actually do with an SBOM? The truth is, this is still a work in progress, and there are many senior developers and security engineers who have a perfect answer for this. For the most part, the goal of an SBOM is to have this inventory accessible, backed up and safe. Many times you’ll find an SBOM stored in an artifact repository, backed up to an S3 bucket or hosted with a provider to enable easy access when knowing what’s running in your container becomes mission critical.Slim.AI Public Container Report 2022Not only is there a question of how to truly extract value out of these types of artifacts, but how will teams manage them as containers continue to grow in size and complexity? This growth can lead to longer CI/CD processing times and an increased workload for DevSecOps teams. The use and management of SBOMs will continue to have a spotlight in software supply chain management.Chris Hughes and Tony Turner break down the fundamental principles of what SBOMs encapsulate in their latest book, “Software Transparency,” where the function of SBOMs is described as a foundational element in achieving software transparency, enabling organizations to identify potential vulnerabilities and proactively address them. Although there are concerns about SBOMs providing visibility for attackers, Hughes states that “having an SBOM puts software consumers in a much better position to understand both the initial risk associated with software use as well as new and emerging vulnerabilities associated with software components in the software they consume.”According to Gartner, by 2025, SBOMs will be a requirement for 60% of software providers, as they become a critical component to achieving software supply chain security. This predictive insight exemplifies the need for SBOM generation ahead of the demand that is inevitably growing.AWS recently announced its support for SBOM export capabilities in Amazon Inspector, a vulnerability management service that scans AWS workloads across the entire AWS organization to gain insight into your software supply chain. Heavy hitters such as Amazon Web Services (AWS) or Docker releasing SBOM exportability features is a glaring hint that the demand and urgency for providing software transparency from software providers is expected to increase. Slim.AI also provides a pathway for generating and managing SBOMs for your container images.In the ever-evolving landscape of software supply chain security (SSCS), staying ahead of future requirements is imperative. Slim uses advanced scanning and analysis capabilities to generate SBOMs that you can immediately download. We thoroughly inspect the entire stack to extract crucial information and construct a detailed inventory of components. This enables organizations to maintain a robust security posture while ensuring compliance with evolving regulatory requirements.NTIA recommends generating and storingSBOMs at build time or in your container images in preparation for new releases. On the Slim platform, you can connect to your container registries (such as AWS, Docker Hub, Google Container Registry, and others) to store SBOMs for each of your container images. SBOMs are generated for both the original and hardened container images as part of the many artifacts that are accessible via the platform. Flow through our container hardening process on the platform to generate a smaller, more optimized, and less vulnerable version of your container image to deploy to production.In the Congressional hearings that followed Log4J, the message from the cloud-native industry was clear: SBOMs are just a starting point. While full software inventories are necessary for triaging risk in the event of an attack, they are not by themselves a means to prevent attacks. There’s excitement around what new tools will be made available that use SBOMs as their source of truth.Until then, most registries are working on the capability to store and manage SBOMs directly inside your registry of choice.With hugely popular containers and packages having built-in and maintained SBOMs, it will be much easier and faster to start mitigating and reducing risk with resources taken from the wild. In addition, many security organizations like OWASP and the OpenSSF are working toward making tooling more accessible and dev-friendly to drive adoption and wider usage.Added measures like slimming and hardening containers can also add greater security benefits in ensuring you only ship to production the critical packages truly required by your application. This will provide us with greater trust in our third-party packages and imports, and greater security for our entire software supply chain.Community created roadmaps, articles, resources and journeys fordevelopers to help you choose your path and grow in your career.