CVE-2020-5408 incorrectly reported by dependency-check

[bjansen]

Vulnerability URL

https://ossindex.sonatype.org/vulnerability/CVE-2020-5408?component-type=maven&component-name=org.springframework.security%2Fspring-security-crypto&utm_source=dependency-check&utm_medium=integration&utm_content=7.0.0

Component URL

https://ossindex.sonatype.org/component/pkg:maven/org.springframework.security/spring-security-crypto

Description Today the dependency-check Maven plugin started reporting the following vunerability:

[ERROR] One or more dependencies were identified with vulnerabilities: 
[ERROR] 
[ERROR] spring-security-crypto-5.6.5.jar: CVE-2020-5408(6.5)

Spring Security 5.6.x should not be affected by this CVE.

The generated HTML reports indicates that the vulnerability is coming from the "OSSINDEX" database:

The corresponding entry in the NVD hasn't been updated since 2021, so this seems to confirm that the source of the problem could be OSSIndex.

[bjansen]

The REST API at https://ossindex.sonatype.org/rest reports the same (incorrect) CVE for the coordinates pkg:maven/org.springframework.security/spring-security-crypto@5.6.5

[ken-duck]

Sorry for the delay, we are working on setting up the appropriate processes now that we have upgraded OSS Index.

In Sonatype's opinion, this vulnerability has not been fixed. From the Security Researchers:

The Sonatype security research team discovered that this issue is not yet fixed as new versions simply @Deprecated the vulnerable method, as mentioned in the advisory as opposed to replacing it with a safe alternative. Therefore, these are still flagged as vulnerable.

[fransf-wtax]

Does this mean the description and the vulnerable versions listed on the CVE-2020-5408 NVD entry should actually be updated? The NIST NVD entry only mentions Spring Security versions up to 5.3.x, which makes it confusing that newer versions are being flagged as vulnerable. Would we need to contact NIST about this?

[ken-duck]

It depends on various groups definitions of "vulnerable". At Sonatype we make that decision based on the "perceived risk." Technically, there is documentation about the vulnerable methods and they are marked as @Deprecated, which some might deem as sufficient.

At Sonatype the researchers decided that there was still too much risk that those packages' vulnerable methods would still be used, often unknowingly through transitive includes, and it is therefore better to call them out.

Trying to get various groups to agree on whether something is a vulnerability or not is tricky. The researchers who communicated the issue to NIST obviously felt that enough was done.

I cannot say what the appropriate next steps would be with regard to the data at NIST, and do not know how one would go about getting data changed (and whether that would cause a furor if our definition of risk is different from their definition of vulnerable.

[msymons]

@ken-duck , methinks that this change is a step in the right direction...

Changes Coming to CVE Record Format JSON and CVE List Content Downloads.

Note the bit about "ability for community contributions, etc". That might help address your last concern (getting data changed).

[ken-duck]

Very interesting. Thanks for the information. I will pass it on to our research team.

[ken-duck]

For the record, OSS Index was updated some time ago to provide deviation notices when we diverge from NVD. Not every issue has been updated with this information at this time, but this one has been.

https://ossindex.sonatype.org/vulnerability/CVE-2020-5408?component-type=maven&component-name=org.springframework.security%2Fspring-security-crypto&utm_source=dependency-check&utm_medium=integration&utm_content=7.0.0

This being the case, I am closing this issue at this point.

For the record, we are migrating to a new email-based reporting system in order to better mesh with our internal processes, which will allow us to be more reactive to our users.

As such, if you notice further issues or would like to follow up on this one, please email ossindex@sonatype.org