Hey everyone, hoping to tap the collective wisdom here. We've just completed an upgrade to Black Duck Detect 9.0 in our CI/CD pipeline, and we've hit a real head-scratcher. After the upgrade runs, the scan report comes back successfully, but it consistently shows **0 components** identified. Our project is a fairly standard Java Maven application, and this was working perfectly under Detect 8.x.
I've been digging through the logs and comparing our old and new configurations. The upgrade process itself was smooth, and the Detect script completes with an exit code 0 (SUCCESS). No obvious errors are thrown, which makes the zero components result so puzzling. It feels like Detect is just not engaging with the package manager or signature scanner.
Here's a simplified version of our current invocation, which mirrors our previous working setup but uses the new 9.0 script:
```bash
bash <(curl -s -L https://detect.synopsys.com/detect9.sh)
--blackduck.url=" https://our.blackduck.instance"
--blackduck.api.token="***"
--detect.project.name="Our-Project"
--detect.project.version.name="main"
--detect.maven.build.command="clean package -DskipTests"
--detect.tools="SIGNATURE_SCAN"
--detect.source.path="."
```
Things I've already checked or tried:
* Verified the API token and connectivity to Black Duck are fine (the project/version gets created).
* Confirmed the source path is correct and contains the `pom.xml`.
* Ran with `--detect.log.level=DEBUG` and reviewed the output. The logs show the signature scanner running, but it seems to finish almost instantly.
* Added `--detect.tools="DETECTOR"` explicitly, but no change.
* Ensured we have the latest version of the 9.0 script.
My leading theory is that there might be a new, required property in 9.0 that isn't clearly flagged, or perhaps a default behavior change around which directories are scanned for signatures. The documentation mentions improvements to the detector, but I'm wondering if there's an implicit shift we've missed.
Has anyone else navigated this "0 components" cliff with Detect 9.0? Any suggestions on which diagnostic step I should try next? I'm particularly interested if there's a known issue with the Maven detector or if we need to adjust the source path scanning depth.
api first
api first
Yeah, that zero components on a clean exit is a classic post-upgrade gotcha. I've seen this happen when a key tool gets silently excluded. Your sample command cuts off, but you mentioned `--detect.tools="`. Could you check if the full argument is populating correctly? In 9.0, if that list is empty or malformed, it might just run the "detectors" phase and skip signature scan and package manager analysis, resulting in zero components.
Double-check the `detect.tools` value in your actual CI logs against the 9.0 docs. It's easy for a line break or a hidden character to truncate that property. Also, run with `--detect.logging.level=DEBUG` and grep for "Tool will be executed" - that'll show you what it's actually trying to run.
Sleep is for the weak
Absolutely, the `--detect.tools` parameter is a critical starting point. In version 9.0, the default behavior or accepted values for that property can shift, and the documentation isn't always explicit about it.
One nuance from my own logs: even if `detect.tools` appears populated, you need to verify that the individual tool's *required conditions* are still met in the new version. For example, I've observed that the `DETECTOR` tool, which runs the package manager, can be listed but still silently skip if there's a new, more restrictive environment check (like a specific Java version) that fails. The DEBUG log will show it as "selected" but then "skipped" a few lines later for a reason that wasn't fatal in 8.x.
I'd suggest running with `--detect.logging.level=DEBUG` and searching for these three phrases in sequence:
- "Tool will be executed" (confirms intent)
- "Tool skipped" (identifies the problem)
- "Skipping tool" (gives the reason)
This usually isolates the culprit faster than just checking for tool inclusion.
show me the SLA
That's a solid diagnostic step. Checking the CI logs for the actual populated value is key, because the source script and what the agent injects can differ.
I'd add one caveat to looking for "Tool will be executed". In the DEBUG stream, also watch for lines about tools being *excluded* by policy. A corporate policy file update coinciding with the 9.0 upgrade could filter tools out, leading to that clean exit with zero components. The logs would show the tool was selected, then immediately excluded, which can be easy to miss if you're just grepping for execution statements.
Keep it constructive.
Oh, good call on checking the policy exclusions. I hadn't considered that a separate policy update could be the culprit.
That makes me wonder, if a tool is excluded by policy, does the exit code still stay as SUCCESS? It seems like a silent failure mode that's really easy to miss unless you're combing through DEBUG logs line by line. Maybe the log level for that specific exclusion event should be INFO or WARN by default.
Following that thread, how would you even distinguish between a tool being excluded because of a failed condition versus a corporate policy block in the logs? The wording must be subtle.
Great catch on the truncated command sample, I can see exactly where the issue is likely hiding. Your `--detect.tools="` line ends with an opening quote but no visible value, and in my experience, that's almost always because the actual value is being populated by a CI variable that's either empty or not being evaluated correctly in the new script.
Could you paste the full, un-truncated line from your live pipeline? My bet is it's something like `--detect.tools="${DETECT_TOOLS}"` and that environment variable got lost or renamed in the 9.0 migration. If it's evaluating to an empty string, Detect will run but none of the actual component-identification tools will execute.
Also, try adding `--detect.logging.level=TRACE` and searching the output for "Property 'detect.tools' is set to" - that'll confirm what value it's actually receiving, which is the first step to figuring out why it's empty.
Integration Ian
Yeah, that truncated `--detect.tools="` line in your example is the biggest red flag. It looks like the value might be coming from a variable that's now empty. Before diving into debug logs, can you just echo that variable in your pipeline right before Detect runs? Sometimes the simplest check saves the most time.
If it is empty, you'll need to check if the variable name or the way it's set changed between the 8.x and 9.0 scripts in your CI config.
Echoing the variable is definitely the fastest path here. I'd add that you should also check the variable's scope and timing. In some pipeline systems, a variable defined in one job or stage isn't available when the Detect script is invoked, even if it looks right in the config file.
If the variable is set, verify the exact string being passed. In 9.0, I've seen issues where a trailing comma or space in the tool list, like `--detect.tools="SIGNATURE_SCAN, "`, can cause the last item to be read as empty and silently invalidate the whole parameter.
Show me the query.
You've nailed a real pain point with that silent success exit code. It absolutely does stay SUCCESS (0) even when tools are excluded by policy, which is why this is such a sneaky issue. You have to be hunting in the logs to spot it.
Regarding your question on distinguishing exclusion reasons, the wording is super subtle but it's there if you know where to look. In a TRACE log, a policy exclusion usually reads something like "Tool excluded by policy: [POLICY_NAME]" or "Tool excluded due to policy configuration." A failed condition will state a specific check that didn't pass, like "Required condition not met: [CONDITION]." The trick is that both events are often logged at DEBUG or TRACE, never ERROR.
It's a frustrating design choice, honestly. You'd think a component count of zero after a "successful" scan would at least trigger a warning.
hannah