When it comes to cooking, it’s not the ingredients that are unique, it’s the recipe. The same can be said for software. Developers mix together third-party and open-source components with bits of custom code to create the applications organizations depend on.
Over time, these applications change and evolve. Developers move on, memories fade, and it becomes a difficult task to know exactly where your cybersecurity weaknesses exist.
A Software Bill of Materials (SBOM) provides a full list of the components used to build an application, including libraries, drivers, dependencies, firmware, licenses, and operating systems. This increased transparency promotes the sharing of vulnerability intelligence and remediation information when a threat is identified.
Table of Contents
Threats Against Security and Privacy
Motivated to protect the American people’s security and privacy, United States President Biden has employed the use of SBOMs as part of an Executive Order that pledges to improve Federal Government efforts to “identify, deter, protect against, detect, and respond” to malicious cyber threats.
Starting with the goal of safeguarding critical United States infrastructure, it is the hope of President Biden that a series of voluntary guidelines and mandatory requirements will emerge for citizens to rely on for protection from the “debilitating effect on national security, economic security, and the public health and safety of the American people.”
Also read: Biden’s Sweeping Economic Executive Order Sets Eyes on Big Tech
What is a SBOM?
Understanding and enumerating software assets can be a difficult job. A comprehensive SBOM offers visibility, accountability, and increased reliability. Other benefits may include better adherence to policies and regulations, consolidation of assets, and added security.
If a vulnerability is found in a component, organizations can use SBOMS to identify affected software, understand the risk, and discover the steps to patch or remediate the defect.
How SBOMs Work
It is critical that an SBOM contains all of the requisite system detail, so that it is always clear whether a system is vulnerable, and whether remediation or mitigation is necessary.
Identifying a compromised component is only one strength of a comprehensive SBOM. This document should also provide important configuration and relationship details. When a developer incorporates a third-party product, they may only use a small (and possibly unaffected) portion of the available functionality. It is also possible that customer-specific modifications or configurations render software components unused. Deciding whether a weakness is actionable relies on this context.
The baseline information that should be included in a SBOM has been developed by The National Telecommunications and Information Administration (NTIA) at the insistence of the Biden Administration.
NTIA has identified the following required component attributes:
- Author name
- Supplier name
- Component name
- Version string
- Component hash
- Unique identifier
- Relationship
Also read: Best DevOps Certifications to Have Now
SBOM Security FAQ
It may feel counterintuitive to trust an SBOM when it compiles so much data into a single document. When protecting the security of information is the ultimate goal, there are a few important questions to ask.
Could information shared in an SBOM aid an attacker, and actually make a system more vulnerable?
The NTIA insists that this is a misconception, while also admitting it’s a possibility.
The NTIA feels that the “defensive benefits of transparency far outweigh this common concern as SBOMs serve more as a roadmap for the defender,” but this may have to be evaluated on a case-by-case basis.
Could an SBOM expose intellectual property or confidential source code?
Maybe. But not because the SBOM requires it.
In the same manner that loose lips sink ships, so would the decision to include specific information in an SBOM. As with all organization documents and communications, it is important that an SBOM does not divulge information that isn’t relevant or necessary.
Does an SBOM give insight into market dynamics or expose intellectual property?
This is the subject of tremendous debate. Having a list of ingredients isn’t the same as a recipe; knowing a component was included in a project doesn’t give enough information to disclose how much of it was used or in what way.
That said, there is nothing preventing trends from being analyzed. When SBOMs are publicly disclosed, they may reveal information about the types of systems using a component and with what frequency.
Don’t underestimate that this insight may also serve as a valuable tool. Learning which components are commonly being used by others in your industry may provide ‘best-in-class’ tips that should be utilized by your organization.
Who Cares About SBOMS?
Don’t worry that an SBOM divulges the name of your favourite open-source component. Your biggest competitors are too busy working on their own projects to concern themselves with the granular details of yours. Not only that, if you are both utilizing a common component in your development, that isn’t an area where either of you is being innovative or unique.
Let’s take it one step further. If a third-party component is found to be vulnerable by another user or vendor, would you prefer to be proactive about the remediation, or just wait until your system is compromised by something your peers have already fixed?
To give this concern even more perspective, these same competitors probably use the same word processor and web browser you do too.
It is counterintuitive to be vigilant about the protection of components that you didn’t create.
Keeping SBOMs Current and Meaningful
It would be nice to live in a simple world, where organizations use a single piece of software that has been designed, developed, and maintained by the same vendor. In this utopia, only a single SBOM would be required. Unfortunately, that isn’t realistic. It’s much more likely that your IT tapestry has been woven from various products, built by various vendors, during various periods in time.
This witches brew of software solutions will task organizations with finding a way to manage multiple SBOMs, integrate with existing vulnerability management solutions to maintain a watchful eye on legacy systems, and to consider undertaking projects to collect and verify all existing assets into freshly created SBOMs.
The creation and maintenance of SBOMs may soon be a contractual requirement from software vendors, but it will be challenging to create and maintain SBOMs that are comprehensive, updated, auditable, enforceable, and actionable.
It is important to treat an SBOM as a living document, constantly being reviewed and updated as necessary. While the onus should be on vendors and software developers to provide customers with updates to components and their details, regular high-level evaluations can help to predict future maintenance requirements. Be certain to flag any software components that are not currently supported or fully patched. Keep notes on components that have caused security problems, or you feel may have other issues of concern.
An SBOM is Your Trusted Advisor
Reducing risk is the cornerstone of application security, and an SBOM is a valuable tool to keep track of software components, ancillary systems, and their current state.
Software vendors and their developers will grow to enjoy letting SBOMs do the heavy lifting, making it easier to manage component dependencies, utilize best practices, and abide by industry standards. Organizations will also enjoy a secondary benefit to regulated and required SBOMs: the potential for researching software components and their known risks ahead of procurement.
This cumulative approach to risk management will offer peace of mind to software users, developers, and buyers as the use of SBOMs gains momentum and becomes an essential by-product of the software development lifecycle.
Also read: AI and Observability Platforms to Alter DevOps Economics
