Merge pull request #14760 from DefectDojo/release/2.57.3

Release: Merge release into master from: release/2.57.3

Author: rossops

components/package.json

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

docs/content/releases/pro/changelog.md

@@ -12,6 +12,32 @@ For Open Source release notes, please see the [Releases page on GitHub](https://
 
 ## Apr 2026: v2.57
 
+### Apr 20, 2026: v2.57.2
+
+* **(Pro UI)** Search and filter state is now preserved when closing a Finding from a Finding list, so you don't lose your place after editing.
+* **(Risk Acceptance)** Bulk Edit no longer leaves Simple Risk Acceptance findings in an inconsistent "Active + Risk Accepted" state. Reactivating a previously risk-accepted Finding now behaves correctly.
+* **(Risk SLA)** Creating a Risk SLA no longer silently coerces unchecked `enforce_*_risk` options to `True`.
+* **(Surveys)** Fixed survey access for both authenticated users and anonymous links.
+* **(Universal Parser)** Non-ASCII scan names no longer cause a `UnicodeEncodeError` on import. CSV files with `""`-escaped quotes in multiline fields now parse correctly.
+* **(API)** Import/Reimport now validates consistency between ID-based and name-based identifiers, catching mismatched payloads earlier.
+* **(Permissions)** Moving an Engagement between Products now requires appropriate permission on both the source and target Product.
+* **(Reports)** Fixed a CSS overflow issue in rendered reports. Cleaned up endpoint template rendering for user fields.
+* **(Tools)** `govulncheck` parser now records `fix_available` and `fix_version`. Risk Recon parser now validates URLs via a shared SSRF utility. Added Mozilla Foundation security advisories as a supported Vulnerability ID source.
+
+### Apr 13, 2026: v2.57.1
+
+* **(Pro UI)** Object-level history views no longer default to a 31-day date filter, so the full history is visible on load.
+* **(Pro UI)** Audit Log "changes" filter now searches only the names of changed fields, reducing false matches.
+* **(Pro UI)** Predefined Finding filters now sync UI state correctly, so the active filter indicator reflects the applied filter.
+* **(Deduplication)** Added a UI for global component deduplication settings, behind a feature flag.
+* **(Rules Engine)** Fixed a preview timeout that occurred when rules were previewed against large Finding sets.
+* **(Universal Parser)** CSV/XML query path now displays correctly in the Universal Parser UI.
+* **(Import)** Additional parameters are now stored in import settings, making them available for reuse on reimport.
+* **(Tools)** Wazuh 4.8 parser now correctly attaches endpoints and locations to findings.
+* **(Tools)** Invicti parser now uses `FirstSeenDate` when populating Finding dates when `DD_USE_FIRST_SEEN` is enabled.
+* **(Tools)** `govulncheck` parser fixed for NDJSON output.
+* **(Tools)** Added CNNVD as a supported Vulnerability ID source.
+
 ### Apr 7, 2026: v2.57.0
 
 * **(Custom Enrichment)** On-prem administrators can now configure custom URLs for EPSS and KEV enrichment data sources under **Settings → Finding Enrichment Settings**. Each source (EPSS scores and CISA Known Exploited Vulnerabilities) can be independently enabled and pointed to an internal mirror or proxy. A **Test Configuration** button validates connectivity before saving. Findings with CVE IDs are automatically enriched with EPSS score/percentile and KEV status during enrichment runs.

docs/content/releases/pro/ddorch-database.md

@@ -0,0 +1,174 @@
+---
+title: "Adding the dd-orch Database on Upgrade"
+toc_hide: true
+weight: -20260501
+description: "Provisioning the dojodb-ddorch PostgreSQL database and pointing DefectDojo Pro at it on an existing self-hosted installation."
+audience: pro
+---
+
+Starting with 2.57.3, DefectDojo Pro requires a second PostgreSQL database, `dojodb-ddorch`, used by the new `ddorch` orchestrator service. The existing `dojodb` database continues to be used by the main Django application.
+
+This guide walks through adding `dojodb-ddorch` to an existing self-hosted PostgreSQL instance and pointing DefectDojo at it.
+
+## Prerequisites
+
+- PostgreSQL 16 is already installed and running on the DB server.
+- The `dojodbusr` role already exists with a known password.
+- `dojodb` is already created and reachable from the DefectDojo app server.
+- `listen_addresses` in `postgresql.conf` is already configured for remote access.
+- You have upgraded to the release that ships the `ddorch` and `ddorch-workers` services.
+
+> **A note on the database name:** `dojodb-ddorch` contains a hyphen, so it must be double-quoted in every SQL statement (`"dojodb-ddorch"`).
+
+## Part 1: Provision the Database
+
+### 1. Create the new database
+
+On the PostgreSQL server, open a `psql` session as the `postgres` superuser:
+
+```bash
+sudo -i -u postgres psql --username postgres
+```
+
+Create the database, grant privileges to the existing `dojodbusr` role, and transfer ownership:
+
+```sql
+CREATE DATABASE "dojodb-ddorch";
+GRANT ALL PRIVILEGES ON DATABASE "dojodb-ddorch" TO dojodbusr;
+ALTER DATABASE "dojodb-ddorch" OWNER TO dojodbusr;
+\q
+```
+
+**Example session:**
+
+```
+root@dbserver:~# sudo -i -u postgres psql --username postgres
+psql (16.8)
+Type "help" for help.
+
+postgres=# CREATE DATABASE "dojodb-ddorch";
+CREATE DATABASE
+postgres=# GRANT ALL PRIVILEGES ON DATABASE "dojodb-ddorch" TO dojodbusr;
+GRANT
+postgres=# ALTER DATABASE "dojodb-ddorch" OWNER TO dojodbusr;
+ALTER DATABASE
+postgres=# \q
+```
+
+> **PostgreSQL 15+ note:** Ownership covers schema rights for the owner, but if you ever connect as a non-owner role you will also need to grant schema privileges inside the new database:
+>
+> ```sql
+> \c "dojodb-ddorch"
+> GRANT ALL ON SCHEMA public TO dojodbusr;
+> ```
+
+### 2. Allow the app server to connect
+
+Edit `/etc/postgresql/16/main/pg_hba.conf` and add a new line for `dojodb-ddorch` next to the existing `dojodb` entry.
+
+**(a) Preferred — restrict to the DefectDojo app server's IP.**
+
+Supposing the app server's IP is `9.9.9.9`, add:
+
+```
+host  dojodb-ddorch  dojodbusr  9.9.9.9/32  scram-sha-256
+host  postgres  dojodbusr  9.9.9.9/32  scram-sha-256
+```
+
+**(b) Alternative — allow from any host.**
+
+```
+host  dojodb-ddorch  dojodbusr  0.0.0.0/0  scram-sha-256
+host  postgres  dojodbusr  0.0.0.0/0  scram-sha-256
+```
+
+> **Note:** The lines in `pg_hba.conf` are whitespace-delimited. The easiest way to add this line is to copy/paste the existing `dojodb` line and change the database name.
+
+**Alternative using `echo` (if no text editor is available):**
+
+```bash
+# For specific IP (replace 9.9.9.9 with your app server IP):
+echo "host  dojodb-ddorch  dojodbusr  9.9.9.9/32  scram-sha-256" | sudo tee -a /etc/postgresql/16/main/pg_hba.conf
+echo "host  postgres  dojodbusr  9.9.9.9/32  scram-sha-256" | sudo tee -a /etc/postgresql/16/main/pg_hba.conf
+
+# OR for all hosts:
+echo "host  dojodb-ddorch  dojodbusr  0.0.0.0/0  scram-sha-256" | sudo tee -a /etc/postgresql/16/main/pg_hba.conf
+echo "host  postgres  dojodbusr  0.0.0.0/0  scram-sha-256" | sudo tee -a /etc/postgresql/16/main/pg_hba.conf
+
+```
+
+### 3. Reload PostgreSQL
+
+Changes to `pg_hba.conf` only require a reload — no restart is needed:
+
+```bash
+sudo systemctl reload postgresql
+```
+
+Verify the reload was picked up:
+
+```bash
+sudo systemctl status postgresql
+```
+
+### 4. Verify connectivity from the app server
+
+From the **DefectDojo app server**, confirm `dojodbusr` can reach the new database. Replace `<db-server-ip>` with your DB server's IP and `<password>` with the password set for `dojodbusr`:
+
+```bash
+psql "host=<db-server-ip> dbname=dojodb-ddorch user=dojodbusr password=<password>" -c "SELECT 1;"
+```
+
+A successful response of `?column?` with a value of `1` confirms the database is reachable and the credentials are valid.
+
+## Part 2: Point DefectDojo at the New Database
+
+Only the `ddorch` service connects to the new database directly. The main Django application reaches the orchestrator over gRPC, so `DD_DATABASE_URL` does **not** change.
+
+### 1. Set the orchestrator database URL
+
+The `ddorch` service reads its connection string from the `DD_DATABASE_URL` environment variable and **automatically appends `-ddorch` to the database name** in whatever URL you pass it. This means you can reuse the same connection string you already use for the main Django application — no need to construct a second URL by hand.
+
+On startup, ddorch rewrites the database name in this URL from `dojodb` to `dojodb-ddorch` and connects to the database you created in Part 1.
+
+### 2. Restart the orchestrator services
+
+From the deployment directory, recreate the two orchestrator containers so they pick up the new environment:
+
+```bash
+docker compose up -d ddorch ddorch-workers
+```
+
+Docker Compose will detect the environment change and recreate the containers. The `ddorch` service runs its own schema migrations against `dojodb-ddorch` on startup — no manual migration command is required.
+
+### 3. Verify ddorch connected and migrated the new database
+
+The most direct signal that the database is correctly wired up is the ddorch startup log. Check the last hundred lines:
+
+```bash
+docker compose logs ddorch --tail=100
+```
+
+Look for three log lines in sequence:
+
+```
+{"level":"INFO","msg":"Appending database name to DATABASE_URL","from":"dojodb","to":"dojodb-ddorch"}
+INFO Running migrations current_schema_version=<N> next_version=<M> migrations_to_apply=<K>
+{"level":"INFO","msg":"starting server","port":9871}
+```
+
+What each line proves:
+
+- **`Appending database name to DATABASE_URL ... to: dojodb-ddorch`** — ddorch received your URL and derived the orch database name correctly.
+- **`Running migrations ... migrations_to_apply=0`** — ddorch connected to `dojodb-ddorch` and found the schema at the expected version. On a first-ever boot against a fresh database you may see `migrations_to_apply=<N>` with a non-zero value and no subsequent error — this means ddorch just created the tables from scratch. Both outcomes indicate success.
+- **`starting server ... port:9871`** — ddorch is up and listening.
+
+If instead you see an error such as `FATAL: password authentication failed`, `no pg_hba.conf entry for host`, or `database "dojodb-ddorch" does not exist`, the database is not reachable — revisit Part 1 before proceeding.
+
+Also confirm both orchestrator containers are running:
+
+```bash
+docker compose ps ddorch ddorch-workers
+```
+
+Both should report `Up`. With ddorch migrated and the workers container running, your installation is now using the new `dojodb-ddorch` database.

docs/content/triage_findings/finding_deduplication/PRO__deduplication_tuning.md

@@ -34,7 +34,7 @@ To adjust Same Tool Deduplication:
 
 ### Available Deduplication Algorithms
 
-DefectDojo Pro offers three deduplication methods for same-tool deduplication:
+DefectDojo Pro offers the following deduplication methods for same-tool deduplication:
 
 #### Hash Code
 Uses a combination of selected fields to generate a unique hash. When selected, a third dropdown will appear showing the fields being used to calculate the hash.
@@ -47,6 +47,9 @@ This algorithm can be useful when working with SAST scanners, or situations wher
 #### Unique ID From Tool or Hash Code
 Attempts to use the tool's unique ID first, then falls back to the hash code if no unique ID is available. This provides the most flexible deduplication option.
 
+#### Global Component
+Matches findings by component name and version across **all Products** in the instance, rather than within a single Product or Engagement. Intended for SCA tools where the same vulnerable dependency appears in many Products. This algorithm is off by default and must be enabled by DefectDojo Support. See [Global Component Deduplication](/triage_findings/finding_deduplication/pro__global_component_deduplication/) for details.
+
 ## Cross Tool Deduplication
 
 Cross Tool Deduplication is disabled by default, as deduplication between different security tools requires careful configuration due to variations in how tools report the same vulnerabilities.
@@ -59,7 +62,7 @@ To enable Cross Tool Deduplication:
 2. Change the **Deduplication Algorithm** from "Disabled" to "Hash Code"
 3. Select which fields should be used for generating the hash in the **Hash Code Fields** dropdown
 
-Unlike Same Tool Deduplication, Cross Tool Deduplication only supports the Hash Code algorithm, as different tools rarely share compatible unique identifiers.
+Cross Tool Deduplication supports the Hash Code algorithm, which is suitable for most workflows, as different tools rarely share compatible unique identifiers. For SCA tools reporting the same dependencies, [Global Component Deduplication](/triage_findings/finding_deduplication/pro__global_component_deduplication/) is also available as a cross-tool option (off by default).
 
 ## Reimport Deduplication
 
@@ -76,7 +79,7 @@ When configuring Reimport Deduplication:
 1. Select the **Security Tool** (Universal or Generic Parser)
 2. Choose the appropriate **Deduplication Algorithm**
 
-The same three algorithm options are available for Reimport Deduplication as for Same Tool Deduplication:
+The following algorithm options are available for Reimport Deduplication:
 - Hash Code
 - Unique ID From Tool
 - Unique ID From Tool or Hash Code

docs/content/triage_findings/finding_deduplication/PRO__global_component_deduplication.md

@@ -0,0 +1,87 @@
+---
+title: "Global Component Deduplication (Pro)"
+description: "Deduplicate Software Composition Analysis Findings by component name and version across all Products"
+weight: 5
+audience: pro
+---
+
+Global Component Deduplication is a DefectDojo Pro algorithm that identifies duplicate Findings across **all Products** based on the component name and version they reference. It is intended for Software Composition Analysis (SCA) tools, where the same vulnerable dependency (for example, `timespan@2.3.0`) may appear in many Products, and you want DefectDojo to treat those occurrences as duplicates of a single original Finding.
+
+Unlike the other deduplication algorithms, Global Component matching is **not scoped to a single Product or Engagement**. A Finding imported into Product B can be marked as a duplicate of an older Finding in Product A, even if the two Products are unrelated.
+
+## Enabling the Global Component Algorithm
+
+Global Component Deduplication is gated behind a feature flag and is **off by default**. To request that it be enabled on your instance, contact [DefectDojo Support](mailto:support@defectdojo.com).
+
+Once the feature is enabled, **Global Component** will become available as an option in the **Deduplication Algorithm** dropdown for both Same Tool and Cross Tool Deduplication settings in the Tuner.
+
+## Configuring Global Component Deduplication
+
+Global Component can be applied to Same-Tool Deduplication, Cross-Tool Deduplication, or both, and is configured per security tool from **Settings > Pro Settings > Deduplication Settings**.
+
+### Same-Tool
+
+Use Same-Tool Deduplication with the Global Component algorithm when you want to deduplicate findings from a single SCA tool across multiple Products.
+
+1. Open the **Same Tool Deduplication** tab.
+2. Select the SCA tool from the **Security Tool** dropdown (for example, `Dependency Track Finding Packaging Format (FPF) Export`).
+3. Set the **Deduplication Algorithm** to **Global Component**.
+4. Submit the form.
+
+Hash Code Fields are not used by this algorithm and are hidden when it is selected.
+
+### Cross-Tool
+
+Use Cross-Tool Deduplication with the Global Component algorithm when you want to deduplicate findings of the same component across different SCA tools and Products.
+
+Cross-tool matching requires Global Component to be configured on **each** tool that should participate.
+
+1. Open the **Cross Tool Deduplication** tab.
+2. For each tool to include: select it from the **Security Tool** dropdown, set the algorithm to **Global Component**, and submit.
+
+## How Matching Works
+
+A new Finding is marked as a duplicate of an existing Finding when:
+
+- The component name and component version match exactly, **and**
+- An older Finding with the same component name and version exists anywhere in the DefectDojo instance — in any Product or Engagement.
+
+Component version matching is exact. A Finding for `timespan@2.3.0` will **not** deduplicate against one for `timespan@2.3.1`.
+
+The Engagement-scoped deduplication setting is ignored for this algorithm; matching is always global.
+
+## Example
+
+Assume Global Component is enabled on `Dependency Track Finding Packaging Format (FPF) Export` (Same Tool) and on a Generic Findings Import tool (Cross Tool):
+
+| Step | Import | Into Product | Result |
+| --- | --- | --- | --- |
+| 1 | Dependency Track scan for `timespan@2.3.0` | Application 0 | 1 active Finding created |
+| 2 | Same Dependency Track scan | Application 1 | 1 Finding created, marked as duplicate of the Application 0 Finding |
+| 3 | Generic Findings Import for `timespan@2.3.0` | Application 2 | 1 Finding created, marked as duplicate of the Application 0 Finding (cross-tool match) |
+| 4 | Dependency Track scan for `timespan@2.3.1` | Application 3 | 1 active Finding created — different version, no match |
+
+Each duplicate Finding shows its original at the bottom of the Finding page in the duplicate chain.
+
+## Cross-Product Visibility
+
+Because Global Component matching crosses Product boundaries, the original Finding in a duplicate chain may live in a Product that the user viewing the duplicate does not have permission to access.
+
+In that case, the Finding is visible and labelled as a duplicate, but the user will not be able to open or navigate to the original. Consider this before enabling Global Component on tools whose Findings are sensitive to Product-level access controls.
+
+## Reverting
+
+To stop using Global Component for a given tool, open its Deduplication Settings and switch the algorithm back to one of the scoped options.
+
+For **Same Tool** Deduplication:
+
+- Hash Code
+- Unique ID From Tool
+- Unique ID From Tool or Hash Code
+
+For **Cross Tool** Deduplication:
+
+- Hash Code
+- Disabled
+
+Changing the algorithm triggers a background recalculation of deduplication hashes for the tool's existing Findings.

docs/content/triage_findings/finding_deduplication/about_deduplication.md

@@ -145,4 +145,5 @@ Sometimes, Deduplication does not work as expected.  Here are some examples of w
 | Reimport closes an old Finding and creates a new one when only the line number changed | Reimport matching uses unstable fields (for example, line number) | <strong>Reimport Deduplication</strong> (prefer stable IDs or stable hash fields) |
 | Multiple Findings are created in the same Test that you believe should be duplicates | Deduplication matching is not configured for that tool or scope | <strong>Same Tool Deduplication</strong> (and consider “Delete Deduplicate Findings” behavior) |
 | Duplicates are created across different tools | Cross-tool matching is disabled or too strict | <strong>Cross Tool Deduplication (Pro only)</strong> (hash-based matching) |
+| The same SCA dependency imported into multiple Products creates separate Findings instead of duplicates | Deduplication is scoped per Product by default | <strong>Global Component Deduplication (Pro only)</strong> ([enable for your SCA tools](/triage_findings/finding_deduplication/pro__global_component_deduplication/)) |
 | Excess duplicates of the same Finding are being created, across Tests | Asset Hierarchy is not set up correctly | [Consider Reimport for continual testing](/triage_findings/finding_deduplication/avoid_excess_duplicates/) |

docs/layouts/_partials/head/script-header.html

@@ -1,7 +1,7 @@
 <!-- Insert scripts NOT needed by stylesheets here -->
 <!-- Start of Reo Javascript -->
 <script type="text/javascript">
-  !function () { var e, t, n; e = "a92cfcfa51eca96", t = function () { Reo.init({ clientID: "a92cfcfa51eca96" }) }, (n = document.createElement("script")).src = "https://static.reo.dev/" + e + "/reo.js", n.async = !0, n.onload = t, document.head.appendChild(n) }();
+  !function(){var e,t,n;e="a92cfcfa51eca96",t=function(){Reo.init({clientID:"a92cfcfa51eca96"})},(n=document.createElement("script")).src="https://static.reo.dev/"+e+"/reo.js",n.defer=!0,n.onload=t,document.head.appendChild(n)}();
 </script>
 <!-- End of Reo Javascript -->
 <script>function initApollo() {