Same component is risk scored differently in different instances of a project

[scooby359]

Current Behavior

I set up Dependency Track a couple of months ago and created and created all our projects using the API and auto-project creation. All went well, components seemed to be imported and scanned and risk scores were applied.

I've now had to recreate the projects due to changing names, so I archived the old projects, and imported the BOMs again using the API autocreation, just with new project names. Components have been imported and scanned, but this time round, the risk scores are lower for many components, even though they're the same components and same versions. I can't see an explanation why the components have scored a lower risk score on the second instance of a project.

We've seen this occur across several projects and components, though just shown one below as an example.

Suspected it may be related to https://github.com/DependencyTrack/dependency-track/issues/2519, but that relates to imports to a single project. In this case, it's a separate project.

Initial project, showing EJS v3.1.9 as a risk score of 10

Second project, showing EJS v3.1.9 as a risk score of 0

Steps to Reproduce

1. Use the Dependency Track API to import a BOM file and auto-create a project on the given name.
2. Allow scanning to happen and observe the output risk scores.
3. Archive the project.
4. Use the Dependency Tack API to import the BOM file with auto-create a project, using a different project name.
5. Allow scanning to happen and observe the output risk scores are lower than the initial project.

Expected Behavior

Expect that for a given component at a specific version, the risk score would be the same across any project.

Dependency-Track Version

4.8.2

Dependency-Track Distribution

Container Image

Database Server

Microsoft SQL Server

Database Server Version

12.0.2000.8

Browser

N/A

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this defect was already reported

[valentijnscholten]

Do both have the exact same purl/cpe for the ejs component?

[poschi3]

We have the same issue and I can confirm that the purl is the same (cpe is empty). We're using Dependency-Track v4.8.2

jackson-core with problem:

jackson-core without problem:

[nscuro]

Note how in both cases shown here, the component had a vulnerability assigned to it previously, but does not have it anymore. If there's a difference in vulnerabilities identified, there will of course be a difference in the risk score.

Can you please verify whether the now-missing vulnerability is legit, or whether it was a false positive that has potentially been resolved in OSS Index in the meantime?

[poschi3]

I'm not sure if I understand you correct. In the case with problems (first image) there is one vulnerability. In the second case there are no vulnerabilities.

This is the vulnerability in case with problems: OSSINDEX sonatype-2022-6438 CWE-400

If I click on the name I get this information:

The link on the bottom in References is https://ossindex.sonatype.org/vulnerability/sonatype-2022-6438?component-type=maven&component-name=com.fasterxml.jackson.core%2Fjackson-core&utm_source=dependency-track&utm_medium=integration&utm_content=v4.6.3 and leads me to 404 error page.

[scooby359]

For my example, in this case I have Snowflake.Data package in the first and second instances of a project.

In the first Snowflake.Data has a known vulnerability and a risk score of 5, in the second instance, there's no recorded vulnerability and a risk score of 0.

In both cases, the Package URL (PURL) is the same.

The first instance has a known vulnerability attached, the second instance has no vulnerability attached.

The known vulnerability links to a Github Security Issue which indicates the vulnerability affects Snowflake.Data < 2.0.18, so version 2.0.7 used in both the first and second instance of the Dependency Track projects should be flagging this as a vulnerability.

[nscuro]

@poschi3 Seems like you fell victim to Sonatype discontinuing their exposure of sonatype-* vulnerabilities. There was a time frame in which OSS Index would utilize Sonatype's proprietary vulnerability database to report vulns for which no CVE exists. This is no longer the case, so you won't see such vulns anymore.

@scooby359 I am unable to reproduce. I added the component you showed, and the CVE is correctly reported by OSS Index, and additionally by GitHub when the GitHub integration is enabled:

Perhaps clicking the Reanalyze button resolves this? If not, please check your API server logs for any errors.

[scooby359]

@nscuro Tried reanalysing and found an error message in the logs, appears the Sonatype OSS API Key had become corrupted. I've reset that and re-run vulnerability analysis and issues are now being found again.

Issue can be closed as solved, thanks.

[savek-cc]

@scooby359 I think you can close the issue yourself as author? In general, some cleanup might be in order with currently more than 500 "open" issues?

[scooby359]

Closed resolved as per comments

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.