New Hub Features Make BOM Management and Code Locations Easier
This past week we released version 3.5 of Black Duck Hub. This release focuses on some subtle but useful user experience enhancements that make it easier for teams to manage larger bills of material (BOMs) and scanned code locations.
Component Review Status and Comment Tracking
Although Hub’s multi-factor discovery mechanism - which combines deep source code scans, package manager declaration analysis, and dynamic/transitive build dependency detection – does a great job of assembling a complete and accurate bill of materials for your open source, most teams will want to perform a post-scan BOM review.
Hub 3.5 adds two features that help make this review easier. The first is the component review status indicator, which shows up next to each entry in the BOM view.
As reviewers confirm each BOM entry they simply click the indicator to mark the component as reviewed. The BOM view can be configured to show only components that have or have not been reviewed to make it easier to focus on those component entries that are either confirmed, are new, or require further scrutiny.
In addition, Hub now provides a way for users to add, edit, delete and review comments on each component in the BOM.>
Our customers have described a wide range of uses for these features, but we’ve intentionally avoided over-engineering them, so that they can address a lot of different needs without adding complexity to the Hub UI. This simplifies BOM management in your Hub instance.
Component Identification Views
As I mentioned above, Hub uses multiple mechanisms to discover the open source in an application or codebase.
The example above shows multiple components that each have to be identified, both through deep source scanning (Match Type Exact) and package manager declarations (Match Type File Dependency). Hub 3.5 updates the Sources view (formerly called the Files view) to show details for all the match sources. For example, if I click on the “3 Matches” link for the ANTLR 2.7.7 entry above, I’ll be taken to the Source view, which shows me how that component was identified.
In this example ANTLR was located both in the source scan as well as a transitive dependency of Hibernate Core 5.0.10, which was declared in the Maven package manager file.
This view of transitive dependencies is important, not only because it provides a more complete list of components in use in my application, but because it also allows the full list of potential vulnerability and license risks to be assessed. If you only examine the top-level declarations, you miss all the subcomponents of those top-level items. Hub captures these transitive dependencies, and this view allows you to see the complete dependency chain.
Customizable Code Location Names
When you scan a source code directory, Hub registers the results as a “Code Location.” You associate Code Locations with projects in the Hub to generate bills of materials. In prior versions, Code Location names were automatically generated using a combination of the machine and directory name where the scan was performed. However, customers told us that this approach created two problems.
First, scanning the same file system from different machines, as is common in a distributed/automated build environment, resulted in redundant Code Location entries. Second, since a code location can be associated with only one project, there was no easy way to share a directory of common code across multiple Hub projects.
Code Location naming in Hub 3.5 addresses both needs. Now, when you run the Hub iScan client, you can specify the name you want to apply to the scan results. Any subsequent rescans using that same Code Location name will replace the prior scan results, regardless of what machines perform the scan. Likewise, you can rescan the same directory structure multiple times using different names to generate unique Code Locations entries for the same code so you can allocate them to multiple projects.
The example above shows four code locations related to a sample codebase called railsgoat. The first two entries (one representing the source files and the other representing a Ruby gem file) use customized names, while the second two use the automatically generated names. However, because they have unique names they are treated as four separate code locations. They can now be mapped to and managed in two separate Hub projects.
If you’d like to learn more about these or any other Hub features, click the link below to schedule a live demo and free trial.