A Bill of Materials (BOM) for software affords the following benefits
- Licensing – each components licensing requirements can be identified & approved
- Vulnerabilities – component & application risk can be assessed
- Reduced debugging – known versions ensure consistent execution by developers, testers, & production
Any complicated product has many components & sub-components. Open source usage with the free availability to include, update, or remove components presents a large risk to the company. The development team should be able to quickly answer basic questions:
- Provide a list of all component license agreements
- What is the highest CVSS score of the components & what is the plan to reduce this exposure?
- What is the impact to updating a component to a new version?
- Author / Organization
- Source website
- Source license URL
- A copy of the license (probably necessary if not an standard license)
- Reason for inclusion
- Responsible person
- URL to it’s CVE disclosure list (for example, Tomcat is pro-active: http://tomcat.apache.org/security.html)
- Risk discussion – it’s common for vulnerabilities tracked in https://cve.mitre.org to have a high CVSS (https://nvd.nist.gov//vuln-metrics/cvss), but not be applicable to a component’s usage. For example, an openssl vulnerability with signature generation may not affect the product if openssl is strictly used for secure communication. This should be clearly documented with analyst name, date, & discussion for each CVE.
The unfortunate part of this proposal is that it is non-trivial. Implementation requires time, effort, and discipline. On-going maintenance has a similar burden. However, creating this retroactively is much worse – I’ve been there, done that!