diff --git a/components/package.json b/components/package.json
index dcbd8aa3673..331c6901feb 100644
--- a/components/package.json
+++ b/components/package.json
@@ -1,6 +1,6 @@
{
"name": "defectdojo",
- "version": "3.3.100",
+ "version": "3.3.200",
"license": "BSD-3-Clause",
"private": true,
"dependencies": {
diff --git a/docker-compose.override.unit_tests.yml b/docker-compose.override.unit_tests.yml
index ba243c56d60..56d46c54865 100644
--- a/docker-compose.override.unit_tests.yml
+++ b/docker-compose.override.unit_tests.yml
@@ -24,6 +24,13 @@ services:
DD_CELERY_BROKER_URL: 'sqla+sqlite:///dojo.celerydb.sqlite'
# No Redis/valkey in unit tests -> default django cache is LocMemCache.
DD_CACHE_URL: ''
+ # Product grading is debounced through a cache marker with a wall-clock window
+ # (dojo.utils.schedule_product_grade). Under the test runner a dispatched grade task
+ # may never run, so a marker would outlive its test and silently skip grading for the
+ # next test whose product gets the same id, and it makes query counts depend on
+ # timing. 0 queues a task per change, as before; the debounce's own unit tests turn
+ # the window on explicitly.
+ DD_PRODUCT_GRADE_DEBOUNCE_SECONDS: '0'
# In-process singleton cache (dojo/caching.py) stays ON for deterministic
# assertNumQueries counts; reset per request (middleware) and per test.
DD_SETTINGS_CACHE_L1_TTL: '30'
diff --git a/docker-compose.override.unit_tests_cicd.yml b/docker-compose.override.unit_tests_cicd.yml
index 862e451fd35..7ae2bd6170f 100644
--- a/docker-compose.override.unit_tests_cicd.yml
+++ b/docker-compose.override.unit_tests_cicd.yml
@@ -43,6 +43,13 @@ services:
DD_TEST_DB_MODE: ${DD_TEST_DB_MODE:-full}
# No Redis/valkey in unit tests -> default django cache is LocMemCache.
DD_CACHE_URL: ''
+ # Product grading is debounced through a cache marker with a wall-clock window
+ # (dojo.utils.schedule_product_grade). Under the test runner a dispatched grade task
+ # may never run, so a marker would outlive its test and silently skip grading for the
+ # next test whose product gets the same id, and it makes query counts depend on
+ # timing. 0 queues a task per change, as before; the debounce's own unit tests turn
+ # the window on explicitly.
+ DD_PRODUCT_GRADE_DEBOUNCE_SECONDS: '0'
# In-process singleton cache (dojo/caching.py) stays ON: a singleton is read
# once per request/test (deterministic assertNumQueries), reset per request
# (middleware) and per test (dojo_test_case setUp).
diff --git a/docs/config/_default/menus/menus.de.toml b/docs/config/_default/menus/menus.de.toml
index ee1c5ecb4b5..9238fdf5d86 100644
--- a/docs/config/_default/menus/menus.de.toml
+++ b/docs/config/_default/menus/menus.de.toml
@@ -85,6 +85,27 @@
pageRef = "/sensei/sensei_reference"
weight = 4
+# Left-hand section sidebar for the Releases chapter (see menus.en.toml).
+[[sidebar_releases]]
+ name = "Open-Source-Upgrades"
+ pageRef = "/releases/os_upgrading"
+ weight = 0
+
+[[sidebar_releases]]
+ name = "Pro-Upgrades"
+ pageRef = "/releases/pro"
+ weight = 1
+
+[[sidebar_releases]]
+ name = "Upgrade auf Kubernetes (Helm)"
+ pageRef = "/get_started/pro/onprem/kubernetes/upgrading_on_kubernetes"
+ weight = 2
+
+[[sidebar_releases]]
+ name = "Upgrade auf Docker Compose"
+ pageRef = "/get_started/pro/onprem/docker_compose/upgrading_on_docker_compose"
+ weight = 3
+
[[social]]
name = "YouTube"
pre = ''
diff --git a/docs/config/_default/menus/menus.en.toml b/docs/config/_default/menus/menus.en.toml
index 26e5aa56bd3..d30d2734144 100644
--- a/docs/config/_default/menus/menus.en.toml
+++ b/docs/config/_default/menus/menus.en.toml
@@ -64,6 +64,31 @@
pageRef = "/sensei/sensei_reference"
weight = 4
+# Left-hand section sidebar for the Releases chapter. Defining this menu
+# replaces the auto-generated releases tree, so it reproduces the two release
+# groups (each auto-expands to its child pages) and then adds the two Pro
+# on-prem upgrade guides so they are discoverable from this panel too. Entries
+# are audience-filtered by the version toggle via each referenced page's audience.
+[[sidebar_releases]]
+ name = "Open Source Upgrades"
+ pageRef = "/releases/os_upgrading"
+ weight = 0
+
+[[sidebar_releases]]
+ name = "Pro Upgrades"
+ pageRef = "/releases/pro"
+ weight = 1
+
+[[sidebar_releases]]
+ name = "Upgrade on Kubernetes (Helm)"
+ pageRef = "/get_started/pro/onprem/kubernetes/upgrading_on_kubernetes"
+ weight = 2
+
+[[sidebar_releases]]
+ name = "Upgrade on Docker Compose"
+ pageRef = "/get_started/pro/onprem/docker_compose/upgrading_on_docker_compose"
+ weight = 3
+
[[main]]
name = "Admin"
url = "/admin/admin_intro/intro/"
diff --git a/docs/config/_default/menus/menus.es.toml b/docs/config/_default/menus/menus.es.toml
index dcbc777a572..66054f24f38 100644
--- a/docs/config/_default/menus/menus.es.toml
+++ b/docs/config/_default/menus/menus.es.toml
@@ -79,6 +79,27 @@
pageRef = "/sensei/sensei_reference"
weight = 4
+# Left-hand section sidebar for the Releases chapter (see menus.en.toml).
+[[sidebar_releases]]
+ name = "Actualizaciones de código abierto"
+ pageRef = "/releases/os_upgrading"
+ weight = 0
+
+[[sidebar_releases]]
+ name = "Actualizaciones Pro"
+ pageRef = "/releases/pro"
+ weight = 1
+
+[[sidebar_releases]]
+ name = "Actualización en Kubernetes (Helm)"
+ pageRef = "/get_started/pro/onprem/kubernetes/upgrading_on_kubernetes"
+ weight = 2
+
+[[sidebar_releases]]
+ name = "Actualización en Docker Compose"
+ pageRef = "/get_started/pro/onprem/docker_compose/upgrading_on_docker_compose"
+ weight = 3
+
[[social]]
name = "YouTube"
pre = ''
diff --git a/docs/config/_default/menus/menus.fr.toml b/docs/config/_default/menus/menus.fr.toml
index bdf3ae97dfb..0676cbf63e8 100644
--- a/docs/config/_default/menus/menus.fr.toml
+++ b/docs/config/_default/menus/menus.fr.toml
@@ -79,6 +79,27 @@
pageRef = "/sensei/sensei_reference"
weight = 4
+# Left-hand section sidebar for the Releases chapter (see menus.en.toml).
+[[sidebar_releases]]
+ name = "Mises à niveau Open Source"
+ pageRef = "/releases/os_upgrading"
+ weight = 0
+
+[[sidebar_releases]]
+ name = "Mises à niveau Pro"
+ pageRef = "/releases/pro"
+ weight = 1
+
+[[sidebar_releases]]
+ name = "Mise à niveau sur Kubernetes (Helm)"
+ pageRef = "/get_started/pro/onprem/kubernetes/upgrading_on_kubernetes"
+ weight = 2
+
+[[sidebar_releases]]
+ name = "Mise à niveau sur Docker Compose"
+ pageRef = "/get_started/pro/onprem/docker_compose/upgrading_on_docker_compose"
+ weight = 3
+
[[social]]
name = "YouTube"
pre = ''
diff --git a/docs/config/_default/menus/menus.it.toml b/docs/config/_default/menus/menus.it.toml
index ca9211fe59b..b733ea21434 100644
--- a/docs/config/_default/menus/menus.it.toml
+++ b/docs/config/_default/menus/menus.it.toml
@@ -79,6 +79,27 @@
pageRef = "/sensei/sensei_reference"
weight = 4
+# Left-hand section sidebar for the Releases chapter (see menus.en.toml).
+[[sidebar_releases]]
+ name = "Aggiornamenti Open Source"
+ pageRef = "/releases/os_upgrading"
+ weight = 0
+
+[[sidebar_releases]]
+ name = "Aggiornamenti Pro"
+ pageRef = "/releases/pro"
+ weight = 1
+
+[[sidebar_releases]]
+ name = "Aggiornamento su Kubernetes (Helm)"
+ pageRef = "/get_started/pro/onprem/kubernetes/upgrading_on_kubernetes"
+ weight = 2
+
+[[sidebar_releases]]
+ name = "Aggiornamento su Docker Compose"
+ pageRef = "/get_started/pro/onprem/docker_compose/upgrading_on_docker_compose"
+ weight = 3
+
[[social]]
name = "YouTube"
pre = ''
diff --git a/docs/config/_default/menus/menus.ja.toml b/docs/config/_default/menus/menus.ja.toml
index a1f7a898c18..5e460bc84e8 100644
--- a/docs/config/_default/menus/menus.ja.toml
+++ b/docs/config/_default/menus/menus.ja.toml
@@ -79,6 +79,27 @@
pageRef = "/sensei/sensei_reference"
weight = 4
+# Left-hand section sidebar for the Releases chapter (see menus.en.toml).
+[[sidebar_releases]]
+ name = "オープンソースのアップグレード"
+ pageRef = "/releases/os_upgrading"
+ weight = 0
+
+[[sidebar_releases]]
+ name = "Pro のアップグレード"
+ pageRef = "/releases/pro"
+ weight = 1
+
+[[sidebar_releases]]
+ name = "Kubernetes（Helm）でのアップグレード"
+ pageRef = "/get_started/pro/onprem/kubernetes/upgrading_on_kubernetes"
+ weight = 2
+
+[[sidebar_releases]]
+ name = "Docker Compose でのアップグレード"
+ pageRef = "/get_started/pro/onprem/docker_compose/upgrading_on_docker_compose"
+ weight = 3
+
[[social]]
name = "YouTube"
pre = ''
diff --git a/docs/config/_default/menus/menus.pt-br.toml b/docs/config/_default/menus/menus.pt-br.toml
index 5b74c33a38e..977594f52d1 100644
--- a/docs/config/_default/menus/menus.pt-br.toml
+++ b/docs/config/_default/menus/menus.pt-br.toml
@@ -79,6 +79,27 @@
pageRef = "/sensei/sensei_reference"
weight = 4
+# Left-hand section sidebar for the Releases chapter (see menus.en.toml).
+[[sidebar_releases]]
+ name = "Atualizações Open Source"
+ pageRef = "/releases/os_upgrading"
+ weight = 0
+
+[[sidebar_releases]]
+ name = "Atualizações Pro"
+ pageRef = "/releases/pro"
+ weight = 1
+
+[[sidebar_releases]]
+ name = "Atualização no Kubernetes (Helm)"
+ pageRef = "/get_started/pro/onprem/kubernetes/upgrading_on_kubernetes"
+ weight = 2
+
+[[sidebar_releases]]
+ name = "Atualização no Docker Compose"
+ pageRef = "/get_started/pro/onprem/docker_compose/upgrading_on_docker_compose"
+ weight = 3
+
[[social]]
name = "YouTube"
pre = ''
diff --git a/docs/config/_default/menus/menus.zh-hans.toml b/docs/config/_default/menus/menus.zh-hans.toml
index 9b4851f477b..6d7abf28db6 100644
--- a/docs/config/_default/menus/menus.zh-hans.toml
+++ b/docs/config/_default/menus/menus.zh-hans.toml
@@ -79,6 +79,27 @@
pageRef = "/sensei/sensei_reference"
weight = 4
+# Left-hand section sidebar for the Releases chapter (see menus.en.toml).
+[[sidebar_releases]]
+ name = "开源升级"
+ pageRef = "/releases/os_upgrading"
+ weight = 0
+
+[[sidebar_releases]]
+ name = "Pro 升级"
+ pageRef = "/releases/pro"
+ weight = 1
+
+[[sidebar_releases]]
+ name = "在 Kubernetes (Helm) 上升级"
+ pageRef = "/get_started/pro/onprem/kubernetes/upgrading_on_kubernetes"
+ weight = 2
+
+[[sidebar_releases]]
+ name = "在 Docker Compose 上升级"
+ pageRef = "/get_started/pro/onprem/docker_compose/upgrading_on_docker_compose"
+ weight = 3
+
[[social]]
name = "YouTube"
pre = ''
diff --git a/docs/content/admin/feature_flags/PRO__feature_flags.md b/docs/content/admin/feature_flags/PRO__feature_flags.md
index 09cbfb45a52..512127c6285 100644
--- a/docs/content/admin/feature_flags/PRO__feature_flags.md
+++ b/docs/content/admin/feature_flags/PRO__feature_flags.md
@@ -62,18 +62,20 @@ The tag is shown only while a restart is actually outstanding. Once the running
**Organization / Asset Relabeling** renames "Product Type" to "Organization" and "Product" to "Asset". It is on by default and toggles from this page like any other feature, but it is worth knowing which parts of DefectDojo it governs:
* The **Pro UI** follows this toggle. The new labels appear on your next page load.
-* The **Classic UI** pages, their URLs, and generated reports take their naming from the `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL` deployment setting (also on by default), which is read when DefectDojo starts. This toggle does not change them, and restarting does not make it change them.
+* The **Classic UI** pages, their URLs, and generated reports take their naming when DefectDojo starts. They follow this toggle after the next restart, in either direction. You do not need to change a deployment setting: DefectDojo reads the stored toggle at start-up and applies it to those surfaces itself.
-The stored toggle was seeded from that deployment setting, so the two agree until you change one of them. If you turn relabeling off here and you also use the Classic UI, set `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL=False` on your deployment and restart so both surfaces match. On [DefectDojo Pro (Cloud)](/get_started/pro/cloud/), contact [DefectDojo Support](mailto:support@defectdojo.com) to have the deployment setting changed.
+Until you restart, the Classic UI keeps the naming the process started with, so it can disagree with the Pro UI for a while. On [DefectDojo Pro (Cloud)](/get_started/pro/cloud/), contact [DefectDojo Support](mailto:support@defectdojo.com) if you need a restart scheduled.
The feature carries a **Restart Recommended** tag on the Feature Flags page for this reason: the naming used outside the Pro UI is fixed when the process starts. The tag shows only while a restart is still outstanding, and clears once you have restarted or toggled the flag back (see [Restart Recommended](#restart-recommended)). Relabeling is cosmetic either way. Database models, field names, and API endpoints are unchanged, so existing automation keeps working. See [Asset Hierarchy](/asset_modelling/pro_hierarchy/asset_hierarchy/).
+The `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL` deployment setting still exists, but only as the value the stored toggle was seeded from on upgrade and as a fallback when the database cannot be reached at start-up. Once the toggle has a stored value, the database owns it.
+
### Locations
**Locations** replaces the legacy Endpoints model: with it on, imports create Location records and the UI and API surface Locations; with it off, imports create Endpoints. It is off by default and is enabled from this page like any other feature, but a few things are worth knowing:
* The **Pro UI** and the **import pipeline** follow this toggle. After you enable Locations, new imports create Locations and the Locations pages appear on your next page load, without a restart.
-* The **Classic UI** pages and the `/api/v2` endpoint/location route wiring are decided from the `DD_V3_FEATURE_LOCATIONS` deployment setting when DefectDojo starts. This toggle does not change them, and restarting does not make it change them. If you use the Classic UI or depend on the `/api/v2` endpoint routes, set `DD_V3_FEATURE_LOCATIONS` to match and restart so every surface agrees. The stored toggle is seeded from that deployment setting on upgrade, so an instance that already ran with `DD_V3_FEATURE_LOCATIONS=True` comes up with the toggle already on (and locked), and the database owns the value from then on.
+* The **Classic UI** pages and the `/api/v2` endpoint/location route wiring are decided when DefectDojo starts. They follow this toggle after the next restart: the `/api/v2/location/` routes (and the `/api/v3/` API) are mounted and listed in the API documentation, and `/api/v2/endpoints/` is served read-compatibly from Locations. You do not need to change a deployment setting. Until you restart, those routes stay as they were when the process started, so `/api/v2/location/` answers 404 in the meantime. The stored toggle is seeded from the `DD_V3_FEATURE_LOCATIONS` deployment setting on upgrade, so an instance that already ran with `DD_V3_FEATURE_LOCATIONS=True` comes up with the toggle already on (and locked); from then on the database owns the value and the setting is only a fallback for when the database cannot be reached at start-up.
* Enabling existing history is not automatic. Your existing data stays as it is until you run the **data-migration suite** that appears under this row once Locations is on: three backfills (endpoints, dependencies, and source-code locations) followed by an identity rehash that unlocks once all three finish. Each is superuser-run, shows progress, is safe to re-run, and can be cancelled while running (it stops at the next batch boundary and can be resumed). Each item can also be **marked complete**, automatically when a run here finishes or by hand for a migration you ran another way, so the page stops prompting you to run it. See [Migrating from Endpoints](/asset_modelling/locations/pro__migrating_from_endpoints/).
Enabling Locations is **self-service and one-way**: once it is on, the toggle locks (shown as **Cannot Be Disabled**), because turning it back off would require reversing the endpoint-to-location data migration, which is not yet supported. The feature carries a **Restart Recommended** tag for the Classic UI / API reason above; as with any such feature, the tag clears once the server has been restarted (see [Restart Recommended](#restart-recommended)).
@@ -125,8 +127,8 @@ Most features are available on both installation types. The exceptions are:
| Feature | Availability | How it is controlled |
| --- | --- | --- |
| Request a New Connector | [DefectDojo Pro (Cloud)](/get_started/pro/cloud/) only | Always on for Cloud instances, and not offered on-premise. No longer listed on the Feature Flags page. |
-| Locations | Both | Feature Flags page for the Pro UI and import pipeline; the Classic UI and `/api/v2` route wiring follow the `DD_V3_FEATURE_LOCATIONS` deployment setting. Enabling is self-service and one-way — once on, it cannot be turned back off. See [above](#locations) and [Locations Overview](/asset_modelling/locations/pro__locations_overview/). |
-| Organization / Asset Relabeling | Both | Feature Flags page for the Pro UI; the Classic UI, its URLs and generated reports follow the `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL` deployment setting. See [above](#organization--asset-relabeling). |
+| Locations | Both | Feature Flags page. The Pro UI and import pipeline follow it right away; the Classic UI and `/api/v2` route wiring follow it after a restart. Enabling is self-service and one-way: once on, it cannot be turned back off. See [above](#locations) and [Locations Overview](/asset_modelling/locations/pro__locations_overview/). |
+| Organization / Asset Relabeling | Both | Feature Flags page. The Pro UI follows it right away; the Classic UI, its URLs and generated reports follow it after a restart. See [above](#organization--asset-relabeling). |
Every other optional feature is toggled directly on the Feature Flags page on both Cloud and On-Premise instances.
diff --git a/docs/content/admin/user_management/PRO__audit_log_index.md b/docs/content/admin/user_management/PRO__audit_log_index.md
index 05fa4e5649c..ffa828ad8b0 100644
--- a/docs/content/admin/user_management/PRO__audit_log_index.md
+++ b/docs/content/admin/user_management/PRO__audit_log_index.md
@@ -87,8 +87,8 @@ attributed to the user who triggered it.
| Rule Filter Entry | ✅ | ✅ | ✅ | |
| Rules Engine Operation | ✅ | ✅ | ✅ | |
| Rules Engine Operation Message | ✅ | ✅ | ✅ | |
-| Rules Engine 2.0 Rule | ✅ | ✅ | ✅ | Node based rules |
-| Rules Engine 2.0 Delivery | ✅ | ✅ | ✅ | Entries in the Deliveries ledger |
+| Triage Engine Rule | ✅ | ✅ | ✅ | Node based rules |
+| Triage Engine Delivery | ✅ | ✅ | ✅ | Entries in the Deliveries ledger |
| Scheduled Task | ✅ | ✅ | ✅ | |
| Scheduled Task Run | ✅ | ✅ | ✅ | |
| Mitigation Policy | ✅ | ✅ | ✅ | |
diff --git a/docs/content/admin/user_management/user_permission_chart.md b/docs/content/admin/user_management/user_permission_chart.md
index 72cfa0f7bae..d7fd1bbcaaa 100644
--- a/docs/content/admin/user_management/user_permission_chart.md
+++ b/docs/content/admin/user_management/user_permission_chart.md
@@ -76,7 +76,7 @@ The majority of Configuration Permissions give users access to certain pages in
| Questionnaires | Access the **Questionnaires \> All Questionnaires** page | Add a new Questionnaire | Edit an existing Questionnaire | Delete a Questionnaire |
| Questions | Access the **Questionnaires \> Questions** page | Add a new Question | Edit an existing Question | n/a |
| Regulations | n/a | Add a Regulation to the **⚙️Configuration \> Regulations** page | Edit an existing Regulation | Delete a Regulation |
-| Rules Engine | Access the **Rules Engine 2.0** sidebar section and everything under it (All Rules, Runs, and Deliveries) | Create a rule, including converting one from the original Rules Engine | Change, enable, schedule, run, replay, or take ownership of an existing rule | Delete a rule |
+| Rules Engine | Access the **Triage Engine** sidebar section and everything under it (All Rules, Runs, and Deliveries) | Create a rule, including converting one from the original Rules Engine | Change, enable, schedule, run, replay, or take ownership of an existing rule | Delete a rule |
| Scheduling Service Schedule | Access the **Scheduling** page | Superuser only | Edit an existing Schedule (change trigger, enable/disable) | Delete a Schedule |
| SLA Configuration | Access the **⚙️Configuration \> SLA Configuration** page | Add a new SLA Configuration | Edit an existing SLA Configuration | Delete an SLA Configuration |
| Test Types | n/a | Add a new Test Type (under **Engagements \> Test Types**) | Edit an existing Test Type | n/a |
diff --git a/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.md b/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.md
index a3811915a8a..e5eb7324bdb 100644
--- a/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.md
+++ b/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.md
@@ -26,9 +26,9 @@ Asset Hierarchy is generally available and on for every instance, Cloud and On-P
Label changes are on by default as of 3.0. There are two controls, covering different parts of the application:
* **Pro UI** (the default UI): a superuser toggles "Organization / Asset Relabeling" at **Settings > Feature Flags**, on both Cloud and On-Premise instances. The new labels appear on the next page load. See [Feature Flags](/admin/feature_flags/pro__feature_flags/).
-* **Classic UI pages and generated reports**: their labels and URLs come from the `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL` deployment setting, which is read when DefectDojo starts. On-premise, set it and restart DefectDojo. On [DefectDojo Pro (Cloud)](/get_started/pro/cloud/), email [support@defectdojo.com](mailto:support@defectdojo.com) with your instance URL.
+* **Classic UI pages and generated reports**: their labels and URLs are decided when DefectDojo starts, so they follow the same toggle after the next restart. On-premise, restart DefectDojo after changing the toggle. On [DefectDojo Pro (Cloud)](/get_started/pro/cloud/), email [support@defectdojo.com](mailto:support@defectdojo.com) with your instance URL if you need a restart scheduled.
-Both default to on, and the Feature Flags value was seeded from the deployment setting, so the two agree unless you change one of them. Keep them in sync if you use the Classic UI as well as the Pro UI.
+The toggle is on by default. Its stored value was seeded from the `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL` deployment setting on upgrade; from then on the database owns it, and the setting is only a fallback for when the database cannot be reached at start-up.
Note that label changes are cosmetic only: API endpoints and field names remain unchanged, so existing automation will continue to work.
@@ -181,6 +181,17 @@ Where an Asset's parent has not been loaded, a **Load Parents** button appears a
Where an Asset has more children than the diagram is currently showing, a **Load** button appears below it, together with a choice of how many to add at a time.
+## Suggested edges from container evidence
+
+When [Container Image Locations](/asset_modelling/locations/pro__container_image_locations/) are enabled, DefectDojo can notice a deployment relationship nobody has drawn: an image whose repository belongs to one asset is seen running in another, and no **deploys to** edge joins the two. Each such pair appears as a **suggested edge** on the hierarchy page, with the images as evidence.
+
+- A banner at the top of the page counts the open suggestions. **Review** opens the list.
+- **Accept** draws the deploys-to edge from the asset that built the image to the asset that runs it. Because deploys-to propagates exposure, the deployed asset then inherits its host's exposure when you read it; finding priority is unaffected, since it runs on the asset's own exposure.
+- **Dismiss** suppresses the pair. Further images for the same pair are counted but do not reopen it. A dismissed suggestion can be reopened from the same dialog.
+- Accepted edges carry their own origin (container evidence), so they can be told apart from edges people drew and from connector-declared ones.
+
+Suggestions are never accepted automatically, and they are only offered within one organization while deploys-to stays a same-organization relationship. Reviewing requires the Asset Hierarchy view permission; deciding requires the edit permission plus edit access to both assets.
+
## Notes
* Note that deduplication scopes have not changed; Assets only deduplicate Findings within themselves, and do not consider Findings in other Assets, regardless of Parent/Child relationships.
diff --git a/docs/content/asset_modelling/PRO_hierarchy/framework_presets.md b/docs/content/asset_modelling/PRO_hierarchy/framework_presets.md
new file mode 100644
index 00000000000..3d1e8c07713
--- /dev/null
+++ b/docs/content/asset_modelling/PRO_hierarchy/framework_presets.md
@@ -0,0 +1,65 @@
+---
+title: "Framework Presets"
+description: "Apply a published scheme's patch windows and scan cadence as one preset, preview the plan first, and revert it later"
+weight: 3
+audience: pro
+---
+
+Most of what a framework asks of vulnerability management is a number: patch critical flaws within 14 days, or within 48 hours when an exploit exists, and scan weekly or fortnightly. A framework preset bundles those numbers as DefectDojo Pro settings: SLA configurations, scan cadence policies, a response policy and a set of checks, named after the scheme and the version of it they encode. You apply a preset in one step after previewing exactly what it would change, and you can revert it later.
+
+Framework presets are released behind the Framework Presets feature flag. An administrator turns it on from the Feature Flags page. Until then the Framework Presets settings page and its API answer with a 403.
+
+A preset encodes DefectDojo's reading of a published scheme at a point in time. Confirm the current requirements with the scheme's publisher or with your assessor before relying on the numbers. Applying a preset is not certification, and it does not decide compliance.
+
+## What a preset contains
+
+A preset has four sections. Each entry has a stable id so that applying the same preset again can find what it created the first time.
+
+- SLA configurations: a name, the day counts and enforcement flags per severity, and the Pro extension fields such as the SLA start policy, the CISA KEV cap and the VDR tiers. A severity the scheme is silent about keeps the day count of your default SLA configuration.
+- Scan cadence policies: how often each class of asset should be scanned. These are installed disabled, for you to switch on. On a release without scan cadence policies the plan lists them as skipped.
+- A response policy: the timeframes severity alone cannot express, such as 48 hours when an exploit exists or when the service is internet-facing. On a release without vulnerability response policies the plan lists it as skipped.
+- Checks: questions the scheme wants answered, such as how many active Critical and High findings are older than the patch window. A check names something DefectDojo can count. Where the instance lacks the data, for example vendor support levels on components, the check says the answer is manual.
+
+A preset is data. It contains numbers, names and references to checks that exist in DefectDojo, never code, and every preset is validated against a schema before it is stored.
+
+## The two shipped presets
+
+**UK Cyber Essentials** encodes the security update management control of the Cyber Essentials requirements for IT infrastructure, version 3.2 (April 2025), published by the National Cyber Security Centre. The scheme asks that updates fixing vulnerabilities the vendor rates critical or high risk, or with a CVSS v3 base score of 7 or above, are applied within 14 days of release, and that software the vendor no longer supports is removed from scope. The preset installs one SLA configuration named UK Cyber Essentials with 14 day Critical and High windows, enforced, and Medium and Low left at your default day counts and not enforced. It adds one disabled scan cadence policy for a scan at least every 30 days, and two checks: unsupported components present, and active Critical and High findings older than 14 days. Review how each of your scanners maps severity onto the CVSS threshold before relying on the window.
+
+**Australian Essential Eight** encodes the patch applications and patch operating systems strategies of the Essential Eight Maturity Model, November 2023, published by the Australian Signals Directorate. The model sets windows by asset class and by whether an exploit exists rather than by severity, so the preset uses severity as a proxy and says so in its notes. It ships three variants, one per maturity level, and you pick the level you are targeting instead of editing numbers. Maturity Level One installs an SLA configuration with two week Critical and High windows and leaves Medium and Low at your defaults. Maturity Levels Two and Three add a one month window for Medium and Low. All three install disabled scan cadence policies at the level's frequency: daily for internet-facing services, fortnightly or weekly for applications that handle untrusted content, and fortnightly for other assets from Level Two. The 48 hour rule lives in the response policy: internet-facing services when an exploit exists or the vendor rates the vulnerability critical, and at Level Three the same rule for applications that handle untrusted content. Tag those applications, such as browsers, office suites, email clients, PDF readers and security products, with the handles-untrusted-content tag so the cadence policy and the check for them apply.
+
+## Plan, then apply
+
+Applying is a two step process, and nothing is written until you have seen the plan.
+
+1. Open Settings, then Framework Presets, and choose Apply on a preset. For the Essential Eight, pick the maturity level first.
+2. Choose Preview plan. The plan lists every item the preset contains and what applying would do to it: create it, update it, leave it because it conflicts with something already there, or skip it and why. An update or a conflict shows the current and the proposed values side by side.
+3. Confirm that you have reviewed the plan, then choose Apply this plan. The plan runs as one transaction: either every item in it is applied or none is.
+
+An item is a conflict when an SLA configuration with the same name already exists with different values and was not created by this preset. The plan shows both sets of values, the configuration is left untouched, and the application is recorded as partially applied. Compare the two and decide by hand. An item this preset created earlier is updated rather than treated as a conflict, so applying a preset again after a hand edit restores its numbers.
+
+If something changes between the preview and the apply, for example a configuration with the same name appears, DefectDojo refuses to apply and asks you to build the plan again.
+
+## Why applying does not reassign assets
+
+Applying a preset creates SLA configurations and tells you which ones it created. It never moves an asset onto one of them. Changing every deadline in a live instance is a decision for the people who own those assets, so after applying, point the assets that should follow the scheme at the new SLA configuration from each asset's edit page, or through the criticality to SLA mapping if you use it.
+
+## Revert
+
+Revert undoes an application. Configurations the application created are deleted, and configurations it updated are restored to the values they had before. Two kinds of row are listed and left alone: a configuration someone edited by hand after it was applied, and a configuration an asset now points at. The history shows what was reverted and what was left, with the reason.
+
+## Drift
+
+Once a week DefectDojo compares each applied preset against the current settings. When an SLA configuration a preset installed no longer matches what the preset wrote, for example because someone changed a day count by hand, the application is marked as drifted and the field that moved is named in its history entry. The Framework Presets page shows a single banner while any applied preset has drifted. Drift is a state, not an event: no notification is sent.
+
+## Versions
+
+A preset records the publication version it encodes. When a scheme is revised, DefectDojo ships the revision as a new preset that supersedes the old one rather than changing the old preset in place, so a configuration you applied never changes underneath you at upgrade time. The gallery shows which preset replaces a superseded one, and previewing the newer version shows the differences.
+
+## Export and import
+
+Any preset can be exported as a JSON file and imported into another instance, which is how a configuration moves from a staging instance to production, and how a customer specific bundle can be delivered without a screen share. An imported preset is a custom preset: it can be edited or deleted, and its key must not already exist on the receiving instance. Bundled presets are read only; export one and import the copy under a new key to customise it.
+
+## API
+
+The public API exposes the same operations under `/api/v2/`. A preset is planned with `POST /api/v2/framework_presets/{id}/plan/`, which returns the plan as an application record, and applied with `POST /api/v2/framework_presets/{id}/apply/`, passing the id of that record. Checks are answered by `GET /api/v2/framework_presets/{id}/checks/`. The history is at `/api/v2/preset_applications/`, with `POST /api/v2/preset_applications/{id}/revert/` to revert one. Export is `GET /api/v2/framework_presets/{id}/export/` and import is `POST /api/v2/framework_presets/import/`. Reading needs the view permission on SLA configurations; planning, applying and importing need the add and change permissions; reverting needs the delete permission as well.
diff --git a/docs/content/asset_modelling/PRO_hierarchy/priority_sla.md b/docs/content/asset_modelling/PRO_hierarchy/priority_sla.md
index ee999f00350..eb126f0f381 100644
--- a/docs/content/asset_modelling/PRO_hierarchy/priority_sla.md
+++ b/docs/content/asset_modelling/PRO_hierarchy/priority_sla.md
@@ -341,6 +341,151 @@ does not restart the countdown. A long-open Finding that moves into a stricter
can therefore go into breach immediately; this is deliberate, as the time the Finding has
already been open counts against the tighter deadline.
+## Vulnerability response policies
+
+Some frameworks do not let you choose your own remediation windows. They publish a table,
+and a deadline is whatever that table says for the combination of facts that describe the
+finding. FedRAMP is the clearest example: its 2026 rules set a maximum response time for
+every combination of potential agency impact, whether the affected asset is reachable from
+the internet, whether exploitation is credible, and which certification class the service
+holds.
+
+A **response policy** holds one published table as data. It records which standard it came
+from, which version of that standard, when that version took effect, and the vocabulary the
+standard grades impact in. Its rows are the individual cells of the table.
+
+Policies are optional. An SLA configuration with no policy attached behaves exactly as it
+always has, and attaching one is a deliberate choice made per SLA configuration.
+
+### Attaching a policy
+
+A response policy is selected on the SLA configuration, alongside the severity or risk days.
+Two fields matter:
+
+* The **Vulnerability Response Policy** field chooses which published table governs findings
+ under this SLA configuration. Leaving it empty keeps the existing behaviour.
+* The **Authorization Level** field states which authorization or certification level the
+ service holds under that standard. Most published tables give different deadlines to
+ different levels, so a policy produces no deadline at all until this is set. DefectDojo
+ logs a warning when a policy needs a level and none is set.
+
+DefectDojo ships the FedRAMP Vulnerability Detection and Response table for 2026. It is
+seeded on startup and is never attached to anything automatically.
+
+### How a deadline is composed
+
+A response policy tightens a deadline. It never extends one. The remediation date a finding
+ends up with is the earliest of:
+
+* the days allowed for its severity or its risk, from the SLA configuration
+* the CISA KEV due date, when capping by that date is enabled
+* the cell the response policy resolves the finding into
+
+Because every step takes the earliest date, attaching a policy can only bring a deadline
+forward. A finding whose policy cell is more generous than its severity window keeps the
+severity window.
+
+### The three facts a policy grades on
+
+Each finding carries three facts, and each one records where its value came from.
+
+**Adverse impact** is the standard's own rating of what the vulnerability would do to the
+organizations relying on the service. DefectDojo takes it from a value someone set by hand,
+then from a rule, then from the finding's existing impact rating where the policy uses the
+same vocabulary, and finally from a mapping out of severity that is configured on the policy
+itself. Severity is last on purpose. It describes the flaw rather than the consequences, so
+it is a starting point to correct rather than an answer.
+
+**Internet reachability** is whether the affected asset can be reached from outside. This is
+not the same question as reachability analysis, which asks whether vulnerable code can be
+reached inside an application. DefectDojo takes it from a value someone set by hand, then
+from the asset's exposure verdict, then from a configurable tag on the finding.
+
+**Credible exploitability** is whether exploitation is realistic rather than theoretical.
+DefectDojo takes it from a value someone set by hand, then from a CISA KEV listing, then from
+an EPSS score at or above the configured threshold, then from threat intelligence showing a
+weaponized exploit. A proof of concept on its own is not enough.
+
+A value set by hand is never replaced by a later recalculation. The same applies to a value
+set by a rule, because that is an automation the customer configured rather than one
+DefectDojo inferred.
+
+### Facts nobody has established
+
+Reachability can end up unknown. Nothing proves that an asset cannot be reached from the
+internet just because no evidence of exposure was found, so DefectDojo distinguishes "not
+established" from "established as not reachable". Only a person marking an asset as isolated
+settles the question in the negative.
+
+When a fact is unknown, DefectDojo resolves the finding as if it held whichever value the
+policy treats more urgently, and records that it did so. An unmeasured fact can never earn a
+finding more time.
+
+### The evaluation clock
+
+Publishing a deadline is only half of what these frameworks ask for. They also ask that every
+vulnerability be looked at quickly, and that you can show it was. A response policy therefore
+carries an evaluation window as well as a timeframe table, measured in days from the date the
+finding was detected, and different authorization levels usually get different windows.
+
+A finding counts as evaluated once somebody establishes one of the three facts. There is no
+separate confirmation step, because deciding that a finding is internet reachable, or rating its
+adverse impact, is the judgment the framework is asking for. DefectDojo records when that happened
+and, where a person did it rather than a rule, who.
+
+Findings whose window has passed without an evaluation appear in the unevaluated queue. Once a day
+DefectDojo sends one notification per asset listing how many of its findings are overdue. One per
+asset, not one per finding: a window measured in days will sometimes produce hundreds of overdue
+findings at once, and an alert for each would bury the thing it exists to raise. The notification
+goes to the asset's members and its organization's members.
+
+Only open findings are counted. A finding that was closed without ever being evaluated is worth
+knowing about in a report, but it is not something anyone can still act on, and leaving it in a
+daily queue would make the queue permanently dirty.
+
+### Rules can do the routine evaluations
+
+A window measured in days is hard to meet by hand across a large estate, so the rules engine has a
+**Set a vulnerability response fact** action. It sets one of the three facts, records that a rule
+was the source, and stamps the evaluation clock in the same step.
+
+The intended shape is a rule that answers the cases your scanners already have evidence for, so
+that the findings left for a person are the ones that need a judgment. A rule never overwrites a
+value somebody set by hand, and a rule running every night does not keep moving the recorded
+evaluation time on findings it has already seen.
+
+### Escalation
+
+Some frameworks treat a particular combination of facts as an incident rather than as a
+vulnerability, and expect it to be handled as one until it is brought back below that line. The
+condition is part of the policy, so it can differ between standards and between versions of the
+same standard.
+
+DefectDojo flags a finding that meets its policy's escalation condition and lists it in a separate
+queue. The flag clears on its own when the finding stops meeting the condition, which usually means
+its impact has been mitigated down a level. The record that it was escalated, and when, is kept
+after the flag clears, because the fact that it happened is part of what a reviewer asks about.
+
+There is no separate incident record to manage. A flag and a filtered view are what the frameworks
+actually require, and the process that follows an escalation already lives in whatever incident
+tooling you use.
+
+### Versions
+
+A new release of a standard arrives as a new policy rather than as an edit to the one already
+in use. Findings judged under an earlier release keep the version that produced their
+deadline, so an assessor can still be shown which published table a given date came from.
+Seeding never overwrites a policy that already exists, so any changes made to a shipped
+policy survive upgrades.
+
+Editing a policy, or any of its cells, recalculates the findings it governs, in the same way
+that changing the days on an SLA configuration does.
+
+The FedRAMP table DefectDojo ships reflects one published version of that standard. Confirm
+which version applies to your own authorization before relying on it, and note that the table
+publishes no deadline for the lowest impact rating, so findings at that rating keep their
+severity or risk window.
+
## Notes on SLAs
* SLAs can be optionally restarted once a [Risk Accepted](/triage_findings/findings_workflows/pro__risk_acceptance/) Finding reactivates. This is set when creating the Risk Acceptance by setting the **Restart SLA Expired** field.
diff --git a/docs/content/asset_modelling/engagements_tests/PRO__findings.md b/docs/content/asset_modelling/engagements_tests/PRO__findings.md
index abd09fcf052..df2980129b9 100644
--- a/docs/content/asset_modelling/engagements_tests/PRO__findings.md
+++ b/docs/content/asset_modelling/engagements_tests/PRO__findings.md
@@ -77,10 +77,11 @@ Mitigation policies can be found and edited in the sidebar under **Configuration
- Unlike the Unique ID From Tool, this identifier is not unique to an individual Finding and may appear on many Findings that match the same detection rule.
- Unlike Vulnerability IDs, these identifiers are specific to the reporting tool and are not publicly standardized.
- Example: `semgrep.rule.lang.security.sql-injection`
-- **EPSS Score / Percentile**: ESS score and percentile for the CVE.
+- **EPSS Score / Percentile**: EPSS score and percentile for the CVE.
- **Known Exploited**: Whether there is confirmation that the vulnerability has been exploited.
- **Ransomware Used**: Whether ransomware was involved in the exploitation of the vulnerability.
- **KEV Date**: The date the Finding was added to the KEV catalog.
+ - The EPSS and KEV values are maintained by the [EPSS / KEV sync](/triage_findings/finding_scoring/epss_kev/). They can also be set by hand in the **Threat Intelligence** panel of the Add and Edit Finding forms; on a Finding that references a CVE, the next sync overwrites what was entered.
- **Found By**: The type of tool that identified the vulnerability.
- **CVSSv3 and CVSSv4 Vector and Score**: The CVSS3 and CVSS4 vector and score of the selected Finding.
- **Integrator Tickets**: Third-party issue tracker ticket numbers associated with the Finding.
diff --git a/docs/content/asset_modelling/engagements_tests/PRO__pci_dss_scope.md b/docs/content/asset_modelling/engagements_tests/PRO__pci_dss_scope.md
new file mode 100644
index 00000000000..13fd4adcbc3
--- /dev/null
+++ b/docs/content/asset_modelling/engagements_tests/PRO__pci_dss_scope.md
@@ -0,0 +1,65 @@
+---
+title: "PCI DSS Scope and Patch Clocks"
+description: "Record PCI DSS scope per Asset, run the Requirement 6.3.3 patch clock, and export a scope inventory"
+audience: pro
+weight: 8
+---
+
+The PCI DSS scope features let an organization record how each Asset relates to its cardholder data environment, run a patch clock that matches the Requirement 6.3.3 timeline, and export the scope inventory an assessor asks for under Requirement 12.5.1. These features are additive: they record the entity's own determinations and never decide compliance, which remains the assessor's judgment.
+
+The PCI DSS scope features, including their API endpoints, are released behind a feature flag. An administrator turns it on per instance from the Feature Flags page before it is generally available. Until then the regulatory profile and inventory endpoints answer with a 403.
+
+## PCI DSS scope on an Asset
+
+Each Asset can carry a regulatory profile that records its PCI DSS facts:
+
+- **PCI DSS scope**: whether the Asset is in the cardholder data environment, connected to or security-impacting it, or out of scope. This is the Requirement 12.5.1 scoping determination.
+- **Component kind**: how the Asset is classified for the Requirement 6.3.2 software inventory, as bespoke or custom software, third-party software, a system component, or a payment page.
+- **Public-facing web application**: whether the Asset is a public-facing web application, which is what Requirements 6.4.1 and 6.4.2 turn on. Left unset, this is derived from the Asset being internet accessible and having an external audience. Set it explicitly to override that derivation.
+- **Assessment anchor date**: the date the assessment year is anchored to, which sets the start of the Requirement 11 quarterly scan calendar. Left unset, it defaults to 1 January of the current year.
+
+The profile also records when scope was last confirmed and by whom. Use **Confirm Scope Today** to record a confirmation, which supports the Requirement 12.5.2 review cadence (at least every 12 months, or every 6 months for a service provider).
+
+The profile is created the first time it is saved for an Asset, so an Asset that has never been assessed simply reads as not assessed.
+
+## Entity type
+
+The instance records whether the organization is assessed under PCI DSS as a merchant, a service provider, both, or unspecified. This setting lives in the system settings. Service providers confirm scope and test network segmentation every six months rather than annually, so several PCI cadence checks read this value.
+
+## The Requirement 6.3.3 patch clock
+
+DefectDojo Pro seeds an SLA configuration named **PCI DSS 6.3.3** that encodes the Requirement 6.3.3 timeline: critical and high-severity items are due within one month, and medium and low items follow a timeframe set by a targeted risk analysis (Requirement 12.3.1), so they are recorded but not enforced.
+
+This configuration is seeded once and is never made the default and never assigned to an Asset automatically. To apply it, assign it to an Asset the same way as any other SLA configuration.
+
+### SLA start policy
+
+Requirement 6.3.3 runs the one-month clock from when a patch was released, not from when the finding happened to be detected. Each SLA configuration therefore carries an **SLA start policy** that chooses which date the clock starts from:
+
+- **Detection date**: the default, and the same behavior as before. The clock starts when the finding was found.
+- **Vulnerability publish date**: the clock starts when the vulnerability was published.
+- **Fix-available date**: the clock starts when a fix became available.
+- **Earliest known**: the clock starts from the earliest of the dates above.
+
+A computed start that would fall after the detection date is clamped to the detection date, so a policy can only tighten the clock, never lengthen it. A start date set by hand, through the finding edit form or the API, is authoritative and the policy never overrides it; clearing it hands the start back to the policy. A start date that was already in place before a policy was chosen is treated the same way. Changing a configuration's policy recalculates the start and expiration dates of the findings already under it, in the background.
+
+The default detection date policy changes nothing about how a finding's dates are set today.
+
+The fix-available date comes from a scanner or connector that reports a fixed version's release date (mapped through the universal parser). When no such date is known, the fix-available policy falls back to the detection date.
+
+## Targeted risk analyses
+
+PCI DSS Requirement 12.3.1 asks for a targeted risk analysis behind each frequency or timeframe an entity chooses for itself, such as the medium and low patch windows under Requirement 6.3.3. The **Targeted Risk Analyses** page records these:
+
+- Each analysis cites the requirement it justifies (for example 6.3.3, 11.3.1.1, or an Appendix A reference such as A3.2.1), names what is protected and the threats, the likelihood and impact, and the decision reached.
+- An analysis is scoped to one Asset, to one Organization, or left entity-wide, and can be linked to the SLA configuration whose frequency it justifies. The scope is fixed when the analysis is created. Members of the Asset or Organization can read it; editing it takes the same permission as editing the Asset or Organization, and entity-wide analyses are managed by administrators.
+- An analysis moves from draft to approved, and an approved analysis can be superseded. Approving it records who approved it and sets a review-due date 12 months out, since Requirement 12.3.1 asks for review at least every 12 months. A superseded analysis stays closed; record a new draft to replace it.
+- A weekly check alerts the people responsible (the Asset's or Organization's members, or administrators for an entity-wide analysis) when an approved analysis is due for review within 30 days, again when it becomes overdue, and then monthly while it stays overdue.
+
+## Scope inventory export
+
+The scope inventory export produces the list an assessor reviews under Requirement 12.5.1. It returns every Asset the user is authorized to view, with its scope, component kind, public-facing flag, business criticality, SLA configuration, owner, and the date scope was last confirmed, as a CSV file.
+
+## Filtering by scope
+
+The Asset list can be narrowed by PCI DSS scope and by component kind, so an assessor or owner can pull up, for example, only the Assets in the cardholder data environment. An Asset whose scope has never been recorded counts as not assessed, so filtering for not assessed lists everything still waiting on a determination.
diff --git a/docs/content/asset_modelling/engagements_tests/PRO__pci_scan_evidence.md b/docs/content/asset_modelling/engagements_tests/PRO__pci_scan_evidence.md
new file mode 100644
index 00000000000..5194822abfa
--- /dev/null
+++ b/docs/content/asset_modelling/engagements_tests/PRO__pci_scan_evidence.md
@@ -0,0 +1,74 @@
+---
+title: "PCI DSS Scan and ASV Evidence"
+description: "Record which tests are PCI scans, track the Requirement 11 quarterly and annual evidence, and export the grid an assessor asks for"
+audience: pro
+weight: 9
+---
+
+PCI DSS Requirement 11 asks an entity to scan on a cadence and to keep the evidence: internal vulnerability scans every quarter, a passing external ASV scan every quarter, penetration tests every year, and segmentation testing on the same yearly cadence or every six months for a service provider. DefectDojo already holds the scans. These features record the few facts a scan report cannot carry, work out where each quarter stands, and produce the grid and workbook an assessor reviews.
+
+DefectDojo records the ASV results an entity reports. It does not perform ASV scans, it is not an Approved Scanning Vendor, and it does not validate an attestation. A passing ASV result is never inferred from an absence of findings; someone records it, or the quarter reads as outstanding.
+
+The scan evidence UI is released behind a feature flag. An administrator turns it on per instance from the Feature Flags page before it is generally available.
+
+## Which tests count as which kind of scan
+
+A test plays a PCI role. The role comes from the test type, so a scanner that is always an internal vulnerability scan is classified once rather than per test:
+
+- **Internal vulnerability scan**: the Requirement 11.3.1 quarterly internal scan.
+- **External ASV scan**: the Requirement 11.3.2 quarterly external scan performed by an Approved Scanning Vendor.
+- **Web application assessment**: an application scan, which supports Requirement 6.4.
+- **Penetration test**: a Requirement 11.4 penetration test delivered as a test rather than an engagement.
+- **Segmentation test**: a Requirement 11.4.5 or 11.4.6 test of segmentation controls.
+
+Common scanner names are classified on first run, and the classification only fills a role that has not been set, so it never overwrites a choice someone made. A single test can override its type's role when one scanner is used for two purposes.
+
+## Facts a scan report does not carry
+
+Some of what an assessor asks about is not in the scan file. These are recorded on the test:
+
+- **Authenticated**: whether the scan ran with credentials, as Requirement 11.3.1.2 asks. The three answers are yes, no, and unknown. Unknown is never treated as authenticated.
+- **ASV result**: pass, fail, or not applicable, along with the **ASV vendor** and the **attestation reference**. This is the entity's record of what the ASV reported.
+- **After a significant change**: links the scan to the change that required it, for Requirements 11.3.1.3 and 11.3.2.1.
+- **Note**: anything a reader of the evidence needs to know about this scan.
+
+These can be set on the test edit form, through the API, or supplied with the scan at import and reimport time, so a pipeline that already uploads results can record the evidence in the same call. A reimport that says nothing about them leaves the earlier answers alone.
+
+Engagements carry the penetration testing facts: the **kind** of test (internal, external, application, or segmentation), a link to the engagement that **retested** its findings, and a **methodology reference**.
+
+## Significant changes
+
+A significant change is what makes Requirements 11.3.1.3 and 11.3.2.1 apply: after one, the entity scans again rather than waiting for the next quarter. Record the change with its date, what changed, and which scans it requires (internal, ASV, penetration test). A change is covered when a test of each required role is linked to it, or is dated within the window after it. That window is 30 days by default.
+
+## Unauthenticated system exceptions
+
+Requirement 11.3.1.2 allows a system that cannot accept credentials, provided the entity documents why and what compensates for it. Record the system, the reason, the compensating control, who documented it and when, and the date the exception is next reviewed. An unauthenticated scan covered by an exception reads as needing attention rather than as satisfied, so the exception is visible to an assessor rather than hidden by it.
+
+## The quarterly grid
+
+The **PCI Scan Evidence** page shows one Asset's assessment year as four quarters, with a row per check. Quarters are counted from the Asset's assessment anchor date, not from 1 January, because an assessor counts from the assessment date. Each cell is a verdict with the evidence behind it, and opens to show the tests and findings it rests on.
+
+| Check | Requirement | Satisfied when |
+|-------|-------------|----------------|
+| Internal scan performed | 11.3.1 | At least one internal vulnerability scan falls in the quarter |
+| Scans authenticated | 11.3.1.2 | Every internal scan in the quarter ran authenticated, or each unauthenticated one is covered by a documented exception |
+| High and critical resolved | 11.3.1.1 | The critical and high findings those scans raised are no longer active at the quarter's end, or were resolved inside the timeframe the entity set |
+| Rescan confirmed | 11.3.1.1 | The resolved findings were confirmed by a later scan, either a reimport that closed them or a later test in the same engagement |
+| Passing ASV scan | 11.3.2 | At least one external ASV scan in the quarter carries a pass, with its vendor and attestation reference |
+| Significant changes covered | 11.3.1.3 and 11.3.2.1 | Every significant change in the quarter has the scans it requires |
+
+A verdict is one of four: satisfied, needs attention, not satisfied, or not applicable. Needs attention is the middle answer, for a requirement that is met on paper but rests on something an assessor will ask about, such as that documented exception.
+
+## The annual checks
+
+Below the grid are the Requirement 11.4 checks, measured over the trailing twelve months: an internal penetration test, an external penetration test, and a segmentation test. Segmentation is measured over six months when the instance is assessed as a service provider, which is recorded in the system settings. A fourth check follows what the penetration tests found: an exploitable finding is expected to be corrected and then confirmed by a retest engagement linked to the original.
+
+## The dashboard tile and the reminders
+
+The **PCI Quarter Status** widget counts, across every in-scope Asset, how many have an internal scan, an authenticated scan and a passing ASV scan recorded for the quarter that is open today, and how many days are left in it. The counts come from a nightly job, and are scoped to what the person looking at the dashboard is authorized to see.
+
+The same nightly job sends a reminder three weeks before a quarter ends, and again a week before, to the members of each in-scope Asset that is still missing an internal scan or a passing ASV scan. Each reminder is sent once per missing check, not once a day, and nothing is sent for a check that is already satisfied.
+
+## The evidence workbook
+
+The export produces an Excel workbook for the assessor. The summary sheet lists every in-scope Asset with its anchor date and the worst verdict in each of its four quarters. Each Asset then gets its own sheet holding the full grid, the annual checks, and the list of tests the verdicts were read from, so any cell can be traced back to the scan behind it. Every sheet records when the workbook was generated and who asked for it. The export can be narrowed to a single Organization.
diff --git a/docs/content/asset_modelling/locations/PRO__container_image_locations.md b/docs/content/asset_modelling/locations/PRO__container_image_locations.md
new file mode 100644
index 00000000000..8d1652fb37d
--- /dev/null
+++ b/docs/content/asset_modelling/locations/PRO__container_image_locations.md
@@ -0,0 +1,54 @@
+---
+title: "Container Image Locations"
+description: "Container Image locations model the image a finding was found in, identified by registry, repository and digest, and the assets that run it"
+weight: 8
+audience: pro
+---
+
+**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**.
+
+> Container Image Locations require the Locations feature and are enabled separately as the **Container Image Locations** flag (beta) on the [Feature Flags page](/admin/feature_flags/pro__feature_flags/). Images reported while the flag is off are still stored; they appear as soon as the flag is turned on.
+
+## What They Model
+
+A container scanner reports which package is vulnerable, but the finding is only actionable once you know which image it was in, where that image runs, and which repository built it. An Image location records the first two; the third is the image's `org.opencontainers.image.source` label, kept on the location for the image-to-repository link.
+
+Each image carries:
+
+- **Registry**: the host, normalised. Docker Hub short names become `index.docker.io`, and hosts are lower-cased with no scheme.
+- **Repository**: the path within the registry, such as `library/nginx` or `acme/payments-api`. Docker Hub official images get the `library/` prefix, so `nginx:1.25` and `docker.io/library/nginx:1.25` are one image.
+- **Digest**: the manifest digest (`sha256:` plus 64 hex characters) when the scanner knows it.
+- **Tag**: the tag as reported.
+- **Source and revision**: the `org.opencontainers.image.source` and `.revision` labels when the reporting tool exposes image labels.
+
+### Identity: digests first, tags when that is all there is
+
+The location's canonical value is `registry/repository@sha256:` when the digest is known, and `registry/repository:tag` when it is not. A tag-only image and a digest image for the same repository are **different locations on purpose**: tags move and digests do not, so collapsing them would make a finding on last week's `:latest` read as a finding on this week's. Every reference to an image records whether its digest is known (`digest_known`), and the lists mark tag-only images as **digest unknown**.
+
+Image locations are **scan-managed**: they are created by imports and connectors, not by hand. There is no "New Image" action; the scanner or registry is the source of truth.
+
+## Where to Find Them
+
+- **All Images** in the sidebar (under Locations, or under Attack Surface in the reorganized menu) lists every image on the instance, with filters for registry, repository, tag and whether the digest is known.
+- **View Images** in an Asset's Locations menu scopes the list to one asset.
+- The asset **location map** draws a Container Images region, grouping images by registry and then repository. A repository with one image collapses to that image.
+- A finding's page has a **Runs in** tile listing the images the finding was found in, each with its registry, repository, tag and short digest, and the assets that run it.
+
+## Built From: the Image to Repository Link
+
+An image's `org.opencontainers.image.source` label names the repository that built it. When the label is present, DefectDojo matches it against, in order, Sensei repository configurations, the **Repo** field of engagements, and repositories mapped through the SCM asset connectors (GitHub, GitLab, Azure DevOps, Bitbucket), and records the matching asset as the image's **Built from** owner together with the `.revision` label.
+
+- One match is linked automatically and shown on the image page and in the finding's **Runs in** tile as "Built from *asset* at *revision*".
+- More than one match is recorded as **candidates** rather than guessed at. The image page lists them, and a person can link one, or any other asset, with **Link repository**.
+- A link made by hand outranks everything the scanners say and is never overwritten; **Unlink** hands the decision back to the resolver.
+- Images built from one asset and seen running in another feed the [suggested edges](/asset_modelling/pro_hierarchy/asset_hierarchy/#suggested-edges-from-container-evidence) on the hierarchy page. No edge is ever drawn without a person accepting it.
+
+Images are resolved when they arrive and again whenever a Sensei repository, an engagement's Repo field or an SCM connector mapping changes.
+
+## API
+
+Images are available read-only at `/api/v2/container_image/`, with the same filters as the list, and through the general locations resource at `/api/v3/locations?type=image`. Each row also exposes a `pkg:oci` Package URL for exports; the stored value stays the plain image reference.
+
+## Relationship to Other Location Types
+
+An Image location sits beside a finding's other locations rather than replacing them: a Trivy image scan still produces Dependency locations for the vulnerable packages, and a cluster connector can attach a Cloud Resource location for the workload the image runs as. Together they answer "which package, in which image, running where".
diff --git a/docs/content/asset_modelling/locations/PRO__exporting_sboms_and_vex.md b/docs/content/asset_modelling/locations/PRO__exporting_sboms_and_vex.md
index aa7a9dbed8d..da90e9bb94f 100644
--- a/docs/content/asset_modelling/locations/PRO__exporting_sboms_and_vex.md
+++ b/docs/content/asset_modelling/locations/PRO__exporting_sboms_and_vex.md
@@ -37,6 +37,15 @@ GET /api/v2/sbom/{asset_id}/?spec=spdx
The response is a downloadable JSON document (`Content-Disposition: attachment`). Components carry their Package URL, group/namespace, version, artifact hashes (algorithms each specification supports), and — when the SBOM import recorded one — the license expression for this Asset's use of the component.
+Where a component records supplier and support facts, the export carries them too. CycloneDX
+writes the supplier as the component's `supplier` object, and the support facts as properties named
+`defectdojo:support_level` and `defectdojo:end_of_support_date`. SPDX writes the supplier as the
+package's supplier and the end of support date as `validUntilDate`.
+
+A component whose support level is unknown emits no support property at all. The document says
+nothing rather than saying unknown, because a consumer reading a property named support level
+should be reading a claim somebody made, not a placeholder.
+
Without a `version`, the export describes the Asset's **current** inventory, and its `dependencies` section declares root → component edges only: the aggregate inventory is a set of libraries, not a graph.
### Exporting one release
diff --git a/docs/content/asset_modelling/locations/PRO__locations_overview.md b/docs/content/asset_modelling/locations/PRO__locations_overview.md
index 4361ac4797a..1230d1b42b8 100644
--- a/docs/content/asset_modelling/locations/PRO__locations_overview.md
+++ b/docs/content/asset_modelling/locations/PRO__locations_overview.md
@@ -7,7 +7,7 @@ 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 must be enabled on your instance before you can use them. You can turn Locations on yourself from the [Feature Flags page](/admin/feature_flags/pro__feature_flags/) — no Support request is required. Enabling is one-way and takes effect for new imports right away; your existing history stays as it is until you run the [migration suite](/asset_modelling/locations/pro__migrating_from_endpoints/) that appears under the flag (endpoint, dependency, and source-code backfills, then an identity rehash). If you also use the Classic UI or depend on the `/api/v2` endpoint routes, keep the `DD_V3_FEATURE_LOCATIONS` deployment setting in sync and restart, since those surfaces are fixed when DefectDojo starts.
+Locations must be enabled on your instance before you can use them. You can turn Locations on yourself from the [Feature Flags page](/admin/feature_flags/pro__feature_flags/) — no Support request is required. Enabling is one-way and takes effect for new imports right away; your existing history stays as it is until you run the [migration suite](/asset_modelling/locations/pro__migrating_from_endpoints/) that appears under the flag (endpoint, dependency, and source-code backfills, then an identity rehash). If you also use the Classic UI or depend on the `/api/v2` endpoint routes, restart DefectDojo after enabling: those surfaces are decided when DefectDojo starts, and they pick up the toggle on the next start. No deployment setting needs to change.
## Why Replace Endpoints?
@@ -22,8 +22,9 @@ Locations fix all three by introducing a **base `Location` object** with a typed
- **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.
- **[Source Code Locations](/asset_modelling/locations/pro__source_code_locations/)** — where a static-analysis finding lives in source, identified by file path and line number. Scan-managed, and the substrate for [tracking findings as their code moves](/triage_findings/finding_deduplication/pro__location_drift_matching/).
+- **[Container Image Locations](/asset_modelling/locations/pro__container_image_locations/)**: the container image a finding was found in, identified by registry, repository and digest, together with the assets that run it and the repository that built it. Scan-managed, behind its own flag.
-Future Location types under consideration include cloud provider resource IDs (AWS ARN, Azure Resource ID, GCP Full Resource Name) and container images (registry/repository:tag and SHA256 fingerprints).
+Cloud provider resource IDs (AWS ARN, Azure Resource ID, GCP Full Resource Name) arrive as Cloud Resource locations from cloud posture scans, and container images as [Container Image Locations](/asset_modelling/locations/pro__container_image_locations/).
## Key Concepts
diff --git a/docs/content/asset_modelling/locations/PRO__working_with_sboms.md b/docs/content/asset_modelling/locations/PRO__working_with_sboms.md
index 832fe11d1b4..9168172c67d 100644
--- a/docs/content/asset_modelling/locations/PRO__working_with_sboms.md
+++ b/docs/content/asset_modelling/locations/PRO__working_with_sboms.md
@@ -24,9 +24,45 @@ Every Dependency is uniquely identified by a pURL, decomposed into atomic fields
| `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` |
+| `supplier_name` *(optional)* | The manufacturer or supplier of this component version | `Example Supplier` |
+| `supplier_url` *(optional)* | A link supporting the supplier or support claim | `https://example.test/support` |
+| `support_level` *(optional)* | How the supplier supports this version | `actively_maintained`, `security_fixes_only`, `community_only`, `unsupported`, `end_of_life`, `unknown` |
+| `end_of_support_date` *(optional)* | The date after which the supplier no longer supports this version | `2030-01-01` |
+| `support_source` *(optional)* | Where the support facts came from | `import`, `manual`, `unknown` |
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.
+## Supplier and Support Metadata
+
+Who supplies a component and how long they will support it are facts a bill of materials is often
+asked for and rarely carries. DefectDojo records them on the component, alongside where each fact
+came from.
+
+Unknown is a valid answer and is stored as unknown. DefectDojo never infers a support level or an
+end of support date from a version number, a release date or a project's activity. A fabricated
+support claim in a regulated bill of materials is a problem for whoever relies on it, so the only
+support facts recorded are the ones somebody supplied.
+
+An import reads these from the document where the format carries them. CycloneDX supplies the
+supplier from the component's supplier, publisher or author, in that order, and reads support
+level and end of support date from component properties. SPDX supplies the supplier from the
+supplier or originator field, and reads an end of support date from `validUntilDate` where the
+document has one. Anything absent stays unknown.
+
+### Which value wins
+
+A component's support facts can come from three places, and they resolve in this order:
+
+1. A per snapshot override, where a specific release carries a different support contract from the
+ component in general.
+2. The value recorded on the component itself, whether that came from an import or from somebody
+ editing it.
+3. Unknown.
+
+An edit made by hand survives later imports of the same component. Re-importing a document does
+not overwrite a support level somebody corrected, and `support_source` records which case applies,
+so a reviewer can tell an imported fact from an entered one.
+
## 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:
diff --git a/docs/content/automation/rules_engine/about.de.md b/docs/content/automation/rules_engine/about.de.md
index 17f9da34c52..a1599292edd 100644
--- a/docs/content/automation/rules_engine/about.de.md
+++ b/docs/content/automation/rules_engine/about.de.md
@@ -13,7 +13,7 @@ Mit der Rules Engine von DefectDojo können Sie benutzerdefinierte Workflows und
Die Rules Engine ist nur über die [Pro UI](/get_started/about/ui_pro_vs_os/) zugänglich.
-**Suchen Sie den grafischen Editor?** [Rules Engine 2.0](/automation/rules_engine_2/about/) baut Automatisierung als visuelle Knotengraphen auf und fügt Verzweigungen, ausgehende Aktionen wie Tickets und Nachrichten, Spuren pro Lauf und ein Zustellungsprotokoll hinzu. Beide Engines laufen nebeneinander, und bestehende Regeln können [dorthin übertragen werden](/automation/rules_engine_2/converting_from_rules_engine/).
+**Suchen Sie den grafischen Editor?** [Triage Engine](/automation/triage_engine/about/) baut Automatisierung als visuelle Knotengraphen auf und fügt Verzweigungen, ausgehende Aktionen wie Tickets und Nachrichten, Spuren pro Lauf und ein Zustellungsprotokoll hinzu. Beide Engines laufen nebeneinander, und bestehende Regeln können [dorthin übertragen werden](/automation/triage_engine/converting_from_rules_engine/).
## Rules Engine aktivieren
diff --git a/docs/content/automation/rules_engine/about.es.md b/docs/content/automation/rules_engine/about.es.md
index 8875fbcf58e..f18ca90d674 100644
--- a/docs/content/automation/rules_engine/about.es.md
+++ b/docs/content/automation/rules_engine/about.es.md
@@ -13,7 +13,7 @@ El Rules Engine de DefectDojo permite crear flujos de trabajo personalizados y a
Solo se puede acceder a Rules Engine a través de la [interfaz Pro](/get_started/about/ui_pro_vs_os/).
-**¿Busca el editor de grafos?** [Rules Engine 2.0](/automation/rules_engine_2/about/) construye la automatización como grafos visuales de nodos, y añade ramificaciones, acciones salientes como tickets y mensajes, rastros por ejecución y un libro de entregas. Ambos motores funcionan en paralelo, y las reglas existentes se pueden [convertir](/automation/rules_engine_2/converting_from_rules_engine/) de uno a otro.
+**¿Busca el editor de grafos?** [Triage Engine](/automation/triage_engine/about/) construye la automatización como grafos visuales de nodos, y añade ramificaciones, acciones salientes como tickets y mensajes, rastros por ejecución y un libro de entregas. Ambos motores funcionan en paralelo, y las reglas existentes se pueden [convertir](/automation/triage_engine/converting_from_rules_engine/) de uno a otro.
## Enabling Rules Engine
diff --git a/docs/content/automation/rules_engine/about.fr.md b/docs/content/automation/rules_engine/about.fr.md
index c4f24878c10..feae79d6462 100644
--- a/docs/content/automation/rules_engine/about.fr.md
+++ b/docs/content/automation/rules_engine/about.fr.md
@@ -13,7 +13,7 @@ Le Moteur de règles de DefectDojo vous permet de créer des workflows personnal
Le Moteur de règles n'est accessible que via l'[interface Pro](/get_started/about/ui_pro_vs_os/).
-**Vous cherchez l'éditeur de graphes ?** Le [Moteur de règles 2.0](/automation/rules_engine_2/about/) construit l'automatisation sous forme de graphes de nœuds visuels, et ajoute des embranchements, des actions sortantes telles que des tickets et des messages, des traces par exécution et un registre des livraisons. Les deux moteurs fonctionnent côte à côte, et les règles existantes peuvent être [converties vers l'autre moteur](/automation/rules_engine_2/converting_from_rules_engine/).
+**Vous cherchez l'éditeur de graphes ?** Le [Triage Engine](/automation/triage_engine/about/) construit l'automatisation sous forme de graphes de nœuds visuels, et ajoute des embranchements, des actions sortantes telles que des tickets et des messages, des traces par exécution et un registre des livraisons. Les deux moteurs fonctionnent côte à côte, et les règles existantes peuvent être [converties vers l'autre moteur](/automation/triage_engine/converting_from_rules_engine/).
## Activer le Moteur de règles
diff --git a/docs/content/automation/rules_engine/about.it.md b/docs/content/automation/rules_engine/about.it.md
index 38121153e89..782f4865ea6 100644
--- a/docs/content/automation/rules_engine/about.it.md
+++ b/docs/content/automation/rules_engine/about.it.md
@@ -13,7 +13,7 @@ Il Rules Engine di DefectDojo consente di creare flussi di lavoro personalizzati
Rules Engine è accessibile solo tramite la [Pro UI](/get_started/about/ui_pro_vs_os/).
-**Cerchi l'editor a grafo?** [Rules Engine 2.0](/automation/rules_engine_2/about/) costruisce l'automazione come grafi di nodi visuali, e aggiunge la ramificazione, azioni in uscita come ticket e messaggi, tracce per ogni run e un registro delle consegne. I due motori funzionano in parallelo, e le regole esistenti possono essere [convertite](/automation/rules_engine_2/converting_from_rules_engine/).
+**Cerchi l'editor a grafo?** [Triage Engine](/automation/triage_engine/about/) costruisce l'automazione come grafi di nodi visuali, e aggiunge la ramificazione, azioni in uscita come ticket e messaggi, tracce per ogni run e un registro delle consegne. I due motori funzionano in parallelo, e le regole esistenti possono essere [convertite](/automation/triage_engine/converting_from_rules_engine/).
## Abilitare Rules Engine
diff --git a/docs/content/automation/rules_engine/about.ja.md b/docs/content/automation/rules_engine/about.ja.md
index 4a3c49fca73..d88042658d2 100644
--- a/docs/content/automation/rules_engine/about.ja.md
+++ b/docs/content/automation/rules_engine/about.ja.md
@@ -13,7 +13,7 @@ DefectDojoのRules Engineを使用すると、Findingやその他のオブジェ
Rules Engineは[Pro UI](/get_started/about/ui_pro_vs_os/)からのみアクセスできます。
-**グラフエディタをお探しですか？** [Rules Engine 2.0](/automation/rules_engine_2/about/)は、自動化をビジュアルなノードグラフとして構築できるようにし、分岐、チケットやメッセージなどのアウトバウンドアクション、実行ごとのトレース、配信台帳を追加します。両エンジンは並行して稼働しており、既存のルールは[変換](/automation/rules_engine_2/converting_from_rules_engine/)することができます。
+**グラフエディタをお探しですか？** [Triage Engine](/automation/triage_engine/about/)は、自動化をビジュアルなノードグラフとして構築できるようにし、分岐、チケットやメッセージなどのアウトバウンドアクション、実行ごとのトレース、配信台帳を追加します。両エンジンは並行して稼働しており、既存のルールは[変換](/automation/triage_engine/converting_from_rules_engine/)することができます。
## Rules Engineの有効化
diff --git a/docs/content/automation/rules_engine/about.md b/docs/content/automation/rules_engine/about.md
index a725a91b3fe..ad5cffa6c86 100644
--- a/docs/content/automation/rules_engine/about.md
+++ b/docs/content/automation/rules_engine/about.md
@@ -12,7 +12,7 @@ DefectDojo's Rules Engine allows you to build custom workflows and bulk actions
Rules Engine can only be accessed through the [Pro UI](/get_started/about/ui_pro_vs_os/).
-**Looking for the graph editor?** [Rules Engine 2.0](/automation/rules_engine_2/about/) builds automation as visual node graphs, and adds branching, outbound actions such as tickets and messages, per-run traces and a delivery ledger. Both engines run side by side, and existing rules can be [converted across](/automation/rules_engine_2/converting_from_rules_engine/).
+**Looking for the graph editor?** [Triage Engine](/automation/triage_engine/about/) builds automation as visual node graphs, and adds branching, outbound actions such as tickets and messages, per-run traces and a delivery ledger. Both engines run side by side, and existing rules can be [converted across](/automation/triage_engine/converting_from_rules_engine/).
## Enabling Rules Engine
diff --git a/docs/content/automation/rules_engine/about.pt-br.md b/docs/content/automation/rules_engine/about.pt-br.md
index fb7f2fc8d21..350a6000f78 100644
--- a/docs/content/automation/rules_engine/about.pt-br.md
+++ b/docs/content/automation/rules_engine/about.pt-br.md
@@ -13,7 +13,7 @@ O Rules Engine do DefectDojo permite construir workflows personalizados e açõe
O Rules Engine só pode ser acessado através da [Pro UI](/get_started/about/ui_pro_vs_os/).
-**Procurando o editor de grafos?** O [Rules Engine 2.0](/automation/rules_engine_2/about/) constrói automações como grafos visuais de nós, e adiciona ramificações, ações de saída como tickets e mensagens, rastros por execução e um livro-razão de entregas. Os dois mecanismos funcionam lado a lado, e regras existentes podem ser [convertidas](/automation/rules_engine_2/converting_from_rules_engine/).
+**Procurando o editor de grafos?** O [Triage Engine](/automation/triage_engine/about/) constrói automações como grafos visuais de nós, e adiciona ramificações, ações de saída como tickets e mensagens, rastros por execução e um livro-razão de entregas. Os dois mecanismos funcionam lado a lado, e regras existentes podem ser [convertidas](/automation/triage_engine/converting_from_rules_engine/).
## Habilitando o Rules Engine
diff --git a/docs/content/automation/rules_engine/about.zh-hans.md b/docs/content/automation/rules_engine/about.zh-hans.md
index efabbc53df5..aa671a40286 100644
--- a/docs/content/automation/rules_engine/about.zh-hans.md
+++ b/docs/content/automation/rules_engine/about.zh-hans.md
@@ -13,7 +13,7 @@ DefectDojo 的规则引擎允许您构建自定义工作流和批量操作，用
规则引擎只能通过 [Pro UI](/get_started/about/ui_pro_vs_os/) 访问。
-**在寻找图形编辑器？** [规则引擎 2.0](/automation/rules_engine_2/about/) 以可视化节点图的形式构建自动化流程，并新增了分支、诸如工单和消息等出站操作、按运行记录的执行痕迹，以及投递台账。两套引擎并行运行，现有规则也可以[转换](/automation/rules_engine_2/converting_from_rules_engine/)到新引擎。
+**在寻找图形编辑器？** [Triage Engine](/automation/triage_engine/about/) 以可视化节点图的形式构建自动化流程，并新增了分支、诸如工单和消息等出站操作、按运行记录的执行痕迹，以及投递台账。两套引擎并行运行，现有规则也可以[转换](/automation/triage_engine/converting_from_rules_engine/)到新引擎。
## 启用规则引擎
diff --git a/docs/content/automation/rules_engine_2/_index.de.md b/docs/content/automation/triage_engine/_index.de.md
similarity index 93%
rename from docs/content/automation/rules_engine_2/_index.de.md
rename to docs/content/automation/triage_engine/_index.de.md
index 98255528d38..bec763b49df 100644
--- a/docs/content/automation/rules_engine_2/_index.de.md
+++ b/docs/content/automation/triage_engine/_index.de.md
@@ -1,5 +1,5 @@
---
-title: Rules Engine 2.0
+title: Triage Engine
description: Bauen Sie Automatisierungen als visuelle Node-Graphen, mit Traces je
Ausführung und einem Zustellungsprotokoll
summary: ''
diff --git a/docs/content/automation/rules_engine_2/_index.es.md b/docs/content/automation/triage_engine/_index.es.md
similarity index 93%
rename from docs/content/automation/rules_engine_2/_index.es.md
rename to docs/content/automation/triage_engine/_index.es.md
index a2c9c266e4d..39e158d2083 100644
--- a/docs/content/automation/rules_engine_2/_index.es.md
+++ b/docs/content/automation/triage_engine/_index.es.md
@@ -1,5 +1,5 @@
---
-title: Rules Engine 2.0
+title: Triage Engine
description: Cree automatizaciones como grafos de nodos visuales, con trazas por ejecución
y un libro de registro de entregas
summary: ''
diff --git a/docs/content/automation/rules_engine_2/_index.fr.md b/docs/content/automation/triage_engine/_index.fr.md
similarity index 100%
rename from docs/content/automation/rules_engine_2/_index.fr.md
rename to docs/content/automation/triage_engine/_index.fr.md
diff --git a/docs/content/automation/rules_engine_2/_index.it.md b/docs/content/automation/triage_engine/_index.it.md
similarity index 93%
rename from docs/content/automation/rules_engine_2/_index.it.md
rename to docs/content/automation/triage_engine/_index.it.md
index bc3d175a90c..66161878895 100644
--- a/docs/content/automation/rules_engine_2/_index.it.md
+++ b/docs/content/automation/triage_engine/_index.it.md
@@ -1,5 +1,5 @@
---
-title: Rules Engine 2.0
+title: Triage Engine
description: Crea automazioni come grafi di nodi visivi, con tracce per singola esecuzione
e un registro delle consegne
summary: ''
diff --git a/docs/content/automation/rules_engine_2/_index.ja.md b/docs/content/automation/triage_engine/_index.ja.md
similarity index 93%
rename from docs/content/automation/rules_engine_2/_index.ja.md
rename to docs/content/automation/triage_engine/_index.ja.md
index fd95f600973..cf2aa7f3f29 100644
--- a/docs/content/automation/rules_engine_2/_index.ja.md
+++ b/docs/content/automation/triage_engine/_index.ja.md
@@ -1,5 +1,5 @@
---
-title: Rules Engine 2.0
+title: Triage Engine
description: 自動化をビジュアルなノードグラフとして構築し、実行ごとのトレースと配信台帳を確認できます
summary: ''
date: 2026-08-02 09:00:00+00:00
diff --git a/docs/content/automation/rules_engine_2/_index.md b/docs/content/automation/triage_engine/_index.md
similarity index 94%
rename from docs/content/automation/rules_engine_2/_index.md
rename to docs/content/automation/triage_engine/_index.md
index 6e559ce77d1..21cbcae238a 100644
--- a/docs/content/automation/rules_engine_2/_index.md
+++ b/docs/content/automation/triage_engine/_index.md
@@ -1,5 +1,5 @@
---
-title: "Rules Engine 2.0"
+title: "Triage Engine"
description: "Build automation as visual node graphs, with per-run traces and a delivery ledger"
summary: ""
date: 2026-08-02T09:00:00+00:00
diff --git a/docs/content/automation/rules_engine_2/_index.pt-br.md b/docs/content/automation/triage_engine/_index.pt-br.md
similarity index 100%
rename from docs/content/automation/rules_engine_2/_index.pt-br.md
rename to docs/content/automation/triage_engine/_index.pt-br.md
diff --git a/docs/content/automation/rules_engine_2/_index.zh-hans.md b/docs/content/automation/triage_engine/_index.zh-hans.md
similarity index 100%
rename from docs/content/automation/rules_engine_2/_index.zh-hans.md
rename to docs/content/automation/triage_engine/_index.zh-hans.md
diff --git a/docs/content/automation/rules_engine_2/about.de.md b/docs/content/automation/triage_engine/about.de.md
similarity index 84%
rename from docs/content/automation/rules_engine_2/about.de.md
rename to docs/content/automation/triage_engine/about.de.md
index 691859f2bc2..b0c3f27466b 100644
--- a/docs/content/automation/rules_engine_2/about.de.md
+++ b/docs/content/automation/triage_engine/about.de.md
@@ -1,35 +1,36 @@
---
-title: Über Rules Engine 2.0
-description: Was Rules Engine 2.0 ist, wie man sie aktiviert, und die Konzepte, auf
+title: Über Triage Engine
+description: Was Triage Engine ist, wie man sie aktiviert, und die Konzepte, auf
denen sie aufbaut
weight: 1
audience: pro
aliases:
- /de/automation/rules_engine_v2/about/
+- /de/automation/rules_engine_2/about/
---
-Hinweis: Rules Engine 2.0 ist eine Funktion, die nur in DefectDojo Pro verfügbar ist.
+Hinweis: Triage Engine ist eine Funktion, die nur in DefectDojo Pro verfügbar ist.
-Rules Engine 2.0 ist ein visueller Automatisierungs-Baukasten. Statt eines Filters plus einer flachen Liste von Aktionen ist eine Regel ein **Graph**: ein Trigger-Knoten, der entscheidet, wann die Regel aufwacht, sowie eine beliebige Anzahl von Logik-, Befunde- und Egress-Knoten, die miteinander verbunden festlegen, was als Nächstes passiert.
+Triage Engine ist ein visueller Automatisierungs-Baukasten. Statt eines Filters plus einer flachen Liste von Aktionen ist eine Regel ein **Graph**: ein Trigger-Knoten, der entscheidet, wann die Regel aufwacht, sowie eine beliebige Anzahl von Logik-, Befunde- und Egress-Knoten, die miteinander verbunden festlegen, was als Nächstes passiert.
-Rules Engine 2.0 ist ausschließlich über die [Pro-UI](/get_started/about/ui_pro_vs_os/) zugänglich.
+Triage Engine ist ausschließlich über die [Pro-UI](/get_started/about/ui_pro_vs_os/) zugänglich.
## Was sie gegenüber der Rules Engine hinzufügt
-Die ursprüngliche [Rules Engine](/automation/rules_engine/about/) wendet eine geordnete Liste von Aktionen auf jeden Befund an, der auf einen Filter passt. Rules Engine 2.0 behält diese Fähigkeit bei und fügt vier Dinge hinzu:
+Die ursprüngliche [Rules Engine](/automation/rules_engine/about/) wendet eine geordnete Liste von Aktionen auf jeden Befund an, der auf einen Filter passt. Triage Engine behält diese Fähigkeit bei und fügt vier Dinge hinzu:
* **Verzweigung.** Ein **Wenn / Filter**-Knoten leitet Elemente in einen true-Zweig und einen false-Zweig, sodass eine Regel kritische Befunde anders behandeln kann als den Rest, ohne in zwei Regeln aufgeteilt werden zu müssen.
* **Egress.** Eine Regel kann DefectDojo verlassen: ein JIRA-Issue oder ein Downstream-Ticket eröffnen, in Slack oder Microsoft Teams posten, eine E-Mail senden, einen Webhook aufrufen, eine In-App-Benachrichtigung auslösen oder einen Bericht erstellen.
* **Nachvollziehbarkeit.** Jede Ausführung wird Knoten für Knoten als [Ausführung](../runs/) erfasst, und jeder ausgehende Versand wird als [Zustellung](../deliveries/) erfasst, die genau angibt, was gesendet wurde, wohin es ging und wie es endete.
* **Ein Simulationsmodus.** Eine Regel kann exakt erfassen, was sie senden würde, ohne tatsächlich etwas zu senden – so testen Sie eine Regel sicher, bevor sie mit der Außenwelt in Berührung kommt.
-Beide Engines laufen nebeneinander. Das Aktivieren von Rules Engine 2.0 deaktiviert oder konvertiert Ihre bestehenden Regeln nicht, und es gibt einen [Konverter](../converting_from_rules_engine/), falls Sie sie übertragen möchten.
+Beide Engines laufen nebeneinander. Das Aktivieren von Triage Engine deaktiviert oder konvertiert Ihre bestehenden Regeln nicht, und es gibt einen [Konverter](../converting_from_rules_engine/), falls Sie sie übertragen möchten.
-## Rules Engine 2.0 aktivieren
+## Triage Engine aktivieren
-Rules Engine 2.0 befindet sich in der Beta-Phase und ist standardmäßig ausgeschaltet. Ein Superuser aktiviert sie unter **Settings > Feature Flags**, sowohl auf Cloud- als auch auf On-Premise-Instanzen. Siehe [Feature Flags](/admin/feature_flags/pro__feature_flags/).
+Triage Engine befindet sich in der Beta-Phase und ist standardmäßig ausgeschaltet. Ein Superuser aktiviert sie unter **Settings > Feature Flags**, sowohl auf Cloud- als auch auf On-Premise-Instanzen. Siehe [Feature Flags](/admin/feature_flags/pro__feature_flags/).
-Sobald das Flag aktiviert ist, erscheint in der Seitenleiste ein Abschnitt **Rules Engine 2.0** mit drei Seiten:
+Sobald das Flag aktiviert ist, erscheint in der Seitenleiste ein Abschnitt **Triage Engine** mit drei Seiten:
| Page | What it is for |
|------|----------------|
diff --git a/docs/content/automation/rules_engine_2/about.es.md b/docs/content/automation/triage_engine/about.es.md
similarity index 83%
rename from docs/content/automation/rules_engine_2/about.es.md
rename to docs/content/automation/triage_engine/about.es.md
index 6498750c5c5..c7cb590d600 100644
--- a/docs/content/automation/rules_engine_2/about.es.md
+++ b/docs/content/automation/triage_engine/about.es.md
@@ -1,35 +1,36 @@
---
-title: Acerca de Rules Engine 2.0
-description: Qué es Rules Engine 2.0, cómo activarlo y los conceptos en los que se
+title: Acerca de Triage Engine
+description: Qué es Triage Engine, cómo activarlo y los conceptos en los que se
basa
weight: 1
audience: pro
aliases:
- /es/automation/rules_engine_v2/about/
+- /es/automation/rules_engine_2/about/
---
-Nota: Rules Engine 2.0 es una función exclusiva de DefectDojo Pro.
+Nota: Triage Engine es una función exclusiva de DefectDojo Pro.
-Rules Engine 2.0 es un generador visual de automatizaciones. En lugar de un filtro más una lista plana de acciones, una regla es un **grafo**: un nodo disparador que decide cuándo se activa la regla, y cualquier cantidad de nodos de lógica, de Hallazgos y de salida conectados entre sí para determinar qué ocurre a continuación.
+Triage Engine es un generador visual de automatizaciones. En lugar de un filtro más una lista plana de acciones, una regla es un **grafo**: un nodo disparador que decide cuándo se activa la regla, y cualquier cantidad de nodos de lógica, de Hallazgos y de salida conectados entre sí para determinar qué ocurre a continuación.
-Solo se puede acceder a Rules Engine 2.0 a través de la [interfaz de Pro](/get_started/about/ui_pro_vs_os/).
+Solo se puede acceder a Triage Engine a través de la [interfaz de Pro](/get_started/about/ui_pro_vs_os/).
## Qué aporta respecto a Rules Engine
-El [Rules Engine](/automation/rules_engine/about/) original aplica una lista ordenada de acciones a cada Hallazgo que coincide con un filtro. Rules Engine 2.0 conserva esa capacidad y añade cuatro cosas:
+El [Rules Engine](/automation/rules_engine/about/) original aplica una lista ordenada de acciones a cada Hallazgo que coincide con un filtro. Triage Engine conserva esa capacidad y añade cuatro cosas:
* **Ramificación.** Un nodo **Si / Filtro** dirige los elementos por una rama verdadera y una rama falsa, de modo que una regla puede tratar los Hallazgos Críticos de forma distinta al resto sin tener que dividirse en dos reglas.
* **Salida.** Una regla puede salir de DefectDojo: abrir un issue de JIRA o un ticket en un sistema externo, publicar en Slack o Microsoft Teams, enviar un correo electrónico, llamar a un webhook, generar una alerta dentro de la aplicación o generar un informe.
* **Trazabilidad.** Cada ejecución se registra nodo por nodo como una [Ejecución](../runs/), y cada envío saliente se registra como una [Entrega](../deliveries/) que indica exactamente qué se envió, adónde fue y cómo terminó.
* **Un modo de simulación.** Una regla puede registrar con precisión lo que enviaría sin enviar realmente nada, que es la forma de probarla de manera segura antes de que llegue al mundo exterior.
-Ambos motores funcionan en paralelo. Activar Rules Engine 2.0 no desactiva ni convierte las reglas existentes, y existe un [conversor](../converting_from_rules_engine/) para cuando se quiera migrarlas.
+Ambos motores funcionan en paralelo. Activar Triage Engine no desactiva ni convierte las reglas existentes, y existe un [conversor](../converting_from_rules_engine/) para cuando se quiera migrarlas.
-## Activación de Rules Engine 2.0
+## Activación de Triage Engine
-Rules Engine 2.0 está en Beta y viene desactivado de forma predeterminada. Un superusuario lo activa desde **Settings > Feature Flags**, tanto en instancias Cloud como On-Premise. Consulte [Feature Flags](/admin/feature_flags/pro__feature_flags/).
+Triage Engine está en Beta y viene desactivado de forma predeterminada. Un superusuario lo activa desde **Settings > Feature Flags**, tanto en instancias Cloud como On-Premise. Consulte [Feature Flags](/admin/feature_flags/pro__feature_flags/).
-Una vez activado el indicador, aparece una sección **Rules Engine 2.0** en la barra lateral con tres páginas:
+Una vez activado el indicador, aparece una sección **Triage Engine** en la barra lateral con tres páginas:
| Página | Para qué sirve |
|------|----------------|
diff --git a/docs/content/automation/rules_engine_2/about.fr.md b/docs/content/automation/triage_engine/about.fr.md
similarity index 84%
rename from docs/content/automation/rules_engine_2/about.fr.md
rename to docs/content/automation/triage_engine/about.fr.md
index 57e5ba4eaa4..cd22b41670f 100644
--- a/docs/content/automation/rules_engine_2/about.fr.md
+++ b/docs/content/automation/triage_engine/about.fr.md
@@ -1,35 +1,36 @@
---
-title: À propos de Rules Engine 2.0
-description: Ce qu'est Rules Engine 2.0, comment l'activer, et les concepts sur lesquels
+title: À propos de Triage Engine
+description: Ce qu'est Triage Engine, comment l'activer, et les concepts sur lesquels
il repose
weight: 1
audience: pro
aliases:
- /fr/automation/rules_engine_v2/about/
+- /fr/automation/rules_engine_2/about/
---
-Remarque : Rules Engine 2.0 est une fonctionnalité réservée à DefectDojo Pro.
+Remarque : Triage Engine est une fonctionnalité réservée à DefectDojo Pro.
-Rules Engine 2.0 est un générateur d'automatisation visuel. Au lieu d'un filtre associé à une liste plate d'actions, une règle est un **graphe** : un nœud déclencheur qui décide quand la règle se réveille, et un nombre quelconque de nœuds de logique, de Constatations et de sortie reliés entre eux pour indiquer ce qui se passe ensuite.
+Triage Engine est un générateur d'automatisation visuel. Au lieu d'un filtre associé à une liste plate d'actions, une règle est un **graphe** : un nœud déclencheur qui décide quand la règle se réveille, et un nombre quelconque de nœuds de logique, de Constatations et de sortie reliés entre eux pour indiquer ce qui se passe ensuite.
-Rules Engine 2.0 n'est accessible que via l'[interface Pro](/get_started/about/ui_pro_vs_os/).
+Triage Engine n'est accessible que via l'[interface Pro](/get_started/about/ui_pro_vs_os/).
## Ce qu'il ajoute par rapport à Rules Engine
-Le [Rules Engine](/automation/rules_engine/about/) d'origine applique une liste ordonnée d'actions à chaque Constatation correspondant à un filtre. Rules Engine 2.0 conserve cette capacité et ajoute quatre éléments :
+Le [Rules Engine](/automation/rules_engine/about/) d'origine applique une liste ordonnée d'actions à chaque Constatation correspondant à un filtre. Triage Engine conserve cette capacité et ajoute quatre éléments :
* **Le branchement.** Un nœud **If / Filter** (Si / Filtre) dirige les éléments vers une branche vraie et une branche fausse, de sorte qu'une seule règle puisse traiter les Constatations Critiques différemment du reste sans devoir être scindée en deux règles.
* **La sortie (egress).** Une règle peut sortir de DefectDojo : ouvrir un ticket JIRA ou un ticket en aval, publier sur Slack ou Microsoft Teams, envoyer un e-mail, appeler un webhook, déclencher une alerte dans l'application, ou générer un rapport.
* **La traçabilité.** Chaque exécution est enregistrée nœud par nœud sous forme d'[Exécution](../runs/), et chaque envoi sortant est enregistré comme une [Livraison](../deliveries/) qui indique exactement ce qui a été envoyé, où cela a été envoyé, et comment cela s'est terminé.
* **Un mode de simulation.** Une règle peut enregistrer précisément ce qu'elle aurait envoyé sans rien envoyer réellement, ce qui permet de la tester en toute sécurité avant de la laisser agir à l'extérieur.
-Les deux moteurs fonctionnent côte à côte. Activer Rules Engine 2.0 ne désactive ni ne convertit vos règles existantes, et il existe un [convertisseur](../converting_from_rules_engine/) pour le jour où vous voudrez les faire migrer.
+Les deux moteurs fonctionnent côte à côte. Activer Triage Engine ne désactive ni ne convertit vos règles existantes, et il existe un [convertisseur](../converting_from_rules_engine/) pour le jour où vous voudrez les faire migrer.
-## Activer Rules Engine 2.0
+## Activer Triage Engine
-Rules Engine 2.0 est en version bêta et est désactivé par défaut. Un superutilisateur l'active depuis **Settings > Feature Flags** (Paramètres > Indicateurs de fonctionnalités), aussi bien sur les instances Cloud que sur les instances On-Premise. Voir [Indicateurs de fonctionnalités](/admin/feature_flags/pro__feature_flags/).
+Triage Engine est en version bêta et est désactivé par défaut. Un superutilisateur l'active depuis **Settings > Feature Flags** (Paramètres > Indicateurs de fonctionnalités), aussi bien sur les instances Cloud que sur les instances On-Premise. Voir [Indicateurs de fonctionnalités](/admin/feature_flags/pro__feature_flags/).
-Une fois l'indicateur activé, une section **Rules Engine 2.0** apparaît dans la barre latérale avec trois pages :
+Une fois l'indicateur activé, une section **Triage Engine** apparaît dans la barre latérale avec trois pages :
| Page | À quoi elle sert |
|------|----------------|
diff --git a/docs/content/automation/rules_engine_2/about.it.md b/docs/content/automation/triage_engine/about.it.md
similarity index 84%
rename from docs/content/automation/rules_engine_2/about.it.md
rename to docs/content/automation/triage_engine/about.it.md
index f3851b80eb2..4f8b4bb4329 100644
--- a/docs/content/automation/rules_engine_2/about.it.md
+++ b/docs/content/automation/triage_engine/about.it.md
@@ -1,34 +1,35 @@
---
-title: Informazioni su Rules Engine 2.0
-description: Cos'è Rules Engine 2.0, come attivarlo e i concetti su cui si basa
+title: Informazioni su Triage Engine
+description: Cos'è Triage Engine, come attivarlo e i concetti su cui si basa
weight: 1
audience: pro
aliases:
- /it/automation/rules_engine_v2/about/
+- /it/automation/rules_engine_2/about/
---
-Nota: Rules Engine 2.0 è una funzionalità disponibile solo in DefectDojo Pro.
+Nota: Triage Engine è una funzionalità disponibile solo in DefectDojo Pro.
-Rules Engine 2.0 è un builder di automazione visuale. Invece di un filtro più un elenco piatto di azioni, una regola è un **grafo**: un nodo trigger che decide quando la regola si attiva, e un numero qualsiasi di nodi logici, Riscontro ed egress collegati tra loro per stabilire cosa succede dopo.
+Triage Engine è un builder di automazione visuale. Invece di un filtro più un elenco piatto di azioni, una regola è un **grafo**: un nodo trigger che decide quando la regola si attiva, e un numero qualsiasi di nodi logici, Riscontro ed egress collegati tra loro per stabilire cosa succede dopo.
-Rules Engine 2.0 è accessibile solo tramite la [UI Pro](/get_started/about/ui_pro_vs_os/).
+Triage Engine è accessibile solo tramite la [UI Pro](/get_started/about/ui_pro_vs_os/).
## Cosa aggiunge rispetto a Rules Engine
-Il [Rules Engine](/automation/rules_engine/about/) originale applica un elenco ordinato di azioni a ogni Riscontro che corrisponde a un filtro. Rules Engine 2.0 mantiene questa capacità e aggiunge quattro cose:
+Il [Rules Engine](/automation/rules_engine/about/) originale applica un elenco ordinato di azioni a ogni Riscontro che corrisponde a un filtro. Triage Engine mantiene questa capacità e aggiunge quattro cose:
* **Ramificazione.** Un nodo **If / Filter** instrada gli elementi lungo un ramo vero e uno falso, così una regola può trattare i Riscontri Critica in modo diverso dal resto senza doverla dividere in due regole.
* **Egress.** Una regola può uscire da DefectDojo: aprire un ticket JIRA o un ticket a valle, pubblicare su Slack o Microsoft Teams, inviare un'email, chiamare un webhook, generare un avviso in-app o produrre un report.
* **Tracciabilità.** Ogni esecuzione viene registrata nodo per nodo come [Run](../runs/), e ogni invio in uscita viene registrato come [Delivery](../deliveries/) che indica esattamente cosa è stato inviato, dove è andato e come è terminato.
* **Una modalità di simulazione.** Una regola può registrare esattamente cosa avrebbe inviato senza inviare nulla, ed è così che la si testa in sicurezza prima che tocchi il mondo esterno.
-I due motori funzionano fianco a fianco. Attivare Rules Engine 2.0 non disabilita né converte le regole esistenti, ed esiste un [convertitore](../converting_from_rules_engine/) per quando si vuole spostarle.
+I due motori funzionano fianco a fianco. Attivare Triage Engine non disabilita né converte le regole esistenti, ed esiste un [convertitore](../converting_from_rules_engine/) per quando si vuole spostarle.
-## Abilitare Rules Engine 2.0
+## Abilitare Triage Engine
-Rules Engine 2.0 è in Beta ed è disattivato per impostazione predefinita. Un superuser lo attiva da **Settings > Feature Flags**, sia sulle istanze Cloud che On-Premise. Vedere [Feature Flags](/admin/feature_flags/pro__feature_flags/).
+Triage Engine è in Beta ed è disattivato per impostazione predefinita. Un superuser lo attiva da **Settings > Feature Flags**, sia sulle istanze Cloud che On-Premise. Vedere [Feature Flags](/admin/feature_flags/pro__feature_flags/).
-Una volta attivato il flag, nella barra laterale compare una sezione **Rules Engine 2.0** con tre pagine:
+Una volta attivato il flag, nella barra laterale compare una sezione **Triage Engine** con tre pagine:
| Pagina | A cosa serve |
|------|----------------|
diff --git a/docs/content/automation/rules_engine_2/about.ja.md b/docs/content/automation/triage_engine/about.ja.md
similarity index 83%
rename from docs/content/automation/rules_engine_2/about.ja.md
rename to docs/content/automation/triage_engine/about.ja.md
index 391695c9038..245c5ab143c 100644
--- a/docs/content/automation/rules_engine_2/about.ja.md
+++ b/docs/content/automation/triage_engine/about.ja.md
@@ -1,34 +1,35 @@
---
-title: Rules Engine 2.0 について
-description: Rules Engine 2.0 とは何か、有効化の方法、基盤となる概念について
+title: Triage Engine について
+description: Triage Engine とは何か、有効化の方法、基盤となる概念について
weight: 1
audience: pro
aliases:
- /ja/automation/rules_engine_v2/about/
+- /ja/automation/rules_engine_2/about/
---
-注: Rules Engine 2.0 は DefectDojo Pro 専用の機能です。
+注: Triage Engine は DefectDojo Pro 専用の機能です。
-Rules Engine 2.0 は、ビジュアルな自動化ビルダーです。フィルターとフラットなアクションのリストの代わりに、ルールは**グラフ**として構成されます。グラフは、ルールがいつ起動するかを決めるトリガーノードと、その後の処理内容を指定する任意の数のロジックノード、Finding ノード、Egress ノードが配線されたものです。
+Triage Engine は、ビジュアルな自動化ビルダーです。フィルターとフラットなアクションのリストの代わりに、ルールは**グラフ**として構成されます。グラフは、ルールがいつ起動するかを決めるトリガーノードと、その後の処理内容を指定する任意の数のロジックノード、Finding ノード、Egress ノードが配線されたものです。
-Rules Engine 2.0 には [Pro UI](/get_started/about/ui_pro_vs_os/) からのみアクセスできます。
+Triage Engine には [Pro UI](/get_started/about/ui_pro_vs_os/) からのみアクセスできます。
## Rules Engine と比べて追加されるもの
-従来の [Rules Engine](/automation/rules_engine/about/) は、1つのフィルターに一致するすべての Finding に対して、順序付けられたアクションのリストを適用します。Rules Engine 2.0 はこの機能を維持しつつ、次の4つを追加します。
+従来の [Rules Engine](/automation/rules_engine/about/) は、1つのフィルターに一致するすべての Finding に対して、順序付けられたアクションのリストを適用します。Triage Engine はこの機能を維持しつつ、次の4つを追加します。
* **分岐。** **If / Filter** ノードは、項目を true 分岐と false 分岐に振り分けます。これにより、1つのルールを2つに分割することなく、Critical の Finding をそれ以外と異なる方法で扱うことができます。
* **Egress。** ルールは DefectDojo の外部にアクションを送信できます。JIRA の課題やダウンストリームのチケットの起票、Slack や Microsoft Teams への投稿、メールの送信、Webhook の呼び出し、アプリ内アラートの発生、レポートの生成などが可能です。
* **トレーサビリティ。** すべての実行はノードごとに [Run](../runs/) として記録され、すべての送信は [Delivery](../deliveries/) として記録されます。Delivery には、何が送信され、どこへ送られ、どのように終了したかが正確に記録されます。
* **Simulate モード。** ルールは、実際には何も送信せずに、送信するはずだった内容を正確に記録できます。これにより、外部に影響を与える前にルールを安全にテストできます。
-両方のエンジンは並行して動作します。Rules Engine 2.0 を有効にしても、既存のルールが無効化されたり変換されたりすることはありません。ルールを移行したい場合のために [converter](../converting_from_rules_engine/) が用意されています。
+両方のエンジンは並行して動作します。Triage Engine を有効にしても、既存のルールが無効化されたり変換されたりすることはありません。ルールを移行したい場合のために [converter](../converting_from_rules_engine/) が用意されています。
-## Rules Engine 2.0 の有効化
+## Triage Engine の有効化
-Rules Engine 2.0 はベータ版であり、デフォルトでは無効になっています。スーパーユーザーが、Cloud インスタンス・On-Premise インスタンスの両方で **Settings > Feature Flags** から有効化します。[Feature Flags](/admin/feature_flags/pro__feature_flags/) を参照してください。
+Triage Engine はベータ版であり、デフォルトでは無効になっています。スーパーユーザーが、Cloud インスタンス・On-Premise インスタンスの両方で **Settings > Feature Flags** から有効化します。[Feature Flags](/admin/feature_flags/pro__feature_flags/) を参照してください。
-フラグが有効になると、サイドバーに **Rules Engine 2.0** セクションが表示され、次の3つのページが含まれます。
+フラグが有効になると、サイドバーに **Triage Engine** セクションが表示され、次の3つのページが含まれます。
| ページ | 用途 |
|------|----------------|
diff --git a/docs/content/automation/rules_engine_2/about.md b/docs/content/automation/triage_engine/about.md
similarity index 84%
rename from docs/content/automation/rules_engine_2/about.md
rename to docs/content/automation/triage_engine/about.md
index 08102876cc8..242baa0aa62 100644
--- a/docs/content/automation/rules_engine_2/about.md
+++ b/docs/content/automation/triage_engine/about.md
@@ -1,20 +1,21 @@
---
-title: "About Rules Engine 2.0"
-description: "What Rules Engine 2.0 is, how to turn it on, and the concepts it is built from"
+title: "About Triage Engine"
+description: "What Triage Engine is, how to turn it on, and the concepts it is built from"
weight: 1
audience: pro
aliases:
- /automation/rules_engine_v2/about/
+ - /automation/rules_engine_2/about/
---
-Note: Rules Engine 2.0 is a DefectDojo Pro-only feature.
+Note: Triage Engine is a DefectDojo Pro-only feature.
-Rules Engine 2.0 is a visual automation builder. Instead of a filter plus a flat list of actions, a rule is a **graph**: a trigger node that decides when the rule wakes up, and any number of logic, Finding and egress nodes wired together to say what happens next.
+Triage Engine is a visual automation builder. Instead of a filter plus a flat list of actions, a rule is a **graph**: a trigger node that decides when the rule wakes up, and any number of logic, Finding and egress nodes wired together to say what happens next.
-Rules Engine 2.0 can only be accessed through the [Pro UI](/get_started/about/ui_pro_vs_os/).
+Triage Engine can only be accessed through the [Pro UI](/get_started/about/ui_pro_vs_os/).
## What it adds over Rules Engine
-The original [Rules Engine](/automation/rules_engine/about/) applies an ordered list of actions to every Finding that matches one filter. Rules Engine 2.0 keeps that capability and adds four things:
+The original [Rules Engine](/automation/rules_engine/about/) applies an ordered list of actions to every Finding that matches one filter. Triage Engine keeps that capability and adds four things:
* **Branching.** An **If / Filter** node routes items down a true branch and a false branch, so one rule can treat Critical Findings differently from the rest without being split into two rules.
* **Egress.** A rule can leave DefectDojo: open a JIRA issue or a downstream ticket, post to Slack or Microsoft Teams, send an email, call a webhook, raise an in-app alert, or generate a report.
@@ -23,13 +24,13 @@ The original [Rules Engine](/automation/rules_engine/about/) applies an ordered
Rules are not limited to Findings. An Asset (Product) rule reacts to Assets being created, updated or tagged, or sweeps them on a schedule, and can set their fields, move them between Organizations, tag and untag them, and place them in the Asset hierarchy. That makes recurring inventory work self-service: instead of a one-off migration to regroup Assets, a rule expresses the grouping and keeps enforcing it as new Assets arrive.
-Both engines run side by side. Turning on Rules Engine 2.0 does not disable or convert your existing rules, and there is a [converter](../converting_from_rules_engine/) for when you want to move them across.
+Both engines run side by side. Turning on Triage Engine does not disable or convert your existing rules, and there is a [converter](../converting_from_rules_engine/) for when you want to move them across.
-## Enabling Rules Engine 2.0
+## Enabling Triage Engine
-Rules Engine 2.0 is in Beta and is off by default. A superuser turns it on from **Settings > Feature Flags**, on both Cloud and On-Premise instances. See [Feature Flags](/admin/feature_flags/pro__feature_flags/).
+Triage Engine is in Beta and is off by default. A superuser turns it on from **Settings > Feature Flags**, on both Cloud and On-Premise instances. See [Feature Flags](/admin/feature_flags/pro__feature_flags/).
-Once the flag is on, a **Rules Engine 2.0** section appears in the sidebar with three pages:
+Once the flag is on, a **Triage Engine** section appears in the sidebar with three pages:
| Page | What it is for |
|------|----------------|
@@ -120,7 +121,7 @@ Runs and deliveries are both kept for 180 days by default, then pruned. The prod
## Where to go next
* [Building Rules](../building_rules/) covers the editor, triggers, scope, conditions and templates.
-* [Node Reference](../node_reference/) documents all 37 nodes.
+* [Node Reference](../node_reference/) documents all 41 nodes.
* [Runs](../runs/) covers execution, traces, cascading and limits.
* [Deliveries](../deliveries/) covers channels, statuses, retries and replay.
* [Converting from Rules Engine](../converting_from_rules_engine/) covers moving existing rules across.
diff --git a/docs/content/automation/rules_engine_2/about.pt-br.md b/docs/content/automation/triage_engine/about.pt-br.md
similarity index 83%
rename from docs/content/automation/rules_engine_2/about.pt-br.md
rename to docs/content/automation/triage_engine/about.pt-br.md
index a249e0d62de..a5fe2316bc8 100644
--- a/docs/content/automation/rules_engine_2/about.pt-br.md
+++ b/docs/content/automation/triage_engine/about.pt-br.md
@@ -1,34 +1,35 @@
---
-title: Sobre o Rules Engine 2.0
-description: O que é o Rules Engine 2.0, como ativá-lo e os conceitos em que se baseia
+title: Sobre o Triage Engine
+description: O que é o Triage Engine, como ativá-lo e os conceitos em que se baseia
weight: 1
audience: pro
aliases:
- /pt-br/automation/rules_engine_v2/about/
+- /pt-br/automation/rules_engine_2/about/
---
-Nota: O Rules Engine 2.0 é um recurso exclusivo do DefectDojo Pro.
+Nota: O Triage Engine é um recurso exclusivo do DefectDojo Pro.
-Rules Engine 2.0 é um construtor visual de automação. Em vez de um filtro mais uma lista simples de ações, uma regra é um **grafo**: um nó de gatilho que decide quando a regra é ativada, e qualquer número de nós de lógica, de Achado e de saída (egress) conectados entre si para dizer o que acontece a seguir.
+Triage Engine é um construtor visual de automação. Em vez de um filtro mais uma lista simples de ações, uma regra é um **grafo**: um nó de gatilho que decide quando a regra é ativada, e qualquer número de nós de lógica, de Achado e de saída (egress) conectados entre si para dizer o que acontece a seguir.
-O Rules Engine 2.0 só pode ser acessado pela [Pro UI](/get_started/about/ui_pro_vs_os/).
+O Triage Engine só pode ser acessado pela [Pro UI](/get_started/about/ui_pro_vs_os/).
## O que ele adiciona em relação ao Rules Engine
-O [Rules Engine](/automation/rules_engine/about/) original aplica uma lista ordenada de ações a cada Achado que corresponde a um filtro. O Rules Engine 2.0 mantém essa capacidade e adiciona quatro coisas:
+O [Rules Engine](/automation/rules_engine/about/) original aplica uma lista ordenada de ações a cada Achado que corresponde a um filtro. O Triage Engine mantém essa capacidade e adiciona quatro coisas:
* **Ramificação (branching).** Um nó **If / Filter** encaminha os itens por um ramo verdadeiro e um ramo falso, de modo que uma única regra possa tratar Achados Críticos de forma diferente do restante sem precisar ser dividida em duas regras.
* **Saída (egress).** Uma regra pode sair do DefectDojo: abrir um chamado no JIRA ou em um sistema de tickets externo, publicar no Slack ou no Microsoft Teams, enviar um e-mail, chamar um webhook, disparar um alerta no aplicativo ou gerar um relatório.
* **Rastreabilidade.** Cada execução é registrada nó a nó como uma [Execução](../runs/), e cada envio de saída é registrado como uma [Entrega](../deliveries/) que informa exatamente o que foi enviado, para onde foi e como terminou.
* **Um modo de simulação.** Uma regra pode registrar exatamente o que enviaria sem enviar nada de fato, o que permite testá-la com segurança antes de deixá-la tocar o mundo externo.
-Os dois mecanismos funcionam lado a lado. Ativar o Rules Engine 2.0 não desativa nem converte suas regras existentes, e há um [conversor](../converting_from_rules_engine/) para quando você quiser migrá-las.
+Os dois mecanismos funcionam lado a lado. Ativar o Triage Engine não desativa nem converte suas regras existentes, e há um [conversor](../converting_from_rules_engine/) para quando você quiser migrá-las.
-## Ativando o Rules Engine 2.0
+## Ativando o Triage Engine
-O Rules Engine 2.0 está em Beta e vem desativado por padrão. Um superusuário o ativa em **Settings > Feature Flags**, tanto em instâncias Cloud quanto On-Premise. Veja [Feature Flags](/admin/feature_flags/pro__feature_flags/).
+O Triage Engine está em Beta e vem desativado por padrão. Um superusuário o ativa em **Settings > Feature Flags**, tanto em instâncias Cloud quanto On-Premise. Veja [Feature Flags](/admin/feature_flags/pro__feature_flags/).
-Assim que a flag é ativada, uma seção **Rules Engine 2.0** aparece na barra lateral com três páginas:
+Assim que a flag é ativada, uma seção **Triage Engine** aparece na barra lateral com três páginas:
| Página | Para que serve |
|------|----------------|
diff --git a/docs/content/automation/rules_engine_2/about.zh-hans.md b/docs/content/automation/triage_engine/about.zh-hans.md
similarity index 82%
rename from docs/content/automation/rules_engine_2/about.zh-hans.md
rename to docs/content/automation/triage_engine/about.zh-hans.md
index 4b88870e684..e4cb78fc706 100644
--- a/docs/content/automation/rules_engine_2/about.zh-hans.md
+++ b/docs/content/automation/triage_engine/about.zh-hans.md
@@ -1,34 +1,35 @@
---
-title: 关于 Rules Engine 2.0
-description: Rules Engine 2.0 是什么、如何启用它，以及它所基于的核心概念
+title: 关于 Triage Engine
+description: Triage Engine 是什么、如何启用它，以及它所基于的核心概念
weight: 1
audience: pro
aliases:
- /zh-hans/automation/rules_engine_v2/about/
+- /zh-hans/automation/rules_engine_2/about/
---
-注意：Rules Engine 2.0 是 DefectDojo Pro 专属功能。
+注意：Triage Engine 是 DefectDojo Pro 专属功能。
-Rules Engine 2.0 是一个可视化自动化构建器。规则不再是“一个过滤器加一份扁平的动作列表”，而是一个**图（graph）**：一个决定规则何时被唤醒的触发器节点，以及任意数量相互连接的逻辑、发现项和出站（egress）节点，用来说明接下来会发生什么。
+Triage Engine 是一个可视化自动化构建器。规则不再是“一个过滤器加一份扁平的动作列表”，而是一个**图（graph）**：一个决定规则何时被唤醒的触发器节点，以及任意数量相互连接的逻辑、发现项和出站（egress）节点，用来说明接下来会发生什么。
-Rules Engine 2.0 只能通过 [Pro UI](/get_started/about/ui_pro_vs_os/) 访问。
+Triage Engine 只能通过 [Pro UI](/get_started/about/ui_pro_vs_os/) 访问。
## 相较于 Rules Engine 新增了什么
-原有的 [Rules Engine](/automation/rules_engine/about/) 会将一份有序的动作列表应用到匹配某个过滤器的每一个发现项上。Rules Engine 2.0 保留了这一能力，并新增了四项内容：
+原有的 [Rules Engine](/automation/rules_engine/about/) 会将一份有序的动作列表应用到匹配某个过滤器的每一个发现项上。Triage Engine 保留了这一能力，并新增了四项内容：
* **分支。** **If / Filter** 节点会将条目分流到“真”分支和“假”分支，因此一条规则就能对严重发现项与其他发现项采取不同处理方式，而无需拆分成两条规则。
* **出站（Egress）。** 规则可以离开 DefectDojo：打开一个 JIRA 问题单或下游工单、发布到 Slack 或 Microsoft Teams、发送邮件、调用 Webhook、发出应用内提醒，或生成报告。
* **可追溯性。** 每次执行都会作为一次[运行（Run）](../runs/)按节点逐一记录，每次出站发送都会作为一条[投递记录（Delivery）](../deliveries/)记录下来，准确说明发送了什么、发到了哪里、结果如何。
* **模拟模式。** 规则可以精确记录它本会发送的内容而不实际发送，这就是在让规则接触外部世界之前安全测试它的方式。
-两套引擎并行运行。启用 Rules Engine 2.0 不会禁用或转换您现有的规则，并且提供了一个[转换器](../converting_from_rules_engine/)，供您在想要迁移规则时使用。
+两套引擎并行运行。启用 Triage Engine 不会禁用或转换您现有的规则，并且提供了一个[转换器](../converting_from_rules_engine/)，供您在想要迁移规则时使用。
-## 启用 Rules Engine 2.0
+## 启用 Triage Engine
-Rules Engine 2.0 处于 Beta 阶段，默认关闭。超级用户可以在 **Settings > Feature Flags** 中启用它，云端和本地部署实例均适用。参见[功能标志](/admin/feature_flags/pro__feature_flags/)。
+Triage Engine 处于 Beta 阶段，默认关闭。超级用户可以在 **Settings > Feature Flags** 中启用它，云端和本地部署实例均适用。参见[功能标志](/admin/feature_flags/pro__feature_flags/)。
-标志启用后，侧边栏会出现一个 **Rules Engine 2.0** 区块，下面有三个页面：
+标志启用后，侧边栏会出现一个 **Triage Engine** 区块，下面有三个页面：
| Page | What it is for |
|------|----------------|
diff --git a/docs/content/automation/rules_engine_2/building_rules.de.md b/docs/content/automation/triage_engine/building_rules.de.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/building_rules.de.md
rename to docs/content/automation/triage_engine/building_rules.de.md
index 91383c52525..7e00dcd8a8a 100644
--- a/docs/content/automation/rules_engine_2/building_rules.de.md
+++ b/docs/content/automation/triage_engine/building_rules.de.md
@@ -5,15 +5,16 @@ weight: 2
audience: pro
aliases:
- /de/automation/rules_engine_v2/building_rules/
+- /de/automation/rules_engine_2/building_rules/
---
-Note: Rules Engine 2.0 is a DefectDojo Pro-only feature.
+Note: Triage Engine is a DefectDojo Pro-only feature.
Eine Regel wird auf einer Zeichenfläche (Canvas) erstellt. Sie ziehen Knoten aus einer Palette, verbinden sie miteinander und konfigurieren jeden davon in einem Seitenpanel. Diese Seite behandelt die Teile dieses Prozesses, die unabhängig von den verwendeten Knoten gleich sind. Die Knoten selbst finden Sie in der [Node-Referenz](../node_reference/).
## Der Editor
-Öffnen Sie **Rules Engine 2.0 > All Rules** und wählen Sie **New Rule**, oder öffnen Sie eine bestehende Regel zur Bearbeitung.
+Öffnen Sie **Triage Engine > All Rules** und wählen Sie **New Rule**, oder öffnen Sie eine bestehende Regel zur Bearbeitung.
Die Palette ist in vier Kategorien gegliedert, was auch der Reihenfolge entspricht, in der Elemente einen typischen Graphen durchlaufen:
diff --git a/docs/content/automation/rules_engine_2/building_rules.es.md b/docs/content/automation/triage_engine/building_rules.es.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/building_rules.es.md
rename to docs/content/automation/triage_engine/building_rules.es.md
index 5cb523a3c03..a55ec722182 100644
--- a/docs/content/automation/rules_engine_2/building_rules.es.md
+++ b/docs/content/automation/triage_engine/building_rules.es.md
@@ -6,15 +6,16 @@ weight: 2
audience: pro
aliases:
- /es/automation/rules_engine_v2/building_rules/
+- /es/automation/rules_engine_2/building_rules/
---
-Nota: Rules Engine 2.0 es una función exclusiva de DefectDojo Pro.
+Nota: Triage Engine es una función exclusiva de DefectDojo Pro.
Una regla se construye en un lienzo. Se arrastran nodos desde una paleta, se conectan entre sí y cada uno se configura en un panel lateral. Esta página cubre las partes de ese proceso que son iguales sea cual sea el nodo que se use. Los propios nodos están en la [Referencia de nodos](../node_reference/).
## El editor
-Abra **Rules Engine 2.0 > Todas las reglas** y elija **Nueva regla**, o abra una regla existente para editarla.
+Abra **Triage Engine > Todas las reglas** y elija **Nueva regla**, o abra una regla existente para editarla.
La paleta está agrupada en cuatro categorías, que también es el orden en que los elementos fluyen a través de un grafo típico:
diff --git a/docs/content/automation/rules_engine_2/building_rules.fr.md b/docs/content/automation/triage_engine/building_rules.fr.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/building_rules.fr.md
rename to docs/content/automation/triage_engine/building_rules.fr.md
index 7c501ed757a..54e5a040af0 100644
--- a/docs/content/automation/rules_engine_2/building_rules.fr.md
+++ b/docs/content/automation/triage_engine/building_rules.fr.md
@@ -6,15 +6,16 @@ weight: 2
audience: pro
aliases:
- /fr/automation/rules_engine_v2/building_rules/
+- /fr/automation/rules_engine_2/building_rules/
---
-Remarque : Rules Engine 2.0 est une fonctionnalité réservée à DefectDojo Pro.
+Remarque : Triage Engine est une fonctionnalité réservée à DefectDojo Pro.
Une règle est construite sur un canevas. Vous glissez des nœuds depuis une palette, vous les reliez entre eux, et vous configurez chacun d'eux dans un panneau latéral. Cette page couvre les aspects de ce processus qui sont identiques quels que soient les nœuds utilisés. Les nœuds eux-mêmes sont décrits dans la [Référence des nœuds](../node_reference/).
## L'éditeur
-Ouvrez **Rules Engine 2.0 > All Rules** et choisissez **New Rule** (Nouvelle règle), ou ouvrez une règle existante pour la modifier.
+Ouvrez **Triage Engine > All Rules** et choisissez **New Rule** (Nouvelle règle), ou ouvrez une règle existante pour la modifier.
La palette est organisée en quatre catégories, qui correspondent aussi à l'ordre dans lequel les éléments traversent un graphe typique :
diff --git a/docs/content/automation/rules_engine_2/building_rules.it.md b/docs/content/automation/triage_engine/building_rules.it.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/building_rules.it.md
rename to docs/content/automation/triage_engine/building_rules.it.md
index 4eb558f5ff1..ebf37c2e8ae 100644
--- a/docs/content/automation/rules_engine_2/building_rules.it.md
+++ b/docs/content/automation/triage_engine/building_rules.it.md
@@ -6,15 +6,16 @@ weight: 2
audience: pro
aliases:
- /it/automation/rules_engine_v2/building_rules/
+- /it/automation/rules_engine_2/building_rules/
---
-Nota: Rules Engine 2.0 è una funzionalità disponibile solo in DefectDojo Pro.
+Nota: Triage Engine è una funzionalità disponibile solo in DefectDojo Pro.
Una regola si costruisce su una canvas. Si trascinano nodi da una palette, si collegano tra loro e si configura ciascuno in un pannello laterale. Questa pagina tratta le parti di questo processo che sono le stesse indipendentemente dai nodi usati. I nodi stessi sono descritti in [Node Reference](../node_reference/).
## L'editor
-Aprire **Rules Engine 2.0 > All Rules** e scegliere **New Rule**, oppure aprire una regola esistente per modificarla.
+Aprire **Triage Engine > All Rules** e scegliere **New Rule**, oppure aprire una regola esistente per modificarla.
La palette è raggruppata in quattro categorie, che rappresentano anche l'ordine in cui gli elementi attraversano un grafo tipico:
diff --git a/docs/content/automation/rules_engine_2/building_rules.ja.md b/docs/content/automation/triage_engine/building_rules.ja.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/building_rules.ja.md
rename to docs/content/automation/triage_engine/building_rules.ja.md
index 99a0d2d71d0..782addc1a15 100644
--- a/docs/content/automation/rules_engine_2/building_rules.ja.md
+++ b/docs/content/automation/triage_engine/building_rules.ja.md
@@ -5,15 +5,16 @@ weight: 2
audience: pro
aliases:
- /ja/automation/rules_engine_v2/building_rules/
+- /ja/automation/rules_engine_2/building_rules/
---
-注: Rules Engine 2.0 は DefectDojo Pro 専用の機能です。
+注: Triage Engine は DefectDojo Pro 専用の機能です。
ルールはキャンバス上で構築します。パレットからノードをドラッグして配線し、それぞれをサイドパネルで設定します。このページでは、どのノードを使う場合でも共通するプロセスの部分を扱います。ノード自体については [Node Reference](../node_reference/) を参照してください。
## エディター
-**Rules Engine 2.0 > All Rules** を開き、**New Rule** を選択するか、既存のルールを開いて編集します。
+**Triage Engine > All Rules** を開き、**New Rule** を選択するか、既存のルールを開いて編集します。
パレットは4つのカテゴリーにグループ分けされており、これは一般的なグラフの中を項目が流れていく順序でもあります。
diff --git a/docs/content/automation/rules_engine_2/building_rules.md b/docs/content/automation/triage_engine/building_rules.md
similarity index 95%
rename from docs/content/automation/rules_engine_2/building_rules.md
rename to docs/content/automation/triage_engine/building_rules.md
index fb51f01fa98..9d745e847a5 100644
--- a/docs/content/automation/rules_engine_2/building_rules.md
+++ b/docs/content/automation/triage_engine/building_rules.md
@@ -5,14 +5,15 @@ weight: 2
audience: pro
aliases:
- /automation/rules_engine_v2/building_rules/
+ - /automation/rules_engine_2/building_rules/
---
-Note: Rules Engine 2.0 is a DefectDojo Pro-only feature.
+Note: Triage Engine is a DefectDojo Pro-only feature.
A rule is built on a canvas. You drag nodes out of a palette, wire them together, and configure each one in a side panel. This page covers the parts of that process that are the same whichever nodes you use. The nodes themselves are in the [Node Reference](../node_reference/).
## Starting a rule
-From **Rules Engine 2.0 > All Rules** there are two ways to begin.
+From **Triage Engine > All Rules** there are two ways to begin.
**From Template** opens a gallery of rules that ship with DefectDojo, grouped into packs. Each card
says what the rule is for, which nodes its graph contains, and what you have to configure before it
@@ -88,12 +89,15 @@ The scope editor follows the kind too: a Finding trigger's scope opens the Findi
## Triggers and scope
-Every graph starts with one of four triggers.
+Every graph starts with exactly one trigger.
* **On Finding Event** wakes the rule when Findings are created, updated, closed or reopened. Choose which of those in the node's **Event** setting, or `any` for all four.
* **On Asset Event** wakes the rule when Assets are created or updated, tag changes included.
* **On a Schedule** sweeps everything in scope on a recurring schedule, Findings or Assets per its **Sweep Over** setting.
* **Manual Run** sweeps everything in scope when you press **Run** on the rule, Findings or Assets per its **Sweep Over** setting.
+* **On a Missing Scan** runs on a schedule and reports Assets whose expected scan has not arrived.
+* **When a Scan Has Landed** wakes the rule once for each scan import that finishes, or fails, on an Asset in scope.
+* **When a Group of Scans Has Landed** waits for a set of scan types to finish importing into an Asset and wakes the rule once for the whole group, down a `complete` or `incomplete` output. See the [Node Reference](../node_reference/) for how a group is defined and what happens when a scan fails or never arrives.
### Scope
@@ -325,6 +329,8 @@ Templates also see a `ctx` block carrying details about the run itself. The keys
| `{{ctx.findings_html}}` | The rendered Finding list, in the email node |
| `{{ctx.report_url}}` | The download link, in the report node |
| `{{ctx.template_name}}` | The report template name, in the report node |
+| `{{ctx.imports_html}}` | The rendered list of a scan group's imports and how each ended, in the email node |
+| `{{ctx.import_summary}}` | One line about a scan group, for example "3 of 4 feeds arrived; missing: ZAP Scan" |
Templates are plain substitution. There is no expression evaluation, no code execution, and no attribute access on objects anywhere in a rule config.
diff --git a/docs/content/automation/rules_engine_2/building_rules.pt-br.md b/docs/content/automation/triage_engine/building_rules.pt-br.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/building_rules.pt-br.md
rename to docs/content/automation/triage_engine/building_rules.pt-br.md
index 52775013257..dc4bcbc1e49 100644
--- a/docs/content/automation/rules_engine_2/building_rules.pt-br.md
+++ b/docs/content/automation/triage_engine/building_rules.pt-br.md
@@ -5,15 +5,16 @@ weight: 2
audience: pro
aliases:
- /pt-br/automation/rules_engine_v2/building_rules/
+- /pt-br/automation/rules_engine_2/building_rules/
---
-Nota: O Rules Engine 2.0 é um recurso exclusivo do DefectDojo Pro.
+Nota: O Triage Engine é um recurso exclusivo do DefectDojo Pro.
Uma regra é construída em uma tela (canvas). Você arrasta nós de uma paleta, os conecta entre si e configura cada um em um painel lateral. Esta página aborda as partes desse processo que são iguais independentemente dos nós usados. Os próprios nós estão descritos em [Node Reference](../node_reference/).
## O editor
-Abra **Rules Engine 2.0 > All Rules** e escolha **New Rule**, ou abra uma regra existente para editá-la.
+Abra **Triage Engine > All Rules** e escolha **New Rule**, ou abra uma regra existente para editá-la.
A paleta é agrupada em quatro categorias, que também é a ordem em que os itens fluem por um grafo típico:
diff --git a/docs/content/automation/rules_engine_2/building_rules.zh-hans.md b/docs/content/automation/triage_engine/building_rules.zh-hans.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/building_rules.zh-hans.md
rename to docs/content/automation/triage_engine/building_rules.zh-hans.md
index f63b1040549..c7531cbe63a 100644
--- a/docs/content/automation/rules_engine_2/building_rules.zh-hans.md
+++ b/docs/content/automation/triage_engine/building_rules.zh-hans.md
@@ -5,15 +5,16 @@ weight: 2
audience: pro
aliases:
- /zh-hans/automation/rules_engine_v2/building_rules/
+- /zh-hans/automation/rules_engine_2/building_rules/
---
-注意：Rules Engine 2.0 是 DefectDojo Pro 专属功能。
+注意：Triage Engine 是 DefectDojo Pro 专属功能。
规则是在画布上构建的。您从调色板中拖出节点，将它们连接起来，并在侧边面板中配置每一个节点。本页介绍的是这一过程中不论使用哪些节点都相同的部分。节点本身的说明请见[节点参考](../node_reference/)。
## 编辑器
-打开 **Rules Engine 2.0 > All Rules**，选择 **New Rule**，或打开一条已有规则进行编辑。
+打开 **Triage Engine > All Rules**，选择 **New Rule**，或打开一条已有规则进行编辑。
调色板分为四个类别，这也是条目在典型图中流动的顺序：
diff --git a/docs/content/automation/rules_engine_2/configuration.de.md b/docs/content/automation/triage_engine/configuration.de.md
similarity index 90%
rename from docs/content/automation/rules_engine_2/configuration.de.md
rename to docs/content/automation/triage_engine/configuration.de.md
index 6f58ca5bb20..26baffad99f 100644
--- a/docs/content/automation/rules_engine_2/configuration.de.md
+++ b/docs/content/automation/triage_engine/configuration.de.md
@@ -1,17 +1,18 @@
---
title: Konfiguration
-description: Einstellungen auf Deployment-Ebene für Rules Engine 2.0
+description: Einstellungen auf Deployment-Ebene für Triage Engine
weight: 7
audience: pro
aliases:
- /de/automation/rules_engine_v2/configuration/
+- /de/automation/rules_engine_2/configuration/
---
-Note: Rules Engine 2.0 is a DefectDojo Pro-only feature.
+Note: Triage Engine is a DefectDojo Pro-only feature.
-Rules Engine 2.0 funktioniert von Haus aus. Die Einstellungen auf dieser Seite richten sich an Deployments, die Durchsatz, Aufbewahrung oder die Richtlinie für ausgehenden Netzwerkverkehr anpassen müssen. Alle werden auf dieselbe Weise angewendet wie jede andere DefectDojo-Einstellung (siehe [Konfiguration](/get_started/open_source/configuration/)).
+Triage Engine funktioniert von Haus aus. Die Einstellungen auf dieser Seite richten sich an Deployments, die Durchsatz, Aufbewahrung oder die Richtlinie für ausgehenden Netzwerkverkehr anpassen müssen. Alle werden auf dieselbe Weise angewendet wie jede andere DefectDojo-Einstellung (siehe [Konfiguration](/get_started/open_source/configuration/)).
-Rules Engine 2.0 wird getrennt von der ursprünglichen Rules Engine konfiguriert. Die beiden Engines teilen sich kein Tuning, sodass eine `DD_RULES_ENGINE_*`-Einstellung sich nicht auf Rules Engine 2.0 auswirkt und eine `DD_RULES_V2_*`-Einstellung sich nicht auf die ursprüngliche Engine auswirkt.
+Triage Engine wird getrennt von der ursprünglichen Rules Engine konfiguriert. Die beiden Engines teilen sich kein Tuning, sodass eine `DD_RULES_ENGINE_*`-Einstellung sich nicht auf Triage Engine auswirkt und eine `DD_RULES_V2_*`-Einstellung sich nicht auf die ursprüngliche Engine auswirkt.
```python
DD_RULES_V2_EVENT_BATCH=(int, 500),
diff --git a/docs/content/automation/rules_engine_2/configuration.es.md b/docs/content/automation/triage_engine/configuration.es.md
similarity index 90%
rename from docs/content/automation/rules_engine_2/configuration.es.md
rename to docs/content/automation/triage_engine/configuration.es.md
index 93c8d5027d9..dd70dcb5c12 100644
--- a/docs/content/automation/rules_engine_2/configuration.es.md
+++ b/docs/content/automation/triage_engine/configuration.es.md
@@ -1,17 +1,18 @@
---
title: Configuración
-description: Ajustes a nivel de despliegue para Rules Engine 2.0
+description: Ajustes a nivel de despliegue para Triage Engine
weight: 7
audience: pro
aliases:
- /es/automation/rules_engine_v2/configuration/
+- /es/automation/rules_engine_2/configuration/
---
-Nota: Rules Engine 2.0 es una función exclusiva de DefectDojo Pro.
+Nota: Triage Engine es una función exclusiva de DefectDojo Pro.
-Rules Engine 2.0 funciona de fábrica. Los ajustes de esta página son para despliegues que necesitan afinar el rendimiento, la retención o la política de red saliente. Todos se aplican de la misma manera que cualquier otro ajuste de DefectDojo (consulte [Configuración](/get_started/open_source/configuration/)).
+Triage Engine funciona de fábrica. Los ajustes de esta página son para despliegues que necesitan afinar el rendimiento, la retención o la política de red saliente. Todos se aplican de la misma manera que cualquier otro ajuste de DefectDojo (consulte [Configuración](/get_started/open_source/configuration/)).
-Rules Engine 2.0 se configura por separado del Rules Engine original. Los dos motores no comparten ningún ajuste, de modo que un ajuste `DD_RULES_ENGINE_*` no afecta a Rules Engine 2.0 y un ajuste `DD_RULES_V2_*` no afecta al motor original.
+Triage Engine se configura por separado del Rules Engine original. Los dos motores no comparten ningún ajuste, de modo que un ajuste `DD_RULES_ENGINE_*` no afecta a Triage Engine y un ajuste `DD_RULES_V2_*` no afecta al motor original.
```python
DD_RULES_V2_EVENT_BATCH=(int, 500),
@@ -133,7 +134,7 @@ Superado este límite, el nodo registra una **omisión visible** que indica sobr
## Ajustes relacionados
-Algunos nodos de Rules Engine 2.0 usan la configuración de integración de todo el sistema en lugar de la propia:
+Algunos nodos de Triage Engine usan la configuración de integración de todo el sistema en lugar de la propia:
* **Enviar un mensaje de Slack** usa el token de Slack del sistema, y recurre al canal de Slack del sistema cuando el nodo no indica ninguno.
* **Enviar un mensaje de Microsoft Teams** usa el webhook de Microsoft Teams de los ajustes del sistema.
diff --git a/docs/content/automation/rules_engine_2/configuration.fr.md b/docs/content/automation/triage_engine/configuration.fr.md
similarity index 90%
rename from docs/content/automation/rules_engine_2/configuration.fr.md
rename to docs/content/automation/triage_engine/configuration.fr.md
index c04669e81f0..162dc13a907 100644
--- a/docs/content/automation/rules_engine_2/configuration.fr.md
+++ b/docs/content/automation/triage_engine/configuration.fr.md
@@ -1,17 +1,18 @@
---
title: Configuration
-description: Paramètres au niveau du déploiement pour Rules Engine 2.0
+description: Paramètres au niveau du déploiement pour Triage Engine
weight: 7
audience: pro
aliases:
- /fr/automation/rules_engine_v2/configuration/
+- /fr/automation/rules_engine_2/configuration/
---
-Remarque : Rules Engine 2.0 est une fonctionnalité réservée à DefectDojo Pro.
+Remarque : Triage Engine est une fonctionnalité réservée à DefectDojo Pro.
-Rules Engine 2.0 fonctionne dès l'installation. Les paramètres de cette page s'adressent aux déploiements qui ont besoin d'ajuster le débit, la rétention ou la politique réseau sortante. Ils s'appliquent tous de la même manière que n'importe quel autre paramètre DefectDojo (voir [Configuration](/get_started/open_source/configuration/)).
+Triage Engine fonctionne dès l'installation. Les paramètres de cette page s'adressent aux déploiements qui ont besoin d'ajuster le débit, la rétention ou la politique réseau sortante. Ils s'appliquent tous de la même manière que n'importe quel autre paramètre DefectDojo (voir [Configuration](/get_started/open_source/configuration/)).
-Rules Engine 2.0 se configure séparément du Rules Engine d'origine. Les deux moteurs ne partagent aucun réglage : un paramètre `DD_RULES_ENGINE_*` n'affecte pas Rules Engine 2.0, et un paramètre `DD_RULES_V2_*` n'affecte pas le moteur d'origine.
+Triage Engine se configure séparément du Rules Engine d'origine. Les deux moteurs ne partagent aucun réglage : un paramètre `DD_RULES_ENGINE_*` n'affecte pas Triage Engine, et un paramètre `DD_RULES_V2_*` n'affecte pas le moteur d'origine.
```python
DD_RULES_V2_EVENT_BATCH=(int, 500),
@@ -133,7 +134,7 @@ Au-delà de ce plafond, le nœud enregistre un **saut visible** indiquant combie
## Paramètres associés
-Certains nœuds de Rules Engine 2.0 utilisent une configuration d'intégration à l'échelle du système plutôt que la leur propre :
+Certains nœuds de Triage Engine utilisent une configuration d'intégration à l'échelle du système plutôt que la leur propre :
* **Send a Slack Message** (Envoyer un message Slack) utilise le jeton Slack du système, et se rabat sur le canal Slack du système lorsque le nœud n'en nomme aucun.
* **Send a Microsoft Teams Message** (Envoyer un message Microsoft Teams) utilise le webhook Microsoft Teams des paramètres système.
diff --git a/docs/content/automation/rules_engine_2/configuration.it.md b/docs/content/automation/triage_engine/configuration.it.md
similarity index 89%
rename from docs/content/automation/rules_engine_2/configuration.it.md
rename to docs/content/automation/triage_engine/configuration.it.md
index 2b5f8c26c72..a157c74ac10 100644
--- a/docs/content/automation/rules_engine_2/configuration.it.md
+++ b/docs/content/automation/triage_engine/configuration.it.md
@@ -1,17 +1,18 @@
---
title: Configurazione
-description: Impostazioni a livello di deployment per Rules Engine 2.0
+description: Impostazioni a livello di deployment per Triage Engine
weight: 7
audience: pro
aliases:
- /it/automation/rules_engine_v2/configuration/
+- /it/automation/rules_engine_2/configuration/
---
-Nota: Rules Engine 2.0 è una funzionalità disponibile solo in DefectDojo Pro.
+Nota: Triage Engine è una funzionalità disponibile solo in DefectDojo Pro.
-Rules Engine 2.0 funziona subito, senza configurazione. Le impostazioni di questa pagina servono ai deployment che devono ottimizzare il throughput, la conservazione o la politica di rete in uscita. Tutte vengono applicate allo stesso modo di qualsiasi altra impostazione di DefectDojo (vedere [Configuration](/get_started/open_source/configuration/)).
+Triage Engine funziona subito, senza configurazione. Le impostazioni di questa pagina servono ai deployment che devono ottimizzare il throughput, la conservazione o la politica di rete in uscita. Tutte vengono applicate allo stesso modo di qualsiasi altra impostazione di DefectDojo (vedere [Configuration](/get_started/open_source/configuration/)).
-Rules Engine 2.0 viene configurato separatamente dal Rules Engine originale. I due motori non condividono alcuna impostazione: un'impostazione `DD_RULES_ENGINE_*` non influisce su Rules Engine 2.0 e un'impostazione `DD_RULES_V2_*` non influisce sul motore originale.
+Triage Engine viene configurato separatamente dal Rules Engine originale. I due motori non condividono alcuna impostazione: un'impostazione `DD_RULES_ENGINE_*` non influisce su Triage Engine e un'impostazione `DD_RULES_V2_*` non influisce sul motore originale.
```python
DD_RULES_V2_EVENT_BATCH=(int, 500),
@@ -133,7 +134,7 @@ Oltre questo tetto il nodo registra un'**omissione visibile** che indica quanti
## Impostazioni correlate
-Alcuni nodi di Rules Engine 2.0 usano la configurazione di integrazione a livello di sistema invece della propria:
+Alcuni nodi di Triage Engine usano la configurazione di integrazione a livello di sistema invece della propria:
* **Send a Slack Message** usa il token Slack di sistema, e ricade sul canale Slack di sistema quando il nodo non ne indica uno.
* **Send a Microsoft Teams Message** usa il webhook Microsoft Teams dalle impostazioni di sistema.
diff --git a/docs/content/automation/rules_engine_2/configuration.ja.md b/docs/content/automation/triage_engine/configuration.ja.md
similarity index 90%
rename from docs/content/automation/rules_engine_2/configuration.ja.md
rename to docs/content/automation/triage_engine/configuration.ja.md
index 6d85dafd129..c99911f858a 100644
--- a/docs/content/automation/rules_engine_2/configuration.ja.md
+++ b/docs/content/automation/triage_engine/configuration.ja.md
@@ -1,17 +1,18 @@
---
title: 設定
-description: Rules Engine 2.0 のデプロイメントレベルの設定
+description: Triage Engine のデプロイメントレベルの設定
weight: 7
audience: pro
aliases:
- /ja/automation/rules_engine_v2/configuration/
+- /ja/automation/rules_engine_2/configuration/
---
-注: Rules Engine 2.0 は DefectDojo Pro 専用の機能です。
+注: Triage Engine は DefectDojo Pro 専用の機能です。
-Rules Engine 2.0 は、そのままの状態で動作します。このページの設定は、スループット、保持期間、または送信先ネットワークポリシーを調整する必要があるデプロイメント向けのものです。これらはすべて、他の DefectDojo の設定と同じ方法で適用されます([設定](/get_started/open_source/configuration/) を参照)。
+Triage Engine は、そのままの状態で動作します。このページの設定は、スループット、保持期間、または送信先ネットワークポリシーを調整する必要があるデプロイメント向けのものです。これらはすべて、他の DefectDojo の設定と同じ方法で適用されます([設定](/get_started/open_source/configuration/) を参照)。
-Rules Engine 2.0 は、従来の Rules Engine とは別に設定されます。両エンジンの間でチューニングは共有されないため、`DD_RULES_ENGINE_*` の設定は Rules Engine 2.0 に影響を与えず、`DD_RULES_V2_*` の設定は従来のエンジンに影響を与えません。
+Triage Engine は、従来の Rules Engine とは別に設定されます。両エンジンの間でチューニングは共有されないため、`DD_RULES_ENGINE_*` の設定は Triage Engine に影響を与えず、`DD_RULES_V2_*` の設定は従来のエンジンに影響を与えません。
```python
DD_RULES_V2_EVENT_BATCH=(int, 500),
@@ -133,7 +134,7 @@ Webhook の URL については、次の通りです。
## 関連する設定
-一部の Rules Engine 2.0 ノードは、独自の設定ではなくシステム全体のインテグレーション設定を使用します。
+一部の Triage Engine ノードは、独自の設定ではなくシステム全体のインテグレーション設定を使用します。
* **Send a Slack Message** はシステムの Slack トークンを使用し、ノードでチャンネルが指定されていない場合はシステムの Slack チャンネルにフォールバックします。
* **Send a Microsoft Teams Message** は、システム設定の Microsoft Teams webhook を使用します。
diff --git a/docs/content/automation/rules_engine_2/configuration.md b/docs/content/automation/triage_engine/configuration.md
similarity index 89%
rename from docs/content/automation/rules_engine_2/configuration.md
rename to docs/content/automation/triage_engine/configuration.md
index 1f28ab56de0..5fe3197228f 100644
--- a/docs/content/automation/rules_engine_2/configuration.md
+++ b/docs/content/automation/triage_engine/configuration.md
@@ -1,16 +1,17 @@
---
title: "Configuration"
-description: "Deployment level settings for Rules Engine 2.0"
+description: "Deployment level settings for Triage Engine"
weight: 7
audience: pro
aliases:
- /automation/rules_engine_v2/configuration/
+ - /automation/rules_engine_2/configuration/
---
-Note: Rules Engine 2.0 is a DefectDojo Pro-only feature.
+Note: Triage Engine is a DefectDojo Pro-only feature.
-Rules Engine 2.0 works out of the box. The settings on this page are for deployments that need to tune throughput, retention, or outbound network policy. All of them are applied the same way as any other DefectDojo setting (see [Configuration](/get_started/open_source/configuration/)).
+Triage Engine works out of the box. The settings on this page are for deployments that need to tune throughput, retention, or outbound network policy. All of them are applied the same way as any other DefectDojo setting (see [Configuration](/get_started/open_source/configuration/)).
-Rules Engine 2.0 is configured separately from the original Rules Engine. The two engines share no tuning, so a `DD_RULES_ENGINE_*` setting does not affect Rules Engine 2.0 and a `DD_RULES_V2_*` setting does not affect the original engine.
+Triage Engine is configured separately from the original Rules Engine. The two engines share no tuning, so a `DD_RULES_ENGINE_*` setting does not affect Triage Engine and a `DD_RULES_V2_*` setting does not affect the original engine.
```python
DD_RULES_V2_EVENT_BATCH=(int, 500),
@@ -132,7 +133,7 @@ Past this ceiling the node records a **visible skip** saying how many items it d
## Related settings
-Some Rules Engine 2.0 nodes use system-wide integration configuration rather than their own:
+Some Triage Engine nodes use system-wide integration configuration rather than their own:
* **Send a Slack Message** uses the system Slack token, and falls back to the system Slack channel when the node names none.
* **Send a Microsoft Teams Message** uses the Microsoft Teams webhook from system settings.
diff --git a/docs/content/automation/rules_engine_2/configuration.pt-br.md b/docs/content/automation/triage_engine/configuration.pt-br.md
similarity index 89%
rename from docs/content/automation/rules_engine_2/configuration.pt-br.md
rename to docs/content/automation/triage_engine/configuration.pt-br.md
index a7347f07c89..ceaa3e4006b 100644
--- a/docs/content/automation/rules_engine_2/configuration.pt-br.md
+++ b/docs/content/automation/triage_engine/configuration.pt-br.md
@@ -1,17 +1,18 @@
---
title: Configuração
-description: Configurações em nível de implantação para o Rules Engine 2.0
+description: Configurações em nível de implantação para o Triage Engine
weight: 7
audience: pro
aliases:
- /pt-br/automation/rules_engine_v2/configuration/
+- /pt-br/automation/rules_engine_2/configuration/
---
-Nota: O Rules Engine 2.0 é um recurso exclusivo do DefectDojo Pro.
+Nota: O Triage Engine é um recurso exclusivo do DefectDojo Pro.
-O Rules Engine 2.0 funciona pronto para uso. As configurações desta página são para implantações que precisam ajustar throughput, retenção ou a política de rede de saída. Todas elas são aplicadas da mesma forma que qualquer outra configuração do DefectDojo (veja [Configuration](/get_started/open_source/configuration/)).
+O Triage Engine funciona pronto para uso. As configurações desta página são para implantações que precisam ajustar throughput, retenção ou a política de rede de saída. Todas elas são aplicadas da mesma forma que qualquer outra configuração do DefectDojo (veja [Configuration](/get_started/open_source/configuration/)).
-O Rules Engine 2.0 é configurado separadamente do Rules Engine original. Os dois mecanismos não compartilham nenhum ajuste, portanto uma configuração `DD_RULES_ENGINE_*` não afeta o Rules Engine 2.0, e uma configuração `DD_RULES_V2_*` não afeta o mecanismo original.
+O Triage Engine é configurado separadamente do Rules Engine original. Os dois mecanismos não compartilham nenhum ajuste, portanto uma configuração `DD_RULES_ENGINE_*` não afeta o Triage Engine, e uma configuração `DD_RULES_V2_*` não afeta o mecanismo original.
```python
DD_RULES_V2_EVENT_BATCH=(int, 500),
@@ -133,7 +134,7 @@ Após esse limite, o nó registra uma **omissão visível (visible skip)** infor
## Configurações relacionadas
-Alguns nós do Rules Engine 2.0 usam a configuração de integração de todo o sistema, em vez da própria:
+Alguns nós do Triage Engine usam a configuração de integração de todo o sistema, em vez da própria:
* **Send a Slack Message** usa o token do Slack do sistema, e recorre ao canal do Slack do sistema quando o nó não indica nenhum.
* **Send a Microsoft Teams Message** usa o webhook do Microsoft Teams das configurações do sistema.
diff --git a/docs/content/automation/rules_engine_2/configuration.zh-hans.md b/docs/content/automation/triage_engine/configuration.zh-hans.md
similarity index 90%
rename from docs/content/automation/rules_engine_2/configuration.zh-hans.md
rename to docs/content/automation/triage_engine/configuration.zh-hans.md
index e43bd7ec366..5303a6336b1 100644
--- a/docs/content/automation/rules_engine_2/configuration.zh-hans.md
+++ b/docs/content/automation/triage_engine/configuration.zh-hans.md
@@ -1,17 +1,18 @@
---
title: 配置
-description: Rules Engine 2.0 的部署层面设置
+description: Triage Engine 的部署层面设置
weight: 7
audience: pro
aliases:
- /zh-hans/automation/rules_engine_v2/configuration/
+- /zh-hans/automation/rules_engine_2/configuration/
---
-注意：Rules Engine 2.0 是 DefectDojo Pro 专属功能。
+注意：Triage Engine 是 DefectDojo Pro 专属功能。
-Rules Engine 2.0 开箱即用。本页的设置面向那些需要调整吞吐量、保留期或出站网络策略的部署环境。所有这些设置的应用方式都与其他任何 DefectDojo 设置相同（参见[配置](/get_started/open_source/configuration/)）。
+Triage Engine 开箱即用。本页的设置面向那些需要调整吞吐量、保留期或出站网络策略的部署环境。所有这些设置的应用方式都与其他任何 DefectDojo 设置相同（参见[配置](/get_started/open_source/configuration/)）。
-Rules Engine 2.0 与原有的 Rules Engine 分开配置。两套引擎不共享任何调优参数，因此 `DD_RULES_ENGINE_*` 设置不会影响 Rules Engine 2.0，`DD_RULES_V2_*` 设置也不会影响原有引擎。
+Triage Engine 与原有的 Rules Engine 分开配置。两套引擎不共享任何调优参数，因此 `DD_RULES_ENGINE_*` 设置不会影响 Triage Engine，`DD_RULES_V2_*` 设置也不会影响原有引擎。
```python
DD_RULES_V2_EVENT_BATCH=(int, 500),
@@ -133,7 +134,7 @@ DD_RULES_V2_MAX_PER_ITEM_SENDS=(int, 1000),
## 相关设置
-部分 Rules Engine 2.0 节点使用的是系统级的集成配置，而不是节点自身的配置：
+部分 Triage Engine 节点使用的是系统级的集成配置，而不是节点自身的配置：
* **Send a Slack Message** 使用系统级的 Slack 令牌，如果节点未指定频道，则回退使用系统级的 Slack 频道。
* **Send a Microsoft Teams Message** 使用系统设置中的 Microsoft Teams Webhook。
diff --git a/docs/content/automation/rules_engine_2/converting_from_rules_engine.de.md b/docs/content/automation/triage_engine/converting_from_rules_engine.de.md
similarity index 89%
rename from docs/content/automation/rules_engine_2/converting_from_rules_engine.de.md
rename to docs/content/automation/triage_engine/converting_from_rules_engine.de.md
index 299dd19f065..f7a9cd16de7 100644
--- a/docs/content/automation/rules_engine_2/converting_from_rules_engine.de.md
+++ b/docs/content/automation/triage_engine/converting_from_rules_engine.de.md
@@ -5,11 +5,12 @@ weight: 6
audience: pro
aliases:
- /de/automation/rules_engine_v2/converting_from_rules_engine/
+- /de/automation/rules_engine_2/converting_from_rules_engine/
---
-Note: Rules Engine 2.0 is a DefectDojo Pro-only feature.
+Note: Triage Engine is a DefectDojo Pro-only feature.
-Beide Engines laufen nebeneinander. Das Aktivieren von Rules Engine 2.0 ändert nichts an Ihren bestehenden [Rules Engine](/automation/rules_engine/about/)-Regeln, und es gibt keine Frist, bis zu der Sie diese migrieren müssen.
+Beide Engines laufen nebeneinander. Das Aktivieren von Triage Engine ändert nichts an Ihren bestehenden [Rules Engine](/automation/rules_engine/about/)-Regeln, und es gibt keine Frist, bis zu der Sie diese migrieren müssen.
Wenn Sie sie migrieren möchten, gibt es dafür einen Konverter. Er übersetzt eine Rules-Engine-Regel (ein Filter plus eine geordnete Liste von Aktionen) in einen gleichwertigen Rules-Engine-2.0-Graphen.
@@ -71,14 +72,14 @@ Vier Dinge, auf die Sie sich einstellen sollten. Der Konverter meldet diese als
* **Der Lauf-Verlauf bleibt, wo er ist.** Der bestehende Lauf-Verlauf sowie die betroffenen und übersprungenen Datensätze verbleiben in der Rules-Engine-Benutzeroberfläche. Sie werden nicht kopiert.
* **Zeitpläne werden standardmäßig nicht aktiviert.** Eine zeitplan-ausgelöste Regel wird konvertiert, aber ihr Zeitplan wird nur kopiert, wenn Sie `--activate-schedules` übergeben. Dadurch bleibt die alleinige Verantwortung für aktive Zeitpläne bei der ursprünglichen Engine, solange beide laufen, sodass eine konvertierte Regel nicht heimlich zu feuern beginnen kann. Wenn Sie einen Zeitplan tatsächlich kopieren, erhält die Kopie einen eigenen Namen, damit sie nicht mit dem Original kollidiert.
-* **Das Nebenläufigkeitsmodell ist unterschiedlich.** Rules Engine hat eine instanzweite Laufsperre. Rules Engine 2.0 serialisiert pro Regel, sodass unterschiedliche Regeln gleichzeitig laufen. Eine Gruppe von Regeln, die sich früher abgewechselt hat, überlappt sich nun.
+* **Das Nebenläufigkeitsmodell ist unterschiedlich.** Rules Engine hat eine instanzweite Laufsperre. Triage Engine serialisiert pro Regel, sodass unterschiedliche Regeln gleichzeitig laufen. Eine Gruppe von Regeln, die sich früher abgewechselt hat, überlappt sich nun.
* **Eine Aktion hat keine Entsprechung.** Eine Aktion „Falsch-positiv auf false setzen“ kann nicht als Rules-Engine-2.0-Knoten ausgedrückt werden und muss von Hand konvertiert werden.
Eine Regel, deren Eigentümer nicht gesetzt ist, wird mit einer Warnung konvertiert. Denken Sie daran, dass eine Regel ohne Eigentümer keine Befunde sieht, weisen Sie also einen zu, bevor Sie sie aktivieren.
## Eine vorgeschlagene Reihenfolge
-1. Aktivieren Sie Rules Engine 2.0 und lassen Sie Ihre bestehenden Regeln weiterlaufen.
+1. Aktivieren Sie Triage Engine und lassen Sie Ihre bestehenden Regeln weiterlaufen.
2. Führen Sie den Konverter mit `--dry-run` aus und lesen Sie den Bericht.
3. Konvertieren Sie. Alles landet deaktiviert.
4. Öffnen Sie jede konvertierte Regel, prüfen Sie den Graphen und belassen Sie den Modus auf **Simulate**.
diff --git a/docs/content/automation/rules_engine_2/converting_from_rules_engine.es.md b/docs/content/automation/triage_engine/converting_from_rules_engine.es.md
similarity index 87%
rename from docs/content/automation/rules_engine_2/converting_from_rules_engine.es.md
rename to docs/content/automation/triage_engine/converting_from_rules_engine.es.md
index 6e6b78167a0..e3ee1dd9a04 100644
--- a/docs/content/automation/rules_engine_2/converting_from_rules_engine.es.md
+++ b/docs/content/automation/triage_engine/converting_from_rules_engine.es.md
@@ -1,17 +1,18 @@
---
title: Migración desde Rules Engine
-description: Migrar reglas existentes de Rules Engine a grafos de Rules Engine 2.0
+description: Migrar reglas existentes de Rules Engine a grafos de Triage Engine
weight: 6
audience: pro
aliases:
- /es/automation/rules_engine_v2/converting_from_rules_engine/
+- /es/automation/rules_engine_2/converting_from_rules_engine/
---
-Nota: Rules Engine 2.0 es una función exclusiva de DefectDojo Pro.
+Nota: Triage Engine es una función exclusiva de DefectDojo Pro.
-Ambos motores funcionan en paralelo. Activar Rules Engine 2.0 no cambia nada de las reglas existentes del [Rules Engine](/automation/rules_engine/about/), y no hay ningún plazo para migrarlas.
+Ambos motores funcionan en paralelo. Activar Triage Engine no cambia nada de las reglas existentes del [Rules Engine](/automation/rules_engine/about/), y no hay ningún plazo para migrarlas.
-Cuando llegue el momento de migrarlas, existe un conversor. Traduce una regla de Rules Engine (un filtro más una lista ordenada de acciones) en un grafo equivalente de Rules Engine 2.0.
+Cuando llegue el momento de migrarlas, existe un conversor. Traduce una regla de Rules Engine (un filtro más una lista ordenada de acciones) en un grafo equivalente de Triage Engine.
## Qué garantiza el conversor
@@ -71,14 +72,14 @@ Cuatro cosas para las que hay que planificar. El conversor las informa como nota
* **El historial de ejecuciones permanece donde está.** El historial de ejecuciones existente, y sus registros afectados y omitidos, permanecen en la interfaz de Rules Engine. No se copian.
* **Las programaciones no se activan de forma predeterminada.** Una regla activada por programación se convierte, pero su programación no se copia a menos que se pase `--activate-schedules`. Esto mantiene la propiedad exclusiva de las programaciones activas en el motor original mientras ambos están en funcionamiento, de modo que una regla convertida no puede empezar a dispararse sin que se note. Cuando sí se copia una programación, la copia recibe un nombre distinto para no colisionar con la original.
-* **El modelo de concurrencia es diferente.** Rules Engine tiene un único bloqueo de ejecución para toda la instancia. Rules Engine 2.0 serializa por regla, de modo que reglas distintas se ejecutan de forma concurrente. Un conjunto de reglas que antes se turnaban ahora se solaparán.
-* **Una acción no tiene equivalente.** Una acción de "establecer falso positivo en falso" no se puede expresar como un nodo de Rules Engine 2.0 y debe convertirse a mano.
+* **El modelo de concurrencia es diferente.** Rules Engine tiene un único bloqueo de ejecución para toda la instancia. Triage Engine serializa por regla, de modo que reglas distintas se ejecutan de forma concurrente. Un conjunto de reglas que antes se turnaban ahora se solaparán.
+* **Una acción no tiene equivalente.** Una acción de "establecer falso positivo en falso" no se puede expresar como un nodo de Triage Engine y debe convertirse a mano.
Una regla sin propietario asignado se convierte, con una advertencia. Recuerde que una regla sin propietario no ve ningún Hallazgo, así que asigne uno antes de activarla.
## Un orden sugerido
-1. Active Rules Engine 2.0 y deje sus reglas existentes en funcionamiento.
+1. Active Triage Engine y deje sus reglas existentes en funcionamiento.
2. Ejecute el conversor con `--dry-run` y lea el informe.
3. Convierta. Todo queda desactivado.
4. Abra cada regla convertida, revise el grafo y deje el modo en **Simulación**.
diff --git a/docs/content/automation/rules_engine_2/converting_from_rules_engine.fr.md b/docs/content/automation/triage_engine/converting_from_rules_engine.fr.md
similarity index 88%
rename from docs/content/automation/rules_engine_2/converting_from_rules_engine.fr.md
rename to docs/content/automation/triage_engine/converting_from_rules_engine.fr.md
index 938da1afa75..ea95cd8ef6c 100644
--- a/docs/content/automation/rules_engine_2/converting_from_rules_engine.fr.md
+++ b/docs/content/automation/triage_engine/converting_from_rules_engine.fr.md
@@ -6,13 +6,14 @@ weight: 6
audience: pro
aliases:
- /fr/automation/rules_engine_v2/converting_from_rules_engine/
+- /fr/automation/rules_engine_2/converting_from_rules_engine/
---
-Remarque : Rules Engine 2.0 est une fonctionnalité réservée à DefectDojo Pro.
+Remarque : Triage Engine est une fonctionnalité réservée à DefectDojo Pro.
-Les deux moteurs fonctionnent côte à côte. Activer Rules Engine 2.0 ne change rien à vos règles [Rules Engine](/automation/rules_engine/about/) existantes, et il n'y a aucune échéance à laquelle vous devriez les faire migrer.
+Les deux moteurs fonctionnent côte à côte. Activer Triage Engine ne change rien à vos règles [Rules Engine](/automation/rules_engine/about/) existantes, et il n'y a aucune échéance à laquelle vous devriez les faire migrer.
-Lorsque vous souhaitez les faire migrer, un convertisseur est disponible. Il traduit une règle Rules Engine (un filtre associé à une liste ordonnée d'actions) en un graphe Rules Engine 2.0 équivalent.
+Lorsque vous souhaitez les faire migrer, un convertisseur est disponible. Il traduit une règle Rules Engine (un filtre associé à une liste ordonnée d'actions) en un graphe Triage Engine équivalent.
## Ce que le convertisseur garantit
@@ -72,14 +73,14 @@ Quatre points à anticiper. Le convertisseur les signale sous forme de notes à
* **L'historique des exécutions reste où il est.** L'historique des exécutions existant, ainsi que ses enregistrements affectés et ignorés, reste dans l'interface de Rules Engine. Il n'est pas copié.
* **Les planifications ne sont pas activées par défaut.** Une règle déclenchée par planification se convertit, mais sa planification n'est pas copiée sauf si vous passez `--activate-schedules`. Cela conserve la seule propriété des planifications actives au moteur d'origine tant que les deux fonctionnent, de sorte qu'une règle convertie ne peut pas commencer à se déclencher à votre insu. Lorsque vous copiez effectivement une planification, la copie reçoit un nom distinct afin de ne pas entrer en collision avec l'original.
-* **Le modèle de concurrence est différent.** Rules Engine possède un seul verrou d'exécution à l'échelle de l'instance. Rules Engine 2.0 sérialise par règle, de sorte que des règles distinctes s'exécutent simultanément. Un ensemble de règles qui se relayaient auparavant se chevauchera désormais.
-* **Une action n'a pas d'équivalent.** Une action « définir faux positif sur false » ne peut pas être exprimée comme un nœud Rules Engine 2.0 et doit être convertie manuellement.
+* **Le modèle de concurrence est différent.** Rules Engine possède un seul verrou d'exécution à l'échelle de l'instance. Triage Engine sérialise par règle, de sorte que des règles distinctes s'exécutent simultanément. Un ensemble de règles qui se relayaient auparavant se chevauchera désormais.
+* **Une action n'a pas d'équivalent.** Une action « définir faux positif sur false » ne peut pas être exprimée comme un nœud Triage Engine et doit être convertie manuellement.
Une règle dont le propriétaire n'est pas défini se convertit, avec un avertissement. Rappelez-vous qu'une règle sans propriétaire ne voit aucune Constatation ; attribuez-lui donc un propriétaire avant de l'activer.
## Un ordre suggéré
-1. Activez Rules Engine 2.0 et laissez vos règles existantes en cours d'exécution.
+1. Activez Triage Engine et laissez vos règles existantes en cours d'exécution.
2. Exécutez le convertisseur avec `--dry-run` et lisez le rapport.
3. Convertissez. Tout est créé désactivé.
4. Ouvrez chaque règle convertie, vérifiez le graphe, et laissez le mode sur **Simulate**.
diff --git a/docs/content/automation/rules_engine_2/converting_from_rules_engine.it.md b/docs/content/automation/triage_engine/converting_from_rules_engine.it.md
similarity index 87%
rename from docs/content/automation/rules_engine_2/converting_from_rules_engine.it.md
rename to docs/content/automation/triage_engine/converting_from_rules_engine.it.md
index bb464e3ab1f..d1f0d44076b 100644
--- a/docs/content/automation/rules_engine_2/converting_from_rules_engine.it.md
+++ b/docs/content/automation/triage_engine/converting_from_rules_engine.it.md
@@ -6,13 +6,14 @@ weight: 6
audience: pro
aliases:
- /it/automation/rules_engine_v2/converting_from_rules_engine/
+- /it/automation/rules_engine_2/converting_from_rules_engine/
---
-Nota: Rules Engine 2.0 è una funzionalità disponibile solo in DefectDojo Pro.
+Nota: Triage Engine è una funzionalità disponibile solo in DefectDojo Pro.
-I due motori funzionano fianco a fianco. Attivare Rules Engine 2.0 non cambia nulla delle regole [Rules Engine](/automation/rules_engine/about/) esistenti, e non c'è una scadenza entro cui spostarle.
+I due motori funzionano fianco a fianco. Attivare Triage Engine non cambia nulla delle regole [Rules Engine](/automation/rules_engine/about/) esistenti, e non c'è una scadenza entro cui spostarle.
-Quando si vuole spostarle, esiste un convertitore. Traduce una regola di Rules Engine (un filtro più un elenco ordinato di azioni) in un grafo Rules Engine 2.0 equivalente.
+Quando si vuole spostarle, esiste un convertitore. Traduce una regola di Rules Engine (un filtro più un elenco ordinato di azioni) in un grafo Triage Engine equivalente.
## Cosa garantisce il convertitore
@@ -72,14 +73,14 @@ Quattro cose da tenere presenti. Il convertitore le riporta come note a ogni ese
* **La cronologia dei run resta dov'è.** La cronologia di esecuzione esistente, e i relativi record interessati e saltati, rimangono nella UI di Rules Engine. Non vengono copiati.
* **Le pianificazioni non vengono attivate per impostazione predefinita.** Una regola attivata da pianificazione si converte, ma la sua pianificazione non viene copiata a meno di passare `--activate-schedules`. Questo mantiene la proprietà esclusiva delle pianificazioni attive nel motore originale finché entrambi sono in esecuzione, così una regola convertita non può iniziare a scattare di nascosto. Quando si copia effettivamente una pianificazione, alla copia viene dato un nome distinto in modo che non collida con l'originale.
-* **Il modello di concorrenza è diverso.** Rules Engine ha un unico lock di esecuzione a livello di istanza. Rules Engine 2.0 serializza per regola, quindi regole distinte vengono eseguite in concorrenza. Un insieme di regole che prima si alternava ora si sovrapporrà.
-* **Un'azione non ha equivalente.** Un'azione "imposta falso positivo a falso" non può essere espressa come nodo di Rules Engine 2.0 e deve essere convertita a mano.
+* **Il modello di concorrenza è diverso.** Rules Engine ha un unico lock di esecuzione a livello di istanza. Triage Engine serializza per regola, quindi regole distinte vengono eseguite in concorrenza. Un insieme di regole che prima si alternava ora si sovrapporrà.
+* **Un'azione non ha equivalente.** Un'azione "imposta falso positivo a falso" non può essere espressa come nodo di Triage Engine e deve essere convertita a mano.
Una regola il cui proprietario non è impostato si converte, con un avviso. Ricordare che una regola senza proprietario non vede alcun Riscontro, quindi assegnarne uno prima di abilitarla.
## Un ordine suggerito
-1. Attivare Rules Engine 2.0 e lasciare in esecuzione le regole esistenti.
+1. Attivare Triage Engine e lasciare in esecuzione le regole esistenti.
2. Eseguire il convertitore con `--dry-run` e leggere il report.
3. Convertire. Tutto viene creato disabilitato.
4. Aprire ogni regola convertita, controllare il grafo, e lasciare la modalità su **Simulate**.
diff --git a/docs/content/automation/rules_engine_2/converting_from_rules_engine.ja.md b/docs/content/automation/triage_engine/converting_from_rules_engine.ja.md
similarity index 86%
rename from docs/content/automation/rules_engine_2/converting_from_rules_engine.ja.md
rename to docs/content/automation/triage_engine/converting_from_rules_engine.ja.md
index 9dde661e20e..c623b5088a1 100644
--- a/docs/content/automation/rules_engine_2/converting_from_rules_engine.ja.md
+++ b/docs/content/automation/triage_engine/converting_from_rules_engine.ja.md
@@ -1,17 +1,18 @@
---
title: Rules Engine からの移行
-description: 既存の Rules Engine のルールを Rules Engine 2.0 のグラフへ移行する
+description: 既存の Rules Engine のルールを Triage Engine のグラフへ移行する
weight: 6
audience: pro
aliases:
- /ja/automation/rules_engine_v2/converting_from_rules_engine/
+- /ja/automation/rules_engine_2/converting_from_rules_engine/
---
-注: Rules Engine 2.0 は DefectDojo Pro 専用の機能です。
+注: Triage Engine は DefectDojo Pro 専用の機能です。
-両方のエンジンは並行して動作します。Rules Engine 2.0 を有効にしても、既存の [Rules Engine](/automation/rules_engine/about/) のルールには何の変更もなく、それらを移行しなければならない期限もありません。
+両方のエンジンは並行して動作します。Triage Engine を有効にしても、既存の [Rules Engine](/automation/rules_engine/about/) のルールには何の変更もなく、それらを移行しなければならない期限もありません。
-実際に移行したくなったときのために、converter(変換ツール)が用意されています。これは、Rules Engine のルール(フィルターと順序付けられたアクションのリスト)を、それと同等の Rules Engine 2.0 のグラフに変換します。
+実際に移行したくなったときのために、converter(変換ツール)が用意されています。これは、Rules Engine のルール(フィルターと順序付けられたアクションのリスト)を、それと同等の Triage Engine のグラフに変換します。
## Converter が保証すること
@@ -71,14 +72,14 @@ python manage.py convert_rules_to_v2
* **Run の履歴はそのままの場所に残ります。** 既存の実行履歴、およびそれに関連する対象レコードとスキップされたレコードは、Rules Engine の UI に残ったままになります。これらはコピーされません。
* **スケジュールはデフォルトでは有効化されません。** スケジュールトリガーのルールは変換されますが、`--activate-schedules` を指定しない限り、そのスケジュールはコピーされません。これにより、両エンジンが稼働している間、稼働中のスケジュールの所有権は従来のエンジンだけが持つことになり、変換されたルールが気づかないうちに発火し始めることはありません。実際にスケジュールをコピーする場合、コピーには元のものと衝突しないよう別の名前が付けられます。
-* **並行実行モデルが異なります。** Rules Engine には、インスタンス全体で1つの実行ロックがあります。Rules Engine 2.0 はルールごとに直列化されるため、異なるルールは同時に実行されます。これまで順番に実行されていたルール群が、これからは重複して実行されるようになります。
-* **1つのアクションには相当するものがありません。** 「false positive を false に設定する」アクションは Rules Engine 2.0 のノードとして表現できないため、手動で変換する必要があります。
+* **並行実行モデルが異なります。** Rules Engine には、インスタンス全体で1つの実行ロックがあります。Triage Engine はルールごとに直列化されるため、異なるルールは同時に実行されます。これまで順番に実行されていたルール群が、これからは重複して実行されるようになります。
+* **1つのアクションには相当するものがありません。** 「false positive を false に設定する」アクションは Triage Engine のノードとして表現できないため、手動で変換する必要があります。
所有者が設定されていないルールも、警告付きで変換されます。所有者のいないルールはどの Finding も参照できないことを忘れずに、有効化する前に所有者を割り当ててください。
## 推奨される手順
-1. Rules Engine 2.0 を有効にし、既存のルールはそのまま稼働させておきます。
+1. Triage Engine を有効にし、既存のルールはそのまま稼働させておきます。
2. `--dry-run` を付けて converter を実行し、レポートを確認します。
3. 変換します。すべて無効な状態になります。
4. 変換された各ルールを開き、グラフを確認し、モードは **Simulate** のままにしておきます。
diff --git a/docs/content/automation/rules_engine_2/converting_from_rules_engine.md b/docs/content/automation/triage_engine/converting_from_rules_engine.md
similarity index 85%
rename from docs/content/automation/rules_engine_2/converting_from_rules_engine.md
rename to docs/content/automation/triage_engine/converting_from_rules_engine.md
index 47186470a2a..f8f0971fdde 100644
--- a/docs/content/automation/rules_engine_2/converting_from_rules_engine.md
+++ b/docs/content/automation/triage_engine/converting_from_rules_engine.md
@@ -1,16 +1,17 @@
---
title: "Converting from Rules Engine"
-description: "Move existing Rules Engine rules across to Rules Engine 2.0 graphs"
+description: "Move existing Rules Engine rules across to Triage Engine graphs"
weight: 6
audience: pro
aliases:
- /automation/rules_engine_v2/converting_from_rules_engine/
+ - /automation/rules_engine_2/converting_from_rules_engine/
---
-Note: Rules Engine 2.0 is a DefectDojo Pro-only feature.
+Note: Triage Engine is a DefectDojo Pro-only feature.
-Both engines run side by side. Turning on Rules Engine 2.0 changes nothing about your existing [Rules Engine](/automation/rules_engine/about/) rules, and there is no deadline by which you must move them.
+Both engines run side by side. Turning on Triage Engine changes nothing about your existing [Rules Engine](/automation/rules_engine/about/) rules, and there is no deadline by which you must move them.
-When you do want to move them, there is a converter. It translates a Rules Engine rule (a filter plus an ordered list of actions) into an equivalent Rules Engine 2.0 graph.
+When you do want to move them, there is a converter. It translates a Rules Engine rule (a filter plus an ordered list of actions) into an equivalent Triage Engine graph.
## What the converter guarantees
@@ -70,14 +71,14 @@ Four things to plan for. The converter reports these as notes on every run.
* **Run history stays where it is.** Existing run history, and its affected and skipped records, remain in the Rules Engine UI. They are not copied.
* **Schedules are not activated by default.** A schedule-triggered rule converts, but its schedule is not copied unless you pass `--activate-schedules`. This keeps sole ownership of live schedules with the original engine while both are running, so a converted rule cannot start firing behind your back. When you do copy a schedule, the copy is given a distinct name so it does not collide with the original.
-* **The concurrency model is different.** Rules Engine has one instance-wide run lock. Rules Engine 2.0 serialises per rule, so distinct rules run concurrently. A set of rules that used to take turns will now overlap.
-* **One action has no equivalent.** A "set false positive to false" action cannot be expressed as a Rules Engine 2.0 node and must be converted by hand.
+* **The concurrency model is different.** Rules Engine has one instance-wide run lock. Triage Engine serialises per rule, so distinct rules run concurrently. A set of rules that used to take turns will now overlap.
+* **One action has no equivalent.** A "set false positive to false" action cannot be expressed as a Triage Engine node and must be converted by hand.
A rule whose owner is unset converts, with a warning. Remember that a rule with no owner sees no Findings, so assign one before enabling it.
## A suggested order
-1. Turn on Rules Engine 2.0 and leave your existing rules running.
+1. Turn on Triage Engine and leave your existing rules running.
2. Run the converter with `--dry-run` and read the report.
3. Convert. Everything lands disabled.
4. Open each converted rule, check the graph, and leave the mode on **Simulate**.
diff --git a/docs/content/automation/rules_engine_2/converting_from_rules_engine.pt-br.md b/docs/content/automation/triage_engine/converting_from_rules_engine.pt-br.md
similarity index 86%
rename from docs/content/automation/rules_engine_2/converting_from_rules_engine.pt-br.md
rename to docs/content/automation/triage_engine/converting_from_rules_engine.pt-br.md
index 60ecb42c855..dfd7acd5be1 100644
--- a/docs/content/automation/rules_engine_2/converting_from_rules_engine.pt-br.md
+++ b/docs/content/automation/triage_engine/converting_from_rules_engine.pt-br.md
@@ -1,17 +1,18 @@
---
title: Migrando do Rules Engine
-description: Migre regras existentes do Rules Engine para grafos do Rules Engine 2.0
+description: Migre regras existentes do Rules Engine para grafos do Triage Engine
weight: 6
audience: pro
aliases:
- /pt-br/automation/rules_engine_v2/converting_from_rules_engine/
+- /pt-br/automation/rules_engine_2/converting_from_rules_engine/
---
-Nota: O Rules Engine 2.0 é um recurso exclusivo do DefectDojo Pro.
+Nota: O Triage Engine é um recurso exclusivo do DefectDojo Pro.
-Os dois mecanismos funcionam lado a lado. Ativar o Rules Engine 2.0 não muda nada em suas regras existentes do [Rules Engine](/automation/rules_engine/about/), e não há um prazo até o qual você precise migrá-las.
+Os dois mecanismos funcionam lado a lado. Ativar o Triage Engine não muda nada em suas regras existentes do [Rules Engine](/automation/rules_engine/about/), e não há um prazo até o qual você precise migrá-las.
-Quando você quiser migrá-las, existe um conversor. Ele traduz uma regra do Rules Engine (um filtro mais uma lista ordenada de ações) em um grafo equivalente do Rules Engine 2.0.
+Quando você quiser migrá-las, existe um conversor. Ele traduz uma regra do Rules Engine (um filtro mais uma lista ordenada de ações) em um grafo equivalente do Triage Engine.
## O que o conversor garante
@@ -71,14 +72,14 @@ Quatro coisas para planejar. O conversor relata essas informações como notas e
* **O histórico de execuções permanece onde está.** O histórico de execuções existente, junto com seus registros afetados e ignorados, permanece na interface do Rules Engine. Eles não são copiados.
* **As programações não são ativadas por padrão.** Uma regra disparada por agendamento é convertida, mas sua programação não é copiada a menos que você passe `--activate-schedules`. Isso mantém a propriedade exclusiva das programações ativas com o mecanismo original enquanto os dois estão em execução, de modo que uma regra convertida não pode começar a disparar sem você perceber. Quando você copia uma programação, a cópia recebe um nome distinto para não colidir com a original.
-* **O modelo de concorrência é diferente.** O Rules Engine tem um único bloqueio de execução para toda a instância. O Rules Engine 2.0 serializa por regra, portanto regras distintas são executadas simultaneamente. Um conjunto de regras que costumava se revezar agora vai se sobrepor.
-* **Uma ação não tem equivalente.** Uma ação de "definir falso positivo como falso" não pode ser expressa como um nó do Rules Engine 2.0 e precisa ser convertida manualmente.
+* **O modelo de concorrência é diferente.** O Rules Engine tem um único bloqueio de execução para toda a instância. O Triage Engine serializa por regra, portanto regras distintas são executadas simultaneamente. Um conjunto de regras que costumava se revezar agora vai se sobrepor.
+* **Uma ação não tem equivalente.** Uma ação de "definir falso positivo como falso" não pode ser expressa como um nó do Triage Engine e precisa ser convertida manualmente.
Uma regra cujo proprietário não está definido é convertida, com um aviso. Lembre-se de que uma regra sem proprietário não vê nenhum Achado, portanto atribua um antes de ativá-la.
## Uma ordem sugerida
-1. Ative o Rules Engine 2.0 e deixe suas regras existentes em execução.
+1. Ative o Triage Engine e deixe suas regras existentes em execução.
2. Execute o conversor com `--dry-run` e leia o relatório.
3. Converta. Tudo é criado desativado.
4. Abra cada regra convertida, verifique o grafo e deixe o modo em **Simulate**.
diff --git a/docs/content/automation/rules_engine_2/converting_from_rules_engine.zh-hans.md b/docs/content/automation/triage_engine/converting_from_rules_engine.zh-hans.md
similarity index 86%
rename from docs/content/automation/rules_engine_2/converting_from_rules_engine.zh-hans.md
rename to docs/content/automation/triage_engine/converting_from_rules_engine.zh-hans.md
index 1bf859d475c..67e732a64ca 100644
--- a/docs/content/automation/rules_engine_2/converting_from_rules_engine.zh-hans.md
+++ b/docs/content/automation/triage_engine/converting_from_rules_engine.zh-hans.md
@@ -1,17 +1,18 @@
---
title: 从 Rules Engine 转换
-description: 将现有的 Rules Engine 规则迁移为 Rules Engine 2.0 的图
+description: 将现有的 Rules Engine 规则迁移为 Triage Engine 的图
weight: 6
audience: pro
aliases:
- /zh-hans/automation/rules_engine_v2/converting_from_rules_engine/
+- /zh-hans/automation/rules_engine_2/converting_from_rules_engine/
---
-注意：Rules Engine 2.0 是 DefectDojo Pro 专属功能。
+注意：Triage Engine 是 DefectDojo Pro 专属功能。
-两套引擎并行运行。启用 Rules Engine 2.0 不会改变您现有的 [Rules Engine](/automation/rules_engine/about/) 规则中的任何内容，也没有必须迁移它们的截止时间。
+两套引擎并行运行。启用 Triage Engine 不会改变您现有的 [Rules Engine](/automation/rules_engine/about/) 规则中的任何内容，也没有必须迁移它们的截止时间。
-当您确实想要迁移时，有一个转换器可以使用。它会将一条 Rules Engine 规则（一个过滤器加一份有序的动作列表）转换为一张等价的 Rules Engine 2.0 图。
+当您确实想要迁移时，有一个转换器可以使用。它会将一条 Rules Engine 规则（一个过滤器加一份有序的动作列表）转换为一张等价的 Triage Engine 图。
## 转换器的保证
@@ -71,14 +72,14 @@ python manage.py convert_rules_to_v2
* **运行历史留在原处。** 现有的运行历史及其受影响和被跳过的记录，仍保留在 Rules Engine 的 UI 中，不会被复制。
* **计划默认不会被激活。** 一条以计划触发的规则可以转换，但除非您传入 `--activate-schedules`，否则其计划不会被复制。这样做是为了在两套引擎同时运行期间，让生效中的计划始终唯一归属于原有引擎，从而使转换后的规则不会在您不知情的情况下开始触发。当您确实复制某个计划时，副本会被赋予一个不同的名称，以免与原计划冲突。
-* **并发模型不同。** Rules Engine 只有一把实例级的运行锁。Rules Engine 2.0 则按规则各自串行化，因此不同的规则会并发运行。原本轮流执行的一组规则，现在会出现重叠。
-* **有一个动作没有对应项。** “将误报状态设为 false”这个动作无法用 Rules Engine 2.0 的节点表达，必须手动转换。
+* **并发模型不同。** Rules Engine 只有一把实例级的运行锁。Triage Engine 则按规则各自串行化，因此不同的规则会并发运行。原本轮流执行的一组规则，现在会出现重叠。
+* **有一个动作没有对应项。** “将误报状态设为 false”这个动作无法用 Triage Engine 的节点表达，必须手动转换。
所有者未设置的规则也能转换，但会附带警告。请记住，没有所有者的规则看不到任何发现项，因此请在启用之前为其指定一个所有者。
## 建议的操作顺序
-1. 启用 Rules Engine 2.0，并让您现有的规则继续运行。
+1. 启用 Triage Engine，并让您现有的规则继续运行。
2. 用 `--dry-run` 运行转换器，并阅读报告。
3. 执行转换。所有结果都会以禁用状态落地。
4. 打开每一条转换后的规则，检查其图，并将模式保持为 **Simulate**。
diff --git a/docs/content/automation/rules_engine_2/deliveries.de.md b/docs/content/automation/triage_engine/deliveries.de.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/deliveries.de.md
rename to docs/content/automation/triage_engine/deliveries.de.md
index 3dc87d89b0d..e3f7c479ec7 100644
--- a/docs/content/automation/rules_engine_2/deliveries.de.md
+++ b/docs/content/automation/triage_engine/deliveries.de.md
@@ -6,11 +6,12 @@ weight: 5
audience: pro
aliases:
- /de/automation/rules_engine_v2/deliveries/
+- /de/automation/rules_engine_2/deliveries/
---
-Hinweis: Rules Engine 2.0 ist eine Funktion, die nur in DefectDojo Pro verfügbar ist.
+Hinweis: Triage Engine ist eine Funktion, die nur in DefectDojo Pro verfügbar ist.
-Jeder ausgehende Nebeneffekt, den eine Regel erzeugt, ist eine Zeile im Zustellungsprotokoll. **Rules Engine 2.0 > Deliveries** listet sie auf.
+Jeder ausgehende Nebeneffekt, den eine Regel erzeugt, ist eine Zeile im Zustellungsprotokoll. **Triage Engine > Deliveries** listet sie auf.
Die Zeile wird geschrieben, **bevor** ein Netzwerkaufruf stattfindet, und sie enthält genau das, was gesendet werden würde oder wurde. Das macht ausgehenden Datenverkehr überprüfbar, statt sich auf eine Logzeile zu verlassen, in der Hoffnung, dass sie jemand aufbewahrt hat, und deshalb ist Simulieren kein eigener Codepfad: Ein simulierter Versand ist dieselbe Zeile, nur ohne den Versandschritt.
diff --git a/docs/content/automation/rules_engine_2/deliveries.es.md b/docs/content/automation/triage_engine/deliveries.es.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/deliveries.es.md
rename to docs/content/automation/triage_engine/deliveries.es.md
index 98523d99153..6654999c40a 100644
--- a/docs/content/automation/rules_engine_2/deliveries.es.md
+++ b/docs/content/automation/triage_engine/deliveries.es.md
@@ -6,11 +6,12 @@ weight: 5
audience: pro
aliases:
- /es/automation/rules_engine_v2/deliveries/
+- /es/automation/rules_engine_2/deliveries/
---
-Nota: Rules Engine 2.0 es una función exclusiva de DefectDojo Pro.
+Nota: Triage Engine es una función exclusiva de DefectDojo Pro.
-Cada efecto secundario saliente que produce una regla es una fila en el registro de entregas. **Rules Engine 2.0 > Entregas** las enumera.
+Cada efecto secundario saliente que produce una regla es una fila en el registro de entregas. **Triage Engine > Entregas** las enumera.
La fila se escribe **antes** de que ocurra cualquier llamada de red, y contiene exactamente lo que se enviaría, o lo que se envió. Eso es lo que hace que el tráfico de salida sea auditable en lugar de una línea de registro que uno espera que alguien haya conservado, y es la razón por la que **Simulate** no es una ruta de código independiente: un envío simulado es la misma fila con el paso de despacho omitido.
diff --git a/docs/content/automation/rules_engine_2/deliveries.fr.md b/docs/content/automation/triage_engine/deliveries.fr.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/deliveries.fr.md
rename to docs/content/automation/triage_engine/deliveries.fr.md
index 0313346d379..93ccfc3a49e 100644
--- a/docs/content/automation/rules_engine_2/deliveries.fr.md
+++ b/docs/content/automation/triage_engine/deliveries.fr.md
@@ -6,11 +6,12 @@ weight: 5
audience: pro
aliases:
- /fr/automation/rules_engine_v2/deliveries/
+- /fr/automation/rules_engine_2/deliveries/
---
-Remarque : Rules Engine 2.0 est une fonctionnalité réservée à DefectDojo Pro.
+Remarque : Triage Engine est une fonctionnalité réservée à DefectDojo Pro.
-Chaque effet secondaire sortant produit par une règle correspond à une ligne du registre des livraisons. **Rules Engine 2.0 > Livraisons** les répertorie.
+Chaque effet secondaire sortant produit par une règle correspond à une ligne du registre des livraisons. **Triage Engine > Livraisons** les répertorie.
La ligne est écrite **avant** tout appel réseau, et elle contient exactement ce qui sera, ou a été, envoyé. C'est ce qui rend les envois sortants auditables plutôt qu'une ligne de journal que l'on espère avoir conservée, et c'est pourquoi **Simulate** n'est pas un chemin de code distinct : un envoi simulé correspond à la même ligne, l'étape de dispatch étant simplement ignorée.
diff --git a/docs/content/automation/rules_engine_2/deliveries.it.md b/docs/content/automation/triage_engine/deliveries.it.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/deliveries.it.md
rename to docs/content/automation/triage_engine/deliveries.it.md
index 9104b44364f..83a06457c9b 100644
--- a/docs/content/automation/rules_engine_2/deliveries.it.md
+++ b/docs/content/automation/triage_engine/deliveries.it.md
@@ -6,11 +6,12 @@ weight: 5
audience: pro
aliases:
- /it/automation/rules_engine_v2/deliveries/
+- /it/automation/rules_engine_2/deliveries/
---
-Nota: Rules Engine 2.0 è una funzionalità disponibile solo in DefectDojo Pro.
+Nota: Triage Engine è una funzionalità disponibile solo in DefectDojo Pro.
-Ogni effetto collaterale in uscita prodotto da una regola corrisponde a una riga nel registro delle consegne. **Rules Engine 2.0 > Consegne** le elenca.
+Ogni effetto collaterale in uscita prodotto da una regola corrisponde a una riga nel registro delle consegne. **Triage Engine > Consegne** le elenca.
La riga viene scritta **prima** che avvenga qualsiasi chiamata di rete e contiene esattamente ciò che verrà, o è stato, inviato. Questo è ciò che rende l'uscita dei dati verificabile, invece di essere una riga di log che si spera qualcuno abbia conservato, ed è il motivo per cui **Simulazione** non è un percorso di codice separato: un invio simulato è la stessa riga con il passaggio di dispatch saltato.
diff --git a/docs/content/automation/rules_engine_2/deliveries.ja.md b/docs/content/automation/triage_engine/deliveries.ja.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/deliveries.ja.md
rename to docs/content/automation/triage_engine/deliveries.ja.md
index 0ba44fe2672..f97f71bd43a 100644
--- a/docs/content/automation/rules_engine_2/deliveries.ja.md
+++ b/docs/content/automation/triage_engine/deliveries.ja.md
@@ -5,11 +5,12 @@ weight: 5
audience: pro
aliases:
- /ja/automation/rules_engine_v2/deliveries/
+- /ja/automation/rules_engine_2/deliveries/
---
-注: Rules Engine 2.0 は DefectDojo Pro 限定の機能です。
+注: Triage Engine は DefectDojo Pro 限定の機能です。
-ルールが生成するすべての送信(アウトバウンド)側の副作用は、配信台帳の1行になります。**Rules Engine 2.0 > Deliveries** にその一覧が表示されます。
+ルールが生成するすべての送信(アウトバウンド)側の副作用は、配信台帳の1行になります。**Triage Engine > Deliveries** にその一覧が表示されます。
この行はネットワーク呼び出しが発生する**前**に書き込まれ、送信される(または送信された)内容を正確に保持します。これにより、送信(egress)は「誰かが保存していることを願うログ行」ではなく、監査可能なものになります。また、これが **Simulate** が別のコードパスではない理由でもあります。シミュレーション送信は、ディスパッチ手順が省略されただけの、同じ行なのです。
diff --git a/docs/content/automation/rules_engine_2/deliveries.md b/docs/content/automation/triage_engine/deliveries.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/deliveries.md
rename to docs/content/automation/triage_engine/deliveries.md
index c6daace3bab..38c116b3dab 100644
--- a/docs/content/automation/rules_engine_2/deliveries.md
+++ b/docs/content/automation/triage_engine/deliveries.md
@@ -5,10 +5,11 @@ weight: 5
audience: pro
aliases:
- /automation/rules_engine_v2/deliveries/
+ - /automation/rules_engine_2/deliveries/
---
-Note: Rules Engine 2.0 is a DefectDojo Pro-only feature.
+Note: Triage Engine is a DefectDojo Pro-only feature.
-Every outbound side effect a rule produces is one row in the delivery ledger. **Rules Engine 2.0 > Deliveries** lists them.
+Every outbound side effect a rule produces is one row in the delivery ledger. **Triage Engine > Deliveries** lists them.
The row is written **before** any network call happens, and it holds exactly what would be, or was, sent. That is what makes egress auditable rather than a log line you hope somebody kept, and it is why **Simulate** is not a separate code path: a simulated send is the same row with the dispatch step skipped.
diff --git a/docs/content/automation/rules_engine_2/deliveries.pt-br.md b/docs/content/automation/triage_engine/deliveries.pt-br.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/deliveries.pt-br.md
rename to docs/content/automation/triage_engine/deliveries.pt-br.md
index 11f004f1b60..239a4eb7c50 100644
--- a/docs/content/automation/rules_engine_2/deliveries.pt-br.md
+++ b/docs/content/automation/triage_engine/deliveries.pt-br.md
@@ -6,11 +6,12 @@ weight: 5
audience: pro
aliases:
- /pt-br/automation/rules_engine_v2/deliveries/
+- /pt-br/automation/rules_engine_2/deliveries/
---
-Nota: o Rules Engine 2.0 é um recurso exclusivo do DefectDojo Pro.
+Nota: o Triage Engine é um recurso exclusivo do DefectDojo Pro.
-Cada efeito colateral de saída produzido por uma regra é uma linha no registro de entregas. **Rules Engine 2.0 > Entregas** as lista.
+Cada efeito colateral de saída produzido por uma regra é uma linha no registro de entregas. **Triage Engine > Entregas** as lista.
A linha é gravada **antes** de qualquer chamada de rede acontecer, e contém exatamente o que seria, ou foi, enviado. É isso que torna a saída auditável, em vez de uma linha de log que você espera que alguém tenha guardado, e é por isso que **Simulate** não é um caminho de código separado: um envio simulado é a mesma linha com a etapa de despacho pulada.
diff --git a/docs/content/automation/rules_engine_2/deliveries.zh-hans.md b/docs/content/automation/triage_engine/deliveries.zh-hans.md
similarity index 96%
rename from docs/content/automation/rules_engine_2/deliveries.zh-hans.md
rename to docs/content/automation/triage_engine/deliveries.zh-hans.md
index b03b85af0f6..715abadaa1c 100644
--- a/docs/content/automation/rules_engine_2/deliveries.zh-hans.md
+++ b/docs/content/automation/triage_engine/deliveries.zh-hans.md
@@ -5,11 +5,12 @@ weight: 5
audience: pro
aliases:
- /zh-hans/automation/rules_engine_v2/deliveries/
+- /zh-hans/automation/rules_engine_2/deliveries/
---
-注意：Rules Engine 2.0 是 DefectDojo Pro 专属功能。
+注意：Triage Engine 是 DefectDojo Pro 专属功能。
-规则产生的每一个对外副作用，都会在投递台账中生成一行记录。**Rules Engine 2.0 > Deliveries** 页面会列出这些记录。
+规则产生的每一个对外副作用，都会在投递台账中生成一行记录。**Triage Engine > Deliveries** 页面会列出这些记录。
该记录会在发生任何网络调用之**前**写入，其中保存的正是即将发送或已经发送的确切内容。正因如此，出站发送才是可审计的，而不是一条只能寄希望于有人保留下来的日志；这也是**模拟**并非另一条独立代码路径的原因：模拟发送使用的是同一条记录，只是跳过了实际派发步骤。
diff --git a/docs/content/automation/rules_engine_2/node_reference.de.md b/docs/content/automation/triage_engine/node_reference.de.md
similarity index 96%
rename from docs/content/automation/rules_engine_2/node_reference.de.md
rename to docs/content/automation/triage_engine/node_reference.de.md
index f0754de767e..d3edb79c6aa 100644
--- a/docs/content/automation/rules_engine_2/node_reference.de.md
+++ b/docs/content/automation/triage_engine/node_reference.de.md
@@ -1,15 +1,16 @@
---
title: Knotenreferenz
-description: Jeder Knoten, den Rules Engine 2.0 mitbringt, und was er jeweils tut
+description: Jeder Knoten, den Triage Engine mitbringt, und was er jeweils tut
weight: 3
audience: pro
aliases:
- /de/automation/rules_engine_v2/node_reference/
+- /de/automation/rules_engine_2/node_reference/
---
-Hinweis: Rules Engine 2.0 ist eine Funktion, die nur in DefectDojo Pro verfügbar ist.
+Hinweis: Triage Engine ist eine Funktion, die nur in DefectDojo Pro verfügbar ist.
-Rules Engine 2.0 bringt 25 Knoten in vier Kategorien mit. Diese Seite dokumentiert sie alle.
+Triage Engine bringt 25 Knoten in vier Kategorien mit. Diese Seite dokumentiert sie alle.
Sofern nicht anders angegeben, nimmt ein Knoten eine Eingabe entgegen, erzeugt eine Ausgabe namens `out` und gibt jedes empfangene Element an diese Ausgabe weiter. Das ist wichtig, wenn Sie Knoten verketten: Ein Befunde-Knoten verändert den Befund und reicht das Element dann weiter, sodass mehrere davon hintereinander alle wirksam werden.
@@ -217,7 +218,7 @@ Ein Knoten, der eine Nachricht pro Befund sendet, stoppt standardmäßig nach 1.
### Wenn ein Kanal nicht verfügbar ist
-Ein Egress-Knoten hängt von etwas außerhalb der Regel ab: einem Slack-Token, einem Microsoft-Teams-Webhook, einer JIRA-Konfiguration, einem lizenzierten Connector. Fehlt das oder ist es abgeschaltet, kann der Knoten nicht arbeiten, und Rules Engine 2.0 macht das an drei verschiedenen Stellen deutlich, statt still zu scheitern:
+Ein Egress-Knoten hängt von etwas außerhalb der Regel ab: einem Slack-Token, einem Microsoft-Teams-Webhook, einer JIRA-Konfiguration, einem lizenzierten Connector. Fehlt das oder ist es abgeschaltet, kann der Knoten nicht arbeiten, und Triage Engine macht das an drei verschiedenen Stellen deutlich, statt still zu scheitern:
* **In der Palette** wird ein nicht verfügbarer Knoten als solcher markiert, mit Angabe des Grundes, bevor Sie ihn auf die Zeichenfläche ziehen.
* **Beim Speichern** wird ein Graph, der einen nicht verfügbaren Knoten enthält, abgelehnt. Das ist der Moment, in dem jemand anwesend ist, um einen anderen auszuwählen.
@@ -321,7 +322,7 @@ Erstellt eine In-App-Benachrichtigung über den Batch.
| Einstellung | Standard | Hinweise |
|---------|---------|-------|
-| **Titel** | `Rules Engine 2.0: {{ctx.rule_name}}` | Wird einmal für den gesamten Batch gerendert. |
+| **Titel** | `Triage Engine: {{ctx.rule_name}}` | Wird einmal für den gesamten Batch gerendert. |
| **Beschreibung** | `{{ctx.count}} finding(s) matched the rule {{ctx.rule_name}}.` | Wird einmal für den gesamten Batch gerendert. |
| **Empfänger** | leer | Benutzernamen, durch Kommas getrennt. Leer benachrichtigt die Administratoren. |
diff --git a/docs/content/automation/rules_engine_2/node_reference.es.md b/docs/content/automation/triage_engine/node_reference.es.md
similarity index 96%
rename from docs/content/automation/rules_engine_2/node_reference.es.md
rename to docs/content/automation/triage_engine/node_reference.es.md
index f1897353bd9..9fee4d412f4 100644
--- a/docs/content/automation/rules_engine_2/node_reference.es.md
+++ b/docs/content/automation/triage_engine/node_reference.es.md
@@ -1,16 +1,17 @@
---
title: Referencia de nodos
-description: Todos los nodos con los que se distribuye Rules Engine 2.0, y qué hace
+description: Todos los nodos con los que se distribuye Triage Engine, y qué hace
cada uno
weight: 3
audience: pro
aliases:
- /es/automation/rules_engine_v2/node_reference/
+- /es/automation/rules_engine_2/node_reference/
---
-Nota: Rules Engine 2.0 es una función exclusiva de DefectDojo Pro.
+Nota: Triage Engine es una función exclusiva de DefectDojo Pro.
-Rules Engine 2.0 se distribuye con 25 nodos en cuatro categorías. Esta página los documenta todos.
+Triage Engine se distribuye con 25 nodos en cuatro categorías. Esta página los documenta todos.
A menos que se indique lo contrario, un nodo recibe una entrada, produce una salida llamada `out`, y pasa cada elemento que recibió a esa salida. Esto importa cuando se encadenan nodos: un nodo de Hallazgos modifica el Hallazgo y luego pasa el elemento hacia adelante, de modo que varios de ellos en fila se aplican todos.
@@ -218,7 +219,7 @@ Un nodo que envía un mensaje por Hallazgo se detiene después de 1000 envíos e
### Cuando un canal no está disponible
-Un nodo de salida depende de algo externo a la regla: un token de Slack, un webhook de Microsoft Teams, una configuración de JIRA, un conector con licencia. Cuando eso falta o está desactivado, el nodo no puede funcionar, y Rules Engine 2.0 lo indica en tres momentos distintos en lugar de fallar en silencio:
+Un nodo de salida depende de algo externo a la regla: un token de Slack, un webhook de Microsoft Teams, una configuración de JIRA, un conector con licencia. Cuando eso falta o está desactivado, el nodo no puede funcionar, y Triage Engine lo indica en tres momentos distintos en lugar de fallar en silencio:
* **En la paleta**, un nodo no disponible se marca como tal, con el motivo, antes de que se arrastre al lienzo.
* **Al guardar**, se rechaza un grafo que contenga un nodo no disponible. Ese es el momento en que alguien está presente para elegir uno diferente.
@@ -322,7 +323,7 @@ Crea una alerta en la aplicación sobre el lote.
| Setting | Default | Notes |
|---------|---------|-------|
-| **Title** | `Rules Engine 2.0: {{ctx.rule_name}}` | Se renderiza una vez para todo el lote. |
+| **Title** | `Triage Engine: {{ctx.rule_name}}` | Se renderiza una vez para todo el lote. |
| **Description** | `{{ctx.count}} finding(s) matched the rule {{ctx.rule_name}}.` | Se renderiza una vez para todo el lote. |
| **Recipients** | vacío | Nombres de usuario, separados por comas. Vacío alerta a los administradores. |
diff --git a/docs/content/automation/rules_engine_2/node_reference.fr.md b/docs/content/automation/triage_engine/node_reference.fr.md
similarity index 97%
rename from docs/content/automation/rules_engine_2/node_reference.fr.md
rename to docs/content/automation/triage_engine/node_reference.fr.md
index a8e61a9f7ef..63aee99703c 100644
--- a/docs/content/automation/rules_engine_2/node_reference.fr.md
+++ b/docs/content/automation/triage_engine/node_reference.fr.md
@@ -1,15 +1,16 @@
---
title: Référence des nœuds
-description: Tous les nœuds fournis avec Rules Engine 2.0, et ce que fait chacun d'eux
+description: Tous les nœuds fournis avec Triage Engine, et ce que fait chacun d'eux
weight: 3
audience: pro
aliases:
- /fr/automation/rules_engine_v2/node_reference/
+- /fr/automation/rules_engine_2/node_reference/
---
-Remarque : Rules Engine 2.0 est une fonctionnalité réservée à DefectDojo Pro.
+Remarque : Triage Engine est une fonctionnalité réservée à DefectDojo Pro.
-Rules Engine 2.0 est fourni avec 25 nœuds répartis en quatre catégories. Cette page les documente tous.
+Triage Engine est fourni avec 25 nœuds répartis en quatre catégories. Cette page les documente tous.
Sauf indication contraire, un nœud reçoit une entrée, produit une sortie appelée `out`, et transmet à cette sortie chaque élément qu'il a reçu. Cela compte lorsque vous enchaînez des nœuds : un nœud de type Constatations modifie la Constatation puis transmet l'élément à la suite, de sorte que plusieurs nœuds enchaînés s'appliquent tous.
@@ -217,7 +218,7 @@ Un nœud envoyant un message par Constatation s'arrête par défaut après 1 000
### Lorsqu'un canal est indisponible
-Un nœud de sortie dépend de quelque chose d'extérieur à la règle : un jeton Slack, un webhook Microsoft Teams, une configuration JIRA, un connecteur sous licence. Lorsque cet élément est manquant ou désactivé, le nœud ne peut pas fonctionner, et Rules Engine 2.0 le signale à trois moments différents plutôt que d'échouer silencieusement :
+Un nœud de sortie dépend de quelque chose d'extérieur à la règle : un jeton Slack, un webhook Microsoft Teams, une configuration JIRA, un connecteur sous licence. Lorsque cet élément est manquant ou désactivé, le nœud ne peut pas fonctionner, et Triage Engine le signale à trois moments différents plutôt que d'échouer silencieusement :
* **Dans la palette**, un nœud indisponible est marqué comme tel, avec la raison, avant même que vous ne le glissiez sur le canevas.
* **À l'enregistrement**, un graphe contenant un nœud indisponible est refusé. C'est le moment où quelqu'un est présent pour en choisir un autre.
@@ -321,7 +322,7 @@ Crée une alerte intégrée à propos du lot.
| Paramètre | Valeur par défaut | Remarques |
|---------|---------|-------|
-| **Titre** | `Rules Engine 2.0: {{ctx.rule_name}}` | Généré une fois pour l'ensemble du lot. |
+| **Titre** | `Triage Engine: {{ctx.rule_name}}` | Généré une fois pour l'ensemble du lot. |
| **Description** | `{{ctx.count}} finding(s) matched the rule {{ctx.rule_name}}.` | Généré une fois pour l'ensemble du lot. |
| **Destinataires** | vide | Noms d'utilisateur, séparés par des virgules. Vide alerte les administrateurs. |
diff --git a/docs/content/automation/rules_engine_2/node_reference.it.md b/docs/content/automation/triage_engine/node_reference.it.md
similarity index 96%
rename from docs/content/automation/rules_engine_2/node_reference.it.md
rename to docs/content/automation/triage_engine/node_reference.it.md
index 8052328ab0c..46704d6b169 100644
--- a/docs/content/automation/rules_engine_2/node_reference.it.md
+++ b/docs/content/automation/triage_engine/node_reference.it.md
@@ -1,15 +1,16 @@
---
title: Riferimento dei nodi
-description: Tutti i nodi inclusi in Rules Engine 2.0, e cosa fa ciascuno
+description: Tutti i nodi inclusi in Triage Engine, e cosa fa ciascuno
weight: 3
audience: pro
aliases:
- /it/automation/rules_engine_v2/node_reference/
+- /it/automation/rules_engine_2/node_reference/
---
-Nota: Rules Engine 2.0 è una funzionalità disponibile solo in DefectDojo Pro.
+Nota: Triage Engine è una funzionalità disponibile solo in DefectDojo Pro.
-Rules Engine 2.0 include 25 nodi suddivisi in quattro categorie. Questa pagina li documenta tutti.
+Triage Engine include 25 nodi suddivisi in quattro categorie. Questa pagina li documenta tutti.
Salvo diversa indicazione, un nodo accetta un input, produce un output chiamato `out` e passa a quell'output ogni elemento ricevuto. Questo è rilevante quando si concatenano i nodi: un nodo sui Riscontri modifica il Riscontro e poi passa l'elemento avanti, quindi più nodi in sequenza vengono applicati tutti.
@@ -217,7 +218,7 @@ Un nodo che invia un messaggio per ogni Riscontro si ferma per impostazione pred
### Quando un canale non è disponibile
-Un nodo di uscita dipende da qualcosa esterno alla regola: un token Slack, un webhook Microsoft Teams, una configurazione JIRA, un connettore con licenza. Quando questo manca o è disattivato, il nodo non può funzionare, e Rules Engine 2.0 lo segnala in tre momenti diversi invece di fallire silenziosamente:
+Un nodo di uscita dipende da qualcosa esterno alla regola: un token Slack, un webhook Microsoft Teams, una configurazione JIRA, un connettore con licenza. Quando questo manca o è disattivato, il nodo non può funzionare, e Triage Engine lo segnala in tre momenti diversi invece di fallire silenziosamente:
* **Nella tavolozza**, un nodo non disponibile viene contrassegnato come tale, con il motivo, prima che venga trascinato sul canvas.
* **Al salvataggio**, un grafo che contiene un nodo non disponibile viene rifiutato. È il momento in cui qualcuno è presente per sceglierne uno diverso.
@@ -321,7 +322,7 @@ Crea un avviso in-app relativo al batch.
| Impostazione | Predefinito | Note |
|---------|---------|-------|
-| **Titolo** | `Rules Engine 2.0: {{ctx.rule_name}}` | Renderizzato una volta per l'intero batch. |
+| **Titolo** | `Triage Engine: {{ctx.rule_name}}` | Renderizzato una volta per l'intero batch. |
| **Descrizione** | `{{ctx.count}} finding(s) matched the rule {{ctx.rule_name}}.` | Renderizzato una volta per l'intero batch. |
| **Destinatari** | vuoto | Nomi utente separati da virgola. Se vuoto, avvisa gli amministratori. |
diff --git a/docs/content/automation/rules_engine_2/node_reference.ja.md b/docs/content/automation/triage_engine/node_reference.ja.md
similarity index 96%
rename from docs/content/automation/rules_engine_2/node_reference.ja.md
rename to docs/content/automation/triage_engine/node_reference.ja.md
index b9d0fcaa3f8..02667b3a5cd 100644
--- a/docs/content/automation/rules_engine_2/node_reference.ja.md
+++ b/docs/content/automation/triage_engine/node_reference.ja.md
@@ -1,15 +1,16 @@
---
title: ノードリファレンス
-description: Rules Engine 2.0に搭載されているすべてのノードと、それぞれの機能
+description: Triage Engineに搭載されているすべてのノードと、それぞれの機能
weight: 3
audience: pro
aliases:
- /ja/automation/rules_engine_v2/node_reference/
+- /ja/automation/rules_engine_2/node_reference/
---
-注: Rules Engine 2.0 は DefectDojo Pro 限定の機能です。
+注: Triage Engine は DefectDojo Pro 限定の機能です。
-Rules Engine 2.0には、4つのカテゴリにわたって25個のノードが搭載されています。このページではそのすべてを解説します。
+Triage Engineには、4つのカテゴリにわたって25個のノードが搭載されています。このページではそのすべてを解説します。
特に断りがない限り、ノードは1つの入力を受け取り、`out` と呼ばれる1つの出力を生成し、受け取ったすべてのアイテムをその出力へと渡します。これはノードを連結する際に重要です。検出事項ノードは検出事項を変更してからアイテムを次へ渡すため、連続して並んだ複数のノードがすべて適用されます。
@@ -217,7 +218,7 @@ Rules Engine 2.0には、4つのカテゴリにわたって25個のノードが
### チャネルが利用できない場合
-送信ノードは、Slackトークン、Microsoft Teams Webhook、JIRA設定、ライセンス済みコネクタなど、ルールの外部にある何かに依存しています。それが欠けているか無効化されている場合、ノードは動作できません。Rules Engine 2.0は黙って失敗するのではなく、3つの異なるタイミングでそれを知らせます。
+送信ノードは、Slackトークン、Microsoft Teams Webhook、JIRA設定、ライセンス済みコネクタなど、ルールの外部にある何かに依存しています。それが欠けているか無効化されている場合、ノードは動作できません。Triage Engineは黙って失敗するのではなく、3つの異なるタイミングでそれを知らせます。
* **パレット内**では、利用できないノードはキャンバスにドラッグする前に、その旨と理由がマークされています。
* **保存時**には、利用できないノードを含むグラフは拒否されます。これは、誰かがその場にいて別のノードを選び直せるタイミングです。
@@ -321,7 +322,7 @@ Webhookエンドポイントに対してJSONをPOSTします。
| 設定 | デフォルト | 備考 |
|---------|---------|-------|
-| **Title** | `Rules Engine 2.0: {{ctx.rule_name}}` | バッチ全体について1回レンダリングされます。 |
+| **Title** | `Triage Engine: {{ctx.rule_name}}` | バッチ全体について1回レンダリングされます。 |
| **Description** | `{{ctx.count}} finding(s) matched the rule {{ctx.rule_name}}.` | バッチ全体について1回レンダリングされます。 |
| **Recipients** | 空 | ユーザー名をカンマ区切りで指定します。空の場合は管理者にアラートが送られます。 |
diff --git a/docs/content/automation/rules_engine_2/node_reference.md b/docs/content/automation/triage_engine/node_reference.md
similarity index 70%
rename from docs/content/automation/rules_engine_2/node_reference.md
rename to docs/content/automation/triage_engine/node_reference.md
index 7391559b2d9..40698eb5c6b 100644
--- a/docs/content/automation/rules_engine_2/node_reference.md
+++ b/docs/content/automation/triage_engine/node_reference.md
@@ -1,14 +1,15 @@
---
title: "Node Reference"
-description: "Every node Rules Engine 2.0 ships with, and what each one does"
+description: "Every node Triage Engine ships with, and what each one does"
weight: 3
audience: pro
aliases:
- /automation/rules_engine_v2/node_reference/
+ - /automation/rules_engine_2/node_reference/
---
-Note: Rules Engine 2.0 is a DefectDojo Pro-only feature.
+Note: Triage Engine is a DefectDojo Pro-only feature.
-Rules Engine 2.0 ships 38 nodes in five categories. This page documents all of them.
+Triage Engine ships 43 nodes in five categories. This page documents all of them.
Unless stated otherwise, a node takes one input, produces one output called `out`, and passes every item it received on to that output. That matters when you chain nodes: a Findings node changes the Finding and then hands the item onward, so several of them in a row all apply.
@@ -101,6 +102,93 @@ ctx.never_imported true when this asset has never received this scan
Wire these into **Egress** nodes — a Slack message, an email, a JIRA issue, a batched digest. Wiring them into a **Findings** node is harmless but pointless: there is no Finding to change, so the node does nothing.
+### When a Scan Has Landed
+
+`trigger.import`
+
+Runs once for each scan import that finishes, or fails, on an asset in scope. Every way a scan reaches DefectDojo counts: an upload in the UI, an import or reimport through the API, a background import, and a connector sync (one event for the whole sync, however many chunks carried it). The trigger fires after the import has finished writing: findings persisted, old findings closed, import history recorded, post-processing run.
+
+| Setting | Default | Notes |
+|---------|---------|-------|
+| **Event** | `completed` | `completed`, `failed`, or either. A failed import is one that raised before or while writing; a parser error counts, and it is announced even when no test was created. |
+| **Scope** | empty | Which assets this rule watches imports on, in the Assets list's vocabulary. Empty is every asset the rule owner can see. |
+| **Engagements** | empty | Narrow to imports into these engagements. Empty watches every engagement of the assets in scope. |
+| **Scan Types** | empty | Scan type names to react to, as a list. Empty reacts to every scan type. |
+
+It emits **one item per import**. The item has no Finding (every `finding.*` path is empty), and carries the test, engagement and asset in their usual places, so templates written for Findings keep working. The import specifics are on `ctx`:
+
+```
+ctx.import_outcome success, empty (the report carried no findings), or failed
+ctx.import_kind import, reimport, or connector_sync
+ctx.import_error the failure message, for a failed import
+ctx.findings_created findings the import created
+ctx.findings_closed findings it closed
+ctx.findings_reactivated findings it reactivated
+ctx.findings_untouched findings it left as they were
+ctx.build_id the build id the import was submitted with, if any
+ctx.commit_hash the commit, if any
+ctx.branch_tag the branch or tag, if any
+ctx.version the version, if any
+ctx.test_ids the test the import wrote, for the report node's "triggering imports" scope
+```
+
+### When a Group of Scans Has Landed
+
+`trigger.import_group`
+
+Waits for a set of scan types to finish importing into an asset, then fires **once** for the whole group. It has two outputs: `complete` when every expected scan arrived, `incomplete` when the group gave up with scans still missing or failed. Wire the action for a finished pipeline (typically **Generate a Report**) to `complete`, and whatever should happen when the pipeline did not finish (an email naming the missing scans, or nothing) to `incomplete`.
+
+A group is three separate decisions, and the settings keep them apart: **which scans make up the group**, **which arrivals belong together**, and **when it is safe to act**.
+
+| Setting | Default | Notes |
+|---------|---------|-------|
+| **Scope** | empty | Which assets this rule watches, in the Assets list's vocabulary. Each asset waits for its own group. |
+| **Engagements** | empty | Narrow to these engagements. When set, each engagement waits for its own group instead of the asset as a whole. |
+| **Expected Scans** | `The scan types listed below` | Or `Every scan type seen recently`: the group is whatever scan types the asset has received within the lookback. That finds a scanner that stopped, but cannot find one that was never wired up. |
+| **Scan Types** | empty | The group, as a list of scan type names. A member may instead be an object `{"scan_type": "ZAP Scan", "required": false, "on_failure": "count_as_arrived"}` to make it optional or give it its own failure policy. |
+| **Lookback (days)** | `30` | Shown for **Every scan type seen recently**. How far back to look for the scan types the asset receives. |
+| **Group Imports By** | `Arrival time only` | With a key (`Build ID`, `Commit hash`, `Branch or tag`, or `A test tag`), imports sharing the same value wait together and different values wait separately. Without one, the first arrival opens the group and later arrivals of missing scan types join it. |
+| **Tag Prefix** | empty | Shown for **A test tag**. Only test tags starting with this correlate, for example `pipeline:`. |
+| **Gives Up** | `After the maximum wait` | Or `At each tick of this rule's schedule`: every tick closes whatever is open, incomplete if scans are still missing. The schedule option needs a schedule on the rule. |
+| **Maximum Wait (minutes)** | `1440` | Shown for **After the maximum wait**. How long after the first arrival the group waits for the rest before firing `incomplete`. Set it a little longer than the slowest scanner takes to report. |
+| **Settle (minutes)** | `2` | A quiet period after the last expected scan lands before the rule fires, so a report is not built while that import is still being deduplicated. Zero fires as soon as the last scan lands. |
+| **When a Scan Fails** | `Keep waiting for the deadline` | What a failed import of an expected scan type does to the group. See below. |
+
+**How a group waits.** The first expected scan to land opens a *cycle* for its asset (and engagement, when narrowed; and correlation key, when grouping by one). Each further expected scan is recorded in that cycle; a scan type that lands twice keeps the latest import, so an hourly scanner and a daily one in the same group produce "the latest hourly result at the moment the daily one landed". When every required scan has arrived and the settle delay has passed, the cycle closes `complete`. When the maximum wait passes first, or the rule's schedule ticks (for **At each tick of this rule's schedule**), it closes `incomplete`. A scan landing after the cycle closed opens the next one. Pressing **Run** on the rule closes every open cycle as it stands, which is how you fire a group that is never going to complete.
+
+**When a scan fails.** A failed import of an expected scan type is recorded against the cycle, and what happens next is the policy:
+
+| Policy | Effect |
+|--------|--------|
+| **Keep waiting for the deadline** | The failure is recorded and the group keeps waiting. A retry that lands replaces it. At the deadline the rule fires `incomplete`, and the items say which scans failed and which never came. |
+| **Fire incomplete immediately** | The cycle closes `incomplete` the moment a scan fails. |
+| **Count it as arrived** | The failed scan satisfies the group; the cycle can complete, and the items still say which scan failed. |
+
+A member listed as an object may override the rule's policy for itself. An optional member (`"required": false`) never blocks completion and never triggers a failure policy; it is simply included if it arrives.
+
+**What the items look like.** The rule fires with **one item per expected scan type**, arrived or not. Like a missing-scan item, each has an empty Finding block; the test, engagement and asset are filled in for scans that arrived and empty for scans that did not. Every item carries the whole cycle on `ctx`, so a template on any of them can describe the group:
+
+```
+ctx.cycle_status complete or incomplete
+ctx.import_summary one line, for example "3 of 4 feeds arrived; missing: ZAP Scan"
+ctx.expected_count how many scan types the group expects
+ctx.arrived_count how many arrived
+ctx.missing_count how many never came
+ctx.failed_count how many failed
+ctx.arrived_members the scan types that arrived, as a list
+ctx.missing_members the scan types that never came
+ctx.failed_members the scan types whose import failed
+ctx.test_ids the tests the arrived scans wrote
+ctx.member_scan_type this item's scan type
+ctx.member_status this item's scan: arrived, failed, or missing
+ctx.member_outcome success, empty, or failed, when it arrived
+ctx.findings_created finding counts of this item's import, as on When a Scan Has Landed
+```
+
+Two egress settings are built for these items. **Generate a Report** has a **Findings Included** option, `Findings of the Triggering Imports`, that reports on every Finding of the tests the group wrote, however many there are. **Send an Email** offers `{{ctx.imports_html}}`, a list of the group's scans and how each one ended, and `{{ctx.import_summary}}` renders in any template, including the report node's announcement.
+
+The shipped template **Report when a group of scans has landed** wires all of this: the group trigger, a report on `complete`, and an email naming the missing scans on `incomplete`.
+
## Logic
### If / Filter
@@ -276,6 +364,18 @@ Sets the risk, overriding the computed one.
|---------|---------|
| **Risk** | `Low`, `Medium`, `Needs Action`, `Urgent` |
+### Set Potential Agency Impact (PAIN)
+
+`finding.set_pain`
+
+Assigns the FedRAMP Potential Agency Impact (PAIN) rating. When PAIN tiering is enabled on the Asset's SLA configuration, this rating drives the VDR remediation deadline. See [PAIN ratings](/federal_compliance/pain_ratings/) for how the rating feeds remediation timelines.
+
+| Setting | Options |
+|---------|---------|
+| **PAIN rating** | `N1 - minimal customer effect`, `N2 - narrow customer effect`, `N3 - disruptive effect on one agency`, `N4 - debilitating on one agency, or disruptive on several`, `N5 - debilitating effect on more than one agency` |
+
+The options carry FedRAMP's own customer-effect wording rather than the bare `N1`–`N5` codes, so a rule author judges the effect rather than a number.
+
### Set a Custom Field
`finding.set_custom_field`
@@ -418,6 +518,18 @@ Assigns a Risk Priority — a [prioritization engine](/asset_modelling/pro_hiera
Unlike the SLA action, this node does not skip an Asset that is mid-recalculation: nothing reverts its write, so the assignment lands normally either way.
+### Assign to a Dedupe Pool
+
+`asset.assign_dedupe_pool`
+
+Makes the Asset deduplicate together with the rest of a [dedupe pool](/triage_findings/finding_deduplication/pro__dedupe_pools/), or removes it from one.
+
+| Setting | Default | Notes |
+|---------|---------|-------|
+| **Action** | `Assign to Pool` | `Assign to Pool` or `Remove from Pool`. |
+| **Pool** | none | Shown for `Assign to Pool`. The pool these Assets should deduplicate within. Required. |
+| **Matching** | `Same tool` | Which kind of matching this membership governs: `Same tool` or `Cross tool`. Reimport matching is not offered, because a pool has no effect on it. |
+
## Egress
Egress nodes are the nodes that leave DefectDojo. Every one of them records a [Delivery](../deliveries/) before anything is sent, and every one of them honours the rule's **Simulate** or **Live** mode.
@@ -430,7 +542,7 @@ A node sending one message per item stops after 1,000 sends in a single run by d
### When a channel is unavailable
-An egress node depends on something outside the rule: a Slack token, a Microsoft Teams webhook, a JIRA configuration, a licensed connector. When that is missing or switched off, the node cannot work, and Rules Engine 2.0 says so at three different moments rather than failing quietly:
+An egress node depends on something outside the rule: a Slack token, a Microsoft Teams webhook, a JIRA configuration, a licensed connector. When that is missing or switched off, the node cannot work, and Triage Engine says so at three different moments rather than failing quietly:
* **In the palette**, an unavailable node is marked as such, with the reason, before you drag it onto the canvas.
* **On save**, a graph containing an unavailable node is refused. That is the moment somebody is present to pick a different one.
@@ -526,6 +638,20 @@ Two things to know. A signing secret typed here is stored with the rule, so for
Free-text URLs are validated when you save. See [Configuration](../configuration/#outbound-destination-validation) for what is rejected and how to allow private addresses.
+### Publish to an SNS Topic
+
+`notify.sns`
+
+Publishes one message about the batch, or one per item, to an Amazon SNS topic, which fans it out to whatever is subscribed.
+
+| Setting | Default | Notes |
+|---------|---------|-------|
+| **Connection** | none | A [Messaging Connector](/issue_tracking/pro_integration/messaging_connectors/) for Amazon SNS. Required. Unlike the chat channels, SNS has no instance-wide fallback: a connection is the only way to address a topic. |
+| **Destination** | empty | Shown once a connection is chosen. The SNS topic to publish to, as its ARN. |
+| **One Message per Finding** | off | Off publishes one message about the batch. |
+| **Message** | `{{finding.severity}}: {{finding.title}} ({{product.name}})` | Rendered per Finding. |
+| **Findings Listed in the Digest** | `10` | Shown for batch messages. How many Findings the message lists before it says how many more there were. |
+
### Raise an In-App Alert
`notify.alert`
@@ -534,7 +660,7 @@ Creates an in-app alert about the batch.
| Setting | Default | Notes |
|---------|---------|-------|
-| **Title** | `Rules Engine 2.0: {{ctx.rule_name}}` | Rendered once for the whole batch. |
+| **Title** | `Triage Engine: {{ctx.rule_name}}` | Rendered once for the whole batch. |
| **Description** | `{{ctx.count}} finding(s) matched the rule {{ctx.rule_name}}.` | Rendered once for the whole batch. |
| **Recipients** | empty | Usernames, comma separated. Empty alerts the administrators. |
@@ -550,10 +676,10 @@ Generates a report from a template, scoped to the Findings that reached this nod
|---------|---------|-------|
| **Report Template** | none | Which template to generate from. Required. |
| **Format** | `pdf` | `pdf` or `html`. |
-| **Findings Included** | `batch_findings` | `batch_findings` limits the report to the Findings that reached this node. `template_default` lets the template use its own filters. |
+| **Findings Included** | `batch_findings` | `batch_findings` limits the report to the Findings that reached this node. `template_default` lets the template use its own filters. `trigger_tests` (Findings of the Triggering Imports) is for rules that start from **When a Scan Has Landed** or **When a Group of Scans Has Landed**: every Finding of the tests those imports wrote. |
| **Announce Over** | none | A [Messaging Connector](/issue_tracking/pro_integration/messaging_connectors/) to post the download link over once the report is generated. Leave empty to not announce. |
| **Announce To** | empty | Shown once a connection is chosen. Where that connection sends: a Slack channel ID, email addresses, and so on. |
-| **Announcement** | `Report ready: {{ctx.report_url}}` | Shown when announcing. `{{ctx.report_url}}` is the download link. |
+| **Announcement** | `Report ready: {{ctx.report_url}}` | Shown when announcing. `{{ctx.report_url}}` is the download link; `{{ctx.import_summary}}` is the scan group's one-line account when the rule started from a group of scans, and empty otherwise. |
`batch_findings` is what a rule can do that a scheduled report cannot: report on exactly the Findings that just matched.
diff --git a/docs/content/automation/rules_engine_2/node_reference.pt-br.md b/docs/content/automation/triage_engine/node_reference.pt-br.md
similarity index 96%
rename from docs/content/automation/rules_engine_2/node_reference.pt-br.md
rename to docs/content/automation/triage_engine/node_reference.pt-br.md
index 071178df60f..0d7e462926d 100644
--- a/docs/content/automation/rules_engine_2/node_reference.pt-br.md
+++ b/docs/content/automation/triage_engine/node_reference.pt-br.md
@@ -1,15 +1,16 @@
---
title: Referência de Nós
-description: Todos os nós com que o Rules Engine 2.0 vem, e o que cada um faz
+description: Todos os nós com que o Triage Engine vem, e o que cada um faz
weight: 3
audience: pro
aliases:
- /pt-br/automation/rules_engine_v2/node_reference/
+- /pt-br/automation/rules_engine_2/node_reference/
---
-Nota: o Rules Engine 2.0 é um recurso exclusivo do DefectDojo Pro.
+Nota: o Triage Engine é um recurso exclusivo do DefectDojo Pro.
-O Rules Engine 2.0 vem com 25 nós em quatro categorias. Esta página documenta todos eles.
+O Triage Engine vem com 25 nós em quatro categorias. Esta página documenta todos eles.
Salvo indicação contrária, um nó recebe uma entrada, produz uma saída chamada `out`, e repassa a essa saída cada item que recebeu. Isso importa quando você encadeia nós: um nó de Achados altera o Achado e então repassa o item adiante, de modo que vários deles em sequência são todos aplicados.
@@ -217,7 +218,7 @@ Um nó que envia uma mensagem por Achado para por padrão após 1.000 envios em
### Quando um canal está indisponível
-Um nó de saída depende de algo externo à regra: um token do Slack, um webhook do Microsoft Teams, uma configuração do JIRA, um conector licenciado. Quando isso está ausente ou desligado, o nó não consegue funcionar, e o Rules Engine 2.0 avisa disso em três momentos diferentes, em vez de falhar silenciosamente:
+Um nó de saída depende de algo externo à regra: um token do Slack, um webhook do Microsoft Teams, uma configuração do JIRA, um conector licenciado. Quando isso está ausente ou desligado, o nó não consegue funcionar, e o Triage Engine avisa disso em três momentos diferentes, em vez de falhar silenciosamente:
* **Na paleta**, um nó indisponível é marcado como tal, com o motivo, antes de você arrastá-lo para a tela.
* **Ao salvar**, um grafo contendo um nó indisponível é recusado. Esse é o momento em que alguém está presente para escolher outro.
@@ -321,7 +322,7 @@ Cria um alerta no aplicativo sobre o lote.
| Setting | Default | Notes |
|---------|---------|-------|
-| **Title** | `Rules Engine 2.0: {{ctx.rule_name}}` | Renderizado uma vez para o lote inteiro. |
+| **Title** | `Triage Engine: {{ctx.rule_name}}` | Renderizado uma vez para o lote inteiro. |
| **Description** | `{{ctx.count}} finding(s) matched the rule {{ctx.rule_name}}.` | Renderizado uma vez para o lote inteiro. |
| **Recipients** | vazio | Nomes de usuário, separados por vírgula. Vazio alerta os administradores. |
diff --git a/docs/content/automation/rules_engine_2/node_reference.zh-hans.md b/docs/content/automation/triage_engine/node_reference.zh-hans.md
similarity index 96%
rename from docs/content/automation/rules_engine_2/node_reference.zh-hans.md
rename to docs/content/automation/triage_engine/node_reference.zh-hans.md
index 2abdf5b9851..43d9216913a 100644
--- a/docs/content/automation/rules_engine_2/node_reference.zh-hans.md
+++ b/docs/content/automation/triage_engine/node_reference.zh-hans.md
@@ -1,15 +1,16 @@
---
title: 节点参考
-description: Rules Engine 2.0 内置的每一个节点及其作用
+description: Triage Engine 内置的每一个节点及其作用
weight: 3
audience: pro
aliases:
- /zh-hans/automation/rules_engine_v2/node_reference/
+- /zh-hans/automation/rules_engine_2/node_reference/
---
-注意：Rules Engine 2.0 是 DefectDojo Pro 专属功能。
+注意：Triage Engine 是 DefectDojo Pro 专属功能。
-Rules Engine 2.0 内置了分为四大类的 25 个节点。本页对它们逐一进行说明。
+Triage Engine 内置了分为四大类的 25 个节点。本页对它们逐一进行说明。
除非另有说明，每个节点都接受一个输入，产生一个名为 `out` 的输出，并将其收到的每一项都传递给该输出。这一点在你串联多个节点时很重要：一个发现项节点会先修改该发现项，然后再将其向后传递，因此依次排列的多个此类节点都会依次生效。
@@ -217,7 +218,7 @@ Rules Engine 2.0 内置了分为四大类的 25 个节点。本页对它们逐
### 当渠道不可用时
-出站节点依赖于规则之外的某些资源：Slack 令牌、Microsoft Teams webhook、JIRA 配置、已获得许可的连接器等。当这些资源缺失或被关闭时，该节点就无法工作，而 Rules Engine 2.0 会在三个不同的时刻明确告知这一点，而不是悄无声息地失败：
+出站节点依赖于规则之外的某些资源：Slack 令牌、Microsoft Teams webhook、JIRA 配置、已获得许可的连接器等。当这些资源缺失或被关闭时，该节点就无法工作，而 Triage Engine 会在三个不同的时刻明确告知这一点，而不是悄无声息地失败：
* **在节点面板中**，不可用的节点在你将其拖到画布上之前，就已经被标注为不可用并说明原因。
* **在保存时**，包含不可用节点的图会被拒绝保存。这正是有人在场、可以另选一个节点的时刻。
@@ -321,7 +322,7 @@ Rules Engine 2.0 内置了分为四大类的 25 个节点。本页对它们逐
| 设置 | 默认值 | 说明 |
|-----|-----|-----|
-| **标题** | `Rules Engine 2.0: {{ctx.rule_name}}` | 针对整批内容渲染一次。 |
+| **标题** | `Triage Engine: {{ctx.rule_name}}` | 针对整批内容渲染一次。 |
| **描述** | `{{ctx.count}} finding(s) matched the rule {{ctx.rule_name}}.` | 针对整批内容渲染一次。 |
| **接收人** | 空 | 用户名，用逗号分隔。留空则提醒管理员。 |
diff --git a/docs/content/automation/rules_engine_2/runs.de.md b/docs/content/automation/triage_engine/runs.de.md
similarity index 96%
rename from docs/content/automation/rules_engine_2/runs.de.md
rename to docs/content/automation/triage_engine/runs.de.md
index f80ab302c02..720c15ab094 100644
--- a/docs/content/automation/rules_engine_2/runs.de.md
+++ b/docs/content/automation/triage_engine/runs.de.md
@@ -6,11 +6,12 @@ weight: 4
audience: pro
aliases:
- /de/automation/rules_engine_v2/runs/
+- /de/automation/rules_engine_2/runs/
---
-Hinweis: Rules Engine 2.0 ist eine reine DefectDojo-Pro-Funktion.
+Hinweis: Triage Engine ist eine reine DefectDojo-Pro-Funktion.
-Ein **Lauf** ist eine Ausführung einer Regel. Jeder Lauf wird aufgezeichnet, unabhängig davon, ob er erfolgreich war oder fehlgeschlagen ist, und jeder Knoten darin hinterlässt eine Spur. **Rules Engine 2.0 > Läufe** listet sie auf.
+Ein **Lauf** ist eine Ausführung einer Regel. Jeder Lauf wird aufgezeichnet, unabhängig davon, ob er erfolgreich war oder fehlgeschlagen ist, und jeder Knoten darin hinterlässt eine Spur. **Triage Engine > Läufe** listet sie auf.
## Was ein Lauf aufzeichnet
@@ -64,7 +65,7 @@ Wenn ein Lauf auf irgendeine Weise verwaist, zum Beispiel weil der ausführende
## Kaskadierung
-Eine Regel, die einen Befund ändert, erzeugt genau die Art von Ereignis, auf das eine andere Regel reagieren kann. Rules Engine 2.0 erlaubt das, sodass Ketten wie `A -> B -> C` funktionieren, und begrenzt dies auf zwei unabhängige Arten:
+Eine Regel, die einen Befund ändert, erzeugt genau die Art von Ereignis, auf das eine andere Regel reagieren kann. Triage Engine erlaubt das, sodass Ketten wie `A -> B -> C` funktionieren, und begrenzt dies auf zwei unabhängige Arten:
* **Tiefe.** Ein Ereignis darf höchstens **3** Kaskadierungsschritte von der Änderung entfernt zurücklegen, die es ausgelöst hat.
* **Ketten-Zugehörigkeit.** Jedes Ereignis trägt die Liste der Regeln, die in seiner Kette bereits durchlaufen wurden, und eine Regel läuft nie zweimal in derselben Kette. Eine Regel kann sich also nicht selbst erneut auslösen, und zwei Regeln können nicht hin- und herspielen.
diff --git a/docs/content/automation/rules_engine_2/runs.es.md b/docs/content/automation/triage_engine/runs.es.md
similarity index 96%
rename from docs/content/automation/rules_engine_2/runs.es.md
rename to docs/content/automation/triage_engine/runs.es.md
index cc68f5b61df..81fd82b3f99 100644
--- a/docs/content/automation/rules_engine_2/runs.es.md
+++ b/docs/content/automation/triage_engine/runs.es.md
@@ -6,11 +6,12 @@ weight: 4
audience: pro
aliases:
- /es/automation/rules_engine_v2/runs/
+- /es/automation/rules_engine_2/runs/
---
-Nota: Rules Engine 2.0 es una función exclusiva de DefectDojo Pro.
+Nota: Triage Engine es una función exclusiva de DefectDojo Pro.
-Una **ejecución** es una instancia de ejecución de una regla. Cada ejecución se registra, tanto si tuvo éxito como si falló, y cada nodo dentro de ella deja un rastro. **Rules Engine 2.0 > Runs** las enumera.
+Una **ejecución** es una instancia de ejecución de una regla. Cada ejecución se registra, tanto si tuvo éxito como si falló, y cada nodo dentro de ella deja un rastro. **Triage Engine > Runs** las enumera.
## Qué registra una ejecución
@@ -64,7 +65,7 @@ Si una ejecución queda abandonada de alguna forma, por ejemplo porque se mató
## Encadenamiento
-Una regla que cambia un Hallazgo produce exactamente el tipo de evento sobre el que otra regla puede activarse. Rules Engine 2.0 permite esto, de modo que las cadenas `A -> B -> C` funcionan, y lo limita de dos formas independientes:
+Una regla que cambia un Hallazgo produce exactamente el tipo de evento sobre el que otra regla puede activarse. Triage Engine permite esto, de modo que las cadenas `A -> B -> C` funcionan, y lo limita de dos formas independientes:
* **Depth.** Un evento puede viajar como máximo **3** saltos en cascada desde el cambio que lo originó.
diff --git a/docs/content/automation/rules_engine_2/runs.fr.md b/docs/content/automation/triage_engine/runs.fr.md
similarity index 99%
rename from docs/content/automation/rules_engine_2/runs.fr.md
rename to docs/content/automation/triage_engine/runs.fr.md
index 6663a3dbc31..94fb73d2504 100644
--- a/docs/content/automation/rules_engine_2/runs.fr.md
+++ b/docs/content/automation/triage_engine/runs.fr.md
@@ -6,6 +6,7 @@ weight: 4
audience: pro
aliases:
- /fr/automation/rules_engine_v2/runs/
+- /fr/automation/rules_engine_2/runs/
---
Remarque : le Moteur de règles 2.0 est une fonctionnalité réservée à DefectDojo Pro.
diff --git a/docs/content/automation/rules_engine_2/runs.it.md b/docs/content/automation/triage_engine/runs.it.md
similarity index 95%
rename from docs/content/automation/rules_engine_2/runs.it.md
rename to docs/content/automation/triage_engine/runs.it.md
index 94b5051c208..3f8585d0188 100644
--- a/docs/content/automation/rules_engine_2/runs.it.md
+++ b/docs/content/automation/triage_engine/runs.it.md
@@ -6,11 +6,12 @@ weight: 4
audience: pro
aliases:
- /it/automation/rules_engine_v2/runs/
+- /it/automation/rules_engine_2/runs/
---
-Nota: Rules Engine 2.0 è una funzionalità disponibile solo in DefectDojo Pro.
+Nota: Triage Engine è una funzionalità disponibile solo in DefectDojo Pro.
-Un **run** è una singola esecuzione di una regola. Ogni run viene registrato, sia che abbia avuto esito positivo sia che sia fallito, e ogni nodo al suo interno lascia una traccia. **Rules Engine 2.0 > Runs** li elenca.
+Un **run** è una singola esecuzione di una regola. Ogni run viene registrato, sia che abbia avuto esito positivo sia che sia fallito, e ogni nodo al suo interno lascia una traccia. **Triage Engine > Runs** li elenca.
## Cosa registra un run
@@ -64,7 +65,7 @@ Se un run viene in qualche modo abbandonato, ad esempio perché il worker che lo
## Cascata
-Una regola che modifica un Finding produce esattamente il tipo di evento su cui un'altra regola può attivarsi. Rules Engine 2.0 lo consente, quindi catene del tipo `A -> B -> C` funzionano, e le limita in due modi indipendenti:
+Una regola che modifica un Finding produce esattamente il tipo di evento su cui un'altra regola può attivarsi. Triage Engine lo consente, quindi catene del tipo `A -> B -> C` funzionano, e le limita in due modi indipendenti:
* **Profondità.** Un evento può percorrere al massimo **3** passaggi a cascata dalla modifica che lo ha originato.
* **Appartenenza alla catena.** Ogni evento porta con sé l'elenco delle regole già attraversate nella sua catena, e una regola non viene mai eseguita due volte nella stessa catena. Quindi una regola non può riattivare se stessa, e due regole non possono rimbalzare tra loro.
diff --git a/docs/content/automation/rules_engine_2/runs.ja.md b/docs/content/automation/triage_engine/runs.ja.md
similarity index 96%
rename from docs/content/automation/rules_engine_2/runs.ja.md
rename to docs/content/automation/triage_engine/runs.ja.md
index 011147733ce..b87a89d38e0 100644
--- a/docs/content/automation/rules_engine_2/runs.ja.md
+++ b/docs/content/automation/triage_engine/runs.ja.md
@@ -5,11 +5,12 @@ weight: 4
audience: pro
aliases:
- /ja/automation/rules_engine_v2/runs/
+- /ja/automation/rules_engine_2/runs/
---
-注: Rules Engine 2.0はDefectDojo Pro限定機能です。
+注: Triage EngineはDefectDojo Pro限定機能です。
-**実行（run）**とは、1つのルールの1回分の実行のことです。成功したか失敗したかにかかわらず、すべての実行が記録され、その内部の各ノードも痕跡を残します。**Rules Engine 2.0 > Runs**にその一覧が表示されます。
+**実行（run）**とは、1つのルールの1回分の実行のことです。成功したか失敗したかにかかわらず、すべての実行が記録され、その内部の各ノードも痕跡を残します。**Triage Engine > Runs**にその一覧が表示されます。
## 実行が記録する内容
@@ -63,7 +64,7 @@ Egress（送出）についても同じ規則が適用されます。配信は
## カスケード
-Findingを変更するルールは、まさに他のルールがトリガーとして利用できる種類のイベントを生成します。Rules Engine 2.0はこれを許可しており、`A -> B -> C`のような連鎖が機能します。ただし、これを2つの独立した方法で制限しています。
+Findingを変更するルールは、まさに他のルールがトリガーとして利用できる種類のイベントを生成します。Triage Engineはこれを許可しており、`A -> B -> C`のような連鎖が機能します。ただし、これを2つの独立した方法で制限しています。
* **Depth（深さ）。** イベントは、それを発生させた変更から最大**3**回のカスケードホップまでしか伝播できません。
* **Chain membership（チェーン所属）。** すべてのイベントは、そのチェーン内で既に通過したルールの一覧を保持しており、同じルールが同じチェーン内で2回実行されることはありません。そのため、ルールが自分自身を再トリガーすることも、2つのルールが互いにやり取りを繰り返すこと（ピンポン）もできません。
diff --git a/docs/content/automation/rules_engine_2/runs.md b/docs/content/automation/triage_engine/runs.md
similarity index 96%
rename from docs/content/automation/rules_engine_2/runs.md
rename to docs/content/automation/triage_engine/runs.md
index e0b98018362..a78eac51c2d 100644
--- a/docs/content/automation/rules_engine_2/runs.md
+++ b/docs/content/automation/triage_engine/runs.md
@@ -5,10 +5,11 @@ weight: 4
audience: pro
aliases:
- /automation/rules_engine_v2/runs/
+ - /automation/rules_engine_2/runs/
---
-Note: Rules Engine 2.0 is a DefectDojo Pro-only feature.
+Note: Triage Engine is a DefectDojo Pro-only feature.
-A **run** is one execution of one rule. Every run is recorded, whether it succeeded or failed, and every node inside it leaves a trace. **Rules Engine 2.0 > Runs** lists them.
+A **run** is one execution of one rule. Every run is recorded, whether it succeeded or failed, and every node inside it leaves a trace. **Triage Engine > Runs** lists them.
## What a run records
@@ -62,7 +63,7 @@ If a run is somehow abandoned, for example because the worker executing it was k
## Cascading
-A rule that changes a Finding produces exactly the kind of event another rule can trigger on. Rules Engine 2.0 allows that, so `A -> B -> C` chains work, and bounds it in two independent ways:
+A rule that changes a Finding produces exactly the kind of event another rule can trigger on. Triage Engine allows that, so `A -> B -> C` chains work, and bounds it in two independent ways:
* **Depth.** An event may travel at most **3** cascade hops from the change that originated it.
* **Chain membership.** Every event carries the list of rules already traversed in its chain, and a rule never runs twice in the same chain. So a rule cannot re-trigger itself, and two rules cannot ping-pong.
diff --git a/docs/content/automation/rules_engine_2/runs.pt-br.md b/docs/content/automation/triage_engine/runs.pt-br.md
similarity index 96%
rename from docs/content/automation/rules_engine_2/runs.pt-br.md
rename to docs/content/automation/triage_engine/runs.pt-br.md
index 7c7bc4e5c7b..dda663e5bae 100644
--- a/docs/content/automation/rules_engine_2/runs.pt-br.md
+++ b/docs/content/automation/triage_engine/runs.pt-br.md
@@ -6,11 +6,12 @@ weight: 4
audience: pro
aliases:
- /pt-br/automation/rules_engine_v2/runs/
+- /pt-br/automation/rules_engine_2/runs/
---
-Observação: o Rules Engine 2.0 é um recurso exclusivo do DefectDojo Pro.
+Observação: o Triage Engine é um recurso exclusivo do DefectDojo Pro.
-Um **run** (execução) é a execução de uma regra. Toda execução é registrada, tenha sido bem-sucedida ou não, e cada nó dentro dela deixa um rastro. **Rules Engine 2.0 > Runs** lista essas execuções.
+Um **run** (execução) é a execução de uma regra. Toda execução é registrada, tenha sido bem-sucedida ou não, e cada nó dentro dela deixa um rastro. **Triage Engine > Runs** lista essas execuções.
## O que uma execução registra
@@ -64,7 +65,7 @@ Se uma execução for de alguma forma abandonada, por exemplo porque o worker qu
## Encadeamento (cascata)
-Uma regra que altera um Finding produz exatamente o tipo de evento que outra regra pode usar como gatilho. O Rules Engine 2.0 permite isso, de modo que cadeias `A -> B -> C` funcionam, e as limita de duas formas independentes:
+Uma regra que altera um Finding produz exatamente o tipo de evento que outra regra pode usar como gatilho. O Triage Engine permite isso, de modo que cadeias `A -> B -> C` funcionam, e as limita de duas formas independentes:
* **Depth (profundidade).** Um evento pode percorrer no máximo **3** saltos de cascata a partir da alteração que o originou.
* **Pertencimento à cadeia.** Todo evento carrega a lista de regras já percorridas em sua cadeia, e uma regra nunca é executada duas vezes na mesma cadeia. Assim, uma regra não pode disparar a si mesma novamente, e duas regras não podem ficar em ping-pong.
diff --git a/docs/content/automation/rules_engine_2/runs.zh-hans.md b/docs/content/automation/triage_engine/runs.zh-hans.md
similarity index 99%
rename from docs/content/automation/rules_engine_2/runs.zh-hans.md
rename to docs/content/automation/triage_engine/runs.zh-hans.md
index fda48ee0f41..47c2f00f66f 100644
--- a/docs/content/automation/rules_engine_2/runs.zh-hans.md
+++ b/docs/content/automation/triage_engine/runs.zh-hans.md
@@ -5,6 +5,7 @@ weight: 4
audience: pro
aliases:
- /zh-hans/automation/rules_engine_v2/runs/
+- /zh-hans/automation/rules_engine_2/runs/
---
注意：规则引擎 2.0 是 DefectDojo Pro 专属功能。
diff --git a/docs/content/connectors/downstream/troubleshooting_jira.de.md b/docs/content/connectors/downstream/troubleshooting_jira.de.md
index 1d34ea14b5c..56844a1620d 100644
--- a/docs/content/connectors/downstream/troubleshooting_jira.de.md
+++ b/docs/content/connectors/downstream/troubleshooting_jira.de.md
@@ -24,7 +24,7 @@ Wenn die Einstellung bereits aktiviert ist und Sie das Jira-Menü trotzdem nicht
Wenn die Jira-Integration von DefectDojo mit Verbindungsfehlern wie „connection refused“, „no route to host“ oder allgemeinen Fehlern beim TLS-Handshake fehlschlägt — und die Anmeldedaten selbst gültig sind — befindet sich Ihre DefectDojo-Instanz möglicherweise hinter einer Firewall, die ausgehenden Datenverkehr über einen Forward-HTTPS-Proxy verlangt.
-Setzen Sie bei On-Prem-Pro-Deployments die Umgebungsvariablen `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` für das Deployment. `dojo-compose-cli` gibt diese automatisch an die Container `uwsgi`, `celeryworker` und Connector weiter. Die vollständige Konfigurationsanleitung finden Sie unter [DefectDojo hinter einem Forward-HTTPS-Proxy betreiben](/onprem_deployment/forward_proxy/).
+Setzen Sie bei On-Prem-Pro-Deployments die Umgebungsvariablen `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` für das Deployment. `dojo-compose-cli` gibt diese automatisch an die Container `uwsgi`, `celeryworker` und Connector weiter. Die vollständige Konfigurationsanleitung finden Sie unter [DefectDojo hinter einem Forward-HTTPS-Proxy betreiben](/get_started/pro/onprem/forward_proxy/).
> Hinweis: Das Setzen von `HTTPS_PROXY` konfiguriert nur den **ausgehenden** Datenverkehr von DefectDojo. Es hat keinen Einfluss darauf, ob Jira **eingehende** Webhooks an DefectDojo zustellen kann — siehe dazu weiter unten [Änderungen an Jira-Issues aktualisieren die Befunde in DefectDojo nicht](#changes-made-to-jira-issues-are-not-updating-findings-in-defectdojo).
diff --git a/docs/content/connectors/downstream/troubleshooting_jira.es.md b/docs/content/connectors/downstream/troubleshooting_jira.es.md
index 088a5b6469e..1570c0850e4 100644
--- a/docs/content/connectors/downstream/troubleshooting_jira.es.md
+++ b/docs/content/connectors/downstream/troubleshooting_jira.es.md
@@ -24,7 +24,7 @@ Si la configuración ya está habilitada y aún no puede ver el menú de Jira, e
Si la integración de Jira de DefectDojo falla con errores de conexión similares a "connection refused", "no route to host" o fallos genéricos del protocolo de enlace TLS — y las credenciales en sí son válidas — es posible que su instancia de DefectDojo esté detrás de un firewall que exige que el tráfico saliente pase por un proxy HTTPS de reenvío.
-Para implementaciones Pro on-prem, configure las variables de entorno `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` en la implementación. `dojo-compose-cli` las propaga automáticamente a los contenedores `uwsgi`, `celeryworker` y de Connector. Consulte [Ejecutar DefectDojo detrás de un proxy HTTPS de reenvío](/onprem_deployment/forward_proxy/) para ver el recorrido completo de configuración.
+Para implementaciones Pro on-prem, configure las variables de entorno `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` en la implementación. `dojo-compose-cli` las propaga automáticamente a los contenedores `uwsgi`, `celeryworker` y de Connector. Consulte [Ejecutar DefectDojo detrás de un proxy HTTPS de reenvío](/get_started/pro/onprem/forward_proxy/) para ver el recorrido completo de configuración.
> Nota: configurar `HTTPS_PROXY` solo configura el tráfico **saliente** de DefectDojo. No afecta la capacidad de Jira para entregar webhooks **entrantes** a DefectDojo — consulte [Los cambios realizados en incidencias de Jira no actualizan los Hallazgos en DefectDojo](#changes-made-to-jira-issues-are-not-updating-findings-in-defectdojo) más abajo para ese caso.
diff --git a/docs/content/connectors/downstream/troubleshooting_jira.fr.md b/docs/content/connectors/downstream/troubleshooting_jira.fr.md
index a42ca2ef75b..d70f3103bac 100644
--- a/docs/content/connectors/downstream/troubleshooting_jira.fr.md
+++ b/docs/content/connectors/downstream/troubleshooting_jira.fr.md
@@ -24,7 +24,7 @@ Si le paramètre est déjà activé et que vous ne voyez toujours pas le menu Ji
Si l'intégration Jira de DefectDojo échoue avec des erreurs de connexion du type « connection refused », « no route to host » ou des échecs génériques de négociation TLS — et que les identifiants eux-mêmes sont valides — il se peut que votre instance DefectDojo se trouve derrière un pare-feu qui exige que le trafic sortant transite par un proxy HTTPS sortant.
-Pour les déploiements Pro sur site, définissez les variables d'environnement `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` sur le déploiement. `dojo-compose-cli` les propage automatiquement aux conteneurs `uwsgi`, `celeryworker` et Connector. Consultez [Exécuter DefectDojo derrière un proxy HTTPS sortant](/onprem_deployment/forward_proxy/) pour la procédure de configuration complète.
+Pour les déploiements Pro sur site, définissez les variables d'environnement `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` sur le déploiement. `dojo-compose-cli` les propage automatiquement aux conteneurs `uwsgi`, `celeryworker` et Connector. Consultez [Exécuter DefectDojo derrière un proxy HTTPS sortant](/get_started/pro/onprem/forward_proxy/) pour la procédure de configuration complète.
> Remarque : la définition de `HTTPS_PROXY` configure uniquement le trafic **sortant** depuis DefectDojo. Cela n'affecte pas la capacité de Jira à délivrer des webhooks **entrants** vers DefectDojo — consultez [Les modifications apportées aux tickets Jira ne mettent pas à jour les Constatations dans DefectDojo](#changes-made-to-jira-issues-are-not-updating-findings-in-defectdojo) ci-dessous pour ce cas.
diff --git a/docs/content/connectors/downstream/troubleshooting_jira.it.md b/docs/content/connectors/downstream/troubleshooting_jira.it.md
index dff98c0521b..6e9b6ec8ffe 100644
--- a/docs/content/connectors/downstream/troubleshooting_jira.it.md
+++ b/docs/content/connectors/downstream/troubleshooting_jira.it.md
@@ -24,7 +24,7 @@ Se l'impostazione è già abilitata e continui a non vedere il menu Jira, al tuo
Se l'integrazione Jira di DefectDojo fallisce con errori di connessione del tipo "connection refused", "no route to host" o generici fallimenti dell'handshake TLS — e le credenziali stesse sono valide — la tua istanza DefectDojo potrebbe trovarsi dietro un firewall che richiede che il traffico in uscita passi attraverso un proxy HTTPS in avanti (forward proxy).
-Per i deployment Pro on-prem, imposta le variabili d'ambiente `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` sul deployment. `dojo-compose-cli` le propaga automaticamente ai container `uwsgi`, `celeryworker` e Connector. Consulta [Eseguire DefectDojo dietro un forward HTTPS proxy](/onprem_deployment/forward_proxy/) per la procedura completa di configurazione.
+Per i deployment Pro on-prem, imposta le variabili d'ambiente `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` sul deployment. `dojo-compose-cli` le propaga automaticamente ai container `uwsgi`, `celeryworker` e Connector. Consulta [Eseguire DefectDojo dietro un forward HTTPS proxy](/get_started/pro/onprem/forward_proxy/) per la procedura completa di configurazione.
> Nota: impostare `HTTPS_PROXY` configura solo il traffico **in uscita** da DefectDojo. Non influisce sulla capacità di Jira di inviare webhook **in entrata** verso DefectDojo — per quel caso consulta [Le modifiche apportate ai ticket Jira non aggiornano i Riscontri in DefectDojo](#changes-made-to-jira-issues-are-not-updating-findings-in-defectdojo) più avanti.
diff --git a/docs/content/connectors/downstream/troubleshooting_jira.ja.md b/docs/content/connectors/downstream/troubleshooting_jira.ja.md
index 7d55c37991c..7869bfba3e4 100644
--- a/docs/content/connectors/downstream/troubleshooting_jira.ja.md
+++ b/docs/content/connectors/downstream/troubleshooting_jira.ja.md
@@ -24,7 +24,7 @@ Jira 連携でよくある問題と、その対処方法を以下に示します
DefectDojo の Jira 連携が「connection refused」「no route to host」、または一般的な TLS ハンドシェイクエラーのような接続エラーで失敗し、かつ認証情報自体は有効である場合、DefectDojo インスタンスがファイアウォールの内側にあり、送信トラフィックがフォワード HTTPS プロキシを経由する必要があるのかもしれません。
-オンプレミスの Pro 版デプロイメントでは、デプロイメント上に `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` 環境変数を設定してください。`dojo-compose-cli` はこれらを `uwsgi`、`celeryworker`、Connector の各コンテナに自動的に伝播します。設定手順の全体については [フォワード HTTPS プロキシの背後で DefectDojo を実行する](/onprem_deployment/forward_proxy/) を参照してください。
+オンプレミスの Pro 版デプロイメントでは、デプロイメント上に `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` 環境変数を設定してください。`dojo-compose-cli` はこれらを `uwsgi`、`celeryworker`、Connector の各コンテナに自動的に伝播します。設定手順の全体については [フォワード HTTPS プロキシの背後で DefectDojo を実行する](/get_started/pro/onprem/forward_proxy/) を参照してください。
> Note: `HTTPS_PROXY` の設定は、DefectDojo からの **送信 (outbound)** トラフィックのみを構成します。Jira から DefectDojo への **受信 (inbound)** Webhook の配信には影響しません。そのケースについては、以下の [Jira issue の変更が DefectDojo の検出事項に反映されない](#changes-made-to-jira-issues-are-not-updating-findings-in-defectdojo) を参照してください。
diff --git a/docs/content/connectors/downstream/troubleshooting_jira.md b/docs/content/connectors/downstream/troubleshooting_jira.md
index c3e8d71f226..40c4657e2cd 100644
--- a/docs/content/connectors/downstream/troubleshooting_jira.md
+++ b/docs/content/connectors/downstream/troubleshooting_jira.md
@@ -24,7 +24,7 @@ If the setting is already enabled and you still can't see the Jira menu, your us
If DefectDojo's Jira integration fails with connection errors that look like "connection refused", "no route to host", or generic TLS handshake failures — and the credentials themselves are valid — your DefectDojo instance may be behind a firewall that requires outbound traffic to go through a forward HTTPS proxy.
-For on-prem Pro deployments, set the `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` environment variables on the deployment. `dojo-compose-cli` propagates these to the `uwsgi`, `celeryworker`, and Connector containers automatically. See [Running DefectDojo Behind a Forward HTTPS Proxy](/onprem_deployment/forward_proxy/) for the full configuration walkthrough.
+For on-prem Pro deployments, set the `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` environment variables on the deployment. `dojo-compose-cli` propagates these to the `uwsgi`, `celeryworker`, and Connector containers automatically. See [Running DefectDojo Behind a Forward HTTPS Proxy](/get_started/pro/onprem/forward_proxy/) for the full configuration walkthrough.
> Note: setting `HTTPS_PROXY` configures **outbound** traffic from DefectDojo only. It does not affect Jira's ability to deliver **inbound** webhooks to DefectDojo — see [Changes made to Jira issues are not updating Findings in DefectDojo](#changes-made-to-jira-issues-are-not-updating-findings-in-defectdojo) below for that case.
diff --git a/docs/content/connectors/downstream/troubleshooting_jira.pt-br.md b/docs/content/connectors/downstream/troubleshooting_jira.pt-br.md
index 848e00f3f2f..be2ea88dad5 100644
--- a/docs/content/connectors/downstream/troubleshooting_jira.pt-br.md
+++ b/docs/content/connectors/downstream/troubleshooting_jira.pt-br.md
@@ -24,7 +24,7 @@ Se a configuração já estiver habilitada e você ainda não conseguir ver o me
Se a integração do Jira no DefectDojo falhar com erros de conexão do tipo "connection refused", "no route to host" ou falhas genéricas no handshake TLS — e as credenciais em si forem válidas — sua instância do DefectDojo pode estar atrás de um firewall que exige que o tráfego de saída passe por um proxy HTTPS de encaminhamento (forward proxy).
-Para implantações Pro on-prem, defina as variáveis de ambiente `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` na implantação. O `dojo-compose-cli` propaga essas variáveis automaticamente para os containers `uwsgi`, `celeryworker` e Connector. Veja [Executando o DefectDojo Atrás de um Proxy HTTPS de Encaminhamento](/onprem_deployment/forward_proxy/) para o passo a passo completo da configuração.
+Para implantações Pro on-prem, defina as variáveis de ambiente `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` na implantação. O `dojo-compose-cli` propaga essas variáveis automaticamente para os containers `uwsgi`, `celeryworker` e Connector. Veja [Executando o DefectDojo Atrás de um Proxy HTTPS de Encaminhamento](/get_started/pro/onprem/forward_proxy/) para o passo a passo completo da configuração.
> Nota: definir `HTTPS_PROXY` configura apenas o tráfego de **saída** do DefectDojo. Isso não afeta a capacidade do Jira de entregar webhooks de **entrada** ao DefectDojo — veja [Alterações feitas em issues do Jira não atualizam os Achados no DefectDojo](#changes-made-to-jira-issues-are-not-updating-findings-in-defectdojo) abaixo para esse caso.
diff --git a/docs/content/connectors/downstream/troubleshooting_jira.zh-hans.md b/docs/content/connectors/downstream/troubleshooting_jira.zh-hans.md
index 50d74c638ba..6e13b16d037 100644
--- a/docs/content/connectors/downstream/troubleshooting_jira.zh-hans.md
+++ b/docs/content/connectors/downstream/troubleshooting_jira.zh-hans.md
@@ -24,7 +24,7 @@ aliases:
如果 DefectDojo 的 Jira 集成出现类似“connection refused”“no route to host”之类的连接错误，或出现通用的 TLS 握手失败——而且凭据本身是有效的——那么您的 DefectDojo 实例可能位于防火墙之后，出站流量需要经过正向 HTTPS 代理。
-对于本地部署的 Pro 版本，请在部署环境中设置 `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` 环境变量。`dojo-compose-cli` 会自动将这些变量传递给 `uwsgi`、`celeryworker` 以及 Connector 容器。完整配置步骤请参见[在正向 HTTPS 代理后运行 DefectDojo](/onprem_deployment/forward_proxy/)。
+对于本地部署的 Pro 版本，请在部署环境中设置 `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` 环境变量。`dojo-compose-cli` 会自动将这些变量传递给 `uwsgi`、`celeryworker` 以及 Connector 容器。完整配置步骤请参见[在正向 HTTPS 代理后运行 DefectDojo](/get_started/pro/onprem/forward_proxy/)。
> 注意：设置 `HTTPS_PROXY` 只会配置 DefectDojo 的**出站**流量。它不会影响 Jira 向 DefectDojo 投递**入站** webhook 的能力——这种情况请参见下方的 [Jira 问题的更改未能更新 DefectDojo 中的发现项](#changes-made-to-jira-issues-are-not-updating-findings-in-defectdojo)。
diff --git a/docs/content/connectors/toolreference/aqua_supply_chain.md b/docs/content/connectors/toolreference/aqua_supply_chain.md
index b086c6eb41e..67eb9815649 100644
--- a/docs/content/connectors/toolreference/aqua_supply_chain.md
+++ b/docs/content/connectors/toolreference/aqua_supply_chain.md
@@ -15,7 +15,16 @@ An **admin-generated** Aqua **API key and secret**, created under **Account Mana
1. Enter your Aqua Supply Chain **edge** host in the **Location** field, for example `https://eu-central-1.edge.cloud.aquasec.com`. This is not the tenant URL the Aqua Security connector uses. Aqua Supply Chain Security answers on the region's **edge** host, not `.cloud.aquasec.com`.
2. Enter the API key in the **API Key** field.
3. Enter the API secret in the **API Secret** field.
-4. If your tenant is in the EU, set the **Auth Host** field to `https://eu-1.api.cloudsploit.com`. Leave it blank for the US host, `https://api.cloudsploit.com`. Aqua caps the issued authentication token at two hours, regardless of the validity the connector requests. The connector re-authenticates on its own when the token expires.
+4. Set the **Auth Host** field to your region's Aqua **CSPM API** host. This is a different host from the **Location** edge host above, and it is used only to exchange the API key and secret for a token. Pick the row for your region:
+
+ | Region | Auth Host |
+ |--------|-----------|
+ | US | `https://api.cloudsploit.com` (or leave blank) |
+ | EU | `https://eu-1.api.cloudsploit.com` |
+ | Singapore | `https://asia-1.api.cloudsploit.com` |
+ | Sydney | `https://ap-2.api.cloudsploit.com` |
+
+ Do not put the edge host (a `cloud.aquasec.com` address) in **Auth Host**, and do not put the CSPM API host in **Location**. Aqua caps the issued authentication token at two hours, regardless of the validity the connector requests. The connector re-authenticates on its own when the token expires.
5. Optionally, set **Scan Categories** to a comma-separated list of the categories to import. The five values are `vulnerabilities` (SCA), `secrets`, `iacMisconfigurations` (IaC), `sast` and `pipelineMisconfigurations` (Pipeline). Leave it blank to import all five. Each finding carries a `category:` tag naming the category it came from.
6. Optionally, set a **Minimum Severity** to limit which findings are imported. Aqua reports severity as a 0-4 value, which DefectDojo maps to Info, Low, Medium, High and Critical.
@@ -25,12 +34,36 @@ Each repository in the tenant becomes a Record. A repository that disappears fro
A repository's default branch is always imported. Two optional fields extend this:
-- **Branch**: a comma-separated list of exact branch names or `*` wildcard families, for example `release/*, bugfix/*`. Every entry adds its matching branches on top of the default branch. Blank entries are ignored.
-- **Track Scanned Branches**: when enabled, each imported branch gets its own engagement on the mapped Record. A fix on one branch then cannot close another branch's findings. The default branch is imported first. A finding that also appears on another branch is marked a duplicate of the default branch's finding. When this is off, all selected branches import into the Record's default engagement.
+- **Branch**: a comma-separated list of exact branch names or `*` wildcard families, for example `release/*, bugfix/*`. Every entry adds its matching branches on top of the default branch. Blank entries are ignored. A branch imports only if Aqua returns it for that repository in the scan-results feed the connector reads (see the note below).
+- **Track Scanned Branches**: when enabled, each imported branch gets its own engagement on the mapped Record. A fix on one branch then cannot close another branch's findings. The default branch is imported first. A finding that also appears on another branch is marked a duplicate of the default branch's finding, unless **Separate Deduplication Per Branch** is on. When this is off, all selected branches import into the Record's default engagement.
+
+This setting also affects which branches are selected when **Branch** is blank. If **Track Scanned Branches** is off, only the default branch is imported. If it is on, every branch Aqua returns for the repository in its scan-results feed is imported.
+
+The connector imports the branches Aqua returns for a repository in its scan-results feed. For some repositories and source types (for example Azure DevOps), that feed returns only the repository's default branch, even when Aqua has scanned other branches and shows their results in the Aqua console. When that happens, a **Branch** entry naming a non-default branch contributes no findings and no engagement is created for it, and only the default branch is imported. If you expect a branch to import and it does not, contact DefectDojo support. Broader support for non-default branches is being worked on.
+
+#### Separate Deduplication Per Branch
+
+By default, the same issue found on two branches is one finding. The second branch's copy is
+marked a duplicate of the default branch's finding. This keeps one row per real issue when a
+release branch carries the same code as the default branch.
-This setting also affects which branches are selected when **Branch** is blank. If **Track Scanned Branches** is off, only the default branch is imported. If it is on, every branch Aqua has scanned is imported.
+Turn on **Separate Deduplication Per Branch** to keep each branch apart. The same issue on two
+branches then stays two findings, and each branch reports its own counts.
-Aqua only stores results for a branch it has actually scanned. A Branch value that matches no scanned branch contributes no findings for that branch.
+This setting applies only to branches that have their own engagement. Turn on **Track Scanned
+Branches** first if you import more than the default branch. It also has an effect only when
+deduplication is enabled in System Settings.
+
+A change takes effect on the next sync. It applies to every branch that sync imports, including
+branches that were imported before you changed the setting. A branch that Aqua no longer reports
+keeps its previous setting.
+
+The connector owns this setting on the branch engagements it creates. If you change it by hand
+on one of those engagements, the next sync sets it back to what the connector is configured for.
+
+Findings that were already marked as duplicates before you turned the setting on keep that mark.
+A later sync does not change them, and the `dedupe` management command skips findings that are
+already duplicates. If you need those findings active again, reopen them by hand.
#### Filing
@@ -43,3 +76,8 @@ Aqua can return several byte-identical rows for the same finding. One example is
#### Sync cost
A full sync pulls the whole tenant in a handful of requests. It sends roughly one request per 10,000 findings, plus the repository list, which takes two or three requests. The connector groups the results locally.
+
+#### Troubleshooting
+
+- **Validation fails with `aqua token exchange failed: unexpected status 405`** (or an "Auth Host redirected" message): the **Auth Host** is not your region's CSPM API host. The token exchange is a `POST` to `/v2/tokens`, and Aqua's gateway answers a `405` when the request lands on a host that redirects it. Set **Auth Host** to the `*.api.cloudsploit.com` host for your region (see the table above) and keep the edge `cloud.aquasec.com` host in **Location**.
+- **Validation fails with `401`/`Access denied`**: the API key or secret is wrong, or the key is not admin-generated. Regenerate the key and secret under **Account Management \> API Keys** and re-enter both.
diff --git a/docs/content/connectors/toolreference/microsoft_defender.md b/docs/content/connectors/toolreference/microsoft_defender.md
index 9a3ac9c71d7..997aba5f1cf 100644
--- a/docs/content/connectors/toolreference/microsoft_defender.md
+++ b/docs/content/connectors/toolreference/microsoft_defender.md
@@ -6,6 +6,8 @@ audience: pro
---
The Microsoft Defender connector imports device vulnerability findings from **Microsoft Defender Vulnerability Management (MDVM)** — one finding per device / software version / CVE combination, including severity, CVSS score, exploitability level and recommended security updates. DefectDojo will discover your Defender **device groups** and create a Record for each one; devices that aren't assigned to any device group are collected under a synthetic **Unassigned** group.
+Here a *device* is a single onboarded machine (identified by its Microsoft device ID), so one machine with several vulnerable software versions produces several findings. A tenant with thousands of devices can therefore produce a large number of findings; see [Importing in phases with device groups](#importing-in-phases-with-device-groups) below to bring them in a few device groups at a time.
+
**Please note:** this Connector is distinct from the file\-based **"MSDefender Parser"** scan type, which imports manually exported Defender files. Choose one import path per Asset to avoid duplicate findings.
#### Prerequisites
@@ -27,6 +29,20 @@ The connector authenticates as a Microsoft Entra ID **app registration** using t
2. Enter the **Directory (tenant) ID** in the **Tenant ID** field.
3. Enter the **Application (client) ID** in the **Client ID** field.
4. Enter the client secret value in the **Client Secret** field.
-5. Optionally, set a **Minimum Severity** to limit which findings are imported.
+5. Optionally, set **Device Groups** to a comma\-separated list of Defender RBAC device group names to import only those groups (see [Importing in phases with device groups](#importing-in-phases-with-device-groups)). Leave it blank to import every device group. Use `Unassigned` for devices that are not in any RBAC group.
+6. Optionally, set a **Minimum Severity** to limit which findings are imported.
Each Defender device group becomes a Record. Microsoft regenerates the vulnerability snapshot the connector reads roughly every 6 hours, and newly onboarded devices can take up to \~24 hours to produce their first vulnerability data — a brand\-new tenant will legitimately Sync zero findings until devices are onboarded and assessed. License activation itself can also take \~20 minutes or more to reach the API ("No active license found" errors during that window resolve on their own).
+
+#### Importing in phases with device groups
+
+A large tenant can hold thousands of devices, which may be more findings than you want to bring in at once. Because the connector organizes everything by Defender RBAC device group, you can onboard a few groups at a time and keep the imported finding count limited to the groups you choose. There are two ways to control which device groups import:
+
+* **Device Groups field (allowlist).** Set the **Device Groups** field on the connector to the group names you want. Only those groups are discovered and imported, and every other group is skipped. This is the simplest option when you already know which groups to bring in, and you can add more names later to onboard the next phase.
+* **Record mapping.** With the field left blank, the connector discovers every device group and creates a Record for each. Map only the Records you want and leave the rest unmapped. Only mapped Records sync findings, so unmapped groups never import.
+
+In both cases the org\-wide snapshot Microsoft provides is read in full on each Sync (the export API cannot filter by group on the server side), but findings are only imported for the groups you selected.
+
+#### Setting a minimum severity per device group
+
+The connector\-level **Minimum Severity** applies to every group. To use a different threshold for one device group, set a **severity override** on that group's Record after it has been discovered. The override applies only to that Record, so you can, for example, import everything from a production group while limiting a lab group to High and Critical.
diff --git a/docs/content/connectors/toolreference/qualys.md b/docs/content/connectors/toolreference/qualys.md
index 3728165269b..f1115fe8e07 100644
--- a/docs/content/connectors/toolreference/qualys.md
+++ b/docs/content/connectors/toolreference/qualys.md
@@ -16,7 +16,8 @@ A Qualys user account with **VMDR API access**, and your subscription's **API se
2. Enter the Qualys API username in the **Username** field.
3. Enter the Qualys API password in the **Secret** field.
4. Optionally, restrict discovery to part of your subscription with **Host Tags** (see below).
-5. Optionally, set a **Minimum Severity** to limit which findings are imported.
+5. Optionally, enable **Create endpoints from hosts** to attach each finding to its host as an endpoint (see below).
+6. Optionally, set a **Minimum Severity** to limit which findings are imported.
Each Qualys host becomes a Record. Detections Qualys has marked **Fixed** are excluded, so reimport closes remediated findings.
@@ -47,4 +48,16 @@ Notes:
**Testing the connection** ignores this field on purpose, so it still confirms your username and password even when the tag names are wrong.
+#### Create endpoints from hosts (optional)
+
+By default, findings imported by this connector are linked only to the mapped asset, with no per-host endpoint. On an asset that aggregates several Qualys hosts, that makes it hard to see which systems a finding affects.
+
+The optional **Create endpoints from hosts** toggle attaches each finding's Qualys host as an endpoint:
+
+* The endpoint host is the Qualys host's **DNS name**, or its **NetBIOS name** when there is no DNS name, or its **IP address** when there is neither — the same preference order the connector uses to name the Record.
+* When the detection reports a **port**, it is included, so `web01.example.com:443` and `web01.example.com:8443` remain distinct endpoints.
+* If the asset already has a matching endpoint, the finding is attached to it; otherwise the endpoint is created. No duplicate endpoints are created either way.
+
+The toggle is **off by default**, which keeps the connector's historical behavior: findings stay asset-only. It can be changed after the connection is created, and takes effect on the next Sync — existing open findings gain their endpoints then too, since a Sync reimports them.
+
**Changing the filter later:** hosts that a newly narrowed filter excludes are no longer discovered. Their existing Records then follow the normal lifecycle for assets the tool stops reporting: **mapped** Records are flagged `MISSING` on the next Sync, and unmapped `NEW` Records are removed. Findings already imported into DefectDojo are not deleted. The filter governs discovery only.
diff --git a/docs/content/federal_compliance/_index.md b/docs/content/federal_compliance/_index.md
index 271d7f7c655..841be55907a 100644
--- a/docs/content/federal_compliance/_index.md
+++ b/docs/content/federal_compliance/_index.md
@@ -50,5 +50,7 @@ purpose.
| [ConMon Snapshots](conmon_snapshots) | Monthly deliverables in FedRAMP Excel and OSCAL, and the optional OSCAL validation service |
| [Remediation Deadlines](remediation_slas) | The FedRAMP Rev 5 and FedRAMP VDR SLA presets |
| [Potential Agency Impact (PAIN) Ratings](pain_ratings) | Rating findings on FedRAMP's N-scale, and the Class C deadline matrix |
+| [Setting Up PAIN Ratings](pain_ratings_setup) | A step-by-step walkthrough: turn tiering on, assign a rating, and check the deadlines against the matrix |
| [CMMC Level 2 Assessments](cmmc_assessments) | Scoring a self-assessment against NIST 800-171 Rev 2 |
+| [CRA and DORA Evidence Packs](eu_evidence_packs) | Assessing an Asset against authored EU regulatory catalogs and exporting its evidence |
| [Control Coverage](control_coverage) | Which 800-53 controls your scanners test, and open weaknesses per control |
diff --git a/docs/content/federal_compliance/cmmc_assessments.md b/docs/content/federal_compliance/cmmc_assessments.md
index a52db98e446..37b187e9f39 100644
--- a/docs/content/federal_compliance/cmmc_assessments.md
+++ b/docs/content/federal_compliance/cmmc_assessments.md
@@ -1,7 +1,7 @@
---
title: "CMMC Level 2 Assessments"
description: "Score a self-assessment against NIST 800-171 Rev 2"
-weight: 6
+weight: 7
audience: pro
---
diff --git a/docs/content/federal_compliance/control_coverage.md b/docs/content/federal_compliance/control_coverage.md
index 1ec395f2413..c0be1d1a798 100644
--- a/docs/content/federal_compliance/control_coverage.md
+++ b/docs/content/federal_compliance/control_coverage.md
@@ -1,7 +1,7 @@
---
title: "Control Coverage"
description: "Which 800-53 controls your scanners test, and open weaknesses per control"
-weight: 7
+weight: 8
audience: pro
---
diff --git a/docs/content/federal_compliance/eu_evidence_packs.md b/docs/content/federal_compliance/eu_evidence_packs.md
new file mode 100644
index 00000000000..76680262435
--- /dev/null
+++ b/docs/content/federal_compliance/eu_evidence_packs.md
@@ -0,0 +1,93 @@
+---
+title: "CRA and DORA Evidence Packs"
+description: "Assess an Asset against authored EU regulatory catalogs and export its evidence"
+weight: 7
+audience: pro
+---
+
+DefectDojo Pro includes authored catalogs for vulnerability-related obligations in the Cyber
+Resilience Act (CRA) and Digital Operational Resilience Act (DORA). A regulatory assessment
+collects the operational facts DefectDojo already holds, gives an assessor space to document the
+remaining evidence, and produces a dated evidence pack.
+
+DefectDojo does not determine whether a regulation applies to an organization, product, or
+service. The catalogs and evidence states are aids to assessment. Confirm applicability,
+interpretation, and conclusions with qualified legal and compliance reviewers.
+
+## Enable EU evidence packs
+
+EU evidence packs require the **Compliance** feature and the beta **EU Evidence Packs** feature.
+An administrator can enable both from [Feature Flags](/admin/feature_flags/pro__feature_flags/).
+
+## Included catalogs
+
+The bundled catalogs contain short, authored paraphrases. Each obligation records its citation
+and links to the corresponding source on EUR-Lex.
+
+The CRA catalog covers Annex I Part II vulnerability handling, the Article 13 support period and
+component due diligence requirements, and the Article 14 vulnerability and incident reporting
+stages.
+
+The DORA catalog covers ICT asset identification, vulnerability and patch management under
+Commission Delegated Regulation (EU) 2024/1774, the testing types in DORA Article 25(1), and the
+Article 28(3) third-party register. The third-party register obligation starts as not applicable
+because the evidence pack does not manage that register.
+
+The catalog text summarizes assessment topics and does not replace the regulations.
+
+## Start and recompute an assessment
+
+Open an Asset's **Compliance** tab. The **Regulatory assessments** section lists existing
+assessments and offers one start button for each regulatory catalog. A new assessment covers the
+selected period and creates an evidence result for every obligation.
+
+Open **EU Evidence** to review the assessment. Select **Recompute Evidence** whenever operational
+data changes. DefectDojo refreshes the automated facts and the automated evidence state for each
+obligation.
+
+The assessment uses five evidence states: satisfied, partially satisfied, not satisfied, not
+applicable, and unknown. These states describe the evidence in DefectDojo. They are not legal
+conclusions.
+
+## Automated evidence
+
+DefectDojo computes evidence only where it has suitable operational facts.
+
+| Evidence source | Obligations it can support |
+| --- | --- |
+| SBOM dependency locations | CRA component and SBOM evidence; DORA third-party and open source library tracking |
+| SLA settings, finding history, and risk acceptances | CRA remediation; DORA patch priority, deadlines, remediation monitoring, and vulnerability records |
+| Tests and engagements in the assessment period | Regular security testing, vulnerability scanning, source code review, and penetration testing |
+| EPSS and KEV enrichment runs | Trustworthy vulnerability information sources |
+| Asset business criticality | ICT asset classification |
+| Published PSIRT advisories | Public disclosure of fixed vulnerabilities |
+
+Optional regulatory profiles, cadence monitoring, reporting cases, and advisory exports can add
+more precise facts when those features are installed. If an optional source is absent, the result
+stays available for manual assessment and explains which evidence is missing. Other obligations
+are manual by design.
+
+## Narratives, attachments, and overrides
+
+Open an obligation's **Evidence** view to inspect the computed facts, record an assessor narrative,
+and attach supporting files. Automated facts include the time at which they were computed.
+
+An assessor can override the effective evidence state after providing a reason. Recomputing does
+not replace that decision. DefectDojo retains the latest automated state beside the effective
+state so reviewers can see when they differ, along with who made the override and when.
+
+## Generate an evidence pack
+
+Select **Generate Evidence Pack** from the assessment. Generation freezes the assessment and its
+results at that point in time. Later edits do not change an existing snapshot.
+
+The pack contains two downloadable artifacts:
+
+* An Excel workbook with a cover sheet, one sheet for each obligation family, and a raw evidence
+ appendix. Family sheets list the obligation, citation, evidence state, evidence summary, and
+ assessor narrative.
+* An OSCAL 1.0.4 assessment-results JSON document. DefectDojo validates it against the vendored
+ NIST schema before making it available.
+
+Each artifact records its file size and SHA-256 digest. PDF output is deferred while the reporting
+module does not expose a reusable server-side HTML-to-PDF path for this report.
diff --git a/docs/content/federal_compliance/fda_cyber_device_pack.md b/docs/content/federal_compliance/fda_cyber_device_pack.md
new file mode 100644
index 00000000000..159e3e10bd1
--- /dev/null
+++ b/docs/content/federal_compliance/fda_cyber_device_pack.md
@@ -0,0 +1,137 @@
+---
+title: "FDA Cyber Device Evidence Pack"
+description: "Record a cyber device profile, track the section 524B lifecycle metrics, and export the evidence pack an assessor reviews"
+weight: 9
+audience: pro
+---
+
+Section 524B of the Federal Food, Drug, and Cosmetic Act asks the manufacturer of a cyber device
+for four things: a plan to monitor and address vulnerabilities after release, updates on a
+justified cycle with a faster route for the severe ones, a software bill of materials, and the
+processes around all of it. DefectDojo already holds much of the underlying record. These features
+add the few facts it cannot infer, work out where each obligation stands, and produce the workbook
+and bill of materials an assessor reviews.
+
+DefectDojo records and reports what the manufacturer supplies. It does not assess whether a
+software bill of materials is complete or accurate, and it does not determine whether a submission
+satisfies the FDA. Those are decisions for the manufacturer and its reviewers.
+
+The cyber device features are released behind a feature flag. An administrator turns them on per
+instance from the Feature Flags page before they are generally available.
+
+## The cyber device profile
+
+An Asset that is a cyber device carries a profile recording what the assessment needs to know
+about it:
+
+- Whether the Asset is a cyber device at all, which is what brings the rest into scope.
+- A device identifier, either the unique device identifier or an internal model code.
+- The submission stage, premarket or postmarket, so a reviewer knows which one this is.
+- The routine security update cycle in days, and the reasoning behind that interval.
+
+The cycle and its justification are recorded together on purpose. The statute asks for a cycle
+that is reasonably justified, so an interval with no reasoning attached is reported as a partial
+answer rather than a complete one.
+
+The profile also carries the security contact and the vulnerability disclosure policy link. These
+are the same two fields the EU regulatory profile uses, because they answer the same question for
+both regulators.
+
+## The seven elements per component
+
+Section 524B and the accompanying minimum elements guidance expect a bill of materials to answer
+seven things about each component. DefectDojo records all seven:
+
+| Element | Where it comes from |
+|---|---|
+| Asset location | The Asset the component was found on |
+| Component name | The imported bill of materials |
+| Version | The imported bill of materials |
+| Supplier | The imported document, or recorded by hand |
+| Support level | The imported document, or recorded by hand |
+| End of support date | The imported document, or recorded by hand |
+| Known vulnerabilities | The findings linked to that component |
+
+Unknown is a valid answer for the support facts and is reported as unknown. DefectDojo does not
+guess a support level or an end of support date. See
+[Working with SBOMs](../../asset_modelling/locations/pro__working_with_sboms) for how imports supply
+these and which value wins when more than one source has an opinion.
+
+## The three lifecycle metrics
+
+Three numbers describe how the manufacturer handles what it finds. Each is measured over the
+assessment period and can be read on its own or as part of the evidence pack.
+
+**How much of what was found got fixed.** The share of vulnerabilities identified in the period
+that were remediated, overall and by severity, with the ones still open listed.
+
+**How long a fix took.** The time from identifying a vulnerability to shipping the patch, reported
+as a mean and a median, overall and by severity, alongside how many are still open and how old
+they are.
+
+**How long the fix took to arrive.** Releasing a patch is not the same as deploying it. This
+measures the time from a release being available to it reaching the devices in the field, and
+names the releases that have no completion recorded and the ones with no release date, because a
+gap in the record is the thing a reviewer most needs to see.
+
+## The assessment
+
+The bundled catalog holds 13 controls across the four families the statute names: postmarket
+monitoring, updates and patches, bill of materials, and processes. Every control statement in the
+catalog is a paraphrase written for DefectDojo, alongside the statute section it refers to. The
+statute and guidance text is not reproduced. Read the source before relying on a wording here.
+
+Nine of the 13 are evidenced from data DefectDojo already holds:
+
+| Control | Read from |
+|---|---|
+| Coordinated vulnerability disclosure | The security contact and the disclosure policy link on the profile |
+| A justified update cycle | The cycle and rationale on the profile |
+| Out of cycle updates for critical vulnerabilities | Critical findings measured against the recorded cycle |
+| Updates reaching the field | The field implementation metric |
+| A bill of materials covering every kind of component | The component inventory and when it was last imported |
+| Machine readable and carrying the minimum elements | The components available to export and how many name a supplier |
+| Support level and end of support per component | The share of components with a known support level |
+| Known vulnerabilities per component | The findings linked to components |
+| Lifecycle metrics tracked and reviewed | The three metrics above |
+
+The remaining four are the manufacturer's own process and paperwork: the monitoring plan, the
+watch on third party and open source components, lifecycle risk management, and security testing.
+DefectDojo holds no record of any of them, so each is declared manual with a note naming the
+evidence to attach.
+
+Two behaviours are worth knowing before reading a result. A period with no critical findings
+reports the out of cycle control as not applicable rather than as a pass, because nothing was
+asked of the process. The support coverage control fails when too much of the inventory has an
+unknown support level, and names the components responsible so somebody can go and find out; the
+threshold is 90 percent of components.
+
+An Asset with no cyber device profile does not fail. Every automated control reports that what it
+reads is absent and says what to record, because a device nobody has configured yet is not a
+device that is out of compliance.
+
+## The evidence pack
+
+Generating a pack produces three files. Each is recorded with its SHA-256 and its size, and the
+same assessment always produces the same bytes, so the hash attests to the evidence rather than to
+one particular download.
+
+- An OSCAL assessment results document, validated against its schema.
+- The workbook, which has no validator and is recorded as not validated rather than claiming a
+ check that never ran.
+- The bill of materials itself, exported as CycloneDX, so the pack ships the document rather than
+ a description of it. It is recorded as not validated for the same reason.
+
+On top of the obligation sheets every regulatory pack carries, the cyber device workbook adds
+three:
+
+- **Component inventory**, one row per component with all seven elements and where each support
+ fact came from.
+- **Lifecycle metrics**, the three metrics above, overall and by severity.
+- **Release history**, every release in the period with when it shipped, when it reached the
+ field, and how long that took, including the releases that cannot yet be measured.
+
+## Related pages
+
+[CRA and DORA Evidence Packs](../eu_evidence_packs) share the assessment screens and the export
+pipeline described here.
diff --git a/docs/content/federal_compliance/images/18-asset-sla-configuration.png b/docs/content/federal_compliance/images/18-asset-sla-configuration.png
new file mode 100644
index 00000000000..f726d2538e7
Binary files /dev/null and b/docs/content/federal_compliance/images/18-asset-sla-configuration.png differ
diff --git a/docs/content/federal_compliance/images/19-pain-tiering-matrix.png b/docs/content/federal_compliance/images/19-pain-tiering-matrix.png
new file mode 100644
index 00000000000..81e1fe88f2b
Binary files /dev/null and b/docs/content/federal_compliance/images/19-pain-tiering-matrix.png differ
diff --git a/docs/content/federal_compliance/images/20-deadline-flat-vdr-tier.png b/docs/content/federal_compliance/images/20-deadline-flat-vdr-tier.png
new file mode 100644
index 00000000000..a008593b48d
Binary files /dev/null and b/docs/content/federal_compliance/images/20-deadline-flat-vdr-tier.png differ
diff --git a/docs/content/federal_compliance/images/21-deadline-unrated-base-sla.png b/docs/content/federal_compliance/images/21-deadline-unrated-base-sla.png
new file mode 100644
index 00000000000..0a3777b419b
Binary files /dev/null and b/docs/content/federal_compliance/images/21-deadline-unrated-base-sla.png differ
diff --git a/docs/content/federal_compliance/images/22-deadline-rated-n5.png b/docs/content/federal_compliance/images/22-deadline-rated-n5.png
new file mode 100644
index 00000000000..d4937374a15
Binary files /dev/null and b/docs/content/federal_compliance/images/22-deadline-rated-n5.png differ
diff --git a/docs/content/federal_compliance/images/23-adopted-template-conditions.png b/docs/content/federal_compliance/images/23-adopted-template-conditions.png
new file mode 100644
index 00000000000..17fe9630229
Binary files /dev/null and b/docs/content/federal_compliance/images/23-adopted-template-conditions.png differ
diff --git a/docs/content/federal_compliance/pain_ratings.md b/docs/content/federal_compliance/pain_ratings.md
index 4c2997f3b4a..b6ca763681a 100644
--- a/docs/content/federal_compliance/pain_ratings.md
+++ b/docs/content/federal_compliance/pain_ratings.md
@@ -11,7 +11,8 @@ from the internet, and how much damage its exploitation would do to the agencies
That third factor is the **Potential Agency Impact N-rating**, or PAIN.
This page covers the rating, how it changes a deadline, and how to assign ratings at scale. For the
-SLA presets that carry the matrix, see [Remediation Deadlines](../remediation_slas).
+SLA presets that carry the matrix, see [Remediation Deadlines](../remediation_slas). To switch it on
+and check the result step by step, see [Setting Up PAIN Ratings](../pain_ratings_setup).
## The N-rating scale
@@ -121,10 +122,10 @@ two-day cell. Nothing else about the finding changed.
## Rating findings with the Rules Engine
-Ratings are assigned through **Rules Engine 2.0**. The **Set Potential Agency Impact (PAIN)** action
+Ratings are assigned through **Triage Engine**. The **Set Potential Agency Impact (PAIN)** action
writes a rating to every finding that reaches it.
-
+
The rating selector offers FedRAMP's own customer-effect wording rather than bare numbers, so
whoever builds the rule sees the judgment being made.
@@ -140,7 +141,7 @@ The action behaves the way a compliance workflow needs it to:
so a rule-set rating and a hand-set one produce the same date.
* A rating outside 1 to 5 is rejected.
* Every run records a per-finding trace of the change, from and to — the audit trail for each impact
- decision. See [Runs](/automation/rules_engine_2/runs/).
+ decision. See [Runs](/automation/triage_engine/runs/).
`finding.pain_rating` is also available as a condition in any filter node, which is what makes
escalation rules such as "above N3 and internet-reachable" possible.
@@ -148,7 +149,7 @@ escalation rules such as "above N3 and internet-reachable" possible.
The rule below produced the deadline change above: a Manual Run trigger, an If / Filter node
selecting the finding, and **Set Potential Agency Impact (PAIN)** set to N5, switched to Live.
-
+
The run trace records each node's input and output counts. This run swept 10,008 findings, one
matched the filter, and one rating was written.
@@ -161,14 +162,14 @@ Two templates covering the PAIN workflow ship in the template gallery, alongside
scan-cadence watchdogs. Adopting a template creates a new rule of your own, disabled and in simulate
mode, so nothing runs until you configure and enable it.
-
+
| Template | What it does |
| --- | --- |
| **FedRAMP — route unrated findings for impact review** | A scheduled sweep for active findings that carry exploit evidence — weaponized or worse — and no PAIN rating, raising an alert to the reviewers who own impact decisions. It surfaces the queue rather than assigning a rating, which is what FedRAMP's provider-judgment requirement asks for. |
| **FedRAMP — escalate reportable-incident candidates** | A scheduled sweep for active findings rated above N3 that are likely exploitable and sit on exposed assets, raising a ticket for each. Class C treats such a finding as a FedRAMP Reportable Incident until it is mitigated to N3 or below. |
-See [Building Rules](/automation/rules_engine_2/building_rules/) for how a template is adopted.
+See [Building Rules](/automation/triage_engine/building_rules/) for how a template is adopted.
## Where the deadline shows up
diff --git a/docs/content/federal_compliance/pain_ratings_setup.md b/docs/content/federal_compliance/pain_ratings_setup.md
new file mode 100644
index 00000000000..9a0adf5dbb2
--- /dev/null
+++ b/docs/content/federal_compliance/pain_ratings_setup.md
@@ -0,0 +1,341 @@
+---
+title: "Setting Up PAIN Ratings"
+description: "Turn on PAIN tiering, assign a first rating, and verify the deadlines the Class C matrix predicts"
+weight: 6
+audience: pro
+---
+
+[Potential Agency Impact (PAIN) Ratings](../pain_ratings) explains what the rating is and how a
+deadline is derived from it. This page is the procedure: the order to do things in, what to check at
+each step, and what the deadline should read when you get there.
+
+Work through it once, on one Asset, before you enable PAIN tiering across an authorization boundary.
+It takes about 45 minutes and ends with a remediation deadline you can trace to a single cell of
+FedRAMP's published table.
+
+Throughout, **D** is a finding's discovery date. Expected results are written as `D + n days`, so
+they hold whatever day you run this.
+
+## Before you start
+
+| Requirement | Why | How to check |
+| --- | --- | --- |
+| **DefectDojo Pro 3.3.100 or later** | Earlier versions carry the database field but offer no way to switch PAIN tiering on | **Use PAIN Ratings for VDR Deadlines** appears in the **FedRAMP VDR & PAIN Tiering** section of an SLA configuration |
+| Feature flag `compliance` | The Compliance tab, the POA&M ledger and the FedRAMP SLA presets | [Feature Flags](/admin/feature_flags/pro__feature_flags/) |
+| Feature flag `rules_engine_v2` | Ratings are assigned by a rule; without it there is no **Set Potential Agency Impact (PAIN)** node | [Feature Flags](/admin/feature_flags/pro__feature_flags/) |
+| Feature flag `threat_intel` | `exploit_maturity`, which the shipped FedRAMP rule templates filter on | [Feature Flags](/admin/feature_flags/pro__feature_flags/) |
+| Background task processing | Every SLA change recalculates asynchronously | On a self-hosted install, confirm the worker is running with your administrator |
+| The **FedRAMP VDR** SLA configuration | It is the only preset carrying the tiers and the matrix | **Configuration > Service Level Agreements** |
+| Permission to edit SLA configurations | Superuser, or the matching [configuration permission](/admin/user_management/user_permission_chart/#configuration-permission-chart) | — |
+
+Without a background worker, every step here saves successfully and **no deadline ever moves**,
+which looks exactly like the feature not working.
+
+### Read this before you turn anything on
+
+**Enabling PAIN tiering makes deadlines longer before it makes them shorter.**
+
+PAIN tiering *replaces* the three flat VDR tiers rather than combining with them. A finding that has
+no rating matches no cell of the matrix, so it falls back to its base severity SLA. On the FedRAMP
+VDR preset, a Critical finding that was sitting on the 4-day Urgent tier moves to 30 days the moment
+you tick the box, and stays there until somebody rates it.
+
+That is correct behaviour, and it is the single most common reason people conclude the feature is
+broken. It is also why the walkthrough below has you record the deadline at three points rather than
+two.
+
+## Choose a finding to watch
+
+Which column of the matrix a finding lands in depends on whether DefectDojo considers it **likely
+exploitable**, which is read from two fields:
+
+* `known_exploited` — is it in the CISA KEV catalog?
+* `epss_score` — is EPSS at or above the configuration's threshold, `0.1` by default?
+
+For the clearest demonstration, pick a finding in the tightest column: **Critical severity,
+KEV-listed, and tagged `internet-reachable`**. A Log4Shell finding (CVE-2021-44228) from any scan
+import is the canonical example.
+
+In normal operation both fields arrive from your scanners or from Finding Enrichment rather than
+being entered by hand. If your imported findings have both empty, turn enrichment on at **Settings >
+Finding Enrichment Settings** and enable **KEV Lookup** and **EPSS Lookup** — on DefectDojo Cloud
+these are already on. With no lookup source configured, enrichment silently enriches nothing.
+
+Confirm the finding you picked actually carries them before predicting a deadline from it. A finding
+with neither is **not likely exploitable**, so it lands in the widest column of the matrix: the
+mechanism still works, but the only movement you will see is 30 days to 16 at N5, which is a much
+weaker check. On a test instance an administrator can set them directly:
+
+```bash
+curl -X PATCH "$DD_URL/api/v2/findings//" \
+ -H "Authorization: Token $DD_TOKEN" -H "Content-Type: application/json" \
+ -d '{"known_exploited": true, "epss_score": 0.9744, "epss_percentile": 0.9997}'
+```
+
+The deadline recalculates on save. Note the finding's **Finding ID** from its URL and its **Date
+Discovered** — that date is **D**.
+
+## Step 1 — Put the Asset on FedRAMP VDR
+
+Open the Asset, choose **Edit**, and set **SLA Configuration** to **FedRAMP VDR**.
+
+
+
+Only **FedRAMP VDR** carries the exploitability tiers and the PAIN matrix. **FedRAMP Rev 5** gives
+you the 30/90/180 base windows and the CISA KEV cap, but no tiering at all.
+
+Changing an Asset's SLA configuration recalculates every finding on it, and the Asset's SLA cannot
+be changed again while that runs — see
+[SLA Recalculation](/asset_modelling/pro_hierarchy/priority_sla/#sla-recalculation).
+
+Then open **Configuration > Service Level Agreements**, edit **FedRAMP VDR**, and confirm it reads:
+
+| Field | Expected |
+| --- | --- |
+| Critical / High / Medium / Low Finding Days | 30 / 30 / 90 / 180 |
+| Enforce … Finding Days (all four) | ticked |
+| Cap SLA by CISA KEV Due Date | ticked |
+| **Enable VDR Deadlines** | **ticked** |
+| VDR Urgent Days | 4 |
+| VDR Credibly-Exploitable Days | 14 |
+| VDR Internet-Reachable Days | 30 |
+| VDR EPSS Threshold | 0.1 |
+| VDR Reachability Tag | `internet-reachable` |
+| **Use PAIN Ratings for VDR Deadlines** | **unticked**, for now |
+
+**Enable VDR Deadlines must be ticked.** The matrix is applied *inside* the VDR calculation, so with
+VDR off no cell is ever consulted and the PAIN checkbox does nothing at all.
+
+If this configuration is already assigned to Assets outside the boundary you are working in, copy it
+first and point only your test Asset at the copy. Enabling PAIN tiering re-dates every finding on
+every Asset using the configuration.
+
+## Step 2 — Record the deadline before tiering
+
+Open your chosen finding and read the **SLA** row in the Details panel.
+
+| Expected | Why |
+| --- | --- |
+| **D + 4 days** | The base SLA for a Critical is 30 days, but the finding is likely exploitable *and* internet-reachable, so the flat VDR **Urgent** tier of 4 days applies. VDR only ever tightens, so 4 wins. |
+
+
+
+The panel above was captured the day after discovery, so **SLA** reads the days remaining rather than
+the window itself.
+
+| If you see | Cause |
+| --- | --- |
+| **D + 30** | The finding is not seen as exploitable or reachable. Check that Known Exploited is ticked, or EPSS is above the threshold, and that the tag reads exactly `internet-reachable` |
+| Some other number | The Asset is still on a different SLA configuration. Repeat Step 1 |
+
+## Step 3 — Turn on PAIN tiering
+
+Edit **FedRAMP VDR** again, scroll to **FedRAMP VDR & PAIN Tiering**, and tick **Use PAIN Ratings for
+VDR Deadlines**. The twelve-cell matrix appears immediately, pre-seeded with FedRAMP's published
+Class C values.
+
+
+
+| PAIN Rating | Exploitable + Internet-Reachable | Exploitable Only | Not Likely Exploitable |
+| --- | --- | --- | --- |
+| PAIN-5 | 2 | 4 | 16 |
+| PAIN-4 | 4 | 8 | 64 |
+| PAIN-3 | 16 | 32 | 128 |
+| PAIN-2 | 48 | 128 | 192 |
+
+There is deliberately no PAIN-1 row: FedRAMP's table starts at N2, so an N1 finding carries no VDR
+deadline and keeps its base window.
+
+Submit. This queues a recalculation across every finding on every Asset using the configuration —
+seconds on one Asset, proportionally longer on a large boundary. **While that sweep runs the
+configuration is locked, and further saves are silently reverted rather than rejected.** If a matrix
+cell snaps back to its old value, that is why: wait for the sweep to finish and edit it again.
+
+When it completes, reload the finding.
+
+| Expected | Why |
+| --- | --- |
+| **D + 30 days** | The finding has no PAIN rating, so no matrix cell applies and it falls back to the base severity SLA |
+
+
+
+The deadline has moved **outwards**, from 4 days to 30. This is the step described at the top of the
+page. Nothing is wrong — continue.
+
+## Step 4 — Assign a rating
+
+PAIN is a judgment about the effect exploitation would have on your agency customers. DefectDojo
+never derives one. Ratings are assigned with a [Rules Engine 2.0](/automation/rules_engine_2/) rule.
+
+Go to **Rules Engine 2.0 > All Rules**, choose **New Rule**, and wire three nodes left to right:
+
+| Order | Palette section | Node | Configuration |
+| --- | --- | --- | --- |
+| 1 | Triggers | **Manual Run** | Sweep Over: `Findings`. Leave scope empty. |
+| 2 | Logic | **If / Filter** | One condition: `finding.id` `equals` your Finding ID. Match: `All of Them`. |
+| 3 | Findings | **Set Potential Agency Impact (PAIN)** | `N5 — debilitating effect on more than one agency` |
+
+Connect **Manual Run** to **If / Filter**, then drag from the filter's **true** output to the PAIN
+node. Filtering on a single `finding.id` is the most legible thing to put on screen for a first run;
+a production rule filters on severity, exploit evidence and `finding.pain_rating` `is not set`
+instead.
+
+
+
+**Simulate mode will not protect your findings.** Simulate holds back outbound sends only — alerts,
+tickets, messages and webhooks. Every Finding edit in a graph happens for real in simulate mode, and
+that includes this one. See [Mode: Simulate or Live](/automation/rules_engine_2/about/#mode-simulate-or-live).
+
+That matters more here than on most nodes, because **a PAIN rating cannot be cleared**. The action
+offers only N1 to N5, and `pain_rating` is not writable through the finding API, so there is no
+supported way to return a finding to unrated. Treat any rule containing **Set Potential Agency Impact
+(PAIN)** as live from the moment you press **Run Now**, and check the filter value before you do.
+
+**Preview** is the safe check for a broad rule — it runs the real engine inside a transaction it then
+rolls back, writing nothing. It will not help you here, though: preview caps how many items it looks
+at, so a rule targeting one specific finding usually comes back empty. For a single-finding rule,
+click **Validate** to confirm the graph is well-formed, then re-open the If / Filter node and read
+the Finding ID back.
+
+Set the mode to **Live**, toggle **Enabled** on, **Save**, then **Run Now**. A rule must be both
+saved and enabled first: **Run Now** is greyed out while there are unsaved changes, and a disabled
+rule records no run.
+
+Open **Rules Engine 2.0 > Runs** and expand the newest run:
+
+
+
+The trace records each node's input and output counts, and **What changed** names the finding that
+was updated. Reload the finding:
+
+| Expected | Why |
+| --- | --- |
+| **D + 2 days** | Rated N5, still exploitable and reachable — the matrix cell at N5 × (LEV + IRV) |
+| Date Discovered still **D** | Unchanged. Only the rating moved |
+
+
+
+## Step 5 — Walk the matrix
+
+Optional, and worth doing once. Edit the rule's PAIN node, change the rating, **Save**, **Run Now**,
+and reload the finding.
+
+| Rating | Cell | Expected deadline | What it shows |
+| --- | --- | --- | --- |
+| N5 | 2 days | **D + 2** | The tightest tier |
+| N4 | 4 days | **D + 4** | The same window the rating-agnostic Urgent tier gave |
+| N3 | 16 days | **D + 16** | The middle of the table |
+| N2 | 48 days | **D + 30** | The base SLA is shorter, so it wins |
+
+**The N2 row is the one to show an assessor.** Its cell is 48 days, but the finding still gets 30,
+because VDR and PAIN tiering can only ever tighten a deadline, never extend one.
+
+Re-running at a rating the finding already holds reports nothing affected. That is deliberate: it
+stops a scheduled rule re-stamping **PAIN Evaluated** on a finding whose impact has not been
+reassessed.
+
+## What this proves
+
+One finding, one discovery date, three deadlines — each the product of a configuration change and
+nothing else.
+
+| Stage | Deadline | Set by |
+| --- | --- | --- |
+| FedRAMP VDR assigned, PAIN tiering off | **D + 4** | The flat VDR Urgent tier, which beats the 30-day base |
+| PAIN tiering on, finding unrated | **D + 30** | The base severity SLA — no matrix cell applies |
+| Rated N5 | **D + 2** | The matrix cell at N5 × (LEV + IRV) |
+
+The severity never changed and no date was typed in by hand. Each deadline was derived from the
+finding's exploitability, its reachability, and the impact rating a person assigned.
+
+## Moving to a production workflow
+
+A rule filtering on one `finding.id` proves the mechanism. Running a boundary needs two more things:
+a queue of findings waiting for an impact decision, and an escalation path for the ratings that
+warrant one. Both ship as templates — see
+[FedRAMP rule templates](../pain_ratings/#fedramp-rule-templates) for what each one does, and
+[Building Rules](/automation/rules_engine_2/building_rules/) for how adoption works.
+
+An adopted template arrives disabled and in simulate mode. Before it will do anything:
+
+| Setting | What to do |
+| --- | --- |
+| **Schedule** | Select the **On a Schedule** trigger and set a cadence. A scheduled rule with no schedule never runs, and this is the most common reason an adopted template appears dead |
+| **Recipients** | On the alert node, name the users who own impact decisions. Left empty it alerts administrators |
+| **Scope** | On the trigger, narrow to the Assets inside your authorization boundary. Left empty, the rule considers every finding its owner can see |
+| **Enabled** | Toggle it on and save |
+
+### Why a newly adopted template is quiet at first
+
+Both PAIN templates filter on `finding.exploit_maturity`, and that field is worth understanding
+before you conclude the rule is broken.
+
+| Condition | Source |
+| --- | --- |
+| `finding.active` `equals` `true` | The finding's own status |
+| `finding.pain_rating` `is not set` | Unrated — what the rule is looking for |
+| `finding.exploit_maturity` `>=` `Weaponized` | Threat intelligence, not the finding record |
+
+**`exploit_maturity` is not `known_exploited`.** It is derived from DefectDojo's threat intelligence
+by matching a finding's CVEs, and written onto findings by a scheduled backfill. It is read-only
+through the API, so nothing you set on a finding populates it.
+
+The consequence is that **findings imported today will not match these templates today**, even when
+their CVEs, KEV flags and EPSS scores are all correct — only the backfill has not reached them yet.
+Configure the rule, let it sit, and check the runs over the following days.
+
+You can watch that coverage arrive rather than guessing at it. On the findings list, add the
+**Exploit Maturity** column, or filter on it, to see which findings the backfill has reached. Once
+the findings you care about show *Weaponized* or higher, the template has something to match.
+
+
+
+One display quirk to expect on an adopted template: the value box on the `finding.active` condition
+renders empty, because the template stores that value as text and the dropdown offers booleans. The
+comparison is type-tolerant and the rule evaluates correctly either way, so you can leave it or
+select `true`.
+
+## Rate before the first POA&M sync
+
+Each POA&M item takes its **Scheduled Completion Date** from the evidencing finding's enforced
+deadline *at the moment the item is created*, and keeps that date afterwards. This is deliberate — a
+commitment an assessor has already read should not silently move — but it means that if the ledger
+was synced before you started rating, the Compliance tab still shows the pre-PAIN dates and it will
+look as though nothing happened.
+
+Rate your findings before the first sync. If items already exist, delete them and re-sync from the
+Asset's **Compliance** tab. See [The POA&M Ledger](../poam_ledger).
+
+## Troubleshooting
+
+| Symptom | Cause | Fix |
+| --- | --- | --- |
+| No **Use PAIN Ratings for VDR Deadlines** checkbox | Version earlier than 3.3.100 | Upgrade |
+| Ticking the box changes nothing | **Enable VDR Deadlines** is off | Tick it — the matrix is applied inside the VDR calculation |
+| No deadline moves after submitting | Background task processing is not running | Check with your administrator |
+| A matrix cell snaps back after editing | The recalculation sweep is still running and the configuration is locked | Wait for it to finish, then edit again |
+| The deadline got *longer* after enabling PAIN | Expected — the finding is unrated | Assign a rating (Step 4) |
+| Baseline is D + 30 instead of D + 4 | The finding is not KEV-listed, EPSS is below threshold, or the tag is missing or misspelled | Check Known Exploited, EPSS, and that the tag matches the configuration's reachability tag exactly |
+| Known Exploited and EPSS empty on imported findings | No enrichment lookup sources configured | Settings > Finding Enrichment Settings |
+| An adopted template matches nothing | `exploit_maturity` has not been backfilled onto those findings | Expected on recent imports — give the backfill time |
+| An adopted template never runs at all | It has no schedule, or it is disabled | Both are required |
+| A rule reports nothing affected | The finding already holds that rating | Expected — choose a different rating |
+| **Run Now** does nothing and no run appears | The rule is disabled | Enable it, save, then run |
+| A simulate run rated the finding anyway | Simulate holds back outbound sends only, not Finding edits | Expected — treat any rule with a PAIN node as live |
+| A rated finding cannot be returned to unrated | By design | Nothing clears a rating; re-run at a different one |
+| The POA&M date did not change | It was frozen when the item was created | Delete the items and re-sync after rating |
+
+## What is not surfaced today
+
+So nobody spends time hunting for these:
+
+* **The rating is not displayed on the finding.** There is no Details row, table column or filter for
+ it. Its visible effect is the deadline; its audit trail is the rule run history.
+* **`pain_rating` is not part of the finding REST API,** so it cannot be read back or exported
+ through `/api/v2/findings/`. It *is* available as `finding.pain_rating` in Rules Engine filter
+ conditions.
+* **`exploit_maturity` is likewise absent from the finding REST API,** though unlike the rating it is
+ visible in the product: add the **Exploit Maturity** column to the findings list, or filter on it,
+ to see which findings the backfill has reached.
+
+None of these affect whether deadlines are computed correctly, which is what this page checks.
diff --git a/docs/content/federal_compliance/pci_evidence_packs.md b/docs/content/federal_compliance/pci_evidence_packs.md
new file mode 100644
index 00000000000..88d40c358d3
--- /dev/null
+++ b/docs/content/federal_compliance/pci_evidence_packs.md
@@ -0,0 +1,157 @@
+---
+title: "PCI DSS Evidence Packs"
+description: "Assess a cardholder data environment against the PCI DSS vulnerability management requirements and export the workbook an assessor reviews"
+weight: 9
+audience: pro
+---
+
+DefectDojo Pro includes an authored catalog for the PCI DSS v4.0.1 requirements that a
+vulnerability management programme answers. A PCI DSS assessment collects the operational facts
+DefectDojo already holds, gives an assessor space to record the rest, and produces a dated
+workbook in the wording a Report on Compliance uses.
+
+DefectDojo does not determine compliance. It reports what the recorded evidence shows. The
+assessor decides what is in place, and a Qualified Security Assessor decides what a Report on
+Compliance says. Nothing on these screens is an assessment finding on its own.
+
+## What the catalog covers, and what it is
+
+The catalog holds 30 controls drawn from three requirements:
+
+- Requirement 6, the secure development and patching obligations that bear on vulnerability
+ management, including the inventory of components, the remediation window for known
+ vulnerabilities, and the assessment of public facing web applications.
+- Requirement 11, the testing obligations: quarterly internal scans, quarterly ASV scans, the
+ rescans that follow, scanning after a significant change, penetration testing, and segmentation
+ testing.
+- Requirement 12, the programme obligations that the testing requirements point at: the targeted
+ risk analysis behind a self chosen frequency, and the confirmation of PCI DSS scope.
+
+PCI DSS is copyrighted by the PCI Security Standards Council. The catalog does not reproduce the
+standard. Every requirement statement in it is a paraphrase written for DefectDojo, alongside the
+requirement number so the standard itself can be cited. Read the requirement in the standard
+before relying on a wording here.
+
+Several requirements let an entity choose its own frequency. The catalog records which ones, and
+those are the requirements that pull Requirement 12.3.1 into the assessment: a self chosen
+frequency has to be justified by a targeted risk analysis and reviewed every twelve months.
+
+Three controls apply only to a service provider. Whether this instance is assessed as one is an
+instance wide setting, and it also halves two cadences, segmentation testing and scope
+confirmation, from twelve months to six.
+
+## Choosing the cardholder data environment
+
+A PCI DSS assessment is rarely an assessment of one system. When you start an assessment you
+choose what it covers:
+
+- A single Asset, which behaves exactly as every other regulatory assessment always has.
+- An Organization, which covers every Asset in it.
+- A chosen set of Assets, for a cardholder data environment that does not line up with one
+ Organization.
+
+For a scope wider than one Asset, each requirement is answered for every Asset in the scope and
+the weakest answer decides the result. An obligation is not satisfied for a cardholder data
+environment while one system in it fails. The per Asset answers are kept in the evidence, so an
+assessor can see which one, and the workbook lists them on the scope sheet.
+
+Who can read an assessment follows its scope in both directions. An assessment over a set exposes
+every Asset in it, so holding one of those Assets is not enough to open it. A user who can see
+every Asset in the scope can.
+
+Assessments that existed before scopes widened are unchanged. They cover the Asset they always
+covered.
+
+## What DefectDojo evidences by itself
+
+These requirements read data DefectDojo already holds. Everything else in the catalog is left to
+the assessor with a note saying why.
+
+| Requirement | Read from |
+|---|---|
+| 6.3.1 | How fresh the vulnerability enrichment data is |
+| 6.3.2 | The component inventory built from imported SBOM and dependency data |
+| 6.3.3 | The SLA configuration and the findings measured against it |
+| 6.4.1 | Tests recorded against the Asset with the web application assessment role |
+| 11.3.1, 11.3.1.2, 11.3.1.3 | The quarterly scan evidence grid |
+| 11.3.2, 11.3.2.1 | The recorded ASV scan results |
+| 11.3.1.1, 12.3.1 | Approved targeted risk analyses and their review dates |
+| 11.4.2, 11.4.3, 11.4.4 | Penetration testing engagements and their retests |
+| 11.4.5, 11.4.6 | Segmentation testing engagements, on the cadence that applies |
+| 12.5.1, 12.5.2, 12.5.2.1 | The PCI DSS scope recorded against the Asset and when it was last confirmed |
+
+Two behaviours are worth knowing before reading a result:
+
+A quarter that has not closed yet is reported but not counted. An assessment run in the second
+month of a quarter would otherwise report a failure for work that is not yet due. The quarter
+still appears on the scan sheet, marked as still running.
+
+Requirement 6.3.3 reads the SLA configuration rather than a separate threshold, so the window it
+measures against is the one configured for the Asset. The workbook states where the SLA clock
+starts, because PCI DSS counts a patching window from the release of the patch rather than from
+the day a scanner noticed.
+
+Requirements DefectDojo cannot evidence are listed in the assessment as manual, each with the
+reason. A change control process, a documented inventory procedure and an assessor's judgement
+about segmentation are not things a scanner reports.
+
+## How a result is worded
+
+The assessment screens use the vocabulary shared by every regulatory catalog in DefectDojo:
+satisfied, partially satisfied, not satisfied, not applicable and unknown. A Report on Compliance
+uses different words, so the PCI DSS workbook translates them. The translation happens in the
+workbook only. No other framework's assessment is affected.
+
+| In DefectDojo | In the workbook |
+|---|---|
+| Satisfied | In place |
+| Satisfied, with an assessor override recorded | In place with compensating control |
+| Partially satisfied | Not in place |
+| Not satisfied | Not in place |
+| Not applicable | Not applicable |
+| Unknown | Not tested |
+
+Partially satisfied becomes not in place deliberately. PCI DSS has no partial credit: a
+requirement is in place or it is not, and a softer word would overstate a half met requirement to
+an assessor. The DefectDojo status is kept in its own column beside the translation, so nothing
+is lost.
+
+In place with compensating control needs checking every time it appears. DefectDojo cannot tell a
+compensating control from any other reason an assessor overrode a result, so an override that
+lands on satisfied is reported in the column PCI DSS reserves for that case, and the reason is
+printed on its own sheet. If the override was not a compensating control, correct it there.
+
+## What is in the workbook
+
+Generating an evidence pack produces two files, as it does for the other catalogs: an OSCAL
+assessment results document and a workbook. Both carry a SHA-256 recorded against the pack, and
+the same assessment always produces the same bytes, so the hash attests to the evidence rather
+than to one particular download. The OSCAL document is validated against its schema. The workbook
+has no validator and is recorded as not validated rather than claiming a check that never ran.
+
+The PCI DSS workbook has eight sheets:
+
+- **Cover**, the scope, catalog, period, a count of requirements under each Report on Compliance
+ label, and the notes explaining how to read the rest.
+- **Scope inventory**, one row per Asset in scope, with the PCI DSS scope recorded against it,
+ when that scope was last confirmed, and the confirmation window that applies.
+- **Quarterly scans**, one row per quarter per check, with the window, whether the quarter has
+ closed, and what the evidence showed.
+- **Remediation timeliness**, the SLA position per Asset, including where the SLA clock starts,
+ what is past its deadline, and the mean time to remediate by severity.
+- **Penetration tests**, the Requirement 11.4 checks with the requirement number each one
+ answered and the engagements behind it.
+- **Targeted risk analyses**, each approved analysis, the requirement it justifies, its review
+ date and whether it is in date.
+- **Compensating controls**, every result an assessor overrode, with the reason recorded.
+- **Obligation results**, every requirement in the catalog with both status columns, the
+ narrative, the attachments and the gathered evidence.
+
+Text in the workbook is written as text rather than as a formula, so a narrative that begins with
+an equals sign is not executed by a spreadsheet application when the assessor opens it.
+
+## Related pages
+
+[CRA and DORA Evidence Packs](../eu_evidence_packs) share the assessment screens and the export
+pipeline this page describes. The PCI DSS Scan and ASV Evidence page covers recording the
+Requirement 11 scan evidence that this assessment reads.
diff --git a/docs/content/federal_compliance/remediation_slas.md b/docs/content/federal_compliance/remediation_slas.md
index 3079d13d955..da3b66d7809 100644
--- a/docs/content/federal_compliance/remediation_slas.md
+++ b/docs/content/federal_compliance/remediation_slas.md
@@ -68,24 +68,25 @@ holding a Class B or Class D certification change the numbers, not the shape.
### Rating your findings
-PAIN is set per finding, on the finding itself. It is deliberately a person's judgment rather than
-something computed from scanner output: FedRAMP asks the provider to estimate the effect exploitation
-would have on the agencies using the service, and explicitly declines to prescribe a method for
-arriving at that. A Triage Engine rule can propose a rating from evidence and route the finding for
-review — see the **Set Potential Agency Impact** node — but the confirmation is yours to make and
-defend.
-
-Two consequences worth knowing before you turn this on:
-
-* **A finding with no rating keeps its base deadline.** Every finding that exists before you start
- rating is unrated, so nothing is re-dated the moment you enable this. Deadlines tighten as you rate.
+PAIN is held per finding, and it is deliberately a person's judgment rather than something computed
+from scanner output: FedRAMP asks the provider to estimate the effect exploitation would have on the
+agencies using the service, and explicitly declines to prescribe a method for arriving at that.
+DefectDojo never derives a rating. Ratings are written by a Triage Engine rule using the **Set
+Potential Agency Impact** node, which is what makes the decision reviewable and auditable — there is
+no rating field on the finding form.
+
+Three consequences worth knowing before you turn this on:
+
+* **An unrated finding matches no cell, so it falls back to its base deadline.** That is not always
+ the same date it had before. Enabling PAIN deadlines **replaces** the three tiers rather than
+ combining with them, so a finding that was sitting on the 4-day tier moves *out* to its base window
+ until somebody rates it. Deadlines then tighten as you rate.
* **N1 has no row, on purpose.** FedRAMP's table starts at N2, so a finding rated N1 carries no VDR
deadline and keeps the FedRAMP Rev 5 window. DefectDojo does not invent a row FedRAMP has not
published.
-
-Enabling PAIN deadlines **replaces** the three tiers rather than combining with them. A finding rated
-N2 gets 48 days, not the 4-day tier it would have received without a rating — which is the point of
-rating it.
+* **A cell only ever caps the base window.** DefectDojo takes the shorter of the two, so a Critical
+ rated N2 gets its 30-day base SLA rather than the N2 cell's 48 days. Tiering can tighten a deadline
+ and never extend one.
The date each rating was set is recorded as **PAIN Evaluated**, so reporting can show when each
impact decision was made. The deadline itself still runs from the finding's SLA start date — its
@@ -93,7 +94,8 @@ discovery date. Re-running a rule that assigns the same rating a finding already
the evaluated date.
For the FedRAMP requirement in full, a worked example, and how to assign ratings at scale, see
-[Potential Agency Impact (PAIN) Ratings](../pain_ratings).
+[Potential Agency Impact (PAIN) Ratings](../pain_ratings). For the order to switch it on in, and what
+each deadline should read as you go, see [Setting Up PAIN Ratings](../pain_ratings_setup).
## Relationship to the ledger
diff --git a/docs/content/get_started/pro/onprem/_index.md b/docs/content/get_started/pro/onprem/_index.md
index bd18768e7f3..9d257c34cf3 100644
--- a/docs/content/get_started/pro/onprem/_index.md
+++ b/docs/content/get_started/pro/onprem/_index.md
@@ -1,6 +1,11 @@
---
title: "🔸 DefectDojo Pro (On-Premise)"
+description: "Self-host DefectDojo Pro on your own infrastructure: sizing, installing on Docker Compose or Kubernetes, upgrades, FIPS mode, and backups"
date: 2021-02-02T20:46:29+01:00
weight: 3
audience: pro
----
\ No newline at end of file
+---
+
+Run DefectDojo Pro in your own environment instead of the hosted product. The pages in this section cover sizing the deployment, the two self-hosted models (Docker Compose and Kubernetes with the Helm chart), upgrading, FIPS 140-3 mode, backups, and reaching external services through a forward proxy.
+
+Start with [Self-Hosting DefectDojo Pro](/get_started/pro/onprem/installation_options/) for the deployment models and prerequisites, then follow the install guide for your platform.
\ No newline at end of file
diff --git a/docs/content/get_started/pro/onprem/backing_up.de.md b/docs/content/get_started/pro/onprem/backing_up.de.md
index 36292d8229c..b41983bd8e6 100644
--- a/docs/content/get_started/pro/onprem/backing_up.de.md
+++ b/docs/content/get_started/pro/onprem/backing_up.de.md
@@ -4,7 +4,7 @@ description: Die vier Dinge, die gesichert werden müssen, wo sie sich bei Compo
und Kubernetes-Deployments jeweils befinden, und wie Sie bestätigen, dass ein Backup
tatsächlich wiederhergestellt werden kann
draft: false
-weight: 12
+weight: 4
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/backing_up.es.md b/docs/content/get_started/pro/onprem/backing_up.es.md
index db0767f8151..85e893257e1 100644
--- a/docs/content/get_started/pro/onprem/backing_up.es.md
+++ b/docs/content/get_started/pro/onprem/backing_up.es.md
@@ -4,7 +4,7 @@ description: Las cuatro cosas que debe capturar, dónde vive cada una en impleme
con Compose y Kubernetes, y cómo confirmar que una copia de seguridad realmente
se puede restaurar
draft: false
-weight: 12
+weight: 4
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/backing_up.fr.md b/docs/content/get_started/pro/onprem/backing_up.fr.md
index e3fea60ab23..815e4deaca3 100644
--- a/docs/content/get_started/pro/onprem/backing_up.fr.md
+++ b/docs/content/get_started/pro/onprem/backing_up.fr.md
@@ -4,7 +4,7 @@ description: Les quatre éléments à capturer, leur emplacement pour les déplo
Compose et Kubernetes, et comment vérifier qu'une sauvegarde peut réellement être
restaurée
draft: false
-weight: 12
+weight: 4
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/backing_up.it.md b/docs/content/get_started/pro/onprem/backing_up.it.md
index ddefd82319b..955f146065a 100644
--- a/docs/content/get_started/pro/onprem/backing_up.it.md
+++ b/docs/content/get_started/pro/onprem/backing_up.it.md
@@ -3,7 +3,7 @@ title: Eseguire il backup di un deployment self-hosted
description: Le quattro cose da acquisire, dove si trova ciascuna nei deployment Compose
e Kubernetes, e come verificare che un backup possa essere effettivamente ripristinato
draft: false
-weight: 12
+weight: 4
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/backing_up.ja.md b/docs/content/get_started/pro/onprem/backing_up.ja.md
index 0b72ae893a0..56cca44e59d 100644
--- a/docs/content/get_started/pro/onprem/backing_up.ja.md
+++ b/docs/content/get_started/pro/onprem/backing_up.ja.md
@@ -2,7 +2,7 @@
title: セルフホスト環境のバックアップ
description: 取得すべき 4 つの要素、Compose および Kubernetes デプロイでそれぞれがどこに存在するか、そしてバックアップが実際に復元可能であることを確認する方法
draft: false
-weight: 12
+weight: 4
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/backing_up.md b/docs/content/get_started/pro/onprem/backing_up.md
index 843f801b1c1..1ca38323b08 100644
--- a/docs/content/get_started/pro/onprem/backing_up.md
+++ b/docs/content/get_started/pro/onprem/backing_up.md
@@ -2,7 +2,7 @@
title: "Backing Up a Self-Hosted Deployment"
description: "The four things to capture, where each one lives for Compose and Kubernetes deployments, and how to confirm a backup can actually be restored"
draft: false
-weight: 12
+weight: 4
audience: pro
---
@@ -40,9 +40,9 @@ Take the dump on a schedule, store it off the machine that produced it, and keep
## Uploaded files
-On a Docker Compose deployment, uploaded files are in the `media` directory inside your deployment directory on the host. Back that path up with your normal filesystem backup. If you have moved it onto separate storage, back up that filesystem rather than the mount point.
-
-On Kubernetes, the media volume is provisioned according to the storage backend you configured, and where the data physically lives determines how you protect it:
+{{< tabs "backup-media" >}}
+{{< tab "Kubernetes" >}}
+The media volume is provisioned according to the storage backend you configured, and where the data physically lives determines how you protect it:
| Storage backend | Where the data lives | How to protect it |
| --- | --- | --- |
@@ -53,18 +53,35 @@ On Kubernetes, the media volume is provisioned according to the storage backend
| `pvc` | A volume from your storage class | A CSI volume snapshot, if your driver supports them |
The chart provisions the volume, it does not protect the contents. There is no snapshot schedule built into it, so the backup has to come from the platform or from your own tooling.
+{{< /tab >}}
+{{< tab "Compose" >}}
+Uploaded files are in the `media` directory inside your deployment directory on the host. Back that path up with your normal filesystem backup. If you have moved it onto separate storage, back up that filesystem rather than the mount point.
+{{< /tab >}}
+{{< /tabs >}}
## Configuration and keys
-On Compose, capture your `customizations` directory, your `certs` directory, and the CLI's stored configuration and environment values. `config print` and `environment print` will show you what is set.
-
-On Kubernetes, capture your values files and the contents of the secrets your release references.
+{{< tabs "backup-config" >}}
+{{< tab "Kubernetes" >}}
+Capture your values files and the contents of the secrets your release references.
+{{< /tab >}}
+{{< tab "Compose" >}}
+Capture your `customizations` directory, your `certs` directory, and the CLI's stored configuration and environment values. `config print` and `environment print` will show you what is set.
+{{< /tab >}}
+{{< /tabs >}}
In both cases, keep the credential encryption key and the secret key somewhere durable and separate, in a secret manager rather than alongside the backup. Anyone holding both the database and those keys can read every stored credential that is encrypted, so they should not travel together. Keys and backup travelling separately narrows the exposure of a lost backup; it does not eliminate it, because the backup still holds the credentials that are not encrypted.
## What is not a backup
+{{< tabs "backup-not-a-backup" >}}
+{{< tab "Kubernetes" >}}
The chart annotates its persistent volume claims so they survive `helm uninstall`, which is on by default. That is a guard against an accidental uninstall, not a backup. It does nothing for corruption, for a deletion inside the application, or for an upgrade that goes badly, because in every one of those cases the volume survives and the damage is on it.
+{{< /tab >}}
+{{< tab "Compose" >}}
+The `media` directory staying on the host after `dojo-compose-cli app stop` is not a backup either. Stopping the stack leaves the files in place, but corruption, a deletion inside the application, or an upgrade that goes badly all land on that same directory.
+{{< /tab >}}
+{{< /tabs >}}
Snapshots retained only in the same account or project as the deployment are similarly weaker than they look. Whatever can delete the deployment can usually delete those too.
diff --git a/docs/content/get_started/pro/onprem/backing_up.pt-br.md b/docs/content/get_started/pro/onprem/backing_up.pt-br.md
index 5697f7128ae..978b95f0353 100644
--- a/docs/content/get_started/pro/onprem/backing_up.pt-br.md
+++ b/docs/content/get_started/pro/onprem/backing_up.pt-br.md
@@ -3,7 +3,7 @@ title: Fazendo Backup de uma Implantação Autogerenciada
description: As quatro coisas a capturar, onde cada uma reside em implantações Compose
e Kubernetes, e como confirmar que um backup pode realmente ser restaurado
draft: false
-weight: 12
+weight: 4
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/backing_up.zh-hans.md b/docs/content/get_started/pro/onprem/backing_up.zh-hans.md
index 1b4f7b9fb44..e94be489528 100644
--- a/docs/content/get_started/pro/onprem/backing_up.zh-hans.md
+++ b/docs/content/get_started/pro/onprem/backing_up.zh-hans.md
@@ -2,7 +2,7 @@
title: 备份自托管部署
description: 需要备份的四项内容、它们在 Compose 和 Kubernetes 部署中各自的位置，以及如何确认备份确实可以恢复
draft: false
-weight: 12
+weight: 4
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/docker_compose/_index.md b/docs/content/get_started/pro/onprem/docker_compose/_index.md
new file mode 100644
index 00000000000..b40bb39bc25
--- /dev/null
+++ b/docs/content/get_started/pro/onprem/docker_compose/_index.md
@@ -0,0 +1,9 @@
+---
+title: "Docker Compose"
+description: "Self-hosting DefectDojo Pro on Docker Compose with dojo-compose-cli"
+draft: false
+weight: 10
+audience: pro
+---
+
+Running DefectDojo Pro on a single host with Docker Compose, managed by `dojo-compose-cli`. These pages cover installing, upgrading, air-gapped installs, adding storage for uploaded files, and raising upload size limits.
diff --git a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.de.md b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.de.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/adding_storage_for_uploads.de.md
rename to docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.de.md
index efb2f214401..b0891c4e6a5 100644
--- a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.de.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.de.md
@@ -3,8 +3,10 @@ title: Speicherplatz für hochgeladene Dateien hinzufügen
description: Erweitern Sie den verfügbaren Speicherplatz für hochgeladene Dateien
in einer Docker-Compose-Bereitstellung, ohne die Bereitstellung selbst zu verändern
draft: false
-weight: 11
+weight: 4
audience: pro
+aliases:
+ - /de/get_started/pro/onprem/adding_storage_for_uploads/
---
Hochgeladene Dateien befinden sich im media-Verzeichnis auf dem Host, und bei einer Docker-Compose-Bereitstellung entspricht der dafür verfügbare Speicherplatz dem, was auf der Festplatte der VM noch frei ist. Große Uploads wie SBOMs können diese Festplatte füllen. Diese Seite beschreibt, wie Sie den Speicherplatz erweitern, ohne die Bereitstellung selbst zu verändern.
diff --git a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.es.md b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.es.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/adding_storage_for_uploads.es.md
rename to docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.es.md
index e6c5ed63749..289cd6e09b9 100644
--- a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.es.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.es.md
@@ -3,8 +3,10 @@ title: Añadir almacenamiento para los archivos subidos
description: Ampliar el almacenamiento disponible para los archivos subidos en un
despliegue de Docker Compose sin modificar el despliegue en sí
draft: false
-weight: 11
+weight: 4
audience: pro
+aliases:
+ - /es/get_started/pro/onprem/adding_storage_for_uploads/
---
Los archivos subidos residen en el directorio media del host, y en un despliegue de Docker Compose el espacio disponible para ellos es el que le quede libre al disco de la VM. Las cargas grandes, como los SBOM, pueden llenar ese disco. Esta página explica cómo ampliar el espacio sin modificar el despliegue en sí.
diff --git a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.fr.md b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.fr.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/adding_storage_for_uploads.fr.md
rename to docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.fr.md
index a6d50b97d47..1811c6106ea 100644
--- a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.fr.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.fr.md
@@ -3,8 +3,10 @@ title: Ajout de stockage pour les fichiers téléversés
description: Augmenter l'espace de stockage disponible pour les fichiers téléversés
sur un déploiement Docker Compose sans modifier le déploiement lui-même
draft: false
-weight: 11
+weight: 4
audience: pro
+aliases:
+ - /fr/get_started/pro/onprem/adding_storage_for_uploads/
---
Les fichiers téléversés résident dans le répertoire media sur l'hôte, et sur un déploiement Docker Compose, l'espace disponible pour eux correspond à ce qu'il reste sur le disque de la VM. Des téléversements volumineux comme des SBOM peuvent remplir ce disque. Cette page explique comment augmenter cet espace sans modifier le déploiement lui-même.
diff --git a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.it.md b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.it.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/adding_storage_for_uploads.it.md
rename to docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.it.md
index fa0d73f7851..f722237ca18 100644
--- a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.it.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.it.md
@@ -3,8 +3,10 @@ title: Aggiungere spazio di archiviazione per i file caricati
description: Espandi lo spazio di archiviazione disponibile per i file caricati in
un deployment Docker Compose senza modificare il deployment stesso
draft: false
-weight: 11
+weight: 4
audience: pro
+aliases:
+ - /it/get_started/pro/onprem/adding_storage_for_uploads/
---
I file caricati risiedono nella directory media sull'host, e in un deployment Docker Compose lo spazio disponibile per essi corrisponde a quanto rimane sul disco della VM. Caricamenti di grandi dimensioni come gli SBOM possono riempire quel disco. Questa pagina illustra come espandere lo spazio senza modificare il deployment stesso.
diff --git a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.ja.md b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.ja.md
similarity index 99%
rename from docs/content/get_started/pro/onprem/adding_storage_for_uploads.ja.md
rename to docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.ja.md
index 46a227be795..375de3f294f 100644
--- a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.ja.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.ja.md
@@ -2,8 +2,10 @@
title: アップロードファイル用のストレージの追加
description: デプロイ自体を変更することなく、Docker Composeデプロイメントでアップロードファイル用に利用可能なストレージを拡張する
draft: false
-weight: 11
+weight: 4
audience: pro
+aliases:
+ - /ja/get_started/pro/onprem/adding_storage_for_uploads/
---
アップロードされたファイルはホスト上のmediaディレクトリに保存され、Docker Composeデプロイメントでは、それらに利用できる容量はVMのディスクの残り容量に依存します。SBOMのような大きなアップロードは、そのディスクを満杯にしてしまうことがあります。このページでは、デプロイ自体を変更することなく容量を拡張する方法について説明します。
diff --git a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.md b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/adding_storage_for_uploads.md
rename to docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.md
index d7c78149b18..a1830c8bddd 100644
--- a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.md
@@ -2,8 +2,10 @@
title: "Adding Storage for Uploaded Files"
description: "Expand the storage available for uploaded files on a Docker Compose deployment without altering the deployment itself"
draft: false
-weight: 11
+weight: 4
audience: pro
+aliases:
+ - /get_started/pro/onprem/adding_storage_for_uploads/
---
Uploaded files live in the media directory on the host, and on a Docker Compose deployment the space available for them is whatever the VM's disk has left. Large uploads such as SBOMs can fill that disk. This page covers expanding the space without changing the deployment itself.
diff --git a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.pt-br.md b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.pt-br.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/adding_storage_for_uploads.pt-br.md
rename to docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.pt-br.md
index ae918679493..95988325014 100644
--- a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.pt-br.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.pt-br.md
@@ -3,8 +3,10 @@ title: Adicionando Armazenamento para Arquivos Enviados
description: Expanda o armazenamento disponível para arquivos enviados em uma implantação
com Docker Compose sem alterar a implantação em si
draft: false
-weight: 11
+weight: 4
audience: pro
+aliases:
+ - /pt-br/get_started/pro/onprem/adding_storage_for_uploads/
---
Os arquivos enviados ficam no diretório media no host, e em uma implantação com Docker Compose o espaço disponível para eles é o que sobrar no disco da VM. Uploads grandes, como SBOMs, podem preencher esse disco. Esta página aborda como expandir esse espaço sem alterar a implantação em si.
diff --git a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.zh-hans.md b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.zh-hans.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/adding_storage_for_uploads.zh-hans.md
rename to docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.zh-hans.md
index dc248e6d2cc..44cb4d44e49 100644
--- a/docs/content/get_started/pro/onprem/adding_storage_for_uploads.zh-hans.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/adding_storage_for_uploads.zh-hans.md
@@ -2,8 +2,10 @@
title: 为上传文件添加存储空间
description: 在不改动 Docker Compose 部署本身的情况下,扩展可用于上传文件的存储空间
draft: false
-weight: 11
+weight: 4
audience: pro
+aliases:
+ - /zh-hans/get_started/pro/onprem/adding_storage_for_uploads/
---
上传的文件存放在主机的 media 目录中,在 Docker Compose 部署中,可供这些文件使用的空间取决于虚拟机磁盘的剩余容量。诸如 SBOM 这类大型上传文件可能会占满该磁盘。本页介绍如何在不更改部署本身的情况下扩展该空间。
diff --git a/docs/content/get_started/pro/onprem/air_gapped_install.de.md b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.de.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/air_gapped_install.de.md
rename to docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.de.md
index 380f91deb54..1df9ce239f3 100644
--- a/docs/content/get_started/pro/onprem/air_gapped_install.de.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.de.md
@@ -4,8 +4,10 @@ description: Bereiten Sie die Installationsartefakte von DefectDojo Pro auf eine
Host mit Internetzugang vor und übertragen Sie sie anschließend in ein abgeschottetes
Netzwerk
draft: false
-weight: 8
+weight: 3
audience: pro
+aliases:
+ - /de/get_started/pro/onprem/air_gapped_install/
---
Diese Seite ergänzt die Installationsanleitung, die mit Ihrer DefectDojo-Pro-Lizenz geliefert wird. Sie behandelt nur das, was sich ändert, wenn der Zielhost keine Verbindung zum Internet hat. Alles andere, einschließlich der Host-Voraussetzungen und der PostgreSQL-Einrichtung, folgt der Standardanleitung.
@@ -52,7 +54,7 @@ newgrp docker
Bestätigen Sie mit `id`, dass sowohl `docker` als auch `dojosrv` aufgeführt sind. Sobald sich Ihr Benutzer in der Gruppe `docker` befindet, benötigen die übrigen Befehle kein `sudo` mehr.
-Wenn der Staging-Host das Internet über einen ausgehenden HTTPS-Proxy erreicht, konfigurieren Sie die Proxy-Variablen, bevor Sie irgendetwas herunterladen. Siehe [Betrieb von DefectDojo hinter einem Forward-HTTPS-Proxy](/onprem_deployment/forward_proxy/).
+Wenn der Staging-Host das Internet über einen ausgehenden HTTPS-Proxy erreicht, konfigurieren Sie die Proxy-Variablen, bevor Sie irgendetwas herunterladen. Siehe [Betrieb von DefectDojo hinter einem Forward-HTTPS-Proxy](/get_started/pro/onprem/forward_proxy/).
### 2. Festlegen der Version
@@ -341,7 +343,7 @@ Sichern Sie Ihre Datenbank vor jedem Upgrade und lesen Sie die [Upgrade-Hinweise
Ein abgeschottetes Deployment läuft ohne jegliche ausgehende Konnektivität, aber Funktionen, die externe Dienste erreichen, können im getrennten Zustand nicht funktionieren. Dies betrifft die Connectors und Integrators, die Daten von cloudgehosteten Tools abrufen, Issue-Tracker-Integrationen wie Jira, ausgehende Benachrichtigungen an Dienste wie Slack und Microsoft Teams sowie Schwachstellen-Anreicherungsdaten, die normalerweise nach einem Zeitplan abgerufen werden.
-Diese werden pro Deployment konfiguriert, anstatt standardmäßig aktiviert zu sein, sodass eine Air-Gapped-Installation durch ihr Fehlen nicht beeinträchtigt wird. Wenn Sie eine solche Funktion aktivieren, ist mit Namensauflösungs- oder Verbindungsfehlern zu rechnen, bis das Deployment über einen Weg zu diesem Dienst verfügt. Wenn der ausgehende Pfad zwar existiert, aber über einen Proxy verläuft, siehe [Betrieb von DefectDojo hinter einem Forward-HTTPS-Proxy](/onprem_deployment/forward_proxy/).
+Diese werden pro Deployment konfiguriert, anstatt standardmäßig aktiviert zu sein, sodass eine Air-Gapped-Installation durch ihr Fehlen nicht beeinträchtigt wird. Wenn Sie eine solche Funktion aktivieren, ist mit Namensauflösungs- oder Verbindungsfehlern zu rechnen, bis das Deployment über einen Weg zu diesem Dienst verfügt. Wenn der ausgehende Pfad zwar existiert, aber über einen Proxy verläuft, siehe [Betrieb von DefectDojo hinter einem Forward-HTTPS-Proxy](/get_started/pro/onprem/forward_proxy/).
### EPSS- und KEV-Daten von einem internen Mirror
diff --git a/docs/content/get_started/pro/onprem/air_gapped_install.es.md b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.es.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/air_gapped_install.es.md
rename to docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.es.md
index 1d16558d068..d88127cfb05 100644
--- a/docs/content/get_started/pro/onprem/air_gapped_install.es.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.es.md
@@ -3,8 +3,10 @@ title: Instalación de DefectDojo Pro en un entorno air-gapped
description: Prepare los artefactos de instalación de DefectDojo Pro en un host con
acceso a internet y luego llévelos a una red air-gapped
draft: false
-weight: 8
+weight: 3
audience: pro
+aliases:
+ - /es/get_started/pro/onprem/air_gapped_install/
---
Esta página es un complemento de las instrucciones de instalación que se incluyen con su licencia de DefectDojo Pro. Cubre únicamente lo que cambia cuando el host de destino no tiene ruta a internet. Todo lo demás, incluidos los requisitos previos del host y la configuración de PostgreSQL, sigue las instrucciones estándar.
@@ -51,7 +53,7 @@ newgrp docker
Confirme con `id` que aparecen tanto `docker` como `dojosrv`. Una vez que su usuario esté en el grupo `docker`, el resto de los comandos no necesitan `sudo`.
-Si el host de preparación llega a internet a través de un proxy HTTPS de salida, configure las variables de proxy antes de descargar nada. Consulte [Cómo ejecutar DefectDojo detrás de un proxy HTTPS de reenvío](/onprem_deployment/forward_proxy/).
+Si el host de preparación llega a internet a través de un proxy HTTPS de salida, configure las variables de proxy antes de descargar nada. Consulte [Cómo ejecutar DefectDojo detrás de un proxy HTTPS de reenvío](/get_started/pro/onprem/forward_proxy/).
### 2. Defina la versión
@@ -340,7 +342,7 @@ Haga una copia de seguridad de su base de datos antes de cualquier actualizació
Una implementación air-gapped funciona sin ninguna conectividad de salida, pero las funciones que se comunican con servicios externos no pueden funcionar mientras esté desconectada. Esto se aplica a los conectores e integradores que obtienen datos de herramientas alojadas en la nube, a las integraciones con sistemas de seguimiento de incidencias como Jira, a las notificaciones de salida hacia servicios como Slack y Microsoft Teams, y a los datos de enriquecimiento de vulnerabilidades que normalmente se obtienen según una programación.
-Estas se configuran por implementación en lugar de estar activas de forma predeterminada, así que una instalación air-gapped no se ve afectada por su ausencia. Si activa alguna, espere que falle con errores de resolución de nombres o de conexión hasta que la implementación tenga una ruta hacia ese servicio. Cuando la ruta de salida existe pero pasa por un proxy, consulte [Cómo ejecutar DefectDojo detrás de un proxy HTTPS de reenvío](/onprem_deployment/forward_proxy/).
+Estas se configuran por implementación en lugar de estar activas de forma predeterminada, así que una instalación air-gapped no se ve afectada por su ausencia. Si activa alguna, espere que falle con errores de resolución de nombres o de conexión hasta que la implementación tenga una ruta hacia ese servicio. Cuando la ruta de salida existe pero pasa por un proxy, consulte [Cómo ejecutar DefectDojo detrás de un proxy HTTPS de reenvío](/get_started/pro/onprem/forward_proxy/).
### Datos de EPSS y KEV desde una réplica interna
diff --git a/docs/content/get_started/pro/onprem/air_gapped_install.fr.md b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.fr.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/air_gapped_install.fr.md
rename to docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.fr.md
index 88768b435f8..89332f05ebf 100644
--- a/docs/content/get_started/pro/onprem/air_gapped_install.fr.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.fr.md
@@ -3,8 +3,10 @@ title: Installation de DefectDojo Pro dans un environnement isolé (air-gapped)
description: Préparez les artefacts d'installation de DefectDojo Pro sur un hôte disposant
d'un accès Internet, puis transférez-les dans un réseau isolé (air-gapped)
draft: false
-weight: 8
+weight: 3
audience: pro
+aliases:
+ - /fr/get_started/pro/onprem/air_gapped_install/
---
Cette page complète les instructions d'installation fournies avec votre licence DefectDojo Pro. Elle ne couvre que ce qui change lorsque l'hôte cible n'a aucun accès à Internet. Pour le reste, y compris les prérequis de l'hôte et la configuration de PostgreSQL, suivez les instructions standard.
@@ -51,7 +53,7 @@ newgrp docker
Vérifiez avec `id` que `docker` et `dojosrv` figurent bien dans la liste. Une fois votre utilisateur dans le groupe `docker`, les commandes suivantes n'ont plus besoin de `sudo`.
-Si l'hôte de préparation accède à Internet via un proxy HTTPS sortant, configurez les variables de proxy avant de télécharger quoi que ce soit. Consultez [Exécuter DefectDojo derrière un proxy HTTPS sortant](/onprem_deployment/forward_proxy/).
+Si l'hôte de préparation accède à Internet via un proxy HTTPS sortant, configurez les variables de proxy avant de télécharger quoi que ce soit. Consultez [Exécuter DefectDojo derrière un proxy HTTPS sortant](/get_started/pro/onprem/forward_proxy/).
### 2. Définir la version
@@ -340,7 +342,7 @@ Sauvegardez votre base de données avant toute mise à niveau, et consultez les
Un déploiement air-gapped fonctionne sans aucune connectivité sortante, mais les fonctionnalités qui contactent des services externes ne peuvent pas fonctionner tant qu'il reste déconnecté. C'est le cas des connecteurs et intégrateurs qui récupèrent des données depuis des outils hébergés dans le cloud, des intégrations avec des outils de suivi des tickets comme Jira, des notifications sortantes vers des services comme Slack et Microsoft Teams, ainsi que des données d'enrichissement de vulnérabilités normalement récupérées selon une planification.
-Ces fonctionnalités se configurent par déploiement plutôt que d'être activées par défaut : une installation air-gapped n'est donc pas compromise par leur absence. Si vous en activez une, attendez-vous à des erreurs de résolution de nom ou de connexion tant que le déploiement n'a pas de route vers ce service. Si le chemin sortant existe mais passe par un proxy, consultez [Exécuter DefectDojo derrière un proxy HTTPS sortant](/onprem_deployment/forward_proxy/).
+Ces fonctionnalités se configurent par déploiement plutôt que d'être activées par défaut : une installation air-gapped n'est donc pas compromise par leur absence. Si vous en activez une, attendez-vous à des erreurs de résolution de nom ou de connexion tant que le déploiement n'a pas de route vers ce service. Si le chemin sortant existe mais passe par un proxy, consultez [Exécuter DefectDojo derrière un proxy HTTPS sortant](/get_started/pro/onprem/forward_proxy/).
### Données EPSS et KEV depuis un miroir interne
diff --git a/docs/content/get_started/pro/onprem/air_gapped_install.it.md b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.it.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/air_gapped_install.it.md
rename to docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.it.md
index 5e9032aad9b..75a50a3c282 100644
--- a/docs/content/get_started/pro/onprem/air_gapped_install.it.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.it.md
@@ -3,8 +3,10 @@ title: Installazione di DefectDojo Pro in un ambiente air-gapped
description: Prepara gli artifact di installazione di DefectDojo Pro su un host con
accesso a Internet, quindi spostali in una rete air-gapped
draft: false
-weight: 8
+weight: 3
audience: pro
+aliases:
+ - /it/get_started/pro/onprem/air_gapped_install/
---
This page is a supplement to the installation instructions supplied with your DefectDojo Pro license. It covers only what changes when the target host has no route to the internet. Everything else, including the host prerequisites and the PostgreSQL setup, follows the standard instructions.
@@ -51,7 +53,7 @@ newgrp docker
Verifica con `id` che siano elencati sia `docker` che `dojosrv`. Una volta che il tuo utente fa parte del gruppo `docker`, i comandi restanti non richiedono `sudo`.
-Se l'host di staging raggiunge Internet tramite un proxy HTTPS in uscita, configura le variabili del proxy prima di scaricare qualsiasi elemento. Consulta [Eseguire DefectDojo dietro un proxy HTTPS forward](/onprem_deployment/forward_proxy/).
+Se l'host di staging raggiunge Internet tramite un proxy HTTPS in uscita, configura le variabili del proxy prima di scaricare qualsiasi elemento. Consulta [Eseguire DefectDojo dietro un proxy HTTPS forward](/get_started/pro/onprem/forward_proxy/).
### 2. Imposta la versione
@@ -340,7 +342,7 @@ Esegui il backup del database prima di ogni aggiornamento e consulta le [note di
Un deployment air-gapped funziona senza alcuna connettività in uscita, ma le funzionalità che raggiungono servizi esterni non possono operare mentre è disconnesso. Questo vale per i connector e gli integrator che effettuano il pull da strumenti ospitati nel cloud, per le integrazioni con issue tracker come Jira, per le notifiche in uscita verso servizi come Slack e Microsoft Teams, e per i dati di arricchimento delle vulnerabilità normalmente recuperati secondo una pianificazione.
-Questi elementi vengono configurati per singolo deployment invece di essere attivi per impostazione predefinita, quindi la loro assenza non compromette un'installazione air-gapped. Se ne abiliti uno, aspettati che fallisca con errori di risoluzione dei nomi o di connessione finché il deployment non avrà un percorso verso quel servizio. Se il percorso in uscita esiste ma passa attraverso un proxy, consulta [Eseguire DefectDojo dietro un proxy HTTPS forward](/onprem_deployment/forward_proxy/).
+Questi elementi vengono configurati per singolo deployment invece di essere attivi per impostazione predefinita, quindi la loro assenza non compromette un'installazione air-gapped. Se ne abiliti uno, aspettati che fallisca con errori di risoluzione dei nomi o di connessione finché il deployment non avrà un percorso verso quel servizio. Se il percorso in uscita esiste ma passa attraverso un proxy, consulta [Eseguire DefectDojo dietro un proxy HTTPS forward](/get_started/pro/onprem/forward_proxy/).
### Dati EPSS e KEV da un mirror interno
diff --git a/docs/content/get_started/pro/onprem/air_gapped_install.ja.md b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.ja.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/air_gapped_install.ja.md
rename to docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.ja.md
index c89f3e1d136..d50c65508da 100644
--- a/docs/content/get_started/pro/onprem/air_gapped_install.ja.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.ja.md
@@ -2,8 +2,10 @@
title: エアギャップ環境への DefectDojo Pro のインストール
description: インターネットに接続できるホストで DefectDojo Pro のインストール用アーティファクトを準備し、エアギャップ環境のネットワークに移動します
draft: false
-weight: 8
+weight: 3
audience: pro
+aliases:
+ - /ja/get_started/pro/onprem/air_gapped_install/
---
このページは、DefectDojo Pro のライセンスに付属するインストール手順を補足するものです。対象ホストがインターネットに接続できない場合に変更が必要となる点のみを扱います。ホストの前提条件や PostgreSQL のセットアップを含め、それ以外はすべて標準の手順に従います。
@@ -50,7 +52,7 @@ newgrp docker
`id` コマンドで `docker` と `dojosrv` の両方がリストされていることを確認してください。ユーザーが `docker` グループに属していれば、以降のコマンドに `sudo` は不要です。
-ステージングホストが送信 HTTPS プロキシ経由でインターネットに接続する場合は、何かを pull する前にプロキシ用の変数を設定してください。詳細は[フォワード HTTPS プロキシ経由での DefectDojo の実行](/onprem_deployment/forward_proxy/)を参照してください。
+ステージングホストが送信 HTTPS プロキシ経由でインターネットに接続する場合は、何かを pull する前にプロキシ用の変数を設定してください。詳細は[フォワード HTTPS プロキシ経由での DefectDojo の実行](/get_started/pro/onprem/forward_proxy/)を参照してください。
### 2. バージョンを設定する
@@ -339,7 +341,7 @@ dojo-compose-cli app restart
エアギャップ環境のデプロイは、送信接続が一切ない状態で動作しますが、外部サービスに接続する機能は、ネットワークが切断されている間は動作できません。これは、クラウドでホストされているツールからデータを取得するコネクタおよびインテグレーター、Jira などの課題管理ツール連携、Slack や Microsoft Teams のようなサービスへの送信通知、そして通常はスケジュールに従って取得される脆弱性エンリッチメントデータに当てはまります。
-これらはデフォルトで有効になっているわけではなく、デプロイごとに設定するものであるため、これらが機能しないことによってエアギャップ環境でのインストールが壊れることはありません。いずれかを有効にした場合、そのデプロイからサービスへの経路が確保されるまでは、名前解決エラーや接続エラーで失敗すると考えてください。送信経路は存在するもののプロキシを経由する場合は、[フォワード HTTPS プロキシ経由での DefectDojo の実行](/onprem_deployment/forward_proxy/)を参照してください。
+これらはデフォルトで有効になっているわけではなく、デプロイごとに設定するものであるため、これらが機能しないことによってエアギャップ環境でのインストールが壊れることはありません。いずれかを有効にした場合、そのデプロイからサービスへの経路が確保されるまでは、名前解決エラーや接続エラーで失敗すると考えてください。送信経路は存在するもののプロキシを経由する場合は、[フォワード HTTPS プロキシ経由での DefectDojo の実行](/get_started/pro/onprem/forward_proxy/)を参照してください。
### 内部ミラーからの EPSS と KEV データ
diff --git a/docs/content/get_started/pro/onprem/air_gapped_install.md b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/air_gapped_install.md
rename to docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.md
index f4212eb249f..0bfa951d5a5 100644
--- a/docs/content/get_started/pro/onprem/air_gapped_install.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.md
@@ -2,8 +2,10 @@
title: "Installing DefectDojo Pro in an Air-Gapped Environment"
description: "Stage the DefectDojo Pro install artifacts on a host with internet access, then move them into an air-gapped network"
draft: false
-weight: 8
+weight: 3
audience: pro
+aliases:
+ - /get_started/pro/onprem/air_gapped_install/
---
This page is a supplement to the installation instructions supplied with your DefectDojo Pro license. It covers only what changes when the target host has no route to the internet. Everything else, including the host prerequisites and the PostgreSQL setup, follows the standard instructions.
@@ -50,7 +52,7 @@ newgrp docker
Confirm with `id` that both `docker` and `dojosrv` are listed. Once your user is in the `docker` group, the remaining commands do not need `sudo`.
-If the staging host reaches the internet through an outbound HTTPS proxy, configure the proxy variables before pulling anything. See [Running DefectDojo Behind a Forward HTTPS Proxy](/onprem_deployment/forward_proxy/).
+If the staging host reaches the internet through an outbound HTTPS proxy, configure the proxy variables before pulling anything. See [Running DefectDojo Behind a Forward HTTPS Proxy](/get_started/pro/onprem/forward_proxy/).
### 2. Set the version
@@ -339,7 +341,7 @@ Back up your database before any upgrade, and review the [upgrade notes](/releas
An air-gapped deployment runs without any outbound connectivity, but features that reach external services cannot work while it is disconnected. This applies to the connectors and integrators that pull from cloud-hosted tools, issue tracker integrations such as Jira, outbound notifications to services like Slack and Microsoft Teams, and vulnerability enrichment data that is normally fetched on a schedule.
-These are configured per deployment rather than being on by default, so an air-gapped install is not broken by their absence. If you enable one, expect it to fail with name resolution or connection errors until the deployment has a route to that service. Where the outbound path exists but goes through a proxy, see [Running DefectDojo Behind a Forward HTTPS Proxy](/onprem_deployment/forward_proxy/).
+These are configured per deployment rather than being on by default, so an air-gapped install is not broken by their absence. If you enable one, expect it to fail with name resolution or connection errors until the deployment has a route to that service. Where the outbound path exists but goes through a proxy, see [Running DefectDojo Behind a Forward HTTPS Proxy](/get_started/pro/onprem/forward_proxy/).
### EPSS and KEV data from an internal mirror
diff --git a/docs/content/get_started/pro/onprem/air_gapped_install.pt-br.md b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.pt-br.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/air_gapped_install.pt-br.md
rename to docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.pt-br.md
index 930519935c0..b6e76b44bb3 100644
--- a/docs/content/get_started/pro/onprem/air_gapped_install.pt-br.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.pt-br.md
@@ -3,8 +3,10 @@ title: Instalando o DefectDojo Pro em um Ambiente Isolado (Air-Gapped)
description: Prepare os artefatos de instalação do DefectDojo Pro em um host com acesso
à internet e depois transfira-os para uma rede isolada
draft: false
-weight: 8
+weight: 3
audience: pro
+aliases:
+ - /pt-br/get_started/pro/onprem/air_gapped_install/
---
This page is a supplement to the installation instructions supplied with your DefectDojo Pro license. It covers only what changes when the target host has no route to the internet. Everything else, including the host prerequisites and the PostgreSQL setup, follows the standard instructions.
@@ -51,7 +53,7 @@ newgrp docker
Confirme com `id` que tanto `docker` quanto `dojosrv` estão listados. Depois que seu usuário estiver no grupo `docker`, os comandos restantes não precisam de `sudo`.
-Se o host de preparação acessa a internet por meio de um proxy HTTPS de saída, configure as variáveis de proxy antes de baixar qualquer coisa. Consulte [Executando o DefectDojo Atrás de um Proxy HTTPS de Encaminhamento](/onprem_deployment/forward_proxy/).
+Se o host de preparação acessa a internet por meio de um proxy HTTPS de saída, configure as variáveis de proxy antes de baixar qualquer coisa. Consulte [Executando o DefectDojo Atrás de um Proxy HTTPS de Encaminhamento](/get_started/pro/onprem/forward_proxy/).
### 2. Defina a versão
@@ -340,7 +342,7 @@ Faça backup do seu banco de dados antes de qualquer atualização e revise as [
Uma implantação isolada funciona sem nenhuma conectividade de saída, mas os recursos que acessam serviços externos não podem funcionar enquanto ela estiver desconectada. Isso se aplica aos conectores e integradores que buscam dados de ferramentas hospedadas na nuvem, às integrações com rastreadores de issues como o Jira, às notificações de saída para serviços como Slack e Microsoft Teams, e aos dados de enriquecimento de vulnerabilidades que normalmente são obtidos periodicamente.
-Esses recursos são configurados por implantação, em vez de vir ativados por padrão, então uma instalação isolada não fica comprometida pela ausência deles. Se você ativar algum, espere que ele falhe com erros de resolução de nome ou de conexão até que a implantação tenha uma rota até aquele serviço. Quando o caminho de saída existe, mas passa por um proxy, consulte [Executando o DefectDojo Atrás de um Proxy HTTPS de Encaminhamento](/onprem_deployment/forward_proxy/).
+Esses recursos são configurados por implantação, em vez de vir ativados por padrão, então uma instalação isolada não fica comprometida pela ausência deles. Se você ativar algum, espere que ele falhe com erros de resolução de nome ou de conexão até que a implantação tenha uma rota até aquele serviço. Quando o caminho de saída existe, mas passa por um proxy, consulte [Executando o DefectDojo Atrás de um Proxy HTTPS de Encaminhamento](/get_started/pro/onprem/forward_proxy/).
### Dados de EPSS e KEV a partir de um espelho interno
diff --git a/docs/content/get_started/pro/onprem/air_gapped_install.zh-hans.md b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.zh-hans.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/air_gapped_install.zh-hans.md
rename to docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.zh-hans.md
index 43f2fec5836..eb1ac518954 100644
--- a/docs/content/get_started/pro/onprem/air_gapped_install.zh-hans.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/air_gapped_install.zh-hans.md
@@ -2,8 +2,10 @@
title: 在离线（气隙）环境中安装 DefectDojo Pro
description: 先在有互联网访问权限的主机上准备好 DefectDojo Pro 安装所需的制品，然后将其转移到离线（气隙）网络中
draft: false
-weight: 8
+weight: 3
audience: pro
+aliases:
+ - /zh-hans/get_started/pro/onprem/air_gapped_install/
---
本页是对 DefectDojo Pro 许可证随附的安装说明的补充。内容仅涉及目标主机无法访问互联网时需要更改的部分。其余部分，包括主机的前提条件和 PostgreSQL 设置，均遵循标准说明进行。
@@ -50,7 +52,7 @@ newgrp docker
使用 `id` 命令确认输出中同时列出了 `docker` 和 `dojosrv`。一旦您的用户加入 `docker` 组，后续命令就无需使用 `sudo`。
-如果暂存主机是通过出站 HTTPS 代理访问互联网的，请在拉取任何内容之前先配置好代理相关变量。请参阅[在正向 HTTPS 代理后运行 DefectDojo](/onprem_deployment/forward_proxy/)。
+如果暂存主机是通过出站 HTTPS 代理访问互联网的，请在拉取任何内容之前先配置好代理相关变量。请参阅[在正向 HTTPS 代理后运行 DefectDojo](/get_started/pro/onprem/forward_proxy/)。
### 2. Set the version
@@ -339,7 +341,7 @@ dojo-compose-cli app restart
离线（气隙）部署在没有任何出站连接的情况下运行，但需要访问外部服务的功能，在处于断网状态时无法正常工作。这包括从云端托管工具拉取数据的连接器（connector）和集成器（integrator）、诸如 Jira 之类的问题跟踪工具集成、面向 Slack 和 Microsoft Teams 等服务的出站通知，以及通常按计划定期获取的漏洞增强数据（vulnerability enrichment data）。
-这些功能是按部署单独配置的，而非默认开启，因此缺少这些功能并不会导致离线（气隙）安装出现故障。如果您启用了其中某项功能，在该部署具备通往相应服务的连接路径之前，应预料到它会因名称解析或连接错误而失败。如果存在出站路径但需经过代理，请参阅[在正向 HTTPS 代理后运行 DefectDojo](/onprem_deployment/forward_proxy/)。
+这些功能是按部署单独配置的，而非默认开启，因此缺少这些功能并不会导致离线（气隙）安装出现故障。如果您启用了其中某项功能，在该部署具备通往相应服务的连接路径之前，应预料到它会因名称解析或连接错误而失败。如果存在出站路径但需经过代理，请参阅[在正向 HTTPS 代理后运行 DefectDojo](/get_started/pro/onprem/forward_proxy/)。
### EPSS and KEV data from an internal mirror
diff --git a/docs/content/get_started/pro/onprem/installing_on_docker_compose.de.md b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.de.md
similarity index 97%
rename from docs/content/get_started/pro/onprem/installing_on_docker_compose.de.md
rename to docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.de.md
index a97c9439c6d..1f4de340876 100644
--- a/docs/content/get_started/pro/onprem/installing_on_docker_compose.de.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.de.md
@@ -3,8 +3,10 @@ title: Installation über Docker Compose
description: Installieren Sie selbst gehostetes DefectDojo Pro auf einem einzelnen
Host mit dojo-compose-cli, mit PostgreSQL auf einem separaten Server
draft: false
-weight: 15
+weight: 1
audience: pro
+aliases:
+ - /de/get_started/pro/onprem/installing_on_docker_compose/
---
Diese Seite behandelt die Installation von DefectDojo Pro über Docker Compose, das einfachere der beiden selbst gehosteten Modelle und die richtige Wahl, wenn Sie noch kein Kubernetes betreiben.
@@ -95,7 +97,7 @@ In einem eingeschränkten Netzwerk benötigt der Anwendungs-Host ausgehenden Zug
Erstellen Sie die Allowlist nach Hostname statt nach Adresse. Die Registry liegt hinter einem Content Delivery Network, daher variieren ihre Adressen je nach Standort und ändern sich mit der Zeit.
-Wenn der Host das Internet über einen ausgehenden Proxy erreicht, siehe [Running DefectDojo Behind a Forward HTTPS Proxy](/onprem_deployment/forward_proxy/). Hat er überhaupt keine Verbindung zum Internet, folgen Sie stattdessen dem Verfahren für die Air-Gapped-Installation in diesem Abschnitt.
+Wenn der Host das Internet über einen ausgehenden Proxy erreicht, siehe [Running DefectDojo Behind a Forward HTTPS Proxy](/get_started/pro/onprem/forward_proxy/). Hat er überhaupt keine Verbindung zum Internet, folgen Sie stattdessen dem Verfahren für die Air-Gapped-Installation in diesem Abschnitt.
### Erreichbarkeit der Datenbank prüfen
diff --git a/docs/content/get_started/pro/onprem/installing_on_docker_compose.es.md b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.es.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/installing_on_docker_compose.es.md
rename to docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.es.md
index 78ef5ff00bc..339510591d2 100644
--- a/docs/content/get_started/pro/onprem/installing_on_docker_compose.es.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.es.md
@@ -3,8 +3,10 @@ title: Instalación en Docker Compose
description: Instale DefectDojo Pro autoalojado en un solo host usando dojo-compose-cli,
con PostgreSQL en un servidor separado
draft: false
-weight: 15
+weight: 1
audience: pro
+aliases:
+ - /es/get_started/pro/onprem/installing_on_docker_compose/
---
Esta página cubre la instalación de DefectDojo Pro en Docker Compose, que es el más sencillo de los dos modelos autoalojados y la opción adecuada si aún no está ejecutando Kubernetes.
@@ -95,7 +97,7 @@ En una red restringida, el host de la aplicación necesita acceso saliente a lo
Incluya en la lista de permitidos por nombre de host en lugar de por dirección. El registro está detrás de una red de distribución de contenido, por lo que sus direcciones varían según la ubicación y cambian con el tiempo.
-Si el host llega a internet a través de un proxy saliente, consulte [Ejecución de DefectDojo detrás de un proxy HTTPS de reenvío](/onprem_deployment/forward_proxy/). Si no tiene ninguna ruta a internet, siga en su lugar el procedimiento de instalación con espacio de aire (air-gapped) de esta sección.
+Si el host llega a internet a través de un proxy saliente, consulte [Ejecución de DefectDojo detrás de un proxy HTTPS de reenvío](/get_started/pro/onprem/forward_proxy/). Si no tiene ninguna ruta a internet, siga en su lugar el procedimiento de instalación con espacio de aire (air-gapped) de esta sección.
### Confirmar que la base de datos es accesible
diff --git a/docs/content/get_started/pro/onprem/installing_on_docker_compose.fr.md b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.fr.md
similarity index 97%
rename from docs/content/get_started/pro/onprem/installing_on_docker_compose.fr.md
rename to docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.fr.md
index 578e84a3591..1c294b4212e 100644
--- a/docs/content/get_started/pro/onprem/installing_on_docker_compose.fr.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.fr.md
@@ -3,8 +3,10 @@ title: Installation sur Docker Compose
description: Installez DefectDojo Pro auto-hébergé sur un hôte unique à l'aide de
dojo-compose-cli, avec PostgreSQL sur un serveur séparé
draft: false
-weight: 15
+weight: 1
audience: pro
+aliases:
+ - /fr/get_started/pro/onprem/installing_on_docker_compose/
---
Cette page explique comment installer DefectDojo Pro sur Docker Compose, le plus simple des deux modèles d'auto-hébergement, et le bon choix si vous n'exploitez pas déjà Kubernetes.
@@ -95,7 +97,7 @@ Dans un réseau restreint, l'hôte applicatif a besoin d'un accès sortant vers
Autorisez par nom d'hôte plutôt que par adresse. Le registre se trouve derrière un réseau de diffusion de contenu, si bien que ses adresses varient selon la localisation et changent au fil du temps.
-Si l'hôte accède à Internet via un proxy sortant, consultez [Exécuter DefectDojo derrière un proxy HTTPS sortant](/onprem_deployment/forward_proxy/). S'il n'a aucun accès à Internet, suivez plutôt la procédure d'installation en environnement isolé (air-gapped) de cette section.
+Si l'hôte accède à Internet via un proxy sortant, consultez [Exécuter DefectDojo derrière un proxy HTTPS sortant](/get_started/pro/onprem/forward_proxy/). S'il n'a aucun accès à Internet, suivez plutôt la procédure d'installation en environnement isolé (air-gapped) de cette section.
### Vérifier que la base de données est accessible
diff --git a/docs/content/get_started/pro/onprem/installing_on_docker_compose.it.md b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.it.md
similarity index 97%
rename from docs/content/get_started/pro/onprem/installing_on_docker_compose.it.md
rename to docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.it.md
index 0cdac48ba29..0299ed13774 100644
--- a/docs/content/get_started/pro/onprem/installing_on_docker_compose.it.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.it.md
@@ -3,8 +3,10 @@ title: Installazione su Docker Compose
description: Installa DefectDojo Pro self-hosted su un singolo host utilizzando dojo-compose-cli,
con PostgreSQL su un server separato
draft: false
-weight: 15
+weight: 1
audience: pro
+aliases:
+ - /it/get_started/pro/onprem/installing_on_docker_compose/
---
Questa pagina descrive l'installazione di DefectDojo Pro su Docker Compose, che è il più semplice dei due modelli self-hosted ed è la scelta giusta se non si utilizza già Kubernetes.
@@ -95,7 +97,7 @@ In una rete con restrizioni, l'host dell'applicazione necessita di accesso in us
Creare l'allowlist per hostname anziché per indirizzo. Il registro si trova dietro una rete di distribuzione dei contenuti, quindi i suoi indirizzi variano a seconda della località e cambiano nel tempo.
-Se l'host raggiunge Internet tramite un proxy in uscita, vedere [Running DefectDojo Behind a Forward HTTPS Proxy](/onprem_deployment/forward_proxy/). Se non ha alcun accesso a Internet, seguire invece la procedura di installazione air-gapped in questa sezione.
+Se l'host raggiunge Internet tramite un proxy in uscita, vedere [Running DefectDojo Behind a Forward HTTPS Proxy](/get_started/pro/onprem/forward_proxy/). Se non ha alcun accesso a Internet, seguire invece la procedura di installazione air-gapped in questa sezione.
### Verificare che il database sia raggiungibile
diff --git a/docs/content/get_started/pro/onprem/installing_on_docker_compose.ja.md b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.ja.md
similarity index 97%
rename from docs/content/get_started/pro/onprem/installing_on_docker_compose.ja.md
rename to docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.ja.md
index e4b5bee1f78..860cf6c9b6e 100644
--- a/docs/content/get_started/pro/onprem/installing_on_docker_compose.ja.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.ja.md
@@ -2,8 +2,10 @@
title: Docker Composeへのインストール
description: dojo-compose-cliを使用して、PostgreSQLを別サーバーに置いた単一ホストにセルフホスト型DefectDojo Proをインストールします
draft: false
-weight: 15
+weight: 1
audience: pro
+aliases:
+ - /ja/get_started/pro/onprem/installing_on_docker_compose/
---
このページでは、セルフホスト型の二つのモデルのうちよりシンプルな方法であり、すでにKubernetesを運用していない場合に適した選択肢である、Docker ComposeへのDefectDojo Proのインストールについて説明します。
@@ -94,7 +96,7 @@ systemctl restart postgresql
アドレスではなくホスト名で許可リストに登録してください。レジストリはコンテンツデリバリーネットワークの背後にあるため、そのアドレスは場所によって異なり、時間とともに変化します。
-ホストがアウトバウンドプロキシ経由でインターネットに到達する場合は、[フォワードHTTPSプロキシの背後でDefectDojoを実行する](/onprem_deployment/forward_proxy/)を参照してください。インターネットへの経路が全くない場合は、代わりにこのセクションのエアギャップインストール手順に従ってください。
+ホストがアウトバウンドプロキシ経由でインターネットに到達する場合は、[フォワードHTTPSプロキシの背後でDefectDojoを実行する](/get_started/pro/onprem/forward_proxy/)を参照してください。インターネットへの経路が全くない場合は、代わりにこのセクションのエアギャップインストール手順に従ってください。
### データベースへの到達性を確認する
diff --git a/docs/content/get_started/pro/onprem/installing_on_docker_compose.md b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.md
similarity index 76%
rename from docs/content/get_started/pro/onprem/installing_on_docker_compose.md
rename to docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.md
index 4c56822dff2..60a38795574 100644
--- a/docs/content/get_started/pro/onprem/installing_on_docker_compose.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.md
@@ -2,8 +2,10 @@
title: "Installing on Docker Compose"
description: "Install self-hosted DefectDojo Pro on a single host using dojo-compose-cli, with PostgreSQL on a separate server"
draft: false
-weight: 15
+weight: 1
audience: pro
+aliases:
+ - /get_started/pro/onprem/installing_on_docker_compose/
---
This page covers installing DefectDojo Pro on Docker Compose, which is the simpler of the two self-hosted models and the right choice if you are not already running Kubernetes.
@@ -94,7 +96,7 @@ In a restricted network, the application host needs outbound access to the follo
Allowlist by hostname rather than by address. The registry sits behind a content delivery network, so its addresses vary by location and change over time.
-If the host reaches the internet through an outbound proxy, see [Running DefectDojo Behind a Forward HTTPS Proxy](/onprem_deployment/forward_proxy/). If it has no route to the internet at all, follow the air-gapped installation procedure in this section instead.
+If the host reaches the internet through an outbound proxy, see [Running DefectDojo Behind a Forward HTTPS Proxy](/get_started/pro/onprem/forward_proxy/). If it has no route to the internet at all, follow the air-gapped installation procedure in this section instead.
### Confirm the database is reachable
@@ -188,36 +190,52 @@ The installation ships a self-signed certificate so that the site works immediat
Then `dojo-compose-cli app restart` to pick them up.
-## Reset the admin password
+## Trusting an internal or private CA
-If you lose the generated password, reset it from the application host. DefectDojo has to be running:
+If DefectDojo has to reach services whose TLS certificates are signed by an internal or private certificate authority (CA), the containers need to trust that CA first. This is common with a self-hosted Jira, an internal SSO or identity provider, SonarQube, or a security tool reached through a Connector. It is a separate concern from [replacing the server certificate](#replace-the-tls-certificate) above: that controls the certificate DefectDojo presents to browsers, whereas this controls which CAs DefectDojo trusts on its outbound calls.
-```bash
-dojo-compose-cli app change-password
-```
+You set the trust by placing PEM-encoded CA bundles in the `certs/private/` directory under the install directory, which is `/opt/dojo/certs/private/` in a default install. Two bundles cover the two sides of the application:
-## Upgrading
+- `dojo-ca-bundle.crt` is for services the application calls directly, such as Jira and SSO providers. On startup the `dojo`, `celeryworker`, and `ddorch-workers` containers read it and set `REQUESTS_CA_BUNDLE` to it when it is present and not empty.
+- `connectors-ca-bundle.crt` is for tools reached through Connectors, such as Burp or Semgrep. The connectors container appends it to `CA_BUNDLES` on startup.
-Back up your database first, and read the release notes for every version between your current one and your target rather than only the target. See the [upgrade notes](/releases/os_upgrading/upgrading_guide/).
+Each file must be in PEM format (Base64-encoded X.509, starting with `-----BEGIN CERTIFICATE-----` and ending with `-----END CERTIFICATE-----`), and each may hold more than one certificate concatenated together. The file has to be readable by the container process, so set permissions accordingly (for example `chmod 644`).
-The CLI can do the whole upgrade, prompting for the version:
+To install a bundle for the application side:
```bash
-dojo-compose-cli app upgrade
+# Create the directory if it does not already exist
+sudo mkdir -p /opt/dojo/certs/private
+
+# Copy your PEM bundle into place under the expected name
+sudo cp my-internal-ca.crt /opt/dojo/certs/private/dojo-ca-bundle.crt
+sudo chmod 644 /opt/dojo/certs/private/dojo-ca-bundle.crt
+
+# Restart the application so the containers pick it up
+dojo-compose-cli app restart
+```
+
+Use the filename `connectors-ca-bundle.crt` instead when the CA is only needed for Connector tools, and install both files if you need both. Inside the containers these paths are `/app/certs/private/dojo-ca-bundle.crt` and `/app/certs/private/connectors-ca-bundle.crt`.
+
+To confirm the bundle was loaded, look at the `dojo` container's startup logs for the confirmation line:
+
+```text
+REQUESTS_CA_BUNDLE set to /app/certs/private/dojo-ca-bundle.crt
```
-If you would rather do it in steps, stop the application, set the new version, download the matching deployment files, then start again:
+If the file is missing or empty the container logs `No CA bundle found ...` instead and starts normally, so a bundle you forgot to install fails as an untrusted-certificate error on the outbound call rather than as a startup error.
+
+## Reset the admin password
+
+If you lose the generated password, reset it from the application host. DefectDojo has to be running:
```bash
-dojo-compose-cli app stop
-dojo-compose-cli config set --version x.y.z --deploy-version x.y.z
-dojo-compose-cli deploy download
-dojo-compose-cli app start
+dojo-compose-cli app change-password
```
-The download step compares the incoming `docker-compose.yml`, nginx configuration, and `local_settings.py` against what you already have, and tells you when they differ so you can reconcile your changes. Adding `--overwrite` accepts the new versions of those files and discards local modifications to them, so use it deliberately.
+## Upgrading
-Keep your own settings in `/opt/dojo/customizations/local_settings.py`. That file is yours and survives upgrades.
+Upgrades are covered on their own page: see the [DefectDojo Pro Upgrade Guide (Docker Compose)](/get_started/pro/onprem/docker_compose/upgrading_on_docker_compose/) for the one-command `app upgrade`, the step-by-step path, air-gapped upgrades, and rollback.
## Command reference
diff --git a/docs/content/get_started/pro/onprem/installing_on_docker_compose.pt-br.md b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.pt-br.md
similarity index 98%
rename from docs/content/get_started/pro/onprem/installing_on_docker_compose.pt-br.md
rename to docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.pt-br.md
index 8c9f08f68e6..5a1df06f545 100644
--- a/docs/content/get_started/pro/onprem/installing_on_docker_compose.pt-br.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.pt-br.md
@@ -3,8 +3,10 @@ title: Instalando no Docker Compose
description: Instale o DefectDojo Pro auto-hospedado em um único host usando o dojo-compose-cli,
com o PostgreSQL em um servidor separado
draft: false
-weight: 15
+weight: 1
audience: pro
+aliases:
+ - /pt-br/get_started/pro/onprem/installing_on_docker_compose/
---
Esta página aborda a instalação do DefectDojo Pro no Docker Compose, que é o mais simples dos dois modelos auto-hospedados e a escolha certa se você ainda não executa Kubernetes.
@@ -95,7 +97,7 @@ Em uma rede restrita, o host da aplicação precisa de acesso de saída para o s
Inclua na lista de permissões por nome de host, e não por endereço. O registro fica atrás de uma rede de distribuição de conteúdo, então seus endereços variam por localização e mudam com o tempo.
-Se o host acessa a internet através de um proxy de saída, veja [Executando o DefectDojo Atrás de um Proxy HTTPS de Encaminhamento](/onprem_deployment/forward_proxy/). Se ele não tiver nenhuma rota para a internet, siga o procedimento de instalação air-gapped desta seção.
+Se o host acessa a internet através de um proxy de saída, veja [Executando o DefectDojo Atrás de um Proxy HTTPS de Encaminhamento](/get_started/pro/onprem/forward_proxy/). Se ele não tiver nenhuma rota para a internet, siga o procedimento de instalação air-gapped desta seção.
### Confirme que o banco de dados está acessível
diff --git a/docs/content/get_started/pro/onprem/installing_on_docker_compose.zh-hans.md b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.zh-hans.md
similarity index 97%
rename from docs/content/get_started/pro/onprem/installing_on_docker_compose.zh-hans.md
rename to docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.zh-hans.md
index 163ba7770e1..24fb81cdcda 100644
--- a/docs/content/get_started/pro/onprem/installing_on_docker_compose.zh-hans.md
+++ b/docs/content/get_started/pro/onprem/docker_compose/installing_on_docker_compose.zh-hans.md
@@ -2,8 +2,10 @@
title: 在 Docker Compose 上安装
description: 使用 dojo-compose-cli 在单台主机上安装自托管的 DefectDojo Pro，并将 PostgreSQL 部署在单独的服务器上
draft: false
-weight: 15
+weight: 1
audience: pro
+aliases:
+ - /zh-hans/get_started/pro/onprem/installing_on_docker_compose/
---
本页介绍如何在 Docker Compose 上安装 DefectDojo Pro，这是两种自托管模式中较为简单的一种，如果您尚未运行 Kubernetes，这是正确的选择。
@@ -94,7 +96,7 @@ systemctl restart postgresql
请按主机名而非地址加入允许列表。镜像仓库位于内容分发网络之后，因此其地址会因地理位置而异，并且会随时间变化。
-如果该主机通过出站代理访问互联网，请参阅[在正向 HTTPS 代理后运行 DefectDojo](/onprem_deployment/forward_proxy/)。如果该主机完全无法访问互联网，请改为遵循本节中的离线（air-gapped）安装流程。
+如果该主机通过出站代理访问互联网，请参阅[在正向 HTTPS 代理后运行 DefectDojo](/get_started/pro/onprem/forward_proxy/)。如果该主机完全无法访问互联网，请改为遵循本节中的离线（air-gapped）安装流程。
### 确认数据库可访问
diff --git a/docs/content/get_started/pro/onprem/docker_compose/upgrading_on_docker_compose.md b/docs/content/get_started/pro/onprem/docker_compose/upgrading_on_docker_compose.md
new file mode 100644
index 00000000000..981d03b6904
--- /dev/null
+++ b/docs/content/get_started/pro/onprem/docker_compose/upgrading_on_docker_compose.md
@@ -0,0 +1,61 @@
+---
+title: "DefectDojo Pro Upgrade Guide (Docker Compose)"
+description: "Upgrade a self-hosted DefectDojo Pro deployment that runs on Docker Compose with dojo-compose-cli"
+draft: false
+weight: 2
+audience: pro
+aliases:
+ - /get_started/pro/onprem/upgrading_on_docker_compose/
+---
+
+This guide covers upgrading a self-hosted DefectDojo Pro deployment that runs on Docker Compose, managed with `dojo-compose-cli`. If you run on Kubernetes, see the [DefectDojo Pro Upgrade Guide](/get_started/pro/onprem/kubernetes/upgrading_on_kubernetes/) for the Helm chart instead.
+
+Each DefectDojo Pro release is a set of container images, deployment files, and settings that are built and tested together. Upgrade them together, and do not change image tags on their own.
+
+## Before you upgrade
+
+Back up your database first, and read the release notes for every version between your current one and your target rather than only the target. See the [upgrade notes](/releases/os_upgrading/upgrading_guide/) and the [DefectDojo Pro Changelog](/releases/pro/changelog/).
+
+Keep your own settings in `/opt/dojo/customizations/local_settings.py`. That file is yours and survives upgrades.
+
+## Upgrade in one command
+
+The CLI can do the whole upgrade, prompting for the version:
+
+```bash
+dojo-compose-cli app upgrade
+```
+
+## Upgrade step by step
+
+If you would rather do it in steps, stop the application, set the new version, download the matching deployment files, then start again:
+
+```bash
+dojo-compose-cli app stop
+dojo-compose-cli config set --version x.y.z --deploy-version x.y.z
+dojo-compose-cli deploy download
+dojo-compose-cli app start
+```
+
+The version you set selects the image tags, and `deploy download` fetches the deployment files that match it. The download step compares the incoming `docker-compose.yml`, nginx configuration, and `local_settings.py` against what you already have, and tells you when they differ so you can reconcile your changes. Adding `--overwrite` accepts the new versions of those files and discards local modifications to them, so use it deliberately.
+
+## Air-gapped upgrades
+
+In an air-gapped deployment, `app upgrade` is declined because it reaches the registry. Upgrade by repeating the staged image-transfer route you used to install: pull the new images on the staging host, move the bundle across, load it on the application host, then set the new `--version` and `--deploy-version` and restart. See [Installing DefectDojo Pro in an Air-Gapped Environment](/get_started/pro/onprem/docker_compose/air_gapped_install/) for the full procedure.
+
+## Rollback
+
+Docker Compose has no automatic rollback. To return to the previous release, set the prior version and re-download the matching deployment files:
+
+```bash
+dojo-compose-cli app stop
+dojo-compose-cli config set --version x.y.z --deploy-version x.y.z
+dojo-compose-cli deploy download
+dojo-compose-cli app start
+```
+
+**Database migrations do not roll back.** Setting an older version restores the images and deployment files, but it does not reverse a schema migration the upgrade applied. If the upgrade migrated the database, restore from the backup you took before upgrading, or coordinate a manual migration reversal with DefectDojo support before you start the older version. If you are several releases behind, contact [support@defectdojo.com](mailto:support@defectdojo.com).
+
+## Questions or support
+
+If an upgrade does not complete, `dojo-compose-cli diagnostics collect` gathers a report bundle that is the fastest way for us to help. Send it, along with what you were running when it failed, to [support@defectdojo.com](mailto:support@defectdojo.com).
diff --git a/docs/content/get_started/pro/onprem/docker_compose/upload_size_limits.md b/docs/content/get_started/pro/onprem/docker_compose/upload_size_limits.md
new file mode 100644
index 00000000000..cb77ccdc0d5
--- /dev/null
+++ b/docs/content/get_started/pro/onprem/docker_compose/upload_size_limits.md
@@ -0,0 +1,37 @@
+---
+title: "Upload Size Limits for Large Scan Files"
+description: "Why a large scan file fails to upload on Docker Compose, and which limit to raise"
+draft: false
+weight: 5
+audience: pro
+---
+
+A large scan file can be rejected at two points on a Docker Compose deployment: the application's own limit, and the nginx that ships in front of it. The error you get tells you which one you hit. Running Kubernetes? See [Upload Size Limits for Large Scan Files](/get_started/pro/onprem/kubernetes/upload_size_limits/) for the Helm chart, which adds ingress and import-route limits that do not apply here.
+
+## Which limit am I hitting
+
+| What you see | Where it came from |
+| --- | --- |
+| `Report file is too large. Maximum supported size is N MB` | The application limit, reported by DefectDojo itself |
+| A plain `413 Request Entity Too Large`, unstyled, with no DefectDojo page around it | The nginx that ships with the deployment rejected the request before it reached the application |
+
+## The application limit
+
+DefectDojo enforces a maximum scan file size of its own, and rejects anything larger with a message naming the current limit. It defaults to 100 MB. On Docker Compose, set the `DD_SCAN_FILE_MAX_SIZE` environment variable, in megabytes, through the CLI, then restart:
+
+```bash
+dojo-compose-cli environment add DD_SCAN_FILE_MAX_SIZE=200
+dojo-compose-cli app restart
+```
+
+Run `dojo-compose-cli environment add --help` for the exact syntax your CLI version expects.
+
+## The nginx ceiling
+
+Compose deployments have no ingress controller, so the ingress limit that Kubernetes deployments raise does not apply. Instead, the nginx that ships in the deployment caps request bodies at 800 MB, which is the practical ceiling, and the application limit above applies on top of that.
+
+Raising the nginx cap means changing a file that ships with the deployment, and those files are replaced when you upgrade rather than preserved like your `customizations` directory. Contact support before changing it, so the change does not disappear at the next upgrade.
+
+## Questions or support
+
+If uploads still fail after raising the limit that matches your symptom, collect the response your client received and the nginx logs covering the attempt, then contact [support@defectdojo.com](mailto:support@defectdojo.com).
diff --git a/docs/content/get_started/pro/onprem/fips_mode.de.md b/docs/content/get_started/pro/onprem/fips_mode.de.md
index 696ea00430d..93fc209ceb9 100644
--- a/docs/content/get_started/pro/onprem/fips_mode.de.md
+++ b/docs/content/get_started/pro/onprem/fips_mode.de.md
@@ -1,7 +1,7 @@
---
title: FIPS-140-3-Modus
date: 2026-07-27 00:00:00+00:00
-weight: 6
+weight: 7
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/fips_mode.es.md b/docs/content/get_started/pro/onprem/fips_mode.es.md
index 26e31878483..1dfbd571d08 100644
--- a/docs/content/get_started/pro/onprem/fips_mode.es.md
+++ b/docs/content/get_started/pro/onprem/fips_mode.es.md
@@ -1,7 +1,7 @@
---
title: Modo FIPS 140-3
date: 2026-07-27 00:00:00+00:00
-weight: 6
+weight: 7
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/fips_mode.fr.md b/docs/content/get_started/pro/onprem/fips_mode.fr.md
index e678bb8579b..f7ddb168fc6 100644
--- a/docs/content/get_started/pro/onprem/fips_mode.fr.md
+++ b/docs/content/get_started/pro/onprem/fips_mode.fr.md
@@ -1,7 +1,7 @@
---
title: Mode FIPS 140-3
date: 2026-07-27 00:00:00+00:00
-weight: 6
+weight: 7
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/fips_mode.it.md b/docs/content/get_started/pro/onprem/fips_mode.it.md
index 20ab70116c2..1aa1abb21e1 100644
--- a/docs/content/get_started/pro/onprem/fips_mode.it.md
+++ b/docs/content/get_started/pro/onprem/fips_mode.it.md
@@ -1,7 +1,7 @@
---
title: Modalità FIPS 140-3
date: 2026-07-27 00:00:00+00:00
-weight: 6
+weight: 7
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/fips_mode.ja.md b/docs/content/get_started/pro/onprem/fips_mode.ja.md
index 557f9b4fb7b..f62321bb2fe 100644
--- a/docs/content/get_started/pro/onprem/fips_mode.ja.md
+++ b/docs/content/get_started/pro/onprem/fips_mode.ja.md
@@ -1,7 +1,7 @@
---
title: FIPS 140-3 モード
date: 2026-07-27 00:00:00+00:00
-weight: 6
+weight: 7
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/fips_mode.md b/docs/content/get_started/pro/onprem/fips_mode.md
index 26452b29a4d..ed18cfc03cc 100644
--- a/docs/content/get_started/pro/onprem/fips_mode.md
+++ b/docs/content/get_started/pro/onprem/fips_mode.md
@@ -1,7 +1,9 @@
---
title: "FIPS 140-3 Mode"
+description: "Deploy DefectDojo Pro with FIPS 140-3 validated cryptography using the -fips container images, for FedRAMP SC-13 and similar requirements"
+draft: false
date: 2026-07-27T00:00:00+00:00
-weight: 6
+weight: 7
audience: pro
---
@@ -36,42 +38,12 @@ Because enforcement happens **inside the container**, FIPS mode does not require
**Sensei is a partial case worth understanding.** Its own binaries are built against the validated Go module, so the job API's TLS and tokens are covered. The image also bundles a polyglot third-party scanner toolchain — Node (which ships its own OpenSSL), Rust (rustls), Python, Ruby, and third-party Go binaries we do not compile — and several of those fetch advisory databases over TLS using their own cryptography. That toolchain cannot be brought under a single validated module, so it is not covered and should not be represented as such to an assessor.
-The embedded PostgreSQL/Redis have no FIPS variant at all. In Kubernetes the chart refuses to render if you enable FIPS alongside Sensei or the embedded datastores, so the trade-off is an explicit decision rather than an assumption (see [Guard rails](#guard-rails)).
+The embedded PostgreSQL/Redis have no FIPS variant at all. In Kubernetes the chart refuses to render if you enable FIPS alongside Sensei or the embedded datastores, so the trade-off is an explicit decision rather than an assumption; see the Kubernetes tab under [Enabling FIPS mode](#enabling-fips-mode).
-## Enabling FIPS mode — Docker Compose
-
-Two changes: use the `-fips` images, and set `DD_FIPS_MODE`.
-
-**1. Point the image tags at the FIPS variants.** In your `.env` or compose override:
-
-```bash
-DD_IMAGE_TAG=-fips
-```
-
-**2. Set `DD_FIPS_MODE` in the shared environment anchors.** The compose file defines shared blocks that every relevant service merges, so this is three edits rather than one per service:
-
-```yaml
-x-dojo-vars: &dojoenv
- DD_FIPS_MODE: "1" # dojo, dojo-import-scan, celerybeat, celeryworker, init, ddorch-workers
- # ... existing settings
-
-x-nginx-vars: &nginxenv
- DD_FIPS_MODE: "1" # nginx
- # ... existing settings
-
-x-psirt-vars: &psirtenv
- DD_FIPS_MODE: "1" # psirt
- # ... existing settings
-```
-
-Then recreate the stack:
-
-```bash
-docker compose up -d --force-recreate
-```
-
-## Enabling FIPS mode — Kubernetes (Helm)
+## Enabling FIPS mode
+{{< tabs "fips-enable" >}}
+{{< tab "Kubernetes" >}}
Set one value. The chart selects the `-fips` image variants and sets `DD_FIPS_MODE` for every pod:
```yaml
@@ -91,20 +63,16 @@ Because the embedded datastores have no FIPS variant and Sensei is only partiall
fips:
enabled: true
sensei:
- enabled: false # partial coverage — see the table above
+ enabled: false # partial coverage, see the coverage table above
postgresql:
enabled: false # use an external FIPS-compliant database
redis:
enabled: false # use an external FIPS-compliant cache
```
-If you need Sensei in a FIPS environment, enable it deliberately with
-`fips.validate: false` and document the bundled scanner toolchain as
-non-validated in your system security plan.
-
-### Guard rails
+If you need Sensei in a FIPS environment, enable it deliberately with `fips.validate: false` and document the bundled scanner toolchain as non-validated in your system security plan.
-If `fips.enabled` is true while a component without a FIPS variant is also enabled, **the chart refuses to render** and names the offenders:
+**Guard rails.** If `fips.enabled` is true while a component without a FIPS variant is also enabled, the chart refuses to render and names the offenders:
```
Error: fips.enabled is true but these services have no FIPS image variant:
@@ -114,385 +82,43 @@ run non-validated cryptography.
```
This is deliberate. A deployment where most services use validated cryptography and one or two quietly do not is worse than an obvious failure: it looks compliant, survives a casual inspection, and only surfaces during an assessment. If you have accepted that risk in writing, override it with `fips.validate: false`.
+{{< /tab >}}
+{{< tab "Compose" >}}
+Two changes: use the `-fips` images, and set `DD_FIPS_MODE`.
-## Enabling FIPS mode — Amazon ECS / Fargate
-
-Fargate is a launch type for ECS, not a separate service: you register ECS task
-definitions with `requiresCompatibilities: ["FARGATE"]` and `networkMode: awsvpc`.
-
-If you already run DefectDojo Pro on ECS, only two things change:
-
-**1. Image tags** gain the `-fips` suffix:
-
-```
-.dkr.ecr..amazonaws.com/defectdojo-pro-django:-fips
-.dkr.ecr..amazonaws.com/defectdojo-pro-nginx:-fips
-```
-
-**2. `DD_FIPS_MODE=1`** in the `environment` block of every container running
-application code — uwsgi, celery worker, celery beat, the initializer, the
-orchestration workers, nginx and psirt.
-
-The rest of this section is a complete FIPS-enabled ECS deployment for readers
-starting from nothing.
-
-### What to provision first
-
-| Resource | Notes |
-|---|---|
-| VPC with two subnets | Private subnets plus a NAT gateway, or public subnets with `assignPublicIp: ENABLED` |
-| RDS for PostgreSQL | Use a FIPS-capable endpoint and document it as an inherited component |
-| ElastiCache for Redis | Two logical databases are used: `/0` for the Celery broker, `/1` for the cache |
-| EFS file system | Two directories: one for `/app/media`, one holding the nginx TLS certificates |
-| Secrets Manager entries | Database URL, `DD_SECRET_KEY`, `DD_CREDENTIAL_AES_256_KEY`, and your Pro licence |
-| Application Load Balancer | HTTPS listener, forwarding to an **HTTPS** target group on port **8443** |
-| ECR repositories | Holding the two `-fips` images |
-| IAM roles | An execution role that can pull from ECR, write logs and read those secrets, plus a task role |
-| CloudWatch log group | Referenced by every container's `awslogs` configuration |
-
-Put the TLS certificate and key on EFS as `dojo.crt` / `dojo.key`, plus
-`nginx_int.crt` / `nginx_int.key`. Both pairs must exist — see
-[Three things ECS needs](#three-things-ecs-needs-that-compose-provides-for-free)
-below for why.
-
-### 1. The initializer task (run once per upgrade)
-
-Applies migrations and seeds first-boot data, then exits. It is a task, not a
-service.
-
-```json
-{
- "family": "defectdojo-pro-init",
- "requiresCompatibilities": ["FARGATE"],
- "networkMode": "awsvpc",
- "cpu": "1024",
- "memory": "2048",
- "executionRoleArn": "",
- "taskRoleArn": "",
- "runtimePlatform": { "cpuArchitecture": "X86_64", "operatingSystemFamily": "LINUX" },
- "containerDefinitions": [
- {
- "name": "init",
- "image": ".dkr.ecr..amazonaws.com/defectdojo-pro-django:-fips",
- "essential": true,
- "entryPoint": ["/entrypoint-initializer.sh"],
- "environment": [
- { "name": "DD_FIPS_MODE", "value": "1" },
- { "name": "DD_INITIALIZE", "value": "true" },
- { "name": "DD_ALLOWED_HOSTS", "value": "" },
- { "name": "DD_SITE_URL", "value": "https://" },
- { "name": "DD_CELERY_BROKER_URL", "value": "redis://:6379/0" },
- { "name": "DD_CACHE_URL", "value": "redis://:6379/1" },
- { "name": "DD_ADMIN_USER", "value": "admin" },
- { "name": "DD_ADMIN_MAIL", "value": "admin@example.com" }
- ],
- "secrets": [
- { "name": "DD_DATABASE_URL", "valueFrom": "" },
- { "name": "DD_SECRET_KEY", "valueFrom": "" },
- { "name": "DD_CREDENTIAL_AES_256_KEY", "valueFrom": "" },
- { "name": "DD_ADMIN_PASSWORD", "valueFrom": "" },
- { "name": "DD_LICENSE", "valueFrom": "" }
- ],
- "logConfiguration": {
- "logDriver": "awslogs",
- "options": {
- "awslogs-group": "",
- "awslogs-region": "",
- "awslogs-stream-prefix": "init"
- }
- }
- }
- ]
-}
-```
-
-```bash
-aws ecs register-task-definition --cli-input-json file://taskdef-init.json
-aws ecs run-task --cluster --launch-type FARGATE \
- --task-definition defectdojo-pro-init \
- --network-configuration "awsvpcConfiguration={subnets=[,],securityGroups=[]}"
-```
-
-Wait for it to reach `STOPPED` with exit code 0 before starting the services.
-
-### 2. The web service (nginx + uwsgi)
-
-Both containers live in one task so nginx reaches uwsgi on `127.0.0.1`.
-
-```json
-{
- "family": "defectdojo-pro-web",
- "requiresCompatibilities": ["FARGATE"],
- "networkMode": "awsvpc",
- "cpu": "2048",
- "memory": "4096",
- "executionRoleArn": "",
- "taskRoleArn": "",
- "runtimePlatform": { "cpuArchitecture": "X86_64", "operatingSystemFamily": "LINUX" },
- "volumes": [
- {
- "name": "media",
- "efsVolumeConfiguration": {
- "fileSystemId": "",
- "transitEncryption": "ENABLED",
- "rootDirectory": "/media"
- }
- },
- {
- "name": "certs",
- "efsVolumeConfiguration": {
- "fileSystemId": "",
- "transitEncryption": "ENABLED",
- "rootDirectory": "/nginx-certs"
- }
- }
- ],
- "containerDefinitions": [
- {
- "name": "uwsgi",
- "image": ".dkr.ecr..amazonaws.com/defectdojo-pro-django:-fips",
- "essential": true,
- "environment": [
- { "name": "DD_FIPS_MODE", "value": "1" },
- { "name": "DD_UWSGI_ENDPOINT", "value": "0.0.0.0:3031" },
- { "name": "DD_ALLOWED_HOSTS", "value": "" },
- { "name": "DD_SITE_URL", "value": "https://" },
- { "name": "DD_CELERY_BROKER_URL", "value": "redis://:6379/0" },
- { "name": "DD_CACHE_URL", "value": "redis://:6379/1" }
- ],
- "secrets": [
- { "name": "DD_DATABASE_URL", "valueFrom": "" },
- { "name": "DD_SECRET_KEY", "valueFrom": "" },
- { "name": "DD_CREDENTIAL_AES_256_KEY", "valueFrom": "" },
- { "name": "DD_LICENSE", "valueFrom": "" }
- ],
- "mountPoints": [{ "sourceVolume": "media", "containerPath": "/app/media" }],
- "logConfiguration": {
- "logDriver": "awslogs",
- "options": {
- "awslogs-group": "",
- "awslogs-region": "",
- "awslogs-stream-prefix": "uwsgi"
- }
- }
- },
- {
- "name": "nginx",
- "image": ".dkr.ecr..amazonaws.com/defectdojo-pro-nginx:-fips",
- "essential": true,
- "dependsOn": [{ "containerName": "uwsgi", "condition": "START" }],
- "portMappings": [{ "containerPort": 8443, "protocol": "tcp" }],
- "environment": [
- { "name": "DD_FIPS_MODE", "value": "1" },
- { "name": "USE_TLS", "value": "false" },
- { "name": "GENERATE_TLS_CERTIFICATE", "value": "false" },
- { "name": "DD_UWSGI_HOST", "value": "127.0.0.1" },
- { "name": "DD_UWSGI_PORT", "value": "3031" },
- { "name": "DD_UWSGI_IMPORT_HOST", "value": "127.0.0.1" },
- { "name": "DD_UWSGI_IMPORT_PORT", "value": "3031" },
- { "name": "DD_SITE_URL", "value": "https://" },
- { "name": "DD_MCP_HOST", "value": "127.0.0.1" },
- { "name": "DD_MCP_PORT", "value": "9142" },
- { "name": "PSIRT_ENABLED", "value": "false" },
- { "name": "NGINX_METRICS_ENABLED", "value": "false" }
- ],
- "mountPoints": [
- { "sourceVolume": "certs", "containerPath": "/etc/nginx/certs", "readOnly": true }
- ],
- "logConfiguration": {
- "logDriver": "awslogs",
- "options": {
- "awslogs-group": "",
- "awslogs-region": "",
- "awslogs-stream-prefix": "nginx"
- }
- }
- }
- ]
-}
-```
-
-`USE_TLS=false` selects the on-prem configuration, which terminates TLS itself on
-8443 using the mounted certificates. Register it and create a service attached to
-the load balancer:
+**1. Point the image tags at the FIPS variants.** In your `.env` or compose override:
```bash
-aws ecs register-task-definition --cli-input-json file://taskdef-web.json
-aws ecs create-service --cluster --service-name defectdojo-pro-web \
- --task-definition defectdojo-pro-web --launch-type FARGATE --desired-count 2 \
- --network-configuration "awsvpcConfiguration={subnets=[,],securityGroups=[]}" \
- --load-balancers "targetGroupArn=,containerName=nginx,containerPort=8443"
-```
-
-### 3. The worker service (Celery worker and beat)
-
-Same image and same secrets as uwsgi; the entry point selects the process. Run
-exactly **one** beat replica.
-
-```json
-{
- "family": "defectdojo-pro-worker",
- "requiresCompatibilities": ["FARGATE"],
- "networkMode": "awsvpc",
- "cpu": "2048",
- "memory": "4096",
- "executionRoleArn": "",
- "taskRoleArn": "",
- "runtimePlatform": { "cpuArchitecture": "X86_64", "operatingSystemFamily": "LINUX" },
- "containerDefinitions": [
- {
- "name": "celeryworker",
- "image": ".dkr.ecr..amazonaws.com/defectdojo-pro-django:-fips",
- "essential": true,
- "entryPoint": ["/entrypoint-celery-worker.sh"],
- "environment": [
- { "name": "DD_FIPS_MODE", "value": "1" },
- { "name": "DD_CELERY_BROKER_URL", "value": "redis://:6379/0" },
- { "name": "DD_CACHE_URL", "value": "redis://:6379/1" }
- ],
- "secrets": [
- { "name": "DD_DATABASE_URL", "valueFrom": "" },
- { "name": "DD_SECRET_KEY", "valueFrom": "" },
- { "name": "DD_CREDENTIAL_AES_256_KEY", "valueFrom": "" },
- { "name": "DD_LICENSE", "valueFrom": "" }
- ],
- "logConfiguration": {
- "logDriver": "awslogs",
- "options": {
- "awslogs-group": "",
- "awslogs-region": "",
- "awslogs-stream-prefix": "celeryworker"
- }
- }
- },
- {
- "name": "celerybeat",
- "image": ".dkr.ecr..amazonaws.com/defectdojo-pro-django:-fips",
- "essential": true,
- "entryPoint": ["/entrypoint-celery-beat.sh"],
- "environment": [
- { "name": "DD_FIPS_MODE", "value": "1" },
- { "name": "DD_CELERY_BROKER_URL", "value": "redis://:6379/0" },
- { "name": "DD_CACHE_URL", "value": "redis://:6379/1" }
- ],
- "secrets": [
- { "name": "DD_DATABASE_URL", "valueFrom": "" },
- { "name": "DD_SECRET_KEY", "valueFrom": "" },
- { "name": "DD_CREDENTIAL_AES_256_KEY", "valueFrom": "" },
- { "name": "DD_LICENSE", "valueFrom": "" }
- ],
- "logConfiguration": {
- "logDriver": "awslogs",
- "options": {
- "awslogs-group": "",
- "awslogs-region": "",
- "awslogs-stream-prefix": "celerybeat"
- }
- }
- }
- ]
-}
+DD_IMAGE_TAG=-fips
```
-### 4. Confirm the deployment is running validated cryptography
-
-```bash
-aws logs tail --filter-pattern FIPS
-```
+**2. Set `DD_FIPS_MODE` in the shared environment anchors.** The compose file defines shared blocks that every relevant service merges, so this is three edits rather than one per service:
-Every container should report the module before it serves anything:
+```yaml
+x-dojo-vars: &dojoenv
+ DD_FIPS_MODE: "1" # dojo, dojo-import-scan, celerybeat, celeryworker, init, ddorch-workers
+ # ... existing settings
-```
-[FIPS] MODE: ACTIVE
-[FIPS] Module: OpenSSL FIPS Provider 3.1.2 (CMVP #4985, FIPS 140-3)
-[FIPS] Non-approved algorithms (MD5-as-security, ChaCha20): blocked
-```
+x-nginx-vars: &nginxenv
+ DD_FIPS_MODE: "1" # nginx
+ # ... existing settings
-If a container is missing from that output it never started, because the check
-fails closed — look at its log stream for the reason.
-
-### Three things ECS needs that Compose provides for free
-
-Docker Compose gives you a host filesystem to bind-mount from and DNS for
-container names. Fargate provides neither, and each gap prevents nginx from
-starting rather than degrading quietly.
-
-**1. TLS certificates must exist before nginx starts.** nginx validates every
-`ssl_certificate` at config load, and the on-prem configuration has no
-certificate-free path: port 8080 only issues a `301` to HTTPS, so the 8443 TLS
-listener is the functional one. Mount an **EFS** volume at `/etc/nginx/certs`
-containing `dojo.crt` / `dojo.key` and `nginx_int.crt` / `nginx_int.key`. Both
-pairs must be present even if you only use one listener.
-
-Alternatively set `USE_TLS=true`, which serves the upstream `nginx_TLS.conf` and
-lets `GENERATE_TLS_CERTIFICATE=true` have the entrypoint generate its own
-certificate. That configuration proxies every path to Django and does not serve
-the Vue UI from `/ui`, so it suits an API-only or strictly behind-ALB deployment.
-
-**2. `DD_MCP_HOST` must resolve.** nginx resolves `proxy_pass` hostnames at
-config load. The default `mcp-server` resolves under Compose (container name) and
-Helm (Service name), but `awsvpc` gives containers no DNS names of their own and
-rejects both `extraHosts` and `dnsSearchDomains`:
-
-```json
-{
- "environment": [
- { "name": "DD_MCP_HOST", "value": "127.0.0.1" },
- { "name": "DD_MCP_PORT", "value": "9142" }
- ]
-}
+x-psirt-vars: &psirtenv
+ DD_FIPS_MODE: "1" # psirt
+ # ... existing settings
```
-Pointing it at loopback when the MCP server is not deployed makes `/mcp` answer
-`502` rather than preventing the whole web tier from starting.
-
-**3. The nginx configuration files come from the image.** The `-fips` nginx image
-bakes the on-prem configuration set in, so no mounts are needed. Compose overlays
-its own bind mounts, so Compose behaviour is unchanged.
-
-### Other Fargate specifics
-
-- **Persistent storage must be EFS.** Fargate cannot attach EBS, so the media
- directory (`/app/media`) needs an EFS volume if you retain uploaded scan files.
-- **No privileged containers or host networking are required.** The images run
- as a non-root user, and `awsvpc` gives each task its own network interface.
-- **nginx → uwsgi.** Containers in the *same* task share a network namespace, so
- co-locating nginx with uwsgi lets nginx reach it on `127.0.0.1` — the simplest
- correct option. If you split them into separate ECS services, point
- `DD_UWSGI_HOST` at a Cloud Map service-discovery name and open the security
- group on the uwsgi port.
-- **Do not override the uwsgi entrypoint.** Set
- `DD_UWSGI_ENDPOINT=0.0.0.0:3031` and leave the image ENTRYPOINT in place;
- uwsgi speaks the uwsgi protocol, which is what nginx expects. Replacing the
- entrypoint with `uwsgi --http` skips the FIPS startup check along with it.
-- **The initializer is a one-shot task**, not a service. Run it with
- `aws ecs run-task` (or as a pre-deploy step) and let it exit; do not give it a
- desired count.
-- **`healthCheck.retries` cannot exceed 10.** Higher values are rejected when
- the task definition is registered.
-- **Point the load balancer at 8443** with an HTTPS target group. The on-prem
- configuration's 8080 listener only redirects to HTTPS, so targeting 8080 loops.
- A self-signed certificate on the target is acceptable to an ALB.
-- **TLS termination.** If the ALB terminates TLS for clients, document the load
- balancer's own FIPS posture separately in your SSP.
-- **Secrets** belong in Secrets Manager or SSM Parameter Store through the
- `secrets` block, never in `environment`. That includes `DD_LICENSE`.
-
-### Retrieving evidence on ECS
-
-The startup evidence block lands in the log group named by the container's
-`awslogs` configuration:
+Then recreate the stack:
```bash
-aws logs tail /ecs/ --filter-pattern FIPS
+docker compose up -d --force-recreate
```
+{{< /tab >}}
+{{< /tabs >}}
-On demand inside a running task (requires `enableExecuteCommand` on the service):
+## Running on Amazon ECS / Fargate
-```bash
-aws ecs execute-command --cluster --task \
- --container uwsgi --interactive --command "python3 /verify_fips.py"
-```
+FIPS on Amazon ECS with the Fargate launch type is covered on its own page: see [FIPS 140-3 Mode on Amazon ECS / Fargate](/get_started/pro/onprem/fips_on_ecs_fargate/).
## Fail-closed startup
@@ -520,32 +146,38 @@ Providers:
Retrieve it with:
+{{< tabs "fips-verify-logs" >}}
+{{< tab "Kubernetes" >}}
```bash
-# Docker Compose
-docker compose logs dojo | grep FIPS
-
-# Kubernetes
kubectl logs deploy/dojopro-django | grep FIPS
```
+{{< /tab >}}
+{{< tab "Compose" >}}
+```bash
+docker compose logs dojo | grep FIPS
+```
+{{< /tab >}}
+{{< /tabs >}}
You can also verify on demand inside a running container:
+{{< tabs "fips-verify-exec" >}}
+{{< tab "Kubernetes" >}}
```bash
-# Docker Compose
-docker compose exec dojo openssl list -providers # fips provider, 3.1.2, active
-docker compose exec dojo openssl md5 /dev/null # expected to FAIL
-docker compose exec dojo python3 /verify_fips.py # full check
-
-# Kubernetes
kubectl exec deploy/dojopro-django -- openssl list -providers
kubectl exec deploy/dojopro-django -- python3 /verify_fips.py
```
-
-For Go services, FIPS mode is compiled in and reported by the Go runtime:
-
+{{< /tab >}}
+{{< tab "Compose" >}}
```bash
-kubectl exec deploy/dojopro-connectors -- printenv GODEBUG # fips140=on
+docker compose exec dojo openssl list -providers # fips provider, 3.1.2, active
+docker compose exec dojo openssl md5 /dev/null # expected to FAIL
+docker compose exec dojo python3 /verify_fips.py # full check
```
+{{< /tab >}}
+{{< /tabs >}}
+
+For Go services (connectors, integrators, ddorch, MCP server), FIPS mode is compiled in and reported by the Go runtime as `GODEBUG=fips140=on`. Check it on a running service with `kubectl exec` on Kubernetes or `docker compose exec` on Docker Compose, for example `printenv GODEBUG`.
## Behaviour differences in FIPS mode
diff --git a/docs/content/get_started/pro/onprem/fips_mode.pt-br.md b/docs/content/get_started/pro/onprem/fips_mode.pt-br.md
index 0866b916911..78737aebfb0 100644
--- a/docs/content/get_started/pro/onprem/fips_mode.pt-br.md
+++ b/docs/content/get_started/pro/onprem/fips_mode.pt-br.md
@@ -1,7 +1,7 @@
---
title: Modo FIPS 140-3
date: 2026-07-27 00:00:00+00:00
-weight: 6
+weight: 7
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/fips_mode.zh-hans.md b/docs/content/get_started/pro/onprem/fips_mode.zh-hans.md
index 329274b7253..cb817f60147 100644
--- a/docs/content/get_started/pro/onprem/fips_mode.zh-hans.md
+++ b/docs/content/get_started/pro/onprem/fips_mode.zh-hans.md
@@ -1,7 +1,7 @@
---
title: FIPS 140-3 模式
date: 2026-07-27 00:00:00+00:00
-weight: 6
+weight: 7
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/fips_on_ecs_fargate.md b/docs/content/get_started/pro/onprem/fips_on_ecs_fargate.md
new file mode 100644
index 00000000000..5ecef1fd9fe
--- /dev/null
+++ b/docs/content/get_started/pro/onprem/fips_on_ecs_fargate.md
@@ -0,0 +1,386 @@
+---
+title: "FIPS 140-3 Mode on Amazon ECS / Fargate"
+description: "Running DefectDojo Pro FIPS images on Amazon ECS with the Fargate launch type"
+draft: false
+weight: 8
+audience: pro
+---
+
+This page covers running the DefectDojo Pro FIPS images on Amazon ECS with the Fargate launch type. For what FIPS mode is, what the images cover, and the behaviour differences that apply to every deployment, see [FIPS 140-3 Mode](/get_started/pro/onprem/fips_mode/).
+
+Fargate is a launch type for ECS, not a separate service: you register ECS task
+definitions with `requiresCompatibilities: ["FARGATE"]` and `networkMode: awsvpc`.
+
+If you already run DefectDojo Pro on ECS, only two things change:
+
+**1. Image tags** gain the `-fips` suffix:
+
+```
+.dkr.ecr..amazonaws.com/defectdojo-pro-django:-fips
+.dkr.ecr..amazonaws.com/defectdojo-pro-nginx:-fips
+```
+
+**2. `DD_FIPS_MODE=1`** in the `environment` block of every container running
+application code — uwsgi, celery worker, celery beat, the initializer, the
+orchestration workers, nginx and psirt.
+
+The rest of this section is a complete FIPS-enabled ECS deployment for readers
+starting from nothing.
+
+### What to provision first
+
+| Resource | Notes |
+|---|---|
+| VPC with two subnets | Private subnets plus a NAT gateway, or public subnets with `assignPublicIp: ENABLED` |
+| RDS for PostgreSQL | Use a FIPS-capable endpoint and document it as an inherited component |
+| ElastiCache for Redis | Two logical databases are used: `/0` for the Celery broker, `/1` for the cache |
+| EFS file system | Two directories: one for `/app/media`, one holding the nginx TLS certificates |
+| Secrets Manager entries | Database URL, `DD_SECRET_KEY`, `DD_CREDENTIAL_AES_256_KEY`, and your Pro licence |
+| Application Load Balancer | HTTPS listener, forwarding to an **HTTPS** target group on port **8443** |
+| ECR repositories | Holding the two `-fips` images |
+| IAM roles | An execution role that can pull from ECR, write logs and read those secrets, plus a task role |
+| CloudWatch log group | Referenced by every container's `awslogs` configuration |
+
+Put the TLS certificate and key on EFS as `dojo.crt` / `dojo.key`, plus
+`nginx_int.crt` / `nginx_int.key`. Both pairs must exist — see
+[Three things ECS needs](#three-things-ecs-needs-that-compose-provides-for-free)
+below for why.
+
+### 1. The initializer task (run once per upgrade)
+
+Applies migrations and seeds first-boot data, then exits. It is a task, not a
+service.
+
+```json
+{
+ "family": "defectdojo-pro-init",
+ "requiresCompatibilities": ["FARGATE"],
+ "networkMode": "awsvpc",
+ "cpu": "1024",
+ "memory": "2048",
+ "executionRoleArn": "",
+ "taskRoleArn": "",
+ "runtimePlatform": { "cpuArchitecture": "X86_64", "operatingSystemFamily": "LINUX" },
+ "containerDefinitions": [
+ {
+ "name": "init",
+ "image": ".dkr.ecr..amazonaws.com/defectdojo-pro-django:-fips",
+ "essential": true,
+ "entryPoint": ["/entrypoint-initializer.sh"],
+ "environment": [
+ { "name": "DD_FIPS_MODE", "value": "1" },
+ { "name": "DD_INITIALIZE", "value": "true" },
+ { "name": "DD_ALLOWED_HOSTS", "value": "" },
+ { "name": "DD_SITE_URL", "value": "https://" },
+ { "name": "DD_CELERY_BROKER_URL", "value": "redis://:6379/0" },
+ { "name": "DD_CACHE_URL", "value": "redis://:6379/1" },
+ { "name": "DD_ADMIN_USER", "value": "admin" },
+ { "name": "DD_ADMIN_MAIL", "value": "admin@example.com" }
+ ],
+ "secrets": [
+ { "name": "DD_DATABASE_URL", "valueFrom": "" },
+ { "name": "DD_SECRET_KEY", "valueFrom": "" },
+ { "name": "DD_CREDENTIAL_AES_256_KEY", "valueFrom": "" },
+ { "name": "DD_ADMIN_PASSWORD", "valueFrom": "" },
+ { "name": "DD_LICENSE", "valueFrom": "" }
+ ],
+ "logConfiguration": {
+ "logDriver": "awslogs",
+ "options": {
+ "awslogs-group": "",
+ "awslogs-region": "",
+ "awslogs-stream-prefix": "init"
+ }
+ }
+ }
+ ]
+}
+```
+
+```bash
+aws ecs register-task-definition --cli-input-json file://taskdef-init.json
+aws ecs run-task --cluster --launch-type FARGATE \
+ --task-definition defectdojo-pro-init \
+ --network-configuration "awsvpcConfiguration={subnets=[,],securityGroups=[]}"
+```
+
+Wait for it to reach `STOPPED` with exit code 0 before starting the services.
+
+### 2. The web service (nginx + uwsgi)
+
+Both containers live in one task so nginx reaches uwsgi on `127.0.0.1`.
+
+```json
+{
+ "family": "defectdojo-pro-web",
+ "requiresCompatibilities": ["FARGATE"],
+ "networkMode": "awsvpc",
+ "cpu": "2048",
+ "memory": "4096",
+ "executionRoleArn": "",
+ "taskRoleArn": "",
+ "runtimePlatform": { "cpuArchitecture": "X86_64", "operatingSystemFamily": "LINUX" },
+ "volumes": [
+ {
+ "name": "media",
+ "efsVolumeConfiguration": {
+ "fileSystemId": "",
+ "transitEncryption": "ENABLED",
+ "rootDirectory": "/media"
+ }
+ },
+ {
+ "name": "certs",
+ "efsVolumeConfiguration": {
+ "fileSystemId": "",
+ "transitEncryption": "ENABLED",
+ "rootDirectory": "/nginx-certs"
+ }
+ }
+ ],
+ "containerDefinitions": [
+ {
+ "name": "uwsgi",
+ "image": ".dkr.ecr..amazonaws.com/defectdojo-pro-django:-fips",
+ "essential": true,
+ "environment": [
+ { "name": "DD_FIPS_MODE", "value": "1" },
+ { "name": "DD_UWSGI_ENDPOINT", "value": "0.0.0.0:3031" },
+ { "name": "DD_ALLOWED_HOSTS", "value": "" },
+ { "name": "DD_SITE_URL", "value": "https://" },
+ { "name": "DD_CELERY_BROKER_URL", "value": "redis://:6379/0" },
+ { "name": "DD_CACHE_URL", "value": "redis://:6379/1" }
+ ],
+ "secrets": [
+ { "name": "DD_DATABASE_URL", "valueFrom": "" },
+ { "name": "DD_SECRET_KEY", "valueFrom": "" },
+ { "name": "DD_CREDENTIAL_AES_256_KEY", "valueFrom": "" },
+ { "name": "DD_LICENSE", "valueFrom": "" }
+ ],
+ "mountPoints": [{ "sourceVolume": "media", "containerPath": "/app/media" }],
+ "logConfiguration": {
+ "logDriver": "awslogs",
+ "options": {
+ "awslogs-group": "",
+ "awslogs-region": "",
+ "awslogs-stream-prefix": "uwsgi"
+ }
+ }
+ },
+ {
+ "name": "nginx",
+ "image": ".dkr.ecr..amazonaws.com/defectdojo-pro-nginx:-fips",
+ "essential": true,
+ "dependsOn": [{ "containerName": "uwsgi", "condition": "START" }],
+ "portMappings": [{ "containerPort": 8443, "protocol": "tcp" }],
+ "environment": [
+ { "name": "DD_FIPS_MODE", "value": "1" },
+ { "name": "USE_TLS", "value": "false" },
+ { "name": "GENERATE_TLS_CERTIFICATE", "value": "false" },
+ { "name": "DD_UWSGI_HOST", "value": "127.0.0.1" },
+ { "name": "DD_UWSGI_PORT", "value": "3031" },
+ { "name": "DD_UWSGI_IMPORT_HOST", "value": "127.0.0.1" },
+ { "name": "DD_UWSGI_IMPORT_PORT", "value": "3031" },
+ { "name": "DD_SITE_URL", "value": "https://" },
+ { "name": "DD_MCP_HOST", "value": "127.0.0.1" },
+ { "name": "DD_MCP_PORT", "value": "9142" },
+ { "name": "PSIRT_ENABLED", "value": "false" },
+ { "name": "NGINX_METRICS_ENABLED", "value": "false" }
+ ],
+ "mountPoints": [
+ { "sourceVolume": "certs", "containerPath": "/etc/nginx/certs", "readOnly": true }
+ ],
+ "logConfiguration": {
+ "logDriver": "awslogs",
+ "options": {
+ "awslogs-group": "",
+ "awslogs-region": "",
+ "awslogs-stream-prefix": "nginx"
+ }
+ }
+ }
+ ]
+}
+```
+
+`USE_TLS=false` selects the on-prem configuration, which terminates TLS itself on
+8443 using the mounted certificates. Register it and create a service attached to
+the load balancer:
+
+```bash
+aws ecs register-task-definition --cli-input-json file://taskdef-web.json
+aws ecs create-service --cluster --service-name defectdojo-pro-web \
+ --task-definition defectdojo-pro-web --launch-type FARGATE --desired-count 2 \
+ --network-configuration "awsvpcConfiguration={subnets=[,],securityGroups=[]}" \
+ --load-balancers "targetGroupArn=,containerName=nginx,containerPort=8443"
+```
+
+### 3. The worker service (Celery worker and beat)
+
+Same image and same secrets as uwsgi; the entry point selects the process. Run
+exactly **one** beat replica.
+
+```json
+{
+ "family": "defectdojo-pro-worker",
+ "requiresCompatibilities": ["FARGATE"],
+ "networkMode": "awsvpc",
+ "cpu": "2048",
+ "memory": "4096",
+ "executionRoleArn": "",
+ "taskRoleArn": "",
+ "runtimePlatform": { "cpuArchitecture": "X86_64", "operatingSystemFamily": "LINUX" },
+ "containerDefinitions": [
+ {
+ "name": "celeryworker",
+ "image": ".dkr.ecr..amazonaws.com/defectdojo-pro-django:-fips",
+ "essential": true,
+ "entryPoint": ["/entrypoint-celery-worker.sh"],
+ "environment": [
+ { "name": "DD_FIPS_MODE", "value": "1" },
+ { "name": "DD_CELERY_BROKER_URL", "value": "redis://:6379/0" },
+ { "name": "DD_CACHE_URL", "value": "redis://:6379/1" }
+ ],
+ "secrets": [
+ { "name": "DD_DATABASE_URL", "valueFrom": "" },
+ { "name": "DD_SECRET_KEY", "valueFrom": "" },
+ { "name": "DD_CREDENTIAL_AES_256_KEY", "valueFrom": "" },
+ { "name": "DD_LICENSE", "valueFrom": "" }
+ ],
+ "logConfiguration": {
+ "logDriver": "awslogs",
+ "options": {
+ "awslogs-group": "",
+ "awslogs-region": "",
+ "awslogs-stream-prefix": "celeryworker"
+ }
+ }
+ },
+ {
+ "name": "celerybeat",
+ "image": ".dkr.ecr..amazonaws.com/defectdojo-pro-django:-fips",
+ "essential": true,
+ "entryPoint": ["/entrypoint-celery-beat.sh"],
+ "environment": [
+ { "name": "DD_FIPS_MODE", "value": "1" },
+ { "name": "DD_CELERY_BROKER_URL", "value": "redis://:6379/0" },
+ { "name": "DD_CACHE_URL", "value": "redis://:6379/1" }
+ ],
+ "secrets": [
+ { "name": "DD_DATABASE_URL", "valueFrom": "" },
+ { "name": "DD_SECRET_KEY", "valueFrom": "" },
+ { "name": "DD_CREDENTIAL_AES_256_KEY", "valueFrom": "" },
+ { "name": "DD_LICENSE", "valueFrom": "" }
+ ],
+ "logConfiguration": {
+ "logDriver": "awslogs",
+ "options": {
+ "awslogs-group": "",
+ "awslogs-region": "",
+ "awslogs-stream-prefix": "celerybeat"
+ }
+ }
+ }
+ ]
+}
+```
+
+### 4. Confirm the deployment is running validated cryptography
+
+```bash
+aws logs tail --filter-pattern FIPS
+```
+
+Every container should report the module before it serves anything:
+
+```
+[FIPS] MODE: ACTIVE
+[FIPS] Module: OpenSSL FIPS Provider 3.1.2 (CMVP #4985, FIPS 140-3)
+[FIPS] Non-approved algorithms (MD5-as-security, ChaCha20): blocked
+```
+
+If a container is missing from that output it never started, because the check
+fails closed — look at its log stream for the reason.
+
+### Three things ECS needs that Compose provides for free
+
+Docker Compose gives you a host filesystem to bind-mount from and DNS for
+container names. Fargate provides neither, and each gap prevents nginx from
+starting rather than degrading quietly.
+
+**1. TLS certificates must exist before nginx starts.** nginx validates every
+`ssl_certificate` at config load, and the on-prem configuration has no
+certificate-free path: port 8080 only issues a `301` to HTTPS, so the 8443 TLS
+listener is the functional one. Mount an **EFS** volume at `/etc/nginx/certs`
+containing `dojo.crt` / `dojo.key` and `nginx_int.crt` / `nginx_int.key`. Both
+pairs must be present even if you only use one listener.
+
+Alternatively set `USE_TLS=true`, which serves the upstream `nginx_TLS.conf` and
+lets `GENERATE_TLS_CERTIFICATE=true` have the entrypoint generate its own
+certificate. That configuration proxies every path to Django and does not serve
+the Vue UI from `/ui`, so it suits an API-only or strictly behind-ALB deployment.
+
+**2. `DD_MCP_HOST` must resolve.** nginx resolves `proxy_pass` hostnames at
+config load. The default `mcp-server` resolves under Compose (container name) and
+Helm (Service name), but `awsvpc` gives containers no DNS names of their own and
+rejects both `extraHosts` and `dnsSearchDomains`:
+
+```json
+{
+ "environment": [
+ { "name": "DD_MCP_HOST", "value": "127.0.0.1" },
+ { "name": "DD_MCP_PORT", "value": "9142" }
+ ]
+}
+```
+
+Pointing it at loopback when the MCP server is not deployed makes `/mcp` answer
+`502` rather than preventing the whole web tier from starting.
+
+**3. The nginx configuration files come from the image.** The `-fips` nginx image
+bakes the on-prem configuration set in, so no mounts are needed. Compose overlays
+its own bind mounts, so Compose behaviour is unchanged.
+
+### Other Fargate specifics
+
+- **Persistent storage must be EFS.** Fargate cannot attach EBS, so the media
+ directory (`/app/media`) needs an EFS volume if you retain uploaded scan files.
+- **No privileged containers or host networking are required.** The images run
+ as a non-root user, and `awsvpc` gives each task its own network interface.
+- **nginx → uwsgi.** Containers in the *same* task share a network namespace, so
+ co-locating nginx with uwsgi lets nginx reach it on `127.0.0.1` — the simplest
+ correct option. If you split them into separate ECS services, point
+ `DD_UWSGI_HOST` at a Cloud Map service-discovery name and open the security
+ group on the uwsgi port.
+- **Do not override the uwsgi entrypoint.** Set
+ `DD_UWSGI_ENDPOINT=0.0.0.0:3031` and leave the image ENTRYPOINT in place;
+ uwsgi speaks the uwsgi protocol, which is what nginx expects. Replacing the
+ entrypoint with `uwsgi --http` skips the FIPS startup check along with it.
+- **The initializer is a one-shot task**, not a service. Run it with
+ `aws ecs run-task` (or as a pre-deploy step) and let it exit; do not give it a
+ desired count.
+- **`healthCheck.retries` cannot exceed 10.** Higher values are rejected when
+ the task definition is registered.
+- **Point the load balancer at 8443** with an HTTPS target group. The on-prem
+ configuration's 8080 listener only redirects to HTTPS, so targeting 8080 loops.
+ A self-signed certificate on the target is acceptable to an ALB.
+- **TLS termination.** If the ALB terminates TLS for clients, document the load
+ balancer's own FIPS posture separately in your SSP.
+- **Secrets** belong in Secrets Manager or SSM Parameter Store through the
+ `secrets` block, never in `environment`. That includes `DD_LICENSE`.
+
+### Retrieving evidence on ECS
+
+The startup evidence block lands in the log group named by the container's
+`awslogs` configuration:
+
+```bash
+aws logs tail /ecs/ --filter-pattern FIPS
+```
+
+On demand inside a running task (requires `enableExecuteCommand` on the service):
+
+```bash
+aws ecs execute-command --cluster --task \
+ --container uwsgi --interactive --command "python3 /verify_fips.py"
+```
diff --git a/docs/content/onprem_deployment/forward_proxy.md b/docs/content/get_started/pro/onprem/forward_proxy.md
similarity index 88%
rename from docs/content/onprem_deployment/forward_proxy.md
rename to docs/content/get_started/pro/onprem/forward_proxy.md
index a6c5803e2e4..bb8361d08e0 100644
--- a/docs/content/onprem_deployment/forward_proxy.md
+++ b/docs/content/get_started/pro/onprem/forward_proxy.md
@@ -1,8 +1,11 @@
---
title: "Running DefectDojo Behind a Forward HTTPS Proxy"
description: "Configure DefectDojo Pro on-prem to reach Jira, SonarQube, and Connectors through an outbound HTTPS proxy"
+draft: false
+weight: 6
audience: pro
-weight: 5
+aliases:
+ - /onprem_deployment/forward_proxy/
---
If your DefectDojo Pro on-prem deployment cannot make direct outbound connections to the internet — for example, because firewall rules require all egress to go through a forward HTTPS proxy — you can configure the standard `HTTPS_PROXY`, `HTTP_PROXY`, and `NO_PROXY` environment variables. DefectDojo will route its outbound calls through the proxy accordingly.
@@ -41,7 +44,7 @@ Once the stack is restarted:
If outbound calls fail with TLS errors after configuring the proxy, the most common causes are:
-- The proxy's TLS certificate is not trusted by the container. You may need to inject a CA bundle into the containers depending on your proxy's TLS configuration.
+- The proxy's TLS certificate is not trusted by the container. If the proxy (or any upstream service) presents a certificate signed by an internal or private CA, add that CA to the containers' trust store. On Docker Compose, see [Trusting an internal or private CA](/get_started/pro/onprem/docker_compose/installing_on_docker_compose/#trusting-an-internal-or-private-ca); on Kubernetes, see [Trusting an internal or private CA](/get_started/pro/onprem/kubernetes/installing_on_kubernetes/#trusting-an-internal-or-private-ca).
- `NO_PROXY` is not configured for internal hosts, so DefectDojo is trying to reach internal services *through* the proxy and failing.
## Known limitation: inbound Jira webhooks
diff --git a/docs/content/get_started/pro/onprem/hardware_sizing.de.md b/docs/content/get_started/pro/onprem/hardware_sizing.de.md
index b2fe54d2608..f6240d43587 100644
--- a/docs/content/get_started/pro/onprem/hardware_sizing.de.md
+++ b/docs/content/get_started/pro/onprem/hardware_sizing.de.md
@@ -3,7 +3,7 @@ title: Hardware-Dimensionierung für selbst gehostetes DefectDojo Pro
description: Allgemeine Anleitung zur Dimensionierung von Rechenleistung, Arbeitsspeicher
und Speicherplatz für eine selbst gehostete DefectDojo-Pro-Bereitstellung
draft: false
-weight: 4
+weight: 2
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/hardware_sizing.es.md b/docs/content/get_started/pro/onprem/hardware_sizing.es.md
index ac555aedc6c..6d61da8eec1 100644
--- a/docs/content/get_started/pro/onprem/hardware_sizing.es.md
+++ b/docs/content/get_started/pro/onprem/hardware_sizing.es.md
@@ -3,7 +3,7 @@ title: Dimensionamiento de hardware para DefectDojo Pro autoalojado
description: Orientación general para dimensionar cómputo, memoria y almacenamiento
para un despliegue autoalojado de DefectDojo Pro
draft: false
-weight: 4
+weight: 2
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/hardware_sizing.fr.md b/docs/content/get_started/pro/onprem/hardware_sizing.fr.md
index 20aec851756..82b0d2c09c0 100644
--- a/docs/content/get_started/pro/onprem/hardware_sizing.fr.md
+++ b/docs/content/get_started/pro/onprem/hardware_sizing.fr.md
@@ -3,7 +3,7 @@ title: Dimensionnement matériel pour DefectDojo Pro auto-hébergé
description: Recommandations générales pour dimensionner le calcul, la mémoire et
le stockage d'un déploiement DefectDojo Pro auto-hébergé
draft: false
-weight: 4
+weight: 2
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/hardware_sizing.it.md b/docs/content/get_started/pro/onprem/hardware_sizing.it.md
index fb98e709a84..ab048b82b04 100644
--- a/docs/content/get_started/pro/onprem/hardware_sizing.it.md
+++ b/docs/content/get_started/pro/onprem/hardware_sizing.it.md
@@ -3,7 +3,7 @@ title: Dimensionamento hardware per DefectDojo Pro self-hosted
description: Linee guida generali per dimensionare risorse di calcolo, memoria e storage
per una distribuzione self-hosted di DefectDojo Pro
draft: false
-weight: 4
+weight: 2
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/hardware_sizing.ja.md b/docs/content/get_started/pro/onprem/hardware_sizing.ja.md
index 7649e53617a..0a7de1152ff 100644
--- a/docs/content/get_started/pro/onprem/hardware_sizing.ja.md
+++ b/docs/content/get_started/pro/onprem/hardware_sizing.ja.md
@@ -2,7 +2,7 @@
title: セルフホスト型 DefectDojo Pro のハードウェアサイジング
description: セルフホスト型 DefectDojo Pro デプロイのコンピュート、メモリ、ストレージをサイジングするための一般的なガイダンス
draft: false
-weight: 4
+weight: 2
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/hardware_sizing.md b/docs/content/get_started/pro/onprem/hardware_sizing.md
index e981da6984e..ba0b9eb923b 100644
--- a/docs/content/get_started/pro/onprem/hardware_sizing.md
+++ b/docs/content/get_started/pro/onprem/hardware_sizing.md
@@ -2,7 +2,7 @@
title: "Hardware Sizing for Self-Hosted DefectDojo Pro"
description: "General guidance for sizing compute, memory, and storage for a self-hosted DefectDojo Pro deployment"
draft: false
-weight: 4
+weight: 2
audience: pro
---
@@ -10,10 +10,12 @@ Sizing a DefectDojo deployment comes down to two questions. How much data are yo
Treat what follows as general guidance rather than a specification. The figures lean deliberately conservative, and they assume a deployment doing everyday triage alongside regular scan imports. Your own numbers will move depending on how you use the Asset, so read the notes under the table before you provision anything.
-Specs are given as generic vCPU and memory figures so they apply to any cloud provider or on-premise hardware. The application node guidance assumes Kubernetes. If you run Docker Compose on a single host, use the same totals.
+Specs are given as generic vCPU and memory figures so they apply to any cloud provider or on-premise hardware. The sizing table has a tab for each deployment method: Kubernetes runs the application tier as pods across nodes and scales out, while Docker Compose runs everything on one host and scales up. Whichever you choose, read [Sizing and tuning the application tier](#sizing-and-tuning-the-application-tier) too, where the two differ most.
## Sizing table
+{{< tabs "sizing-table" >}}
+{{< tab "Kubernetes" >}}
| Findings | Concurrent users | Database | Application nodes |
| --- | --- | --- | --- |
| Up to 100K | Up to ~25 | 2–4 vCPU / 16–32 GB | 2 × (2–4 vCPU / 8–16 GB) |
@@ -26,6 +28,21 @@ Specs are given as generic vCPU and memory figures so they apply to any cloud pr
Where you land inside a range depends on your workload. Start at the upper end of a range if anything in [What pushes you up a tier](#what-pushes-you-up-a-tier) applies to you.
The 500M row is a reference point at the far end rather than a continuation of the pattern above it, so do not interpolate between it and the 10M tier. A deployment sitting between those two needs to be sized individually. It also assumes work that hardware alone will not do for you, covered in [Very large deployments](#very-large-deployments).
+{{< /tab >}}
+{{< tab "Compose" >}}
+Docker Compose runs everything on one host, so this is the Kubernetes guidance consolidated onto a single machine: the "Application host" figure is the Kubernetes application-tier total run as one instance instead of spread across pods, and the database column is unchanged. Provision the host to match your finding count, then tune the application to use it (see [Sizing and tuning the application tier](#sizing-and-tuning-the-application-tier)).
+
+| Findings | Concurrent users | Application host (CPU / RAM) | Database (CPU / RAM) |
+| --- | --- | --- | --- |
+| Up to 100K | Up to ~25 | 4–8 vCPU / 16–32 GB | 2–4 vCPU / 16–32 GB |
+| 100K–500K | ~25–50 | 8–12 vCPU / 32–48 GB | 4–8 vCPU / 32–64 GB |
+| 500K–1M | ~50–100 | 16–24 vCPU / 64–96 GB | 8 vCPU / 64–96 GB |
+| 1M–5M | ~100–250 | 40–48 vCPU / 160–192 GB | 8–16 vCPU / 96–128 GB |
+| 5M–10M | ~250–500 | 72–80 vCPU / 288–320 GB | 16–32 vCPU / 128–192 GB |
+
+A single host has no redundancy and scales only by getting bigger. The compute at the larger tiers gets impractical to put on one machine, so toward the top of this range Kubernetes is usually the better fit, both for horizontal scale and for surviving the loss of a node. The database figures assume a separate database host, which we recommend for production; if you run the database in a container on the same host (evaluation only, not production data), add its CPU and memory to the host's.
+{{< /tab >}}
+{{< /tabs >}}
## How to read these numbers
@@ -33,15 +50,74 @@ The 500M row is a reference point at the far end rather than a continuation of t
DefectDojo runs aggregation-heavy queries across your findings. Those stay fast while the working set and its indexes are served from memory, and they degrade quickly once the database starts reaching for disk. When you have to choose, buy memory before you buy cores. The table reflects that. Memory roughly doubles from tier to tier while CPU counts move much more slowly.
-### Application nodes track users, not findings
+### The application tier tracks users, not findings
+
+The concurrent user figures in the table assume smaller datasets belong to smaller teams. That assumption breaks often. If you hold 200K findings but have 100 people in the UI at once, size the application tier for the users and leave the database where your finding count puts it. The two scale independently.
+
+There is one exception, at the far end of the table. Import and deduplication run on the application tier rather than in the database, so once a data set is large enough for that work to dominate, the application tier follows ingest volume instead of user count. That is why the 500M row sits well above what its user figure on its own would suggest.
+
+### Sizing and tuning the application tier
+
+The "Application nodes" column is the compute the application tier needs. How you provide it, and what you have to do to make the application actually use it, is where the two deployment methods differ.
+
+{{< tabs "sizing-app-tier" >}}
+{{< tab "Kubernetes" >}}
+The Helm chart runs the application tier as pods and sets the uWSGI and Celery concurrency for you from your values, so on Kubernetes you provide the capacity and let the chart place pods on it. Kubernetes spreads the load whether you give it a few large nodes or more small ones, so the node counts in the table are one workable arrangement rather than a requirement. Two things are worth holding to: keep at least two nodes so losing one doesn't take the application down, and avoid nodes smaller than 2 vCPU / 8 GB so individual pods schedule comfortably.
+{{< /tab >}}
+{{< tab "Compose" >}}
+On a single host there are no pods to schedule or nodes to spread across, so read the "Application nodes" column as one total: add the per-node figures together and provision that much CPU and memory on the one machine. Compute-optimized hardware for that host is worth choosing when your provider offers it. A single host has no redundancy, so treat losing it as downtime and keep a tested backup and a restore plan.
+
+Sizing the host is only half of it. The application does not reach for extra cores on its own: the uWSGI web processes and the Celery workers run at fixed counts until you raise them. After you resize the host, tune these and restart.
+
+Scale with **processes, not threads.** uWSGI threads do not run Python in parallel — the GIL lets only one thread per process execute at a time — so past a handful they mostly consume database connections and add context-switching overhead instead of throughput. Keep threads low and add processes as the lever:
+
+```bash
+dojo-compose-cli environment add --key "DD_UWSGI_NUM_OF_THREADS" --value "4"
+dojo-compose-cli environment add --key "DD_UWSGI_NUM_OF_PROCESSES" --value "<1–1.5× the host's CPU count, then tune>"
+dojo-compose-cli environment add --key "DD_CELERY_WORKER_CONCURRENCY" --value ""
+dojo-compose-cli environment add --key "DD_CELERY_WORKER_AUTOSCALE_MAX" --value ""
+
+dojo-compose-cli environment print # confirm the values
+dojo-compose-cli app stop
+dojo-compose-cli app start
+```
+
+What each knob does:
+
+| Knob | Start at | What raising it does |
+| --- | --- | --- |
+| `DD_UWSGI_NUM_OF_PROCESSES` | 1–1.5× host vCPU | The main throughput lever. More web processes serve more requests at once, until they saturate CPU or outrun the database's connections. |
+| `DD_UWSGI_NUM_OF_THREADS` | 4 | Little throughput to gain past a handful, since the GIL serializes them, and each thread still opens its own database connections. Leave it low. |
+| `DD_CELERY_WORKER_CONCURRENCY` | host vCPU | Parallel async workers for imports, deduplication, and notifications. Raise it for import-heavy or CI-driven workloads; lower it if background work is starving the web processes of CPU. |
+| `DD_CELERY_WORKER_AUTOSCALE_MAX` | host vCPU | The ceiling Celery scales up to under load. Keep it near the core count so bursts don't open more connections than the database can serve. |
+
+These four decide how many database connections the application holds open, so tune them alongside the database's own limits (see [Tuning the database](#tuning-the-database)). The Helm chart derives the same settings from your values, so on Kubernetes you normally leave them to the chart.
+{{< /tab >}}
+{{< /tabs >}}
+
+## Tuning the database
+
+The database is where finding queries live or die, and PostgreSQL ships with defaults tuned for a small machine. On a dedicated database host you have to raise a handful of settings before it will use the memory you gave it. A 64 GB host left on stock `shared_buffers` performs like a small one. These are the settings that move the needle for DefectDojo's aggregation-heavy reads, in rough order of impact:
+
+| Setting | Starting point | What it controls |
+| --- | --- | --- |
+| `shared_buffers` | ~25% of the host's RAM | PostgreSQL's own cache of table and index pages. This is the lever behind "buy memory before cores": while the working set and its indexes fit here, finding queries stay fast; once they don't, the database reaches for disk and latency climbs sharply. |
+| `effective_cache_size` | ~50–75% of RAM | A planner hint, not an allocation. It tells the planner how much data is likely cached, which steers it toward index scans over full-table scans on your findings. Set too low, the planner picks slow plans on a host that had the memory all along. |
+| `work_mem` | 32–128 MB | Memory for one sort or hash step, and DefectDojo sorts and groups findings constantly. It is allocated per operation per connection, so a large value multiplied by hundreds of connections is how you run the host out of memory. Raise it in small steps. |
+| `maintenance_work_mem` | 512 MB–2 GB | Memory for index builds, `VACUUM`, and schema migrations. It doesn't affect steady-state queries, but it decides how long an upgrade's migrations and reindexes take. |
+| `max_connections` | above the application's total | The ceiling on concurrent connections. It has to clear what the application holds open, with headroom. Too low and requests fail outright under load; far too high and every idle connection still costs memory. |
+
+On a managed database (RDS, Cloud SQL, and the like) these are parameter-group settings rather than lines in `postgresql.conf`, but they are the same knobs. Whichever you run, raise them together with the memory you provision.
-The concurrent user figures in the table assume smaller datasets belong to smaller teams. That assumption breaks often. If you hold 200K findings but have 100 people in the UI at once, size the application layer for the users and leave the database where your finding count puts it. The two scale independently.
+### Keep the connection budget balanced
-There is one exception, at the far end of the table. Import and deduplication run on the application tier rather than in the database, so once a data set is large enough for that work to dominate, node count follows ingest volume instead of user count. That is why the 500M row sits well above what its user figure on its own would suggest.
+The application tier and the database are tuned against one shared number: how many connections the application holds open. Every uWSGI process and every Celery worker keeps its own, so the total is roughly:
-### Node shape is flexible
+```
+(uWSGI processes × uWSGI threads) + Celery worker concurrency
+```
-Kubernetes will spread the load whether you give it a few large nodes or more small ones, so the node counts above are one workable arrangement rather than a requirement. Two things are worth holding to. Keep at least two nodes so losing one doesn't take the application down, and avoid nodes smaller than 2 vCPU / 8 GB so individual pods schedule comfortably.
+On a 12 vCPU host tuned as above that is `18 × 4 + 12 = 84`, and under load it settles near that. Keep the database's `max_connections` comfortably ahead of the number you land on. The failure mode is not the obvious one: too many processes and workers open more connections than the database can serve and end up hammering it, which surfaces as slow queries and 500s under load rather than as more throughput. Raise the application's process and worker counts gradually while watching the connection count and CPU headroom, rather than setting a large multiple of the core count up front.
## Storage
@@ -79,7 +155,7 @@ Both of those point at the same work. Partitioning and archiving cold findings o
The figures here already lean conservative, and being one size too large costs far less than being one size too small. Database memory pressure in particular does not degrade gracefully. Performance holds up fine until it doesn't.
-Adding application capacity later is straightforward, since you add nodes. Resizing a database typically means downtime, so that is the one worth getting right up front.
+Adding application capacity later is straightforward: on Kubernetes you add pods or nodes, and on Docker Compose you resize the host and raise the process and worker counts as above. Resizing a database typically means downtime, so that is the one worth getting right up front.
## Questions or support
diff --git a/docs/content/get_started/pro/onprem/hardware_sizing.pt-br.md b/docs/content/get_started/pro/onprem/hardware_sizing.pt-br.md
index 1b0ad2a0a61..43d3bf51945 100644
--- a/docs/content/get_started/pro/onprem/hardware_sizing.pt-br.md
+++ b/docs/content/get_started/pro/onprem/hardware_sizing.pt-br.md
@@ -3,7 +3,7 @@ title: Dimensionamento de hardware para o DefectDojo Pro autogerenciado
description: Orientação geral para dimensionar processamento, memória e armazenamento
em uma implantação autogerenciada do DefectDojo Pro
draft: false
-weight: 4
+weight: 2
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/hardware_sizing.zh-hans.md b/docs/content/get_started/pro/onprem/hardware_sizing.zh-hans.md
index 261dd49dae6..9656a55af89 100644
--- a/docs/content/get_started/pro/onprem/hardware_sizing.zh-hans.md
+++ b/docs/content/get_started/pro/onprem/hardware_sizing.zh-hans.md
@@ -2,7 +2,7 @@
title: 自托管 DefectDojo Pro 的硬件规模规划
description: 关于为自托管 DefectDojo Pro 部署规划计算、内存和存储规模的一般性指南
draft: false
-weight: 4
+weight: 2
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/installation_options.de.md b/docs/content/get_started/pro/onprem/installation_options.de.md
index 16a17c9f24c..578f6c57d1d 100644
--- a/docs/content/get_started/pro/onprem/installation_options.de.md
+++ b/docs/content/get_started/pro/onprem/installation_options.de.md
@@ -1,7 +1,7 @@
---
title: Self-Hosting von DefectDojo Pro
date: 2021-02-02 20:46:29+01:00
-weight: 5
+weight: 1
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/installation_options.es.md b/docs/content/get_started/pro/onprem/installation_options.es.md
index a9f2984b99f..3703a1826c5 100644
--- a/docs/content/get_started/pro/onprem/installation_options.es.md
+++ b/docs/content/get_started/pro/onprem/installation_options.es.md
@@ -1,7 +1,7 @@
---
title: Alojamiento propio de DefectDojo Pro
date: 2021-02-02 20:46:29+01:00
-weight: 5
+weight: 1
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/installation_options.fr.md b/docs/content/get_started/pro/onprem/installation_options.fr.md
index a9bf3ec8e22..22b0c8315ed 100644
--- a/docs/content/get_started/pro/onprem/installation_options.fr.md
+++ b/docs/content/get_started/pro/onprem/installation_options.fr.md
@@ -1,7 +1,7 @@
---
title: Auto-hébergement de DefectDojo Pro
date: 2021-02-02 20:46:29+01:00
-weight: 5
+weight: 1
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/installation_options.it.md b/docs/content/get_started/pro/onprem/installation_options.it.md
index 98e36098cd1..b21699f14a8 100644
--- a/docs/content/get_started/pro/onprem/installation_options.it.md
+++ b/docs/content/get_started/pro/onprem/installation_options.it.md
@@ -1,7 +1,7 @@
---
title: Self-hosting di DefectDojo Pro
date: 2021-02-02 20:46:29+01:00
-weight: 5
+weight: 1
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/installation_options.ja.md b/docs/content/get_started/pro/onprem/installation_options.ja.md
index 35e9bd3d202..15715fae5f4 100644
--- a/docs/content/get_started/pro/onprem/installation_options.ja.md
+++ b/docs/content/get_started/pro/onprem/installation_options.ja.md
@@ -1,7 +1,7 @@
---
title: DefectDojo Proのセルフホスティング
date: 2021-02-02 20:46:29+01:00
-weight: 5
+weight: 1
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/installation_options.md b/docs/content/get_started/pro/onprem/installation_options.md
index b37b0b72007..797147432e0 100644
--- a/docs/content/get_started/pro/onprem/installation_options.md
+++ b/docs/content/get_started/pro/onprem/installation_options.md
@@ -1,7 +1,9 @@
---
title: "Self-Hosting DefectDojo Pro"
+description: "The self-hosted deployment models for DefectDojo Pro (Docker Compose and Kubernetes), what you need before you start, and how the rest of this section fits"
+draft: false
date: 2021-02-02T20:46:29+01:00
-weight: 5
+weight: 1
audience: pro
---
@@ -27,11 +29,16 @@ You will need a license file and the deployment tooling for your chosen model. D
You will also need somewhere to run it, a PostgreSQL database it can reach, and a hostname that resolves to the deployment. The individual installation pages cover the specifics for each model.
-## What else is in this section
+## Choose your deployment method
+
+The install and upgrade steps live in two sections, one per method:
-The pages alongside this one cover the rest of the lifecycle. There is sizing guidance for choosing hardware, instructions for moving an existing open source instance into a self-hosted Pro deployment, and a procedure for installing where the target host has no route to the internet.
+- **[Kubernetes (Helm)](/get_started/pro/onprem/kubernetes/)** — installing and upgrading with the Helm chart, plus deploying on OpenShift.
+- **[Docker Compose](/get_started/pro/onprem/docker_compose/)** — installing and upgrading with `dojo-compose-cli`, plus air-gapped installs and adding storage for uploaded files.
+
+## What else is in this section
-For deployments already running, there are pages on upgrading, on backing up, on raising the limits that reject large scan uploads, and on expanding storage for uploaded files when a host runs short. Use the section navigation to browse them.
+The remaining pages apply to both methods: [hardware sizing](/get_started/pro/onprem/hardware_sizing/), [migrating from open source](/get_started/pro/onprem/migrating_from_open_source/), [upgrading](/get_started/pro/onprem/upgrading/), [FIPS mode](/get_started/pro/onprem/fips_mode/) (with a separate page for [FIPS on Amazon ECS / Fargate](/get_started/pro/onprem/fips_on_ecs_fargate/)), and [backing up](/get_started/pro/onprem/backing_up/). Raising upload size limits differs by method, so it lives in each section: [Kubernetes](/get_started/pro/onprem/kubernetes/upload_size_limits/) and [Docker Compose](/get_started/pro/onprem/docker_compose/upload_size_limits/).
## Questions
diff --git a/docs/content/get_started/pro/onprem/installation_options.pt-br.md b/docs/content/get_started/pro/onprem/installation_options.pt-br.md
index c4a0d462901..b9eee63cb8c 100644
--- a/docs/content/get_started/pro/onprem/installation_options.pt-br.md
+++ b/docs/content/get_started/pro/onprem/installation_options.pt-br.md
@@ -1,7 +1,7 @@
---
title: Auto-hospedagem do DefectDojo Pro
date: 2021-02-02 20:46:29+01:00
-weight: 5
+weight: 1
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/installation_options.zh-hans.md b/docs/content/get_started/pro/onprem/installation_options.zh-hans.md
index a0250f0eefa..915a1b04be5 100644
--- a/docs/content/get_started/pro/onprem/installation_options.zh-hans.md
+++ b/docs/content/get_started/pro/onprem/installation_options.zh-hans.md
@@ -1,7 +1,7 @@
---
title: 自托管 DefectDojo Pro
date: 2021-02-02 20:46:29+01:00
-weight: 5
+weight: 1
audience: pro
---
diff --git a/docs/content/get_started/pro/onprem/kubernetes/_index.md b/docs/content/get_started/pro/onprem/kubernetes/_index.md
new file mode 100644
index 00000000000..b6423f7dae4
--- /dev/null
+++ b/docs/content/get_started/pro/onprem/kubernetes/_index.md
@@ -0,0 +1,9 @@
+---
+title: "Kubernetes (Helm)"
+description: "Self-hosting DefectDojo Pro on Kubernetes with the Helm chart"
+draft: false
+weight: 9
+audience: pro
+---
+
+Running DefectDojo Pro on Kubernetes with the DefectDojo Pro Helm chart. These pages cover installing, upgrading, migrating from open source, deploying on OpenShift, and raising upload size limits.
diff --git a/docs/content/get_started/pro/onprem/installing_on_kubernetes.de.md b/docs/content/get_started/pro/onprem/kubernetes/installing_on_kubernetes.de.md
similarity index 99%
rename from docs/content/get_started/pro/onprem/installing_on_kubernetes.de.md
rename to docs/content/get_started/pro/onprem/kubernetes/installing_on_kubernetes.de.md
index 3bbdf794be1..f4bb0e19ab2 100644
--- a/docs/content/get_started/pro/onprem/installing_on_kubernetes.de.md
+++ b/docs/content/get_started/pro/onprem/kubernetes/installing_on_kubernetes.de.md
@@ -1,10 +1,12 @@
---
-title: DefectDojo Pro Installationsleitfaden
+title: DefectDojo Pro Installationsleitfaden (Kubernetes / Helm)
description: 'DefectDojo Pro mit dem Helm-Chart auf Kubernetes installieren: Infrastruktur,
Secrets und die Installation selbst'
draft: false
-weight: 13
+weight: 1
audience: pro
+aliases:
+ - /de/get_started/pro/onprem/installing_on_kubernetes/
---