dependency-track
dependency-track copied to clipboard
DependencyTrack
Vulnerabilities not detected
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:
- Dependency-Track Version: 4.4.2
- Distribution: Docker
- BOM Format & Version: XML Schema v1.3
- Database Server: PostgreSQL
- Browser: Chrome
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
Can you provide the BOM, or an excerpt of the BOM with only the affected components?
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.
Unfortunately we are not allowed to disclose versions of external libraries used in our product. We are currently investigating the issue by:
- Enabling extended logging --> No clear errors or issues were visible
- Setting up a new instance of D-track and uploading the BOM file there
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.
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.
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.
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/)
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)!
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 ?
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.
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.
Finding similar problems, where our own internal investigation shows that:
- CVE is known in the NVD (CVE-2020-11440)
- CVE is linked to a component in the project (cpe:2.3:o:windriver:vxworks:7.0:-::::::)
- Link is found by our internal tooling which should link to DT and should give similar results.
- Vulnerability is correctly registered in DT (VULNID can be found using CVE)
- Vulnerable-Software is correctly registered in DT (SWID can be found using CPE).
- Vulnerable-Software -> Vulnerability can be found in VULNERABLESOFTWARE_VULNERABILITIES (VULNID,SWID tuple)
- Component can be found.
- Component-> Vulnerability can NOT be found (component_ID,VulnID).
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.
@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.
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.
Idk if its the same problem but i see stuff like this:
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:
I am on version 4.9.1
@gruselglatz Are the projects with missing vulnerabilities marked as inactive? Inactive projects are not part of the daily portfolio-wide vulnerability analysis.
