Upgrading to DefectDojo Version 3.2.200

Locations is now a self-service toggle (DefectDojo Pro)

In DefectDojo Pro, Locations moves from an environment-managed setting to a database-backed toggle on the Settings > Feature Flags page. You no longer need a deployment change or a Support request to turn it on: the toggle drives the Pro UI and the import pipeline live, with no restart.

A few properties are worth knowing:

  • Enabling is one-way. Once Locations is on, the toggle locks (shown as Cannot Be Disabled), because turning it back off would require reversing the location data migration, which is not yet supported.
  • The Classic UI and /api/v2 route wiring still follow DD_V3_FEATURE_LOCATIONS. Those surfaces are decided when the process starts, so the toggle carries a Restart Recommended tag. If you use the Classic UI or depend on the /api/v2 endpoint routes, keep the deployment setting in sync and restart so every surface agrees.
  • The stored value is seeded from the environment on upgrade. An instance already running with DD_V3_FEATURE_LOCATIONS=True comes up with the toggle already on (and locked); the database owns the value from then on, and you do not need to remove the environment variable. The setting is consulted only as a boot-time fallback when the database is unavailable.

Open source DefectDojo is unaffected: with the pro app absent, DD_V3_FEATURE_LOCATIONS continues to govern Locations exactly as before.

Data-migration suite carries existing history into Locations

Enabling the toggle only changes behaviour for new imports. Your existing history is carried forward by a data-migration suite that appears under the Locations row on the Feature Flags page once the feature is on. Each item is run on demand by a superuser, shows live progress and an ETA, and is safe to re-run (every step is idempotent).

Because a Finding can carry three independent kinds of location, the suite has four items:

ItemWhat it doesCommand
Endpoints to Locations backfillExisting Endpoint rows become URL Locations (tags, metadata, references, and status all carried over).migrate_endpoints_to_locations
Components to Dependencies backfillEach Finding’s component_name / component_version becomes a Dependency Location.migrate_components_to_dependencies
Findings to Code Locations backfillEach Finding’s file_path / line becomes a Source Code Location.migrate_findings_to_code_locations
Identity rehashRecomputes the deduplication identity for scan types whose digest changed when the flag flipped, so future reimports match the migrated Locations instead of closing and re-opening findings.—

The three backfills are independent and may run in any order. The identity rehash stays locked until all three backfills have completed, because the identity it recomputes folds in every location type; running it against a half-migrated database would bake an incomplete identity. Only one item runs at a time.

The backfills only read the Finding fields they convert (component_*, file_path, line) and add Locations and references alongside; they never modify or delete your Findings or the original Endpoint rows. Each is also available as a management command (above) for scripted or air-gapped runs.

For the full behavior of each backfill and the read-compatibility of the legacy Endpoint API afterward, see Migrating from Endpoints.

What you need to do

  • Already running with DD_V3_FEATURE_LOCATIONS=True: nothing changes on your surfaces. The Feature Flags toggle now reflects that value and owns it going forward. Leave the environment variable set so the Classic UI and /api/v2 stay aligned.
  • Turning Locations on for the first time: enable it from the Feature Flags page, then run the three backfills followed by the identity rehash from the suite under the row. If you use the Classic UI or the /api/v2 endpoint routes, set DD_V3_FEATURE_LOCATIONS=True and restart so those boot-fixed surfaces match.
  • No action for open source: the behavior is unchanged when the pro app is not installed.

For more information, check the Release Notes.