Software Bill of Materials
Contextualize the Software Bill of Materials (SBOM) in the right business context.
TL;DR
Securing your software supply chain as a product organization is imperative. Import your software libraries into VSM by means of industry-standard CycloneDX to drive an actionable context (teams, products, and services) for your software libraries, to manage your technology risks easily and meaningfully.
Background
Building modern-day software encompasses many sources of risk that can jeopardize your business (see diagram below). Securing and safeguarding your software supply chain has become a first-order concern for product teams and companies. Incidents like SolarWinds or log4j have underpinned the necessity to have a thorough understanding of all components within your technological stack or as the 2022 State of DevOps report by Google puts it "Today, the topic of software supply chain security has become widely recognized as urgent — if not over family dinner, certainly in the boardroom".
all credits go to https://slsa.dev/
Initiatives, such as the SLSA framework are conducive to structure and enforce guidelines to double-down on the security of your software supply chain at large (see also the presentation below by Kelsey Hightower on the same topic). The 2022 State of DevOps report also finds that adhering to these best practices seems to be associated with higher levels of software supply chain security assurance.
slsa.devOne of the core elements of your software supply chain that poses a risk are third-party software libraries. These can by direct or indirect means (transitive dependencies) bring in malignant dependencies into your technology stack, thereby creating unwanted backdoors into your software, as was the case for log4j. To uniformly make sense of all ingredients (or software libraries) within any software project the term software bill of material (SBOM) was coined.
The importance and obligation to understand and provide a clear picture of the software components of any piece of software is underpinned by the US government filing an executive order obliging the provision of an SBOM by any software provider of the US government. We expect more institutions and other regulatory bodies to follow suit. Also, the aforementioned SLSA framework, as part of their Level 1, requires automatic provenance, in the form of an SBOM.
There are multiple open-source formats or schemas for an SBOM, such as SPDX or CycloneDX to streamline and create a shared understanding of an SBOM. Especially, CycloneDX has a wealth of community support creating tooling to easily integrate the SBOM creation from within your software projects (see https://cyclonedx.org/tool-center/ ) and is backed by many cutting-edge software companies. This is why LeanIX VSM puts this standard at its core to digest your software libraries and ultimately help you manage your risks.
What's in there for me?
In the bigger scheme of securing your software supply chain (shifting left) to build great and secure digital products, VSM helps you to decipher your used third-party libraries in the context of your teams, services, and products. By providing an API to ingest CycloneDX Security Bill of Materials (SBOM) VSM now allows you to neatly provide the CycloneDX SBOM files as part of your build procedures (CI/CD).
As an engineer: Easily understand which software libraries my services are using without extensive search costs to ensure I'm not blindly incorporating unwanted risks.
As an engineering leader: Quickly & comprehensively assess across all my engineering teams, which software libraries and licenses are used and correlate owning teams and encompassing services. This is especially vital to mitigate vulnerabilities fast or ensure no license infringements.
How VSM can help?
Integrating CycloneDX SBOMs with VSM allows you and your product teams to:
- Stay up to date on the technological risk introduced by the use of third-party software in the context of your products, teams, and the services themselves
- Mitigate identified security risks fast and allow rapid collaboration amongst affected services and teams to provide trusted digital products
- Streamline the use of certain third-party software and weed out disallowed software early on
Scenario 1: I already create CycloneDX SBOMs
Create a step in your CI/CD pipeline to provide the CycloneDX SBOM file on a continuous basis to VSM. This is a one-time setup.
CI/CD setup
See the details in the technical setup guide:
docs-vsm.leanix.netAlso, refer to the tutorial for a sample setup with Jenkins or the GitHub action:
Scenario 2: I don't yet create CycloneDX SBOMs
Step 1: Embed the CycloneDX SBOM generation as part of your build process
Best Practice - CycloneDX SBOM generation
We strongly suggest using the SBOM plugins provided by the CycloneDX initiative for the combined use with VSM. For the main package managers, these plugins are easy to embed and reliably extract all relevant information (dependency tree incl. transitive dependencies, consistent use of the PURL and licenses) from your build files.
Please navigate to our guide on how to embed the CycloneDX plugins for the main package managers in your build process:
Step 2: Provide the SBOM file to VSM (as part of your build)
Create a step in your CI/CD pipeline to provide the CycloneDX SBOM file on a continuous basis to VSM. This is a one-time setup.
CI/CD setup
See the details in the technical setup guide:
Also, refer to the tutorial for a sample setup with Jenkins:
Understand your software libraries in their business and technological context
Once you have mapped your service into your service catalog (
this is a one-time effort) you can dive into understanding your technological footprint and used libraries globally and on a service-per-service level.
Which services and teams are using a specific library?
Searching for specific libraries
Updated 2 months ago