Based on our recent migration to Black Duck for production scans, my team ran into a common pain point: noise. Every release scan flagged thousands of new components, most of which were just transitive dependencies already present in our development branches. It made identifying genuinely new risk for a production release incredibly time-consuming.
The solution we implemented was establishing a 'golden' Bill of Materials (BOM) to use as a baseline for comparison. The goal is to have a clean, approved snapshot of components that constitute your *releasable* artifact, not every library that appears in your dev environment.
Here’s our workflow:
1. **Create the Golden BOM from a Release Candidate:** We trigger a Black Duck scan against our final release candidate branch, *after* code freeze and all dependency updates are complete.
2. **Curate the Results Manually (Once):** In the Black Duck project, we review the list. We explicitly approve all components that are:
* Direct dependencies we intentionally included.
* Necessary transitive dependencies (we map these to their parent).
* Bundled tools or libraries required for build/runtime.
3. **Set the BOM as the Baseline:** Using the Black Duck UI, we mark this specific scan as the "Baseline" for the project. This is your 'golden' reference state.
4. **Diff Against Future Scans:** For subsequent production scans (e.g., for the next release), we run the scan and use the "Compare to Baseline" feature. The report now highlights *only* the components that have changed—new additions, version updates, or removals—against your known-good release state.
Key pitfalls to avoid:
* Don't use a development branch scan as your golden BOM; it's too fluid.
* Don't skip the manual curation step. Auto-approving all components in the RC scan defeats the purpose.
* Remember to update your golden BOM for each major release. It's a living baseline, not a one-time setup.
This approach cut our release review time by about 70%, because we're now focused on a manageable delta. It turns Black Duck from a compliance checklist tool into a genuine risk gate for release management.
—Anita
—Anita
This is the right approach, but your step 2 is a ticking time bomb. Manual curation doesn't scale and becomes obsolete immediately after the next patch release of a library.
We automated the "golden BOM" by pinning the scan to the artifact hash of the last production deployment. The process is:
1. After a successful production deploy, our pipeline captures the container SHA and triggers a Black Duck scan on *that exact image*.
2. The results are pushed as a JSON artifact and tagged with the release version.
3. For the next release candidate, we diff the new scan against that JSON baseline programmatically in the pipeline, failing the stage if net-new high/critical vulnerabilities are introduced.
This makes the baseline immutable and directly tied to what was actually shipped. You're comparing to last known-good production, not a manually reviewed list that someone forgot to update.
shift left or go home
Manual curation at step 2 sounds like a huge initial lift. How big was your team when you did this first pass, and how long did it take? We're a small group and that kind of manual review feels daunting 😅
Also, what happens when a transitive dependency gets updated by its parent in the next release? Do you have to go re-approve it, or does your "approved" status somehow carry over?