Most health-conscious people pay close attention to labels in the grocery store. They want to know what’s in their food before they eat it, and they tend to make choices based on the ingredients, additives, preservatives, nutritional value, etc. The labels, and especially expiration dates, let buyers know if the food is healthy and safe to consume.
In this same way, it’s important to know what’s in your software before using it, so you know its ingredients are safe for your organization to consume. Since most software today is made up of open source components, combined with proprietary code (e.g., business logic) that makes everything work, having a list of all open source ingredients in the software you consume allows your organization to manage risk more effectively.
Therefore, leaning on what the manufacturing industry calls a “bill of materials” (BOM), we have the software BOM, or SBOM. An SBOM contains an accurate list of all open source software ingredients found in a software-based product. With this in mind—and due to a number of recent and notorious open source supply chain attacks drawing the attention of security experts, industry advocates, and even the US federal government—the current administration decided to act with regard to SBOMs.
On May 12, 2021, President Biden issued Executive Order 14028, “Improving the Nation’s Cybersecurity,” which states: “The term ‘Software Bill of Materials’ or ‘SBOM’ means a formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components.”
Security experts agree that an initial step toward the EO’s goal of enhancing software supply chain security is transparency, and an SBOM is now required for anyone selling software to the US federal government and its agencies. So, do organizations that develop their own software in-house, to be used solely to support their own operations, need SBOMs for their own applications? The answer is likely yes.
Why an SBOM for the Software You Develop Makes Sense
In the past, organizations that developed their own software applications primarily did it in-house. Developers and security teams knew the origins of the core components that made up their applications and had full control over the recipe, so to speak. However, this model is no longer acceptable to most organizations, primarily due to time-to-market demands. Management and customers alike expect faster and more frequent releases/updates thanks to their familiarity with some of the media and retail giants that update their applications and release new builds on a daily basis—if not more frequently.
This rapid-release capability is largely owed to more organizations integrating significant amounts of open source into their application stacks. Due to this move, the open source supply chain, community, and contributors are expanding exponentially. Even a weekly build might pull in loads of open source components that may have been updated by the community since the last version in use, and if developers and security teams don’t allow the updates to be performed within their own applications, they will be deploying builds with potentially known vulnerabilities. If any of your applications import libraries from NPM, Maven Central, or any other registry, then you are using open source in your codebase.
If you have complete knowledge of what open source “ingredients” are required to build or compile the applications your organization relies on, then you can mitigate a number of risks when trying to improve the security of your applications. Therefore, if a new vulnerability (e.g., CVE) is issued, you can confirm if you are affected by comparing known vulnerable versions against your existing SBOM. If you have matches, you can quickly determine which issues must be resolved before the next build is released.
Ultimately, having a better view of the open source that your applications depend on will give you a clear view of your own vulnerabilities and associated risks. However, there are quite a few caveats concerning SBOMs that you should be aware of. The first is as follows.
SBOMS Are Not Spreadsheets
Generating an SBOM report may sound relatively simple, but in most cases, it’s not. As you likely know, modern software projects make use of a long list of third-party open source packages, each of which often calls on many other packages as dependencies. This can create an extensive tree of dependencies being used by your software in the form of direct dependencies, dependencies of dependencies, and so on. Simply put, trying to create and manage an SBOM using a spreadsheet is nearly impossible, and if you attempt to manage your open source usage in this fashion, it will likely get out of hand very quickly.
At the end of the day, SBOMs just make sense. Understanding your own risk profile and doing everything possible to effectively manage and reduce your organization’s risk falls into the realm of due care, which is defined as, “the standard of care a reasonable person would exercise in the same situation or under similar circumstances.” If due care is not being upheld, then your organization, your developers, and your security teams could be viewed as negligent.
In the next blog in this SBOM/Software Supply Chain series, we’ll discuss what an SBOM report should include and highlight the easiest approach to generating a high-quality SBOM report using Checkmarx Software Composition Analysis (CxSCA) solution .
To see an SBOM being created live, don’t hesitate to request a demo here.
To learn more, don’t forget to join our Technical Meetup Series to dive into topics like SBOM and open source libraries. Checkmarx experts Alex Cohen, James Brotsos, and I will walk you through security vulnerabilities you might not even know you had. We’ll also discuss the latest industry trends and application security best practices. It’ll be an interactive discussion, so bring your questions and pick our brains about how to improve your processes.
Download Our Ultimate Guide to SCA Here
