Software supply chain: Part 1
President Biden’s Executive Order 14028 in May 2021 called out the federal need to purchase software that include SBOMs, which they define to “Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.” This has been a huge catalyst for the security space, leading to more questions about the inner workings of widely used software both in the government space and vendors that do business with the government.
Today, many security players and code scanners in the market are finally starting to automatically generate SBOMs as part of their offerings, often with no added cost. While each one is a bit disparate in their exact offering, I view this as a great advancement in the space and gives way too much needed visibility into the complex code deployments that exist in modern cloud infrastructure.
If you are not familiar with how complex these webs can be, here is an example pulled from GraphMyRepo on the pandas data analysis framework, which is about 15MB in size and used by millions of companies globally.
There are many security vendors in this space, as well as open source frameworks that will scan your dependency tree. The major problem we have today is the SBOM is not created equally. SBOMs can be used for managing risk and determining vulnerability impact, if properly done, but it’s very hard to build holistic risk models when the data is not standardized across multiple platforms.
Here are three key points that you need to take away from your SBOMs:
Understanding where the software is used
As security professionals, we often ask ourselves the question “do we a piece of software and where?” This question continues to evolve with more complexities if we include software dependencies in development versus production level code. But what about when you have multiple products or multiple environments with different risk profiles? In order to make reasonable business decisions, you need to answer many more questions, which means having more metadata and environment information in addition to the SBOM. Understanding the software and where it is used will help build context to properly make risk decisions.
Charactering legal risk of your open-source libraries
One item often overlooked is the need to understand open source licensed software to ensure compliance to your organizations policy. Licensing can have legal ramifications and open your code to discovery and legal claims. You can read some of the past examples here. As I mentioned previously, additional points of data showing context, as well as a review date, will help build the foundation for ensuring compliance. Engineering use case will often drift over time which must be considered.
Understanding downstream libraries
Remember the story of the faker open source project that quite literally destroyed downstream users? Dependencies often have other dependencies that get overlooked during the scanning. It’s important to recursively search your code to uncover downstream libraries that may be affected, especially in the production pipeline.
Prepare for alternatives in advance
Vulnerabilities are discovered all the time in open source libraries, and often they take time to fix. These could me a matter of days, weeks, or even months. Knowing that you have potentially unsupported software is critical to being able to respond properly. You may need to remove code within the library yourself or fork and maintain the project internally. It may be unreasonable to completely remove all risk, but having a plan for the weak links in advance will mitigate this type of risk when it occurs.
The SBOM experiment has a long way to go, and many are trying to standardize the format to machine readable standards (SPDX, CycloneDX, etc) that go way beyond what I have mentioned above. We are moving in the right direction, however we must try to unify these standards into a common machine readable format or face an explosion of different standards.
As we continue to build larger and more complex modular software, we continue to increase the outside dependencies and surface area for supply chain attacks. While we can manually develop and gain more insights for “Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk”, the future is being able to automate the entire workflow process from findings to remediation.
Stay tuned for the next installment in the software supply chain series.
Related: Chainguard Trains Spotlight on SBOM Quality Problem
Related: Big Tech Vendors Object to US Gov SBOM Mandate
Related: Microsoft Releases Open Source Toolkit for Generating SBOMs
Related: Cybersecurity Leaders Scramble to Decipher SBOM Mandate
