-
Notifications
You must be signed in to change notification settings - Fork 1.8k
bugfix(metrics): closed findings counter always shows 0 when no new findings are imported #14464
bugfix(metrics): closed findings counter always shows 0 when no new findings are imported #14464valentijnscholten merged 3 commits intoDefectDojo:bugfixfrom
Conversation
The Closed Findings counter on the Product Metrics page shows 0 even when closed findings exist and are correctly displayed when clicking the link.
| Metrics page (counter) | Findings list (after clicking) |
|---|---|
Root cause: finding_queries() builds end_date from the latest finding discovery date (as midnight 00:00:00) and uses it as the upper bound for mitigated__range. This is semantically incorrect
- a finding can be closed at any time after discovery, including days or weeks after the last scan. Any finding closed after that midnight cutoff is silently excluded from the counter.
The bug "self-healed" only when a new finding with a later discovery date was imported - making it particularly hard to notice. In environments with stable finding profiles (re-imports without new findings), the counter stayed at 0 permanently.
Related historical issues: #9735, #2187.
Fix: replace end_date with timezone.now() as the upper bound so any finding closed up to the current moment is counted. Applied in both dojo/product/views.py and dojo/metrics/utils.py.
Test results
Added regression tests in unittests/test_product_metrics_closed_count.py:
- finding closed on the same day as discovery date (after midnight) is counted
- finding discovered in the past but closed recently is counted
- all findings closed at any time on the same day are counted
Updated test_closed_findings_filtered_by_mitigated_date in unittests/test_metrics_queries.py to reflect correct behavior: findings closed after the discovery date range but before now() should appear in closed metrics.
Documentation
No documentation changes needed.
Checklist
- Rebased against latest
bugfix - Bugfix submitted against
bugfixbranch - Code is ruff compliant
- Code is Python 3.13 compliant
- Unit tests added
Unit tests
Risk threshold exceeded.This pull request modifies sensitive files (dojo/metrics/utils.py and dojo/product/views.py); the scanner flagged these as sensitive edits and notes that sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml. Review and verify the changes and authorizations before merging.
Configured Codepaths Edit in
|
| Vulnerability | Configured Codepaths Edit |
|---|---|
| Description | Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml. |
Configured Codepaths Edit in dojo/product/views.py (drs_675901ae)
| Vulnerability | Configured Codepaths Edit |
|---|---|
| Description | Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml. |
We've notified @mtesauro.
Comment to provide feedback on these findings.
Report false positive: @dryrunsecurity fp [FINDING ID] [FEEDBACK]
Report low-impact: @dryrunsecurity nit [FINDING ID] [FEEDBACK]
Example: @dryrunsecurity fp drs_90eda195 This code is not user-facing
All finding details can be found in the DryRun Security Dashboard.
a437692 to
179a5ec
Compare
The closed findings counter showed 0 even when closed findings existed.
Root cause: the upper bound for mitigated__range was derived from the latest
finding discovery date (end_date), built as midnight (00:00:00). This made
no semantic sense - a finding can be closed at any time after discovery,
so using the discovery date as the cutoff for mitigated is incorrect.
Fix: replace end_date with timezone.now() as the upper bound so any finding
closed up to the current moment is counted. Applied in both
dojo/product/views.py and dojo/metrics/utils.py.
The bug "self-healed" the next day when a new finding with a later discovery
date was imported - making it particularly hard to notice.
Adds regression tests in unittests/test_product_metrics_closed_count.py.
Updates test_closed_findings_filtered_by_mitigated_date to reflect correct
behavior: findings closed after discovery date range but before now() should
appear in closed metrics.
179a5ec to
1f68169
Compare
Maffooch
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this change support a use case of trying to answer the question "how many findings were closed in Q4 2025" ?
|
Hello @Maffooch, yes, I believe this fix supports that use case. Users can filter by mitigated date using either the Before this fix, the closed findings counter showed incorrect results (often 0) regardless of which mitigated filter was applied, because the upper bound for With this fix, the counter correctly reflects the filtered result. I'll test this locally and attach screenshots. |
Maffooch
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent testing! Thanks for the PR
valentijnscholten
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
mtesauro
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved
a58f164
into
DefectDojo:bugfix