diff --git a/docs/assets/scss/common/_custom.scss b/docs/assets/scss/common/_custom.scss index 66c495098fd..22e0522e75a 100644 --- a/docs/assets/scss/common/_custom.scss +++ b/docs/assets/scss/common/_custom.scss @@ -210,6 +210,25 @@ h1, h2, h3, h4, h5, h6, display: none; } +// Pro badge — appears next to sidebar items with audience: pro +// Box height is `1lh` so it equals one line-height of the surrounding text. +.pro-badge { + display: inline-flex; + align-items: center; + box-sizing: border-box; + height: 1lh; + margin-left: 0.5em; + padding: 0 0.45em; + border: 1px solid #F2561D; + border-radius: 0.25rem; + background-color: rgba(#F2561D, 0.72); + color: #fff; + font-size: 0.7em; + font-weight: 500; + vertical-align: middle; + white-space: nowrap; +} + // ============================================================ // Cards // ============================================================ @@ -419,6 +438,12 @@ h1, h2, h3, h4, h5, h6, border-color: #F2762E; } + // Pro badge in dark mode + .pro-badge { + background-color: rgba(#F2561D, 0.85); + border-color: #F2762E; + } + // Selection color in dark mode ::selection { background-color: rgba(#82B0D9, 0.3); diff --git a/docs/content/asset_modelling/hierarchy/OS__sla_configuration.md b/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.md similarity index 97% rename from docs/content/asset_modelling/hierarchy/OS__sla_configuration.md rename to docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.md index ef454a48b2e..b0c82fd1e1d 100644 --- a/docs/content/asset_modelling/hierarchy/OS__sla_configuration.md +++ b/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.md @@ -8,7 +8,7 @@ aliases: --- Each Product in DefectDojo can have its own Service Level Agreement (SLA) configuration, which represents the days your organization has to remediate or otherwise manage a Finding. -SLA can be set based on either **[Finding Severity](/asset_modelling/hierarchy/product_hierarchy/#findings)** or **[Finding Risk](/asset_modelling/hierarchy/pro__priority_sla/)** (in DefectDojo Pro). +SLA can be set based on either **[Finding Severity](/asset_modelling/os_hierarchy/product_hierarchy/#findings)** or **[Finding Risk](/asset_modelling/pro_hierarchy/priority_sla/)** (in DefectDojo Pro). ![image](images/sla_multiple.png) diff --git a/docs/content/asset_modelling/hierarchy/OS__source-code-repositories.md b/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.md similarity index 100% rename from docs/content/asset_modelling/hierarchy/OS__source-code-repositories.md rename to docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.md diff --git a/docs/content/asset_modelling/OS_hierarchy/_index.md b/docs/content/asset_modelling/OS_hierarchy/_index.md new file mode 100644 index 00000000000..81e9356aa58 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/_index.md @@ -0,0 +1,11 @@ +--- +title: "Product Hierarchy" +audience: opensource +date: 2021-02-02T20:46:29+01:00 +draft: false +type: docs +weight: 3 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/hierarchy/benchmarks.md b/docs/content/asset_modelling/OS_hierarchy/benchmarks.md similarity index 100% rename from docs/content/asset_modelling/hierarchy/benchmarks.md rename to docs/content/asset_modelling/OS_hierarchy/benchmarks.md diff --git a/docs/content/asset_modelling/hierarchy/product_health_grade.md b/docs/content/asset_modelling/OS_hierarchy/product_health_grade.md similarity index 100% rename from docs/content/asset_modelling/hierarchy/product_health_grade.md rename to docs/content/asset_modelling/OS_hierarchy/product_health_grade.md diff --git a/docs/content/asset_modelling/hierarchy/product_hierarchy.md b/docs/content/asset_modelling/OS_hierarchy/product_hierarchy.md similarity index 100% rename from docs/content/asset_modelling/hierarchy/product_hierarchy.md rename to docs/content/asset_modelling/OS_hierarchy/product_hierarchy.md diff --git a/docs/content/asset_modelling/hierarchy/_index.md b/docs/content/asset_modelling/PRO_hierarchy/_index.md similarity index 91% rename from docs/content/asset_modelling/hierarchy/_index.md rename to docs/content/asset_modelling/PRO_hierarchy/_index.md index 906dff8366a..136d6186dda 100644 --- a/docs/content/asset_modelling/hierarchy/_index.md +++ b/docs/content/asset_modelling/PRO_hierarchy/_index.md @@ -3,6 +3,7 @@ title: "Asset Hierarchy" date: 2021-02-02T20:46:29+01:00 draft: false type: docs +audience: pro weight: 3 sidebar: collapsed: false diff --git a/docs/content/asset_modelling/hierarchy/PRO__assets_organizations.md b/docs/content/asset_modelling/PRO_hierarchy/assets_organizations.md similarity index 96% rename from docs/content/asset_modelling/hierarchy/PRO__assets_organizations.md rename to docs/content/asset_modelling/PRO_hierarchy/assets_organizations.md index bffdd35984c..54e0c47e07a 100644 --- a/docs/content/asset_modelling/hierarchy/PRO__assets_organizations.md +++ b/docs/content/asset_modelling/PRO_hierarchy/assets_organizations.md @@ -82,7 +82,7 @@ Core Application [Organization] └── nginx ``` -In this diagram, every element under "Core Application" could be recorded as a separate Asset, with unique business criticality (see: [Priority & Risk](/asset_modelling/hierarchy/pro__priority_sla/#prioritization-engines/)), RBAC, and corresponding Engagements and Tests. You could continue to test, and store results, on the parent Asset (for example, `webapp-backend`), but you could also run isolated testing on a particular child Asset (for example, `database`). +In this diagram, every element under "Core Application" could be recorded as a separate Asset, with unique business criticality (see: [Priority & Risk](/asset_modelling/pro_hierarchy/priority_sla/#prioritization-engines/)), RBAC, and corresponding Engagements and Tests. You could continue to test, and store results, on the parent Asset (for example, `webapp-backend`), but you could also run isolated testing on a particular child Asset (for example, `database`). ### Pen Tests: Isolated RBAC diff --git a/docs/content/asset_modelling/hierarchy/PRO__priority_sla.md b/docs/content/asset_modelling/PRO_hierarchy/priority_sla.md similarity index 99% rename from docs/content/asset_modelling/hierarchy/PRO__priority_sla.md rename to docs/content/asset_modelling/PRO_hierarchy/priority_sla.md index 1407232bb4e..b5c13afde6d 100644 --- a/docs/content/asset_modelling/hierarchy/PRO__priority_sla.md +++ b/docs/content/asset_modelling/PRO_hierarchy/priority_sla.md @@ -197,7 +197,7 @@ Note that when a Product's Prioritization Engine is changed, or a Prioritization Each Product in DefectDojo can have its own Service Level Agreement (SLA) configuration, which represents the days your organization has to remediate or otherwise manage a Finding. -SLA can be set based on either **[Finding Severity](/asset_modelling/hierarchy/product_hierarchy/#findings)** or **[Finding Risk](/asset_modelling/hierarchy/pro__priority_sla/)** (in DefectDojo Pro). +SLA can be set based on either **[Finding Severity](/asset_modelling/os_hierarchy/product_hierarchy/#findings)** or **[Finding Risk](/asset_modelling/pro_hierarchy/priority_sla/)** (in DefectDojo Pro). ![image](images/sla_multiple.png) diff --git a/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.md b/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.md new file mode 100644 index 00000000000..53961251fd3 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.md @@ -0,0 +1,31 @@ +--- +title: "Product Health Grade" +description: "How DefectDojo calculates a Product Health Grade" +aliases: + - /en/working_with_findings/organizing_engagements_tests/product_health_grade +--- +DefectDojo can calculate a grade for your Products based on the amount of Findings contained within. Grades are ranked from A \- F. + +Note that only Active \& Verified Findings contribute to a Product Grade \- unverified Findings will not have an impact. + +## Product Grade Calculation + +Every Product Grade starts at 100 (with no Findings). + +Grade calculation starts by looking at the highest **Severity** level of a Finding in a Product, and reducing the Product Health to a base level. + +| **Highest Severity Level of a Finding** | **Maximum Grade** | +| --- | --- | +| **Critical** | **40** | +| **High** | **60** | +| **Medium** | **80** | +| **Low** | **95** | + +Further points are then deducted from the Grade for each additional Finding: + +| **Severity Level of an additional Finding** | **Grade Reduced by** | +| --- | --- | +| **Critical** | **5** | +| **High** | **3** | +| **Medium** | **2** | +| **Low** | **1** | diff --git a/docs/content/asset_modelling/locations/PRO__locations_overview.md b/docs/content/asset_modelling/locations/PRO__locations_overview.md new file mode 100644 index 00000000000..95c60dbe69a --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__locations_overview.md @@ -0,0 +1,79 @@ +--- +title: "Locations Overview" +description: "What Locations are and why they replace Endpoints" +audience: pro +weight: 1 +--- + +**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**, or, in the future, a **cloud resource ID**, **container image**, or **code repository**. + +Locations are currently in **Beta** and will need to be enabled on your instance. To enable Locations on your instance, contact [support@defectdojo.com](mailto:support@defectdojo.com). + +## Why Replace Endpoints? + +The original Endpoints model was built around URLs and IP addresses — it carried web-app fields like `protocol`, `host`, `port`, `path`, and a fixed status table that was tightly coupled to Findings. Three problems followed: + +1. **Limited fidelity.** Endpoints could not cleanly describe non-URL assets such as third-party libraries, container images, or cloud resources, even though scanners increasingly produce findings about those things. +2. **Performance ceiling.** Per-Finding Endpoint_Status rows and the URL-shaped schema did not scale well at large customer volumes. +3. **Components were second-class.** Software libraries lived only as denormalised fields on a Finding, so a library could not exist independently of a vulnerability — making true SBOM management impossible. + +Locations fix all three by introducing a **base `Location` object** with a typed payload, plus dedicated **subtypes** for each asset shape. The MVP ships two subtypes: + +- **URL Locations** — functional equivalent of the old Endpoints, with the same protocol/host/port/path/query/fragment fields. +- **Dependency Locations** — software libraries identified by [Package URL (pURL)](https://github.com/package-url/purl-spec), used to model SBOM contents. + +Future Location types under consideration include cloud provider resource IDs (AWS ARN, Azure Resource ID, GCP Full Resource Name), container images (registry/repository:tag and SHA256 fingerprints), and code repositories. + +## Key Concepts + +### Locations and Subtypes + +A **Location** is the shared parent. It carries: + +- A `Location Type` (e.g. `"url"`, `"dependency"`) +- A canonical `Location Value` string used for display, search, and de-duplication +- `Tags` and inherited tags from the parent Asset +- Metadata (custom key/value pairs) + +A **subtype** (URL or Dependency) holds the structured fields specific to that kind of location. URLs and Dependencies always live alongside a parent Location object; the subtype's `Location Value` is generated from its structured fields. + +### References + +Locations are not directly attached to Products or Findings. Instead, two **Reference** objects link them: + +- **Asset References** — relationships the Location has to Assets (e.g. `libFoo` is *owned by* Asset 6, *used by* Asset 9). Each reference carries a status (`Active` or `Mitigated`) and an optional **relationship** ("Used By" or "Owned By"). +- **Finding References** — relationships the Location has to Findings. Each reference carries a richer status (`Active`, `Mitigated`, `False Positive`, `Risk Accepted`, `Out of Scope`) plus the auditor and audit time. + +This separation is what allows a library to exist on a Product *without* needing a Finding — a missing capability in the old Components model. + +### Auto-Association at Import Time + +When a parser produces a Finding that references a URL or library, the importer: + +1. Looks up an existing Location matching the URL or pURL; if none exists, it creates one. +2. Creates a Finding Reference linking the Finding to the Location with status `Active`. +3. Creates (or reuses) an Asset Reference so the Location also lives on the parent Asset. + +Existing parsers have been updated to emit Location data when the feature flag is on, and to fall back to the legacy Endpoint model when it is off. No reconfiguration is needed when Locations are enabled — the next import will route through the Locations pipeline automatically. + +## What's in the MVP + +| Capability | Status | +| --- | --- | +| Foundational `Location`, `URL`, `Dependency` models | Shipped | +| REST API for Locations and References | Shipped (read-only `Location`, full CRUD on References) | +| Endpoint API read-compatibility shim | Shipped | +| Endpoint → URL one-way migration command | Shipped | +| Parser updates (URLs and dependencies) | Shipped for the major parsers | +| SBOM upload (CycloneDX, SPDX v2/v3) | Shipped via `/api/v2/sbom-import/` | +| Pro UI for Locations, URLs, Dependencies | Shipped (Beta) | +| pURL search/filter | Shipped | +| License tracking on dependencies | Partial (`license_expression` field) | +| SWID Tag SBOM format | Not in MVP | + +## Where to Go Next + +- **Enable the feature** — contact [support@defectdojo.com](mailto:support@defectdojo.com) to turn Locations on for your instance. +- **Migrate from Endpoints** — see [Migrating from Endpoints](../pro__migrating_from_endpoints) for what the migration preserves, and how the legacy Endpoint API behaves afterward. +- **Day-to-day URL workflows** — see [Working with URLs](../pro__working_with_urls). +- **SBOMs and dependencies** — see [Working with SBOMs](../pro__working_with_sboms). diff --git a/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.md b/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.md new file mode 100644 index 00000000000..ade68c711c5 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.md @@ -0,0 +1,70 @@ +--- +title: "Migrating from Endpoints" +description: "What happens when you migrate existing Endpoint data to Locations" +audience: pro +weight: 3 +--- + +When you enable Locations on an existing DefectDojo Pro instance, the data already stored as Endpoints needs to be carried forward into the new Locations model. This page describes migration, what it preserves, and how the legacy Endpoint API behaves once the migration has run. + +Note that migration is **one-way**. There is no automated rollback path that re-creates Endpoints from Locations. + +## What the Migration Does + +For every existing Endpoint, migration will: + +1. **Creates a URL Location** (or re-uses an existing one) using the Endpoint's `protocol`, `userinfo`, `host`, `port`, `path`, `query`, and `fragment` fields. The new URL is automatically attached to a parent `Location` object. +2. **Carries over tags.** Every tag on the Endpoint is added to the Location's tag set. +3. **Carries over metadata.** Each `DojoMeta` row attached to the Endpoint is re-pointed at the new Location. +4. **Creates a `LocationProductReference`** so the URL appears under the correct Asset (Product). +5. **Creates a `LocationFindingReference` for every `Endpoint_Status`**: + + | Endpoint_Status flag | Resulting Location status | + | --- | --- | + | `risk_accepted=True` | **Risk Accepted** | + | `false_positive=True` | **False Positive** | + | `out_of_scope=True` | **Out of Scope** | + | `mitigated=True` | **Mitigated** | + | (none of the above) | **Active** | + + The mapping is order-sensitive: the *first* matching flag wins. This intentionally collapses the old multi-flag combinations down to the single canonical status that Locations use. + + +## What the Migration Does Not Do + +- It does **not** create Dependency Locations. SBOM and library data has never existed as Endpoints, so there is nothing for the migration to convert. To populate Dependencies, upload SBOMs (see [Working with SBOMs](../pro__working_with_sboms)) or re-run scans with parsers that emit dependency data. +- 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. + +## Endpoint API After Migration + +Once Locations is enabled, the legacy Endpoint API enters a **read-compatibility** mode designed to keep existing automations working without code changes — but only for read traffic. + +### What still works + +- `GET /api/v2/endpoints/` — Returns rows that *look like* Endpoints but are actually projected from Location Product Reference rows joined to URL Locations. The familiar fields (`protocol`, `host`, `port`, `path`, `query`, `fragment`, `tags`, `product`, `active_finding_count`) are all present. +- `GET /api/v2/endpoints/{id}/` — Single-Endpoint retrieval works the same way. The `id` is the original Endpoint ID and is preserved through the migration via the Asset Reference mapping. +- `GET /api/v2/endpoint_status/` and `GET /api/v2/endpoint_status/{id}/` — Returns rows projected from `LocationFindingReference`. The legacy `mitigated`, `false_positive`, `out_of_scope`, and `risk_accepted` boolean fields are reconstructed. +- Filtering by `protocol`, `host`, `port`, `path`, `query`, `fragment`, `product`, and `tag(s)` continues to work. +- The `generate_report` action on individual Endpoints continues to work. + +### What returns 403 + +- `POST`, `PUT`, `PATCH`, and `DELETE` on `/api/v2/endpoints/` and `/api/v2/endpoint_status/` all return `HTTP 403` with the body: + + > Writes to this endpoint are deprecated when V3_FEATURE_LOCATIONS is enabled + + Clients that write Endpoint data must move to the new Reference endpoints (`POST /api/v2/location_findings/`, `POST /api/v2/location_products/`) and to the URL endpoint (`POST /api/v2/urls/`). + +### Behavioural Differences to Watch For + +A few things behave differently from the original Endpoint API: + +- **Single status instead of flags.** Locations have one status at a time. If your code relied on a Finding being *both* `mitigated=True` *and* `false_positive=True` simultaneously on an Endpoint_Status, that is no longer representable — the migration picks the highest-priority flag (the order shown in the table above). +- **`endpoint` field on Endpoint_Status.** The legacy `endpoint` field is reconstructed by looking up the matching Asset Reference. In rare cases where a Finding's Asset no longer matches its Location's Asset references, this field may be null. +- **Pagination and ordering.** Available ordering fields on the read-compat shim are `host`, `product`, `id`, and `active_finding_count`. If your client orders by another field, switch to one of these or move to the new Locations endpoints. + +## Tags and Metadata + +Tags applied to Endpoints become tags on the Location object (not on the URL subtype). Tag-based filters in the legacy API continue to match. + +Endpoint metadata is re-pointed at the Location during migration. Existing automations that read metadata via `/api/v2/endpoint_meta/` should continue to work; new metadata should be written through the Location endpoints. diff --git a/docs/content/asset_modelling/locations/PRO__working_with_sboms.md b/docs/content/asset_modelling/locations/PRO__working_with_sboms.md new file mode 100644 index 00000000000..2ac1995b8ec --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__working_with_sboms.md @@ -0,0 +1,107 @@ +--- +title: "Working with SBOMs" +description: "Manage software dependencies and SBOMs as Locations" +audience: pro +weight: 5 +--- + +DefectDojo Pro models software libraries as **Dependency Locations**. A Dependency is a Location subtype identified by a [Package URL (pURL)](https://github.com/package-url/purl-spec) 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. + +Dependencies replace the previous **Components** model, which was attached only to Findings. With Locations, libraries can exist independently of any vulnerability — you can upload an SBOM to an Asset and then let Findings auto-attach to the dependencies they reference as scans come in. + +## What a Dependency Holds + +Every Dependency is uniquely identified by a pURL, decomposed into atomic fields you can search and filter on: + +| Field | Meaning | Example | +| --- | --- | --- | +| `purl_type` | Library ecosystem | `npm`, `pypi`, `maven`, `cargo`, `nuget`, `gem` | +| `namespace` | Vendor or organisation | `org.apache.logging` | +| `name` | Library name | `log4j-core` | +| `version` | Specific version | `2.17.0` | +| `qualifiers` *(optional)* | Implementation details | `arch=amd64` | +| `subpath` *(optional)* | Path within an archive or monorepo | `src/lib/foo` | +| `artifact_hashes` *(optional)* | Fingerprints | SHA256 sums | +| `license_expression` *(optional)* | SPDX license expression | `Apache-2.0`, `MIT` | +| `file_path` *(optional)* | Where the library was found in the project | `package-lock.json` | + +This atomic decomposition is what makes pURL-based search useful: you can ask *"all `pypi` packages in the `django` namespace at version 4.x"* and DefectDojo can answer that without parsing a free-text string. + +## Owned-By vs Used-By + +When a Dependency is associated with an Asset, the Asset Reference carries an optional **relationship** describing *how* the library belongs to the Asset: + +- **`owned_by`** — *"this library is owned by this Asset"*. Use this for first-party libraries an Asset publishes or maintains. +- **`used_by`** — *"this library is used by this Asset"*. Use this for third-party dependencies an Asset consumes. + +The same library can be `owned_by` one Asset and `used_by` several others, which is exactly the relationship you need to answer *"who consumes the package my team publishes?"* during vulnerability triage. + +## Uploading an SBOM + +To populate Dependencies in bulk, upload an SBOM file against a Product. The endpoint is: + +``` +POST /api/v2/sbom-import/ +``` + +| Field | Description | +| --- | --- | +| `product` | The target Product (Asset) ID | +| `file` | The SBOM file | +| `scan_type` | The SBOM format — see supported formats below | +| `replace` *(optional)* | If `true`, stale Product associations not backed by an existing Finding reference are removed. Default: `false` (cumulative) | + +The importer parses the file, extracts `Dependency` records, deduplicates them against existing Locations (creating new ones as needed), and creates Asset References linking each Dependency to the Product. The Pro UI exposes the same upload flow — see the **Upload SBOM** action on a Product's Locations tab. + +### Supported Formats + +The MVP ships parsers for the two dominant SBOM formats: + +- **CycloneDX** — JSON and XML +- **SPDX** — JSON (v2 and v3), XML, and tag-value + +SWID Tag format is not yet supported. + +### Replace vs Append + +By default, repeated uploads are **additive**: dependencies that already exist on the Asset are kept, new ones are added, and nothing is removed. This matches the typical workflow of incremental SBOM updates. + +Set `replace=true` to prune. When replace mode is on, after a successful import the importer removes Product associations that were not present in the new SBOM **and** are not currently referenced by an active Finding. References tied to active Findings are preserved even in replace mode, so you do not lose vulnerability context just because a new SBOM omits a package. + +## Findings That Reference Libraries + +When a parser ingests a vulnerability tied to a library — for example, an SCA tool reporting `CVE-2021-44228` against `log4j-core@2.14.1` — the importer: + +1. Looks up an existing Dependency Location by pURL, or creates a new one. +2. Creates a `LocationFindingReference` linking the Finding to the Dependency with status **Active**. +3. Creates a `LocationProductReference` so the Dependency also appears on the parent Product, if it isn't already. + +Because Findings and SBOM uploads share the same underlying Dependency objects, a Finding ingested *before* an SBOM upload will be retroactively visible in the SBOM view, and vice versa. + +## REST API + +| Task | Endpoint | +| --- | --- | +| Upload an SBOM | `POST /api/v2/sbom-import/` | +| List Dependencies | `GET /api/v2/dependencies/` | +| Create a Dependency manually | `POST /api/v2/dependencies/` | +| List Dependency Locations | `GET /api/v2/location/?location_type=dependency` | +| Link a Dependency to a Finding | `POST /api/v2/location_findings/` | +| Link a Dependency to a Product (with `owned_by` / `used_by`) | `POST /api/v2/location_products/` | + +Filters on `/api/v2/dependencies/` include the pURL component fields, tags, and ordering on `name`, `version`, and active-finding count. + +## In the Pro UI + +When Locations is enabled, the navigation exposes: + +- **Locations / Dependencies** — Global list of every Dependency across the instance, with pURL filters. +- **Locations on a Product/Asset** — Per-Asset view that shows both URLs and Dependencies, with the **Upload SBOM** action surfaced on the Dependencies tab. +- **New Dependency** — Form to create a single library by entering its pURL components manually. +- **Findings detail** — A Finding that touches a library shows its Dependency Locations alongside any URL Locations, so you can see *"this CVE affects `log4j-core@2.14.1` on Asset 6 and Asset 9"* in one place. + +## What's Not in the MVP + +- **SWID Tag SBOM format** — Not parsed. CycloneDX or SPDX is required. +- **License risk scoring** — The `license_expression` field is captured when present in the SBOM, but DefectDojo does not yet flag findings on license incompatibility. License-based reporting is on the roadmap as a follow-up to the Locations MVP. +- **Container image and cloud resource Locations** — Future Location subtypes. For now, libraries discovered inside a container image are recorded as Dependencies; the container image itself is not yet a first-class Location. diff --git a/docs/content/asset_modelling/locations/PRO__working_with_urls.md b/docs/content/asset_modelling/locations/PRO__working_with_urls.md new file mode 100644 index 00000000000..db7db4b9021 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__working_with_urls.md @@ -0,0 +1,88 @@ +--- +title: "Working with URLs" +description: "Day-to-day use of URL Locations as the Endpoints replacement" +audience: pro +weight: 4 +--- + +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. + +This page covers what changes when you start using URL Locations day-to-day, the new UI surfaces, and the API endpoints to use in place of the legacy Endpoint API. + +## The URL Subtype + +Every URL is a Location. That means a URL has both: + +- The structured URL fields (`protocol`, `user_info`, `host`, `port`, `path`, `query`, `fragment`, plus a `hash` used for de-duplication). +- The shared Location fields (`location_type="url"`, a canonical `location_value` string for display and search, tags, inherited tags, metadata, and Reference links to Assets and Findings). + +When you create or upload a URL, DefectDojo parses it into the structured fields and writes both the URL row and its parent Location row in a single transaction. URL de-duplication is exact-match across the structured fields — two URLs are considered the same if every component matches, with the standard default-port collapsing (`http://example.com:80/` and `http://example.com/` resolve to the same URL). + +## In the Pro UI + +When the Locations feature is enabled, the navigation exposes: + +- **Locations / All** — A list of every Location across both URL and Dependency subtypes. Filter by type, status, Asset, Finding, or tag. +- **Locations / URLs** — A scoped list of URL Locations only. This is the closest analogue to the old Endpoints page. +- **New URL** — A form to create a single URL with structured fields, tags, and optional Asset/Finding associations. +- **Locations on an Asset** — From any Asset, the **Locations** tab shows the URLs and Dependencies attached to that Asset, with status counts and quick actions. + +Common workflows from the Endpoints UI are preserved: + +- **Bulk status updates.** Select multiple URL Locations and apply a status (Active, Mitigated, False Positive, Risk Accepted, Out of Scope) to their Finding references in one action. +- **Adding existing URLs to a Asset.** Use **Add Existing** on a Asset's Locations tab to link URLs already in the system rather than creating duplicates. +- **Tags.** Tags applied to a URL Location propagate as inherited tags on the Findings that reference it, the same way Endpoint tags previously did. + +## Status Model + +URL Locations use the same single-status labels as all other Locations: + +| Status | Meaning | +| --- | --- | +| **Active** | The Finding at this URL is open. | +| **Mitigated** | The Finding has been remediated for this URL. | +| **False Positive** | The Finding is not a real vulnerability for this URL. | +| **Risk Accepted** | The Finding is acknowledged but accepted at this URL. | +| **Out of Scope** | This URL is excluded from the engagement. | + +Note that the old Endpoint Status model allowed multiple flags simultaneously (e.g. `mitigated=True` and `false_positive=True`). Locations enforce one status at a time. If you migrated from Endpoints, the most specific flag was preserved (see the mapping table in [Migrating from Endpoints](../pro__migrating_from_endpoints)). + +Asset References use a simpler status: only **Active** or **Mitigated**, since Asset-level status does not need the auditing detail. + +## REST API + +Use these endpoints in place of the legacy Endpoint API: + +| Task | Endpoint | +| --- | --- | +| List URLs | `GET /api/v2/urls/` | +| Create a URL | `POST /api/v2/urls/` | +| Update a URL's tags or metadata | `PATCH /api/v2/urls/{id}/` | +| List all Locations (URLs + Dependencies) | `GET /api/v2/location/?location_type=url` | +| Link a URL to a Finding | `POST /api/v2/location_findings/` | +| Link a URL to a Asset | `POST /api/v2/location_Assets/` | +| Update a Finding-link's status | `PATCH /api/v2/location_findings/{id}/` | +| Remove a Finding-link | `DELETE /api/v2/location_findings/{id}/` | + +Filters on `/api/v2/urls/` include the structured URL fields plus `tag(s)`, `has_tags`, `Asset`, and ordering by `host`, `Asset`, or active-finding count. + +The legacy `/api/v2/endpoints/` endpoint still serves **read** traffic via a compatibility shim — see [Migrating from Endpoints](../pro__migrating_from_endpoints) for what is preserved and where the shim differs from the original behaviour. **Writes** to the legacy endpoints return `403` and must be moved to the endpoints above. + +## Importing URLs from Scans + +Scanner imports create URL Locations automatically. When a parser emits a URL for a Finding (the same way it used to emit an Endpoint), the importer: + +1. Looks up an existing URL with matching structured fields, or creates one. +2. Creates a Finding Reference linking the Finding to the URL with status **Active**. +3. Creates (or reuses) an Asset Reference so the URL also appears on the parent Asset. + +DefectDojo parsers which previously created Endpoints have been updated to automatically create Locations in Pro. + +## Things That Behave Differently + +A few small behaviour changes are worth noting: + +- **One status per URL/Finding pair.** As described above, the multi-flag Endpoint_Status model is collapsed to a single status. Workflows that toggled flags independently need to pick a single transition. +- **Tags live on the Location, not the URL.** The URL subtype does not carry its own tag set; tags belong to the parent Location. If you read a URL via the API, the `tags` field comes from `location.tags`. +- **De-duplication is per-canonical-URL, not per-Asset.** Two Assets that have the same URL share a single underlying URL Location and reference it twice (one Asset Reference each). This is intentional and is what enables cross-Asset reporting. +- **The `endpoints` field on Findings.** When the flag is on, this field on the Finding API still returns rows, but they are projected from URL Locations rather than from the Endpoint table. Treat it as read-only and write through `/api/v2/location_findings/` instead. diff --git a/docs/content/asset_modelling/locations/_index.md b/docs/content/asset_modelling/locations/_index.md new file mode 100644 index 00000000000..bff8d988629 --- /dev/null +++ b/docs/content/asset_modelling/locations/_index.md @@ -0,0 +1,12 @@ +--- +title: "Locations" +description: "Higher-fidelity asset modelling — URLs, SBOMs, and beyond" +date: 2026-05-06T00:00:00+00:00 +draft: false +type: docs +audience: pro +weight: 4 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/tags/OS__tagging_objects.md b/docs/content/asset_modelling/tags/OS__tagging_objects.md index e9f5f7fcfb3..4dcf74b87fd 100644 --- a/docs/content/asset_modelling/tags/OS__tagging_objects.md +++ b/docs/content/asset_modelling/tags/OS__tagging_objects.md @@ -71,7 +71,7 @@ Tags can be managed in the following ways: ## Tag Inheritance -When Tag Inheritance is enabled, tags applied to a given Product will automatically be applied to all objects under Products in the [Product Hierarchy](/asset_modelling/hierarchy/product_hierarchy/). +When Tag Inheritance is enabled, tags applied to a given Product will automatically be applied to all objects under Products in the [Product Hierarchy](/asset_modelling/os_hierarchy/product_hierarchy/). ### Configuration diff --git a/docs/content/asset_modelling/tags/PRO__tagging_objects copy.md b/docs/content/asset_modelling/tags/PRO__tagging_objects copy.md index bb9e69720b5..a476f53fd89 100644 --- a/docs/content/asset_modelling/tags/PRO__tagging_objects copy.md +++ b/docs/content/asset_modelling/tags/PRO__tagging_objects copy.md @@ -100,7 +100,7 @@ Tags can be managed in the following ways: **Pro UI note: though Tag inheritance can be configured using the Pro UI, inherited Tags currently can only be accessed and filtered for through the Classic UI or the API.** -When Tag Inheritance is enabled, tags applied to a given Product will automatically be applied to all objects under Products in the [Product Hierarchy](/asset_modelling/hierarchy/product_hierarchy/). +When Tag Inheritance is enabled, tags applied to a given Product will automatically be applied to all objects under Products in the [Product Hierarchy](/asset_modelling/os_hierarchy/product_hierarchy/). ### Configuration diff --git a/docs/content/automation/api/api-v2-docs.md b/docs/content/automation/api/api-v2-docs.md index b88e744a0cd..69cec007107 100644 --- a/docs/content/automation/api/api-v2-docs.md +++ b/docs/content/automation/api/api-v2-docs.md @@ -189,7 +189,7 @@ Some of the api wrappers contain quite a bit of logic to ease scanning and impor ## Import Importing via the API is performed via the [import-scan](https://demo.defectdojo.org/api/v2/doc/) endpoint. -As described in the [Product Hierarchy](/asset_modelling/hierarchy/product_hierarchy/), Test gets created inside an Engagement, inside a Product, inside a Product Type. +As described in the [Product Hierarchy](/asset_modelling/os_hierarchy/product_hierarchy/), Test gets created inside an Engagement, inside a Product, inside a Product Type. An import can be performed by specifying the names of these entities in the API request: diff --git a/docs/content/get_started/about/OS__new_user_checklist.md b/docs/content/get_started/about/OS__new_user_checklist.md index cf977048319..b3dd10e6328 100644 --- a/docs/content/get_started/about/OS__new_user_checklist.md +++ b/docs/content/get_started/about/OS__new_user_checklist.md @@ -12,9 +12,9 @@ The essence of DefectDojo is to import security data, organize it, and present i ### DefectDojo Open-Source -1. Open-Source users can start by creating their first [Product Type and Product](/asset_modelling/hierarchy/product_hierarchy/). Once those are created, they can [import a file](/import_data/import_scan_files/os__import_scan_ui/) to one of those Products using the UI. +1. Open-Source users can start by creating their first [Product Type and Product](/asset_modelling/os_hierarchy/product_hierarchy/). Once those are created, they can [import a file](/import_data/import_scan_files/os__import_scan_ui/) to one of those Products using the UI. -2. Now that you have data in DefectDojo, consider expanding your Product layout [Product Hierarchy Overview](/asset_modelling/hierarchy/product_hierarchy/). The Product Hierarchy creates a working inventory of your apps, which helps you divide your data up into logical categories. These categories can be used to apply access control rules, or to segment your reports to the correct team. +2. Now that you have data in DefectDojo, consider expanding your Product layout [Product Hierarchy Overview](/asset_modelling/os_hierarchy/product_hierarchy/). The Product Hierarchy creates a working inventory of your apps, which helps you divide your data up into logical categories. These categories can be used to apply access control rules, or to segment your reports to the correct team. 3. Use the [Report Builder](/metrics_reports/reports/using_the_report_builder/#opening-the-report-builder) to summarize the data you've imported. Reports can be used to quickly share Findings with stakeholders such as Product Owners. diff --git a/docs/content/get_started/about/PRO__new_user_checklist.md b/docs/content/get_started/about/PRO__new_user_checklist.md index 3b6e7b2726d..f037e3365ac 100644 --- a/docs/content/get_started/about/PRO__new_user_checklist.md +++ b/docs/content/get_started/about/PRO__new_user_checklist.md @@ -14,7 +14,7 @@ The essence of DefectDojo is to import security data, organize it, and present i 1. Start by [importing a file](/import_data/import_scan_files/pro__import_scan_ui/) using the UI. This is generally the quickest way to see how your data fits into the DefectDojo model. -2. Now that you have data in DefectDojo, learn more about how to organize it with the [Product Hierarchy Overview](/asset_modelling/hierarchy/product_hierarchy/). The Product Hierarchy creates a working inventory of your apps, which helps you divide your data into logical categories, apply access control rules, sort Findings by [Priority and Risk](/asset_modelling/hierarchy/pro__priority_sla/) or to segment your reports to the correct team. +2. Now that you have data in DefectDojo, learn more about how to organize it with the [Product Hierarchy Overview](/asset_modelling/os_hierarchy/product_hierarchy/). The Product Hierarchy creates a working inventory of your apps, which helps you divide your data into logical categories, apply access control rules, sort Findings by [Priority and Risk](/asset_modelling/pro_hierarchy/priority_sla/) or to segment your reports to the correct team. 3. Check out your [Metrics pages](/metrics_reports/pro_metrics/pro__overview/) which can be used to quickly share Finding reports with key stakeholders. diff --git a/docs/content/get_started/about/about_defectdojo.md b/docs/content/get_started/about/about_defectdojo.md index 1de8d812f78..473ca746e15 100644 --- a/docs/content/get_started/about/about_defectdojo.md +++ b/docs/content/get_started/about/about_defectdojo.md @@ -86,7 +86,7 @@ DefectDojo Inc. hosts a Pro edition of this software for commercial purposes. A * **[CLI Tools](/import_data/pro/specialized_import/external_tools/)** for rapid integration with your systems * **[Additional Project Tracking Integrations](/issue_tracking/intro/intro/)**: ServiceNow, Azure DevOps, GitHub and GitLab * **[Improved Metrics](/metrics_reports/pro_metrics/pro__overview/)** for executive reporting and high-level analysis -* **[Priority And Risk](/asset_modelling/hierarchy/pro__priority_sla/)** to identify the Findings of highest urgency, system-wide +* **[Priority And Risk](/asset_modelling/pro_hierarchy/priority_sla/)** to identify the Findings of highest urgency, system-wide * **Premium Support** and implementation guidance for your organization The Pro edition is available as a cloud-hosted SaaS offering, and is also available for installation on-premises. diff --git a/docs/content/get_started/about/faq.md b/docs/content/get_started/about/faq.md index ab14697cec4..d5855ae494d 100644 --- a/docs/content/get_started/about/faq.md +++ b/docs/content/get_started/about/faq.md @@ -34,7 +34,7 @@ DefectDojo is designed to support and standardize your current security workflow DefectDojo Pro expands on the above workflows further, adding: - An [improved UI](/get_started/about/ui_pro_vs_os/) designed for speed and efficiency when navigating through enterprise-level data volumes. It also includes a dark mode. -- The ability to [pre-triage your Findings](/asset_modelling/hierarchy/pro__priority_sla/) by Priority and Risk, allowing your team to identify and fix your most critical issues first. +- The ability to [pre-triage your Findings](/asset_modelling/pro_hierarchy/priority_sla/) by Priority and Risk, allowing your team to identify and fix your most critical issues first. - A [Rules Engine](/automation/rules_engine/about) to script automated bulk actions and build custom workflows to handle Findings and other objects, no programming experience required. - [Enhanced report and metrics generation capabilities](/get_started/about/ui_pro_vs_os/#new-dashboards) to easily share the security posture of your apps and repos. - [Advanced deduplication settings](/triage_findings/finding_deduplication/pro__deduplication_tuning/) to fine-tune how DefectDojo identifies and manages duplicate findings. @@ -54,7 +54,7 @@ Role and permission assignment generally happens at the Product Type / Product l Whether you’re a one-person security team for a small organization or a CISO overseeing a swath of software projects,you can easily organize [Role-Based Access Control (RBAC)](/admin/user_management/about_perms_and_roles/) in order to properly establish context for each team member and control access to certain parts of Infrastructure. -Generally, role and permission assignment happens at the [Product Type/Product level](/asset_modelling/hierarchy/product_hierarchy/). Each team member can be given a role pertaining to one or more Products or Product Types that governs how they can interact with the vulnerability data within (e.g., read only, read-write, or full control). +Generally, role and permission assignment happens at the [Product Type/Product level](/asset_modelling/os_hierarchy/product_hierarchy/). Each team member can be given a role pertaining to one or more Products or Product Types that governs how they can interact with the vulnerability data within (e.g., read only, read-write, or full control). ## Import Workflows diff --git a/docs/content/get_started/about/ui_pro_vs_os.md b/docs/content/get_started/about/ui_pro_vs_os.md index e01fa48fbef..893cc0c4ea1 100644 --- a/docs/content/get_started/about/ui_pro_vs_os.md +++ b/docs/content/get_started/about/ui_pro_vs_os.md @@ -32,13 +32,13 @@ To access the Pro UI, open your User Options menu from the top-right hand corner 4. Import methods can be found in the Import section: set up [API Connectors](/import_data/pro/connectors/about_connectors/), use the [Add Findings](/import_data/import_scan_files/pro__import_scan_ui/) form to Add Findings, use [Smart Upload](/import_data/pro/specialized_import/smart_upload/) to handle infrastructure scanning tools, or use our external tools—[Universal Importer and DefectDojo CLI](/import_data/pro/specialized_import/external_tools/)—to streamline both the import and reimport processes of Findings and associated objects. -5. The **Manage** section allows you to view different objects in the [Product Hierarchy](/asset_modelling/hierarchy/product_hierarchy/), with views for Product Types, Products, Engagements, Tests, Findings, Risk Acceptances, Endpoints, and Components. There are additional sections for generating reports (Report Builder), using surveys (Surveys), as well as a [Rules Engine](/automation/rules_engine/about/). +5. The **Manage** section allows you to view different objects in the [Product Hierarchy](/asset_modelling/os_hierarchy/product_hierarchy/), with views for Product Types, Products, Engagements, Tests, Findings, Risk Acceptances, Endpoints, and Components. There are additional sections for generating reports (Report Builder), using surveys (Surveys), as well as a [Rules Engine](/automation/rules_engine/about/). 5. The **Settings** section allows you to configure your DefectDojo instance, including your Integrations, License, Cloud Settings, Users, Feature Configuration and admin-level Enterprise Settings. 6. The **Pro Settings** section contains the System Settings, Banner Settings, Notification Settings, Jira Instances, Deduplication Settings, and Authentication Settings, including SAML, OIDC, OAuth, Login, and MFA forms. -7. The Pro UI also has a **new table format**, used in the [Product Hierarchy](/asset_modelling/hierarchy/product_hierarchy/) to help with navigation. Each column can be clicked on to apply a relevant filter, and columns can be reordered to present data however you like. +7. The Pro UI also has a **new table format**, used in the [Product Hierarchy](/asset_modelling/os_hierarchy/product_hierarchy/) to help with navigation. Each column can be clicked on to apply a relevant filter, and columns can be reordered to present data however you like. 8. The table also has a **"Toggle Columns"** menu which can add or remove columns from the table. diff --git a/docs/content/get_started/pro/pro_features.md b/docs/content/get_started/pro/pro_features.md index e9ad78bb9d8..63b304a775b 100644 --- a/docs/content/get_started/pro/pro_features.md +++ b/docs/content/get_started/pro/pro_features.md @@ -22,14 +22,14 @@ See our [Pro UI Guide](/get_started/about/ui_pro_vs_os/) for more information. ### Assets/Organizations -DefectDojo Pro allows for improved organizational visualization for large lists of repositories or other business structures. See [Assets/Organizations documentation](/asset_modelling/hierarchy/pro__assets_organizations/) for details. +DefectDojo Pro allows for improved organizational visualization for large lists of repositories or other business structures. See [Assets/Organizations documentation](/asset_modelling/pro_hierarchy/assets_organizations/) for details. ![image](images/asset_hierarchy_diagram.png) ### Finding Priority DefectDojo Pro can pre-triage your Findings by Priority and Risk, allowing your team to identify and fix your most critical issues first. -See our [Finding Priority Guide](/asset_modelling/hierarchy/pro__priority_sla/) for more details. +See our [Finding Priority Guide](/asset_modelling/pro_hierarchy/priority_sla/) for more details. ### Rules Engine diff --git a/docs/content/import_data/pro/connectors/manage_operations.md b/docs/content/import_data/pro/connectors/manage_operations.md index c965fad55ea..24bddbb0ab2 100644 --- a/docs/content/import_data/pro/connectors/manage_operations.md +++ b/docs/content/import_data/pro/connectors/manage_operations.md @@ -67,7 +67,7 @@ Whenever Sync runs, it will compare the latest scan data against the existing li * If there are new Findings detected, they will be added to the Test as new Findings. * If there are any Findings which aren’t detected in the latest scan, they will be marked as Inactive in the Test. -To learn more about Products, Engagements, Tests and Findings, see our [Product Hierarchy Overview](/asset_modelling/hierarchy/product_hierarchy/). +To learn more about Products, Engagements, Tests and Findings, see our [Product Hierarchy Overview](/asset_modelling/os_hierarchy/product_hierarchy/). ### Running Sync Manually diff --git a/docs/content/import_data/pro/connectors/manage_records.md b/docs/content/import_data/pro/connectors/manage_records.md index 2b605ee3cb2..ff2f933c121 100644 --- a/docs/content/import_data/pro/connectors/manage_records.md +++ b/docs/content/import_data/pro/connectors/manage_records.md @@ -58,7 +58,7 @@ Once a Record is Mapped, DefectDojo will be ready to import your tool’s scans This makes it possible to send scan data from multiple Connectors to the same Product. All of the data will be stored in the same Engagement, but each Connector will store data in a separate Test. -To learn more about Products, Engagements and Tests, see our [Product Hierarchy Overview](/asset_modelling/hierarchy/product_hierarchy/). +To learn more about Products, Engagements and Tests, see our [Product Hierarchy Overview](/asset_modelling/os_hierarchy/product_hierarchy/). ## Record States - Glossary diff --git a/docs/content/metrics_reports/dashboards/Introduction_dashboard.md b/docs/content/metrics_reports/dashboards/Introduction_dashboard.md index 927d27de0e4..288bfbe7444 100644 --- a/docs/content/metrics_reports/dashboards/Introduction_dashboard.md +++ b/docs/content/metrics_reports/dashboards/Introduction_dashboard.md @@ -118,7 +118,7 @@ This section summarizes the Graded performance of each Product in your instance, Finding Counts of each severity are calculated by the tile, but note that Product Grade is only assigned based on Active Findings, so there may be Inactive Findings counted in this table which do not contribute to the Grade. -To understand how grades are calculated, see our guide to **[Product Health Grading](/asset_modelling/hierarchy/product_health_grade/)**. +To understand how grades are calculated, see our guide to **[Product Health Grading](/asset_modelling/pro_hierarchy/product_health_grade/)**. ## Dashboard Configuration diff --git a/docs/content/metrics_reports/dashboards/about_custom_dashboard_tiles.md b/docs/content/metrics_reports/dashboards/about_custom_dashboard_tiles.md index 29cafd5b12e..25b83cf103f 100644 --- a/docs/content/metrics_reports/dashboards/about_custom_dashboard_tiles.md +++ b/docs/content/metrics_reports/dashboards/about_custom_dashboard_tiles.md @@ -13,7 +13,7 @@ Dashboard Tiles are customizable sets of filters for your DefectDojo instance, w Tiles can: * Act as shortcuts for particular sets of Findings, Products, or other objects -* Visualize relevant metrics related a Product, Engagement or other components of the [Product Hierarchy](/asset_modelling/hierarchy/product_hierarchy/) +* Visualize relevant metrics related a Product, Engagement or other components of the [Product Hierarchy](/asset_modelling/os_hierarchy/product_hierarchy/) * Provide alerts on particular activity, track SLA Violations, failing imports or new Critical Findings Tile Filters set a narrower focus for any tile you want to create. Each Tile has a different set of relevant filters which can be selected. @@ -317,7 +317,7 @@ This Tile compares the Product Grade of all Products on your instance, so that y This tile uses a comparison operator (\<, \=, \<\=, \>\=) to track Products which equal, exceed or fail to meet the Product Grade which you want to monitor. ![image](images/About_Custom_Dashboard_Tiles_11.png) -For more information on how Product Grades are calculated, see our article on [Product Health Grading](/asset_modelling/hierarchy/product_health_grade/). +For more information on how Product Grades are calculated, see our article on [Product Health Grading](/asset_modelling/pro_hierarchy/product_health_grade/). #### Example: Track Failing Products diff --git a/docs/content/releases/pro/changelog.md b/docs/content/releases/pro/changelog.md index 1847b8df99d..4c170941c3f 100644 --- a/docs/content/releases/pro/changelog.md +++ b/docs/content/releases/pro/changelog.md @@ -208,7 +208,7 @@ No significant UX changes. #### Dec 8, 2025: v2.53.1 -* **(Assets/Organizations)** Introduced overhaul to Products/Product Types, added the ability to create and diagram relationships between Assets. See [Assets/Organizations documentation](/asset_modelling/hierarchy/pro__assets_organizations/) for details, and information on opting in to the Beta. +* **(Assets/Organizations)** Introduced overhaul to Products/Product Types, added the ability to create and diagram relationships between Assets. See [Assets/Organizations documentation](/asset_modelling/pro_hierarchy/assets_organizations/) for details, and information on opting in to the Beta. * **(Findings)** Added new KEV fields for ransomware, exploits, and date handling. * **(Pro UI)** Added Table Preferences menu, allowing you to store preset lists of columns for each table. @@ -489,7 +489,7 @@ Hotfix release - no significant feature changes. ![image](images/risk_table.png) - **(Pro UI)** Added a link to Universal Importer to the sidebar, which provides access to the [Universal Importer and DefectDojo CLI](/import_data/pro/specialized_import/external_tools/) tools. -- **(Pro UI)** Added smart Prioritization and Risk fields to DefectDojo Pro, which can be used to more easily triage Findings based on the impact of the Product they affect. See [Priority](/asset_modelling/hierarchy/pro__priority_sla/) documentation for more information. +- **(Pro UI)** Added smart Prioritization and Risk fields to DefectDojo Pro, which can be used to more easily triage Findings based on the impact of the Product they affect. See [Priority](/asset_modelling/pro_hierarchy/priority_sla/) documentation for more information. - **(Tools)** Updated Fortify Webinspect parser to handle Fortify's new XML report format. #### Apr 14, 2025: v2.45.1 diff --git a/docs/content/supported_tools/parsers/file/sarif.md b/docs/content/supported_tools/parsers/file/sarif.md index f544eb6f5eb..e9f5ebad0c4 100644 --- a/docs/content/supported_tools/parsers/file/sarif.md +++ b/docs/content/supported_tools/parsers/file/sarif.md @@ -23,7 +23,7 @@ For example: | Dockle | `Dockle` | `Dockle Scan (SARIF)` | | MobSF | `mobsfscan` | `mobsfscan (SARIF)` | -This means that even though all of these tools produce SARIF output and are imported with `scan_type=SARIF`, each tool will create a **distinct Test Type** in DefectDojo. For more information on how report-defined Test Types work, see **[Test Types](/asset_modelling/hierarchy/product_hierarchy#test-types)**. +This means that even though all of these tools produce SARIF output and are imported with `scan_type=SARIF`, each tool will create a **distinct Test Type** in DefectDojo. For more information on how report-defined Test Types work, see **[Test Types](/asset_modelling/os_hierarchy/product_hierarchy#test-types)**. ## Reimporting SARIF Results diff --git a/docs/layouts/_partials/sidebar/render-section-menu.html b/docs/layouts/_partials/sidebar/render-section-menu.html index 2c41e1f437a..e474de66962 100644 --- a/docs/layouts/_partials/sidebar/render-section-menu.html +++ b/docs/layouts/_partials/sidebar/render-section-menu.html @@ -31,6 +31,14 @@ {{- $linkContent = . }} {{- end }} + {{- /* Pro badge for parent pages (from _index.md with child pages) marked audience: pro */ -}} + {{- $proBadge := "" -}} + {{- with $node.Page }} + {{- if and (eq .Params.audience "pro") .Pages }} + {{- $proBadge = `Pro` -}} + {{- end }} + {{- end }} + {{- $ariaCurrent := "" -}} {{- $liClass := "" -}} @@ -47,7 +55,7 @@
  • {{- with $node.Page.Pages }} - {{ $linkContent }} + {{ $linkContent }}{{ $proBadge | safeHTML }}