bugfix(metrics): closed findings counter always shows 0 when no new findings are imported #14464
Open
vvpoglazov wants to merge 1 commit intoDefectDojo:bugfixfrom
Open
Conversation
🔴 Risk threshold exceeded.This pull request modifies sensitive code paths (dojo/metrics/utils.py and dojo/product/views.py), and the scanner flagged these edits as sensitive—configure allowed paths and authors in .dryrunsecurity.yaml to manage or suppress these findings.
🔴 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_4c7d856d)
| 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.
vvpoglazov
force-pushed
the
bugfix/metrics-closed-findings-end-of-day
branch
2 times, most recently
from
a437692 to
179a5ec
Compare
…ilter 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.
vvpoglazov
force-pushed
the
bugfix/metrics-closed-findings-end-of-day
branch
from
179a5ec to
1f68169
Compare
Maffooch
requested changes
Mar 9, 2026
Contributor
Maffooch
left a comment
Maffooch
left a comment
There was a problem hiding this comment.
Would this change support a use case of trying to answer the question "how many findings were closed in Q4 2025" ?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Closed Findings counter on the Product Metrics page shows
0even when closed findings exist and are correctly displayed when clicking the link.Root cause:
finding_queries()buildsend_datefrom the latest finding discovery date (as midnight00:00:00) and uses it as the upper bound formitigated__range. This is semantically incorrectThe 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
0permanently.Related historical issues: #9735, #2187.
Fix: replace
end_datewithtimezone.now()as the upper bound so any finding closed up to the current moment is counted. Applied in bothdojo/product/views.pyanddojo/metrics/utils.py.Test results
Added regression tests in
unittests/test_product_metrics_closed_count.py:Updated
test_closed_findings_filtered_by_mitigated_dateinunittests/test_metrics_queries.pyto reflect correct behavior: findings closed after the discovery date range but beforenow()should appear in closed metrics.Documentation
No documentation changes needed.
Checklist
bugfixbugfixbranchUnit tests