Similar to a "bill of materials" which is used in traditional manufacturing supply chains to track the suppliers, parts and versions used to build products, a 'software bill of materials' – also known as a BoM – is used to inventory the components used to build software. A component is source code that has been compiled into a binary building block, making it easy to add robust features during the development process.
Virtually any programming language can be packaged as a component. Java is the most popular component type, commanding the majority of the market today.
These re-usable components are most often downloaded from public open source repositories but can also be proprietary or from a third party organization. By using these modular building blocks, organizations can accelerate innovation to improve time-to-market and competitive differentiation. In fact, it is not uncommon for a typical application to be 80-90 percent comprised of components.
Without a software bill of materials, organizations are unaware of the components they’ve used in any of their applications. Therefore, they can’t determine which components are outdated, or which ones have a known security vulnerability or license issue. If a security vulnerability is newly discovered, organizations have no easy, automated way to determine if they use the component and where.
We cannot imagine a traditional manufacturer lacking the ability to know what suppliers or parts are used in products we rely on every day. For example, if an air bag or braking mechanism was discovered to be defective, the manufacturer would have no easy way to know which automobiles and consumers were impacted. No processes would be in place to quickly remediate and minimize the impact of the problem.
Yet, in our software, the lack of visibility impacts consumer privacy and safety, and exposes organizations to legal risk, security breaches and development inefficiency.
Due to lack of visibility, automation and processes, it is extremely difficult for an application development team to assess the quality of a component before, during or after it is used in an application. A typical application contains 106 components, 24 of which have known security vulnerabilities and 9 known restrictive licenses.
Insurance companies, lawmakers and industries are rapidly addressing this issue, including legislation such as the Cyber Supply Chain Management and Transparency Act of 2014 and guidelines already issued by OWASP, PCI, FS-ISAC and many others. The first step toward reducing known vulnerabilities in modern software starts with the visibility provided by a software bill of materials.
Sonatype offers a free tool called the “Application Health Check” (AHC) to create a free software bill of materials. Since our BoM is created using robust features from our Nexus Lifecycle and Nexus Auditor solutions, the quality, depth and breadth of information exceeds what you will typically find in from other BoM offerings.
Creating your software bill of materials is a quick process. First, you download the tool and select a java application archive for analysis. Within five minutes or less you will receive an email with a link to your summary report. This analysis gives you a high level summary and confirms that you have scanned the appropriate file type, usually a war or jar file. From there you can request the full, detailed report, which includes the complete bill of materials inventory.
Upon request, the full, detailed report is sent to you within a few hours. Here you will find the complete software bill of materials as well as additional component insight.
This “policy” tab conveniently combines the severity of open source component vulnerabilities or license issues (1st column) with an inventory of all components including open source executable components (2nd column), relative component popularity (3rd column) and component age and release history (4th and 5th columns) so you can see if a newer version is available.
To focus on just the known security vulnerabilities, you select the “Security” tab. This provides the threat level (1st column), problem code which links to the original Common Vulnerability Enumeration (CVE) (2nd column). Sonatype, Inc. curates this information from data published by the National Institute for Science and Technology (NIST) in the National Vulnerability Database (NVD) as well as a wide variety of public and private sources. The component name and version is in the 3rd column.
The “License” tab gives you a close-up view of potential license issues, including restrictive licenses in your application. Restrictive licenses are listed in order of concern, with the most restrictive, problematic licenses listed first (1st column) and an inventory list of components (2nd column).
In most cases, even deeper details are available by clicking on any data item in any report tab. You can create a report just like this using the free software bill of materials tool.
|Questions to ask...||Sonatype|
|Do you need to upload your application, or do you download the analysis tool?||Download the analysis tool to your environment.|
|What is scanned?||Binaries|
|What type of component matching is used to ensure precise matching?||Advanced binary fingerprinting to precisely match components and avoid false positives.|
|What component types are included in the software bill of materials?||Java, (more component types coming soon)|
|If known vulnerabilities are found, can you link to the associated CVE?||Yes|
|How is the CVE data compiled? Is it straight from NIST, or is it curated?||Sonatype curates data from a wide variety of public and private sources, then analyses the data to understand precisely which component is impacted within the component group.|
|How many pages is a typical report?||5-7 pages on average|
|How long does it take to run the analyses?||The summary results are delivered in about five minutes. If requested, the detailed analysis is sent in a few hours.|
|What is included?||Sonatype|
|Known security vulnerabilities?||Yes*|
*Java only. Other language types coming soon.
The free Application Health Check service can be used to analyze a few applications in production and is an excellent way to learn what components are used and any known security, legal or quality issues. As such, the Health Check tells you what has occurred in a few of your applications.
By contrast Nexus Lifecycle helps you keep outdated and defective components out of your software and enables you to monitor unlimited applications both in development and in production. Through complete software supply chain automation and visibility, organizations can use policies to define acceptable component types, then monitor and control usage at every life cycle stage.
An up-to-date component data feed streams into the Nexus Lifecycle product, and is integrated into popular development tools including the IDE and CI servers. Development teams have instant access to component information and can easily choose a better quality component from the start. Production applications are continuously monitored with alerts sent to various stakeholders if a component is newly discovered to be vulnerable. Nexus Lifecycle proactively empowers an organization to avoid undesirable components and associated risk, unplanned work, and technical debt. With Nexus Lifecycle, organizations can eliminate vulnerabilities and produce ongoing, constantly updated bills of materials for any and all applications to prove that chosen components are safe.
Nexus Auditor continuously monitors production applications and inventories and identifies potential component issues after-the-fact. It is ideal for organizations who are just starting with software supply chain automation and want to gain visibility into existing component consumption and risk before automating the entire software supply chain.
Attention: Java version 1.7 or higher must be installed first in order to run this software. Safari users, please be sure your browser does not automatically unzip files. Windows users, please unzip and run the .exe file inside to run the application.