Merge remote-tracking branch 'upstream/dev' into feature/celery-queue-status-ui

Author: valentijnscholten

.github/workflows/integration-tests.yml

@@ -76,7 +76,7 @@ jobs:
           # "tests/import_scanner_test.py",
           # "tests/zap.py",
         ]
-        os: [alpine, debian]
+        os: [debian]
         v3_feature_locations: [true, false]
         exclude:
           # standalone create endpoint page is gone in v3

.github/workflows/performance-tests.yml

@@ -23,13 +23,13 @@ jobs:
         uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
         with:
           path: built-docker-image
-          pattern: built-docker-image-django-alpine-linux-amd64
+          pattern: built-docker-image-django-debian-linux-amd64
           merge-multiple: true
 
       - name: Load docker images
         timeout-minutes: 10
         run: |
-          docker load -i built-docker-image/django-alpine-linux-amd64_img
+          docker load -i built-docker-image/django-debian-linux-amd64_img
           docker images
 
       - name: Set unit-test mode
@@ -45,7 +45,7 @@ jobs:
             -f docker/docker-compose.override.performance_tests_cicd.yml \
             up -d --no-deps uwsgi
         env:
-          DJANGO_VERSION: alpine
+          DJANGO_VERSION: debian
 
       - name: Run performance tests (auto-update counts)
         timeout-minutes: 15

.github/workflows/renovate.yaml

@@ -21,4 +21,4 @@ jobs:
         uses: suzuki-shunsuke/github-action-renovate-config-validator@ee9f69e1f683ed0d08225086482b34fc9abe9300 # v2.1.0
         with:
           strict: "true"
-          validator_version: 43.91.2 # renovate: datasource=github-releases depName=renovatebot/renovate
+          validator_version: 43.102.8 # renovate: datasource=github-releases depName=renovatebot/renovate

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

@@ -16,7 +16,7 @@ jobs:
     runs-on: ${{ inputs.platform ==  'linux/arm64' && 'ubuntu-24.04-arm' || 'ubuntu-latest' }}
     strategy:
       matrix:
-        os: [alpine, debian]
+        os: [debian]
 
     steps:
       # Replace slashes so we can use this in filenames

docs/content/get_started/open_source/installation.md

@@ -18,6 +18,23 @@ See instructions in [DOCKER.md](<https://github.com/DefectDojo/django-DefectDojo
 
 [SaaS link](https://defectdojo.com/platform)
 
+---
+## **Docker Image Variants**
+---
+
+DefectDojo publishes Docker images in multiple variants:
+
+| | AMD64 | ARM64 |
+|---|---|---|
+| **Debian** | ✅ Supported | ⚠️ Unit tested |
+| **Alpine** | ⚠️ Community | ⚠️ Community |
+
+**Debian on AMD64** is the officially supported and tested configuration. All CI tests (unit, integration, and performance) run against this combination.
+
+**Debian on ARM64** is built and covered by unit tests in CI, but integration and performance tests are not run against it.
+
+The **Alpine** variants are built and published but are not covered by any automated testing. Use them at your own risk.
+
 ---
 ## **Options for the brave (not officially supported)**
 ---

docs/content/releases/os_upgrading/2.56.4.md

@@ -0,0 +1,11 @@
+---
+title: 'Upgrading to DefectDojo Version 2.56.4'
+toc_hide: true
+weight: -20260319
+description: JFrog Xray API Summary Artifact parser deduplication
+---
+
+## JFrog Xray API Summary Artifact parser deduplication
+Deduplication of JFrog Xray API Summary Artifact findings is improved for newly imported findings.  
+
+To apply this on existing data, you need to recompute the hashes for this specific parser [see docs](https://docs.defectdojo.com/triage_findings/finding_deduplication/os__deduplication_tuning/#after-changing-deduplication-settings).

docs/content/supported_tools/parsers/file/anchore_grype.md

@@ -203,3 +203,31 @@ By default, DefectDojo identifies duplicate Findings using these [hashcode field
 - severity
 - component name
 - component version
+
+### Anchore Grype Detailed
+
+Both scan types accept the same JSON report format. The difference is in how Findings are deduplicated:
+
+- **`Anchore Grype`** — Aggregates all matches for the same CVE, component name, and version into a single Finding, regardless of file path. Deduplication is based on hashcode fields (`title`, `severity`, `component_name`, `component_version`).
+- **`Anchore Grype detailed`** — Creates a separate Finding for each unique file path. Deduplication is based on `unique_id_from_tool`, composed as `{vuln_id}|{component_name}|{component_version}|{file_path}`.
+
+A typical case is a package installed at multiple paths in a container image (e.g., /usr/lib/x86_64-linux-gnu/libc.so.6 and /lib/x86_64-linux-gnu/libc.so.6) — the same CVE would produce one Finding in default mode and two in detailed mode.
+
+**Field mapping:**
+
+| Finding Field | Grype JSON Source |
+|---|---|
+| `title` | `{vulnerability.id} in {artifact.name}:{artifact.version}` |
+| `severity` | `vulnerability.severity` (mapped: `Unknown`/`Negligible` → `Info`) |
+| `description` | `vulnerability.namespace`, `vulnerability.description`, `matchDetails[].matcher`, `artifact.purl` |
+| `component_name` | `artifact.name` |
+| `component_version` | `artifact.version` |
+| `file_path` | `artifact.locations[0].path` |
+| `vuln_id_from_tool` | `vulnerability.id` |
+| `unique_id_from_tool` | `vuln_id\|component_name\|component_version\|file_path` (detailed mode only) |
+| `references` | `vulnerability.dataSource`, `vulnerability.urls`, `relatedVulnerabilities[0].dataSource`, `relatedVulnerabilities[0].urls` |
+| `mitigation` | `vulnerability.fix.versions` |
+| `fix_available` | `true` if `vulnerability.fix.versions` is non-empty |
+| `fix_version` | `vulnerability.fix.versions[0]` (or comma-joined if multiple) |
+| `cvssv3` | `vulnerability.cvss` or `relatedVulnerabilities[0].cvss` |
+| `epss_score` / `epss_percentile` | `vulnerability.epss` or `relatedVulnerabilities[0].epss` |

docs/package-lock.json

@@ -76,13 +76,44 @@ def apply_async(self, args=None, kwargs=None, **options):
         return super().apply_async(args=args, kwargs=kwargs, **options)
 
 
-class PgHistoryTask(DojoAsyncTask):
+class PluggableContextTask(DojoAsyncTask):
+
+    """
+    Extends DojoAsyncTask with pluggable context managers loaded from settings.
+
+    CELERY_TASK_CONTEXT_MANAGERS is a list of dotted paths to callables that
+    return context managers. Each task execution is wrapped in all of them.
+    This replaces the celery signal-based approach (task_prerun/task_postrun)
+    which does not work reliably with prefork worker pools.
+    """
+
+    def __call__(self, *args, **kwargs):
+        from contextlib import ExitStack  # noqa: PLC0415
+
+        from django.utils.module_loading import import_string  # noqa: PLC0415
+
+        cm_paths = getattr(settings, "CELERY_TASK_CONTEXT_MANAGERS", [])
+        if not cm_paths:
+            return super().__call__(*args, **kwargs)
+
+        # ExitStack ensures all entered context managers are properly exited
+        # (via __exit__) even if the task raises an exception, so cleanup
+        # and batch dispatch always happen.
+        with ExitStack() as stack:
+            for path in cm_paths:
+                cm_factory = import_string(path)
+                stack.enter_context(cm_factory())
+            return super().__call__(*args, **kwargs)
+
+
+class PgHistoryTask(PluggableContextTask):
 
     """
     Custom Celery base task that automatically applies pghistory context.
 
-    This class inherits from DojoAsyncTask to provide:
+    This class inherits from PluggableContextTask to provide:
     - User context injection and task tracking (from DojoAsyncTask)
+    - Pluggable context managers from settings (from PluggableContextTask)
     - Automatic pghistory context application (from this class)
 
     When a task is dispatched via dojo_dispatch_task or dojo_async_task, the current