Locations on DefectDojo Documentation

Locations Overview

Mon, 01 Jan 0001 00:00:00 +0000

Locations are a new asset-modelling tool in DefectDojo Pro. They replace the legacy Endpoints model and absorb the previous Components (library) data, giving DefectDojo a single, polymorphic way to describe where a Finding lives, whether that’s a URL, a software dependency from an SBOM, a line of source code, a container image, or a cloud resource.

Location Map

Mon, 01 Jan 0001 00:00:00 +0000

The Location Map opens an Asset’s Locations page on a map instead of a table. Every URL, source file, dependency and cloud resource the Asset has is drawn as a set of trees, one dashed region per location type, and each node shows how many active findings sit on it or beneath it.

Migrating from Endpoints

Mon, 01 Jan 0001 00:00:00 +0000

When you enable Locations on an existing DefectDojo Pro instance, the data already stored on your Findings needs to be carried forward into the new Locations model. This page describes the migration suite, what each part preserves, and how the legacy Endpoint API behaves once the migration has run.

Working with URLs

Mon, 01 Jan 0001 00:00:00 +0000

URL Locations are the functional replacement for the legacy Endpoints model. They store the same URL-shaped fields you are used to — protocol, host, port, path, query, fragment — and serve the same role: identifying where a web-application Finding lives.

Working with SBOMs

Mon, 01 Jan 0001 00:00:00 +0000

DefectDojo Pro models software libraries as Dependency Locations. A Dependency is a Location subtype identified by a Package URL (pURL) and intended to represent a single library or package — org.apache.logging.log4j:log4j-core@2.17.0, pypi/django@5.0.2, npm/react@18.2.0, and so on.

Source Code Locations

Mon, 01 Jan 0001 00:00:00 +0000

Source Code Locations extend the Locations model to static analysis: alongside URLs (DAST) and Dependencies (SCA), a Code location describes where a SAST finding lives in source — identified by its file path and line number.

Exporting SBOMs and VEX

Mon, 01 Jan 0001 00:00:00 +0000

DefectDojo Pro can serialize an Asset’s current dependency inventory back out as a standards-compliant SBOM, and its vulnerability triage decisions as a machine-readable VEX document. Both are produced from the same Dependency Locations that SBOM imports and scan findings populate, so whatever your scanners and uploads have accumulated is what the export describes — the documents are consumed by downstream tooling, compliance pipelines, and AI agents, not just humans.

Container Image Locations

Mon, 01 Jan 0001 00:00:00 +0000

Container Image Locations extend the Locations model to container scanning: alongside URLs (DAST), Dependencies (SCA), Source Code (SAST) and Cloud Resources (posture), an Image location describes the container image a finding was found in, identified by its registry, repository and digest.

AI Inventory

Mon, 01 Jan 0001 00:00:00 +0000

AI Inventory lists the AI found in every repository DefectDojo scans. It covers coding assistants and their rules files, MCP servers, models, AI SDKs and agent frameworks, AI service endpoints, agent skills, and the AI provider keys that secret scanning finds. Each component is a Dependency Location identified by a Package URL, so it shows up in component search and in SBOM exports, and it can be governed with AI Governance Policies.

Exporting an AIBOM

Mon, 01 Jan 0001 00:00:00 +0000

An AI bill of materials (AIBOM) lists the AI components in an Asset: coding assistants, MCP servers, models, AI packages, AI services and agent skills. DefectDojo produces it as a CycloneDX 1.6 document from the AI Inventory. It is the same export as the SBOM, limited to the AI components, so the two pair by bom-ref.