Fix: Correct direct vs transitive dependency classification in Cargo Lockfile Detector #1461

zahidblackduck · 2025-07-03T04:58:51Z

JIRA Ticket

IDETECT-4746

Description

This merge request fixes a bug in the Cargo Lockfile Detector where transitive dependencies were incorrectly identified as direct dependencies in the generated BOM.
This change ensures that only dependencies explicitly declared in Cargo.toml are marked as direct. All others are accurately classified as transitive.

Implementation Details

The CargoExtractor has been updated to:
- Parse direct dependencies from Cargo.toml
- Resolve root dependencies separately before performing DFS to collect transitives
- If Cargo.toml is not found, falls back to the previous implementation
The transformToGraph(...) method in CargoLockPackageTransformer now:
- Accepts a Set<NameVersion> of root dependencies
- Adds only those as root nodes in the dependency graph
- Correctly links transitive dependencies as children

Impact

Ensures BOMs generated via the Cargo Lockfile Detector reflect accurate dependency relationships
Reduces false positives where transitive packages were mistakenly marked as direct
Improves reliability of policy evaluation and SBOM auditing in Rust projects scanned without the Cargo CLI

N.B: This merge request is meant for detect release 10.7

… transformer

Copilot

Pull Request Overview

This PR fixes the classification of direct vs. transitive dependencies in the Cargo Lockfile Detector’s BOM by tracking only those declared in Cargo.toml as roots.

The transformer now takes an explicit rootDependencies set and only marks those as root nodes.
The extractor collects direct dependencies from Cargo.toml, resolves versions of unnamed deps, and passes the roots through to the transformer.
Tests were updated to call the new two-argument transformToGraph and supply the expected root set.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
detectable/src/test/java/.../CargoLockPackageTransformerTest.java	Updated imports and replaced single-arg `transformToGraph` calls with two-arg version, supplying roots.
detectable/src/main/java/.../CargoLockPackageTransformer.java	Changed `transformToGraph` signature to accept a `Set<NameVersion>` of roots and adjust root-node logic.
detectable/src/main/java/.../CargoTomlParser.java	Added a null-check around the dependency-type filter to include all when filter is `null`.
detectable/src/main/java/.../CargoExtractor.java	Gathered `resolvedRootDependencies`, resolved missing versions, and passed roots into the transformer.

Comments suppressed due to low confidence (3)

detectable/src/main/java/com/blackduck/integration/detectable/detectables/cargo/CargoExtractor.java:119

[nitpick] The parameter resolvedRootDependenciesOut is not immediately clear. Rename it to something like rootDependenciesSink or simply rootDependencies to improve readability.

    private void processTransitiveDependenciesForInclusion(

detectable/src/test/java/com/blackduck/integration/detectable/detectables/cargo/transform/CargoLockPackageTransformerTest.java:34

Add a test where rootDependencies is empty to verify the fallback behavior (all lockfile packages become roots) matches the previous one-argument logic.

        Set<NameVersion> rootDependencies = new HashSet<>();

detectable/src/main/java/com/blackduck/integration/detectable/detectables/cargo/transform/CargoLockPackageTransformer.java:38

Avoid creating a new NameVersion object on each iteration for the contains check. Consider precomputing a map of (name, version) keys or using a canonical identifier to reduce object churn.

            if (rootDependencies.isEmpty() || rootDependencies.contains(new NameVersion(name, version))) {

… into dev/zahidblackduck/IDETECT-4746

…ETECT-4746-SNAPSHOT

...ble/src/main/java/com/blackduck/integration/detectable/detectables/cargo/CargoExtractor.java

shantyk · 2025-07-29T13:32:49Z

...duck/integration/detectable/detectables/cargo/transform/CargoLockPackageTransformerTest.java

        CargoLockPackageTransformer cargoLockPackageTransformer = new CargoLockPackageTransformer();

-        assertThrows(DetectableException.class, () -> cargoLockPackageTransformer.transformToGraph(input));
+        assertThrows(DetectableException.class, () -> cargoLockPackageTransformer.transformToGraph(input, rootDependencies));


I know the method that returns an exception here, verifyNoDuplicatePackages(), is not modified in the PR but I wanted to understand it better. Since Cargo allows multiple versions of the same crate (unlike many other pkg mgrs), what is the purpose of that method? There may be a disconnect between my understanding of a unique crate name/version versus a CargoLockPackage definition. Thanks in advance for your explanation!

The verifyNoDuplicatePackages() in the CargoLockPackageTransformer class ensures that when a dependency is listed in Cargo.lock without a version (e.g., "bitflags"), there should only be one resolved version of that package in the Cargo.lock file. This is based on the assumption that unversioned entries indicate unambiguous resolution.

For example, this entry in a Cargo.lock package:

[[package]] name = "libredox" version = "0.1.3" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "c0ff37bd590ca25063e35af745c343cb7a0271906fb7b37e4813e8f79f00268d" dependencies = [ "bitflags", "libc", ]

This implies that only one version of bitflags exists in the lock file:

[[package]] name = "bitflags" version = "2.9.0"

If, however, there are multiple versions of bitflags present:

[[package]] name = "bitflags" version = "2.8.0" [[package]] name = "bitflags" version = "2.9.0"

Then the lookup becomes ambiguous, since "bitflags" without a version doesn't specify which one to use. In such cases, verifyNoDuplicatePackages() fails deliberately to avoid incorrect resolution.

You can see a valid case in https://github.com/casey/just, where "bitflags" is listed without a version, because only one version is present in the lockfile.

Looks like that code has been that way for a while but this discussion does make me curious whether the example of bitflags with multiple versions is indeed invalid (impossible?) or if it should be handled differently. Maybe we can get more into this next time we chat.

shantyk · 2025-07-29T13:38:42Z

Please add release note entry

andrian-sevastyanov · 2025-07-29T16:50:05Z

...ble/src/main/java/com/blackduck/integration/detectable/detectables/cargo/CargoExtractor.java

@@ -53,6 +54,9 @@ public Extraction extract(File cargoLockFile, @Nullable File cargoTomlFile, Carg
        List<CargoLockPackageData> filteredPackages = cargoLockPackageDataList;
        boolean exclusionEnabled = isDependencyExclusionEnabled(cargoDetectableOptions);
        String cargoTomlContents = null;
+        Set<NameVersion> dependenciesToInclude;


It might be better to declare this where it's initialized. This saves a line of code and also reduces the likelihood of someone trying to use a null value.

andrian-sevastyanov · 2025-07-29T17:04:57Z

...java/com/blackduck/integration/detectable/detectables/maven/unit/MavenComplexOutputTest.java

Mostly curious: what led you to make these changes in a maven test?

I switched from List.of(..) to Arrays.asList(..) because the project targets Java 8 in build.gradle, and List.of(..) is only available from Java 9 onward, thus causing a cannot find symbol error when running tests in IntelliJ. Also, since we wrap the result in new ArrayList<>(...), the immutability benefit of List.of(..) is lost anyway, so using Arrays.asList(..) doesn't change the actual behavior of the test.
I'm not sure though whether we should go with the change. If we are against this, I can revert the change.

andrian-sevastyanov · 2025-07-29T20:45:56Z

...ble/src/main/java/com/blackduck/integration/detectable/detectables/cargo/CargoExtractor.java

@@ -53,6 +54,9 @@ public Extraction extract(File cargoLockFile, @Nullable File cargoTomlFile, Carg
        List<CargoLockPackageData> filteredPackages = cargoLockPackageDataList;
        boolean exclusionEnabled = isDependencyExclusionEnabled(cargoDetectableOptions);
        String cargoTomlContents = null;
+        Set<NameVersion> dependenciesToInclude;
+        Set<NameVersion> resolvedRootDependencies = new HashSet<>();
+        Map<String, List<CargoLockPackageData>> packageLookupMap = indexPackagesByName(filteredPackages);


It seems like now in this class we're calling indexPackagesByName() for the same list of packages more than once. Let's try to avoid this.

You are right. We can surely avoid multiple calls to the method by passing around the map wherever needed. Will update accordingly.

…IDETECT-4746

cpottsbd · 2025-07-31T13:52:53Z

documentation/src/main/markdown/currentreleasenotes.md

@@ -30,7 +30,7 @@

 ### Resolved issues

-* 
+* (IDETECT-4746) – Fixed incorrect labeling of transitive dependencies as direct in the Cargo Lockfile Detector.


Nit - from: "... in the Cargo Lockfile Detector." to "... by the Cargo Lockfile Detector."

cpottsbd · 2025-08-01T15:39:35Z

documentation/src/main/markdown/currentreleasenotes.md

@@ -30,7 +30,7 @@

 ### Resolved issues

-* 
+* (IDETECT-4746) – Fixed incorrect labeling of transitive dependencies as direct by the Cargo Lockfile Detector.


My apologies for the delay, when I read the line back over I thought of this rewording idea:

(IDETECT-4746) – Fixed Cargo Lockfile Detector incorrectly labeling transitive dependencies as direct dependencies.

zahidblackduck added 3 commits July 1, 2025 20:47

cargo lockfile detector transitive dependency incorrect flag fix

02153f2

exclusion strategy fix to correctly flag directs & transitives

267cc29

update lookup map for dependencies

20c49bd

zahidblackduck self-assigned this Jul 3, 2025

zahidblackduck marked this pull request as draft July 3, 2025 04:59

zahidblackduck changed the title Fix: Correct direct vs transitive dependency classification in Cargo Lockfile Detector**JIRA Ticket** Fix: Correct direct vs transitive dependency classification in Cargo Lockfile Detector Jul 3, 2025

zahidblackduck added 4 commits July 3, 2025 15:39

failed tests refactor to accommodate the change in cargo lock package…

428eeb7

… transformer

remove wildcard imports

9243092

wildcard imports cleanup

2e1cace

maven output test change revoke

449ca10

zahidblackduck requested review from Copilot, andrian-sevastyanov, dterrybd, shantyk and devmehtabd July 3, 2025 10:08

This comment was marked as outdated.

Sign in to view

zahidblackduck marked this pull request as ready for review July 3, 2025 10:14

zahidblackduck requested a review from Copilot July 3, 2025 10:15

This comment was marked as outdated.

Sign in to view

cargo lock package transformer test issue fix

f0c195a

zahidblackduck requested a review from Copilot July 4, 2025 17:01

Copilot AI reviewed Jul 4, 2025

View reviewed changes

zahidblackduck marked this pull request as draft July 4, 2025 17:04

blackduck-serv-builder and others added 7 commits July 16, 2025 08:30

Release 10.6.0-SIGQA7-zahidblackduck.IDETECT-4746

83aece9

Release 10.6.0-SIGQA8-zahidblackduck.IDETECT-4746

266a2a1

fix test failure, update cargo functional test

8ca4db8

Merge remote-tracking branch 'origin/dev/zahidblackduck/IDETECT-4746'…

f3c301e

… into dev/zahidblackduck/IDETECT-4746

Release 10.6.0-SIGQA9-zahidblackduck.IDETECT-4746

f0e927d

Using the next snapshot post release 10.6.0-SIGQA10-zahidblackduck.ID…

9ce2d55

…ETECT-4746-SNAPSHOT

Merge conflict resolve with master

57f99af

fix incorrect indentation

16e1793

shantyk reviewed Jul 29, 2025

View reviewed changes

...ble/src/main/java/com/blackduck/integration/detectable/detectables/cargo/CargoExtractor.java Outdated Show resolved Hide resolved

shantyk reviewed Jul 29, 2025

View reviewed changes

andrian-sevastyanov reviewed Jul 29, 2025

View reviewed changes

zahidblackduck added 3 commits July 31, 2025 12:25

refactor cargo extractor as per review

b773510

update current release note for the issue

f5efeac

Merge remote-tracking branch 'origin/master' into dev/zahidblackduck/…

0dda4fb

…IDETECT-4746

zahidblackduck requested review from shantyk, andrian-sevastyanov and cpottsbd July 31, 2025 06:43

zahidblackduck marked this pull request as ready for review July 31, 2025 10:04

cpottsbd reviewed Jul 31, 2025

View reviewed changes

update release note entry as per review

cc262b3

zahidblackduck requested a review from cpottsbd July 31, 2025 14:56

andrian-sevastyanov approved these changes Jul 31, 2025

View reviewed changes

cpottsbd reviewed Aug 1, 2025

View reviewed changes

zahidblackduck added 2 commits August 1, 2025 23:13

Merge conflict resolve with master

17bb613

remove hyphen from release note entry, update entry line

6b52992

cpottsbd approved these changes Aug 1, 2025

View reviewed changes

shantyk approved these changes Aug 7, 2025

View reviewed changes

merge conflict resolve with master

5c67d8d

zahidblackduck merged commit 8da9c5d into master Aug 8, 2025

zahidblackduck deleted the dev/zahidblackduck/IDETECT-4746 branch August 29, 2025 18:40

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix: Correct direct vs transitive dependency classification in Cargo Lockfile Detector #1461

Fix: Correct direct vs transitive dependency classification in Cargo Lockfile Detector #1461

Uh oh!

zahidblackduck commented Jul 3, 2025 •

edited

Loading

Uh oh!

This comment was marked as outdated.

Uh oh!

This comment was marked as outdated.

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

shantyk Jul 29, 2025

Uh oh!

zahidblackduck Jul 31, 2025 •

edited

Loading

Uh oh!

andrian-sevastyanov Jul 31, 2025

Uh oh!

shantyk commented Jul 29, 2025 •

edited by zahidblackduck

Loading

Uh oh!

andrian-sevastyanov Jul 29, 2025

Uh oh!

andrian-sevastyanov Jul 29, 2025

Uh oh!

zahidblackduck Jul 31, 2025

Uh oh!

andrian-sevastyanov Jul 29, 2025

Uh oh!

zahidblackduck Jul 31, 2025

Uh oh!

cpottsbd Jul 31, 2025

Uh oh!

cpottsbd Aug 1, 2025

Uh oh!

Uh oh!

Fix: Correct direct vs transitive dependency classification in Cargo Lockfile Detector #1461

Fix: Correct direct vs transitive dependency classification in Cargo Lockfile Detector #1461

Uh oh!

Conversation

zahidblackduck commented Jul 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as outdated.

Uh oh!

This comment was marked as outdated.

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zahidblackduck Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shantyk commented Jul 29, 2025 • edited by zahidblackduck Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

zahidblackduck commented Jul 3, 2025 •

edited

Loading

zahidblackduck Jul 31, 2025 •

edited

Loading

shantyk commented Jul 29, 2025 •

edited by zahidblackduck

Loading