 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
A software bill of materials (SBOM) is a comprehensive list of the components, libraries and other assets that make up a software application. It details the third-party components and dependencies used in the software, which helps in managing security and compliance risks in the software supply chain.
An SBOM tracks software development metadata about each component including data fields such as version, origin and license. This enables organizations to track vulnerabilities, perform regular software maintenance and ensure compliance with regulatory requirements.
SBOMs can be built in several formats, including:
Since the space is rapidly evolving, there is no formal consensus around which format is the best. A bill’s format will depend on the tool or procedure used to generate it, the requirements of the organization and its intended use.
A bill of materials provides crucial information about the components that make up a piece of software. It allows organizations to manage and monitor the security footprint of their applications.
This is especially important today, as cybersecurity threats evolve and systems become more complex. Software deployments now comprise many software products, often from multiple software vendors. The SolarWinds attack and the Log4Shell vulnerability are two recent examples of supply chain risk. By maintaining up-to-date SBOM security, organizations can identify common vulnerabilities and exposures (CVEs) and ensure that they are addressed before they are exploited.
Additionally, SBOMs can help organizations ensure that they are in compliance with regulations and standards, such as:
Maintaining complete and accurate SBOMs streamlines the process of demonstrating compliance with these regulations, helping organizations to build trust with customers and stakeholders.
Numerous SBOM tools have been released under a variety of open source licenses. You can now generate SBOMs from container images or git repositories and file systems containing source code. There are even tools that work with more esoteric sources such as OCI archives and Singularity Image Format (SIF) containers.
Popular open source tools include: Tern, Syft, Kubernetes bom, and spdx-sbom-generator to name just a few.
Open source tools are fantastic, but DevOps effort is still required to integrate your tool of choice into your image build pipelines. Even once SBOM pipelines are configured, additional thought is required around surfacing SBOMs and the metadata they contain in a user-friendly manner. That’s where Palette’s Software Bill of Materials (SBOM) scan comes into play.
Palette already supports a range of scans out of the box, covering Kubernetes configuration security, conformance and penetration testing. Now we are pleased to announce our Software Bill of Materials (SBOM) scan.
Getting started is simple. First, select your desired SBOM format: we support four of the most popular. Then, set your scan scope, and optionally specify a backup storage location. Scan scopes include:
Palette will identify every unique container image within your chosen scope and generate an SBOM for that image. We’ll also run the SBOM through a vulnerability scanner that will flag CVEs.
You can click into a completed scan to view a scan report containing additional detail for every image that was scanned.
The context column indicates every unique usage of each image, broken out by container name, namespace and pod name. We do this because each image may be in use by various containers within a given scope.
The vulnerability summary column provides a condensed view of the vulnerability report. You can access greater detail by clicking on any row in the scan report.
Finally, each image details page within the scan report provides a list of dependencies and vulnerabilities. These tables are condensed highlights of the metadata contained in the SBOM that was generated for a particular image. Each dependency’s version and type is displayed, but additional metadata will be included in the SBOM. Exactly what additional metadata is included will depend on the selected SBOM format.
For each vulnerability, you can view the name, severity level, vulnerability code, installed or impacted version and the fix version (if a fix is available). Any CVEs documented in the NIST National Vulnerability Database (NVD) will render as a hyperlink to the NVD detail page for that particular vulnerability.
If you specify a backup storage location — any common blob storage provider, such as AWS S3 or Minio — we’ll upload the full SBOMs there. You can download them with the click of a button or using the Palette API.
If you didn’t specify a backup storage location, you won’t be able to download the raw SBOMs. But Palette will still preserve all the results and metadata pictured in the screenshots above.
SBOMs can provide value to any organization across multiple dimensions, including:
Given the growing prevalence of cybersecurity breaches, maintaining SBOMs for your software is essential. Fortunately, Palette makes it easy to get started. You’re just a few clicks or API calls away from having an SBOM for every single image in your Kubernetes cluster.
Thanks for reading, and if you have any questions, don’t hesitate to reach out via email or LinkedIn.
