Should vulnerabilities for versions with qualifier (e.g. "1.2.3-internal.1") still be flagged?

[felixscheinost]

I'm getting fixes for older versions of Java libraries from a third party provider.

This means instead of having library "1.2.3", I'm using "1.2.3-internal.1".

I noticed that this means that the Gradle plugin will no longer flag issues in "1.2.3".

I'm assuming this is intentional, but is there a way around this?

I would prefer a workflow where I'm double checking that the internal.1 version actually fixed a given CVE and then suppressing it.

Thanks!

[chadlwilson]

it might not be intentional. Would need a reproducer with specific details of dependency, expected vulnerability source, report evidence contents etc to know. it depends whether you expect it to match something from Sonatype Guide or NVD, and the behaviour may differ. For OSSIndex/Guide matching is largely delegated to Sonatype once the version is extracted from a POM/Gradle metadata. For NVD there is a whole bunch of logic to determine a match on ODC's side.

IIRC there is some special handling for "known" version part suffixes such as alpha, beta, RC etc to treat them as "less than", but otherwise I imagine they will be treated as "greater than", and thus "fixed".

Parsing version numbers like ODC needs to do is obviously fundamentally indeterminate across ecosystems, and totally inconsistent, lacking formal specification except sometimes within NVD CPE specifiers.

There is no special purpose flag, but you might be able to do something based on hints file using evidenceMatchers
https://dependency-check.github.io/DependencyCheck/dependency-hint.1.4.xsd - which is the false negative counterpart to false positives. Not sure how you'd write a generic rule though. https://dependency-check.github.io/DependencyCheck/general/hints.html

[felixscheinost]

Thanks for the quick answer!

I began setting up a minimal reproducer and like you suspected the specific vulnerability that disappears with the qualified version is from OSS Index.

I tried adding a hints file but that didn't work for some reason.

Does the OSSIndex API not work on the CPEs?

I tried:

  <hint>
    <given>
      <evidence type="vendor" source="pom" name="groupid" value="ch.qos.logback" confidence="HIGH"/>
      <evidence type="vendor" source="pom" name="artifactid" value="logback-classic" confidence="HIGH"/>
    </given>
    <add>
      <evidence type="version" source="file" name="version" value="1.2.13" confidence="HIGH"/>
      <evidence type="version" source="gradle" name="version" value="1.2.13" confidence="HIGH"/>
      <evidence type="version" source="pom" name="version" value="1.2.13" confidence="HIGH"/>
      <evidence type="version" source="Manifest" name="Bundle-Version" value="1.2.13" confidence="HIGH"/>
    </add>
  </hint>

In the debug logs I can see just:

[org.owasp.dependencycheck.analyzer.OssIndexAnalyzer] Enrich dependency: Dependency{ fileName='logback-core-1.2.13-internal.1.jar', actualFilePath='</modules-2/files-2.1/ch.qos.logback/logback-core/1.2.13-internal.1/8e9caee457398020051c20ef6d998733ade92f65/logback-core-1.2.13-internal.1.jar', filePath='<snip>/modules-2/files-2.1/ch.qos.logback/logback-core/1.2.13-internal.1/8e9caee457398020051c20ef6d998733ade92f65/logback-core-1.2.13-internal.1.jar', packagePath='<snip>/modules-2/files-2.1/ch.qos.logback/logback-core/1.2.13-internal.1/8e9caee457398020051c20ef6d998733ade92f65/logback-core-1.2.13-internal.1.jar'}
[org.owasp.dependencycheck.analyzer.OssIndexAnalyzer]   Package: pkg:maven/ch.qos.logback/logback-core@1.2.13-internal.1 -> HIGH

[chadlwilson]

I can't recall whether the hints apply before the OSSIndexAnalyzer - I guess they should, logically speaking.

Probably need to compare to the as-is evidence before changing anything though. Start from the evidence in an empty report and work backwards. If there is other evidence already at HIGH, you might need HIGHEST level for the version. Not sure what happens if you fake the "source" either, as that's not what the examples do.

And no, OSSIndex has nothing to do with CPEs. No-one uses CPE expressions to specify affected versions except NVD, to my knowledge. Everyone else uses simple "version between" statements and likely proprietary concepts of versions that fall apart as soon as it's not semver, or are ecosystem-specific? (And in Java/maven case there is no universal standard I guess, just approximations of excessive complexity due to the history/age of Maven central)

As is natural, I think PURL and ES/JS ecosystem are trying to reinvent the CPE wheel with VERS specifiers. https://www.packageurl.org/docs/vers/introduction - with dozens of different semantics to implement across ecosystems, including the vague "maven version ranges" and very complex maven sorting scheme at https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification (which is a superset of what I described above as ODC's normal approach).

Anyway, if these are HeroDevs releases (or similar) and you're a paying customer, then they really should provide a way to fix this, so people can scan with more confidence and without such a grind. Ideally they'd publish some open datasets or similar that either act as "vuln feeds" for their artifacts, or confirm patches applied - like the linux distros do when they are backporting patches from upstream to their custom distro builds, and then they'd feed that data to places like Sonatype Guide, GHSA or OSV.dev - or otherwise make it easy to incorporate into tools.

From an ecosystem perspective, reusing the group/artifact (and changing the version) is commonly done, but not really correct (unless the OSS dev is the one supplying a private patched version) because they do not own the logback namespace in Maven Central and thus that version is not an artifact comparable to 1.2.3. Sonatype Guide works off PURLs and PURLs are really for published artifacts into an ecosystem repository.

[felixscheinost]

Anyway, if these are HeroDevs releases (or similar) and you're a paying customer, then they really should provide a way to fix this, so people can scan with more confidence and without such a grind

Yeah its a paid service similar to HeroDevs.

You're right, I'll open a ticket with them and see what they say.

Thank you!

[muhammadmobi]

@felixscheinost, on your follow-up about why the hint had no effect:

Hints do run before OSS Index, but they can't change what OSS Index is asked about:

• Order: HintAnalyzer runs in POST_INFORMATION_COLLECTION2, CPEAnalyzer in IDENTIFIER_ANALYSIS, and OssIndexAnalyzer in FINDING_ANALYSIS_PHASE2, the last of the three (AnalysisPhase.java).
• What OSS Index gets: the request is built only from the dependency's Package-URL identifiers (PurlIdentifier, so pkg:maven/ch.qos.logback/logback-classic@1.2.13-internal.1 here). Evidence isn't read at all (OssIndexAnalyzer.java).
• What a hint can change: only vendor, product and version evidence, added or removed (HintAnalyzer.java). It can't add or rewrite an identifier, so the purl keeps -internal.1, and Sonatype judges that version.

So for findings that come only from OSS Index, a hint can't make ODC treat 1.2.13-internal.1 as 1.2.13. Your added version evidence can still matter on the NVD side, because the CPE analyzer runs after hints. Check in the report whether the CPE for logback-classic now carries 1.2.13. If other version evidence is already at HIGH, try HIGHEST as suggested above. Whether that brings the CVE back depends on NVD having a CPE range for it.

If you want "flag it, verify the fix, then suppress" for OSS Index results too, Sonatype would need to see the upstream version. As far as I can see, ODC has no way to override the purl today, so that would be a feature request, for example letting a hint add or replace a purl identifier.

[felixscheinost]

Thanks!

Yeah I think broadly speaking there are two ways:

1. Like you say configure (e.g. via hints) ODC to "rewrite" the purl into the unqualified one
2. Get OSS Index to give me the result I want with the qualified version.

I think I'll try to pursue 2) both by contacting Sonatype and the vendor that I get the fixed versions from.