Introduction 

Hungry? And munching on packaged food? Just turn the pack and have a look at the ingredients. Shocked to see you are probably eating some chemical stuff. Hey! Sorry, it’s not a good food habits blog 😊 , We will have it some other day. 

Just wanted to match up with the analogy, the way food packet has all used ingredients mentioned on it, any Software has a list of on-the-shelf components, and open-source components. 

This list is called Software Billing of Materials or Sbom. 

Why “S” BOM? 

Software project development has become agile to cope with the faster-changing business needs. There is a good chance that the software developer uses components that are on the shelf or components that are open-source. After the incident of Log4j, the organizations are vigilant enough about the composition of the software built using out-house components. This makes it need of hour to keep track of third-party components used in the software. 

When the list of third-party components is available, it becomes easier to locate the exact component that is nasty. This also helps to apply remediation to the nasty part.  This not  only saves time but also the efforts and losses that may incur due to delayed detection of the defect in the software. This also helps in getting legal compliance and at the same time avoiding the pitfall of using open-source malicious code snippets and libraries. This in turn fortifies the software  supply chain security. 

The Origin 

The concept originates from the manufacturing industries where the billing of material or the list of the parts used in the machine is mentioned on the final product. BOM was traditionally used in manufacturing processes. Manufacturers use BOMs to keep track of the parts used to make a product. This helps in tracing the exact part if the defect had been discovered in the product. 

It started from the security breaches like Codecov, Kaseya, and Apache Log4j. This led to the US government issuing the Executive Order to follow certain rules and guidelines while doing business with the US government. According to the guidelines, vendors must secure their software to ensure the safety and integrity of software applications used by the federal government. This led to the origin of SBOM in the software industry which soon is likely to become a de facto standard for all organizations to follow. 

SBOM as one of the pillars to Security 

Gone are the days when organizations developed applications in-house using their own software pieces, though there are a few exceptions. Businesses are changing with rapid pace and so are the releases. With CI/CD approach in DevOps practices, the releases are more frequent. No wonder, to reduce the time-to market, developers opt for the readymade components or the open-source code that can meet the time crunch demands. This may result in filthy entry of malicious code into the software.   

SBOM enables organizations to identify and track all third-party components, in particular open-source components, and comply with licensing requirements. It also helps ensure that the organization does not run vulnerable open-source components and keeps track of critical updates and patches. It enables organizations to utilize open-source components without guilt, as needed while maintaining security and compliance. 

SBOM Standards:  

The use of open source and on-the-shelf, components are unavoidable, what can be done to avoid vulnerabilities is to maintain the list of ingredient software components in a standard format so that it is understandable, readable, and universal throughout the software supply chain ecosystems.  

 For that purpose, the NTIA Software Transparency Working Group on Standards and Formats was established in 2018 to evaluate current formats for Software Bills of Materials and identify potential future uses. The group examined existing standards and initiatives related to identifying external components and shared libraries used in software products and communicating this information in a machine-readable format.  

The working group found that three formats are commonly used. The key takeaway is that SBOM data can be conveyed in various formats and the ecosystem should support interoperability between them. 

Following are the three formats for SBOM- 

1. Software Package Data Exchange (SPDX®), an open-source, machine-readable format developed by the Linux Foundation and now an ISO/IEC standard
2. CycloneDX (CDX), an open-source, machine-readable format developed by the OWASP community
3. Software Identification (SWID), an ISO/IEC industry standard used by various commercial software publishers

What all SBOM must include? 

 According to the NTIA standard, an SBOM must include: 

1. Author Name—usually the organization that develops the software. 
2. Vendor Name—the name of the software vendor, including aliases (alternative names). Vendor and author may be different if a supplier is creating an SBOM on behalf of the vendor. 
3. Component Name—the name and possible aliases of the software component. 
4. Version String—the format of the version information is free-form, but should follow common industry usage. 
5. Component Hash—the best way to identify a software component is to use a cryptographic hash that serves as a unique identifier. 
6. Unique Identifier—in addition to the hash, each component must have an ID number that identifies it within the SBOM. 
7. Relationship—defines the relationship between the component and the package.  
8. In addition to these minimum requirements, an SBOM can include additional information such as security scores, common vulnerabilities and exposure codes (CVEs) of known vulnerabilities in software components, and their severity. 

software Bill of Materials Best Practices 

Regular Updates 

As the code is revised very often, there is a good chance that third party components are being added, removed or replaced.  These changes can happen at any time across multiple teams, and must be tracked in real time, otherwise the SBOM will quickly become outdated. 

Data Integrity 

Audit of contents of SBOM is a crucial part.  The contents of the SBOM must be auditable along with all version numbers and licenses. Information in an SBOM must come from trusted sources and must be verifiable by a third party.  

Mark the problematic components 

The SBOM should: 

Enlist the existing files and components 

Mark the files and components that are in active use 

Mark the vulnerable components that require attention 

Update protocol  

As mentioned earlier, SBOM documents will also go under revisions as and when changes are made into the software. There should be a protocol to associate the revised SBOM to the updated version of the software.  

Conclusion 

The SBOM is a practice followed in the manufacturing industries where the Billing of Material or the list of the parts used in the machine is mentioned on the product. With the rapidly changing business needs, software releases became frequent which led to the use of on-the-shelf and open-source components. This paved the way to keep track of such software components so that tracing of the vulnerabilities and its mitigation becomes easier. A well-maintained SBOM document can act as a lifesaver in this scenario. If SBOM is practiced scrupulously , vulnerabilities can be triaged earlier, in turn creating a bastion to safeguard the software. 

 If you have any queries regarding DevOps/DevSecOps/GitLab adoption, please write us at – 

 https://fineshift.com/contact/ 

 To know more about our services please click the link below- 

 https://fineshift.com/services/