Release: Merge release into master from: release/merge-dev-into-master-3.5.103

components/package.json

@@ -1,6 +1,6 @@
 {
   "name": "defectdojo",
-  "version": "3.5.102",
+  "version": "3.5.103",
   "license": "BSD-3-Clause",
   "private": true,
   "dependencies": {

docs/content/admin/feature_flags/PRO__feature_flags.md

@@ -140,7 +140,7 @@ Features under **MCP** appear on the Feature Flags page beneath the MCP server s
 | **Administrator MFA Reset** | Let superusers reset multi-factor authentication for another user from the Users page. The reset removes that user's authenticator and recovery codes and notifies them; they set MFA up again at their next sign-in if it is required. Turning this off removes the action. Users can still remove their own MFA from their profile. | On | [Docs](/admin/user_management/pro__mfa/#recovering-a-user-who-has-lost-their-mfa-device) |
 | **AI Inventory and Governance** (BETA) | Inventory the AI in every scanned repository: coding assistants and their rules files, MCP servers, models, AI packages, AI service endpoints, agent skills and AI provider keys. Policies mark each component authorized, unauthorized or needs review, unauthorized components become Findings, and each Asset can export an AI bill of materials. Inventories that arrive while this is off are still stored and appear when it is turned on. Requires **Locations**. | Off | [Docs](/asset_modelling/locations/pro__ai_inventory/) |
 | **AI Threat Modeling** | Generate a STRIDE threat model, attacker profiles, attack paths and security requirements from a feature design with Sensei. | On | [Docs](/sensei/threat_modeling/) |
-| **Airgapped instance** | This instance has no route off its network, so it never contacts DefectDojo. The version check, external tools, announcements, threat intel downloads and error and performance diagnostics stop, and both support pages show the DefectDojo support address instead. Load threat intel bundles from a file. The DD_AIRGAPPED environment variable turns this on for the whole deployment. | Off | [Docs](/get_started/pro/onprem/airgapped/) |
+| **Airgapped Instance** | This instance has no route off its network, so it never contacts DefectDojo. The version check, external tools, announcements, threat intel downloads and error and performance diagnostics stop, and both support pages show the DefectDojo support address instead. Load threat intel bundles from a file. The DD_AIRGAPPED environment variable turns this on for the whole deployment. | Off | [Docs](/get_started/pro/onprem/airgapped/) |
 | **Asset Discovery** (BETA) | List the devices your EDR sees on the network that have no agent of its own, as CrowdStrike Falcon Discover and Microsoft Defender for Endpoint report them. Turn it on per connection with Report Unmanaged Devices. The devices are candidates: none becomes an Asset, and none counts toward Total Findings. | Off | [Docs](/asset_modelling/pro__unmanaged_devices/) |
 | **Asset Exposure** (BETA) | Compute whether an asset is reachable from outside, and whether a finding's code is actually deployed in production, from the evidence connectors already collect. Both feed prioritization; exposure can also drive the FedRAMP VDR SLA tiers. | Off | [Docs](/triage_findings/finding_scoring/asset_exposure/) |
 | **Asset Identity** | Let connectors find each Asset by the identifier its source uses instead of by name, and list every identifier it is known by on its Identity card. Records that are already mapped stay where they are. Turning this off goes back to matching by name; the identifiers are kept. | Off | [Docs](/asset_modelling/engagements_tests/pro__assets/#asset-identity-aliases) |

docs/content/admin/notifications/configure_personal_notifs.md

@@ -31,9 +31,19 @@ In addition to standard personal notifications, DefectDojo Users can also receiv
 
 ![image](images/Configure_System_&_Personal_Notifications_3.png)
 
-This configuration can be changed from the **Notifications** section on the **Asset** page: e.g. `your-instance.defectdojo.com/product/{id}`.
+In the Pro UI, open the Asset, then choose **Notifications** from the ⚙️ gear menu in the page header (the same menu appears on each Asset row in the Asset lists). The dialog lists the events that can be followed for one Asset, with a column for each delivery method:
 
-From here, you can set whether you want to receive **🔔 Alert**, **Mail** or **Slack** notifications for actions taken on this particular Asset. These notifications apply in addition to any system\-wide notifications you are already receiving. 
+* **Engagement Added** and **Engagement Closed**
+* **Test Added** and **Scan Added**
+* **SLA Breach** and **SLA Breach (Combined)**
+* **Risk Acceptance Expiring**
+* **Finding Risk Accepted**, **Threat Intel Escalation** and **AI Component Discovered**: the Pro events that are sent about one Asset
+
+Tick a box to receive that event over that method, then **Submit**. The box under a method's name ticks or clears it for every event. Opening the dialog changes nothing: an Asset starts with every event off until settings are submitted for it. Other Pro events (connector health, work assignments, review requests and the like) are sent to named people or are not about one Asset, so they are set on Personal Notifications only.
+
+In the Classic UI, this configuration is changed from the **Notifications** section on the **Asset** page: e.g. `your-instance.defectdojo.com/product/{id}`.
+
+From here, you can set whether you want to receive **🔔 Alert**, **Mail** or **Slack** notifications for actions taken on this particular Asset. These notifications apply in addition to your Personal Notifications and any system\-wide notifications you are already receiving, and they stop if you lose access to the Asset.
 
 Microsoft Teams cannot send personal notifications of any kind, so Teams notifications cannot be chosen from this menu.
 

docs/content/admin/notifications/configure_system_notifs.md

@@ -43,4 +43,15 @@ This restriction does not apply to System Notifications that are sent to a speci
 
 See our guide on [Role-Based Access Control](../../user_management/about_perms_and_roles/) for more information on RBAC and setting permissions.
 
-However, the connected System Email, Slack and Teams accounts cannot apply RBAC as they are not associated with a specific DefectDojo user.  **All selected system-wide notifications will be sent to these locations, so you should ensure that these channels can only be accessed by specific people in your organization.**
+However, the connected System Email, Slack and Teams accounts cannot apply RBAC as they are not associated with a specific DefectDojo user.  **All selected system-wide notifications will be sent to these locations, so you should ensure that these channels can only be accessed by specific people in your organization.**
+
+## Notification webhooks a Group owns
+
+Notification webhooks are managed by superusers on **Notification Webhooks**. With Group Ownership on, a webhook can also belong to a Group, so the Group's Triage Engine rules post to it:
+
+* A member whose Role in the Group carries **Integration Edit** creates one for the Group (**Owned By**), and changes or deletes the Group's webhooks. Members whose Role carries **Integration View** see them. The header value is shown only to someone who can change the webhook.
+* A Group's webhook receives no personal or system notifications; it is used by the rules that name it.
+* A Group's webhook may not post to a private, loopback or link-local address. Creating, editing or transferring one with such an address into a Group is refused, and so is a send to it, unless the instance allows private destinations for the Triage Engine (`DD_RULES_V2_ALLOW_PRIVATE_EGRESS`).
+* **Share** shows it to other Groups, and **Transfer** moves it to another Group. Only a superuser moves one to the instance, which makes it a system webhook.
+* The **Owner** column shows who owns each webhook. System webhooks read as owned by the instance.
+

docs/content/admin/sso/PRO__login_settings.md

@@ -25,6 +25,7 @@ Find it under **Connect > Authorization > Login Settings**. Changing it takes th
 
 Session Age and Idle Timeout apply to every login, whether by username and password or by SSO. A user whose session ends, for either reason, is taken to the login page on their next click, and lands back on the page they were on once they sign in again.
 
+- In the Pro UI, a **Session Expiring** warning counts down the time left before a session ends, opening five minutes ahead by default (the `DD_SESSION_EXPIRE_WARNING` environment variable, in seconds, and never more than half the Idle Timeout ahead of an inactivity deadline). While inactivity is what will end the session, **Stay Signed In** starts a new Idle Timeout. When Session Age is what will end it, the warning says the session cannot be extended: save any work, then sign in again. Every open tab shares the session, so staying signed in from one tab closes the warning in the others.
 - Only requests the user makes count as activity. A page left open in a browser tab still reaches the Idle Timeout, even though it keeps refreshing its notification count in the background.
 - Activity is recorded at most once a minute, so an idle session can end up to a minute before the Idle Timeout, never after it.
 - A change to either setting reaches every running server within a minute, and applies to sessions that are already signed in. Shortening Session Age signs out anyone whose login is older than the new value.

docs/content/admin/user_management/PRO__service_users.md

@@ -94,7 +94,7 @@ On the Service Users page it is marked with a **Group Automation** chip, and the
 
 * It has no password and no token, and none can be issued, so it can never authenticate to the API or the UI.
 * Its access is exactly its group's: the group's Organization and Asset Roles and its Global Roles. Its access cards say the access is set at the group level, and it cannot be given a Global Role, a membership or a group of its own.
-* Its menu offers only **View Service User**. It cannot be edited, disabled, given a new token or deleted here, and the Users API refuses to deactivate it. Change its access by changing the group's, and remove it by deleting the group.
+* Its menu offers only **View Service User**. It cannot be edited, disabled, given a new token or deleted here, and the Users API refuses to deactivate it. Change its access by changing the group's, and remove it by deleting the group. Its API token, when the **Group API Tokens** flag is on, is issued and revoked on the group's page: see [the group's API token](../create_user_group/#the-groups-api-token).
 * Its name and description follow the group's current name.
 
 Group Automation identities do not count toward the licensed user total, the same as any service user.

docs/content/admin/user_management/create_user_group.md

@@ -39,12 +39,12 @@ With Access Administration on (Pro), a Group's page has these tabs:
 * **Access**: what the Group reaches in its own right: its Global Roles, its Configuration Permissions, and the Organizations and Assets it holds a Role on, with how each one is reached. Every member of the Group receives this access through it, and a Group that holds a Global Role is marked as having instance-wide access. The Group's own Roles are changed here, with **Add to Organization**, **Add to Asset**, **Change Role** and **Remove**. Each change is checked against your permissions on that Organization or Asset, exactly as on its own Members dialog.
 * **Default Profile**: the [Default Profile](#default-profiles) the Group's Members start from, and what that profile sets. See [Set Group Defaults](#set-group-defaults).
 
-With Group Ownership on, the page also has an **Owned Content** tab: one row for each kind of content a Group can own (**Rules**, **Report Templates**, **Report Blocks**, **Report Themes** and **Generated Reports**), with how many of the Group's you can see. A report schedule belongs to its Template, as a rule's schedule belongs to the rule, so it has no row of its own. A kind's name opens its list filtered to the Group, and that page's title and breadcrumb name the Group (for example **Report Templates Owned By AppSec**, under a link back to the Group).
+With Group Ownership on, the page also has an **Owned Content** tab: one row for each kind of content a Group can own (**Rules**, **Report Templates**, **Report Blocks**, **Report Themes**, **Generated Reports**, **Dashboards**, **Webhook Receivers**, **Notification Webhooks**, **Downstream Connectors** and **Ticket Templates**), with how many of the Group's you can see. A report schedule belongs to its Template, as a rule's schedule belongs to the rule, so it has no row of its own. A kind's name opens its list filtered to the Group, and that page's title and breadcrumb name the Group (for example **Report Templates Owned By AppSec**, under a link back to the Group).
 
 * The kind's name opens its usual list filtered to the Group: the **Owner** filter is set to the Group, and clearing it shows the whole list again.
 * The row menu has **View** (the same filtered list) and, where you can create that kind for the Group, **New**, which opens the create page with **Owned By** already set to the Group. See [Group ownership of rules](/automation/triage_engine/sharing_and_versions/#group-ownership) and [of Report Builder content](/metrics_reports/reports/report-builder/#group-ownership).
 
-A kind is listed when the Group owns something of that kind that you can see, or when you can create it there (your Role in the Group, or a Global Role, carries its **Add** permission; for a rule you must also be a member of the Group), and only while Triage Engine or Reporting is turned on.
+A kind is listed when the Group owns something of that kind that you can see, or when you can create it there (your Role in the Group, or a Global Role, carries its **Add** permission, or **Integration Edit** for connectors, ticket templates and notification webhooks; for a rule or a webhook receiver you must also be a member of the Group), and only while the feature it belongs to (Triage Engine, Reporting or Downstream Connectors) is turned on.
 
 The Group's page shows what it owns. Who owns something is chosen where it is created (**Owned By**) and changed with **Transfer** in its row menu.
 
@@ -62,17 +62,31 @@ Rules and report schedules a Group owns do not run as the person who created the
 The identity has exactly the Group's access, and nothing of its own:
 
 * It sees and edits what the Group's Organization and Asset Roles allow, and what the Group's Global Roles allow. When the Group gains or loses access, so does the identity, immediately.
-* It has no password and no API token, and it cannot sign in.
+* It has no password and cannot sign in. It has no API token unless one is issued for the Group (see [The group's API token](#the-groups-api-token)).
 * It cannot be given a Global Role, a membership or any access of its own. Its access is set on the Group.
 * It is removed when the Group is deleted.
 
 Because the identity carries the Group's access, a Group that holds a Global Role has an identity that reaches the whole instance, and its rules can act on every Finding. The rule editor's **Runs As** panel warns about this.
 
 Changing what a Group's rule or report schedule does needs membership of the Group as well as the permission to edit it, because the change acts with the Group's access. See [Group Content permissions](../pro__custom_rbac_roles/#group-content-permissions).
 
+### The group's API token
+
+With the **Group API Tokens** feature flag on, a Group's automation identity can hold one API token, so the Group's own automation (a pipeline, a script) calls the API as the Group. The token sees exactly what the Group owns and has been granted, nothing more. It acts as the Group, not as whoever issued it, so it can read Group content (connectors and ticket templates, for example, with their secrets masked) that the issuer's own Role in the Group does not show them.
+
+The **Automation Identity** card on the Group's **Overview** tab shows the token's first characters, who issued it and when, and when it expires. A superuser, or a member whose Role in the Group carries **Service User Edit**, manages it there:
+
+* **Issue Token** creates the token, with an expiry of 30, 60, 90 or 180 days or none. The token is shown once; DefectDojo keeps only a hash of it. Issuing creates the automation identity if the Group has none yet.
+* **Replace Token** issues a new token; the old one stops working at once. OAuth access tokens already exchanged from it keep working until they expire, within the hour.
+* **Revoke Token** ends the token at once (OAuth access tokens already exchanged from it expire within the hour). Revoking works even while the feature flag is off.
+
+When the Group holds a Global Role, its token reaches everything that Role grants, so only a superuser may issue it; the card still offers its other managers **Revoke Token**. The token is used like any [service user](../pro__service_users/#use-the-token) token, in the `Authorization` header with the `Token` keyword. Group API Tokens needs Service Users on: a group token is a service user token. Turning the **Group API Tokens** flag (or **Service Users**) off refuses every group token, and every OAuth access token exchanged from one, until it is turned on again.
+
 ### Deleting a Group that owns content
 
-Deleting a Group does not delete its rules, templates, blocks, themes or schedules. Its rules are turned off, its templates, blocks and themes are hidden from everyone except superusers and holders of the matching global permission, and its schedules stop running. The rules, templates, blocks and themes appear under **Settings > Groups > Unowned Content** (a schedule waits with its Template and comes back when the Template is transferred), where an administrator holding **Rule Edit** or **Report Template Edit** as a Global Role transfers them to another Group or to the instance. The Group's automation identity is removed with the Group.
+Deleting a Group does not delete its rules, templates, blocks, themes, schedules, webhook receivers, notification webhooks, connectors or ticket templates. Its rules are turned off, its templates, blocks and themes are hidden from everyone except superusers and holders of the matching global permission, and its schedules stop running. Its webhook receivers stop accepting deliveries, and its notification webhooks are made permanently inactive, so nothing is sent through them until they have a new owner. The rules, templates, blocks, themes, receivers, notification webhooks, connectors and ticket templates appear under **Settings > Groups > Unowned Content** (a schedule waits with its Template and comes back when the Template is transferred), where an administrator holding the matching global Edit permission (**Rule Edit**, **Report Template Edit** or **Integration Edit**) transfers them to another Group or to the instance. Only a superuser moves a notification webhook to the instance, because that makes it a system webhook. The Group's automation identity, and with it the Group's API token, is removed with the Group.
+
+Its dashboards, page layouts and saved table views are kept too, hidden from everyone except superusers and holders of the matching share permission (**Dashboard Share**, **Page Layout Share**, **Table Preference Share**) as a Global Role. A dashboard waits in the **Group Dashboards** section of **Manage Layouts**, tagged **Unowned**, until it is transferred. A layout the Group had shared with everyone stays shared.
 
 ## Create a User Group