Software Bill of Material (BOM) Value

A Bill of Materials (BOM) for software affords the following benefits

  1. Licensing – each components licensing requirements can be identified & approved
  2. Vulnerabilities – component & application risk can be assessed
  3. 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:

  1. Provide a list of all component license agreements
  2. What is the highest CVSS score of the components & what is the plan to reduce this exposure?
  3. What is the impact to updating a component to a new version?
A product or component BOM should contain enough information for the team to manage (hopefully pro-actively) development, in spite of daily concerns: management requests, new updates, team turnover, alternative design considerations, etc. Each component’s BOM should be in tracked at it’s highest level via source control.
BOM Items for each sub-component:
  • Name
  • 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.
Candidates for BOM-like tracking: product software, build machines, test computers, & deployment platforms. For example, the build machine should be a strictly controlled resource with documentation to support employee hand-off with minimal disruption. If the creation/provisioning of a new build machine takes more than a couple of hours, the company has a significant risk.

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!

😞

 

Advertisements
Software Bill of Material (BOM) Value

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s