Skip to content

Optimize queryset annotations & prefetches to cut DB time for test / finding / product views (issue #12575) #12603

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Maffooch merged 3 commits into from
Jun 30, 2025

Add subquery for test_count for engagements getting

f6f89c1
Select commit
Loading
Failed to load commit list.
Merged

Optimize queryset annotations & prefetches to cut DB time for test / finding / product views (issue #12575) #12603

Add subquery for test_count for engagements getting
f6f89c1
Select commit
Loading
Failed to load commit list.
DryRunSecurity / General Security Analyzer succeeded Jun 25, 2025 in 42s

DryRun Security

Details

General Security Analyzer Findings: 3 detected

⚠️ Subquery Field Name Injection Risk dojo/utils.py (click for details)
Type Subquery Field Name Injection Risk
Description The build_count_subquery function uses an unvalidated group_field parameter directly in Django ORM queries. While Django's ORM provides some protections, passing unvalidated field names could potentially lead to unexpected query behavior. The risk is low because Django's ORM typically sanitizes field names, but it's worth adding input validation to prevent any potential manipulation.
Filename dojo/utils.py
CodeLink

django-DefectDojo/dojo/utils.py

Lines 28 to 34 in f6f89c1

from django.contrib import messages
from django.contrib.auth.signals import user_logged_in, user_logged_out, user_login_failed
from django.core.paginator import Paginator
from django.db.models import Case, Count, IntegerField, Q, Subquery, Sum, Value, When
from django.db.models.query import QuerySet
from django.db.models.signals import post_save
from django.dispatch import receiver
⚠️ Incorrect Subquery Aggregation Logic dojo/utils.py (click for details)
Type Incorrect Subquery Aggregation Logic
Description The build_count_subquery function uses [:1] to slice the subquery result, which contradicts its docstring of returning 'one aggregated count per group_field'. This could lead to incomplete or incorrect data aggregation, potentially causing unexpected application behavior. The [:1] slice means only the first group's count is returned, not counts for all distinct groups.
Filename dojo/utils.py
CodeLink

django-DefectDojo/dojo/utils.py

Lines 2671 to 2681 in f6f89c1

}
logger.debug("No valid CVSS3 vector found in %s", cvss_vector_string)
return {}
def build_count_subquery(model_qs: QuerySet, group_field: str) -> Subquery:
"""Return a Subquery that yields one aggregated count per `group_field`."""
return Subquery(
model_qs.values(group_field).annotate(c=Count("*")).values("c")[:1], # one row per group_field
output_field=IntegerField(),
)
⚠️ Performance Risk in Complex Subqueries dojo/finding/views.py (click for details)
Type Performance Risk in Complex Subqueries
Description The introduced subqueries in the finding views (active_endpoint_count and mitigated_endpoint_count) use complex database operations with OuterRef, Coalesce, and custom build_count_subquery. While not a direct security vulnerability, these could potentially cause performance degradation or resource exhaustion under high load or with large datasets.
Filename dojo/finding/views.py
CodeLink

django-DefectDojo/dojo/finding/views.py

Lines 6 to 12 in f6f89c1

import logging
import mimetypes
from collections import OrderedDict, defaultdict
from functools import partial
from itertools import chain
from pathlib import Path
View more details on DryRunSecurity