You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Stacked on top of the vulnerability_id-type change (feat/vulnerability-id-type).
Adds a Finding_CWE relationship so a finding can carry multiple CWEs, mirroring
vulnerability ids: the primary CWE stays on Finding.cwe; additional CWEs live in
the relationship and are exposed via finding.cwes. Wired through the UI, the API
(cwes field), and parsers (finding.unsaved_cwes). CWE is a weakness class, kept
out of hash_code and the cve field, so existing hash codes/dedup are unaffected.
Migrations 0279_finding_cwe (create table) and 0280_backfill_finding_cwe (seed
from legacy Finding.cwe), chained after the vulnerability_id migrations (0278).
Backfill existing findings with: manage.py migrate_cwe
Copy file name to clipboardExpand all lines: docs/content/releases/os_upgrading/3.2.md
+35-11Lines changed: 35 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,33 +2,57 @@
2
2
title: 'Upgrading to DefectDojo Version 3.2.x'
3
3
toc_hide: true
4
4
weight: -20260701
5
-
description: Vulnerability ids gain an autodetected type. A migration adds the type column, de-duplicates vulnerability-id rows, and adds a uniqueness constraint. Existing hash codes are unaffected.
5
+
description: Vulnerability ids gain an autodetected type and a uniqueness constraint; findings can now carry multiple CWEs via a new Finding_CWE relationship. Migrations add the type column, de-duplicate vulnerability-id rows, add the uniqueness constraint, create the CWE table, and backfill it. Existing hash codes are unaffected.
6
6
---
7
7
8
8
## Vulnerability id type
9
9
10
10
Each `Vulnerability_Id` gains an autodetected `vulnerability_id_type` — the identifier's leading
11
11
prefix (`CVE-2024-1234` → `CVE`, `GHSA-…` → `GHSA`, `RUSTSEC-…` → `RUSTSEC`). It is derived
12
12
structurally (no registry) and stored (indexed) so identifiers can be filtered and grouped by type
13
-
efficiently. It is `NULL` when there is no non-numeric prefix.
13
+
efficiently. It is `NULL` when there is no non-numeric prefix. It is populated automatically on
14
+
import and on `save()`; existing rows are backfilled by migration. It does not participate in
15
+
`hash_code`, so **existing hash codes and deduplication are unaffected**.
14
16
15
-
The type is populated automatically: on import (bulk paths) and on `save()`. Existing rows are
16
-
backfilled by the migration below. This is a denormalized, derived attribute — it does not
17
-
participate in `hash_code`, so **existing hash codes and deduplication are unaffected**.
17
+
A unique constraint is also added on `(finding, vulnerability_id)`; pre-existing duplicate rows
18
+
(unintended) are consolidated first.
19
+
20
+
## Multiple CWEs per finding
21
+
22
+
A finding could previously store only one CWE (the integer `cwe` field). This release adds a
23
+
dedicated `Finding_CWE` relationship so a finding can carry **multiple CWEs**, using the same
24
+
approach as vulnerability ids: the primary CWE stays on `Finding.cwe` (unchanged — legacy
25
+
deduplication and hash codes still use it), and additional CWEs live in the relationship.
26
+
27
+
CWE is modeled separately from vulnerability identifiers on purpose: a CWE is a weakness *class*,
28
+
not a vulnerability *instance* identifier, so it must not participate in `hash_code`,
29
+
vulnerability-id deduplication, or the `cve` field. Because of this separation, **existing hash
30
+
codes and deduplication are unaffected**.
31
+
32
+
CWEs are populated automatically on import and when a finding is created or edited (from the
33
+
finding's CWE field, plus any additional CWEs a parser supplies). The finding exposes them via
34
+
`finding.cwes` (primary first, deduplicated).
18
35
19
36
## Database migration
20
37
21
-
Three migrations run automatically on upgrade:
38
+
Five migrations run automatically on upgrade:
22
39
23
40
-`0276_vulnerability_id_type` — adds the indexed `vulnerability_id_type` column and a leading
24
41
index on `vulnerability_id`.
25
-
-`0277_backfill_vulnerability_id_type` — backfills `vulnerability_id_type` for existing rows and
26
-
removes duplicate `(finding, vulnerability_id)` rows, keeping the earliest of each — such
27
-
duplicates are unintended, and consolidating them allows a uniqueness constraint to be added.
28
-
-`0278_unique_finding_vulnerability_id` — adds a unique constraint on `(finding, vulnerability_id)`.
42
+
-`0277_backfill_vulnerability_id_type` — backfills `vulnerability_id_type` and removes duplicate
43
+
`(finding, vulnerability_id)` rows (keeping the earliest).
44
+
-`0278_unique_finding_vulnerability_id` — adds the unique constraint on `(finding, vulnerability_id)`.
45
+
-`0279_finding_cwe` — creates the `Finding_CWE` table (unique per `(finding, cwe)`).
46
+
-`0280_backfill_finding_cwe` — seeds `Finding_CWE` rows from the legacy `Finding.cwe` values.
29
47
30
48
### What you need to do
31
49
32
-
The migrations are applied automatically. No manual steps are required.
50
+
The migrations are applied automatically. New and edited findings populate their CWE relationship
51
+
automatically. To backfill `Finding_CWE` rows for **existing** findings, run the idempotent command
52
+
after upgrading:
53
+
54
+
```
55
+
manage.py migrate_cwe
56
+
```
33
57
34
58
For more information, check the [Release Notes](https://github.com/DefectDojo/django-DefectDojo/releases/tag/3.2.0).
0 commit comments