Black Duck Detect 11.5.1: Prevent missed Gradle dependencies in release BOMs

Black Duck Detect 11.5.1 fixes Gradle scans that could report zero components for phantom subprojects, protecting release owners from approving incomplete BOM evidence.

What changed in 11.5.1

The Gradle init-script regression affected projects where a container or phantom module had no build.gradle file, while dependencies were declared in the root build.gradle. Those modules could be assigned an empty configuration set, resulting in zero detected components.

For a release organization, a successful scan with an incomplete component inventory is more concerning than a visible failure. It can leave open-source policy, license, and vulnerability decisions based on partial evidence.

This release also fixes an IndexOutOfBoundsException during component-location analysis when a version string contains spaces. That correction reduces avoidable scan interruptions in repositories with nonstandard version metadata.

Why the Gradle correction matters to governance

A BOM is commonly treated as an approval artifact: it supports security gates, legal review, supplier obligations, and audit inquiries. If a Gradle build reports no components for a module that actually contributes dependencies, downstream controls may not evaluate the full release content.

Release and platform teams should treat this update as a data-quality correction, not merely a scanner maintenance patch. The fix reduce the chance that a green pipeline is interpreted as proof of complete dependency coverage when it is not.

Recommended actions:

• Identify multi-project Gradle builds with container or phantom subprojects.
• Re-run scans for representative release branches after upgrading.
• Compare component counts and BOM differences against the prior baseline.
• Investigate newly detected dependencies before changing policy thresholds.
• Retain before-and-after scan records for governed releases.

Operational impact for CI/CD teams

The immediate implementation work is limited, but validation should be deliberate. A scan that previously returned zero components for an affected subproject may now produce dependencies that require policy evaluation.

This can affect workflows in several ways:

• A build may expose license or security findings that were previously absent from the BOM.
• Exception records may need reassessment if they were issued from incomplete inventory data.
• Build engineering teams may need to confirm root-level dependency declarations are being represented as intended.
• QA teams should add a regression case for phantom-module dependency detection.

A practical control is to establish expected component-count ranges for high-value repositories. Significant movement does not automatically indicate a problem, but it should trigger review by the application owner and security team.

Upgrade considerations carried into 11.5.x

The 11.5 line also includes changes relevant to upgrade planning. Quack Patch output now defaults to the Detect scan output directory, and that output is included in the diagnostic ZIP when the feature is enabled. This improves artifact collection because scan evidence and generated patch output are retained together.

Teams using Python, Rust, Bazel, sbt, uv, BitBake, or Setuptools should review the earlier 11.5.x fixes when deciding test scope. These updates address parsing and dependency-reporting edge cases, including Python extras and environment markers, Cargo caret declarations, Bazel partial query results, and excluded uv optional dependencies.

For Setuptools projects with unsupported install_requires syntax, Detect now fails fast rather than silently producing an incorrect BOM. That is a useful control: an explicit failure creates an actionable remediation path instead of misleading release evidence.

Network, endpoint, and platform planning

Detect naming, documentation links, and download endpoints have changed. Update internal runbooks, bookmarked documentation, automation references, and allow lists as part of normal release engineering hygiene.

• Use repo.blackduck.com for code downloads; Detect 10.0.0 and later require it.
• Use detect.blackduck.com for Detect script downloads.
• If using SCA Scan Service, confirm the documented service and storage IP addresses are allowed through firewalls.
• Upgrade Detect 8 installations to 8.11.2 and Detect 9 installations to 9.10.1 where those versions remain in use.

There are also forward-looking platform decisions to schedule. Java 8 support is planned for deprecation in the anticipated 2026 Q3 Detect 12.0.0 release, aligned with Cyber Resilience Act compliance timelines. CentOS support in Detect Docker Inspector, along with imageinspector.service.port.centos, is deprecated and planned for removal in 12.0.0.

These are governance items as much as technical ones. Runtime and operating-system dependencies should be owned, recorded, and remediated before a forced upgrade creates delivery risk.

Recommended rollout approach

Use a staged deployment rather than updating every pipeline at once:

• Upgrade a representative set of Gradle repositories, including multi-project builds.
• Compare BOMs, component counts, policy outcomes, and scan durations.
• Validate download endpoints and SCA Scan Service network access from hosted and self-managed runners.
• Update pipeline templates, internal documentation, and operational support procedures.
• Promote the version through controlled release rings after evidence review.

This approach gives security, platform engineering, and application teams a shared basis for deciding whether BOM changes reflect newly corrected discovery or an unrelated build configuration issue.

How Merito helps

Merito helps organizations assess Detect upgrade impact across repositories, CI runners, network controls, and release-governance processes. We can build regression test packs for dependency detection, analyze BOM deltas, update pipeline standards, and document evidence for audit and change approval.

The goal is not simply to deploy 11.5.1. It is to make sure corrected scan results are understood, governed, and acted on consistently across the software portfolio.

Merito is an authorized Black Duck reseller and services partner. Our Black Duck Detect team can scope licensing, sizing, and rollout for 11.5.1, and our enterprise upgrade services help you plan and validate the upgrade with minimal disruption to release schedules.