Home Asset modelling Locations Knowledge Check Knowledge Check (Pro) Nineteen questions about Locations in DefectDojo Pro: what they replace, how References link them to Assets and Findings, how the migration from Endpoints works, and how URLs, Dependencies, Source Code and Container Image Locations behave.
Pick an answer to see whether it’s right and why. Your first pick is the one that counts toward your score, but you can then pick the other options to see where each one would point you. Each explanation links to the page that covers it. Nothing is recorded: your answers stay in your browser and disappear when you leave the page.
1. What are Locations for?A.
Recording which region or data center your DefectDojo instance is hosted in
B.
Grouping Assets into a hierarchy, the way Organizations group Assets
C.
Describing where a Finding lives, whether that’s a URL, a software dependency, a line of source code, a container image or a cloud resource
D.
Tagging Findings with the office or team that owns them A Location is one shared, typed object for
where a Finding lives. Each kind of place (URL, Dependency, Source Code, Container Image, Cloud Resource) is a subtype of the same base Location.
Read more Where to look instead: Locations aren’t about your instance. They describe the places your scanners report Findings in.
Key Concepts →
Where to look instead: Assets are grouped by the Asset Hierarchy. A Location is attached to Assets, not a container for them.
Asset Hierarchy →
Where to look instead: Locations carry tags, but they model the scanned place, not who owns the Finding.
In the Pro UI →
2. What do Locations replace?A.
The legacy Endpoints model, and the Components data that used to live only as fields on a Finding
B.
Assets and Engagements
C.
Only Endpoints. Libraries still live as component fields on each Finding
D.
Tests, so each scan creates Locations instead URL Locations are the functional replacement for Endpoints, and Dependency Locations replace Components. With Dependencies, a library can exist on an Asset without any Finding.
Read more Where to look instead: Assets and Engagements stay as they are. A Location is linked to an Asset through an Asset Reference.
References →
Where to look instead: Components became Dependency Locations, identified by a Package URL, so a library no longer depends on a Finding to exist.
Working with SBOMs →
Where to look instead: Tests are unchanged. An import still creates a Test; its Findings are then linked to Locations.
Auto-Association at Import Time →
3. How do you turn Locations on for your instance?A.
Open a request with DefectDojo Support
B.
Turn it on yourself from the Feature Flags page
C.
Set an environment variable and redeploy DefectDojo
D.
Nothing to do: Locations are on for every Pro instance Locations are self-service: a superuser turns them on from
Settings > Feature Flags . No Support request and no deployment setting is needed, though a restart brings the
/api/v2 routes in line with the toggle.
Read more Where to look instead: No Support request is required for Locations.
Locations Overview →
Where to look instead: No deployment setting needs to change. Asset Versions is the setting that’s managed by deployment configuration.
Asset Versions and BOM Snapshots →
Where to look instead: Locations are off by default and must be enabled before you can use them.
Feature Flags: Locations →
4. How is a Location connected to the Assets and Findings it belongs to?A.
A Location stores a single Asset ID and a single Finding ID
B.
It isn’t connected. Locations are a separate inventory with no links to Findings
C.
Each Finding stores a copy of the Location’s fields
D.
Through Reference objects: Asset References link it to Assets, and Finding References link it to Findings Locations aren’t attached directly. Asset References and Finding References link them, each with its own status, so one Location can be shared by many Assets and many Findings.
Read more Where to look instead: A Location is shared. Two Assets with the same URL share one Location and reference it twice.
Things That Behave Differently →
Where to look instead: Imports link Findings to Locations automatically with an Active Finding Reference.
Auto-Association at Import Time →
Where to look instead: The Finding keeps its own fields (such as file_path and line), but the Location is a separate shared object it references.
Relationship to Finding Fields →
5. You upload an SBOM to an Asset. What does that add?A.
One Finding for every component the SBOM lists
B.
A Container Image Location for every image the SBOM mentions
C.
Dependency Locations for the libraries it lists, linked to the Asset by Asset References, with no Findings needed
D.
Nothing until a scan reports a vulnerability in one of the components An SBOM upload populates the Asset’s Dependencies. Findings that later reference those libraries attach to the same Dependency objects, and Findings imported earlier show up in the SBOM view too.
Read more Where to look instead: Components aren’t vulnerabilities. A library can sit on an Asset with no Finding at all.
References →
Where to look instead: An SBOM upload records libraries as Dependencies only. Container images come from scans and connectors.
What's Not in the MVP →
Where to look instead: The upload creates the Dependencies straight away. Findings attach to them as scans come in.
Findings That Reference Libraries →
6. Which Location types can only be created by scans and connectors (not by hand)?A.
Source Code and Container Image Locations
B.
URL and Dependency Locations
C.
All of them. No Location can be created by hand
D.
None of them. Every type has a New action Source Code and Container Image Locations are scan-managed: the scanner (or registry) is the source of truth, so there is no New action for them. URLs and Dependencies each have a New form.
Read more Where to look instead: Both have a New form: New URL on the URLs list and New Dependency on the Dependencies list.
In the Pro UI →
Where to look instead: You can create URLs and Dependencies yourself, and New Location on an Asset’s Locations tab.
In the Pro UI →
Where to look instead: There is no New Source Code Location or New Image action.
Container Image identity →
7. What does the Location Map show?A.
A geographic map of where your Assets’ servers are located
B.
An Asset’s Locations drawn as trees, one region per Location type, with active Finding counts on every node
C.
Every Location in the instance across all Assets
D.
The relationships between Assets in the Asset Hierarchy The Location Map replaces the table on an Asset’s Locations page. Locations are grouped by what they share (a host, a directory, a package, an account), and each node counts the active Findings on it or beneath it.
Read more Where to look instead: The map groups Locations by what they share, not by geography.
Groups and Locations →
Where to look instead: All Locations , which isn’t scoped to one Asset, keeps the table.
Where the Map Appears →
Where to look instead: Relationships between Assets are drawn on the hierarchy page.
Asset Hierarchy →
8. You’ve just enabled Locations. What happens to the Endpoints and component data your Findings already had?A.
It’s converted to Locations automatically the moment you save the flag
B.
It’s deleted, so you have to re-import your scans
C.
Nothing yet: new imports use Locations right away, and existing data moves over when a superuser runs the data-migration suite
D.
It stays as Endpoints for good, and only new imports use Locations Enabling Locations changes new imports only. The data-migration suite under the flag carries existing history forward. Enabling is one-way, so plan the switch before you turn it on.
Read more Where to look instead: The migration doesn’t run on its own. Each item is run on demand by a superuser.
Running the migration →
Where to look instead: Nothing is deleted. Even after migration, the legacy Endpoint rows stay until you choose to remove them.
What the Migration Does Not Do →
Where to look instead: The migration suite carries it forward. Endpoints are deprecated, and their pages go away in 3.6.0.
Migrating from Endpoints →
9. An Endpoint_Status has both mitigated=True and false_positive=True. What status does its Finding Reference get after migration?A.
Mitigated
B.
False Positive
C.
Both: the reference keeps the two flags
D.
Active, because the flags conflict A Location reference has one status at a time. The migration checks the flags in order (Risk Accepted, False Positive, Out of Scope, Mitigated) and the first match wins.
Read more Where to look instead: Mitigated is checked last, so any of the other flags wins over it.
What the Endpoints Backfill Does →
Where to look instead: Locations enforce a single status, so the old multi-flag combinations are collapsed.
Status Model →
Where to look instead: Active is used only when none of the flags is set.
What the Endpoints Backfill Does →
10. With Locations enabled, an automation sends POST /api/v2/endpoints/. What does it get back?A.
A new Endpoint, as before
B.
A 200 response, but the write is silently ignored
C.
410 Gone, with the replacement route in the bodyD.
403, because writes to the legacy Endpoint API are deprecated. Writes go to /api/v2/urls/, /api/v2/location_findings/ and /api/v2/location_products/The legacy Endpoint API keeps serving reads through a compatibility shim, but every write (
POST,
PUT,
PATCH,
DELETE) returns
403.
Read more Where to look instead: Only reads still work on /api/v2/endpoints/, and they’re projected from URL Locations.
What still works →
Where to look instead: Writes fail loudly, so automations know to move to the new endpoints.
REST API →
Where to look instead: 410 is for a route that still reaches the old Endpoint data, which DefectDojo treats as a bug to fix, not for writes.
If a Route Returns 410 →
11. Two Assets both have Findings on https://example.com/login. How many URL Locations exist for it?A.
One, shared by both Assets through one Asset Reference each
B.
Two, one per Asset
C.
One per Finding
D.
One per Test that reported it URL de-duplication is per canonical URL, not per Asset. Sharing one Location is what makes cross-Asset reporting possible.
Read more Where to look instead: Locations aren’t copied per Asset. Each Asset gets its own Asset Reference to the same Location.
References →
Where to look instead: Findings link to the Location through Finding References; they don’t each get their own.
Importing URLs from Scans →
Where to look instead: An import looks up an existing URL with matching fields before creating one.
Importing URLs from Scans →
12. Which statuses can an Asset Reference have?A.
Active, Mitigated, False Positive, Risk Accepted or Out of Scope
B.
Owned By or Used By
C.
Active or Mitigated
D.
None. Only Finding References have a status Asset References use a simpler status than Finding References, since Asset-level status doesn’t need the auditing detail.
Read more Where to look instead: Those five are the statuses of a Finding Reference, which also records the auditor and audit time.
References →
Where to look instead: Those are the relationship an Asset Reference can carry, which is separate from its status.
Owned-By vs Used-By →
Where to look instead: Both kinds of reference carry a status.
References →
13. Your team publishes a library that three other Assets consume. How should the Dependency’s Asset References describe that?A.
Mark the library Active on your Asset and Mitigated on the others
B.
owned_by your Asset, and used_by each of the three consuming AssetsC.
Create a separate Dependency for each Asset
D.
used_by your Asset, and owned_by each of the three consuming Assetsowned_by is for a first-party library an Asset publishes or maintains, and
used_by is for a third-party dependency it consumes. Together they answer “who consumes the package my team publishes?”
Read more Where to look instead: Status describes whether the library is still present, not how it belongs to the Asset. That’s the relationship.
Status Model →
Where to look instead: A Dependency is identified by its Package URL, so one library is one shared Location.
What a Dependency Holds →
Where to look instead: It’s the other way round: the publisher owns it and the consumers use it.
Owned-By vs Used-By →
14. You re-upload an SBOM with replace_dependencies=true, and it no longer lists a package that has an active Finding. What happens to that package on the Asset?A.
It’s removed, along with its Finding
B.
It’s removed, and the Finding is closed as mitigated
C.
The upload fails because the SBOM is missing a package
D.
It stays, because associations tied to active Findings are kept even in replace mode Replace mode prunes Asset associations that aren’t in the new SBOM
and aren’t referenced by an active Finding, so you don’t lose vulnerability context when a new SBOM omits a package.
Read more Where to look instead: An SBOM upload never deletes Findings, and replace mode keeps packages that active Findings reference.
Replace vs Append →
Where to look instead: An SBOM upload doesn’t close Findings. Scans and reimports change Finding status.
Findings That Reference Libraries →
Where to look instead: A missing package isn’t an error. Without replace mode, uploads simply add.
Replace vs Append →
15. A scanner reports acme/payments-api:latest with no digest, and another reports the same repository with a digest. How does DefectDojo treat them?A.
As two different Container Image Locations on purpose, because tags move and digests don’t
B.
As one image, merged by repository name
C.
It drops the tag-only image because it can’t be identified
D.
It looks up the digest for the tag in the registry and merges them An image’s identity is its digest when known and its tag only when that’s all there is. Collapsing them would make a Finding on last week’s
:latest read as one on this week’s. Tag-only images are marked
Digest Unknown .
Read more Where to look instead: Images are identified by registry, repository and digest, not repository alone.
What They Model →
Where to look instead: Tag-only images are kept and flagged rather than dropped.
Container Image identity →
Where to look instead: DefectDojo doesn’t resolve tags to digests. A tag-only image stays a separate Location.
Container Image identity →
16. With Location Drift Matching on, a SAST Finding moves from auth.py:42 to auth.py:57. What happens to its Source Code Locations?A.
The old reference is deleted and replaced by the new one
B.
The Finding is closed and a new Finding is created at line 57
C.
The reference to the old Location is mitigated and stamped with where the Finding moved and why; a new Active reference points at line 57
D.
Nothing. Source Code Locations only change when you edit them by hand The Finding keeps its identity, and the references record the trail. The finding page shows that trail as a location history timeline.
Read more Where to look instead: The old reference is kept so the movement history can be shown.
Movement History →
Where to look instead: Drift matching exists to stop that close-and-recreate churn.
Location Drift Matching →
Where to look instead: Source Code Locations are scan-managed. Imports and reimports keep them up to date.
Status Correctness →
17. Where does the metadata that was on an Endpoint end up after migration?A.
It’s dropped, because Locations don’t carry metadata
B.
In the Custom Fields card on the Location page, scoped to the Asset the Endpoint belonged to
C.
Only in Custom Fields, and only if the Custom Fields feature flag is on
D.
Copied onto every Finding that referenced the Endpoint Each
DojoMeta row is re-pointed at the new Location. Because a Location can be shared by several Assets, each field shows the Asset it belongs to.
Read more Where to look instead: Locations carry metadata (custom key/value pairs), just as Endpoints did.
Locations and Subtypes →
Where to look instead: The Custom Fields feature flag doesn’t change Location metadata. The card shows it whether the flag is on or off.
Tags and Metadata →
Where to look instead: The migration doesn’t modify Findings.
What the Migration Does Not Do →
18. Some of your Endpoints recorded AWS ARNs in the host field. What do they become after the Endpoints backfill?A.
Cloud Resource Locations, detected automatically
B.
Nothing. The backfill skips anything that isn’t a web address
C.
Container Image Locations
D.
URL Locations, like every other Endpoint. A cloud connector creates proper Cloud Resource Locations DefectDojo can’t reliably tell a resource identifier in a host field from a real hostname, and guessing wrong could change a Finding’s identity. A cloud connector reads the provider’s own identifier instead.
Read more Where to look instead: The backfill doesn’t guess. Cloud Resource Locations come from cloud posture scans and connectors.
Location Inventory from Connectors →
Where to look instead: Only Endpoints whose fields don’t form a valid URL are skipped (shown as Invalid URL ).
Removing the Legacy Endpoint Rows →
Where to look instead: Container Image Locations are created by scans and connectors, not by the backfill.
Container Image Locations →
19. With Asset Versions enabled, what is an Asset version?A.
Metadata about an Asset, so one Finding row can be recorded as found in or fixed in several releases
B.
A child Asset that holds a copy of every Finding in that release
C.
A version string DefectDojo sorts, so it can infer that 5.1 sits between 5.0 and 5.2
D.
A tag on the Asset’s Dependencies A version is metadata, not another Asset. Imports record
found_in and
fixed_in claims against it, and SBOM uploads record a BOM snapshot for it, without duplicating Findings.
Read more Where to look instead: Modelling releases as child Assets copies every Finding into every release, which is exactly what versions avoid.
Asset Versions and BOM Snapshots →
Where to look instead: Versions carry no ordering. DefectDojo doesn’t parse or compare version strings.
Binding an upload to a version →
Where to look instead: A version is bound to an upload with the version field, not with tags.
Binding an upload to a version →
