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

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

MORE BY THIS AUTHOR

Do You Have the Right Tools in Your Application Security Toolkit?

| Jan 16, 2017

Application vulnerabilities are the #1 cyberattack target, but how do you know you are using the right tools to secure them? RSA Conference 2017 is just a few weeks away and all you need to do to get a sense of the mind-boggling array of security solutions on the market is to take a walk through

| MORE >

It’s Time to Select Our 2016 Open Source Rookies

| Dec 5, 2016

Looking forward to this year’s Rookies and looking back at Rookies past This time of year is one of great anticipation at Black Duck. We are eagerly anticipating a very special delivery. A crew of helpers is busy putting together a list. It will be thoroughly checked and even checked twice. I

| MORE >