Merge pull request #13992 from DefectDojo/release/2.53.5

Release: Merge release into master from: release/2.53.5

Author: rossops

.github/dependabot.yml

@@ -64,10 +64,3 @@ updates:
     versions:
     - ">= 4.a"
     - "< 5"
-- package-ecosystem: docker
-  directory: "/"
-  schedule:
-    interval: weekly
-  open-pull-requests-limit: 10
-  target-branch: dev
-  

.github/renovate.json

@@ -13,8 +13,7 @@
     "components/package.json",
     "components/package-lock.json",
     "dojo/components/yarn.lock",
-    "dojo/components/package.json",
-    "Dockerfile**"
+    "dojo/components/package.json"
   ],
   "ignoreDeps": [],
   "packageRules": [{

.github/workflows/rest-framework-tests.yml

@@ -58,7 +58,7 @@ jobs:
 
       # no celery or initializer needed for unit tests
       - name: Unit tests
-        timeout-minutes: 15
+        timeout-minutes: 20
         run: docker compose up --no-deps --exit-code-from uwsgi uwsgi
         env:
           DJANGO_VERSION: ${{ matrix.os }}

components/package.json

@@ -1,6 +1,6 @@
 {
   "name": "defectdojo",
-  "version": "2.53.4",
+  "version": "2.53.5",
   "license" : "BSD-3-Clause",
   "private": true,
   "dependencies": {

docs/content/en/working_with_findings/organizing_engagements_tests/product_hierarchy.md

@@ -25,9 +25,9 @@ Product Types can have Role\-Based Access Control rules applied, which limit tea
 
 #### What can a Product Type represent?
 
-* If a particular software project has many distinct deployments or versions, it may be worth creating a single Product Type which covers the scope of the entire project, and having each version exist as individual Products.  
+* If a particular software project has many distinct deployments or versions, it may be worth creating a single Product Type which covers the scope of the entire project, and having each version exist as individual Products.
 ​
-* You also might consider using Product Types to represent stages in your software development process: one Product Type for 'In Development', one Product Type for 'In Production', etc.  
+* You also might consider using Product Types to represent stages in your software development process: one Product Type for 'In Development', one Product Type for 'In Production', etc.
 ​
 * Ultimately, it's your decision how you wish to organize your Products, and what you Product Type to represent. Your DefectDojo hierarchy may need to change to fit your security teams' needs.
 
@@ -58,11 +58,11 @@ The following scenarios are good reasons to consider creating a separate DefectD
 * "**ExampleProduct 1\.0**" uses completely different software components from "**ExampleProduct 2\.0**", and both versions are actively supported by your company.
 * The team assigned to work on "**ExampleProduct version A**" is different than the product team assigned to work on "**ExampleProduct version B**", and needs to have different security permissions assigned as a result.
 
-These variations within a single Product can also be handled at the Engagement level. Note that Engagements don't have access control in the way Products and Product Types do. 
+These variations within a single Product can also be handled at the Engagement level. Note that Engagements don't have access control in the way Products and Product Types do.
 
 ## **Engagements**
 
-Once a Product is set up, you can begin creating and scheduling Engagements. Engagements are meant to represent moments in time when testing is taking place, and contain one or more **Tests**. 
+Once a Product is set up, you can begin creating and scheduling Engagements. Engagements are meant to represent moments in time when testing is taking place, and contain one or more **Tests**.
 
 Engagements always have:
 
@@ -72,12 +72,12 @@ Engagements always have:
 * an assigned **Testing Lead**
 * an associated **Product**
 
-There are two types of Engagement: **Interactive** and **CI/CD**. 
+There are two types of Engagement: **Interactive** and **CI/CD**.
 
 * An **Interactive Engagement** is typically run by an engineer. Interactive Engagements are focused on testing the application while the app is running, using an automated test, human tester, or any activity “interacting” with the application functionality. See [OWASP's definition of IAST](https://owasp.org/www-project-devsecops-guideline/latest/02c-Interactive-Application-Security-Testing#:~:text=Interactive%20Application%20Security%20Testing,interacting%E2%80%9D%20with%20the%20application%20functionality.).
 * A **CI/CD Engagement** is for automated integration with a CI/CD pipeline. CI/CD Engagements are meant to import data as an automated action, triggered by a step in the release process.
 
-Engagements can be tracked using DefectDojo's **Calendar** view. 
+Engagements can be tracked using DefectDojo's **Calendar** view.
 
 #### What can an Engagement represent?
 
@@ -91,7 +91,7 @@ If you have a planned testing effort scheduled, an Engagement offers you a place
 
 * **Test:** Nessus Scan Results (March 12\)
 * **Test:** NPM Scan Audit Results (March 12\)
-* **Test:** Snyk Scan Results (March 12\)  
+* **Test:** Snyk Scan Results (March 12\)
 ​
 You can also organize CI/CD Test results within an Engagement. These kinds of Engagements are 'Open\-Ended' meaning that they don't have a date, and will instead add additional data each time the associated CI/CD actions are run.
 
@@ -137,6 +137,29 @@ The following Test Types appear in the "Scan Type" dropdown when creating a new
 
 Non-parser Test Types should be used when you need to manually create findings that require remediation but don't originate from automated scanner output.
 
+#### **Parser-based Test Types**
+
+Parser-based test types can be categorized by how their test type name is determined:
+
+- **Fixed Test Type Names**: The test type name is predefined and known before import (e.g., "ZAP Scan", "Nessus Scan").
+
+- **Report-Defined Test Type Names**: The test type name is extracted from the scan report content at import time.
+
+Examples include:
+  - **Generic Findings Import**: Creates test types based on the `type` field in JSON reports
+  - **SARIF**: Creates test types based on tool names in the SARIF report (e.g., "Dockle Scan (SARIF)")
+  - **OpenReports**: Creates separate test types per source found in the report
+
+**Report-Defined Test Type Naming Rules:**
+- If the report's `type` field equals the scan type → uses scan type directly (e.g., "Generic Findings Import")
+- If the report's `type` field differs → creates "{type} Scan ({scan_type})" format (e.g., "Tool1 Scan (Generic Findings Import)")
+- If no `type` field is provided → uses scan type directly
+
+**Important Considerations:**
+- Report-defined test types are automatically created when a new type is detected during import or reimport.
+- For reimports, the test type name must match exactly - mismatches will raise a validation error
+- Deduplication settings (`HASHCODE_FIELDS_PER_SCANNER`) use test type names as keys, so report-defined names must be configured accordingly if you want custom deduplication behavior
+
 #### **How do Tests interact with each other?**
 
 Tests take your testing data and group it into Findings. Generally, security teams will be running the same testing effort repeatedly, and Tests in DefectDojo allow you to handle this process in an elegant way.

dojo/__init__.py

@@ -4,6 +4,6 @@
 # Django starts so that shared_task will use this app.
 from .celery import app as celery_app  # noqa: F401
 
-__version__ = "2.53.4"
+__version__ = "2.53.5"
 __url__ = "https://github.com/DefectDojo/django-DefectDojo"
 __docs__ = "https://documentation.defectdojo.com"

dojo/finding/deduplication.py

@@ -196,7 +196,18 @@ def is_deduplication_on_engagement_mismatch(new_finding, to_duplicate_finding):
 
 
 def get_endpoints_as_url(finding):
-    return [hyperlink.parse(str(e)) for e in finding.endpoints.all()]
+    # Fix for https://github.com/DefectDojo/django-DefectDojo/issues/10215
+    # When endpoints lack a protocol (scheme), str(e) returns a string like "10.20.197.218:6379"
+    # without the "//" prefix. hyperlink.parse() then misinterprets the hostname as the scheme.
+    # We replicate the behavior from dojo/endpoint/utils.py line 265: prepend "//" if "://" is missing
+    # to ensure hyperlink.parse() correctly identifies host, port, and path components.
+    urls = []
+    for e in finding.endpoints.all():
+        endpoint_str = str(e)
+        if "://" not in endpoint_str:
+            endpoint_str = "//" + endpoint_str
+        urls.append(hyperlink.parse(endpoint_str))
+    return urls
 
 
 def are_urls_equal(url1, url2, fields):

dojo/finding/views.py

@@ -968,8 +968,9 @@ def process_jira_form(self, request: HttpRequest, finding: Finding, context: dic
             logger.debug("jform.jira_issue: %s", context["jform"].cleaned_data.get("jira_issue"))
             logger.debug(JFORM_PUSH_TO_JIRA_MESSAGE, context["jform"].cleaned_data.get("push_to_jira"))
             # can't use helper as when push_all_jira_issues is True, the checkbox gets disabled and is always false
+            push_to_jira_checkbox = context["jform"].cleaned_data.get("push_to_jira")
             push_all_jira_issues = jira_helper.is_push_all_issues(finding)
-            push_to_jira = push_all_jira_issues or context["jform"].cleaned_data.get("push_to_jira")
+            push_to_jira = push_all_jira_issues or push_to_jira_checkbox or jira_helper.is_keep_in_sync_with_jira(finding)
             logger.debug("push_to_jira: %s", push_to_jira)
             logger.debug("push_all_jira_issues: %s", push_all_jira_issues)
             logger.debug("has_jira_group_issue: %s", finding.has_jira_group_issue)
@@ -996,12 +997,6 @@ def process_jira_form(self, request: HttpRequest, finding: Finding, context: dic
                     jira_helper.finding_link_jira(request, finding, new_jira_issue_key)
                     jira_message = "Linked a JIRA issue successfully."
             # any existing finding should be updated
-            jira_instance = jira_helper.get_jira_instance(finding)
-            push_to_jira = (
-                push_to_jira
-                and not (push_to_jira and finding.finding_group)
-                and (finding.has_jira_issue or (jira_instance and jira_instance.finding_jira_sync))
-            )
             # Determine if a message should be added
             if jira_message:
                 messages.add_message(

dojo/importers/base_importer.py

@@ -205,10 +205,34 @@ def consolidate_dynamic_tests(self, tests: list[Test]) -> list[Finding]:
         if not self.test:
             # Determine if we should use a custom test type name
             if test_raw.type:
-                test_type_name = f"{tests[0].type} Scan"
-                if test_type_name != self.scan_type:
-                    test_type_name = f"{test_type_name} ({self.scan_type})"
+                # If test_raw.type equals scan_type, use scan_type directly
+                if test_raw.type == self.scan_type:
+                    test_type_name = self.scan_type
+                else:
+                    test_type_name = f"{tests[0].type} Scan"
+                    if test_type_name != self.scan_type:
+                        test_type_name = f"{test_type_name} ({self.scan_type})"
             self.test = self.create_test(test_type_name)
+        else:
+            # During reimport, validate that the test_type matches
+            # Calculate the expected test_type_name from the incoming report
+            expected_test_type_name = self.scan_type
+            if test_raw.type:
+                # If test_raw.type equals scan_type, use scan_type directly
+                if test_raw.type == self.scan_type:
+                    expected_test_type_name = self.scan_type
+                else:
+                    expected_test_type_name = f"{test_raw.type} Scan"
+                    if expected_test_type_name != self.scan_type:
+                        expected_test_type_name = f"{expected_test_type_name} ({self.scan_type})"
+            # Compare with existing test's test_type name
+            if self.test.test_type.name != expected_test_type_name:
+                msg = (
+                    f"Test type mismatch: Test {self.test.id} has test_type '{self.test.test_type.name}', "
+                    f"but the report contains test_type '{expected_test_type_name}'. "
+                    f"Reimport with matching test_type or create a new test."
+                )
+                raise ValidationError(msg)
         # This part change the name of the Test
         # we get it from the data of the parser
         # Update the test and test type with meta from the raw test

dojo/importers/default_importer.py

@@ -18,7 +18,7 @@
     Test_Import,
 )
 from dojo.notifications.helper import create_notification
-from dojo.utils import perform_product_grading
+from dojo.utils import get_full_url, perform_product_grading
 from dojo.validators import clean_tags
 
 logger = logging.getLogger(__name__)
@@ -365,11 +365,13 @@ def close_old_findings(
             old_findings = old_findings.filter(Q(service__isnull=True) | Q(service__exact=""))
         # Update the status of the findings and any endpoints
         for old_finding in old_findings:
+            url = str(get_full_url(reverse("view_test", args=(self.test.id,))))
+            test_title = str(self.test.title)
             self.mitigate_finding(
                 old_finding,
                 (
-                    "This finding has been automatically closed "
-                    "as it is not present anymore in recent scans."
+                    'This Finding has been automatically closed by the Test: \n "' + test_title + '"\n' + url +
+                    "\n\nThis is because this Finding is not present anymore in recent scans."
                 ),
                 finding_groups_enabled=self.findings_groups_enabled,
                 product_grading_option=False,