Release: Merge release into master from: release/3.1.100

components/package.json

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

docs/content/admin/user_management/OS__creating_new_users.md

@@ -36,6 +36,8 @@ The admin who creates the account is responsible for delivering the initial cred
 
 If your instance is configured with [SSO](../configure_sso/), the workflow is different — users are typically created on first login from the Identity Provider, and you only need to grant them group membership or roles afterwards.
 
+If you have moved to open-source DefectDojo (where SSO is Pro-only) and existing SSO users can no longer log in, see [Re-enabling login for SSO users](../os__sso_user_local_login_fallback/).
+
 ## Recovering from a lost MFA token
 
 If a user loses access to their MFA device, see the [MFA recovery section](/get_started/pro/cloud/connectivity-troubleshooting/#ive-lost-access-to-my-mfa-codes) of the connectivity troubleshooting guide. There is currently no way to remove MFA from an account without an MFA code — the workaround is to create a new account for the user and re-grant the same permissions.

docs/content/admin/user_management/OS__sso_user_local_login_fallback.md

@@ -0,0 +1,57 @@
+---
+title: "Re-enabling login for SSO users (Open Source)"
+description: "Give SSO-provisioned users a local password after moving to Open Source, where SSO is a Pro-only feature"
+audience: opensource
+weight: 2
+---
+
+## When this applies
+
+SSO (SAML, OIDC, OAuth) is a [DefectDojo Pro](https://defectdojo.com) feature. If you upgrade to open-source DefectDojo 3.x (or otherwise move off Pro), the SSO login options are removed, and users who were provisioned through SSO can no longer log in. Their accounts were never given a local password, and the UI and API will not let you set one for them: DefectDojo detects them as SSO accounts and blocks the change.
+
+You do **not** need to delete and recreate these users (which would lose their history, permissions, and object ownership). Instead, give each account a local password on the backend and force a password reset on next login.
+
+See the [SSO section](/admin/sso/) and the [3.0 upgrade notes](/releases/os_upgrading/3.0/#sso-providers-are-available-in-defectdojo-pro-only) for background on SSO being Pro-only.
+
+## Why it happens
+
+Open-source DefectDojo authenticates against Django's local user database only. It decides whether an account is an "SSO user" purely by whether the account has a usable password. SSO-provisioned accounts were created with an *unusable* password, so:
+
+* local login fails (there is no password to check), and
+* the **Force password reset** control in the UI and API is blocked, with a message that the user is authorized through SSO.
+
+Setting a real password clears both conditions at once: the account can log in locally, and the forced-reset flag becomes settable.
+
+## The workaround
+
+Run these steps from the Django shell inside the `uwsgi` container:
+
+```bash
+docker compose exec -it uwsgi ./manage.py shell
+```
+
+### Exmaple for a single user
+
+```python
+from dojo.user.models import Dojo_User, UserContactInfo
+
+u = Dojo_User.objects.get(username="alice@example.com")
+u.set_password("<temporary-strong-password>")   # makes the account a local login account
+u.save()
+
+uci, _ = UserContactInfo.objects.get_or_create(user=u)
+uci.force_password_reset = True                  # force a change on next login
+uci.save()
+```
+
+## What the user does next
+
+Deliver the temporary password to each user out-of-band (email, your team chat, however you normally share secrets). On their next login, DefectDojo redirects them to the **Change Password** page and will not let them go anywhere else until they set their own password. The forced-reset flag clears automatically once they do.
+
+If your instance has the "I forgot my password" flow enabled (`DD_FORGOT_PASSWORD`, on by default) and email configured, users can instead use the **I forgot my password** link on the login page after their account has a usable password, and set a password without needing the temporary one.
+
+## Notes
+
+* **Kubernetes:** run the shell in the Django pod instead, e.g. `kubectl exec -it deploy/defectdojo-django -c uwsgi -- ./manage.py shell` (adjust the deployment and container names to your release).
+* Choose a strong throwaway password. With `force_password_reset = True` the user cannot keep it, so it only needs to survive one login.
+* Keep at least one working local admin account so you are never locked out.

docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.md

@@ -159,6 +159,7 @@ Examples include:
 **Report-Defined Test Type Naming Rules:**
 - If the report's `type` field equals the scan type → uses scan type directly (e.g., "Generic Findings Import")
 - If the report's `type` field differs → creates "{type} Scan ({scan_type})" format (e.g., "Tool1 Scan (Generic Findings Import)")
+- If the report's `type` field already ends with the " ({scan_type})" suffix → uses it verbatim, so the suffix is never doubled (e.g., "Tool1 (Generic Findings Import)" stays "Tool1 (Generic Findings Import)")
 - If no `type` field is provided → uses scan type directly
 
 **Important Considerations:**

docs/content/asset_modelling/engagements_tests/OS__tests.md

@@ -37,7 +37,7 @@ While each method differs primarily in how scan data is parsed and ingested, the
 
 When no native parser exists for a given tool, **Generic Findings Import** allows you to import findings using a standardized JSON or CSV schema, regardless of the original source. 
 
-DefectDojo parses the provided data, creates a new Test (or imports into an existing one), and attaches the Findings. A corresponding Test Type is also created in the format “{Test Name} (Generic Findings Import).”
+DefectDojo parses the provided data, creates a new Test (or imports into an existing one), and attaches the Findings. A corresponding Test Type is also created based on the report's optional `type` field: when `type` is omitted (or equals the scan type) the Test Type is “Generic Findings Import”; when `type` is provided it becomes “{type} Scan (Generic Findings Import)” (a `type` that already ends with the “(Generic Findings Import)” suffix is used verbatim).
 
 |  | **Native Parsers** | **Generic Findings Import** | 
 |----------|---------------|------------------------|

docs/content/asset_modelling/engagements_tests/PRO__tests.md

@@ -35,7 +35,7 @@ While each method differs primarily in how scan data is parsed and ingested, the
 
 When no native parser exists for a given tool, [**Generic Findings Import**](/supported_tools/parsers/generic_findings_import) allows you to import findings using a standardized JSON or CSV schema, regardless of the original source. 
 
-DefectDojo parses the provided data, creates a new Test (or imports into an existing one), and attaches the Findings. A corresponding Test Type is also created in the format “`{Test Name}` (Generic Findings Import).”
+DefectDojo parses the provided data, creates a new Test (or imports into an existing one), and attaches the Findings. A corresponding Test Type is also created based on the report's optional `type` field: when `type` is omitted (or equals the scan type) the Test Type is “Generic Findings Import”; when `type` is provided it becomes “`{type}` Scan (Generic Findings Import)” (a `type` that already ends with the “(Generic Findings Import)” suffix is used verbatim).
 
 #### Universal Parser 
 

docs/content/get_started/pro/onprem/upgrading.md

@@ -0,0 +1,31 @@
+---
+title: "Upgrading DefectDojo Pro (On-Premise)"
+description: "Supported upgrade procedure for self-hosted DefectDojo Pro deployments using the Helm chart"
+draft: false
+weight: 5
+audience: pro
+---
+
+This page describes the supported upgrade procedure for self-hosted DefectDojo Pro deployments that use the DefectDojo Pro Helm chart.
+
+## Upgrade everything as one unit
+
+Each DefectDojo Pro release consists of a Helm chart version, container image versions, and the Pro settings files. These are built and tested together and must be upgraded together as one unit.
+
+Upgrading only the image tags is not supported and will break your deployment.
+
+## Settings files and upgrades
+
+DefectDojo Pro ships a `pro_settings.py` file with every release, and the file changes with nearly every version. Do not carry a copy of `pro_settings.py` forward across upgrades, and do not patch an older copy by hand. The application must always run the `pro_settings.py` that matches its version.
+
+Put your own customizations in `local_settings.py`, never in `pro_settings.py`. Your `local_settings.py` is preserved across upgrades.
+
+The Helm chart ships and mounts the matching `pro_settings.py` and your `local_settings.py` automatically. When you upgrade using the chart, there is nothing to copy or migrate by hand.
+
+## Supported upgrade procedure
+
+1. Review the release notes for every version between your current version and your target version, not just the target itself. See the [DefectDojo Pro Changelog](/releases/pro/changelog/) and the version-specific [upgrade notes](/releases/os_upgrading/upgrading_guide/).
+2. Back up your database.
+3. Upgrade to the Helm chart release that matches your target application version, reusing your existing values files. Do not change image tags independently of the chart version.
+
+If you have questions about upgrading your on-premise deployment, contact [support@defectdojo.com](mailto:support@defectdojo.com).

docs/content/import_data/pro/connectors/about_connectors.md

@@ -29,9 +29,11 @@ We currently support Connectors for the following tools, with more on the way:
 * **Akamai API Security**
 * **Anchore**
 * **AWS Security Hub**
+* **Backstage** (asset inventory: builds Product hierarchy and team ownership from the Software Catalog)
 * **BurpSuite**
 * **Checkmarx ONE**
 * **Dependency-Track**
+* **Group-IB ASM**
 * **IriusRisk**
 * **JFrog Xray**
 * **Probely**