What is a software bill of materials
If you were to build a house for the most important people in your life—for instance, for your family—comfort and security would be your top priorities. Apart from safely designed spaces and ample living space, you would want to make sure that the structure is building code compliant and made from materials that you trust.
This is exactly why a bill of materials is a crucial element in software development. In the same way that documenting building materials and designs used in a construction project establishes structural integrity, having a complete list of software dependencies and open source components in your source code allows you the extra confidence about the applications you are using.
In the wake of security issues brought about by incidents such as the Heartbleed Bug and Log4j exploit, the Biden administration issued an executive order on improving national cybersecurity in May 2021. The goal of the executive order is “to modernize [the federal government’s] approach to cybersecurity.” and “to keep pace with today’s dynamic and increasingly sophisticated cyber threat environment.”
One of the key developments mandated by the EO is adding a mandatory software bill of materials (SBOM) to be included for all government software procurements. This requires all software companies wishing to sell to the US federal government must provide an SBOM for each product sold.
According to the Cybersecurity & Infrastructure Security Agency, an SBOM is “a nested inventory, a list of ingredients that make up software components.” It lists down all the building blocks present in a software and allows information and security professionals to: (1) verify all components have no known vulnerability, and (2) trace the software supply chain and therefore manage risks in the event of a possible exploit.
How does an SBOM help cybersecurity?
To put things plainly, the SBOM requirement is based on the aspect of transparency. That may raise a few eyebrows: wouldn’t a complete list of all software dependencies be equally dangerous?
The short answer is possibly yes, but it is important to note that an SBOM is merely a reference. It is not meant to curtail threats nor limit exposure to vulnerabilities on its own (more on this later). In essence, it serves as the “guide” or manual for understanding and mitigating risks inherent to a software product by, for example, listing all open source libraries and their respective versions incorporated into that product.
The idea is that more transparency reinforces quality and security especially amongst the open source software community. With more eyes on a particular tech or code, issues and vulnerabilities are discovered and remedied more quickly—sort of like the idea behind blockchain operating like a public ledger. And in this case, the benefits far outweigh the risk of documenting your source code components.
Open source programs are software or bits of code that is published and made available to the public—and it has been so useful and fundamental to contemporary software development that you would be hard pressed to find a functioning program or application that does not utilize open source components.
The architecture of modern software is highly interdependent.
Suffice to say, the main benefit that a bill of materials provides to cybersecurity is by providing transparency into a software’s supply chain. A software supply chain is every component that is used by an application or plays a role in its functioning. You might see where this is going. A software supply chain is only as strong as its weakest link.
Take for example the log4j exploit. According to CISA, log4j is a software component that is used to log security and performance information in consumer, enterprise services, websites, and applications. There was a problem: An unauthenticated remote actor could exploit this component and take control of a system with the Log4Shell. Log4j was so broadly used by companies and organizations around the world that when news of the vulnerability broke out, everybody was scrambling to remove, repudiate, and patch out all applications associated with the component.
For the purpose of this blog, we are more interested in how an SBOM could have helped mitigate the associated risks with such a widespread vulnerability.
The underestimated benefit here is time. If you maintain an SBOM for your product, it would be easier to verify how much of your software supply chain has been impacted by a newly discovered security flaw. Combing through your source to see if you’re affected takes precious time that could have otherwise been used to patch or remove the affected component.
Furthermore, if you’re publishing software for widespread use (e.g. commercial software), maintaining an SBOM provides a crystal clear picture of what risks or issues might be present in third party components your project uses, allowing you to remedy these proactively before there’s a larger exploit or incident, instead of reactively when the damage has already been done.
In short, an SBOM helps security and IT professionals by providing a complete list of possible program dependencies. This list either helps them identify and maintain vulnerable components earlier in the software development life cycle (SLDC), or otherwise helps them swiftly identify where to make reparations in the decisive moments of a security breach.
A visualization of a project’s dependencies and their properties from Google’s Open Source Insights Project
Zero trust—even for yourself
In the same EO, there is a reference to a zero trust model—wait, weren’t we talking about creating a list for transparency? Yes, but we have not addressed to whom we should be transparent. An SBOM should generally be only accessible by people with the right clearance. That includes your own DevOps engineers, cybersecurity and compliance personnel, and in some cases, your trusted clients. In the hands of these people, an SBOM is a very powerful tool in your defense against malicious actors.
A lesser known purpose of an SBOM is to protect companies from themselves. Apart from verifying who has access to sensitive information such as your product’s bill of materials, the zero trust model also relies on the following tenets:
- Right person(s)
- Right data
- Right type of access
- And only for the right reasons.
These four elements severely limit how much of a company’s sensitive data is accessible by employees, which is a core tactic used for minimizing the surface area and potential vulnerabilities in an IT system. No user or system is automatically trusted by default, regardless of their location or network environment. “Zero trust” operates under the assumption that all entities, whether inside or outside the network perimeter, should be treated as potentially untrusted and subject to verification and authorization.
There are many different benefits in following a zero trust model of security. In fact, some of your favorite apps and programs might already be using it. Here are some practices that you may have already experienced:
- Multi-factor authentication (MFA)
- Just-in-Time (JIT) access
- Continuous monitoring
- Conditional access
- Device health checks
- User and entity behavior analytics (UEBA)
How do you generate a software bill of materials?
An SBOM is a key element in a wider security architecture. Shoring up defenses comes with “an acknowledgement that threats exist both inside and outside traditional network boundaries”.
Planning and Preparation
So how do you create an SBOM? First off, you must identify what type of SBOM you need. This will depend on what program you have, how mature it is in its SLDC, and overall size of the program.
From Cybersecurity and Infrastructure Security Agency: Types of Software Bill of Materials (SBOM) Documents
The next consideration is the format of the SBOM. As of the time this article was written, while there is no universal data exchange format yet, there are three prevalent formats: SPDX, CPE and CycloneDX. Any of these open source options should be sufficient for most use cases, but find the one that best suits your program. As for the actual file documentation format, SBOMs can come in formats as simple as a .csv file but can also be delivered in a wide variety of other file formats such as: .xlsx, .spdx, .xml, .json, and .yaml.
And if you are interested in creating your own bill of materials for collaboration with federal agencies and institutions, it is best to refer to their public facing forums to see their policies on SBOM formats. For instance, the National Telecommunications and Information Administration does not have a standard format but does specify the minimum elements that a bill of material should contain. Other federal agencies might have differing requirements.
Planning an SBOM
Creating and managing an SBOM is a complex undertaking especially if you have a large program or utilize a wide number of free and open-source software (FOSS) and libraries. Creating an SBOM from scratch is usually the hardest part especially if you are opting for a more manual approach (maintaining one is by no means a meager task but is not as complicated as the first bill made). Here is a general checklist for creating and keeping an SBOM up to date:
- Defining the project scope
- Listing known FOSS components and libraries used
- Establishing protocols for monitoring component updates
- Setting up vulnerability alerts and security notifications
- Updating the SBOM to reflect changes
Manually Creating an SBOM
Manually creating an SBOM is possible, but software composition analysis (SCA) programs can greatly reduce the resources required to do so. A reputable SCA tool would include third-party and specialized components used in your source but it is still up to the developer to verify and check a one-to-one correspondence with the actual source This is where manually checking and recording source code components is essential. For example, an SCA tool might tag your source as dependent on the an library when in reality you are merely using a single binary file, a code snippet, or even a reference. Freeform input is acceptable as long as you follow whatever format you originally chose.
Generating an SBOM with Tools
As mentioned earlier, creating an SBOM with tools is usually more practical and faster. SCA programs automatically scan your source and list down all the components complete with version number, library information, and similar helpful details that will complete your SBOM.
These tools will analyze your source code and return an output in the format of your choosing. One of the most common methods SCA tools use to generate SBOMs is the upload and scan method. This may involve initiating the process with an API call, verifying the call with an account with the right privileges, and supplying one-time authentication keys. The actual scan happens off site and the service provider provides the final output document.
Recall the concept of zero trust: working with tools (i.e. third party providers) should undergo an even higher level of scrutiny than if you were executing everything on premise. You would not want to grant admin privileges to an entity you do not trust.
A sample SBOM in a CycloneDX .json format opened in UltraEdit. Taken from GitHub.
Summary
Whatever your stance is on zero trust and the creation of SBOMs, there is no denying that the industry is trending towards it. More and more companies and software developers—not just federal agencies—will be requiring an SBOM as part of their purchase order. Similarly, even the open source community will be more trusting
Creating an SBOM should not only be considered because it is a federal requirement, instead generating an SBOM should also be considered for the benefits it provides in strengthening your software supply chain. It bolsters your defenses in preventing vulnerabilities from even reaching your users, and it also allows you an extra layer of remediation when huge security flaws are detected.
0 Comments