DependencyTrack
Negative Number Of Unaudited Findings
Current Behavior
Audited findings show negative value on dashboard
Steps to Reproduce
Not actually sure...
Expected Behavior
Lowest value for unaudited should be 0
Dependency-Track Version
4.12.x
Dependency-Track Distribution
Container Image
Database Server
Microsoft SQL Server
Database Server Version
No response
Browser
Google Chrome
Checklist
- [x] I have read and understand the contributing guidelines
- [x] I have checked the existing issues for whether this defect was already reported
Hey @BlythMeister If this is still open Can i pick this? How can i reproduce this ?
I have no idea how to reproduce it...all I know if that I have more analysis than findings somehow.
If you tell me what the 2 counts are totaling i.e. how they get the values, I can check our data to maybe point you in a direction for how it's wrong.
@BlythMeister I'm not able to replicate this issue I am not getting negative value mentioned in this issue ?
@BlythMeister Can you check whether this problem stems from component metrics or "higher up"? Since project metrics are just a sum of component metrics, and portfolio metrics a sum of project metrics, it would be helpful to know where the issue originates.
A DB query would help here, like this:
select "FINDINGS_TOTAL"
, "FINDINGS_AUDITED"
from "DEPENDENCYMETRICS"
where "FINDINGS_TOTAL" < "FINDINGS_AUDITED"
I suspect the underlying issue is a race condition, possibly caused by vulnerability analysis happening while metrics are being calculated, or metrics updates happening concurrently for the same project or component.
i had a few records like this.
the problem was that they had
findings total = 1 findings audited = 2 findings unaudited = -1
i fixed by reducing audited by 1 and increaseing unaudited by 1.
But perhaps whatever writes to that table should ensure that those numbers are never negative :D
@BlythMeister Did you find those in the DEPENDENCYMETRICS table?
I guess we could just retry the calculation if we detect such invalid values going forward.
yeah, i found them in that table. Ran an update where unaudited was -1 to set audited = audited - 1 and unaudited = unaudted + 1 ran it a few times (one had -3 unaudited) and fixed them all
Running:
SELECT SUM(Findings_total),SUM(FINDINGS_AUDITED),SUM(FINDINGS_UNAUDITED)
FROM DEPENDENCYMETRICS dm INNER JOIN PROJECT p ON dm.PROJECT_ID = p.ID
WHERE dm.ID IN (SELECT MAX(dm.ID)
FROM DEPENDENCYMETRICS dm INNER JOIN PROJECT p ON dm.PROJECT_ID = p.ID
WHERE p.ACTIVE = 1
GROUP BY COMPONENT_ID, PROJECT_ID)
i get 678, 673, 3
I would therefore expect it to be Findings unaudited 3. Findings audited 673.
Interestingly, that means that i am showing 13 under on un-audited and audited.
I've resolved the 3 that I had left. I also called refresh metrics for everything.
Still have a negative 13 showing.
Is there a way to completely rebuild metrics?
I.e. can I reset and start over on them.
AH-HA
select * from PORTFOLIOMETRICS where FINDINGS_UNAUDITED < 0
Hundreds of rows!
So whatever is writing the metrics needs a bit of looking to not allow negative numbers i think :D
Sorry for the bulk spam here, but i think i've found the root cause.
We originally had OSS Index (sonatype) setup. we have removed it, i manually removed some of the vulnerability information, but i'm not sure if i removed everything The Components_Vulerabilities table still had rows listed which didn't have a corresponding row in the findings table.
I think this has then lead to a lot of the metrics getting broken.
UPDTE: CONFIRMED!
I removed the bad rows from COMPONENTS_VULNERABILITES (whereby there was no corresponding row in FINDINGATTRIBUTION) using the SQL
DELETE cv FROM COMPONENTS_VULNERABILITIES cv LEFT JOIN FINDINGATTRIBUTION fa ON cv.COMPONENT_ID = fa.COMPONENT_ID AND cv.VULNERABILITY_ID = fa.VULNERABILITY_ID WHERE fa.ID IS NULL
Ran the portfolio metrics refresh and now my numbers all match perfectly!
So the issue came about because of my bad manual removing of OSS Index analyser.
Me AGAIN :)
It wasn't that :-) But, i do think i have found something. When calculating metrics on component, if the same alias is found, it skips (https://github.com/DependencyTrack/dependency-track/blob/master/src/main/java/org/dependencytrack/tasks/metrics/ComponentMetricsUpdateTask.java#L87-L90)
However, the checking for audits at https://github.com/DependencyTrack/dependency-track/blob/master/src/main/java/org/dependencytrack/tasks/metrics/ComponentMetricsUpdateTask.java#L203-L215 does not do the same thing.
The unanalised then takes the total - analysed.
SO
If there is 2 findings both with analysis but with the same alias, the total findings will be 1, but the analysed would be 2. so therefore unanalysed would be -1.
I think this is actually more prevelant when you have OSS Index and Internal analyser as the duplicate alias don't get combined allowing you to submit 2 analysis on it
Good catch @BlythMeister! That indeed looks like the culprit.
Should be easy enough to resolve.
Looking at it, I think the findings counter cannot be de-duplicated based on aliases, but the vulnerabilities counter can. Since you can have multiple findings (e.g. GHSA-123 from GitHub, CVE-123 from OSS Index) each with their own audit / suppression (findingsAudited, suppressed). vulnerabilities does not have this differentiation so aliases can be taken into consideration for it.
@BlythMeister,
We have re-assigned this once more (to v4.14.0 milestone) in order that v4.13.0 be released without further delay.
Apologies for this but, on the positive side, the v4.13.0 release will contain a lot of useful new functionality.
