With the mass adoption of open source software in recent years, there has been an increasing tendency to include it as dependencies. This means that software systems use open source components for reusability and reliability reasons. However, the things that are easy to include are equally difficult to try to track, and things can get out of hand if there is no control or policy for including them.
This is why some skeptics wonder if there is a more effective way to leverage this power and convenience without causing more problems in the long run. There should be a way to record all of the parts that are required to compile, host, and run all of the software components of the infrastructure. We call this list a “bill of materials,” and this article will be devoted to explaining how it helps us address the risks of trusting external code.
Bill of Materials for Software Development
The term “bill of materials” (or BOM) is taken from industrial manufacturing. It is a list of raw materials or assembly parts along with the quantities of each item that are needed to manufacture a complete component. You can think of it as the list of ingredients.
The BOM is vital because it serves as a verification document and helps ensure that all of the necessary parts are present and available in the proper quantities. If one part is missing, for example, or if the manufacturer was delayed in delivering the part, then there would be a flag in that BOM showing the issue with that particular part. Here is an example of a BOM file:
We can extend the analogy of the automotive recall to the software industry. This is what we call the Software Bill of Materials (sBOM), and it lists packages and library components. For example, you may have a node.js project where the node_modules folder contains all of the required packages that are used for building and running the application. If some of them turn out to demonstrate vulnerabilities or malicious code that was somehow injected via the registry, then your software pipeline is at risk.
The sBOM should list all packages used by all software components, their versions, their license models, a virus scanner report, and when they were last updated. Each package is traceable to the list of components that are connected so that you can trace the affected components if there is a failed scan. You also want to be able to upgrade or replace them in case of depreciation or a CVE exposure.
Why Do You Need a “Parts List” for Software?
A “parts list” is a list of packages and dependent libraries that your software services need in order to operate. If the programs import libraries from NPM, Maven Central, or any other registry, then you can count them as parts.
If you have complete knowledge of those parts and what is required to build or compile the applications in your organization, then you can mitigate a whole series of issues and risks involved in maintaining those programs.
For example, if a new vulnerability is issued, then you can check if you are affected by comparing the affected versions against your existing bill of materials. If you have matches, you can find out which systems are affected.
Another example would be discovering that a library or dependency has been removed from a registry for whatever reason (such as license changes, legislative requirements, or maintainer decision). In that case, you wouldn’t be able to use that component, and you would have to utilize a different version or consider a replacement. If you maintain an accurate BOM list, you might be able to find alternative parts or libraries that can be replaced. This would mean that you’d have a contingency plan attached to some critical BOM items just in case.
Ultimately, having a better view of the components that your software depends on will give you a clear view of your risks and the vulnerabilities of your components.
Sample “Parts List” Scan
How can we figure out what should be on this parts list? If you ask the developers, they will likely show you the package-lock.json or the Gemfile.lock from their projects. However, these do not include other parts like hardware, OS modules, license types, or any other details.
You can either use automated tools to retrieve that information as part of the CI/CD process or as part of your regular scanning of repos, or you can use an external vendor to manage that for you. For example, to check if some licenses are business-friendly, you can use the js-green-licenses checker from Google:
$ npx js-green-licenses –local ./
This would show you unlicensed or unsuitable packages from a predefined list. However, it only works for npm projects, and it only checks open-source licenses.
If you want to cover all bases, you will have to find all of the tools that show the list of dependencies and include some sort of policy that they must publish their parts list before deploying to production. Once this part is configured, it will be considerably easier to enroll applications and record their bill of materials.
Next Steps
With the general adoption of open source technologies, businesses are taking on the additional risks of vulnerabilities, deprecated versions, and hostile license models.
Before you jump on the bandwagon of the latest sBOM trends, it’s critical that you assess the current security posture of your organization and identify how this change would gain you more credibility and increase your customers’ confidence in your products.
Once your path is clear, it’s important to assess present standards and best practices for compiling the list. You should start by reviewing the ntia website material from top to bottom. When you have the requisite domain knowledge, you can make informed decisions about the appropriate strategy for your organization and establish some baseline policies.
You need to be on top of documenting and capturing any changes or updates; otherwise, if left to their own devices, people tend to ignore them. It’s difficult to know the best way to capture software bills of materials in advance, and since security standards change constantly, it’s incredibly difficult to establish a long-term solution.
Thankfully, there are companies like Checkmarx that can help you with that. By utilizing their SCA solution, you can scan and compile the list of materials for software components. You can check it out and request a free demo today.
Theo Despoudis is a Senior Software Engineer, a consultant and an experienced mentor. He has a keen interest in Open Source Architectures, Cloud Computing, best practices and functional programming. He occasionally blogs on several publishing platforms and enjoys creating projects from inspiration. Follow him on Twitter @nerdokto. He can be contacted via http://www.techway.io/.
Download our Ultimate Guide to SCA here.
