Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
As cyber attacks become more sophisticated and happen more frequently, SBOMs or software bills of materials have become a more common practice across the software supply chain to trace vulnerabilities with as much accuracy as possible. Software bills of materials help software buyers make more informed purchasing decisions by disclosing an application’s various components.
What is a Software Bill of Materials (SBOM)?
A software bill of materials lists components of software –whether open-source or proprietary– for the sake of transparency and security. Components include:
- Dependencies
- Firmware
- Hierarchical relationships
- Libraries
- Licenses
- Operating systems
- Metadata
An SBOM functions in a similar way to a nutritional facts label, describing the ingredients that went into developing the software. Aside from being a list of components, however, an SBOM is also a catalog of software versions and updates. That is, it’s a living document that evolves as the software does.
Why Are SBOMs Used?
Software development involves third parties, creating a software supply chain that has become increasingly susceptible to attacks. As a case in point, Python’s open-source code repository found itself vulnerable to malicious behavior in 2021. Any third-party software using Python was at risk and, further down the chain, companies using that software. If that third-party software had had an SBOM, its users further down the supply chain could have been informed of the vulnerability and investigated it further.
SBOM Pros
SBOMs are beneficial to any organization that prioritizes security. According to Bren Briggs, Vice President of DevSecOps at Hypergiant, an SBOM is a “crucial component of cybersecurity control.” Briggs goes on to say that “asset inventory is the single most fundamental control available to organizations to reduce the risk of vulnerabilities.” Given that cybersecurity attacks are becoming more complex and more frequent, Briggs believes that having an SBOM in place is a good practice for organizations to be “disciplined in the basic controls” and achieve “far better levels of security with lower effort and cost.”
SBOMs also empower software buyers and ensure adaptability, compliance, and supply chain integrity.
Adaptability
Since SBOMs contain a catalog of previous software versions, they allow software developers to quickly revert to a previous software version in case an update disrupts or threatens the software’s performance and security.
Buyer power
SBOMs therefore give software buyers more visibility into what a software contains and its potential vulnerabilities, keeping them in control of the research and buying process before committing to an application.
Compliance
SBOMs are not purely a matter of corporate discretion. President Biden announced in an executive order that application developers must provide a software bill of materials to improve cybersecurity.
Similarly, according to 2020 IoT cybersecurity laws in California and Oregon, manufacturers must build standard security features into their devices’ software, such as regular, automatic security updates.
SBOMs contain a log of changes to and version of software, making it easy for the developer to maintain records and remain compliant to regulatory standards in the event of an audit.
Supply Chain Integrity
Over all, vigilance across the software supply chain has led to SBOM use for transparency purposes. On the vendor side, an SBOM supports software developers to be more vigilant about third-party components. They enhance visibility over the software’s components, enable easier management of component dependencies, and support industry best practices and standards. SBOMs enhance supply chain integrity, keeping developers, vendors, and clients informed and unified in their approach to security.
SBOM Cons
Difficulty
Drafting a SBOM is not so cut and dry. While a list of individual parts works for the manufacturing environment, this is not how software development happens. A developer may incorporate only certain files, functions, or lines of code from third-party software, making it difficult to draft up a SBOM.
False alarms
Components of software are not inherently vulnerable; they’re only vulnerable based on how they’re being used within the software. It’s therefore misguided for customers to rely on a SBOM to trace vulnerabilities because the component in question may only be vulnerable if used in a certain way. Use context should therefore be included in SBOMs so as not to raise false alarms for customers.
Time intensiveness
Given the difficulty in tracing components to draft an SBOM, doing so will also take time. Other factors that prolong the process is training staff to use a tool that helps create an SBOM that follows the National Telecommunications and Information Administration’s (NTIA) guidelines. The time it takes to write up an SBOM is not an excuse for foregoing security and transparency, however, it is a formidable challenge for software developers to take into account.
Lack of data
Opponents of the efficacy of SBOMs cite the NTIA’s lack of data to back up the effectiveness of SBOMs in preventing cybersecurity attacks. While SBOMs may be good in theory, they may ultimately do more harm than good by distracting software developers and customers from more serious impending risks.
SBOM is a Step in the Right Direction
SBOMs services are increasingly becoming part of vulnerability management, third-party risk management, and software composition analysis offerings. While SBOMs are neither preventative nor a cure-all solution for cyberattacks, they are a step towards transparency and vigilance for software developers and customers to identify and address risks.
Read next: Top Vulnerability Management Tools & Software 2022
