Merge branch 'bugfix' into zip-handling-consolidation

Author: rossops

docs/content/admin/user_management/user_permission_chart.md

@@ -63,10 +63,12 @@ The majority of Configuration Permissions give users access to certain pages in
 | Login Banner | n/a | n/a | Edit the login banner, located under **⚙️Configuration \> Login Banner** | n/a |
 | Announcements | n/a | n/a | Configure Announcements, located under  **⚙️Configuration \> Announcements** | n/a |
 | Note Types | Access the ⚙️Configuration \> Note Types page | Add a Note Type | Edit a Note Type | Delete a Note Type |
+| Prioritization Engines | Access the Prioritization Engine configuration page | Add a new Prioritization Engine | Edit an existing Prioritization Engine | Delete a Prioritization Engine |
 | Product Types | n/a | Add a new Product Type (under Products \> Product Type) | n/a | n/a |
 | Questionnaires | Access the **Questionnaires \> All Questionnaires** page | Add a new Questionnaire | Edit an existing Questionnaire | Delete a Questionnaire |
 | Questions | Access the **Questionnaires \> Questions** page | Add a new Question | Edit an existing Question | n/a |
 | Regulations | n/a | Add a Regulation to the **⚙️Configuration \> Regulations** page | Edit an existing Regulation | Delete a Regulation |
+| Scheduling Service Schedule | Access the **Scheduling** page | Superuser only | Edit an existing Schedule (change trigger, enable/disable) | Delete a Schedule |
 | SLA Configuration | Access the **⚙️Configuration \> SLA Configuration** page | Add a new SLA Configuration | Edit an existing SLA Configuration | Delete an SLA Configuration |
 | Test Types | n/a | Add a new Test Type (under **Engagements \> Test Types**) | Edit an existing Test Type | n/a |
 | Tool Configuration | Access the **⚙️Configuration \> Tool Configuration** page | Add a new Tool Configuration | Edit an existing Tool Configuration | Delete a Tool Configuration |

docs/content/automation/rules_engine/about.md

@@ -14,17 +14,28 @@ Rules Engine can only be accessed through the [Pro UI](/get_started/about/ui_pro
 
 Currently, Rules can only be created for Findings, however more object types will be supported in the future.
 
-Rules always need to be manually triggered from the **All Rules** page.  When a rule is triggered, it will be applied to all existing Findings that match the filter conditions set.
+Rules can be triggered manually from the **All Rules** page, or scheduled to run automatically on a recurring schedule.  When a rule is triggered, it will be applied to all existing Findings that match the filter conditions set.
 
 ## Possible Rule Actions
 Each Rule can apply one or more of these changes to a Finding when it is triggered successfully (i.e. matches the set Filter conditions).
 
-* Modify or append one or more informational fields on a Finding, including Title, Description, Severity, CVSSv3 Vector, Active, Verified, Risk Accepted, False Positive, Mitigated
-* Set a User to Review a Finding
-* Assign a Group as Owners for a Finding
-* Add Tags to a Finding
-* Add a Note to a Finding
-* Create an Alert in DefectDojo with custom text
+### Field Modifications
+* **Set a field** on a Finding, including Title, Description, Severity, CVSSv3 Vector, Active, Verified, Risk Accepted, False Positive, Mitigated
+* **Append or Prepend text** to a Finding's Title or Description
+* **Set Priority** — override the calculated Priority value on a Finding (overrides automatic priority calculation)
+* **Set Risk** — override the calculated Risk level on a Finding (overrides automatic risk calculation)
+* **Add, Subtract, Multiply, or Divide** the Priority value on a Finding by a given number
+
+### Assignments & Ownership
+* **Set a User to Review** a Finding
+* **Assign a Group as Owners** for a Finding
+* **Set a Mitigation Policy** on a Finding — assigns a pre-configured Mitigation Policy to the Finding
+* **Add to Risk Acceptance** — adds a Finding to an existing Risk Acceptance record (sets risk_accepted=True, active=False, and handles Jira integration and endpoint statuses)
+
+### Tags, Notes & Alerts
+* **Add Tags** to a Finding
+* **Add a Note** to a Finding
+* **Create an Alert** in DefectDojo with custom text
 
 ### Filter conditions
 Rules are automatically triggered when a Finding meets specific Filter conditions. For more information on Filters that can be used to create Rule Actions, see the [Filter Index](/navigation/pro__filter_index) page.

docs/content/automation/rules_engine/scheduling.md

@@ -0,0 +1,51 @@
+---
+title: "Scheduling Rules"
+description: "Automatically run Rules Engine rules on a recurring or one-time schedule"
+weight: 2
+audience: pro
+---
+<span style="background-color:rgba(242, 86, 29, 0.3)">Note: Rules Engine Scheduling is a DefectDojo Pro-only feature.</span>
+
+Rules can be scheduled to run automatically rather than triggered manually each time.  A scheduled rule will execute against all Findings that match its filter conditions at the configured time.
+
+The user setting up the schedule must have the **Change Scheduling Service Schedule** configuration permission.
+
+## Schedule Types
+
+### Single Run
+
+A Single Run schedule executes the rule once at a specific date and time.  After the run completes, the schedule is not repeated.
+
+### Repeated Run
+
+A Repeated Run schedule allows you to trigger a rule on a recurring basis — for example, every day at 9:00 AM, or every Monday at 15:00.
+
+**Note:** Rules Engine schedules are limited to quarter-hour marks.  The minute field of a cron schedule must be one of: **0, 15, 30, or 45**.  Other minute values are not permitted.
+
+Examples of valid schedules:
+- Every hour on the hour: `0 * * * *`
+- Every day at 9:15 AM: `15 9 * * *`
+- Every Monday at 3:00 PM: `0 15 * * 1`
+- Every 15 minutes: `0,15,30,45 * * * *`
+
+## Creating a Schedule for a Rule
+
+1. Navigate to the **All Rules** page from the **Rules Engine** menu in the sidebar.
+2. Find the rule you want to schedule, and open its action menu (**⋮**).
+3. Click **Schedule Rule**.  This option is only visible if the Scheduling Service is enabled and you have the required permission.
+4. In the **Schedule Rule** modal, fill in the following fields:
+
+| Field | Description |
+|---|---|
+| **Name** | A unique name for this schedule (required, max 100 characters). |
+| **Description** | Optional description of the schedule's purpose. |
+| **Trigger Type** | Choose **Single Run** for a one-time execution, or **Repeated Run** for a recurring cron schedule. |
+| **Frequency** | For Repeated Run: use the cron builder to select the period (hourly, daily, weekly, etc.) and the specific minute, hour, and day values. For Single Run: select a date and time using the date picker. |
+| **Enable Schedule** | Toggle to enable or disable the schedule.  A disabled schedule will not run until re-enabled. |
+
+5. Click **Submit** to save the schedule.  The rule will run automatically at the next scheduled time.
+
+
+## Permissions
+
+Access to scheduling within Rules Engine requires Superuser permissions or the appropriate Configuration Permission.  See [User Permission Chart](/admin/user_management/user_permission_chart) for details.  

docs/content/releases/pro/changelog.md

@@ -12,11 +12,17 @@ For Open Source release notes, please see the [Releases page on GitHub](https://
 
 ## Feb 2026: v2.55
 
+### Feb 26, 2026: v2.55.5
+
+* **(Rules Engine)** Rules Engine now automatically retries when encountering database lock contention or serialization conflicts, reducing the likelihood of a rule run failing due to temporary load on the system.
+
 ### Feb 24, 2026: v2.55.4
 
 * **(Connectors)** Added Akamai API Security, JFrog Xray to Connectors.
 * **(Surveys)** Anonymous surveys: users can now access surveys without logging in when anonymous surveys are enabled.
 * **(Pro UI)** The Pro UI editor now uses Markdown-based editing for text fields.  This resolves issues with HTML-string encoding, especially when Findings were manually entered or edited.
+* **(Rules Engine)** Added **Set Mitigation Policy** action type: Rules can now assign a pre-configured Mitigation Policy to matching Findings.
+* **(Rules Engine)** Added **Add to Risk Acceptance** action type: Rules can now add matching Findings to an existing Risk Acceptance record, automatically setting them as risk-accepted and inactive, and handling Jira integration and endpoint statuses.
 
 ### Feb 17, 2026: v2.55.3
 
@@ -126,6 +132,7 @@ No significant UX changes.
 #### Oct 20, 2025: v2.51.2
 
 * **(Connectors)** Added Anchore Enterprise Connector.
+* **(Rules Engine)** Rules can now be scheduled to run automatically on a recurring or one-time basis.  From the Rules list, use the **⋮** menu on any rule to open the **Schedule Rule** form.
 
 
 #### Oct 14, 2025: v2.51.1

dojo/api_v2/serializers.py

@@ -2711,8 +2711,11 @@ def process_scan(
                 # Attempt to create an engagement
                 logger.debug("reimport for non-existing test, using import to create new test")
                 context["engagement"] = auto_create_manager.get_or_create_engagement(**context)
+                # Do not close old findings when creating a brand new test: there are no
+                # existing findings to compare against, and close_old_findings would
+                # incorrectly close findings from other tests in the same scope.
                 context["test"], _, _, _, _, _, _ = self.get_importer(
-                    **context,
+                    **{**context, "close_old_findings": False},
                 ).process_scan(
                     context.pop("scan", None),
                 )
@@ -2856,30 +2859,36 @@ def save(self):
             msg = "Invalid format"
             raise Exception(msg)
 
+        # Filter out ignored keys
+        language_names = [name for name in deserialized if name not in {"header", "SUM"}]
+        # Prepopulate existing Language_Type objects
+        existing_types = {
+            lt.language: lt
+            for lt in Language_Type.objects.filter(language__in=language_names)
+        }
+        # Determine which Language_Type objects need to be created
+        new_language_names = [name for name in language_names if name not in existing_types]
+        new_types = [Language_Type(language=name) for name in new_language_names]
+        Language_Type.objects.bulk_create(new_types)
+        # Add newly created Language_Type objects to cache
+        for lt in Language_Type.objects.filter(language__in=new_language_names):
+            existing_types[lt.language] = lt
+        # Delete all Languages for this product
         Languages.objects.filter(product=product).delete()
-
-        for name in deserialized:
-            if name not in {"header", "SUM"}:
-                element = deserialized[name]
-
-                try:
-                    (
-                        language_type,
-                        _created,
-                    ) = Language_Type.objects.get_or_create(language=name)
-                except Language_Type.MultipleObjectsReturned:
-                    language_type = Language_Type.objects.filter(
-                        language=name,
-                    ).first()
-
-                language = Languages()
-                language.product = product
-                language.language = language_type
-                language.files = element.get("nFiles", 0)
-                language.blank = element.get("blank", 0)
-                language.comment = element.get("comment", 0)
-                language.code = element.get("code", 0)
-                language.save()
+        # Prepare Languages objects for bulk insert
+        languages_to_create = [
+            Languages(
+                product=product,
+                language=existing_types[name],
+                files=deserialized[name].get("nFiles", 0),
+                blank=deserialized[name].get("blank", 0),
+                comment=deserialized[name].get("comment", 0),
+                code=deserialized[name].get("code", 0),
+            )
+            for name in language_names
+        ]
+        # Bulk insert all Languages in one query
+        Languages.objects.bulk_create(languages_to_create)
 
     def validate(self, data):
         if is_scan_file_too_large(data["file"]):

dojo/finding/deduplication.py

@@ -8,7 +8,7 @@
 from django.db.models.query_utils import Q
 
 from dojo.celery import app
-from dojo.models import Finding, System_Settings
+from dojo.models import Endpoint_Status, Finding, System_Settings
 
 logger = logging.getLogger(__name__)
 deduplicationLogger = logging.getLogger("dojo.specific-loggers.deduplication")
@@ -295,12 +295,19 @@ def build_candidate_scope_queryset(test, mode="deduplication", service=None):
     # Base prefetches for both modes
     prefetch_list = ["endpoints", "vulnerability_id_set", "found_by"]
 
-    # Additional prefetches for reimport mode
+    # Additional prefetches for reimport mode: fetch only non-special endpoint statuses with their
+    # endpoint joined in, so endpoint_manager can read status_finding_non_special directly without
+    # any extra DB queries
     if mode == "reimport":
-        prefetch_list.extend([
-            "status_finding",
-            "status_finding__endpoint",
-        ])
+        prefetch_list.append(
+            Prefetch(
+                "status_finding",
+                queryset=Endpoint_Status.objects.exclude(
+                    Q(false_positive=True) | Q(out_of_scope=True) | Q(risk_accepted=True),
+                ).select_related("endpoint"),
+                to_attr="status_finding_non_special",
+            ),
+        )
 
     return (
         queryset

dojo/importers/default_reimporter.py

@@ -766,12 +766,8 @@ def process_matched_mitigated_finding(
         else:
             # TODO: Delete this after the move to Locations
             # Reactivate mitigated endpoints that are not false positives, out of scope, or risk accepted
-            endpoint_statuses = existing_finding.status_finding.exclude(
-                Q(false_positive=True)
-                | Q(out_of_scope=True)
-                | Q(risk_accepted=True),
-            )
-            self.endpoint_manager.chunk_endpoints_and_reactivate(endpoint_statuses)
+            # status_finding_non_special is prefetched by build_candidate_scope_queryset
+            self.endpoint_manager.chunk_endpoints_and_reactivate(existing_finding.status_finding_non_special)
         existing_finding.notes.add(note)
         self.reactivated_items.append(existing_finding)
         # The new finding is active while the existing on is mitigated. The existing finding needs to

dojo/importers/endpoint_manager.py

@@ -157,8 +157,9 @@ def update_endpoint_status(
         """Update the list of endpoints from the new finding with the list that is in the old finding"""
         # New endpoints are already added in serializers.py / views.py (see comment "# for existing findings: make sure endpoints are present or created")
         # So we only need to mitigate endpoints that are no longer present
-        # using `.all()` will mark as mitigated also `endpoint_status` with flags `false_positive`, `out_of_scope` and `risk_accepted`. This is a known issue. This is not a bug. This is a future.
-        existing_finding_endpoint_status_list = existing_finding.status_finding.all()
+        # status_finding_non_special is prefetched by build_candidate_scope_queryset with the
+        # special-status exclusion and endpoint select_related already applied at the DB level
+        existing_finding_endpoint_status_list = existing_finding.status_finding_non_special
         new_finding_endpoints_list = new_finding.unsaved_endpoints
         if new_finding.is_mitigated:
             # New finding is mitigated, so mitigate all old endpoints

dojo/importers/location_manager.py

@@ -127,17 +127,19 @@ def update_location_status(
         """Update the list of locations from the new finding with the list that is in the old finding"""
         # New endpoints are already added in serializers.py / views.py (see comment "# for existing findings: make sure endpoints are present or created")
         # So we only need to mitigate endpoints that are no longer present
-        # using `.all()` will mark as mitigated also `endpoint_status` with flags `false_positive`, `out_of_scope` and `risk_accepted`. This is a known issue. This is not a bug. This is a future.
-
+        existing_location_refs: QuerySet[LocationFindingReference] = existing_finding.locations.exclude(
+            status__in=[
+                FindingLocationStatus.FalsePositive,
+                FindingLocationStatus.RiskAccepted,
+                FindingLocationStatus.OutOfScope,
+            ],
+        )
         if new_finding.is_mitigated:
             # New finding is mitigated, so mitigate all existing location refs
-            self.chunk_locations_and_mitigate(existing_finding.locations.all(), user)
+            self.chunk_locations_and_mitigate(existing_location_refs, user)
         else:
             # New finding not mitigated; so, reactivate all refs
-            existing_location_refs: QuerySet[LocationFindingReference] = existing_finding.locations.all()
-
-            new_locations_values = [str(location) for location in new_finding.unsaved_locations]
-
+            new_locations_values = {str(location) for location in new_finding.unsaved_locations}
             # Reactivate endpoints in the old finding that are in the new finding
             location_refs_to_reactivate = existing_location_refs.filter(location__location_value__in=new_locations_values)
             # Mitigate endpoints in the existing finding not in the new finding

dojo/location/models.py

@@ -111,9 +111,19 @@ def associate_with_finding(
         audit_time: datetime | None = None,
     ) -> LocationFindingReference:
         """
-        Get or create a LocationFindingReference for this location and finding,
-        updating the status each time. Also associates the related product.
+        Get or create a LocationFindingReference for this location and finding.
+        Also associates the related product.
         """
+        # Check if there is an existing reference for this finding and location
+        # If this method is being used to set the status
+        if LocationFindingReference.objects.filter(
+            location=self,
+            finding=finding,
+        ).exists():
+            return LocationFindingReference.objects.get(
+                location=self,
+                finding=finding,
+            )
         # Determine the status
         if status is None:
             status = self.status_from_finding(finding)
@@ -144,10 +154,17 @@ def associate_with_product(
         product: Product,
         status: ProductLocationStatus | None = None,
     ) -> LocationProductReference:
-        """
-        Get or create a LocationProductReference for this location and product,
-        updating the status each time.
-        """
+        """Get or create a LocationProductReference for this location and product"""
+        # Check if there is an existing reference for this finding and location
+        # If this method is being used to set the status
+        if LocationProductReference.objects.filter(
+            location=self,
+            product=product,
+        ).exists():
+            return LocationProductReference.objects.get(
+                location=self,
+                product=product,
+            )
         if status is None:
             status = self.status_from_product(product)
         # Use a transaction for safety in concurrent scenarios