TPL is not reported as vulnerable

[shriharikalessnc]

Precondition

• [Scan package should contain Azure.Identity.dll with file version 1.700.22.46903 and product version 1.7] I checked the issues list for existing open or closed reports of the same problem.

Describe the bug
Azure.Identity.dll@1.7.0 is not reported as vulnerable and package name is taken as pkg:generic/Azure.Identity@1.700.22.46903. Ideally it should report it as vulnerable.

Version of dependency-check used
The problem occurs using version 12.1.9 of the cli (cli, gradle plugin, maven plugin, etc.)

Expected behavior
Azure.Identity.dll@1.7.0 should report as vulnerable

[chadlwilson]

Can you please

• give more specific instructions on how to replicate your problem
• share specifically why you think it should be vulnerable - which CVEs or other entries are you expecting to be reported? Be specific please.
• share the html report details that show what ODC detected for this library (please also expand the 'evidence' section

[shriharikalessnc]

Steps to replicate:

1. checked attached zip with Azure.Identity.dll.
   2.download cli version 12.1.9
   3 extract attached zip and scan it with cli - ".\bin\dependency-check.bat --format JSON --out $ReportFileName --scan $scan --ossIndexUsername $ossIndexUsername --ossIndexPassword $ossIndexPassword --nvdDatafeed $nvdDatafeed --nvdApiKey $nvdApiKey"

$scan - provide path of attached scan folder. 4. check attached generated report Folder_2025-11-19T174106.json, Azure.Identity@1.7.0 is not reported as vulnerable.

Folder_2025-11-19T174106.json
ScanFolder.zip

The said package Azure.Identity@1.7.0 have three CVEs - ref - https://ossindex.sonatype.org/component/pkg:nuget/Azure.Identity@1.7.0
CVE-2023-36414, CVE-2024-35255, CVE-2024-29992
Hence it should be reported as vulnerable.

Hope provided steps are clear and issue is explained properly now.

[chadlwilson]

Thanks!

I'm guessing for some reason the tool is using/seeing the File Version rather than the Product Version (1.7.0+3627e3cbc75c628f659d033ed9270c9d02ab9038) from the metadata. I'm not familiar with the tool and haven't replicated yet, but GrokAssembly seems to support getting that, and the ProductVersion is normally preferred to the FileVersion, so something funny must be going on.

[chadlwilson]

The primary culprit is the logic at

DependencyCheck/core/src/main/java/org/owasp/dependencycheck/analyzer/AssemblyAnalyzer.java

Lines 255 to 271 in 6008202

	if (dependency.getVersion() == null) {
	if (data.getFileVersion() != null && data.getProductVersion() != null
	&& data.getFileVersion().length() >= data.getProductVersion().length()) {
	if (fileVersion != null && fileVersion.toString().length() == data.getFileVersion().length()) {
	dependency.setVersion(fileVersion.toString());
	} else if (productVersion != null && productVersion.toString().length() == data.getProductVersion().length()) {
	dependency.setVersion(productVersion.toString());
	}
	} else {
	if (productVersion != null && productVersion.toString().length() == data.getProductVersion().length()) {
	dependency.setVersion(productVersion.toString());
	} else if (fileVersion != null && fileVersion.toString().length() == data.getFileVersion().length()) {
	dependency.setVersion(fileVersion.toString());
	}
	}
	}
	}

with secondary blame to the version parser at

DependencyCheck/core/src/main/java/org/owasp/dependencycheck/utils/DependencyVersionUtil.java

Lines 39 to 41 in 7ac5059

	private static final Pattern RX_VERSION = Pattern.compile(
	"\\d+(\\.\\d+){1,6}([._-]?(snapshot|release|final|alpha|beta|rc$|[a-zA-Z]{1,3}[_-]?\\d{1,8}|[a-z]\\b|\\d{1,8}\\b))?",
	Pattern.CASE_INSENSITIVE);

The top logic causes the the fileVersion to be chosen in favour of the productVersion simply due to it being "longer" after parsing.

This happens because the the version parser basically only treats . as a relevant separator, so the +gitsha is discarded:

DependencyCheck/core/src/main/java/org/owasp/dependencycheck/analyzer/AssemblyAnalyzer.java

Lines 242 to 243 in 6008202

	final DependencyVersion fileVersion = DependencyVersionUtil.parseVersion(data.getFileVersion(), true);
	final DependencyVersion productVersion = DependencyVersionUtil.parseVersion(data.getProductVersion(), true);

So

parsedFileVersion = "1.700.22.46903"
parsedProductVersion = "1.7.0"

"1.700.22.46903".length() > "1.7.0".length()

Due to this length comparison logic, it distrusts the entire ProductVersion when determining the canonical dependency version identifier (which ends up in the report and used for matching vulns/CPEs).

I am not sure using the string length is a valid way to determine which of these to trust, even though the ProductVersion has HIGHEST confidence and FileVersion is HIGH prior to this logic, but I infer the assumption is that the FileVersion should just be a more specific variant of the ProductVersion, and if it's longer it should be more trusted/useful as it is more specific.

Unfortunately this does not hold true in this DLL's case though; the FileVersion is the wrong thing to trust. The 1.7.0 is encapsulated in the file version as 1.700 with an ordinal as the second part.

As a (perhaps) secondary issue, later the DependencyFilterAnalyzer throws away the evidence from the non-canonical version which is why it is gone from the report entirely.

DependencyCheck/core/src/main/java/org/owasp/dependencycheck/analyzer/VersionFilterAnalyzer.java

Lines 134 to 140 in 19dd71b

	protected void analyzeDependency(Dependency dependency, Engine engine) throws AnalysisException {
	final Set<Evidence> remove;
	if (dependency.getVersion() != null) {
	remove = dependency.getEvidence(EvidenceType.VERSION).stream()
	.filter(e -> !e.isFromHint() && !dependency.getVersion().equals(e.getValue()))
	.collect(Collectors.toSet());

I'm not quite sure how to proceed here; perhaps @jeremylong has some ideas.

[chadlwilson]

GrokAssembly output for testing:

<?xml version="1.0" encoding="utf-8"?>
<assembly>
    <companyName>Microsoft Corporation</companyName>
    <productName>Azure .NET SDK</productName>
    <productVersion>1.7.0+3627e3cbc75c628f659d033ed9270c9d02ab9038</productVersion>
    <comments>This is the implementation of the Azure SDK Client Library for Azure Identity</comments>
    <fileDescription>Microsoft Azure.Identity Component</fileDescription>
    <fileName>C:\Users\chad\Downloads\ScanFolder\Azure.Identity.dll</fileName>
    <fileVersion>1.700.22.46903</fileVersion>
    <internalName>Azure.Identity.dll</internalName>
    <legalCopyright>┬® Microsoft Corporation. All rights reserved.</legalCopyright>
    <originalFilename>Azure.Identity.dll</originalFilename>
    <fullName>Azure.Identity, Version=1.7.0.0, Culture=neutral, PublicKeyToken=92742159e12e44c8</fullName>
    <namespaces>
        <namespace>Microsoft.CodeAnalysis</namespace>
        <namespace>System.Runtime.CompilerServices</namespace>
        <namespace>Azure.Core</namespace>
        <namespace>Azure.Core.Pipeline</namespace>
        <namespace>Azure.Core.Diagnostics</namespace>
        <namespace>Azure.Identitiy</namespace>
        <namespace>Azure.Identity</namespace>
    </namespaces>
</assembly>

[jeremylong]

The length comparison is definitely not right. Likely need to rework the logic on this (obviously). We may want to also grab the version from the full name to complicate things a bit. But I'm thinking if we have multiple does one start with another to get agreement from the multiple versions listed? If I get some time over the weekend, I may try and come up with a better heuristic for dotnet.

[chadlwilson]

There is a sort of prefix check earlier in the logic but it seems to basically see if the two parsed versions agree on the first three parts, and treat that as the magic number if so. In this case they only agree on two parts so it moves on to the length check.

I see similar code elsewhere such as the PEAnalyzer - looks copied. But I couldnt find tests that would help me understand the methodology and intention. Probably need to find the "original".

[shriharikalessnc]

One more weird observation for package log4net@1.2.10.0. it is also reported as not vulnerable however it has 1 critical vulnerability -
https://ossindex.sonatype.org/component/pkg:nuget/log4net@1.2.10
CVE - CVE-2018-1285

Something is changed in recent version of dependency check because earlier it was reported correctly.

[chadlwilson]

Sometimes these things can change due to metadata and heuristics, but that one seems pretty clear cut.

Is 1.2.10.0 the correct version for the log4net DLL that you're scanning?

Do you recall which ODC version you last saw it reported correctly with and whether it was ossindex or NVD (or perhaps both) that was reporting it?

[shriharikalessnc]

Yes, 1.2.10.0 is correct file version. and product version is 1.2.

I did not recall ODC version however it was reporting by NVD.