Organizations are looking at more intelligent ways to strengthen their software supply chains due to the increased cyberattacks. The Apache Log4j zero-day vulnerability – one of the most talked about incidents in recent years shook the whole IT industry. Many government institutions, organizations, and individuals were affected by this incident. In May 2021, the Biden administration published a cybersecurity executive order to improve the nation's cybersecurity. The White House highlighted and explicitly asked to focus on transparency in software components to boost its cybersecurity efforts. This in-detail order of enhancements also mentioned the requirement to maintain and provide a software bill of materials (SBOM). The Log4j vulnerability only made a strong case for software developers, publishers, and consumers to consider adopting SBOMs. So, what exactly is an SBOM?
What is an SBOM?
A "Software Bill of Materials" (SBOM) is used in the software industry as an inventory system to list down the "ingredients" that make up the components of the software. It is a formal record detailing the supply chain relationships of the different pieces that developers use to build software. It includes details about open-source and enterprise components, licenses, versions, and vulnerabilities. An SBOM can be compared to the Bill of Materials (BOM) used in the manufacturing industry, which contains details like raw materials, assembly components, parts, and different quantities used to manufacture an end product.
Why do organizations need a Software Bill of Materials?
Today's applications are complex and built out of different components. Most are a mixture of proprietary code, open-source, and third-party components. An SBOM serves as the backbone of these complex apps. Third-party and open-source codes have limited visibility and thus may be vulnerable to external attackers. Attackers take advantage of this limited visibility by targeting vulnerable organizations and causing attacks like the SolarWinds supply chain attack. An OSRA report discovered that 97% of codebases in 2022 contained open-source code, and 88% of organizations are still behind in keeping their open source updated.
Organizations must keep track of every step and every component that builds the software so that threats can be identified, avoided, and patched before they become lethal to the organization. An SBOM gives organizations clear visibility into the software supply chain, saving time for identifying and fixing the issue. Organizations can track codes to their code bases, identify vendors for specific codes, and measure the quality of that code. It helps determine and control the quality of the entire supply chain and serves as an excellent tool to qualify or disqualify vendors. Organizations can maintain software security because organizations have details of every piece that makes up the software puzzle.
SBOMs also aid in better risk management by fortifying software security. With organizations responsible for their software development chains – open-source, third-party, and proprietary code, risk management and security leaders are constantly on the lookout for solutions that reduce the security risk of the supply chain while boosting the time-to-market. An SBOM is an ideal tool to give insights into third-party software and understand the risks. Customers can be quickly notified about identified threats before it multiplies.
End users have realized the importance of having an SBOM readily available, and suppliers with maintained SBOMs are preferred. Topped with the U.S. President's mandate on maintaining an SBOM, customers choose to partner with organizations that maintain one. It has become a leading parameter for doing business with the U.S. Federal Government, and this trend is rapidly expanding to the private sector.
Why are regulators rooting for SBOMs?
SBOMs not only strengthen the overall security of the software supply chain but also enhance its functionality. The industry has seen open-source and even proprietary software, sometimes with flaws or loopholes being used. Using such code repeatedly re-introduces the same vulnerability over and over again and even passes them on to clients that use that software. Such weaknesses have led to high-profile incidents like the Colonial Pipeline incident and the Equifax breach. Security leaders must respond quickly in these cases and identify the applications using the infected library. Organizations with SBOMs have considerably reduced response times because they can map each application to the vulnerable dependency - making regulators very interested in adopting and enforcing SBOMs.
What should be included in an SBOM?
Responding to the executive order on improving national security, the National Telecommunication and Information Administration (NTIA) released a document outlining "The Minimum Elements For a Software Bill of Materials (SBOM)". The document contains the fields needed to meet federal government requirements. The highlighting ones include the following:
- Supplier name: The name of an entity that creates, defines, and identifies components.
- Component name: Designation assigned to a unit of software-defined by the original supplier.
- The version of the component: Identifier used by the supplier to specify a change in software from a previously identified version.
- Other unique identifiers: Other identifiers that are used to identify a component or serve as a look-up key for relevant databases.
- Dependency relationship: Characterizing the relationship that an upstream component X is included in software Y.
- Author of SBOM data: The name of the entity that creates the SBOM data for this component.
- Timestamp record: Record the date and time of the SBOM data assembly.
- Standardized formats: The SBOM should be conveyed in one of these formats - Software Package Data Exchange (SPDX), CycloneDX13, or Software Identification (SWID) tags.
Ensure you maintain the aforementioned list of records in your SBOM against typical assets such as development dependencies, software applications or packages, container images, hosts, and hardware devices.
Software Bill of Materials best practices
Modern software is complicated. One piece of code is interlinked and dependent on another in a complex dependency tree. SBOMs help meet the demands of high visibility into the application's core components. Let's look at some best practices to maintain an accurate SBOM.
- Update the SBOM regularly: The software vendor is responsible for maintaining and recording application component changes. Include everything from code updates, new features, bug fixes, and other changes to maintain transparency. Remember to update the SBOM regularly to ensure it does not become outdated.
- Ensure data integrity: Since information, integrity is an integral part that makes the SBOM such a valuable tool to possess, ensure that its details come from trusted sources. Verifying entries is good practice to ensure that all information, including licenses and version numbers, are recorded.
- Clarify potential issues that can affect users: The SBOM must clearly have information on the current state of applications and the steps needed to secure them properly. It must display all the files & components, indicate the ones in use, and highlight areas that require attention. Include everything from known bugs to known vulnerabilities and maintain a high-level transparency.
- Identify SBOM documents: Remember that multiple people will access the SBOM. So, make sure to monitor who has access to what. Keep the naming convention clear and specify the latest version of the SBOM so that everybody is on the same page.
Do you need an SBOM?
Absolutely! All forward-thinking organizations must adapt to changing conditions and requirements of the market. There is no point in hiring Sherlock Holmes once the security is breached. The details you don't know about any software have the power to hurt you potentially. SBOMs provide you transparency into the software supply chain. Maintaining them is one of the crucial steps of making organizations future-proof.
