From 44c8b4ae1cacd200916fbcb5bea27bd6a84dc08a Mon Sep 17 00:00:00 2001 From: Sam Vader Date: Mon, 21 Sep 2026 16:36:24 -0500 Subject: [PATCH 1/2] docs(locations): cloud resource drift matching and the endpoint migration boundary Add two decisions to the OSS docs for the CloudResource location work. The endpoint migration guide now says the migration does not convert cloud resources held in Endpoint rows. Those rows keep migrating as URL Locations. A cloud connector re-import is the way to get a real Cloud Resource Location. The location drift matching guide now documents cloud resource matching. A cloud resource matches on its provider-assigned identifier alone, with no fuzzy matching. --- .../locations/PRO__migrating_from_endpoints.md | 1 + .../finding_deduplication/PRO__location_drift_matching.md | 6 ++++++ 2 files changed, 7 insertions(+) diff --git a/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.md b/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.md index 7c99cf6d4f1..2f3bb1e0650 100644 --- a/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.md +++ b/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.md @@ -81,6 +81,7 @@ Both create Locations on their identity hash and upsert their references, so the - It does **not** delete the original Endpoint or Endpoint_Status rows. They remain in the database to back the read-only legacy API. They are not used by the new UI or by imports after the feature is enabled. - It does **not** modify your Findings. The backfills only *read* the `component_*` and `file_path`/`line` fields; they add Locations and references alongside, leaving the Finding rows untouched. +- It does **not** convert cloud resources into Cloud Resource Locations. Endpoints often recorded things that are not web addresses at all, such as container references and AWS ARNs. Every one of those migrates as a URL Location, the same as any other Endpoint. DefectDojo cannot reliably tell a resource identifier stuffed into a host field from a genuine hostname. Guessing wrong can change a Finding's identity. To model those resources properly, import the account through a cloud connector. The connector reads the provider's own resource identifier. It creates a Cloud Resource Location from that identifier. ## Endpoint API After Migration diff --git a/docs/content/triage_findings/finding_deduplication/PRO__location_drift_matching.md b/docs/content/triage_findings/finding_deduplication/PRO__location_drift_matching.md index 0db858b051e..7d95d41aa53 100644 --- a/docs/content/triage_findings/finding_deduplication/PRO__location_drift_matching.md +++ b/docs/content/triage_findings/finding_deduplication/PRO__location_drift_matching.md @@ -63,6 +63,12 @@ With tracking enabled, reimport matching happens in two stages: When the same vulnerable package appears in **several manifests**, each manifest's finding is tracked independently: a version bump in one lockfile never swallows the finding from another. +### Cloud resource findings + +Cloud resources match on their identifier alone: the ARN, resource URI, or Azure resource ID the provider assigned. There is no fuzzy match here, and that is on purpose. A cloud provider assigns that identifier once, when it creates the resource, and never changes it. A bucket is not renamed into a different bucket. Instead, the provider deletes it and creates a new one. That new bucket is a genuinely different resource, so it is correctly a different finding. + +Region, service, tags, and display name can all change. The resource itself stays the same. None of these fields take part in the match. A relabelled instance is still the same instance, so it keeps its findings. + ### Severity re-scores Security tools re-score severities as their rule engines evolve. With tracking enabled, a tool-reported severity change does **not** split a finding's identity: the finding matches, and its severity is updated from the scan, unless a person has re-triaged the severity by hand, in which case the human's value always wins (see below). From 5ff8fc9a9b68ba9398e4c2b0b62e08316f5eeb1a Mon Sep 17 00:00:00 2001 From: Sam Vader Date: Mon, 21 Sep 2026 17:33:44 -0500 Subject: [PATCH 2/2] docs(locations): note the dedupe effect for cloud resource findings Say what a user sees after the Pro change. Two findings on two different cloud resources are never duplicates. An earlier merge does not survive the next import. --- .../finding_deduplication/PRO__location_drift_matching.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/content/triage_findings/finding_deduplication/PRO__location_drift_matching.md b/docs/content/triage_findings/finding_deduplication/PRO__location_drift_matching.md index 7d95d41aa53..1f7d98631a1 100644 --- a/docs/content/triage_findings/finding_deduplication/PRO__location_drift_matching.md +++ b/docs/content/triage_findings/finding_deduplication/PRO__location_drift_matching.md @@ -69,6 +69,8 @@ Cloud resources match on their identifier alone: the ARN, resource URI, or Azure Region, service, tags, and display name can all change. The resource itself stays the same. None of these fields take part in the match. A relabelled instance is still the same instance, so it keeps its findings. +Two findings on two different cloud resources are never duplicates of each other. If an earlier import merged them, they stay separate after the next import. + ### Severity re-scores Security tools re-score severities as their rule engines evolve. With tracking enabled, a tool-reported severity change does **not** split a finding's identity: the finding matches, and its severity is updated from the scan, unless a person has re-triaged the severity by hand, in which case the human's value always wins (see below).