Troubles understanding origins of references

[philcrash98]

I'm working on incorporating this tool into our CI/CD pipeline, utilizing Dependency Track to identify vulnerabilities. Within my project, Dependency Track has detected a vulnerable library, such as System.Drawing.Common, with multiple versions. I'm trying to address these vulnerabilities and having problems in locating all the versions in my code. On some versions there is no trace of its existence in the code. Additionally, the versions of the library that I cannot validate lack any information in the dependency tree.
However, this tool finds these references, and I don't understand how. Has anyone else encountered a similar situation?

[mtsfoni]

Hey,

With the limited information available, I can only assume that this version of System.Drawing.Common is a transitive dependency of a package you use. If you encounter multiple versions of the same assembly, another way to use this tool might be helpful. Here's a brief summary:

How and what dependencies are found by the tool depends heavily on your CLI arguments.

The recommended approach is to call the tool with the .csproj file, which is the root of the software you plan to deliver. This could be a simple .exe file or an ASP.NET project.

If your project uses package references in the project file (as opposed to the packages.config file), the tool can read all information from the project.assets file of that specific project. The generated bill of materials (BOM) is expected to have high accuracy and completeness.
In this case, the recursive-scan argument is not necessary.

If the project uses packages.config files, these are used to build the SBOM. The recursive-scan option is required to find all transitive dependencies. The results from the found projects are aggregated, which can lead to lower accuracy and might include packages that are not actually used but referenced by a child project.

The other method is to use the tool on the entire solution. This method scans each project's assets-file or packages.config, reads all their components, and then simply aggregates them into one BOM. In my opinion, this is a quick way to scan your solution if it's very lightweight and doesn't need aggregation, like a solution for a NuGet package.