search

DependencyTrack / dependency-track

Dependency-Track is an intelligent Component Analysis platform that allows organizations to identify and reduce risk in the software supply chain.
https://dependencytrack.org/
Apache License 2.0
2.69k stars 578 forks source link

Vulnerabilities not detected #1546

Open Jonas-vdb opened 2 years ago

Jonas-vdb commented 2 years ago

Current Behavior:

A new Dependency Track project was created (using the jenkins plugin). The BOM file is the same as a another project. The other project shows 22 vulnerabilities (NPM, NVD, OSSIndex) but the newly created version has no vulnerabilities.

The original upload (when the project was also automatically created) happened 20h ago. The analyzer should have done it's analyzing (1) when the BOM was uploaded and (2) every 6h.

I tried manually re-uploading the BOM file but without success. The logs of that attempt can be found below.

Steps to Reproduce:

Not sure what makes my setup reproduce this issue.

Expected Behavior:

The project should show the same amount of vulnerabilities.

Environment:

Additional Details:

2022-04-14 13:20:30,809 INFO [BomUploadProcessingTask] Processing CycloneDX BOM uploaded to project: 1307707d-9ce7-4e64-b4c7-d63e29a50534
2022-04-14 13:20:31,545 INFO [BomUploadProcessingTask] Processing CycloneDX dependency graph for project: 1307707d-9ce7-4e64-b4c7-d63e29a50534
2022-04-14 13:20:31,581 INFO [BomUploadProcessingTask] Processed 18 components and 0 services uploaded to project 1307707d-9ce7-4e64-b4c7-d63e29a50534
2022-04-14 13:20:31,963 INFO [InternalAnalysisTask] Starting internal analysis task
2022-04-14 13:20:32,037 INFO [InternalAnalysisTask] Internal analysis complete
2022-04-14 13:20:32,041 INFO [PolicyEngine] Evaluating 18 component(s) against applicable policies
2022-04-14 13:20:32,144 INFO [PolicyEngine] Policy analysis complete
2022-04-14 13:20:32,146 INFO [MetricsUpdateTask] Executing metrics update for project: 1307707d-9ce7-4e64-b4c7-d63e29a50534
2022-04-14 13:20:32,551 INFO [MetricsUpdateTask] Completed metrics update for project: 1307707d-9ce7-4e64-b4c7-d63e29a50534
stevespringett commented 2 years ago

Can you provide the BOM, or an excerpt of the BOM with only the affected components?

frost9i commented 2 years ago

I'm currently experiencing alike issue. NVD being parsed, but changes aren't getting into database. Component spring-beans must have critical vulnerability, but isn't detected.

Planning to make local backup of tables that store vulnerabilities, and restore them into remote server. image

spring-bom.txt

Jonas-vdb commented 2 years ago

Unfortunately we are not allowed to disclose versions of external libraries used in our product. We are currently investigating the issue by:

It actually looks like none of the projects vulnerabilities are being updated. Could have been since the upgrade from v4.4.1 to v4.4.2 on March 4, 2022.

chergik commented 2 years ago

We are having the same issue and are on the version 4.2.0.

Jonas-vdb commented 2 years ago

We ended up setting up a new instance and manually exporting and importing the versions, the BOM files and the audit trails.

We think it started failing when we switched from PostgreSQL v13 to v14. We did a dump of the data and imported it in a new v14 DB. No errors or warnings were shown at the time but we suspect it was related to that. The move was done months ago but the issue was not seen. We assumed no new vulnerabilities were being reported.

hostalp commented 2 years ago

Well we're having this issue running DT 4.3.6 @ PostgreSQL 12, so it shouldn't be related to the DB server version. However it may be related to the database schema and its state.

heidricha commented 2 years ago

A similar thimg happens for us

f.e. libexpat1 ▸ 2.2.10-2+deb11u3 is identified as a component of the OpenJDK:11 docker image CVE-2021-45960 is listed in the vulnerabilities

but CVE-2021-45960 is not enlisted as a vulnerability for the image above

dep-track is 4.4.2, DB is h2 sbom format is CycloneDX 1.4, by docker sbom (https://docs.docker.com/engine/sbom/)

heidricha commented 2 years ago

I have found a few things, maybe interesting for others too.

Although a vulnerability affects versions of an application, usually linux distribution maintainers apply security patches for the affected version. This way the actual package is not considered to be affected, although it has a version that would imply this.

In my example f.e. Debian already released the security patch, so the Debian package for libexpat1 is not vulnerable anymore, despite the actual expat version number.

There's a whole article about this (I guess there are more, but there's one): https://www.redhat.com/en/blog/determining-your-risk

looks like dependency-track does the right thing to identify the threat (or its absence)!

lislei commented 2 years ago

Hey folks, we're facing the same issue. Previous working setup was 3.8 with PostgreSQL 13.0.

We're experiencing this on our production setup after migrating to the newest version (currently 4.5 / PostgreSQL 14.2).

Migration steps:

pg_dump -U dtrack dtrack > dtrack_export.pgsql
psql -U dtrack dtrack < dtrack_export.pgsql
psql -U dtrack dtrack < 3.8.0_to_4.0.0_postgres.sql

Is there perhaps something missing in 3.8.0_to_4.0.0_postgres.sql ?

lislei commented 2 years ago

I have tried updating the plugin in our build system effectively bumping the SBOM format from 1.3 to 1.4 without any success. The dependencies are picked by DT, and the number of dependencies are the exactly the same as before. Difference is the vulnerabilities not being added.

lislei commented 2 years ago

We resolved this issue today. The solution was to re-enter the API token for the Sonatype OSS service.

After auditing the backend server logs this clue presented itself:

2022-06-26 22:45:19,008 ERROR [OssIndexAnalysisTask] An error occurred decrypting the OSS Index API Token. Skipping
javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
mveck commented 2 years ago

Finding similar problems, where our own internal investigation shows that:

I would expect that the analysis would automatically populate the last table based on the information which is available, but it shows that the last step (linking component to the vulnerability) has some hickups...

In our project this results in 600+ vulnerabilities not mapped by DT in multiple projects, but these vulnerabilities are found in the NVD.

syalioune commented 1 year ago

@mveck There was an issue (c.f #2240) preventing component with CPE having a N/A update value (like cpe:2.3:windriver:vxworks:7.0:-::::::) being correctly matched against VULNERABLE_SOFTWARE. It is now fixed in v4.7. That can maybe solve your issue.

nigellh commented 1 year ago

Check that none of the packages have a blank name in the SBOM.

"name": "",

It will import the SBOM up until that point and then stop and no vulnerabilities are generated for any that have been imported up to then.

Some packages have a blank in the repo name and so tooling that is looking for packages return an empty field. If the SBOM is created from that and there are several thousand packages, can be a little tricky to find, but the DT logs clearly show it.

DT should probably have a fix to reject it, but continue processing.

gruselglatz commented 12 months ago

Idk if its the same problem but i see stuff like this: image

Is this the desired behavior for old projects, that they don't get updated? When i click "rescan" in the vuln tab, the dep gets the new vulns. I don't see any suspicious logs, or errors. My tasks look like this: image

I am on version 4.9.1

nscuro commented 12 months ago

@gruselglatz Are the projects with missing vulnerabilities marked as inactive? Inactive projects are not part of the daily portfolio-wide vulnerability analysis.

gruselglatz commented 12 months ago

@nscuro nope, all active.