Picking Up Where
SBOMs Leave Off –
Best Practice Guide to
Securing Software
Supply Chains
White Paper Picking Up Where SBOMs Leave Off – Best Practice Guide to Securing Software Supply Chains
2 What is Software Supply Once upon a time, developers would
build software with one hundred percent
Chain Security and Why is
original code. All the code contained
it So Important? in a program would be written for that
specific program. Today, software is
3 Enter the SBOM assembled – that is, much of it is pieced
together with pre-built elements.
4 SBOMs Are Not Enough
Assembled software makes a lot of sense. Many of
5 LeanIX Value Stream the elements you would need for an application or
tool have already been built by someone else and are
Management available in publicly accessible open-source software
libraries. For example, web applications use services
such as login screens, password verification, and search
1
capabilities. Instead of writing code from scratch for
these common services, you can simply incorporate
open-source libraries that already contain them.
All of the services, libraries, tools, and processes used to
develop, build, and publish a software product make up
its software supply chain.
White Paper Picking Up Where SBOMs Leave Off – Best Practice Guide to Securing Software Supply Chains
What is Software Supply Chain
Security and Why is it So Important?
Software supply chain security is the act of ensuring the security of every element that
goes into a functioning software product, from source to deployment. This includes
open-source libraries, which often contain hidden risks and vulnerabilities.
While libraries are useful because they reduce Open-source software is particularly at risk to these
development time and offer shortcuts that simplify kinds of attacks, since the code is publicly available and
programming processes, they also present unique can be dissected for vulnerabilities, which are likely to
security challenges. This is because libraries contain be found. Synopsys' 2023 Open Source Security and
many direct and transitive dependencies between Risk Analysis (OSSRA) examined 2,409 codebases. The
components (component A depends on component analysis revealed that 97% of the codebases contained
B, which depends on component C, and so on). These open-source components, and at least one vulnerability
dependencies can contain vulnerabilities and create was found in 84% of them. The report also found that
unwanted backdoors into your software, as was the 73% of the code it examined across the aerospace,
case in the infamous log4j incident. aviation, automotive, transportation, and logistics
industries was open source.
On December 9th, 2021, a remote code execution
2
(RCE) vulnerability in Apache log4j 2 was identified To secure your software supply chain against
as being exploited. By submitting a specially crafted vulnerabilities in open-source software libraries and
request to a vulnerable system, an attacker could other types of cyber-threats, you have to have a full
instruct that system to download and subsequently accounting of everything in it. While there are a number
execute a malicious payload. Due to the broad usage of methods for dealing with software supply chain risk,
of the popular Java library, many IT Systems and SaaS SBOMs are a critical starting point
providers were at severe risk.
Another famous example of vulnerabilities in
dependencies leading to a cyber-attack is the
torchtriton incident. On New Year's Eve in 2022, Pytorch
learned about a malicious dependency confusion
attack using a package named "torchtriton" that 97% of the codebases contained
open-source components
was uploaded to the Python Package Index (PyPI)
code repository. Users added this dependency and
unknowingly ran a malicious binary. This is known as a
'supply chain attack', and directly affects dependencies
84% of the codebases contained
at least one vulnerability
for packages that are hosted on public package indices.
73%
of examined code across
the aerospace, aviation,
automotive, transportation,
and logistics industries was
open source
White Paper Picking Up Where SBOMs Leave Off – Best Practice Guide to Securing Software Supply Chains
Enter the SBOM
SBOMs are machine-readable lists created by vendors government provide SBOMs for their software. SBOMs
that function like ingredient labels for software will also play a critical role in meeting the requirements
products. of the 2022 EU Cyber Resiliency Act. One of the primary
goals of these initiatives is to shift liability for risky
People who work in the engineering or manufacturing software from consumers to producers. This means it will
space are familiar with bills of materials (BOMs), which be the vendor’s responsibility to ensure they’re not using
are comprehensive lists of everything that goes into vulnerable components, even if they don’t own the code
creating a physical product. This includes raw materials, themselves.
parts, components, and subcomponents, along with the
quantities of each needed for a final product. At the end of the day, however, an SBOM is simply a
static file containing fairly high-level information. To
The SBOM is a BOM for software. It lists and tracks all reap the true value of SBOMs, you need to understand
the components, modules, and libraries that were used their content in context. Which team is using a given
to build the software, along with licenses, versions, file library? Which exact services are built on that library?
names, publishers, patch statuses, and dependency Which products are powered by those services? The best
relationships. way to discover and view this critical information is to
connect the SBOM to a comprehensive service catalog.
SBOMs help ensure transparency and security in
software supply chains. Among other things, they enable
3
organizations to determine if software is impacted by
a particular, identified vulnerability. SBOMs also make it
easier to understand dependencies across components,
monitor components for vulnerabilities, and manage
license compliance.
SBOMs are fast becoming an industry standard, and by 2025
60%
a growing number of buyers now require them from
the vendors they do business with. In fact, Gartner
predicts that by 2025, 60% of organizations responsible
for critical infrastructure software will mandate and of organizations responsible for
standardize SBOMs in their software engineering critical infrastructure software will
practices – a dramatic increase from less than 20% mandate and standardize SBOMs
in 2022.
in their software engineering
SBOMs are already a requirement under the ISO
practices
standard for open-source software, and in May
of 2021, the White House issued executive order
EO14028: Improving The Nation's Cybersecurity, ,
which mandates that all software vendors to the US
White Paper Picking Up Where SBOMs Leave Off – Best Practice Guide to Securing Software Supply Chains
SBOMs Are Not Enough
You can use an SBOM to find out if a vulnerable library is As Synopsis Principal Security Strategist Tim Mackey
being used in a piece of software. But The SBOM doesn't put it:
tell you anything about the nature of the service, the
affected product, or the team that has to deal with the
vulnerability. “Without those sources and
workflows, an SBOM is no more
Affected services and associated APIs could support
a myriad of different applications, which in turn could effective than telling someone who
enable critical business processes. But the SBOM only doesn’t know they need to change
tells you whether or not you have the vulnerability in a the oil in their car regularly the
piece of software. If a vulnerability is discovered, many
chemical composition of motor oil.”
dev teams still have to search manually to determine
its full impact. Modern software architectures consist of
thousands of services, so manual searches are not only
time-consuming, but in many cases they are unfeasible. Furthermore, the ability to map vulnerabilities to
services, services to applications, and applications
In order to use SBOMs effectively, it’s best to already to business products enables you to prioritize your
have all your libraries mapped to services and those remediation efforts. Many vulnerabilities contained
services in turn mapped to the applications using them. in software libraries are not critical and don’t require
4
Creating this map requires a precise catalog of all of immediate remediation. Not all vulnerabilities are
your organizations’ services and associated libraries. exploitable, and even the ones that are might not
affect anything crucial to the organization. The
When you identify a compromised library in your SBOM, average organization can only patch around 10% of
you can immediately reference the mapped catalog to vulnerabilities in their environment each month. Since
determine every service that contains the library, and time and resources are limited, organizations need to
what business products those services support. That be strategic in selecting which vulnerabilities to fix.
way, you not only know where to find the vulnerability,
but also how it could affect your operations. You will For example, let’s say your SBOM reveals that a
also know which teams are responsible for the affected vulnerability exists in a software product you have
products. in your infrastructure. But your mapped inventory
shows that the service containing the compromised
Without that mapped catalog, you’ll just have a long component is an internal product in beta. Since it’s not
list of every ingredient in every piece of software in customer-facing and currently has limited use in the
your organization – a list that is so complex it requires organization, fixing this vulnerability is a low-priority
a machine to read it. The SBOM cannot tell you where task. On the other hand, if you discover a vulnerability in
exactly your vulnerabilities are or how they could a service that supports a customer-facing application,
affect you. you need to fix it immediately.
White Paper Picking Up Where SBOMs Leave Off – Best Practice Guide to Securing Software Supply Chains
LeanIX Value Stream Management
LeanIX’s Value Stream Management (VSM) empowers you to safeguard your software
supply chain with SBOMs backed by a robust service catalog.
The VSM Service Catalog Using the VSM Service Catalog
The VSM Service Catalog provides a real-time, detailed for Efficient SBOM Consumption
inventory of all of your services, underlying libraries, VSM’s easy-to-use interface and filtering capabilities
and associated APIs, and clearly connects them to all allow you easily ingest SBOMs for efficient analysis.
relevant teams and products. This data-rich inventory
can be expanded to capture dependencies and map LeanIX ingests SBOMs generated with the CycloneDX
how services connect to applications and products standard. We then expand upon the technical value
throughout the organization. captured in the CycloneDX SBOM by aggregating data
from numerous SBOMs into the VSM Service Catalog,
With powerful, out-of-the-box integrations and where it can be easily accessed, searched and filtered,
easy- to-use APIs, the VSM Service Catalog provides enabling rapid impact assessment and reducing
details on the software supply chain of each service, response times when a vulnerability is found.
including associated business products, technical API
documentation, and ownership within the dev team.
5
As a result, you can understand at a glance which
services are dependent on a specific library, which
teams are responsible, and which products use the
service. The Service Catalog also acts as a single
source of truth across your business and can be used to
efficiently consume SBOMs.
The VSM Service Catalog shows everything you need Ingest SBOMs easily with the VSM Catalog
to know at a glance
White Paper Picking Up Where SBOMs Leave Off – Best Practice Guide to Securing Software Supply Chains
Always Meet Software Supply Chain
Security Demands
Software supply chain security is fast becoming table stakes to do business
in the digital economy. SBOMs play a key role in this, but you need the right
tools and information to effectively use SBOMs for their intended purpose.
That’s where LeanIX comes in. Our Value Stream Management (VSM)
solution picks up where SBOMs leave off, allowing you to ingest and analyze
SBOMs so you can know within minutes where to find all vulnerabilities
across your organization and conduct rapid remediation and business
impact analyses. VSM is designed specifically to meet today’s market
demand for enterprise-ready and interoperable solutions that are easy to
use and bring fast time-to-value.
6
To find out more about the LeanIX Value Stream Management
platform, try it out with a 14-day free trial.
Start your free trial!
This document is current at the time of its initial publication. LeanIX GmbH reserves the right to alter it at any time.
THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED AS IS, WITH NO WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLICIT.
LeanIX's Continuous Transformation Platform® is trusted by Corporate IT and Product IT to achieve comprehensive visibility and superior governance. Global
customers organize, plan and manage IT landscapes with LeanIX's automated and data-driven approach. Offering Enterprise Architecture, SaaS Management, and
Value Stream Management, LeanIX helps organizations make sound decisions and accelerate transformation journeys. LeanIX has a thousand customers globally,
including Adidas, Bosch, Dropbox, Santander and Workday. LeanIX is headquartered in Bonn, Germany, with additional offices in Germany and subsidiaries in Boston
(USA), London (UK), Paris (France), Amsterdam (Netherlands) and Ljubljana (Slovenia). For more details, please visit www.leanix.net.
Copyright© LeanIX GmbH. All rights reserved. LeanIX and the LeanIX logo are trademarks or registered trademarks of LeanIX GmbH in Germany and/or other countries.
All other products or services are trademarks of their respective companies.
2023
www.leanix.net
