The importance of building a Software Bill of Materials (SBOM)
Today’s software is built out of hundreds, and sometimes even thousands, of components. Vulnerability increases with each component added. The more components, the greater the risk. The only way to have a consistent plan for making your software product secure is to know the security of each part. And that’s where a Software Bill of Materials (SBOM) comes in.
This machine readable inventory of the components you’ve used provides transparency into your software supply chain, giving you the opportunity to take any necessary steps to keep your software safe, should one of its components become at risk.
What is a Software Bill of Materials (SBOM)
An SBOM is “a formal record containing the details and supply chain relationships of various components used in building software,” according to a recent U.S. Executive Order. (1)
This comprehensive list of all the software components, dependencies, and metadata associated with an application, provides transparency down the supply chain and enhances cybersecurity. (2)
Software Bill Of Materials: Achieve Total Asset Visibility
Blog Post - Sasja Storms, Head of Customer Success
How did SBOMs get to be so important?
In 2020, SolarWinds, a Tulsa, Oklahoma-based international player in network management was hacked, with a vast impact across the private sector and the U.S. government. This attack by Russian threat actors on SolarWinds’ Orion, a network management software tool, put 18,000 customers at risk and cost SolarWinds $40 million in the first 9 months after the attack, according to an article in Cybersecurity Dive. (3) It also potentially jeopardized SolarWinds’ reputation.
“In the SolarWinds incident, Russian threat actors manipulated SolarWinds’ software build environment — injecting malicious code within a millisecond window of the build process,” Cybersecurity Dive says. “ (4) The changes were subtle and undetectable.”
The SolarWinds incident drew attention to the fact that software providers lack the same accountability found in other industries. It also made software developers rethink their processes. And it drew all eyes to the software supply chain. As a result, the U.S. government now requires an SBOM from its vendors. (5)
Benefits of an SBOM
SBOMs are fast gaining attention as something highly recommended, and some governments, like the U.S., are starting to lean toward what could soon become regulations in this area.
According to the U.S National Telecommunications and Information Administration (NTIA), SBOMs can also help to:
- reduce costs
- control security risk
- manage licensing risk
- monitor compliance risk
- improve software development
- manage the software supply chain (6)
- help vendors that use them to differentiate themselves in the market
- standardize formats across multiple sectors
- identify suspicious or counterfeit software components (7)
Developers building their own software will find an SBOM makes it easier to find vulnerable software components and calculate the risks involved. It also allows you to see software that is not affected by a vulnerability — freeing up your time to be used where it’s most needed. (8)
Proponents of SBOMs say that if all software had an SBOM, it would increase software supply chain transparency, lower costs and make transparency more scalable. It could make cybersecurity more systematic. (9)
Newsletter sign up
Get insights directly to your inbox
Subscribe to our newsletter for blog recaps, fresh tips, insights, and resource downloads.
What do you need in an SBOM?
An SBOM is an in-depth look at each component found in a software. The NTIA currently recommends an SBOM include this baseline information on each component:
● Supplier name
● Component name
● Version of the component
● Cryptographic hash of the component
● Any other unique identifier
● Dependency relationship
● Author of the SBOM data
NTIA is gathering comments now from the industry to expand its recommendations on SBOMs., so this list may change.
When it comes to cloud-native applications, SBOMs are even more important. This is because the architectures used in cloud-native applications break applications into smaller, independent services. Many of these services also include open-source software packages, sometimes used across multiple services, and potentially thousands of times. (10)
Currently the two mature, full-featured formats used for SBOMs are: CycloneDX3 and SPDX4. Both can be represented in spreadsheets, but the two most widely used data interchange formats are JSON and XML. (11)
The importance of building your own SBOM
An SBOM is instrumental in safeguarding the software supply chain for organizations, playing a pivotal role in enhancing both software security and the management of supply chain risks. It assists in the identification and control of security risks linked to third-party components and enables you to monitor vulnerabilities, licenses, and dependencies.
It doesn’t matter what you are building, whether it’s open-source software or something proprietary – knowing your software supply chain is crucial. Without it, you are flying blind on too many risks. It’s also important to keep your SBOM up to date because components and their versions constantly change.
Challenges in adopting SBOMs
It’s pretty clear that SBOMs provide a great many benefits. But there are a few pitfalls. Watch for these:
- Be strategic and consistent when integrating an SBOM into your process. If you aren’t careful, creating the SBOM could slow down development.
- Make sure you have accurate and up-to-date information for your SBOM, especially for applications that update or change frequently. Be prepared to use some resources for this.
- Find that balance between security and transparency. Watch out for privacy and intellectual property concerns when sharing SBOMs with external stakeholders.
- Remember that all parties in the software supply chain must adopt and share SBOMs for this effort to be effective. Transparency and security will take collaboration. Encourage commitment and standardization across stakeholders. (12)
Using automated tools to find everything on your attack surface and identify the risks within it
The National Institute of Standards and Technology (NIST) and the Industrial Internet Consortium (IIC) define trustworthiness of a system as having safety, reliability, resilience and privacy.
But cyberattacks, human errors, environmental disturbances and system faults, all create a changing level of trustworthiness. That’s why IIC says trustworthiness is a journey. (13)
To keep your enterprise safe on this journey is going to require vigilance and artificial intelligence (AI), to automate the process.
AI allows you to quickly and accurately understand the security of your data within the big picture of your enterprise and helps you to prioritize what actions to take. This is important because you don’t have time to waste. Attackers are also using AI, and it’s cutting the end-to-end life cycle of an attack from weeks to days or even hours.
Sixty-nine percent of organizations have experienced an attack targeting an unknown, unmanaged, or poorly managed external-facing asset.
Hadrian continuously discovers assets, scanning the entire internet to accurately identify every asset belonging to your organization. We also continuously assess 3rd party applications for risks that could result in a data breach of your critical data. Hadrian's probes can identify over 10,000 SaaS applications and 1,000s of software packages and versions to identify every application. We reduce risks, improve efficiency, and streamline compliance.