Black Duck Hub 3.5: Improved BOM Management & More

Black Duck Hub 3.5: Improved BOM Management

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.

Component Review Status Indicator

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.>

Action Pack 4.2.6 Comment

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.

Component Identification Methods

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.

Source View

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.

Code Locations

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.

Request a Live Demo

Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.


Did Lack of Visibility into Apache Struts Lead to the Equifax Breach?

| Sep 11, 2017

As most of you are aware, last Friday news broke of a major data breach at Equifax. As one of the major credit reporting agencies, Equifax maintains a vast amount of sensitive personal and financial information for residents of the United States and the United Kingdom, and this breach is reported

| MORE >

Hub 4.1 Makes Managing Open Source Risks Easier

| Aug 21, 2017

We’ve recently updated Black Duck Hub with a number of new capabilities that make it easier for teams to discover open source in their environment, prioritize their vulnerability and compliance management activities, and determine the best upgrade path for open source components that are

| MORE >

Introducing Black Duck CoPilot

| Jun 13, 2017

Today we’re happy to announce the release of Black Duck CoPilot (, a new cloud service that helps open source project teams catalog and report on their project’s dependencies and vulnerabilities. What is CoPilot and What Does It Do? Black Duck CoPilot is a

| MORE >