Merge branch 'bugfix' into sc-13654_freshservice_docs

Author: mtesauro

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

@@ -114,6 +114,31 @@ See [Burp Documentation](https://portswigger.net/burp/documentation/enterprise/u
 
 See the official [Burp documentation](https://portswigger.net/burp/extensibility/enterprise/graphql-api/index.html) for more information on the Burp API.
 
+## **Censys**
+
+The Censys connector reads host assets from the Censys Platform and imports each host's exposed services as findings. It uses the Censys Platform global search API to enumerate the hosts you scope it to.
+
+#### Prerequisites
+
+You will need a Censys **Platform** account with API access:
+
+* A **Personal Access Token**, created in the Censys Platform Console under Personal Access Tokens.
+* Your **Organization ID**, shown on the same settings page under "Current Organization". API access to the search endpoint requires an organization, so a Starter tier or higher is needed. Free\-tier tokens have no organization ID and cannot use the search API.
+
+Per\-host CVE and risk data is available only on Censys Core (enterprise) tiers, so on lower tiers findings represent exposed services rather than vulnerabilities.
+
+See the [Censys Platform API documentation](https://docs.censys.com/reference/get-started) for more information.
+
+#### Connector Mappings
+
+1. Enter `https://api.platform.censys.io` in the **Location** field.
+2. Enter your Personal Access Token in the **API Key** field.
+3. Enter your **Organization ID**.
+4. Enter a **Search Query** that scopes the import to your own assets, for example `host.autonomous_system.asn: <your ASN>` or `host.ip: 203.0.113.0/24`.
+5. Optionally, set a **Minimum Severity** to limit which findings are imported.
+
+DefectDojo creates a Record for each host and imports its exposed services as findings.
+
 ## **Checkmarx ONE**
 
 DefectDojo's Checkmarx ONE connector calls the Checkmarx API to fetch data.
@@ -129,6 +154,23 @@ DefectDojo's Checkmarx ONE connector calls the Checkmarx API to fetch data.
 3. Enter your tenant location in the **Location** field. This URL is formatted as follows:  
 ​`https://<your-region>.ast.checkmarx.net/` . Your Region can be found at the beginning of your Checkmarx URL when using the Checkmarx app. **<https://ast.checkmarx.net>** is the primary US server (which has no region prefix).
 
+## **CrowdStrike Falcon**
+
+The CrowdStrike Falcon connector imports **Spotlight vulnerabilities** and **EDR detections** from the Falcon platform, as two separate finding types (`CrowdStrike:Spotlight` and `CrowdStrike:Detections`). DefectDojo creates a Record for each Falcon **host**.
+
+#### Prerequisites
+
+A Falcon **API client** (Client ID and secret), created in the Falcon console under **Support \> API Clients and Keys**. Grant it the scopes for the data you want to import: **Hosts: Read** (required, for host discovery), **Vulnerabilities (Spotlight): Read** (for Spotlight findings), and **Alerts: Read** (for EDR detections). The two finding types are independent — if the client lacks a scope, that finding type is skipped rather than failing the sync, so a client without **Alerts: Read** still imports Spotlight vulnerabilities.
+
+#### Connector Mappings
+
+1. Enter your Falcon cloud's API base URL in the **Location** field, matching your console region — for example `https://api.crowdstrike.com` (US\-1), `https://api.us-2.crowdstrike.com` (US\-2), `https://api.eu-1.crowdstrike.com` (EU\-1), or `https://api.laggar.gcw.crowdstrike.com` (US\-GOV\-1).
+2. Enter the API client's Client ID in the **Client ID** field.
+3. Enter the API client's secret in the **Client Secret** field.
+4. Optionally, set a **Minimum Severity** to limit which findings are imported.
+
+Each Falcon host becomes a Record, named for its hostname, OS, and type. Only **open** and **reopened** Spotlight vulnerabilities are imported, so reimport closes remediated findings.
+
 ## Dependency\-Track
 
 This connector fetches data from a on\-premise Dependency\-Track instance, via REST API.
@@ -148,6 +190,26 @@ To generate a Dependency\-Track API key:
 
 For more information, see **[Dependency\-Track Documentation](https://docs.dependencytrack.org/integrations/rest-api/)**.
 
+## **Have I Been Pwned**
+
+The Have I Been Pwned (HIBP) connector uses the HIBP REST API to report which accounts on your organization's own domains have appeared in known data breaches. DefectDojo discovers each domain you have verified with HIBP and imports one finding per breach affecting that domain.
+
+#### Prerequisites
+
+You will need a Have I Been Pwned API key with domain search, which requires a **Core** subscription tier or higher. You can obtain a key from your [Have I Been Pwned account](https://haveibeenpwned.com/API/Key).
+
+You must also **verify at least one domain** on your HIBP account before any breach data is available. HIBP lets you verify a domain by DNS TXT record, meta tag, file upload, or email, under **Domain search** in your account. Until a domain is verified, the connector discovers no domains and imports no findings.
+
+#### Connector Mappings
+
+1. Enter `https://haveibeenpwned.com` in the **Location** field.
+2. Enter your API key in the **Secret** field.
+3. Optionally, set a **Minimum Severity** to limit which findings are imported. Findings below the selected severity will not be imported.
+
+DefectDojo creates a separate Record for each domain you have verified with HIBP, and imports one finding per breach affecting accounts on that domain. Each finding's severity reflects the kind of data the breach exposed, and its description lists the affected accounts on your domain so your team can act on them.
+
+See the [Have I Been Pwned API documentation](https://haveibeenpwned.com/API/v3) for more information.
+
 ## **IriusRisk**
 
 The IriusRisk connector uses an API token to pull threat modeling data from your IriusRisk instance.
@@ -196,6 +258,35 @@ DefectDojo maps each Artifactory **repository** as a separate Record. On first S
 
 See the [JFrog Xray REST API documentation](https://jfrog.com/help/r/jfrog-rest-apis/xray-rest-apis) for more information.
 
+## **Microsoft Defender**
+
+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.
+
+**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 Product to avoid duplicate findings.
+
+#### Prerequisites
+
+Your Microsoft tenant needs an active license that includes the Defender vulnerability export APIs: **Defender for Endpoint Plan 2**, **Microsoft Defender Vulnerability Management Standalone**, or MDE P1/P2 with the MDVM add\-on. (The MDVM *Add\-on* SKU on its own is not sufficient — it requires Defender for Endpoint Plan 2 underneath.)
+
+The connector authenticates as a Microsoft Entra ID **app registration** using the client credentials flow. To create one:
+
+1. In the [Azure portal](https://portal.azure.com), open **App registrations \> New registration**. Name it (for example `defectdojo-connector`), leave the defaults, and select **Register**.
+2. On the app's **Overview** page, note the **Application (client) ID** and **Directory (tenant) ID**.
+3. Open **API permissions \> Add a permission \> APIs my organization uses** and search for **WindowsDefenderATP**. If it doesn't appear, your tenant's Defender backend hasn't been provisioned yet: ensure the license is active, open [security.microsoft.com](https://security.microsoft.com) once, and retry after a few minutes.
+4. Choose **Application permissions** (*not* Delegated — Delegated permissions never appear in the connector's service token), expand **Vulnerability**, check **Vulnerability.Read.All**, and select **Add permissions**.
+5. Select **Grant admin consent** and confirm. The Status column must show a green check — without this step every API call returns a 403 error.
+6. Open **Certificates & secrets \> New client secret**, set an expiry, and copy the secret **Value** immediately (it is only shown once). The Connector stops working when the secret expires, so note the date.
+
+#### Connector Mappings
+
+1. Enter `https://api.security.microsoft.com` in the **Location** field.
+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.
+
+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).
+
 ## Probely
 
 This connector uses the Probely REST API to fetch data.
@@ -264,6 +355,28 @@ On\-premise Tenable Connectors are not available at this time.
 
 See [Tenable's API Documentation](https://docs.tenable.com/vulnerability-management/Content/Settings/my-account/GenerateAPIKey.htm) for more info.
 
+## **Wazuh**
+
+The Wazuh connector uses the Wazuh Indexer (OpenSearch) to fetch vulnerability findings. Wazuh 4.8 and later store detected CVEs in the Indexer rather than the Wazuh server API, so this connector reads them directly from the `wazuh-states-vulnerabilities-*` index.
+
+DefectDojo creates a Record for each Wazuh agent (endpoint) and imports that agent's detected CVEs as findings on a scheduled basis.
+
+#### Prerequisites
+
+You will need:
+
+* The base URL of your Wazuh Indexer, including the port (the Indexer listens on port 9200 by default). DefectDojo connects to the Indexer directly, so this endpoint must be reachable from DefectDojo. For self\-managed deployments this is the host running the Wazuh Indexer. For Wazuh Cloud, use the Indexer endpoint shown in your Wazuh Cloud console, which is separate from the Wazuh dashboard URL.
+* An Indexer user and password with read access to the `wazuh-states-vulnerabilities-*` index. We recommend creating a dedicated user for DefectDojo.
+
+Vulnerability detection must be enabled in Wazuh so that the vulnerability\-state index is populated. See the [Wazuh vulnerability detection documentation](https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html) for more information.
+
+#### Connector Mappings
+
+1. Enter your Wazuh Indexer base URL in the **Location** field, including the scheme and port, for example `https://your-indexer.example.com:9200`. Do not include a trailing path. DefectDojo constructs the search paths automatically.
+2. Enter the Indexer username in the **Username** field.
+3. Enter the Indexer password in the **Password** field.
+4. Optionally, set a **Minimum Severity** to limit which findings are imported. Findings below the selected severity will not be imported.
+
 ## Wiz
 
 Using the Wiz connector requires you to create a service account: see the [Wiz documentation](https://docs.wiz.io/wiz-docs/docs/service-accounts-settings#add-a-service-account) for more info.  You will need a Wiz account to access the documentation.

docs/content/issue_tracking/jira/PRO__jira_guide.md

@@ -138,6 +138,38 @@ Note that DefectDojo cannot send any Issue\-specific metadata as Custom Fields,
 
 Follow **[this guide](#custom-fields-in-jira)** to get started working with Custom Fields.
 
+#### Close / Reopen Transition fields
+
+Some Jira workflows **require** certain fields to be set as part of a transition — for example, a workflow that refuses to close an Issue unless a Resolution and a Justification field are provided on the close screen. The Custom fields setting above only applies when an Issue is *created*, so it cannot satisfy these workflows.
+
+Without these settings, DefectDojo sends close / reopen transitions with no fields. A workflow that requires fields will reject that transition, and the Finding and the Jira Issue fall out of sync: the Finding shows as Mitigated in DefectDojo while the Issue remains open in Jira.
+
+The **Close Transition fields** and **Reopen Transition fields** settings accept a JSON object that is sent as the `fields` payload of the close / reopen transition call. For example, to close Issues with a Resolution of *Won't Fix* plus a justification value:
+
+```json
+{
+    "resolution": {"name": "Won't Fix"},
+    "customfield_10200": "Risk accepted by security team #report-false-positive"
+}
+```
+
+Leave these settings as 'null' if your Jira workflow does not require fields on transitions.
+
+**Which fields do you need?**
+
+* Ask your Jira admin which fields are on the close / reopen **transition screens**, and which of them are enforced by a validator. The configured JSON must satisfy **every** required field: if any required field is missing from the payload, Jira rejects the whole transition and sets nothing — supplying only some of the required fields does not help.
+* Conversely, fields must be present **on the transition screen** to be sent at all: Jira rejects transitions that attempt to set fields that are not on the screen for that transition.
+* On workflows built with Jira Cloud's current workflow editor, Jira automatically fills in the site's default Resolution when an Issue moves to a done-category status.  So, a required Resolution alone will not block a bare transition there, and the practical use of `"resolution"` in this payload is choosing a *meaningful* value (for example *False Positive*) instead of the site default. Workflows built with the classic editor, or with marketplace validator apps, can still hard-require Resolution.
+* Reopen transitions typically clear the Resolution via the workflow itself, so **Reopen Transition fields** usually only needs the custom fields your workflow requires.
+
+**Notes:**
+
+* The same JSON is sent for *every* close (or reopen) transition for the Product or Engagement — the values are static and do not vary per Finding. If you need different fields per disposition (for example, a different Resolution for False Positive findings than for remediated findings), use the DefectDojo Pro Jira Integrator, which supports per-status transition field mappings.
+* Values use the same format as Jira's REST API: strings for text fields, `{"name": ...}` for resolutions, `[{"name": ...}]` for multi-select fields, and so on.
+* If transitions were rejected while these settings were missing or incomplete, correcting the settings repairs the drift: the next status push for the Finding retries the transition with the configured fields.
+* Both settings are also available on the `/api/v2/jira_projects/` REST endpoint (`close_transition_fields` / `reopen_transition_fields`), so they can be managed via the API.
+* These fields are also applied when DefectDojo closes an Issue because its Finding was **deleted** — the values are captured at the moment the close is queued.
+
 #### Jira labels
 
 Select the relevant labels that you want the Issue to be created with in Jira, e.g. **DefectDojo**, **YourProductName..**

dojo/db_migrations/0278_jira_project_transition_fields.py

@@ -0,0 +1,21 @@
+from django.db import migrations, models
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ('dojo', '0277_seed_deduplication_execution_mode'),
+    ]
+
+    operations = [
+        migrations.AddField(
+            model_name='jira_project',
+            name='close_transition_fields',
+            field=models.JSONField(blank=True, help_text='JIRA fields to send as part of the Close transition, e.g. {"resolution": {"name": "Won\'t Fix"}, "customfield_10200": "justification"}. Use this when the JIRA workflow requires fields on the close transition screen. Fields not on the transition screen are rejected by JIRA.', null=True, verbose_name='Close transition fields'),
+        ),
+        migrations.AddField(
+            model_name='jira_project',
+            name='reopen_transition_fields',
+            field=models.JSONField(blank=True, help_text='JIRA fields to send as part of the Reopen transition, e.g. {"customfield_10201": "reopened by DefectDojo"}. Fields not on the transition screen are rejected by JIRA.', null=True, verbose_name='Reopen transition fields'),
+        ),
+    ]

dojo/jira/api/serializers.py

@@ -77,11 +77,12 @@ def validate(self, data):
             msg = "Either engagement or product has to be set."
             raise serializers.ValidationError(msg)
 
-        if "custom_fields" in data and isinstance(data["custom_fields"], str):
-            try:
-                data["custom_fields"] = json.loads(data["custom_fields"])
-            except json.JSONDecodeError as e:
-                raise serializers.ValidationError({"custom_fields": f"Invalid JSON: {e}"}) from e
+        for json_field in ("custom_fields", "close_transition_fields", "reopen_transition_fields"):
+            if json_field in data and isinstance(data[json_field], str):
+                try:
+                    data[json_field] = json.loads(data[json_field])
+                except json.JSONDecodeError as e:
+                    raise serializers.ValidationError({json_field: f"Invalid JSON: {e}"}) from e
 
         return data