diff --git a/docs/content/asset_modelling/engagements_tests/PRO__assets.de.md b/docs/content/asset_modelling/engagements_tests/PRO__assets.de.md index a7d32100da2..c3d74121ab9 100644 --- a/docs/content/asset_modelling/engagements_tests/PRO__assets.de.md +++ b/docs/content/asset_modelling/engagements_tests/PRO__assets.de.md @@ -169,7 +169,7 @@ Das bedeutet, dass dieselbe Schwachstelle je nachdem, ob sie ein internes Entwic ### Jira-/Downstream-Connector-Beziehungen -Assets können direkt mit [Jira](/connectors/downstream/pro__jira_guide/#main-content)- oder [Integrators](/connectors/downstream/downstream_toolreference/#main-content)-Instanzen (z. B. GitHub, GitLab, ServiceNow usw.) verknüpft werden, die die Befunde des Assets nach außen in externe Ticketing-/Work-Management-Systeme übertragen. +Assets können direkt mit [Jira](/connectors/downstream/pro__jira_guide/#main-content)- oder [Integrators](/connectors/toolreference/downstream/#main-content)-Instanzen (z. B. GitHub, GitLab, ServiceNow usw.) verknüpft werden, die die Befunde des Assets nach außen in externe Ticketing-/Work-Management-Systeme übertragen. Da Befunde Risiko, Priorität und Zuständigkeit von ihrem übergeordneten Asset übernehmen, bestimmt das Asset effektiv den Behebungskontext, der in Jira-Tickets und Downstream-Connector-Workflows einfließt. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__assets.es.md b/docs/content/asset_modelling/engagements_tests/PRO__assets.es.md index b81d5b69115..c948400b10c 100644 --- a/docs/content/asset_modelling/engagements_tests/PRO__assets.es.md +++ b/docs/content/asset_modelling/engagements_tests/PRO__assets.es.md @@ -169,7 +169,7 @@ Esto significa que la misma vulnerabilidad puede recibir una puntuación de Prio ### Relaciones con Jira / Downstream Connector -Los Activos se pueden asignar directamente a instancias de [Jira](/connectors/downstream/pro__jira_guide/#main-content) o de [Integrators](/connectors/downstream/downstream_toolreference/#main-content) (por ejemplo, GitHub, GitLab, ServiceNow, etc.), que envían los Hallazgos del Activo hacia sistemas externos de tickets/gestión de trabajo. +Los Activos se pueden asignar directamente a instancias de [Jira](/connectors/downstream/pro__jira_guide/#main-content) o de [Integrators](/connectors/toolreference/downstream/#main-content) (por ejemplo, GitHub, GitLab, ServiceNow, etc.), que envían los Hallazgos del Activo hacia sistemas externos de tickets/gestión de trabajo. Dado que los Hallazgos heredan el riesgo, la prioridad y la propiedad de su Activo principal, el Activo determina de forma efectiva el contexto de remediación que fluye hacia los tickets de Jira y los flujos de trabajo de Downstream Connector. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__assets.fr.md b/docs/content/asset_modelling/engagements_tests/PRO__assets.fr.md index 70f0cac93eb..f78b8b74d9a 100644 --- a/docs/content/asset_modelling/engagements_tests/PRO__assets.fr.md +++ b/docs/content/asset_modelling/engagements_tests/PRO__assets.fr.md @@ -169,7 +169,7 @@ Cela signifie qu'une même vulnérabilité peut recevoir un score de Priorité o ### Relations Jira / Connecteur en aval -Les Actifs peuvent être associés directement à des instances [Jira](/connectors/downstream/pro__jira_guide/#main-content) ou d'[Intégrateurs](/connectors/downstream/downstream_toolreference/#main-content) (par ex. GitHub, GitLab, ServiceNow, etc.), qui poussent les Constatations de l'Actif vers l'extérieur, dans des systèmes externes de gestion de tickets/travail. +Les Actifs peuvent être associés directement à des instances [Jira](/connectors/downstream/pro__jira_guide/#main-content) ou d'[Intégrateurs](/connectors/toolreference/downstream/#main-content) (par ex. GitHub, GitLab, ServiceNow, etc.), qui poussent les Constatations de l'Actif vers l'extérieur, dans des systèmes externes de gestion de tickets/travail. Étant donné que les Constatations héritent du risque, de la priorité et de la propriété de leur Actif parent, l'Actif détermine effectivement le contexte de remédiation qui alimente les tickets Jira et les flux de travail des Connecteurs en aval. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__assets.ja.md b/docs/content/asset_modelling/engagements_tests/PRO__assets.ja.md index 8227c790f3b..19c4bf81216 100644 --- a/docs/content/asset_modelling/engagements_tests/PRO__assets.ja.md +++ b/docs/content/asset_modelling/engagements_tests/PRO__assets.ja.md @@ -169,7 +169,7 @@ DefectDojo Proでは、検出事項はそれを含むアセットからSLA目標 ### Jira/ダウンストリームコネクターとの関係 -アセットは、[Jira](/connectors/downstream/pro__jira_guide/#main-content)や[インテグレーター](/connectors/downstream/downstream_toolreference/#main-content)のインスタンス(GitHub、GitLab、ServiceNowなど)に直接マッピングでき、アセットの検出事項を外部のチケット/作業管理システムに送信できます。 +アセットは、[Jira](/connectors/downstream/pro__jira_guide/#main-content)や[インテグレーター](/connectors/toolreference/downstream/#main-content)のインスタンス(GitHub、GitLab、ServiceNowなど)に直接マッピングでき、アセットの検出事項を外部のチケット/作業管理システムに送信できます。 検出事項は親アセットからリスク、優先度、所有権を継承するため、実質的にアセットが、Jiraチケットやダウンストリームコネクターのワークフローに流れ込む修復コンテキストを決定することになります。 diff --git a/docs/content/asset_modelling/engagements_tests/PRO__assets.md b/docs/content/asset_modelling/engagements_tests/PRO__assets.md index 342de6db2f3..d5a811f1d9c 100644 --- a/docs/content/asset_modelling/engagements_tests/PRO__assets.md +++ b/docs/content/asset_modelling/engagements_tests/PRO__assets.md @@ -178,7 +178,7 @@ This means that the same vulnerability may receive a different Priority or Risk ### Jira / Downstream Connector Relationships -Assets can be mapped directly to [Jira](/connectors/downstream/pro__jira_guide/#main-content) or [Integrators](/connectors/downstream/downstream_toolreference/#main-content) instances (e.g. GitHub, GitLab, ServiceNow, etc.), which push the Asset’s Findings outward into external ticketing/work-management systems. +Assets can be mapped directly to [Jira](/connectors/downstream/pro__jira_guide/#main-content) or [Integrators](/connectors/toolreference/downstream/#main-content) instances (e.g. GitHub, GitLab, ServiceNow, etc.), which push the Asset’s Findings outward into external ticketing/work-management systems. Because Findings inherit risk, priority, and ownership from their parent Asset, the Asset effectively determines the remediation context that flows into Jira tickets and Downstream Connector workflows. diff --git a/docs/content/connectors/downstream/about.de.md b/docs/content/connectors/downstream/about.de.md index baf49538983..a808f66d89a 100644 --- a/docs/content/connectors/downstream/about.de.md +++ b/docs/content/connectors/downstream/about.de.md @@ -93,20 +93,20 @@ Jeder Anbieter hat unterschiedliche Anforderungen daran, wie DefectDojo mit ihm Die vollständige Liste der Anforderungen finden Sie auf den folgenden anbieterspezifischen Seiten: -- [Azure Devops](/connectors/downstream/downstream_toolreference/#azure-devops-boards) -- [Bitbucket](/connectors/downstream/downstream_toolreference/#bitbucket) -- [Freshservice](/connectors/downstream/downstream_toolreference/#freshservice) -- [GitHub](/connectors/downstream/downstream_toolreference/#github) -- [GitLab Boards](/connectors/downstream/downstream_toolreference/#gitlab) -- [Jira](/connectors/downstream/downstream_toolreference/#jira) -- [Linear](/connectors/downstream/downstream_toolreference/#linear) -- [Opsgenie](/connectors/downstream/downstream_toolreference/#opsgenie) -- [PagerDuty](/connectors/downstream/downstream_toolreference/#pagerduty) -- [ServiceDesk Plus](/connectors/downstream/downstream_toolreference/#servicedesk-plus) -- [ServiceNow](/connectors/downstream/downstream_toolreference/#servicenow) -- [ServiceNow SecOps / Vulnerability Response](/connectors/downstream/downstream_toolreference/#servicenow-secops) -- [Shortcut](/connectors/downstream/downstream_toolreference/#shortcut) -- [Zendesk](/connectors/downstream/downstream_toolreference/#zendesk) +- [Azure Devops](/connectors/toolreference/azure_devops_boards/) +- [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector) +- [Freshservice](/connectors/toolreference/freshservice/) +- [GitHub](/connectors/toolreference/github/#downstream-connector) +- [GitLab Boards](/connectors/toolreference/gitlab/#downstream-connector) +- [Jira](/connectors/toolreference/jira/) +- [Linear](/connectors/toolreference/linear/) +- [Opsgenie](/connectors/toolreference/opsgenie/) +- [PagerDuty](/connectors/toolreference/pagerduty/) +- [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/) +- [ServiceNow](/connectors/toolreference/servicenow/) +- [ServiceNow SecOps / Vulnerability Response](/connectors/toolreference/servicenow_secops/) +- [Shortcut](/connectors/toolreference/shortcut/) +- [Zendesk](/connectors/toolreference/zendesk/) ## Fehlerbehandlung und Debugging diff --git a/docs/content/connectors/downstream/about.es.md b/docs/content/connectors/downstream/about.es.md index fb8af0f12af..1ebb33c8133 100644 --- a/docs/content/connectors/downstream/about.es.md +++ b/docs/content/connectors/downstream/about.es.md @@ -93,20 +93,20 @@ Cada proveedor tiene requisitos distintos sobre cómo debe interactuar DefectDoj Para consultar la lista completa de requisitos, abra a continuación las páginas específicas de cada proveedor: -- [Azure Devops](/connectors/downstream/downstream_toolreference/#azure-devops-boards) -- [Bitbucket](/connectors/downstream/downstream_toolreference/#bitbucket) -- [Freshservice](/connectors/downstream/downstream_toolreference/#freshservice) -- [GitHub](/connectors/downstream/downstream_toolreference/#github) -- [GitLab Boards](/connectors/downstream/downstream_toolreference/#gitlab) -- [Jira](/connectors/downstream/downstream_toolreference/#jira) -- [Linear](/connectors/downstream/downstream_toolreference/#linear) -- [Opsgenie](/connectors/downstream/downstream_toolreference/#opsgenie) -- [PagerDuty](/connectors/downstream/downstream_toolreference/#pagerduty) -- [ServiceDesk Plus](/connectors/downstream/downstream_toolreference/#servicedesk-plus) -- [ServiceNow](/connectors/downstream/downstream_toolreference/#servicenow) -- [ServiceNow SecOps / Vulnerability Response](/connectors/downstream/downstream_toolreference/#servicenow-secops) -- [Shortcut](/connectors/downstream/downstream_toolreference/#shortcut) -- [Zendesk](/connectors/downstream/downstream_toolreference/#zendesk) +- [Azure Devops](/connectors/toolreference/azure_devops_boards/) +- [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector) +- [Freshservice](/connectors/toolreference/freshservice/) +- [GitHub](/connectors/toolreference/github/#downstream-connector) +- [GitLab Boards](/connectors/toolreference/gitlab/#downstream-connector) +- [Jira](/connectors/toolreference/jira/) +- [Linear](/connectors/toolreference/linear/) +- [Opsgenie](/connectors/toolreference/opsgenie/) +- [PagerDuty](/connectors/toolreference/pagerduty/) +- [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/) +- [ServiceNow](/connectors/toolreference/servicenow/) +- [ServiceNow SecOps / Vulnerability Response](/connectors/toolreference/servicenow_secops/) +- [Shortcut](/connectors/toolreference/shortcut/) +- [Zendesk](/connectors/toolreference/zendesk/) ## Manejo de errores y depuración diff --git a/docs/content/connectors/downstream/about.fr.md b/docs/content/connectors/downstream/about.fr.md index e10b8b68071..2eaf5c65992 100644 --- a/docs/content/connectors/downstream/about.fr.md +++ b/docs/content/connectors/downstream/about.fr.md @@ -92,20 +92,20 @@ Chaque éditeur a des exigences variables quant à la façon dont DefectDojo doi Pour la liste complète des exigences, veuillez consulter les pages spécifiques à chaque éditeur ci-dessous : -- [Azure Devops](/connectors/downstream/downstream_toolreference/#azure-devops-boards) -- [Bitbucket](/connectors/downstream/downstream_toolreference/#bitbucket) -- [Freshservice](/connectors/downstream/downstream_toolreference/#freshservice) -- [GitHub](/connectors/downstream/downstream_toolreference/#github) -- [GitLab Boards](/connectors/downstream/downstream_toolreference/#gitlab) -- [Jira](/connectors/downstream/downstream_toolreference/#jira) -- [Linear](/connectors/downstream/downstream_toolreference/#linear) -- [Opsgenie](/connectors/downstream/downstream_toolreference/#opsgenie) -- [PagerDuty](/connectors/downstream/downstream_toolreference/#pagerduty) -- [ServiceDesk Plus](/connectors/downstream/downstream_toolreference/#servicedesk-plus) -- [ServiceNow](/connectors/downstream/downstream_toolreference/#servicenow) -- [ServiceNow SecOps / Vulnerability Response](/connectors/downstream/downstream_toolreference/#servicenow-secops) -- [Shortcut](/connectors/downstream/downstream_toolreference/#shortcut) -- [Zendesk](/connectors/downstream/downstream_toolreference/#zendesk) +- [Azure Devops](/connectors/toolreference/azure_devops_boards/) +- [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector) +- [Freshservice](/connectors/toolreference/freshservice/) +- [GitHub](/connectors/toolreference/github/#downstream-connector) +- [GitLab Boards](/connectors/toolreference/gitlab/#downstream-connector) +- [Jira](/connectors/toolreference/jira/) +- [Linear](/connectors/toolreference/linear/) +- [Opsgenie](/connectors/toolreference/opsgenie/) +- [PagerDuty](/connectors/toolreference/pagerduty/) +- [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/) +- [ServiceNow](/connectors/toolreference/servicenow/) +- [ServiceNow SecOps / Vulnerability Response](/connectors/toolreference/servicenow_secops/) +- [Shortcut](/connectors/toolreference/shortcut/) +- [Zendesk](/connectors/toolreference/zendesk/) ## Gestion des erreurs et débogage diff --git a/docs/content/connectors/downstream/about.ja.md b/docs/content/connectors/downstream/about.ja.md index 539b770ac8d..2219699e22d 100644 --- a/docs/content/connectors/downstream/about.ja.md +++ b/docs/content/connectors/downstream/about.ja.md @@ -92,20 +92,20 @@ Issue Tracker Assignmentは、単一の製品またはエンゲージメント 要件の完全な一覧については、以下のベンダー別ページを開いてください。 -- [Azure Devops](/connectors/downstream/downstream_toolreference/#azure-devops-boards) -- [Bitbucket](/connectors/downstream/downstream_toolreference/#bitbucket) -- [Freshservice](/connectors/downstream/downstream_toolreference/#freshservice) -- [GitHub](/connectors/downstream/downstream_toolreference/#github) -- [GitLab Boards](/connectors/downstream/downstream_toolreference/#gitlab) -- [Jira](/connectors/downstream/downstream_toolreference/#jira) -- [Linear](/connectors/downstream/downstream_toolreference/#linear) -- [Opsgenie](/connectors/downstream/downstream_toolreference/#opsgenie) -- [PagerDuty](/connectors/downstream/downstream_toolreference/#pagerduty) -- [ServiceDesk Plus](/connectors/downstream/downstream_toolreference/#servicedesk-plus) -- [ServiceNow](/connectors/downstream/downstream_toolreference/#servicenow) -- [ServiceNow SecOps / Vulnerability Response](/connectors/downstream/downstream_toolreference/#servicenow-secops) -- [Shortcut](/connectors/downstream/downstream_toolreference/#shortcut) -- [Zendesk](/connectors/downstream/downstream_toolreference/#zendesk) +- [Azure Devops](/connectors/toolreference/azure_devops_boards/) +- [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector) +- [Freshservice](/connectors/toolreference/freshservice/) +- [GitHub](/connectors/toolreference/github/#downstream-connector) +- [GitLab Boards](/connectors/toolreference/gitlab/#downstream-connector) +- [Jira](/connectors/toolreference/jira/) +- [Linear](/connectors/toolreference/linear/) +- [Opsgenie](/connectors/toolreference/opsgenie/) +- [PagerDuty](/connectors/toolreference/pagerduty/) +- [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/) +- [ServiceNow](/connectors/toolreference/servicenow/) +- [ServiceNow SecOps / Vulnerability Response](/connectors/toolreference/servicenow_secops/) +- [Shortcut](/connectors/toolreference/shortcut/) +- [Zendesk](/connectors/toolreference/zendesk/) ## エラー処理とデバッグ diff --git a/docs/content/connectors/downstream/about.md b/docs/content/connectors/downstream/about.md index 5a036d2eab0..96f60b82282 100644 --- a/docs/content/connectors/downstream/about.md +++ b/docs/content/connectors/downstream/about.md @@ -92,20 +92,20 @@ Each vendor will have varying requirements for how DefectDojo will need to inter For the complete list of requirements, please open the vendor specific pages below: -- [Azure Devops](/connectors/downstream/downstream_toolreference/#azure-devops-boards) -- [Bitbucket](/connectors/downstream/downstream_toolreference/#bitbucket) -- [Freshservice](/connectors/downstream/downstream_toolreference/#freshservice) -- [GitHub](/connectors/downstream/downstream_toolreference/#github) -- [GitLab Boards](/connectors/downstream/downstream_toolreference/#gitlab) -- [Jira](/connectors/downstream/downstream_toolreference/#jira) -- [Linear](/connectors/downstream/downstream_toolreference/#linear) -- [Opsgenie](/connectors/downstream/downstream_toolreference/#opsgenie) -- [PagerDuty](/connectors/downstream/downstream_toolreference/#pagerduty) -- [ServiceDesk Plus](/connectors/downstream/downstream_toolreference/#servicedesk-plus) -- [ServiceNow](/connectors/downstream/downstream_toolreference/#servicenow) -- [ServiceNow SecOps / Vulnerability Response](/connectors/downstream/downstream_toolreference/#servicenow-secops) -- [Shortcut](/connectors/downstream/downstream_toolreference/#shortcut) -- [Zendesk](/connectors/downstream/downstream_toolreference/#zendesk) +- [Azure Devops](/connectors/toolreference/azure_devops_boards/) +- [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector) +- [Freshservice](/connectors/toolreference/freshservice/) +- [GitHub](/connectors/toolreference/github/#downstream-connector) +- [GitLab Boards](/connectors/toolreference/gitlab/#downstream-connector) +- [Jira](/connectors/toolreference/jira/) +- [Linear](/connectors/toolreference/linear/) +- [Opsgenie](/connectors/toolreference/opsgenie/) +- [PagerDuty](/connectors/toolreference/pagerduty/) +- [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/) +- [ServiceNow](/connectors/toolreference/servicenow/) +- [ServiceNow SecOps / Vulnerability Response](/connectors/toolreference/servicenow_secops/) +- [Shortcut](/connectors/toolreference/shortcut/) +- [Zendesk](/connectors/toolreference/zendesk/) ## Error Handling and Debugging diff --git a/docs/content/connectors/downstream/downstream_toolreference.de.md b/docs/content/connectors/downstream/downstream_toolreference.de.md deleted file mode 100644 index 9f6585b4b3b..00000000000 --- a/docs/content/connectors/downstream/downstream_toolreference.de.md +++ /dev/null @@ -1,767 +0,0 @@ ---- -title: Referenz zu Downstream-Connector-Tools -description: Detaillierte Einrichtungsanleitungen für Downstream Connectors -weight: 1 -audience: pro -aliases: -- /de/en/share_your_findings/integrations_toolreference -- /de/issue_tracking/pro_integration/integrations_toolreference/ ---- - -Hier finden Sie konkrete Anweisungen dazu, wie Sie einen DefectDojo Downstream Connector mit einem Issue-Tracker eines Drittanbieters einrichten. - -## Azure DevOps Boards - -### Instanz-Einrichtung - -- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf Ihre Azure-URL gesetzt werden, zum Beispiel `https://dev.azure.com/{your organization}` -- **Token** sollte auf ein persönliches Zugriffstoken aus Azure gesetzt werden. - -Die Authentifizierung bei Azure DevOps erfordert ein [persönliches Zugriffstoken](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows) -mit der Berechtigung „Read, Write and Manage“ für „Work Items“ im Azure-Projekt, mit dem Sie arbeiten möchten. - -### Issue-Tracker-Zuordnung - -Diese Angaben legen fest, wie DefectDojo Attribute von Befunden oder Befundgruppen einem bestimmten Projekt in Azure DevOps zuordnet: - -#### Details zur Issue-Tracker-Zuordnung - -Das Feld `Project ID` entspricht dem Namen oder der ID des Projekts in Azure. - -#### Details zur Schweregrad-Zuordnung - -Die Attribute im Formular sind als Standardwerte vorbelegt und lauten wie folgt: - -- **Name des Schweregrad-Felds**: `/fields/Microsoft.VSTS.Common.Priority` -- **Info-Zuordnung**: `4` -- **Niedrig-Zuordnung**: `4` -- **Mittel-Zuordnung**: `3` -- **Hoch-Zuordnung**: `2` -- **Kritisch-Zuordnung**: `1` - -#### Details zur Status-Zuordnung - -Die Attribute im Formular sind als Standardwerte vorbelegt und lauten wie folgt: - -- **Name des Status-Felds**: `/fields/System.State` -- **Aktiv-Zuordnung**: `To Do` -- **Geschlossen-Zuordnung**: `Done` -- **Falsch-positiv-Zuordnung**: `Done` -- **Risiko-akzeptiert-Zuordnung**: `Done` - -## Bitbucket - -Die Bitbucket-Integration ermöglicht es Ihnen, Issues in den [Issue-Tracker](https://support.atlassian.com/bitbucket-cloud/docs/enable-an-issue-tracker/) eines Bitbucket-Cloud-Repositorys zu übertragen. - -Der Issue-Tracker ist in Bitbucket optional und muss im Repository aktiviert werden, bevor DefectDojo dort Issues erstellen kann. Öffnen Sie zum Aktivieren das Repository in Bitbucket, wählen Sie **Repository settings** und aktivieren Sie den Issue-Tracker anschließend unter **Features**. - -### Instanz-Einrichtung - -- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf `https://bitbucket.org` gesetzt werden. -- **Email** sollte die E-Mail-Adresse des Atlassian-Kontos sein, zu dem das API-Token gehört. -- **API Token** sollte auf ein Atlassian-API-Token mit Scopes gesetzt werden. - -Bitbucket-App-Passwörter wurden von Atlassian abgekündigt und funktionieren mit dieser Integration nicht. So erstellen Sie ein API-Token: - -1. Öffnen Sie die [Atlassian-Kontoeinstellungen](https://id.atlassian.com/manage-profile/security/api-tokens) und wählen Sie **Security** und dann **Create and manage API tokens**. -2. Wählen Sie **Create API token with scopes**, benennen Sie das Token und legen Sie ein Ablaufdatum fest. -3. Wählen Sie **Bitbucket** als App aus. -4. Erteilen Sie dem Token die Berechtigung, Repositorys zu lesen sowie Issues zu lesen und zu schreiben. - -### Issue-Tracker-Zuordnung - -- **Workspace** sollte der Slug des Workspace sein, der das Repository enthält, so wie er in bitbucket.org-URLs erscheint. -- **Repository Slug** sollte der Slug des Repositorys sein, in dem Sie Issues erstellen möchten. - -### Details zur Schweregrad-Zuordnung - -Dies wird dem Bitbucket-Feld „Priority“ eines Issues zugeordnet. Die Attribute im Formular sind als Standardwerte vorbelegt, und jeder Wert muss eine der Bitbucket-Prioritäten sein: `trivial`, `minor`, `major`, `critical` oder `blocker`. - -- **Name des Schweregrad-Felds**: `priority` -- **Info-Zuordnung**: `trivial` -- **Niedrig-Zuordnung**: `minor` -- **Mittel-Zuordnung**: `major` -- **Hoch-Zuordnung**: `critical` -- **Kritisch-Zuordnung**: `blocker` - -### Details zur Status-Zuordnung - -Dies wird dem Bitbucket-Feld „State“ eines Issues zugeordnet. Jeder Wert muss einer der Bitbucket-Issue-Status sein: `new`, `open`, `resolved`, `on hold`, `invalid`, `duplicate`, `wontfix` oder `closed`. - -- **Name des Status-Felds**: `state` -- **Aktiv-Zuordnung**: `new` -- **Geschlossen-Zuordnung**: `resolved` -- **Falsch-positiv-Zuordnung**: `invalid` -- **Risiko-akzeptiert-Zuordnung**: `wontfix` - -## GitHub - -Die GitHub-Integration ermöglicht es Ihnen, Issues zu einem [GitHub Project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects) hinzuzufügen, wodurch außerdem Issues in einem zugehörigen Repo geöffnet werden. Diese Repos/Projects können entweder mit einer GitHub-Organisation oder mit einem persönlichen GitHub-Konto verknüpft sein. - -### Instanz-Einrichtung - -- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf die URL Ihres GitHub-Benutzers oder Ihrer GitHub-Organisation gesetzt werden, je nachdem, wo Sie Issues erstellen möchten, zum Beispiel `https://github.com/{your-organization}` -- **Token** sollte auf ein persönliches Zugriffstoken aus GitHub gesetzt werden. - -Persönliche Zugriffstoken für GitHub können unter https://github.com/settings/tokens erstellt werden. Das Token muss die Scopes „Repo“ und „Project“ besitzen. - -### Issue-Tracker-Zuordnung - -- **Issue Tracker Mapping Label** sollte so gesetzt werden, dass es das Project oder Repo identifiziert, in dem Sie Issues erstellen möchten. -- **Project Number** sollte die ID eines GitHub-Projects sein, an das Sie Elemente senden möchten. Sie finden sie in der URL, während Sie ein Project ansehen, zum Beispiel `https://github.com/orgs/{your-org}/projects/{project number}`. -- **Repository Name** sollte der Name eines Repos sein, das Ihrer Organisation (oder Ihrem Benutzer) zugeordnet ist und in das Sie Issues übertragen möchten. - - -### Details zur Schweregrad-Zuordnung - -**Damit die Integration eingerichtet werden kann, MUSS im Project ein benutzerdefiniertes Feld für die Issue-Priorität angelegt sein, andernfalls wird der Schweregrad nicht korrekt zugeordnet und Issues werden nicht an GitHub übertragen.** - -Folgen Sie dieser Anleitung, um ein [benutzerdefiniertes Feld](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/quickstart-for-projects#creating-a-field-to-track-priority) zu erstellen. -Für jeden Schweregrad muss eine entsprechende Single-Select-Option verfügbar sein. Standardmäßig schlägt DefectDojo zum Beispiel P0, P1, P2, P3, P4 als mögliche Prioritätswerte vor, und jeder dieser Werte muss dem benutzerdefinierten Feld „Priority“ hinzugefügt werden. - -- **Name des Schweregrad-Felds**: `Priority` -- **Info-Zuordnung**: `P0` -- **Niedrig-Zuordnung**: `P1` -- **Mittel-Zuordnung**: `P2` -- **Hoch-Zuordnung**: `P3` -- **Kritisch-Zuordnung**: `P4` - -### Details zur Status-Zuordnung - -Standardmäßig haben neue GitHub Projects für Issues die Status „In Progress“ und „Done“. Dem Project können weitere Status hinzugefügt werden, um bei Bedarf den Status Falsch-positiv oder Risiko akzeptiert nachzuverfolgen. Eine Möglichkeit dafür ist, dem Project-Board eine neue Statusspalte hinzuzufügen. - -- **Name des Status-Felds**: `Status` -- **Aktiv-Zuordnung**: `In Progress` -- **Geschlossen-Zuordnung**: `Done` -- **Falsch-positiv-Zuordnung**: `Done` -- **Risiko-akzeptiert-Zuordnung**: `Done` - -## GitLab - -Die GitLab-Integration ermöglicht es Ihnen, Issues zu einem [GitLab-Projekt](https://docs.gitlab.com/ee/user/project/) hinzuzufügen. - -### Instanz-Einrichtung - -- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf den Link zu Ihrem GitLab-Server gesetzt werden, zum Beispiel `https://gitlab.com/`. -- **Token** sollte auf ein persönliches Zugriffstoken aus GitLab gesetzt werden. Das Token muss API-Scopes besitzen. Siehe [GitLabs Anleitung zum Erstellen eines persönlichen Zugriffstokens](https://docs.gitlab.com/user/profile/personal_access_tokens/#create-a-personal-access-token). - -### Issue-Tracker-Zuordnung - -- **Project Name**: Der Name des Projekts in GitLab, an das Sie Issues senden möchten. - -### Details zur Schweregrad-Zuordnung - -Dies wird dem GitLab-Feld „Priority“ zugeordnet. -- **Name des Schweregrad-Felds**: `Priority` -- **Info-Zuordnung**: `1` -- **Niedrig-Zuordnung**: `2` -- **Mittel-Zuordnung**: `3` -- **Hoch-Zuordnung**: `4` -- **Kritisch-Zuordnung**: `5` - -### Details zur Status-Zuordnung - -Standardmäßig kennt GitLab die Status „opened“ und „closed“. Zusätzliche Status-Labels können hinzugefügt werden, wenn Sie den Status Falsch-positiv oder Risiko akzeptiert nachverfolgen möchten. Details finden Sie in den [GitLab-Docs](https://docs.gitlab.com/user/work_items/status/). - -- **Name des Status-Felds**: `Status` -- **Aktiv-Zuordnung**: `opened` -- **Geschlossen-Zuordnung**: `closed` -- **Falsch-positiv-Zuordnung**: `closed` -- **Risiko-akzeptiert-Zuordnung**: `closed` - -## Jira - -Die Jira-Integration überträgt DefectDojo-Befunde und Befundgruppen als Issues in ein Jira-Projekt, hält den Status jedes Issues mit dem Befund synchron und verknüpft den Befund mit dem erstellten Issue. Sowohl Jira **Cloud** als auch **Data Center / Server** werden unterstützt. Jira Service Management wird nicht unterstützt. - -### Auswahl einer Authentifizierungsmethode - -Legen Sie zuerst **Jira Deployment** fest und wählen Sie dann eine **Authentication Method**: - -**Jira Cloud** -- **API Token (E-Mail + Token)** – HTTP-Basic-Authentifizierung mit der E-Mail-Adresse eines Atlassian-Kontos und einem [API-Token](https://id.atlassian.com/manage-profile/security/api-tokens). Aufrufe gehen direkt an Ihre Site-URL. -- **OAuth 2.0 (empfohlen)** – eine einmalige Zustimmung im Browser; DefectDojo bezieht und erneuert die Token für Sie. -- **Service Account Token** – ein API-Token mit Scopes, das für ein Atlassian-[Servicekonto](https://support.atlassian.com/user-management/docs/manage-api-tokens-for-service-accounts/) erstellt wurde. - -**Jira Data Center / Server** -- **Personal Access Token (empfohlen)** -- **Benutzername + Passwort** - -> **Wie die Cloud-Authentifizierung Jira erreicht:** OAuth 2.0 und Service Account authentifizieren sich beide per Bearer-Token gegenüber Atlassians Gateway – `https://api.atlassian.com/ex/jira/{cloudId}` – und das ist ein *anderer Host* als Ihre Site-URL `https://your-site.atlassian.net`. DefectDojo verwendet für jeden API-Aufruf das Gateway, bildet den auf einem Befund angezeigten Ticket-Link jedoch immer aus Ihrer **Site-URL**, sodass der Link, den ein Benutzer anklickt, ein normaler, im Browser aufrufbarer `.../browse/{ISSUE-KEY}`-Link ist. (Bei API-Token- und Data-Center-Authentifizierung wird die Site-URL direkt aufgerufen, es gibt dort also keine Aufteilung.) - -### Instanz-Einrichtung - -- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf Ihre Jira-**Site-URL** gesetzt werden, zum Beispiel `https://your-organization.atlassian.net`. Sie wird für die im Browser aufrufbaren Ticket-Links verwendet und – bei API-Token- und Data-Center-Authentifizierung – als API-Basis-URL. -- Die übrigen Felder hängen von der oben gewählten Methode ab (E-Mail + API-Token, OAuth-Client-Anmeldedaten, Servicekonto-Token, PAT oder Benutzername + Passwort). - -### OAuth-2.0-Einrichtung (Cloud) - -Erstellen Sie eine dedizierte App in der [Atlassian Developer Console](https://developer.atlassian.com/console/myapps/) und verbinden Sie sie anschließend aus DefectDojo heraus. - -1. Wählen Sie **Create → OAuth 2.0 integration**. Es muss eine *OAuth 2.0 integration* sein – eine Connect- oder Forge-App kann den 3LO-Authorization-Code-Grant nicht nutzen (Sie würden `grant_type is not enabled for client` erhalten). -2. Wählen Sie bei der Frage nach dem **Access type** die Option **Resource-level**. Damit wird das Token auf die eine Jira-Site beschränkt, die der Benutzer autorisiert – genau das, worauf eine DefectDojo-Verbindung zielt. (**Account-level** gewährt Zugriff auf jede Site des Atlassian-Kontos – mehr als erforderlich.) -3. Fügen Sie unter **Permissions** die **Jira platform REST API** hinzu und erteilen Sie die unten aufgeführten Scopes. Hinweis: `offline_access` ist hier *nicht* aufgeführt – es ist ein Standard-OAuth-Scope, den DefectDojo in der Autorisierungs-URL anfordert, und nichts, das Sie auf diesem Bildschirm hinzufügen. -4. Klicken Sie unter **Authorization** neben **OAuth 2.0 (3LO)** auf **Configure** und setzen Sie die **Callback URL** auf `https:///integrators/jira/oauth/callback` – sie muss exakt Ihrer DefectDojo-Site-URL entsprechen. Erst dadurch werden der Authorization-Code-Grant und Refresh-Token aktiviert; wird dies übersprungen, treten die Fehler `grant_type is not enabled` / `Client is not allowed to use offline_access` auf. -5. Kopieren Sie die **Client ID** und das **Client Secret** in das DefectDojo-Formular und klicken Sie auf **Submit**, um die Verbindung zu speichern. -6. Klicken Sie auf **Connect with Jira** und bestätigen Sie den Zustimmungsbildschirm. Atlassian leitet zurück zu DefectDojo, das die Token speichert und Ihre `cloudId` automatisch auflöst. Bei Erfolg erscheint die Anzeige „Connected“. - -> Der Callback-Host ist die `SITE_URL` Ihrer DefectDojo-Instanz. Atlassian muss den Browser dorthin weiterleiten können, und der Wert muss exakt dem entsprechen, was DefectDojo sendet – verwenden Sie deshalb den echten Hostnamen, über den Ihre Benutzer DefectDojo erreichen, und keinen Wert, der nur aus dem internen Netzwerk erreichbar ist. - -#### Minimale OAuth-Scopes - -DefectDojo fordert standardmäßig diese vier klassischen Scopes an, und sie sind gleichzeitig das **absolute Minimum** – jeder davon deckt ein bestimmtes Verhalten ab: - -| Scope | Erforderlich für | -|-------|--------------| -| `read:jira-work` | Lesen des Projekts, der Issues und der verfügbaren Übergänge (Verbindungsprüfung und Statussynchronisierung). | -| `write:jira-work` | Erstellen und Bearbeiten von Issues sowie Ausführen von Statusübergängen. | -| `read:jira-user` | Die Identitätsprüfung der Verbindung – DefectDojo ruft beim Prüfen des Zugriffs `/myself` auf. | -| `offline_access` | Ausgeben eines **Refresh-Tokens**. Ohne ihn läuft das Access-Token ab (etwa eine Stunde nach dem Verbinden) und die Verbindung funktioniert nicht mehr, weil DefectDojo es nicht länger erneuern kann. | - -Atlassian empfiehlt klassische Scopes gegenüber granularen; die vier oben genannten halten den Footprint der App minimal und genügen für alles, was die Integration tut. - -##### Alternative mit granularen Scopes - -Wenn Ihre Organisation **granulare** Scopes anstelle klassischer verlangt, lautet der minimale äquivalente Satz: - -| Granularer Scope | Erforderlich für | -|----------------|--------------| -| `read:user:jira` | Die Identitätsprüfung über `/myself`. | -| `read:project:jira` | Prüfen, ob das Zielprojekt existiert. | -| `read:issue:jira` | Lesen des aktuellen Status eines Issues während der Synchronisierung. | -| `write:issue:jira` | Erstellen und Bearbeiten von Issues **sowie Ausführen von Statusübergängen** – es gibt keinen separaten Schreib-Scope für Übergänge, denn ein Übergang ist ein Schreibvorgang am Issue. | -| `read:issue.transition:jira` | Auflisten der für ein Issue verfügbaren Übergänge. | -| `offline_access` | Das Refresh-Token (wie bei den klassischen Scopes). | - -Je nach Feldkonfiguration Ihrer Site kann ein Endpunkt zusätzlich begleitende Lese-Scopes benötigen, um Felder zu expandieren – am häufigsten `read:status:jira` und `read:field:jira` (sowie `read:issue-meta:jira` beim Erstellen). Schlägt eine Übertragung mit einem `403`-Fehler „scope does not match“ fehl, fügen Sie genau den im Fehler genannten Scope hinzu. Genau dieses Ausufern begleitender Scopes ist der Grund, warum klassische Scopes empfohlen werden. - -Für die Methode **Service Account Token** erteilen Sie dem Token `read:jira-work` und `write:jira-work` (sowie `read:jira-user`) – oder die oben genannten granularen Entsprechungen ohne `offline_access`. `offline_access` ist hier nicht relevant – ein Servicekonto-Token ist langlebig und wird von DefectDojo nicht erneuert. - -### Issue-Tracker-Zuordnung - -- **Project Key**: der Schlüssel des Jira-Projekts, in dem Issues erstellt werden, zum Beispiel `SEC`. -- **Issue Type**: der zu erstellende Issue-Typ, zum Beispiel `Bug` oder `Task`. Standard ist `Bug`. - -### Details zur Schweregrad-Zuordnung - -Die Standardwerte entsprechen dem Standard-Prioritätsschema von Jira. Passen Sie sie an die Prioritätsnamen in Ihrem Projekt an: - -- **Name des Schweregrad-Felds**: `priority` -- **Info-Zuordnung**: `Lowest` -- **Niedrig-Zuordnung**: `Low` -- **Mittel-Zuordnung**: `Medium` -- **Hoch-Zuordnung**: `High` -- **Kritisch-Zuordnung**: `Highest` - -### Details zur Status-Zuordnung - -Status unterscheiden sich je nach Projekt-Workflow, daher sind diese Standardwerte dafür gedacht, an die Statusnamen **Ihres** Workflows angepasst zu werden: - -- **Name des Status-Felds**: `status` -- **Aktiv-Zuordnung**: `To Do` -- **Geschlossen-Zuordnung**: `Done` -- **Falsch-positiv-Zuordnung**: `Done` -- **Risiko-akzeptiert-Zuordnung**: `Done` - -### Benutzerdefinierte Felder (optional) - -Sie können weitere Jira-Felder zuordnen – zum Beispiel eine beim Schließen erforderliche `resolution` oder `labels` – und zwar im Schritt **Custom Fields** der Zuordnung. Jede Zuordnung eines benutzerdefinierten Felds besteht aus vier Teilen: - -- **Source** – woher der Wert kommt: ein Attribut des übertragenen **Befunds**, **Tests**, **Engagements** oder **Assets** oder ein **statischer Wert**. -- **Value** – bei einer Objektquelle das konkrete auszulesende Attribut, ausgewählt aus einer Liste der Felder dieses Objekts mit lesbaren Bezeichnungen (zum Beispiel *Schweregrad*, *CVE*, *Mitigation*). Bei der Quelle **Static value** ist dies ein Freitextfeld, in das Sie den wörtlichen Wert eingeben. -- **Vendor Field** – das Jira-Feld, in das geschrieben wird. Da DefectDojo den Feldkatalog von Jira lesen kann, ist dies eine durchsuchbare Auswahl, die jedes Feld mit seinem **Anzeigenamen** auflistet und für Sie in die interne ID auflöst – Sie wählen also *DD Close Justification* und DefectDojo speichert `customfield_10255`. Die Auswahl wird aus der Verbindung befüllt und funktioniert daher, sobald die Verbindung gespeichert und geprüft ist. -- **Application point** – *wann* das Feld gesendet wird: bei der **Ticket-Erstellung**, bei **jeder Aktualisierung** oder als Teil eines bestimmten Status-**Übergangs** (Aktiv / Geschlossen / Falsch-positiv / Risiko akzeptiert). Ein auf einen Übergang beschränktes Feld wird als Teil der Bearbeitung dieses Übergangs gesendet – so liefern Sie einen Wert, den Jira nur auf einem Übergangsbildschirm akzeptiert, meist eine `resolution`, die Ihr Workflow beim Auflösen eines Issues verlangt. - -### Ticket-Vorlagen (optional) - -Standardmäßig verwenden Jira-Issues den integrierten Titel und Textkörper von DefectDojo. Um sie anzupassen, hängen Sie im Schritt **Ticket Template** der Zuordnung eine **Ticket-Vorlage** an. Eine Vorlage definiert vier unabhängig voneinander optionale Bestandteile – Zusammenfassung und Beschreibung für den **Befund** sowie Zusammenfassung und Beschreibung für die **Befundgruppe**. Jeder leer gelassene Bestandteil fällt auf den integrierten Standard zurück, sodass Sie nur den Titel, nur den Textkörper oder alle vier überschreiben können. Verwenden Sie **Test render** im Vorlagen-Editor, um die gerenderte Ausgabe anhand von Beispieldaten vorab zu prüfen – so erkennen Sie Fehler wie unbekannte Platzhalter oder Werte, die die Längenbegrenzung eines Felds überschreiten – bevor Sie speichern. Wird eine Vorlage später gelöscht, fallen die Zuordnungen, die sie verwendet haben, automatisch auf die integrierten Standardwerte zurück. - -### Funktionsweise - -- **Erstellen / Aktualisieren / Löschen:** Beim Erstellen wird ein neues Issue übertragen und der Link am Befund vermerkt; beim Aktualisieren wird das bestehende Issue bearbeitet; beim Löschen eines Befunds wird sein Issue zwangsweise geschlossen (in Jira wird nichts gelöscht). Übertragungen können manuell erfolgen („Push to Integrator“) oder automatisch gemäß der Issue-Tracker-Zuweisung. -- **Statusabgleich:** Nach dem Erstellen (und bei jeder Aktualisierung) liest DefectDojo den aktuellen Status des Issues und sucht, falls er vom zugeordneten Ziel abweicht, einen einzelnen Workflow-Übergang, der ihn erreicht, und wendet diesen an. Existiert kein solcher Übergang, vermerkt die Zuordnung einen Fehler, anstatt stillschweigend zu scheitern. Alle auf Übergänge beschränkten benutzerdefinierten Felder werden mit diesem Übergang gesendet. -- **Ticket-Link:** Der am Befund angezeigte Link ist `https://your-site.atlassian.net/browse/{ISSUE-KEY}` – immer Ihre öffentliche Site-URL, niemals das interne Gateway. -- **Token-Lebenszyklus (OAuth):** DefectDojo verantwortet den gesamten Ablauf – es führt den Authorization-Code-Austausch durch, speichert Access- und Refresh-Token und erneuert sie bei Bedarf vor einer Übertragung, wobei das neue Refresh-Token jedes Mal gespeichert wird (Atlassian rotiert es bei jeder Erneuerung). -- **Speicherung der Anmeldedaten:** Alle Verbindungsdaten (Passwörter, Token, Client Secrets, OAuth-Token) werden verschlüsselt gespeichert und niemals über die API zurückgegeben – beim Bearbeiten einer Verbindung erscheint für gespeicherte Geheimnisse ein Platzhalter „leer lassen, um beizubehalten“. - -## Linear - -Die Linear-Integration ermöglicht es Ihnen, DefectDojo-Befunde als [Linear](https://linear.app/)-Issues zu übertragen. Issues werden in einem Team in Ihrem Linear-Workspace erstellt. - -### Instanz-Einrichtung - -- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf `https://api.linear.app/graphql` gesetzt werden. -- **API Key** sollte auf einen persönlichen Linear-API-Key gesetzt werden. Keys können in Linear unter „Settings“, dann „Security & access“, dann [API](https://linear.app/settings/account/security) generiert werden. Der Key wird im Header `Authorization` an die GraphQL-API von Linear gesendet. - -### Issue-Tracker-Zuordnung - -- **Team (Group) ID** sollte auf die ID des Linear-Teams gesetzt werden, für das Issues erstellt werden. Sie können Ihre Teams und deren IDs auflisten, indem Sie die Linear-GraphQL-API aufrufen: - -``` -curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ - -d '{"query":"{ teams { nodes { id name key } } }"}' https://api.linear.app/graphql -``` - -### Details zur Schweregrad-Zuordnung - -Ein Linear-Issue trägt eine numerische **Priorität** anstelle eines Schweregrad-Felds. Jeder DefectDojo-Schweregrad wird einer Linear-Priorität zugeordnet, wobei `1` „Urgent“ und `4` „Low“ bedeutet: - -- **Name des Schweregrad-Felds**: `Priority` -- **Info-Zuordnung**: `4` -- **Niedrig-Zuordnung**: `4` -- **Mittel-Zuordnung**: `3` -- **Hoch-Zuordnung**: `2` -- **Kritisch-Zuordnung**: `1` - -### Details zur Status-Zuordnung - -Jeder Statuswert muss auf die ID eines Workflow-States in Ihrem Linear-Team gesetzt werden. Workflow-State-IDs sind je Workspace eindeutig, daher gibt es keine Standardwerte. Sie können die Workflow-States und ihre IDs auflisten, indem Sie die Linear-GraphQL-API aufrufen: - -``` -curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ - -d '{"query":"{ workflowStates { nodes { id name type team { key } } } }"}' https://api.linear.app/graphql -``` - -- **Name des Status-Felds**: `Workflow State ID` -- **Aktiv-Zuordnung**: die ID eines gestarteten oder noch nicht gestarteten States, zum Beispiel `Todo` oder `In Progress`. -- **Geschlossen-Zuordnung**: die ID eines abgeschlossenen States, zum Beispiel `Done`. Wenn ein Befund in DefectDojo gelöscht wird, wird sein Issue in diesen State verschoben. - -## Opsgenie - -Die Opsgenie-Integration ermöglicht es Ihnen, DefectDojo-Befunde und Befundgruppen als Opsgenie-Alerts zu übertragen, die optional an ein Opsgenie-Team als Responder geleitet werden. - -### Instanz-Einrichtung - -- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf `https://api.opsgenie.com` gesetzt werden. Wird Ihr Opsgenie-Konto in der EU-Serviceregion gehostet, verwenden Sie stattdessen `https://api.eu.opsgenie.com`. Liegen Ihre Alerts in Jira Service Management Operations (Atlassian überführt Opsgenie in JSM), verwenden Sie `https://api.atlassian.com/jsm/ops/integration`. -- **API Key** sollte auf einen Opsgenie-**API-Integrations**-Key gesetzt werden. Ein Kontoadministrator kann einen solchen in der Opsgenie-Web-App unter **Settings > Integrations** erstellen: Fügen Sie eine Integration des Typs **API** hinzu und erteilen Sie ihr *Create and Update Access* (sowie *Read Access*, damit DefectDojo die Verbindung prüfen kann). Beachten Sie, dass dies ein Integrations-Key und kein persönlicher API-Key ist - DefectDojo authentifiziert sich mit `GenieKey`-Autorisierung, die nur Integrations-Keys unterstützen. - -### Issue-Tracker-Zuordnung - -- **Team Name** *(optional)* sollte der Name des Opsgenie-Teams sein, das erstellten Alerts als Responder hinzugefügt wird. Sie können das Feld leer lassen: Ist der API-Integrations-Key teambezogen, werden Alerts automatisch an dieses Team geleitet, andernfalls entscheiden die Routing-Regeln Ihres Kontos über die Responder. - -### Details zur Schweregrad-Zuordnung - -Schweregrade werden dem Opsgenie-Alert-Feld **Priority** zugeordnet, das die feste Opsgenie-Skala von `P1` (kritisch) bis `P5` (informativ) verwendet: - -- **Name des Schweregrad-Felds**: `Priority` -- **Info-Zuordnung**: `P5` -- **Niedrig-Zuordnung**: `P4` -- **Mittel-Zuordnung**: `P3` -- **Hoch-Zuordnung**: `P2` -- **Kritisch-Zuordnung**: `P1` - -Ist ein Schweregrad einem unbekannten Wert zugeordnet, wird die Priorität weggelassen und Opsgenie wendet seinen eigenen Standard (`P3`) an. - -### Details zur Status-Zuordnung - -Opsgenie-Alerts sind `open` oder `closed`, und ein offener Alert kann zusätzlich `acknowledged` sein: - -- **Name des Status-Felds**: `Status` -- **Aktiv-Zuordnung**: `open` -- **Geschlossen-Zuordnung**: `closed` -- **Falsch-positiv-Zuordnung**: `closed` -- **Risiko-akzeptiert-Zuordnung**: `acknowledged` - -Beachten Sie, dass `closed` in Opsgenie ein endgültiger Status ist - ein geschlossener Alert kann nicht wieder geöffnet werden, und sein Alias wird freigegeben. Anders als manche anderen Tools erlaubt Opsgenie Inhaltsänderungen nach dem Erstellen, sodass beim Übertragen eines aktualisierten Befunds neben dem Status auch Nachricht, Beschreibung und Priorität synchronisiert werden. - -DefectDojo setzt den **Alias** jedes Alerts auf einen stabilen Schlüssel, der vom Befund oder von der Befundgruppe abgeleitet ist, und Opsgenie dedupliziert offene Alerts anhand des Alias - ein erneutes Übertragen desselben Befunds aktualisiert daher den bestehenden offenen Alert, anstatt ein Duplikat zu erzeugen. - -## PagerDuty - -Die PagerDuty-Integration ermöglicht es Ihnen, DefectDojo-Befunde und Befundgruppen als PagerDuty-Incidents zu übertragen, die auf einem PagerDuty-Service Ihrer Wahl eröffnet werden. - -### Instanz-Einrichtung - -- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf `https://api.pagerduty.com` gesetzt werden. Wird Ihr PagerDuty-Konto in der EU-Serviceregion gehostet, verwenden Sie stattdessen `https://api.eu.pagerduty.com`. -- **API Token** sollte auf einen PagerDuty-REST-API-Key gesetzt werden. Ein Kontoadministrator kann einen solchen in der PagerDuty-Web-App unter **Integrations > API Access Keys > Create New API Key** erstellen. Lassen Sie „Read-only“ deaktiviert - DefectDojo muss Incidents erstellen und aktualisieren. -- **From Email** sollte die E-Mail-Adresse eines gültigen Benutzers in Ihrem PagerDuty-Konto sein. PagerDuty verlangt diese Adresse beim Erstellen oder Aktualisieren von Incidents, und sie wird als Anforderer des Incidents angezeigt. - -### Issue-Tracker-Zuordnung - -- **Service ID** sollte die ID des PagerDuty-Services sein, auf dem Incidents eröffnet werden. Sie finden sie am Ende der URL, während Sie den Service in PagerDuty ansehen, zum Beispiel `https://{your-subdomain}.pagerduty.com/service-directory/{service id}`. - -### Details zur Schweregrad-Zuordnung - -Standardmäßig wird dies dem PagerDuty-Incident-Feld **Urgency** zugeordnet, das nur `high` oder `low` akzeptiert: - -- **Name des Schweregrad-Felds**: `Urgency` -- **Info-Zuordnung**: `low` -- **Niedrig-Zuordnung**: `low` -- **Mittel-Zuordnung**: `low` -- **Hoch-Zuordnung**: `high` -- **Kritisch-Zuordnung**: `high` - -Alternativ können Sie, wenn in Ihrem PagerDuty-Konto [Priorities](https://support.pagerduty.com/main/docs/incident-priority) aktiviert sind, Schweregrade stattdessen Prioritätsnamen zuordnen. Setzen Sie den **Namen des Schweregrad-Felds** auf `Priority` und verwenden Sie die Prioritätsnamen Ihres Kontos (zum Beispiel `P1` bis `P5`) als Zuordnungswerte. Bei einer Zuordnung auf Priority bleibt die Urgency des Incidents den Urgency-Regeln Ihres Services überlassen. - -### Details zur Status-Zuordnung - -PagerDuty-Incidents haben drei Status: `triggered`, `acknowledged` und `resolved`. - -- **Name des Status-Felds**: `Status` -- **Aktiv-Zuordnung**: `triggered` -- **Geschlossen-Zuordnung**: `resolved` -- **Falsch-positiv-Zuordnung**: `resolved` -- **Risiko-akzeptiert-Zuordnung**: `acknowledged` - -Beachten Sie, dass `resolved` in PagerDuty ein endgültiger Status ist - ein aufgelöster Incident kann nicht wieder geöffnet werden. Beachten Sie außerdem, dass PagerDuty es nicht erlaubt, Titel oder Beschreibung eines Incidents nach dem Erstellen zu bearbeiten; beim Übertragen eines aktualisierten Befunds werden daher Status, Urgency und Priority synchronisiert, Inhaltsänderungen jedoch nicht. - -## ServiceNow - -Die ServiceNow-Integration ermöglicht es Ihnen, DefectDojo-Befunde als ServiceNow-Incidents zu übertragen. - -### Instanz-Einrichtung - -DefectDojo authentifiziert sich bei ServiceNow über OAuth 2.0. Wie Sie die OAuth-Anmeldedaten erstellen, hängt von Ihrem ServiceNow-Release ab – neuere Releases (Zurich und später) verwenden einen Client-Credentials-Grant, frühere Releases ein Refresh-Token. - -#### ServiceNow Zurich und später (Client Credentials) - -In neueren ServiceNow-Releases wurde die klassische Option „Create an OAuth API endpoint for external clients“ zugunsten der **New Inbound Integration Experience** abgekündigt, die einen an ein Servicekonto gebundenen OAuth-**Client-Credentials**-Grant ausgibt: - -1. Suchen Sie in der linken Navigationsleiste nach „Application Registry“ und wählen Sie den Eintrag aus. -2. Klicken Sie auf **New** und wählen Sie dann **New Inbound Integration Experience**. -3. Wählen Sie **New Integration → OAuth - Client credentials grant**. -4. Setzen Sie den **OAuth Application User** auf das Servicekonto, das die Incidents erstellen wird. Die Rollen dieses Kontos bestimmen, was DefectDojo schreiben darf. -5. Speichern Sie die Registrierung. ServiceNow generiert **Client ID** und **Client Secret** automatisch (lassen Sie diese Felder beim Erstellen der Registrierung leer). - -Anschließend in DefectDojo: - -- **Instance Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf die URL Ihres ServiceNow-Servers gesetzt werden, zum Beispiel `https://your-organization.service-now.com/`. -- **Client ID** sollte die Client ID aus der OAuth-Registrierung sein. -- **Client Secret** sollte das Client Secret aus der OAuth-Registrierung sein. - -Lassen Sie die Felder Refresh Token, Username und Password leer – DefectDojo fordert für jede Synchronisierung ein frisches Client-Credentials-Token an. - -#### Frühere ServiceNow-Releases (Refresh-Token) - -Bei Releases, die noch die klassische Registrierung anbieten, benötigen Sie ein Refresh-Token, das dem Benutzer- oder Servicekonto zugeordnet ist, das Incidents an ServiceNow überträgt: - -1. Suchen Sie in der linken Navigationsleiste nach „Application Registry“ und wählen Sie den Eintrag aus. -2. Klicken Sie auf „New“. -3. Wählen Sie „Create an OAuth API endpoint for external clients“. -4. Füllen Sie die erforderlichen Felder aus: - * Name: Geben Sie Ihrer Anwendung einen sinnvollen Namen (z. B. Vulnerability Integration Client). - * (Optional) Passen Sie die Token-Lebensdauer an: - * Access Token Lifespan: Standard sind 1800 Sekunden (30 Minuten). - * Refresh Token Lifespan: Standard sind 8640000 Sekunden (etwa 100 Tage). -5. Klicken Sie auf „Submit“, um den Anwendungsdatensatz zu erstellen. -6. Wählen Sie die Anwendung nach dem Absenden aus der Liste aus und notieren Sie sich die Felder **Client ID und Client Secret**. - -Anschließend müssen Sie mit dieser Registrierung ein Refresh-Token beziehen, was nur über die ServiceNow-API möglich ist. Öffnen Sie ein Terminalfenster und fügen Sie Folgendes ein (ersetzen Sie dabei die in `{{}}` eingeschlossenen Variablen durch die tatsächlichen Angaben Ihres Benutzers) - -``` -curl --request POST \ - --url {{INSTANCE_HOST}}/oauth_token.do \ - --header 'content-type: application/x-www-form-urlencoded' \ - --data grant_type=password \ - --data 'client_id={{CLIENT_ID}}' \ - --data 'client_secret={{CLIENT_SECRET}}' \ - --data 'username={{USERNAME}}' \ - --data 'password={{PASSWORD}}' - ``` - -Wenn Ihre ServiceNow-Anmeldedaten korrekt sind und Zugriff auf Administratorebene in ServiceNow erlauben, sollten Sie eine Antwort mit einem RefreshToken erhalten. Dieses Token benötigen Sie, um die Integration mit DefectDojo abzuschließen. - -- **Instance Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf die URL Ihres ServiceNow-Servers gesetzt werden, zum Beispiel `https://your-organization.service-now.com/`. -- **Refresh Token** ist das Feld, in das das Refresh-Token eingetragen wird. -- **Client ID** sollte die in der OAuth-App-Registrierung festgelegte Client ID sein. -- **Client Secret** sollte das in der OAuth-App-Registrierung festgelegte Client Secret sein. - -### Details zur Schweregrad-Zuordnung - -Dies wird dem ServiceNow-Feld „Impact“ zugeordnet. -- **Info-Zuordnung**: `1` -- **Niedrig-Zuordnung**: `1` -- **Mittel-Zuordnung**: `2` -- **Hoch-Zuordnung**: `3` -- **Kritisch-Zuordnung**: `3` - -### Details zur Status-Zuordnung - -- **Name des Status-Felds**: `State` -- **Aktiv-Zuordnung**: `New` -- **Geschlossen-Zuordnung**: `Closed` -- **Falsch-positiv-Zuordnung**: `Resolved` -- **Risiko-akzeptiert-Zuordnung**: `Resolved` - -Jede Zuordnung akzeptiert eine Standard-Statusbezeichnung (`New`, `In Progress`, `On Hold`, `Resolved`, `Closed`, `Cancelled`) oder einen numerischen Statuswert. Auf Instanzen mit angepassten Incident-Status – oder wenn eine andere Tabelle als `incident` das Ziel ist – verwenden Sie den numerischen **Statuswert** aus der Auswahlliste Ihrer Instanz; ein numerischer Wert außerhalb des Standardsatzes wird genau so an ServiceNow gesendet, wie er konfiguriert ist. Der integrierte Standardwert für den Resolution-Code begleitet nur die Standardstatus „resolved“/„closed“; kombinieren Sie benutzerdefinierte Statuswerte daher mit den unten beschriebenen Zuordnungen für Abschluss- und Resolution-Felder. - -### Abschluss- und Resolution-Felder - -Manche ServiceNow-Instanzen erzwingen eine Data Policy, die Felder wie den **Resolution code** (`close_code`) zwingend erforderlich macht, sobald ein Incident in einen aufgelösten oder geschlossenen Status wechselt. Schließt DefectDojo einen Incident ohne diese Felder, weist ServiceNow den Schreibvorgang mit HTTP 403 *„Data Policy Exception“* zurück, und der Grund wird in der Fehleransicht der Integration festgehalten. - -Hängen Sie die erforderlichen Felder mit **Custom Field Mappings** an den Statuswechsel an und setzen Sie **Apply On** auf die Disposition, die sie tragen soll: - -- **Transition to Closed** – wird gesendet, wenn ein Befund behoben/geschlossen wird. -- **Transition to False Positive** – wird gesendet, wenn ein Befund als Falsch-positiv markiert wird. -- **Transition to Risk Accepted** – wird gesendet, wenn für einen Befund das Risiko akzeptiert wird. - -Um zum Beispiel einen zwingend erforderlichen Resolution code zu erfüllen: - -| Source | Field Name | Value | Apply On | -|---|---|---|---| -| Static | `close_code` | `Resolved by DefectDojo` | Transition to Closed | -| Static | `close_notes` | `Reviewed by the security team` | Transition to Closed | -| Static | `close_code` | `Not a defect` | Transition to False Positive | - -Hinweise: - -- Field Name ist der ServiceNow-Spaltenname – `close_code`, `close_notes` oder ein benutzerdefiniertes `u_...`-Feld. -- Übergangszuordnungen greifen, wenn sich der Status des Datensatzes tatsächlich ändert: bei einem Befund, der beim ersten Übertragen bereits geschlossen ist, bei einer Aktualisierung, die den Datensatz schließt oder wieder öffnet, und beim erzwungenen Schließen, wenn eine Ticket-Verknüpfung gelöscht wird. Sie werden bei routinemäßigen Aktualisierungen eines unveränderten Datensatzes nicht erneut gesendet, sodass Journalfelder wie `work_notes` pro Übergang einen Eintrag erhalten. -- Referenzfelder wie `assignment_group` und `assigned_to` erwarten eine **sys_id** und keinen Anzeigenamen. -- Werte, die als JSON interpretierbar sind, werden typisiert gesendet: `true`, `42`, `[...]`, `{...}` – und `null`, wodurch das Feld geleert wird. Um solchen Text als wörtliche Zeichenkette zu senden, schließen Sie ihn in doppelte Anführungszeichen ein (z. B. `"null"`). -- `short_description`, `description`, `state`, `impact`, `urgency` und `priority` gehören zur Beschreibungsvorlage und zu den Schweregrad-/Status-Zuordnungen und können daher nicht über eine Zuordnung benutzerdefinierter Felder gesetzt werden. -- Auf anderen Tabellen als `incident` werden Statuswerte, die dem Standardsatz für Incidents entsprechen (`1`, `2`, `3`, `6`, `7`, `8`), weiterhin mit Incident-Semantik interpretiert – einschließlich des automatischen Standard-Resolution-Codes bei `6`/`7`/`8`. Bevorzugen Sie auf benutzerdefinierten Tabellen Statuswerte außerhalb dieses Bereichs, oder geben Sie die Abschlussfelder wie oben beschrieben explizit an. - -## ServiceNow SecOps - -Die ServiceNow-SecOps-Integration (auch bekannt als **ServiceNow SecOps / Vulnerability Response**) überträgt DefectDojo-Befunde und Befundgruppen in eine ServiceNow-Sicherheitstabelle – einen **Security Incident** (`sn_si_incident`) oder ein **Vulnerable Item** (`sn_vul_vulnerable_item`) – und hält den Datensatz synchron, während sich der Befund ändert (Erstellen, Aktualisieren und Auflösen/Schließen). Sie ist das Security-Operations-Gegenstück zur oben beschriebenen ServiceNow-Issue-Tracker-Integration; verwenden Sie ServiceNow SecOps, wenn Sie die Anwendungen Security Incident Response (SIR) oder Vulnerability Response (VR) einsetzen. - -### Instanz-Einrichtung - -- **Instance Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf die URL Ihres ServiceNow-Servers gesetzt werden, zum Beispiel `https://your-organization.service-now.com/`. - -ServiceNow SecOps unterstützt drei Authentifizierungsmethoden; geben Sie **eine** davon an: - -- **OAuth 2.0** – geben Sie eine **Client ID**, ein **Client Secret** und ein **Refresh Token** ein. Sie erhalten diese genau so, wie im Abschnitt [ServiceNow](#servicenow) oben beschrieben (erstellen Sie einen OAuth-API-Endpunkt in der Application Registry und tauschen Sie Ihre Anmeldedaten dann unter `/oauth_token.do` gegen ein Refresh-Token). Alternativ können Sie **Client ID** und **Client Secret** zusammen mit einem **Username** und **Password** angeben, um anstelle eines Refresh-Tokens den OAuth-Password-Grant zu verwenden. -- **API Key** – geben Sie einen **API Key** ein, der als Header `x-sn-apikey` gesendet wird. Der Key authentifiziert nichts, solange auf der Instanz kein Inbound Authentication Profile und keine REST API Access Policy daran angehängt sind. -- **HTTP Basic** – geben Sie **Username** und **Password** des Servicekontos ein. - -Das Servicekonto (oder der OAuth-Client) benötigt Schreibzugriff auf die Zieltabelle. - -### Issue-Tracker-Zuordnung - -- **Target Table** legt die ServiceNow-Tabelle fest, in die Datensätze geschrieben werden: **Security Incident** (`sn_si_incident`, der Standard) oder **Vulnerable Item** (`sn_vul_vulnerable_item`). - -### Details zur Schweregrad-Zuordnung - -Bei einem Security Incident wird dies dem Feld **Impact** zugeordnet; ServiceNow leitet die Incident-Priorität aus Impact und Urgency ab, sodass Urgency dem zugeordneten Impact folgt, sofern Sie sie nicht selbst zuordnen. Bei einem Vulnerable Item ordnen Sie den Schweregrad dem Risikofeld zu, das Ihre Instanz verwendet. Die Standardwerte unten entsprechen der Standard-SIR-Impact-Skala (`1` Hoch, `2` Mittel, `3` Niedrig) und sind bearbeitbar. - -- **Name des Schweregrad-Felds**: `impact` -- **Info-Zuordnung**: `3` -- **Niedrig-Zuordnung**: `3` -- **Mittel-Zuordnung**: `2` -- **Hoch-Zuordnung**: `1` -- **Kritisch-Zuordnung**: `1` - -### Details zur Status-Zuordnung - -Dies wird dem Feld **State** des Datensatzes zugeordnet. Statuswerte sind numerische Codes, die sich zwischen den Tabellen Security Incident und Vulnerable Item unterscheiden und pro Instanz angepasst werden können; prüfen Sie sie daher gegen Ihre eigene Konfiguration. Die Standardwerte unten verwenden die Standard-SIR-Statuscodes (`16` Analysis, `3` Closed). - -- **Name des Status-Felds**: `state` -- **Aktiv-Zuordnung**: `16` -- **Geschlossen-Zuordnung**: `3` -- **Falsch-positiv-Zuordnung**: `3` -- **Risiko-akzeptiert-Zuordnung**: `3` - -Wird ein Datensatz geschlossen, setzt DefectDojo zusätzlich den ServiceNow-**Close Code** und die **Close Notes** (`Resolved` für geschlossene Befunde, `False positive` und `Risk accepted` für die entsprechenden Status). - -### Verhalten speziell bei ServiceNow SecOps - -- **Deduplizierung** – jeder Datensatz wird in seinem Feld `correlation_id` mit dem DefectDojo-Identifikator des Befunds oder der Befundgruppe gekennzeichnet. Bevor DefectDojo einen Datensatz erstellt, sucht es per `correlation_id` nach einem vorhandenen; ein Treffer wird übernommen und aktualisiert statt dupliziert, sodass erneute Synchronisierungen idempotent sind. -- **Aktualisierungen** werden im Journal **Work notes** des Datensatzes eingetragen (intern), niemals in kundenseitig sichtbaren Comments. -- **Auflösen beim Löschen** – das Löschen eines Befunds in DefectDojo löst bzw. schließt den ServiceNow-Datensatz (State + Close Code), anstatt ihn zu löschen; Datensätze werden niemals endgültig gelöscht. -- **Referenzfelder** – die optionalen Werte `cmdb_ci`, `assignment_group` und `assigned_to` dürfen als Anzeigenamen angegeben werden; DefectDojo löst jeden in seine `sys_id` auf. Ein Name, der nicht auflösbar ist, wird mit einer Warnung verworfen, anstatt die Übertragung fehlschlagen zu lassen. - -## Shortcut - -Die Shortcut-Integration ermöglicht es Ihnen, DefectDojo-Befunde als [Shortcut](https://www.shortcut.com/)-Stories zu übertragen. Stories werden mit dem Story-Typ „Bug“ erstellt und einem Team in Ihrem Shortcut-Workspace zugewiesen. - -### Instanz-Einrichtung - -- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf `https://api.app.shortcut.com` gesetzt werden. -- **API Token** sollte auf ein Shortcut-API-Token gesetzt werden. Token können in Shortcut unter „Settings“, dann „Your Account“, dann [API Tokens](https://app.shortcut.com/settings/account/api-tokens) generiert werden. - -### Issue-Tracker-Zuordnung - -- **Team (Group) ID** sollte auf die UUID des Shortcut-Teams gesetzt werden, für das Stories erstellt werden. Sie finden diese UUID, indem Sie die Team-Seite in Shortcut öffnen und den Identifikator aus der URL kopieren, oder indem Sie die Shortcut-API aufrufen: - -``` -curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/groups -``` - -### Details zur Schweregrad-Zuordnung - -Jeder Schweregradwert wird der Story als Label zugewiesen. Labels werden in Shortcut automatisch erstellt, falls sie noch nicht existieren; die Standardwerte unten können also unverändert übernommen oder durch Labelnamen Ihrer Wahl ersetzt werden. Ändert sich der Schweregrad eines Befunds, wird das alte Schweregrad-Label von der Story entfernt und das neue hinzugefügt. - -- **Name des Schweregrad-Felds**: `Label` -- **Info-Zuordnung**: `sev-info` -- **Niedrig-Zuordnung**: `sev-low` -- **Mittel-Zuordnung**: `sev-medium` -- **Hoch-Zuordnung**: `sev-high` -- **Kritisch-Zuordnung**: `sev-critical` - -### Details zur Status-Zuordnung - -Jeder Statuswert muss auf die numerische ID eines Workflow-States in Ihrem Shortcut-Workspace gesetzt werden. Workflow-State-IDs sind je Workspace eindeutig, daher gibt es keine Standardwerte. Sie können die Workflow-States und ihre IDs auflisten, indem Sie die Shortcut-API aufrufen: - -``` -curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/workflows -``` - -- **Name des Status-Felds**: `Workflow State ID` -- **Aktiv-Zuordnung**: die ID des States für offene Arbeit, zum Beispiel ein Backlog- oder To-Do-State. -- **Geschlossen-Zuordnung**: die ID eines States vom Typ „Done“. Wenn ein Befund in DefectDojo gelöscht wird, wird seine Story in diesen State verschoben. -- **Falsch-positiv-Zuordnung**: die ID des States, der für Falsch-positiv-Befunde verwendet wird. -- **Risiko-akzeptiert-Zuordnung**: die ID des States, der für Befunde mit akzeptiertem Risiko verwendet wird. - -## Freshservice - -Die Freshservice-Integration ermöglicht es Ihnen, DefectDojo-Befunde und Befundgruppen als Freshservice-Tickets zu übertragen, die einer Agenten-Gruppe Ihrer Wahl zugewiesen werden. - -### Instanz-Einrichtung - -- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf Ihre Freshservice-URL gesetzt werden: `https://yourcompany.freshservice.com`. -- **API Key** sollte ein Freshservice-API-Key sein. Sie finden ihn, indem Sie auf Ihr Profilbild (oben rechts) > **Profile settings** klicken - der Key erscheint rechts unterhalb des Abschnitts **Delegate Approvals**, nachdem Sie das Captcha gelöst haben. Wird dort kein Key angezeigt, ist der API-Zugriff möglicherweise auf Kontoebene deaktiviert und muss zuerst von einem Administrator aktiviert werden. -- **Requester Email** sollte die E-Mail-Adresse sein, in deren Namen Tickets angefordert werden. Freshservice verlangt für jedes Ticket einen Anforderer, daher erstellt DefectDojo Tickets mit dieser Adresse als Anforderer. - -### Issue-Tracker-Zuordnung - -- **Group ID** sollte die numerische ID der Freshservice-Agenten-Gruppe sein, der Tickets zugewiesen werden. Sie finden sie in der URL, während Sie die Gruppe unter **Admin > Agent Groups** ansehen. -- **Workspace ID** (optional) leitet Tickets bei Konten mit mehreren Workspaces an einen bestimmten Workspace. Lassen Sie das Feld leer, um den primären Workspace zu verwenden. - -### Details zur Schweregrad-Zuordnung - -Dies wird dem Freshservice-Ticketfeld **Priority** zugeordnet, das numerische Codes verwendet (`1` Low, `2` Medium, `3` High, `4` Urgent). Die Prioritätsnamen werden ebenfalls akzeptiert: - -- **Name des Schweregrad-Felds**: `Priority` -- **Info-Zuordnung**: `1` -- **Niedrig-Zuordnung**: `1` -- **Mittel-Zuordnung**: `2` -- **Hoch-Zuordnung**: `3` -- **Kritisch-Zuordnung**: `4` - -### Details zur Status-Zuordnung - -Dies wird dem Ticketfeld **Status** zugeordnet, das numerische Codes verwendet (`2` Open, `3` Pending, `4` Resolved, `5` Closed). Die Statusnamen werden ebenfalls akzeptiert: - -- **Name des Status-Felds**: `Status` -- **Aktiv-Zuordnung**: `2` -- **Geschlossen-Zuordnung**: `5` -- **Falsch-positiv-Zuordnung**: `5` -- **Risiko-akzeptiert-Zuordnung**: `3` - -Einige Freshservice-spezifische Verhaltensweisen, die Sie kennen sollten: - -- Aktualisierungen synchronisieren den vollständigen Ticketinhalt - Freshservice erlaubt es, Betreff und Beschreibung nach dem Erstellen zu bearbeiten. -- Tickets werden geschlossen und nicht gelöscht, wenn ein Befund entfernt wird; Tickets, die bereits Resolved oder Closed sind, bleiben unberührt. Beim Schließen wird automatisch eine Lösungsnotiz angehängt, sodass Konten, die eine solche verlangen (eine verbreitete Geschäftsregel), das Schließen akzeptieren. -- Manche Konten berechnen die Priorität eines Tickets aus einer Impact-/Urgency-Matrix oder einer Geschäftsregel und ignorieren die beim Erstellen gesendete Priorität. DefectDojo erkennt dies und wendet die zugeordnete Priorität mit einer nachgelagerten Aktualisierung erneut an, sodass die Zuordnung dennoch wirksam wird. - -## ServiceDesk Plus - -Die Integration mit ManageEngine ServiceDesk Plus ermöglicht es Ihnen, DefectDojo-Befunde und Befundgruppen als ServiceDesk-Plus-Requests zu übertragen, die einer Support-Gruppe Ihrer Wahl zugewiesen werden. Sowohl die **Cloud**-Edition (ServiceDesk Plus OnDemand) als auch die **On-Premises**-Edition werden von derselben Integration unterstützt - die Anmeldedaten, die Sie angeben, bestimmen, welcher Modus verwendet wird. - -### Instanz-Einrichtung - -- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf Ihre ServiceDesk-Plus-URL gesetzt werden: `https://sdpondemand.manageengine.com` für die Cloud-Edition (oder Ihr regionales Äquivalent) beziehungsweise die Adresse Ihres Servers bei On-Premises-Installationen. - -Geben Sie dann **einen** der beiden Anmeldedatensätze an: - -#### On-Premises: Technician Key - -- **Technician Key** sollte ein API-Key sein, der für einen Techniker auf Ihrem Server unter **Admin > General Settings > API** generiert wurde. Lassen Sie die Zoho-OAuth-Felder leer. - -#### Cloud: Zoho OAuth - -Die Cloud-Edition authentifiziert sich über Zoho Accounts OAuth: - -1. Öffnen Sie die [Zoho API Console](https://api-console.zoho.com/) und erstellen Sie einen **Self Client**. -2. Notieren Sie sich die **Client ID** und das **Client Secret**. -3. Geben Sie im Tab „Generate Code“ des Self Client den Scope `SDPOnDemand.requests.ALL` ein, wählen Sie eine Dauer und generieren Sie den Code. -4. Tauschen Sie den Code gegen ein Refresh-Token: - -``` -curl --request POST \ - --url 'https://accounts.zoho.com/oauth/v2/token' \ - --data 'grant_type=authorization_code' \ - --data 'client_id={{CLIENT_ID}}' \ - --data 'client_secret={{CLIENT_SECRET}}' \ - --data 'code={{GENERATED_CODE}}' -``` - -5. Geben Sie die **Client ID**, das **Client Secret** und das zurückgegebene **Refresh Token** im Instanzformular ein. Wird Ihr Konto außerhalb des US-Rechenzentrums gehostet, setzen Sie die **Token URL** auf Ihren regionalen Zoho-Accounts-Endpunkt (zum Beispiel `https://accounts.zoho.eu/oauth/v2/token`). - -### Issue-Tracker-Zuordnung - -- **Group Name** sollte der Name der ServiceDesk-Plus-Support-Gruppe sein, der Requests zugewiesen werden, genau so, wie er unter **Admin > Users > Support Groups** erscheint. - -### Details zur Schweregrad-Zuordnung - -Dies wird dem ServiceDesk-Plus-Request-Feld **Priority** anhand des Namens zugeordnet, unter Verwendung der Prioritätsnamen Ihres Kontos: - -- **Name des Schweregrad-Felds**: `Priority` -- **Info-Zuordnung**: `Low` -- **Niedrig-Zuordnung**: `Normal` -- **Mittel-Zuordnung**: `Medium` -- **Hoch-Zuordnung**: `High` -- **Kritisch-Zuordnung**: `High` - -### Details zur Status-Zuordnung - -Dies wird dem Request-Feld **Status** anhand des Namens zugeordnet. Die Standardwerte verwenden die integrierten Status: - -- **Name des Status-Felds**: `Status` -- **Aktiv-Zuordnung**: `Open` -- **Geschlossen-Zuordnung**: `Closed` -- **Falsch-positiv-Zuordnung**: `Closed` -- **Risiko-akzeptiert-Zuordnung**: `On Hold` - -Einige ServiceDesk-Plus-spezifische Verhaltensweisen, die Sie kennen sollten: - -- Aktualisierungen synchronisieren den vollständigen Request-Inhalt - anders als die meisten Tracker erlaubt ServiceDesk Plus es, Betreff und Beschreibung nach dem Erstellen zu bearbeiten. -- Requests werden geschlossen und nicht gelöscht, wenn ein Befund entfernt wird; Requests, die bereits Closed oder Resolved sind, bleiben unberührt. -- Macht Ihr Konto beim Schließen Felder zwingend erforderlich (zum Beispiel eine Lösung), kann ein von DefectDojo angestoßenes Schließen von diesen Regeln abgewiesen werden und erscheint dann in der Fehlertabelle der Integration. - -## Zendesk - -Die Zendesk-Integration ermöglicht es Ihnen, DefectDojo-Befunde und Befundgruppen als Zendesk-Tickets zu übertragen, die einer Zendesk-Gruppe Ihrer Wahl zugewiesen werden. - -### Instanz-Einrichtung - -- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. -- **Location** sollte auf die URL Ihres Zendesk-Kontos gesetzt werden, zum Beispiel `https://your-subdomain.zendesk.com`. -- **Email** sollte die E-Mail-Adresse des Zendesk-Agenten sein, zu dem das API-Token gehört. -- **API Token** sollte auf ein Zendesk-API-Token gesetzt werden. Ein Administrator kann eines im Zendesk Admin Center unter **Apps and integrations > APIs > Zendesk API** erstellen (der Token-Zugriff muss aktiviert sein). - -### Issue-Tracker-Zuordnung - -- **Group ID** sollte die numerische ID der Zendesk-Gruppe sein, der Tickets zugewiesen werden. Sie finden sie im Admin Center unter **People > Team > Groups** oder in der URL, während Sie die Gruppe ansehen. - -### Details zur Schweregrad-Zuordnung - -Dies wird dem Zendesk-Ticketfeld **Priority** zugeordnet, das `low`, `normal`, `high` und `urgent` akzeptiert: - -- **Name des Schweregrad-Felds**: `Priority` -- **Info-Zuordnung**: `low` -- **Niedrig-Zuordnung**: `low` -- **Mittel-Zuordnung**: `normal` -- **Hoch-Zuordnung**: `high` -- **Kritisch-Zuordnung**: `urgent` - -### Details zur Status-Zuordnung - -Zendesk-Tickets unterstützen die Status `new`, `open`, `pending`, `hold`, `solved` und `closed`. Beachten Sie, dass `hold` in Ihrem Konto aktiviert sein muss, bevor es verwendet werden kann. - -- **Name des Status-Felds**: `Status` -- **Aktiv-Zuordnung**: `new` -- **Geschlossen-Zuordnung**: `solved` -- **Falsch-positiv-Zuordnung**: `solved` -- **Risiko-akzeptiert-Zuordnung**: `pending` - -Einige Zendesk-spezifische Verhaltensweisen, die Sie kennen sollten: - -- Die Ticketbeschreibung ist in Zendesk der erste Kommentar und kann nach dem Erstellen nicht bearbeitet werden; beim Übertragen eines aktualisierten Befunds werden daher Betreff, Priorität und Status des Tickets synchronisiert, Änderungen der Beschreibung jedoch nicht. -- Tickets werden als `solved` markiert und nicht gelöscht, wenn ein Befund entfernt wird; Zendesk schließt gelöste Tickets nach einer bestimmten Zeit automatisch. -- `closed` ist ein endgültiger Status - geschlossene Tickets können überhaupt nicht mehr aktualisiert werden, und das Übertragen eines Befunds, dessen Ticket geschlossen ist, meldet einen Fehler. diff --git a/docs/content/connectors/downstream/downstream_toolreference.es.md b/docs/content/connectors/downstream/downstream_toolreference.es.md deleted file mode 100644 index b56b2fbc84b..00000000000 --- a/docs/content/connectors/downstream/downstream_toolreference.es.md +++ /dev/null @@ -1,767 +0,0 @@ ---- -title: Referencia de herramientas de Downstream Connectors -description: Guías de configuración detalladas para Downstream Connectors -weight: 1 -audience: pro -aliases: -- /es/en/share_your_findings/integrations_toolreference -- /es/issue_tracking/pro_integration/integrations_toolreference/ ---- - -Estas son las instrucciones específicas que detallan cómo configurar un Downstream Connector de DefectDojo con un rastreador de incidencias (Issue Tracker) de un tercero. - -## Azure DevOps Boards - -### Configuración de la instancia - -- **Label** debe ser la etiqueta que desea usar para identificar esta integración. -- **Location** debe establecerse en su URL de Azure - por ejemplo `https://dev.azure.com/{your organization}` -- **Token** debe establecerse en un token de acceso personal de Azure. - -La autenticación con Azure DevOps requiere un [token de acceso personal](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows) -con permisos establecidos en "Read, Write and Manage" para "Work Items" en el proyecto de Azure con el que desea trabajar. - -### Mapeo del Issue Tracker - -Estos detalles determinan cómo DefectDojo mapeará los atributos de un Hallazgo o Grupo de Hallazgos a un Proyecto dado en Azure DevOps: - -#### Detalles del mapeo del Issue Tracker - -El campo `Project ID` corresponde al nombre o al ID del proyecto en Azure. - -#### Detalles del mapeo de severidad - -Los atributos del formulario se proporcionan como valores predeterminados y son los siguientes: - -- **Severity Field Name**: `/fields/Microsoft.VSTS.Common.Priority` -- **Info Mapping**: `4` -- **Low Mapping**: `4` -- **Medium Mapping**: `3` -- **High Mapping**: `2` -- **Critical Mapping**: `1` - -#### Detalles del mapeo de estado - -Los atributos del formulario se proporcionan como valores predeterminados y son los siguientes: - -- **Status Field Name**: `/fields/System.State` -- **Active Mapping**: `To Do` -- **Closed Mapping**: `Done` -- **False Positive Mapping**: `Done` -- **Risk Accepted Mapping**: `Done` - -## Bitbucket - -La integración de Bitbucket le permite enviar incidencias al [rastreador de incidencias](https://support.atlassian.com/bitbucket-cloud/docs/enable-an-issue-tracker/) de un repositorio de Bitbucket Cloud. - -El rastreador de incidencias es opcional en Bitbucket y debe habilitarse en el repositorio antes de que DefectDojo pueda crear incidencias en él. Para habilitarlo, abra el repositorio en Bitbucket y seleccione **Repository settings**, luego habilite el rastreador de incidencias en **Features**. - -### Configuración de la instancia - -- **Label** debe ser la etiqueta que desea usar para identificar esta integración. -- **Location** debe establecerse en `https://bitbucket.org`. -- **Email** debe ser la dirección de correo electrónico de la cuenta de Atlassian a la que pertenece el token de la API. -- **API Token** debe establecerse en un token de API de Atlassian con alcance limitado (scoped). - -Atlassian ha declarado obsoletas las contraseñas de aplicación de Bitbucket y no funcionarán con esta integración. Para crear un token de API: - -1. Abra la [configuración de la cuenta de Atlassian](https://id.atlassian.com/manage-profile/security/api-tokens) y elija **Security**, luego **Create and manage API tokens**. -2. Elija **Create API token with scopes**, asigne un nombre al token y establezca una fecha de vencimiento. -3. Seleccione **Bitbucket** como la aplicación. -4. Otorgue al token permiso para leer repositorios y para leer y escribir incidencias. - -### Mapeo del Issue Tracker - -- **Workspace** debe ser el slug del espacio de trabajo que contiene el repositorio, tal como aparece en las URL de bitbucket.org. -- **Repository Slug** debe ser el slug del repositorio en el que desea crear incidencias. - -### Detalles del mapeo de severidad - -Esto se mapea al campo Priority de la incidencia de Bitbucket. Los atributos del formulario se proporcionan como valores predeterminados, y cada valor debe ser una de las prioridades de Bitbucket: `trivial`, `minor`, `major`, `critical` o `blocker`. - -- **Severity Field Name**: `priority` -- **Info Mapping**: `trivial` -- **Low Mapping**: `minor` -- **Medium Mapping**: `major` -- **High Mapping**: `critical` -- **Critical Mapping**: `blocker` - -### Detalles del mapeo de estado - -Esto se mapea al campo State de la incidencia de Bitbucket. Cada valor debe ser uno de los estados de incidencia de Bitbucket: `new`, `open`, `resolved`, `on hold`, `invalid`, `duplicate`, `wontfix` o `closed`. - -- **Status Field Name**: `state` -- **Active Mapping**: `new` -- **Closed Mapping**: `resolved` -- **False Positive Mapping**: `invalid` -- **Risk Accepted Mapping**: `wontfix` - -## GitHub - -La integración de GitHub le permite añadir incidencias a un [GitHub Project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects), que también abre incidencias en un Repo asociado. Estos Repos/Proyectos pueden asociarse tanto a una organización de GitHub como a una cuenta personal de GitHub. - -### Configuración de la instancia - -- **Label** debe ser la etiqueta que desea usar para identificar esta integración. -- **Location** debe establecerse en la URL de su usuario u organización de GitHub, según dónde desee crear las incidencias. por ejemplo `https://github.com/{your-organization}` -- **Token** debe establecerse en un token de acceso personal de GitHub. - -Los tokens de acceso personal para GitHub pueden crearse en https://github.com/settings/tokens. El token debe tener los alcances (scopes) Repo y Project. - -### Mapeo del Issue Tracker - -- **Issue Tracker Mapping Label** debe establecerse para identificar el Proyecto o Repo en el que desea crear incidencias. -- **Project Number** debe ser el ID de un proyecto de GitHub al que desea enviar los elementos. Puede obtenerlo de la URL al ver un Proyecto, por ejemplo `https://github.com/orgs/{your-org}/projects/{project number}`. -- **Repository Name** debe ser el nombre de un repositorio asociado a su organización (o usuario) al que desea enviar las incidencias. - - -### Detalles del mapeo de severidad - -**Para configurar la integración, el proyecto DEBE tener un campo personalizado creado para representar la prioridad de la incidencia; de lo contrario, la severidad no se mapeará correctamente y las incidencias no se enviarán a GitHub.** - -Siga esta guía para crear un [campo personalizado](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/quickstart-for-projects#creating-a-field-to-track-priority). -Cada severidad necesitará tener una opción de selección única correspondiente disponible. Por ejemplo, de forma predeterminada DefectDojo sugiere P0, P1, P2, P3, P4 como posibles valores de Priority, y cada uno de ellos deberá añadirse al campo personalizado Priority. - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `P0` -- **Low Mapping**: `P1` -- **Medium Mapping**: `P2` -- **High Mapping**: `P3` -- **Critical Mapping**: `P4` - -### Detalles del mapeo de estado - -De forma predeterminada, los nuevos proyectos de GitHub tendrán estados para las incidencias de "In Progress" y "Done". Se pueden añadir estados adicionales al proyecto para rastrear el estado Falso positivo o Riesgo aceptado si lo desea. Una de las formas de hacerlo es añadiendo una nueva columna de estado al tablero del proyecto. - -- **Status Field Name**: `Status` -- **Active Mapping**: `In Progress` -- **Closed Mapping**: `Done` -- **False Positive Mapping**: `Done` -- **Risk Accepted Mapping**: `Done` - -## GitLab - -La integración de GitLab le permite añadir incidencias a un [Proyecto de GitLab](https://docs.gitlab.com/ee/user/project/). - -### Configuración de la instancia - -- **Label** debe ser la etiqueta que desea usar para identificar esta integración. -- **Location** debe establecerse en el enlace de su servidor de GitLab, por ejemplo `https://gitlab.com/`. -- **Token** debe establecerse en un token de acceso personal de GitLab. El token debe tener alcances de API. Consulte la [guía de GitLab para crear un token de acceso personal](https://docs.gitlab.com/user/profile/personal_access_tokens/#create-a-personal-access-token). - -### Mapeo del Issue Tracker - -- **Project Name**: el nombre del proyecto en GitLab al que desea enviar incidencias. - -### Detalles del mapeo de severidad - -Esto se mapea al campo Priority de GitLab. -- **Severity Field Name**: `Priority` -- **Info Mapping**: `1` -- **Low Mapping**: `2` -- **Medium Mapping**: `3` -- **High Mapping**: `4` -- **Critical Mapping**: `5` - -### Detalles del mapeo de estado - -De forma predeterminada, GitLab tiene los estados 'opened' y 'closed'. Se pueden añadir etiquetas de estado adicionales si desea rastrear el estado Falso positivo o Riesgo aceptado. Consulte la [documentación de GitLab](https://docs.gitlab.com/user/work_items/status/) para más detalles. - -- **Status Field Name**: `Status` -- **Active Mapping**: `opened` -- **Closed Mapping**: `closed` -- **False Positive Mapping**: `closed` -- **Risk Accepted Mapping**: `closed` - -## Jira - -La integración de Jira envía los Hallazgos y Grupos de Hallazgos de DefectDojo a un proyecto de Jira como incidencias, mantiene sincronizado el estado de cada incidencia con el Hallazgo y enlaza el Hallazgo de vuelta a la incidencia creada. Se admiten tanto Jira **Cloud** como **Data Center / Server**. Jira Service Management no es compatible. - -### Elegir un método de autenticación - -Establezca primero **Jira Deployment**, luego elija un **Authentication Method**: - -**Jira Cloud** -- **API Token (email + token)** — autenticación HTTP Basic usando un correo electrónico de cuenta de Atlassian y un [token de API](https://id.atlassian.com/manage-profile/security/api-tokens). Las llamadas se dirigen directamente a la URL de su sitio. -- **OAuth 2.0 (recomendado)** — un consentimiento del navegador de una sola vez; DefectDojo obtiene y renueva los tokens por usted. -- **Service Account Token** — un token de API con alcance limitado creado para una [cuenta de servicio](https://support.atlassian.com/user-management/docs/manage-api-tokens-for-service-accounts/) de Atlassian. - -**Jira Data Center / Server** -- **Personal Access Token (recomendado)** -- **Username + Password** - -> **Cómo llega la autenticación de Cloud a Jira:** tanto OAuth 2.0 como Service Account se autentican como un token Bearer contra la puerta de enlace de Atlassian — `https://api.atlassian.com/ex/jira/{cloudId}` —, que es un *host distinto* de la URL de su sitio `https://your-site.atlassian.net`. DefectDojo usa la puerta de enlace para cada llamada a la API, pero siempre construye el enlace del ticket que se muestra en un Hallazgo a partir de la **URL de su sitio**, de modo que el enlace en el que hace clic un usuario es un enlace normal y navegable `.../browse/{ISSUE-KEY}`. (La autenticación de API Token y Data Center llama directamente a la URL del sitio, por lo que no existe esa división.) - -### Configuración de la instancia - -- **Label** debe ser la etiqueta que desea usar para identificar esta integración. -- **Location** debe establecerse en la **URL del sitio** de Jira, por ejemplo `https://your-organization.atlassian.net`. Esto se usa para los enlaces de ticket navegables y, para la autenticación de API Token y Data Center, como URL base de la API. -- Los campos restantes dependen del método elegido anteriormente (email + token de API, credenciales de cliente OAuth, token de cuenta de servicio, PAT, o nombre de usuario + contraseña). - -### Configuración de OAuth 2.0 (Cloud) - -Cree una aplicación dedicada en la [consola de desarrolladores de Atlassian](https://developer.atlassian.com/console/myapps/) y luego conéctese desde DefectDojo. - -1. Elija **Create → OAuth 2.0 integration**. Debe ser una *integración OAuth 2.0* — una aplicación Connect o Forge no puede usar el grant de código de autorización 3LO (obtendría `grant_type is not enabled for client`). -2. Cuando se le solicite el **Access type**, elija **Resource-level**. Esto limita el token al único sitio de Jira que autoriza el usuario, que es exactamente lo que apunta una conexión de DefectDojo. (**Account-level** otorga acceso a todos los sitios de la cuenta de Atlassian — más amplio de lo necesario.) -3. En **Permissions**, añada la **Jira platform REST API** y otorgue los alcances listados a continuación. Nota: `offline_access` *no* aparece aquí — es un alcance OAuth estándar que DefectDojo solicita en la URL de autorización, no algo que se añada en esta pantalla. -4. En **Authorization**, junto a **OAuth 2.0 (3LO)**, haga clic en **Configure** y establezca la **Callback URL** en `https:///integrators/jira/oauth/callback` — debe coincidir exactamente con la URL de su sitio de DefectDojo. Habilitar esto es lo que activa el grant de código de autorización y los tokens de renovación; omitirlo provoca los errores `grant_type is not enabled` / `Client is not allowed to use offline_access`. -5. Copie el **Client ID** y el **Client Secret** en el formulario de DefectDojo y haga clic en **Submit** para guardar la conexión. -6. Haga clic en **Connect with Jira** y apruebe la pantalla de consentimiento. Atlassian redirige de vuelta a DefectDojo, que almacena los tokens y resuelve su `cloudId` automáticamente. Aparece un indicador "Connected" cuando tiene éxito. - -> El host de callback es su `SITE_URL` de DefectDojo. Atlassian debe poder redirigir el navegador allí, y el valor debe coincidir exactamente con lo que envía DefectDojo — así que use el nombre de host real al que sus usuarios acceden a DefectDojo, no un valor solo alcanzable desde dentro de la red. - -#### Alcances mínimos de OAuth - -DefectDojo solicita estos cuatro alcances clásicos de forma predeterminada, y también son el **mínimo absoluto** requerido — cada uno respalda un comportamiento específico: - -| Alcance | Requerido para | -|-------|--------------| -| `read:jira-work` | Leer el proyecto, las incidencias y las transiciones disponibles (validación de conexión y sincronización de estado). | -| `write:jira-work` | Crear y editar incidencias, y ejecutar transiciones de estado. | -| `read:jira-user` | La verificación de identidad de la conexión — DefectDojo llama a `/myself` al validar el acceso. | -| `offline_access` | Emitir un **token de renovación**. Sin él, el token de acceso expira (~1 hora después de conectarse) y la conexión deja de funcionar, porque DefectDojo ya no puede renovarlo. | - -Atlassian recomienda los alcances clásicos sobre los granulares; los cuatro anteriores mantienen mínima la huella de la aplicación y son suficientes para todo lo que hace la integración. - -##### Alternativa de alcances granulares - -Si su organización requiere alcances **granulares** en lugar de clásicos, el conjunto mínimo equivalente es: - -| Alcance granular | Requerido para | -|----------------|--------------| -| `read:user:jira` | La verificación de identidad `/myself`. | -| `read:project:jira` | Validar que el proyecto objetivo existe. | -| `read:issue:jira` | Leer el estado actual de una incidencia durante la sincronización. | -| `write:issue:jira` | Crear y editar incidencias **y ejecutar transiciones de estado** — no existe un alcance de escritura de transición separado; una transición es una escritura en la incidencia. | -| `read:issue.transition:jira` | Listar las transiciones disponibles en una incidencia. | -| `offline_access` | El token de renovación (igual que en el clásico). | - -Dependiendo de la configuración de campos de su sitio, un endpoint también puede requerir alcances de lectura complementarios para expandir campos — lo más común es `read:status:jira` y `read:field:jira` (y `read:issue-meta:jira` para la creación). Si un envío falla con un error `403` de "scope does not match", añada el alcance exacto indicado en el error. Esta proliferación de alcances complementarios es precisamente la razón por la que se recomiendan los alcances clásicos. - -Para el método **Service Account Token**, otorgue al token `read:jira-work` y `write:jira-work` (además de `read:jira-user`) — o los equivalentes granulares anteriores sin `offline_access`. `offline_access` no aplica — un token de cuenta de servicio es de larga duración y DefectDojo no lo renueva. - -### Mapeo del Issue Tracker - -- **Project Key**: la clave del proyecto de Jira en el que se crearán las incidencias, por ejemplo `SEC`. -- **Issue Type**: el tipo de incidencia a crear, por ejemplo `Bug` o `Task`. El valor predeterminado es `Bug`. - -### Detalles del mapeo de severidad - -Los valores predeterminados coinciden con el esquema de prioridad predeterminado de Jira. Edítelos para que coincidan con los nombres de prioridad de su proyecto: - -- **Severity Field Name**: `priority` -- **Info Mapping**: `Lowest` -- **Low Mapping**: `Low` -- **Medium Mapping**: `Medium` -- **High Mapping**: `High` -- **Critical Mapping**: `Highest` - -### Detalles del mapeo de estado - -Los estados varían según el flujo de trabajo de cada proyecto, por lo que estos valores predeterminados están pensados para editarse con los nombres de estado de **su** flujo de trabajo: - -- **Status Field Name**: `status` -- **Active Mapping**: `To Do` -- **Closed Mapping**: `Done` -- **False Positive Mapping**: `Done` -- **Risk Accepted Mapping**: `Done` - -### Campos personalizados (opcional) - -Puede mapear campos adicionales de Jira — por ejemplo, un `resolution` requerido al cerrar, o `labels` — en el paso **Custom Fields** del mapeo. Cada mapeo de campo personalizado tiene cuatro partes: - -- **Source** — de dónde proviene el valor: un atributo del **Finding**, **Test**, **Engagement** o **Asset** que se está enviando, o un **Static value**. -- **Value** — para un origen de objeto, el atributo específico a leer, elegido de una lista de los campos de ese objeto con etiquetas legibles (por ejemplo *Severity*, *CVE*, *Mitigation*). Para un origen **Static value**, esto es un cuadro de texto libre en el que escribe el valor literal. -- **Vendor Field** — el campo de Jira en el que se escribe. Como DefectDojo puede leer el catálogo de campos de Jira, este es un selector con búsqueda que lista cada campo por su **nombre de visualización** y lo resuelve al id interno por usted — así que selecciona *DD Close Justification* y DefectDojo almacena `customfield_10255`. El selector se llena a partir de la conexión, por lo que funciona una vez que la conexión se ha guardado y validado. -- **Application point** — *cuándo* enviar el campo: en la **creación del ticket**, en **cada actualización**, o como parte de una **transición** de estado específica (Active / Closed / False Positive / Risk Accepted). Un campo con alcance de transición se envía como parte de la edición de esa transición — así es como se proporciona un valor que Jira solo acepta en una pantalla de transición, más comúnmente un `resolution` que su flujo de trabajo requiere cuando se resuelve una incidencia. - -### Plantillas de ticket (opcional) - -De forma predeterminada, las incidencias de Jira usan el título y el cuerpo integrados de DefectDojo. Para personalizarlos, adjunte una **Ticket Template** al mapeo en su paso **Ticket Template**. Una plantilla define cuatro piezas independientemente opcionales — el resumen y la descripción del **Finding**, y el resumen y la descripción del **Finding Group**. Cualquier pieza que se deje en blanco recurre al valor predeterminado integrado, por lo que puede anular solo el título, solo el cuerpo, o los cuatro. Use **Test render** en el editor de plantillas para previsualizar la salida renderizada con datos de muestra — detectando errores como marcadores de posición desconocidos o valores que exceden el límite de longitud de un campo — antes de guardar. Si una plantilla se elimina posteriormente, los mapeos que la usaban vuelven automáticamente a los valores predeterminados integrados. - -### Cómo funciona - -- **Crear / Actualizar / Eliminar:** crear envía una nueva incidencia y registra el enlace en el Hallazgo; actualizar edita la incidencia existente; eliminar un Hallazgo fuerza el cierre de su incidencia (nada se elimina en Jira). Los envíos pueden ser manuales ("Push to Integrator") o automáticos según la asignación del Issue Tracker. -- **Reconciliación de estado:** después de crear (y en cada actualización) DefectDojo lee el estado actual de la incidencia y, si difiere del objetivo mapeado, busca una única transición del flujo de trabajo que lo alcance y la aplica. Si no existe tal transición, el mapeo registra un error en lugar de fallar silenciosamente. Cualquier campo personalizado con alcance de transición se envía con esa transición. -- **Enlace del ticket:** el enlace que se muestra en el Hallazgo es `https://your-site.atlassian.net/browse/{ISSUE-KEY}` — siempre la URL pública de su sitio, nunca la puerta de enlace interna. -- **Ciclo de vida del token (OAuth):** DefectDojo gestiona todo el flujo — realiza el intercambio de código de autorización, almacena los tokens de acceso y de renovación, y renueva bajo demanda antes de un envío, guardando el nuevo token de renovación cada vez (Atlassian lo rota en cada renovación). -- **Almacenamiento de credenciales:** todas las credenciales de la conexión (contraseñas, tokens, secretos de cliente, tokens OAuth) se cifran en reposo y nunca se devuelven a través de la API — editar una conexión muestra un marcador de posición "leave blank to keep" para los secretos almacenados. - -## Linear - -La integración de Linear le permite enviar los Hallazgos de DefectDojo como incidencias de [Linear](https://linear.app/). Las incidencias se crean en un equipo (Team) de su espacio de trabajo de Linear. - -### Configuración de la instancia - -- **Label** debe ser la etiqueta que desea usar para identificar esta integración. -- **Location** debe establecerse en `https://api.linear.app/graphql`. -- **API Key** debe establecerse en una clave de API personal de Linear. Las claves pueden generarse en Linear en Settings, luego Security & access, luego [API](https://linear.app/settings/account/security). La clave se envía a la API GraphQL de Linear en el encabezado `Authorization`. - -### Mapeo del Issue Tracker - -- **Team (Group) ID** debe establecerse en el ID del equipo de Linear para el que se crearán las incidencias. Puede listar sus equipos y sus ID llamando a la API GraphQL de Linear: - -``` -curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ - -d '{"query":"{ teams { nodes { id name key } } }"}' https://api.linear.app/graphql -``` - -### Detalles del mapeo de severidad - -Una incidencia de Linear lleva una **priority** numérica en lugar de un campo de severidad. Cada severidad de DefectDojo se mapea a una prioridad de Linear, donde `1` es Urgent y `4` es Low: - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `4` -- **Low Mapping**: `4` -- **Medium Mapping**: `3` -- **High Mapping**: `2` -- **Critical Mapping**: `1` - -### Detalles del mapeo de estado - -Cada valor de estado debe establecerse en el ID de un estado de flujo de trabajo (Workflow State) en su equipo de Linear. Los ID de estado de flujo de trabajo son únicos para cada espacio de trabajo, por lo que no hay valores predeterminados. Puede listar los estados de flujo de trabajo y sus ID llamando a la API GraphQL de Linear: - -``` -curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ - -d '{"query":"{ workflowStates { nodes { id name type team { key } } } }"}' https://api.linear.app/graphql -``` - -- **Status Field Name**: `Workflow State ID` -- **Active Mapping**: el ID de un estado started o unstarted, por ejemplo `Todo` o `In Progress`. -- **Closed Mapping**: el ID de un estado completed, por ejemplo `Done`. Cuando se elimina un Hallazgo en DefectDojo, su incidencia se mueve a este estado. - -## Opsgenie - -La integración de Opsgenie le permite enviar los Hallazgos y Grupos de Hallazgos de DefectDojo como alertas de Opsgenie, opcionalmente enrutadas a un equipo de Opsgenie como responsable. - -### Configuración de la instancia - -- **Label** debe ser la etiqueta que desea usar para identificar esta integración. -- **Location** debe establecerse en `https://api.opsgenie.com`. Si su cuenta de Opsgenie está alojada en la región de servicio de la UE, use `https://api.eu.opsgenie.com` en su lugar. Si sus alertas residen en Jira Service Management Operations (Atlassian está integrando Opsgenie en JSM), use `https://api.atlassian.com/jsm/ops/integration`. -- **API Key** debe establecerse en una clave de **integración API** de Opsgenie. Un administrador de la cuenta puede crear una en la aplicación web de Opsgenie en **Settings > Integrations**: añada una integración de tipo **API** y otórguele *Create and Update Access* (y *Read Access* para que DefectDojo pueda verificar la conexión). Tenga en cuenta que esto es una clave de integración, no una clave de API personal - DefectDojo se autentica con autorización `GenieKey`, que solo admiten las claves de integración. - -### Mapeo del Issue Tracker - -- **Team Name** *(opcional)* debe ser el nombre del equipo de Opsgenie que se añadirá como responsable en las alertas creadas. Puede dejarlo vacío: si la clave de integración de la API tiene alcance de equipo, las alertas se enrutan automáticamente a ese equipo, y en caso contrario las propias reglas de enrutamiento de su cuenta deciden los responsables. - -### Detalles del mapeo de severidad - -Las severidades se mapean al campo **Priority** de la alerta de Opsgenie, que usa la escala fija de Opsgenie de `P1` (crítica) a `P5` (informativa): - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `P5` -- **Low Mapping**: `P4` -- **Medium Mapping**: `P3` -- **High Mapping**: `P2` -- **Critical Mapping**: `P1` - -Si una severidad se mapea a un valor no reconocido, se omite la prioridad y Opsgenie aplica su propio valor predeterminado (`P3`). - -### Detalles del mapeo de estado - -Las alertas de Opsgenie son `open` o `closed`, y una alerta abierta puede además estar `acknowledged`: - -- **Status Field Name**: `Status` -- **Active Mapping**: `open` -- **Closed Mapping**: `closed` -- **False Positive Mapping**: `closed` -- **Risk Accepted Mapping**: `acknowledged` - -Tenga en cuenta que `closed` es un estado final en Opsgenie - una alerta cerrada no se puede reabrir, y su alias queda liberado. A diferencia de otras herramientas, Opsgenie sí permite editar el contenido después de la creación, así que enviar un Hallazgo actualizado sincroniza su mensaje, descripción y prioridad junto con el estado. - -DefectDojo establece el **alias** de cada alerta con una clave estable derivada del Hallazgo o Grupo de Hallazgos, y Opsgenie deduplica las alertas abiertas por alias - así que reenviar el mismo Hallazgo actualiza la alerta abierta existente en lugar de crear un duplicado. - -## PagerDuty - -La integración de PagerDuty le permite enviar los Hallazgos y Grupos de Hallazgos de DefectDojo como incidentes de PagerDuty, abiertos en un servicio de PagerDuty de su elección. - -### Configuración de la instancia - -- **Label** debe ser la etiqueta que desea usar para identificar esta integración. -- **Location** debe establecerse en `https://api.pagerduty.com`. Si su cuenta de PagerDuty está alojada en la región de servicio de la UE, use `https://api.eu.pagerduty.com` en su lugar. -- **API Token** debe establecerse en una clave de la API REST de PagerDuty. Un administrador de la cuenta puede crear una en la aplicación web de PagerDuty en **Integrations > API Access Keys > Create New API Key**. Deje sin marcar "Read-only" - DefectDojo necesita crear y actualizar incidentes. -- **From Email** debe ser la dirección de correo electrónico de un usuario válido de su cuenta de PagerDuty. PagerDuty requiere esta dirección al crear o actualizar incidentes, y se mostrará como el solicitante del incidente. - -### Mapeo del Issue Tracker - -- **Service ID** debe ser el ID del servicio de PagerDuty en el que se abrirán los incidentes. Puede encontrarlo al final de la URL al ver el servicio en PagerDuty, por ejemplo `https://{your-subdomain}.pagerduty.com/service-directory/{service id}`. - -### Detalles del mapeo de severidad - -De forma predeterminada, esto se mapea al campo **Urgency** del incidente de PagerDuty, que solo acepta `high` o `low`: - -- **Severity Field Name**: `Urgency` -- **Info Mapping**: `low` -- **Low Mapping**: `low` -- **Medium Mapping**: `low` -- **High Mapping**: `high` -- **Critical Mapping**: `high` - -Alternativamente, si su cuenta de PagerDuty tiene habilitadas las [Priorities](https://support.pagerduty.com/main/docs/incident-priority), puede mapear las severidades a nombres de Priority en su lugar. Establezca **Severity Field Name** en `Priority` y use los nombres de Priority de su cuenta (por ejemplo `P1` a `P5`) como valores de mapeo. Al mapear a Priority, la Urgency del incidente queda a cargo de las propias reglas de urgencia de su servicio. - -### Detalles del mapeo de estado - -Los incidentes de PagerDuty tienen tres estados: `triggered`, `acknowledged` y `resolved`. - -- **Status Field Name**: `Status` -- **Active Mapping**: `triggered` -- **Closed Mapping**: `resolved` -- **False Positive Mapping**: `resolved` -- **Risk Accepted Mapping**: `acknowledged` - -Tenga en cuenta que `resolved` es un estado final en PagerDuty - un incidente resuelto no se puede reabrir. Tenga en cuenta también que PagerDuty no permite editar el título o la descripción de un incidente después de su creación, así que enviar un Hallazgo actualizado sincronizará su estado, urgencia y prioridad, pero no los cambios de contenido. - -## ServiceNow - -La integración con ServiceNow le permite enviar los Hallazgos de DefectDojo como Incidentes de ServiceNow. - -### Configuración de la instancia - -DefectDojo se autentica ante ServiceNow mediante OAuth 2.0. La forma de crear las credenciales de OAuth depende de la versión de ServiceNow: las versiones más recientes (Zurich y posteriores) usan una concesión de Client Credentials, mientras que las versiones anteriores usan un token de actualización (refresh token). - -#### ServiceNow Zurich y posteriores (client credentials) - -Las versiones recientes de ServiceNow han descontinuado la opción clásica "Create an OAuth API endpoint for external clients" en favor de la **New Inbound Integration Experience**, que emite una concesión OAuth de **Client Credentials** vinculada a una cuenta de servicio: - -1. En la barra de navegación izquierda, busque "Application Registry" y selecciónela. -2. Haga clic en **New** y luego elija **New Inbound Integration Experience**. -3. Seleccione **New Integration → OAuth - Client credentials grant**. -4. Configure **OAuth Application User** con la cuenta de servicio que creará los Incidentes. Los roles de esa cuenta determinan lo que DefectDojo puede escribir. -5. Guarde el registro. ServiceNow genera automáticamente el **Client ID** y el **Client Secret** (deje esos campos en blanco al crear el registro). - -Luego, en DefectDojo: - -- **Instance Label** debe ser la etiqueta que desee usar para identificar esta integración. -- **Location** debe configurarse con la URL de su servidor ServiceNow, por ejemplo `https://your-organization.service-now.com/`. -- **Client ID** debe ser el Client ID del registro de OAuth. -- **Client Secret** debe ser el Client Secret del registro de OAuth. - -Deje vacíos los campos Refresh Token, Username y Password: DefectDojo solicita un token nuevo mediante client credentials en cada sincronización. - -#### Versiones anteriores de ServiceNow (refresh token) - -En las versiones que aún ofrecen el registro clásico, obtenga un Refresh Token asociado al Usuario o a la cuenta de servicio que enviará los Incidentes a ServiceNow: - -1. En la barra de navegación izquierda, busque "Application Registry" y selecciónela. -2. Haga clic en "New". -3. Elija "Create an OAuth API endpoint for external clients". -4. Complete los campos obligatorios: - * Name: proporcione un nombre significativo para su aplicación (por ejemplo, Vulnerability Integration Client). - * (Opcional) Ajuste la vigencia del token: - * Access Token Lifespan: el valor predeterminado es 1800 segundos (30 minutos). - * Refresh Token Lifespan: el valor predeterminado es 8640000 segundos (aproximadamente 100 días). -5. Haga clic en Submit para crear el registro de la aplicación. -6. Después de enviarlo, seleccione la aplicación en la lista y anote los campos **Client ID y Client Secret**. - -Luego deberá usar este registro para obtener un Refresh Token, que solo se puede obtener a través de la API de ServiceNow. Abra una ventana de terminal y pegue lo siguiente (sustituyendo las variables entre `{{}}` por la información real de su usuario) - -``` -curl --request POST \ - --url {{INSTANCE_HOST}}/oauth_token.do \ - --header 'content-type: application/x-www-form-urlencoded' \ - --data grant_type=password \ - --data 'client_id={{CLIENT_ID}}' \ - --data 'client_secret={{CLIENT_SECRET}}' \ - --data 'username={{USERNAME}}' \ - --data 'password={{PASSWORD}}' - ``` - -Si sus credenciales de ServiceNow son correctas y permiten acceso de nivel administrador a ServiceNow, debería recibir una respuesta con un RefreshToken. Necesitará ese token para completar la integración con DefectDojo. - -- **Instance Label** debe ser la etiqueta que desee usar para identificar esta integración. -- **Location** debe configurarse con la URL de su servidor ServiceNow, por ejemplo `https://your-organization.service-now.com/`. -- **Refresh Token** es donde debe introducirse el Refresh Token. -- **Client ID** debe ser el Client ID configurado en el OAuth App Registration. -- **Client Secret** debe ser el Client Secret configurado en el OAuth App Registration. - -### Detalles del mapeo de severidad - -Esto se corresponde con el campo Impact de ServiceNow. -- **Mapeo de Informativa**: `1` -- **Mapeo de Baja**: `1` -- **Mapeo de Media**: `2` -- **Mapeo de Alta**: `3` -- **Mapeo de Crítica**: `3` - -### Detalles del mapeo de estado - -- **Nombre del campo de estado**: `State` -- **Mapeo de Activo**: `New` -- **Mapeo de Cerrado**: `Closed` -- **Mapeo de Falso positivo**: `Resolved` -- **Mapeo de Riesgo aceptado**: `Resolved` - -Cada mapeo acepta una etiqueta de estado estándar (`New`, `In Progress`, `On Hold`, `Resolved`, `Closed`, `Cancelled`) o un valor de estado numérico. En instancias con estados de Incidente personalizados, o cuando se apunta a una tabla distinta de `incident`, use el **valor de estado** numérico de la lista de opciones de su instancia; un valor numérico fuera del conjunto estándar se envía a ServiceNow exactamente como se configuró. El valor predeterminado integrado del código de resolución solo acompaña a los estados estándar de resuelto/cerrado, así que combine los valores de estado personalizados con los mapeos de campos de cierre y resolución que se describen a continuación. - -### Campos de cierre y resolución - -Algunas instancias de ServiceNow aplican una Data Policy que hace obligatorios campos como el **Resolution code** (`close_code`) cada vez que un Incidente pasa a un estado resuelto o cerrado. Si DefectDojo cierra un Incidente sin ellos, ServiceNow rechaza la escritura con un HTTP 403 *"Data Policy Exception"* y el motivo queda registrado en la vista de Errores de la integración. - -Asocie los campos requeridos al cambio de estado mediante **Custom Field Mappings**, configurando **Apply On** con la disposición que debe incluirlos: - -- **Transition to Closed**: se envía cuando un Hallazgo se mitiga o se cierra. -- **Transition to False Positive**: se envía cuando un Hallazgo se marca como falso positivo. -- **Transition to Risk Accepted**: se envía cuando un Hallazgo tiene el riesgo aceptado. - -Por ejemplo, para satisfacer un Resolution code obligatorio: - -| Source | Field Name | Value | Apply On | -|---|---|---|---| -| Static | `close_code` | `Resolved by DefectDojo` | Transition to Closed | -| Static | `close_notes` | `Reviewed by the security team` | Transition to Closed | -| Static | `close_code` | `Not a defect` | Transition to False Positive | - -Notas: - -- Field Name es el nombre de columna de ServiceNow: `close_code`, `close_notes`, o un campo personalizado `u_...`. -- Los mapeos de transición se disparan cuando el estado del registro realmente cambia: un Hallazgo que ya está cerrado cuando se envía por primera vez, una actualización que cierra o reabre el registro, y el cierre forzado cuando se elimina un enlace de ticket. No se vuelven a enviar en actualizaciones rutinarias de un registro sin cambios, por lo que los campos de bitácora como `work_notes` reciben una entrada por cada transición. -- Los campos de referencia como `assignment_group` y `assigned_to` esperan un **sys_id**, no un nombre para mostrar. -- Los valores que se interpretan como JSON se envían tipados: `true`, `42`, `[...]`, `{...}`, y `null`, que borra el campo. Para enviar ese texto como una cadena literal, enciérrelo entre comillas dobles (por ejemplo, `"null"`). -- `short_description`, `description`, `state`, `impact`, `urgency` y `priority` pertenecen a la plantilla de descripción y a los mapeos de severidad/estado, por lo que no se pueden configurar mediante un mapeo de campo personalizado. -- En tablas distintas de `incident`, los valores de estado que coinciden con el conjunto estándar de Incidente (`1`, `2`, `3`, `6`, `7`, `8`) se siguen interpretando con la semántica de Incidente, incluido el valor predeterminado automático de Resolution code en `6`/`7`/`8`. Prefiera valores de estado fuera de ese rango en tablas personalizadas, o proporcione explícitamente los campos de cierre como se indicó anteriormente. - -## ServiceNow SecOps - -La integración de ServiceNow SecOps (también conocida como **ServiceNow SecOps / Vulnerability Response**) envía los Hallazgos y Grupos de Hallazgos de DefectDojo a una tabla de seguridad de ServiceNow —un **Security Incident** (`sn_si_incident`) o un **Vulnerable Item** (`sn_vul_vulnerable_item`)— y la mantiene sincronizada a medida que el Hallazgo cambia (creación, actualización y resolución/cierre). Es la contraparte de operaciones de seguridad de la integración de ServiceNow como sistema de tickets descrita arriba; use ServiceNow SecOps cuando ejecute las aplicaciones Security Incident Response (SIR) o Vulnerability Response (VR). - -### Configuración de la instancia - -- **Instance Label** debe ser la etiqueta que desee usar para identificar esta integración. -- **Location** debe configurarse con la URL de su servidor ServiceNow, por ejemplo `https://your-organization.service-now.com/`. - -ServiceNow SecOps admite tres métodos de autenticación; proporcione **uno**: - -- **OAuth 2.0**: introduzca un **Client ID**, un **Client Secret** y un **Refresh Token**. Obténgalos exactamente como se describe en la sección [ServiceNow](#servicenow) anterior (cree un endpoint de API OAuth en el Application Registry y luego intercambie sus credenciales en `/oauth_token.do` por un refresh token). Alternativamente, proporcione el **Client ID** y el **Client Secret** junto con un **Username** y un **Password** para usar la concesión de contraseña de OAuth en lugar de un refresh token. -- **API Key**: introduzca una **API Key**, que se envía como el encabezado `x-sn-apikey`. La clave no autentica nada hasta que se le asocie un Inbound Authentication Profile y una REST API Access Policy en la instancia. -- **HTTP Basic**: introduzca el **Username** y el **Password** de la cuenta de servicio. - -La cuenta de servicio (o el cliente OAuth) necesita acceso de escritura a la tabla de destino. - -### Mapeo del sistema de tickets - -- **Target Table** selecciona la tabla de ServiceNow en la que se escriben los registros: **Security Incident** (`sn_si_incident`, el valor predeterminado) o **Vulnerable Item** (`sn_vul_vulnerable_item`). - -### Detalles del mapeo de severidad - -Para un Security Incident, esto se corresponde con el campo **Impact**; ServiceNow deriva la Priority del incidente a partir de Impact y Urgency, por lo que Urgency refleja el Impact mapeado a menos que lo mapee usted mismo. Para un Vulnerable Item, mapee la severidad al campo de riesgo que use su instancia. Los valores predeterminados a continuación coinciden con la escala estándar de Impact de SIR (`1` Alta, `2` Media, `3` Baja) y son editables. - -- **Nombre del campo de severidad**: `impact` -- **Mapeo de Informativa**: `3` -- **Mapeo de Baja**: `3` -- **Mapeo de Media**: `2` -- **Mapeo de Alta**: `1` -- **Mapeo de Crítica**: `1` - -### Detalles del mapeo de estado - -Esto se corresponde con el campo **State** del registro. Los valores de State son códigos numéricos que difieren entre las tablas Security Incident y Vulnerable Item y pueden personalizarse por instancia, así que revíselos contra su propia configuración. Los valores predeterminados a continuación usan los códigos de estado estándar de SIR (`16` Analysis, `3` Closed). - -- **Nombre del campo de estado**: `state` -- **Mapeo de Activo**: `16` -- **Mapeo de Cerrado**: `3` -- **Mapeo de Falso positivo**: `3` -- **Mapeo de Riesgo aceptado**: `3` - -Cuando se cierra un registro, DefectDojo también configura el **Close Code** y las **Close Notes** de ServiceNow (`Resolved` para los Hallazgos cerrados, `False positive` y `Risk accepted` para los estados correspondientes). - -### Comportamientos específicos de ServiceNow SecOps - -- **Deduplicación**: cada registro se etiqueta con el identificador de DefectDojo del Hallazgo o del Grupo de Hallazgos en su `correlation_id`. Antes de crear un registro, DefectDojo busca uno existente por `correlation_id`; si hay coincidencia, se adopta y se actualiza en lugar de duplicarse, de modo que las resincronizaciones son idempotentes. -- Las **actualizaciones** se publican en la bitácora **Work notes** del registro (interna), nunca en los Comments visibles para el cliente. -- **Resolver al eliminar**: eliminar un Hallazgo en DefectDojo resuelve/cierra el registro de ServiceNow (State + Close Code) en lugar de eliminarlo; los registros nunca se eliminan de forma permanente. -- **Campos de referencia**: los valores opcionales `cmdb_ci`, `assignment_group` y `assigned_to` pueden proporcionarse como nombres para mostrar; DefectDojo resuelve cada uno a su `sys_id`. Un nombre que no se resuelve se descarta con una advertencia en lugar de hacer fallar el envío. - -## Shortcut - -La integración con Shortcut le permite enviar los Hallazgos de DefectDojo como Stories de [Shortcut](https://www.shortcut.com/). Las Stories se crean con el tipo de story Bug y se asignan a un Team de su espacio de trabajo de Shortcut. - -### Configuración de la instancia - -- **Label** debe ser la etiqueta que desee usar para identificar esta integración. -- **Location** debe configurarse como `https://api.app.shortcut.com`. -- **API Token** debe configurarse con un token de API de Shortcut. Los tokens pueden generarse en Shortcut en Settings, luego Your Account, luego [API Tokens](https://app.shortcut.com/settings/account/api-tokens). - -### Mapeo del sistema de tickets - -- **Team (Group) ID** debe configurarse con el UUID del Team de Shortcut para el que se crearán las Stories. Puede encontrar este UUID abriendo la página del Team en Shortcut y copiando el identificador de la URL, o llamando a la API de Shortcut: - -``` -curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/groups -``` - -### Detalles del mapeo de severidad - -Cada valor de severidad se aplica a la Story como una etiqueta. Las etiquetas se crean automáticamente en Shortcut si aún no existen, por lo que los valores predeterminados a continuación pueden usarse tal cual, o sustituirse por nombres de etiqueta de su elección. Cuando cambia la severidad de un Hallazgo, la etiqueta de severidad anterior se elimina de la Story y se añade la nueva. - -- **Nombre del campo de severidad**: `Label` -- **Mapeo de Informativa**: `sev-info` -- **Mapeo de Baja**: `sev-low` -- **Mapeo de Media**: `sev-medium` -- **Mapeo de Alta**: `sev-high` -- **Mapeo de Crítica**: `sev-critical` - -### Detalles del mapeo de estado - -Cada valor de estado debe configurarse con el ID numérico de un Workflow State en su espacio de trabajo de Shortcut. Los ID de Workflow State son únicos para cada espacio de trabajo, por lo que no hay valores predeterminados. Puede listar los Workflow States y sus ID llamando a la API de Shortcut: - -``` -curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/workflows -``` - -- **Nombre del campo de estado**: `Workflow State ID` -- **Mapeo de Activo**: el ID del estado para trabajo abierto, por ejemplo un estado de Backlog o To Do. -- **Mapeo de Cerrado**: el ID de un estado de tipo Done. Cuando se elimina un Hallazgo en DefectDojo, su Story se mueve a este estado. -- **Mapeo de Falso positivo**: el ID del estado que se usará para los Hallazgos marcados como Falso positivo. -- **Mapeo de Riesgo aceptado**: el ID del estado que se usará para los Hallazgos con Riesgo aceptado. - -## Freshservice - -La integración con Freshservice le permite enviar los Hallazgos y Grupos de Hallazgos de DefectDojo como tickets de Freshservice, asignados a un Group de agentes de su elección. - -### Configuración de la instancia - -- **Label** debe ser la etiqueta que desee usar para identificar esta integración. -- **Location** debe configurarse con su URL de Freshservice: `https://yourcompany.freshservice.com`. -- **API Key** debe ser una clave de API de Freshservice. Encuéntrela haciendo clic en su foto de perfil (arriba a la derecha) > **Profile settings**: la clave aparece a la derecha, debajo de la sección **Delegate Approvals**, después de completar el captcha. Si no aparece ninguna clave ahí, es posible que el acceso a la API esté deshabilitado a nivel de cuenta y un administrador deba habilitarlo primero. -- **Requester Email** debe ser la dirección de correo en cuyo nombre se solicitan los tickets. Freshservice exige un solicitante en cada ticket, por lo que DefectDojo crea los tickets con esta dirección como solicitante. - -### Mapeo del sistema de tickets - -- **Group ID** debe ser el ID numérico del Group de agentes de Freshservice al que se asignarán los tickets. Encuéntrelo en la URL al ver el grupo en **Admin > Agent Groups**. -- **Workspace ID** (opcional) enruta los tickets a un espacio de trabajo específico en cuentas con varios espacios de trabajo. Déjelo vacío para usar el espacio de trabajo principal. - -### Detalles del mapeo de severidad - -Esto se corresponde con el campo **Priority** del ticket de Freshservice, que usa códigos numéricos (`1` Low, `2` Medium, `3` High, `4` Urgent). También se aceptan los nombres de prioridad: - -- **Nombre del campo de severidad**: `Priority` -- **Mapeo de Informativa**: `1` -- **Mapeo de Baja**: `1` -- **Mapeo de Media**: `2` -- **Mapeo de Alta**: `3` -- **Mapeo de Crítica**: `4` - -### Detalles del mapeo de estado - -Esto se corresponde con el campo **Status** del ticket, que usa códigos numéricos (`2` Open, `3` Pending, `4` Resolved, `5` Closed). También se aceptan los nombres de estado: - -- **Nombre del campo de estado**: `Status` -- **Mapeo de Activo**: `2` -- **Mapeo de Cerrado**: `5` -- **Mapeo de Falso positivo**: `5` -- **Mapeo de Riesgo aceptado**: `3` - -Algunos comportamientos específicos de Freshservice que debe tener en cuenta: - -- Las actualizaciones sincronizan el contenido completo del ticket: Freshservice permite editar el asunto y la descripción después de la creación. -- Los tickets se cierran en lugar de eliminarse cuando se elimina un Hallazgo; los tickets ya Resolved o Closed se dejan sin modificar. Se adjunta automáticamente una nota de resolución al cerrar, por lo que las cuentas que exigen una (una regla de negocio habitual) aceptan el cierre. -- Algunas cuentas calculan la prioridad de un ticket a partir de una matriz de Impact/Urgency o de una regla de negocio, e ignoran la prioridad enviada en la creación. DefectDojo detecta esto y vuelve a aplicar la prioridad mapeada con una actualización posterior, de modo que el mapeo sigue teniendo efecto. - -## ServiceDesk Plus - -La integración con ManageEngine ServiceDesk Plus le permite enviar los Hallazgos y Grupos de Hallazgos de DefectDojo como solicitudes (requests) de ServiceDesk Plus, asignadas a un Group de soporte de su elección. La misma integración admite tanto la edición **cloud** (ServiceDesk Plus OnDemand) como la **on-premises**; las credenciales que proporcione determinan qué modo se usa. - -### Configuración de la instancia - -- **Label** debe ser la etiqueta que desee usar para identificar esta integración. -- **Location** debe configurarse con su URL de ServiceDesk Plus: `https://sdpondemand.manageengine.com` para la edición cloud (o su equivalente regional), o la dirección de su servidor para instalaciones on-premises. - -Luego proporcione **uno** de los dos conjuntos de credenciales: - -#### On-premises: Technician Key - -- **Technician Key** debe ser una clave de API generada para un técnico en su servidor, en **Admin > General Settings > API**. Deje vacíos los campos de OAuth de Zoho. - -#### Cloud: Zoho OAuth - -La edición cloud se autentica mediante Zoho Accounts OAuth: - -1. Abra la [Zoho API Console](https://api-console.zoho.com/) y cree un **Self Client**. -2. Anote el **Client ID** y el **Client Secret**. -3. En la pestaña "Generate Code" del Self Client, introduzca el alcance `SDPOnDemand.requests.ALL`, elija una duración y genere el código. -4. Intercambie el código por un refresh token: - -``` -curl --request POST \ - --url 'https://accounts.zoho.com/oauth/v2/token' \ - --data 'grant_type=authorization_code' \ - --data 'client_id={{CLIENT_ID}}' \ - --data 'client_secret={{CLIENT_SECRET}}' \ - --data 'code={{GENERATED_CODE}}' -``` - -5. Introduzca el **Client ID**, el **Client Secret** y el **Refresh Token** obtenido en el formulario de la instancia. Si su cuenta está alojada fuera del centro de datos de EE. UU., configure **Token URL** con el endpoint regional de Zoho Accounts correspondiente (por ejemplo, `https://accounts.zoho.eu/oauth/v2/token`). - -### Mapeo del sistema de tickets - -- **Group Name** debe ser el nombre del grupo de soporte de ServiceDesk Plus al que se asignarán las solicitudes, exactamente como aparece en **Admin > Users > Support Groups**. - -### Detalles del mapeo de severidad - -Esto se corresponde con el campo **Priority** de la solicitud de ServiceDesk Plus por nombre, usando los nombres de prioridad de su cuenta: - -- **Nombre del campo de severidad**: `Priority` -- **Mapeo de Informativa**: `Low` -- **Mapeo de Baja**: `Normal` -- **Mapeo de Media**: `Medium` -- **Mapeo de Alta**: `High` -- **Mapeo de Crítica**: `High` - -### Detalles del mapeo de estado - -Esto se corresponde con el campo **Status** de la solicitud por nombre. Los valores predeterminados usan los estados integrados: - -- **Nombre del campo de estado**: `Status` -- **Mapeo de Activo**: `Open` -- **Mapeo de Cerrado**: `Closed` -- **Mapeo de Falso positivo**: `Closed` -- **Mapeo de Riesgo aceptado**: `On Hold` - -Algunos comportamientos específicos de ServiceDesk Plus que debe tener en cuenta: - -- Las actualizaciones sincronizan el contenido completo de la solicitud: a diferencia de la mayoría de los sistemas de tickets, ServiceDesk Plus permite editar el asunto y la descripción después de la creación. -- Las solicitudes se cierran en lugar de eliminarse cuando se elimina un Hallazgo; las solicitudes ya Closed o Resolved se dejan sin modificar. -- Si su cuenta hace obligatorios ciertos campos al cerrar (por ejemplo, una resolución), un cierre enviado desde DefectDojo puede ser rechazado por esas reglas y aparecerá en la tabla de errores de la integración. - -## Zendesk - -La integración con Zendesk le permite enviar los Hallazgos y Grupos de Hallazgos de DefectDojo como tickets de Zendesk, asignados a un Group de Zendesk de su elección. - -### Configuración de la instancia - -- **Label** debe ser la etiqueta que desee usar para identificar esta integración. -- **Location** debe configurarse con la URL de su cuenta de Zendesk, por ejemplo `https://your-subdomain.zendesk.com`. -- **Email** debe ser la dirección de correo del agente de Zendesk al que pertenece el token de API. -- **API Token** debe configurarse con un token de API de Zendesk. Un administrador puede crear uno en el Zendesk Admin Center, en **Apps and integrations > APIs > Zendesk API** (debe habilitarse el acceso por token). - -### Mapeo del sistema de tickets - -- **Group ID** debe ser el ID numérico del Group de Zendesk al que se asignarán los tickets. Puede encontrarlo en el Admin Center, en **People > Team > Groups**, o en la URL al ver el grupo. - -### Detalles del mapeo de severidad - -Esto se corresponde con el campo **Priority** del ticket de Zendesk, que acepta `low`, `normal`, `high` y `urgent`: - -- **Nombre del campo de severidad**: `Priority` -- **Mapeo de Informativa**: `low` -- **Mapeo de Baja**: `low` -- **Mapeo de Media**: `normal` -- **Mapeo de Alta**: `high` -- **Mapeo de Crítica**: `urgent` - -### Detalles del mapeo de estado - -Los tickets de Zendesk admiten los estados `new`, `open`, `pending`, `hold` y `closed`, así como `solved`. Tenga en cuenta que `hold` debe estar habilitado en su cuenta antes de poder usarse. - -- **Nombre del campo de estado**: `Status` -- **Mapeo de Activo**: `new` -- **Mapeo de Cerrado**: `solved` -- **Mapeo de Falso positivo**: `solved` -- **Mapeo de Riesgo aceptado**: `pending` - -Algunos comportamientos específicos de Zendesk que debe tener en cuenta: - -- La descripción del ticket es el primer comentario en Zendesk y no se puede editar después de la creación, por lo que enviar un Hallazgo actualizado sincronizará el asunto, la prioridad y el estado del ticket, pero no los cambios de descripción. -- Los tickets se marcan como `solved` en lugar de eliminarse cuando se elimina un Hallazgo; Zendesk cierra automáticamente los tickets resueltos después de un período de tiempo. -- `closed` es un estado final: los tickets cerrados no se pueden actualizar en absoluto, y enviar un Hallazgo cuyo ticket esté cerrado generará un error. diff --git a/docs/content/connectors/downstream/downstream_toolreference.fr.md b/docs/content/connectors/downstream/downstream_toolreference.fr.md deleted file mode 100644 index 302b3b1f1d5..00000000000 --- a/docs/content/connectors/downstream/downstream_toolreference.fr.md +++ /dev/null @@ -1,765 +0,0 @@ ---- -title: Référence des outils de connecteurs descendants -description: Guides de configuration détaillés pour les connecteurs descendants -weight: 1 -audience: pro -aliases: -- /fr/en/share_your_findings/integrations_toolreference -- /fr/issue_tracking/pro_integration/integrations_toolreference/ ---- - -## Azure DevOps Boards - -### Configuration de l'instance - -- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur votre URL Azure - par exemple `https://dev.azure.com/{your organization}` -- **Token** doit être défini sur un jeton d'accès personnel Azure. - -L'authentification avec Azure DevOps nécessite un [jeton d'accès personnel](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows) -dont les autorisations sont définies sur « Read, Write and Manage » pour les « Work Items » du projet Azure avec lequel vous souhaitez travailler. - -### Mappage du suivi des tickets - -Ces informations déterminent la façon dont DefectDojo associe les attributs d'une Constatation ou d'un Groupe de constatations à un projet donné dans Azure DevOps : - -#### Détails du mappage du suivi des tickets - -Le champ `Project ID` correspond au nom ou à l'ID du projet dans Azure. - -#### Détails du mappage de la sévérité - -Les attributs du formulaire sont fournis par défaut et sont les suivants : - -- **Severity Field Name** : `/fields/Microsoft.VSTS.Common.Priority` -- **Info Mapping** : `4` -- **Low Mapping** : `4` -- **Medium Mapping** : `3` -- **High Mapping** : `2` -- **Critical Mapping** : `1` - -#### Détails du mappage du statut - -Les attributs du formulaire sont fournis par défaut et sont les suivants : - -- **Status Field Name** : `/fields/System.State` -- **Active Mapping** : `To Do` -- **Closed Mapping** : `Done` -- **False Positive Mapping** : `Done` -- **Risk Accepted Mapping** : `Done` - -## Bitbucket - -L'intégration Bitbucket vous permet de transmettre des tickets vers le [suivi des tickets](https://support.atlassian.com/bitbucket-cloud/docs/enable-an-issue-tracker/) d'un dépôt Bitbucket Cloud. - -Le suivi des tickets est optionnel dans Bitbucket et doit être activé sur le dépôt avant que DefectDojo puisse y créer des tickets. Pour l'activer, ouvrez le dépôt dans Bitbucket, sélectionnez **Repository settings**, puis activez le suivi des tickets sous **Features**. - -### Configuration de l'instance - -- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur `https://bitbucket.org`. -- **Email** doit être l'adresse e-mail du compte Atlassian auquel appartient le jeton API. -- **API Token** doit être défini sur un jeton API Atlassian à portée limitée. - -Les mots de passe d'application Bitbucket sont dépréciés par Atlassian et ne fonctionneront pas avec cette intégration. Pour créer un jeton API : - -1. Ouvrez les [paramètres du compte Atlassian](https://id.atlassian.com/manage-profile/security/api-tokens) et choisissez **Security**, puis **Create and manage API tokens**. -2. Choisissez **Create API token with scopes**, nommez le jeton et définissez une date d'expiration. -3. Sélectionnez **Bitbucket** comme application. -4. Accordez au jeton l'autorisation de lire les dépôts, ainsi que de lire et écrire des tickets. - -### Mappage du suivi des tickets - -- **Workspace** doit correspondre au slug de l'espace de travail contenant le dépôt, tel qu'il apparaît dans les URL de bitbucket.org. -- **Repository Slug** doit correspondre au slug du dépôt dans lequel vous souhaitez créer des tickets. - -### Détails du mappage de la sévérité - -Ceci correspond au champ Priority des tickets Bitbucket. Les attributs du formulaire sont fournis par défaut, et chaque valeur doit être l'une des priorités de Bitbucket : `trivial`, `minor`, `major`, `critical` ou `blocker`. - -- **Severity Field Name** : `priority` -- **Info Mapping** : `trivial` -- **Low Mapping** : `minor` -- **Medium Mapping** : `major` -- **High Mapping** : `critical` -- **Critical Mapping** : `blocker` - -### Détails du mappage du statut - -Ceci correspond au champ State des tickets Bitbucket. Chaque valeur doit être l'un des états de ticket de Bitbucket : `new`, `open`, `resolved`, `on hold`, `invalid`, `duplicate`, `wontfix` ou `closed`. - -- **Status Field Name** : `state` -- **Active Mapping** : `new` -- **Closed Mapping** : `resolved` -- **False Positive Mapping** : `invalid` -- **Risk Accepted Mapping** : `wontfix` - -## GitHub - -L'intégration GitHub vous permet d'ajouter des tickets à un [GitHub Project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects), ce qui ouvre également des tickets dans un dépôt (Repo) associé. Ces dépôts/projets peuvent être associés soit à une organisation GitHub, soit à un compte GitHub personnel. - -### Configuration de l'instance - -- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur l'URL de votre utilisateur ou organisation GitHub, selon l'endroit où vous souhaitez créer des tickets, par exemple `https://github.com/{your-organization}` -- **Token** doit être défini sur un jeton d'accès personnel GitHub. - -Les jetons d'accès personnels pour GitHub peuvent être créés à l'adresse https://github.com/settings/tokens. Le jeton doit disposer des portées Repo et Project. - -### Mappage du suivi des tickets - -- **Issue Tracker Mapping Label** doit être défini pour identifier le projet ou le dépôt dans lequel vous souhaitez créer des tickets. -- **Project Number** doit correspondre à l'ID du projet GitHub vers lequel vous souhaitez envoyer les éléments. Vous pouvez l'obtenir depuis l'URL affichée lorsque vous consultez un projet, par exemple `https://github.com/orgs/{your-org}/projects/{project number}`. -- **Repository Name** doit correspondre au nom d'un dépôt associé à votre organisation (ou utilisateur) vers lequel vous souhaitez transmettre des tickets. - - -### Détails du mappage de la sévérité - -**Pour configurer l'intégration, le projet DOIT disposer d'un champ personnalisé créé pour représenter la priorité des tickets ; sinon, la sévérité ne sera pas correctement mappée et les tickets ne seront pas transmis à GitHub.** - -Suivez ce guide pour créer un [champ personnalisé](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/quickstart-for-projects#creating-a-field-to-track-priority). -Chaque sévérité doit disposer d'une option à sélection unique correspondante. Par exemple, par défaut, DefectDojo propose P0, P1, P2, P3, P4 comme valeurs possibles de priorité, et chacune d'elles doit être ajoutée au champ personnalisé Priority. - -- **Severity Field Name** : `Priority` -- **Info Mapping** : `P0` -- **Low Mapping** : `P1` -- **Medium Mapping** : `P2` -- **High Mapping** : `P3` -- **Critical Mapping** : `P4` - -### Détails du mappage du statut - -Par défaut, les nouveaux projets GitHub disposent des statuts « In Progress » et « Done » pour les tickets. Des statuts supplémentaires peuvent être ajoutés au projet pour suivre les statuts Faux positif ou Risque accepté si vous le souhaitez. L'une des façons d'y parvenir consiste à ajouter une nouvelle colonne de statut au tableau du projet. - -- **Status Field Name** : `Status` -- **Active Mapping** : `In Progress` -- **Closed Mapping** : `Done` -- **False Positive Mapping** : `Done` -- **Risk Accepted Mapping** : `Done` - -## GitLab - -L'intégration GitLab vous permet d'ajouter des tickets à un [projet GitLab](https://docs.gitlab.com/ee/user/project/). - -### Configuration de l'instance - -- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur le lien de votre serveur GitLab, par exemple `https://gitlab.com/`. -- **Token** doit être défini sur un jeton d'accès personnel GitLab. Le jeton doit disposer des portées API. Consultez le [guide GitLab pour créer un jeton d'accès personnel](https://docs.gitlab.com/user/profile/personal_access_tokens/#create-a-personal-access-token). - -### Mappage du suivi des tickets - -- **Project Name** : le nom du projet dans GitLab vers lequel vous souhaitez envoyer les tickets. - -### Détails du mappage de la sévérité - -Ceci correspond au champ Priority de GitLab. -- **Severity Field Name** : `Priority` -- **Info Mapping** : `1` -- **Low Mapping** : `2` -- **Medium Mapping** : `3` -- **High Mapping** : `4` -- **Critical Mapping** : `5` - -### Détails du mappage du statut - -Par défaut, GitLab dispose des statuts « opened » et « closed ». Des étiquettes de statut supplémentaires peuvent être ajoutées si vous souhaitez suivre les statuts Faux positif ou Risque accepté. Consultez la [documentation GitLab](https://docs.gitlab.com/user/work_items/status/) pour plus de détails. - -- **Status Field Name** : `Status` -- **Active Mapping** : `opened` -- **Closed Mapping** : `closed` -- **False Positive Mapping** : `closed` -- **Risk Accepted Mapping** : `closed` - -## Jira - -L'intégration Jira transmet les Constatations et Groupes de constatations de DefectDojo vers un projet Jira sous forme de tickets, maintient le statut de chaque ticket synchronisé avec la Constatation, et relie la Constatation au ticket créé. Jira **Cloud** et **Data Center / Server** sont tous deux pris en charge. Jira Service Management n'est pas pris en charge. - -### Choisir une méthode d'authentification - -Définissez d'abord **Jira Deployment**, puis choisissez une **Authentication Method** : - -**Jira Cloud** -- **API Token (email + token)** — authentification HTTP Basic utilisant l'e-mail d'un compte Atlassian et un [jeton API](https://id.atlassian.com/manage-profile/security/api-tokens). Les appels sont envoyés directement à l'URL de votre site. -- **OAuth 2.0 (recommended)** — un consentement navigateur unique ; DefectDojo obtient et actualise les jetons pour vous. -- **Service Account Token** — un jeton API à portée limitée créé pour un [compte de service](https://support.atlassian.com/user-management/docs/manage-api-tokens-for-service-accounts/) Atlassian. - -**Jira Data Center / Server** -- **Personal Access Token (recommended)** -- **Username + Password** - -> **Comment l'authentification Cloud atteint Jira :** OAuth 2.0 et Service Account s'authentifient tous deux via un jeton Bearer auprès de la passerelle Atlassian — `https://api.atlassian.com/ex/jira/{cloudId}` — qui est un *hôte différent* de l'URL de votre site `https://your-site.atlassian.net`. DefectDojo utilise la passerelle pour chaque appel API, mais construit toujours le lien du ticket affiché sur une Constatation à partir de l'**URL de votre site**, de sorte que le lien sur lequel un utilisateur clique est un lien normal et navigable de type `.../browse/{ISSUE-KEY}`. (L'authentification API Token et Data Center appelle directement l'URL du site, il n'y a donc pas de séparation.) - -### Configuration de l'instance - -- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur l'**URL de votre site** Jira, par exemple `https://your-organization.atlassian.net`. Elle est utilisée pour les liens de tickets navigables et — pour l'authentification API Token et Data Center — comme URL de base de l'API. -- Les champs restants dépendent de la méthode choisie ci-dessus (e-mail + jeton API, identifiants client OAuth, jeton de compte de service, PAT, ou nom d'utilisateur + mot de passe). - -### Configuration OAuth 2.0 (Cloud) - -Créez une application dédiée dans la [console développeur Atlassian](https://developer.atlassian.com/console/myapps/), puis connectez-vous depuis DefectDojo. - -1. Choisissez **Create → OAuth 2.0 integration**. Il doit s'agir d'une *intégration OAuth 2.0* — une application Connect ou Forge ne peut pas utiliser le flux d'autorisation par code 3LO (vous obtiendriez `grant_type is not enabled for client`). -2. Lorsque l'on vous demande le **Access type**, choisissez **Resource-level**. Cela limite le jeton au seul site Jira que l'utilisateur autorise, ce qui correspond exactement à ce que cible une connexion DefectDojo. (**Account-level** accorde l'accès à tous les sites du compte Atlassian — une portée plus large que nécessaire.) -3. Dans **Permissions**, ajoutez la **Jira platform REST API** et accordez les portées listées ci-dessous. Remarque : `offline_access` n'est *pas* listée ici — il s'agit d'une portée OAuth standard que DefectDojo demande dans l'URL d'autorisation, et non d'un élément à ajouter sur cet écran. -4. Dans **Authorization**, à côté de **OAuth 2.0 (3LO)**, cliquez sur **Configure** et définissez la **Callback URL** sur `https:///integrators/jira/oauth/callback` — elle doit correspondre exactement à l'URL de votre site DefectDojo. C'est cette activation qui active le flux d'autorisation par code et les jetons de rafraîchissement ; l'omettre provoque les erreurs `grant_type is not enabled` / `Client is not allowed to use offline_access`. -5. Copiez le **Client ID** et le **Client Secret** dans le formulaire DefectDojo, puis cliquez sur **Submit** pour enregistrer la connexion. -6. Cliquez sur **Connect with Jira** et approuvez l'écran de consentement. Atlassian redirige ensuite vers DefectDojo, qui stocke les jetons et résout automatiquement votre `cloudId`. Un indicateur « Connected » apparaît en cas de succès. - -> L'hôte de rappel est votre `SITE_URL` DefectDojo. Atlassian doit pouvoir y rediriger le navigateur, et la valeur doit correspondre exactement à ce que DefectDojo envoie — utilisez donc le nom d'hôte réel par lequel vos utilisateurs accèdent à DefectDojo, et non une valeur accessible uniquement depuis l'intérieur du réseau. - -#### Portées OAuth minimales - -DefectDojo demande ces quatre portées classiques par défaut, qui constituent également le **minimum absolu** requis — chacune sous-tend un comportement spécifique : - -| Scope | Required for | -|-------|--------------| -| `read:jira-work` | Lire le projet, les tickets et les transitions disponibles (validation de la connexion et synchronisation du statut). | -| `write:jira-work` | Créer et modifier des tickets, et exécuter des transitions de statut. | -| `read:jira-user` | La vérification d'identité de la connexion — DefectDojo appelle `/myself` lors de la validation de l'accès. | -| `offline_access` | Émettre un **jeton de rafraîchissement**. Sans cela, le jeton d'accès expire (~1 heure après la connexion) et la connexion cesse de fonctionner, car DefectDojo ne peut plus le rafraîchir. | - -Atlassian recommande les portées classiques plutôt que les portées granulaires ; les quatre ci-dessus limitent l'empreinte de l'application au minimum et suffisent pour tout ce que fait l'intégration. - -##### Alternative avec portées granulaires - -Si votre organisation exige des portées **granulaires** plutôt que classiques, l'ensemble minimal équivalent est le suivant : - -| Granular scope | Required for | -|----------------|--------------| -| `read:user:jira` | La vérification d'identité `/myself`. | -| `read:project:jira` | Valider que le projet cible existe. | -| `read:issue:jira` | Lire le statut actuel d'un ticket pendant la synchronisation. | -| `write:issue:jira` | Créer et modifier des tickets **et exécuter des transitions de statut** — il n'existe pas de portée d'écriture distincte pour les transitions ; une transition est une écriture sur le ticket. | -| `read:issue.transition:jira` | Lister les transitions disponibles sur un ticket. | -| `offline_access` | Le jeton de rafraîchissement (identique aux portées classiques). | - -Selon la configuration des champs de votre site, un endpoint peut également nécessiter des portées de lecture complémentaires pour développer les champs — le plus souvent `read:status:jira` et `read:field:jira` (ainsi que `read:issue-meta:jira` pour la création). Si une transmission échoue avec une erreur `403` « scope does not match », ajoutez la portée exacte mentionnée dans l'erreur. C'est précisément cette prolifération de portées complémentaires qui justifie la recommandation des portées classiques. - -Pour la méthode **Service Account Token**, accordez au jeton `read:jira-work` et `write:jira-work` (ainsi que `read:jira-user`) — ou les équivalents granulaires ci-dessus sans `offline_access`. `offline_access` ne s'applique pas — un jeton de compte de service est longue durée et n'est pas rafraîchi par DefectDojo. - -### Mappage du suivi des tickets - -- **Project Key** : la clé du projet Jira dans lequel créer des tickets, par exemple `SEC`. -- **Issue Type** : le type de ticket à créer, par exemple `Bug` ou `Task`. La valeur par défaut est `Bug`. - -### Détails du mappage de la sévérité - -Les valeurs par défaut correspondent au schéma de priorité par défaut de Jira. Modifiez-les pour correspondre aux noms de priorité de votre projet : - -- **Severity Field Name** : `priority` -- **Info Mapping** : `Lowest` -- **Low Mapping** : `Low` -- **Medium Mapping** : `Medium` -- **High Mapping** : `High` -- **Critical Mapping** : `Highest` - -### Détails du mappage du statut - -Les statuts varient selon le workflow de chaque projet ; ces valeurs par défaut sont donc destinées à être modifiées pour correspondre aux noms de statut de **votre** workflow : - -- **Status Field Name** : `status` -- **Active Mapping** : `To Do` -- **Closed Mapping** : `Done` -- **False Positive Mapping** : `Done` -- **Risk Accepted Mapping** : `Done` - -### Champs personnalisés (facultatif) - -Vous pouvez mapper des champs Jira supplémentaires — par exemple un `resolution` requis à la fermeture, ou des `labels` — dans l'étape **Custom Fields** du mappage. Chaque mappage de champ personnalisé comporte quatre parties : - -- **Source** — d'où provient la valeur : un attribut de la **Constatation**, du **Test**, de l'**Engagement**, ou de l'**Asset** transmis, ou une **valeur statique**. -- **Value** — pour une source de type objet, l'attribut spécifique à lire, choisi dans une liste des champs de cet objet avec des libellés lisibles (par exemple *Severity*, *CVE*, *Mitigation*). Pour une source **valeur statique**, il s'agit d'une zone de texte libre dans laquelle vous saisissez la valeur littérale. -- **Vendor Field** — le champ Jira dans lequel écrire. Comme DefectDojo peut lire le catalogue de champs de Jira, il s'agit d'un sélecteur avec recherche qui liste chaque champ par son **nom d'affichage** et le résout pour vous en identifiant interne — vous sélectionnez donc *DD Close Justification* et DefectDojo stocke `customfield_10255`. Le sélecteur est alimenté à partir de la connexion ; il fonctionne donc une fois la connexion enregistrée et validée. -- **Application point** — *quand* envoyer le champ : à la **création du ticket**, à **chaque mise à jour**, ou dans le cadre d'une **transition** de statut spécifique (Actif / Fermé / Faux positif / Risque accepté). Un champ associé à une transition est envoyé dans le cadre de la modification de cette transition — c'est ainsi que vous fournissez une valeur que Jira n'accepte que sur un écran de transition, le plus souvent un `resolution` que votre workflow exige à la résolution d'un ticket. - -### Modèles de tickets (facultatif) - -Par défaut, les tickets Jira utilisent le titre et le corps intégrés de DefectDojo. Pour les personnaliser, associez un **Ticket Template** au mappage dans son étape **Ticket Template**. Un modèle définit quatre éléments indépendamment facultatifs — le résumé et la description de la **Constatation**, ainsi que le résumé et la description du **Groupe de constatations**. Tout élément laissé vide revient à la valeur par défaut intégrée, ce qui vous permet de ne remplacer que le titre, que le corps, ou les quatre. Utilisez **Test render** dans l'éditeur de modèle pour prévisualiser le rendu à partir de données d'exemple — ce qui permet de détecter des erreurs telles que des espaces réservés inconnus ou des valeurs dépassant la limite de longueur d'un champ — avant d'enregistrer. Si un modèle est ensuite supprimé, les mappages qui l'utilisaient reviennent automatiquement aux valeurs par défaut intégrées. - -### Fonctionnement - -- **Create / Update / Delete :** la création transmet un nouveau ticket et enregistre le lien sur la Constatation ; la mise à jour modifie le ticket existant ; la suppression d'une Constatation force la fermeture de son ticket (rien n'est supprimé dans Jira). Les transmissions peuvent être manuelles (« Push to Integrator ») ou automatiques selon l'Issue Tracker Assignment. -- **Réconciliation du statut :** après la création (et à chaque mise à jour), DefectDojo lit le statut actuel du ticket et, s'il diffère de la cible mappée, recherche une transition de workflow unique permettant de l'atteindre et l'applique. Si aucune transition de ce type n'existe, le mappage enregistre une erreur plutôt que d'échouer silencieusement. Tout champ personnalisé associé à une transition est envoyé avec cette transition. -- **Lien du ticket :** le lien affiché sur la Constatation est `https://your-site.atlassian.net/browse/{ISSUE-KEY}` — toujours l'URL publique de votre site, jamais la passerelle interne. -- **Cycle de vie du jeton (OAuth) :** DefectDojo gère l'intégralité du flux — il effectue l'échange du code d'autorisation, stocke les jetons d'accès et de rafraîchissement, et les rafraîchit à la demande avant chaque transmission, en persistant le nouveau jeton de rafraîchissement à chaque fois (Atlassian le fait pivoter à chaque rafraîchissement). -- **Stockage des identifiants :** tous les identifiants de connexion (mots de passe, jetons, secrets client, jetons OAuth) sont chiffrés au repos et ne sont jamais renvoyés par l'API — la modification d'une connexion affiche un texte indicatif « leave blank to keep » pour les secrets stockés. - -## Linear - -L'intégration Linear vous permet de transmettre les Constatations de DefectDojo sous forme de tickets [Linear](https://linear.app/). Les tickets sont créés dans une équipe (Team) de votre espace de travail Linear. - -### Configuration de l'instance - -- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur `https://api.linear.app/graphql`. -- **API Key** doit être définie sur une clé API personnelle Linear. Les clés peuvent être générées dans Linear sous Settings, puis Security & access, puis [API](https://linear.app/settings/account/security). La clé est envoyée à l'API GraphQL de Linear dans l'en-tête `Authorization`. - -### Mappage du suivi des tickets - -- **Team (Group) ID** doit être défini sur l'ID de l'équipe Linear pour laquelle les tickets seront créés. Vous pouvez lister vos équipes et leurs ID en appelant l'API GraphQL de Linear : - -``` -curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ - -d '{"query":"{ teams { nodes { id name key } } }"}' https://api.linear.app/graphql -``` - -### Détails du mappage de la sévérité - -Un ticket Linear porte une **priority** numérique plutôt qu'un champ de sévérité. Chaque sévérité DefectDojo est mappée à une priorité Linear, où `1` correspond à Urgent et `4` à Low : - -- **Severity Field Name** : `Priority` -- **Info Mapping** : `4` -- **Low Mapping** : `4` -- **Medium Mapping** : `3` -- **High Mapping** : `2` -- **Critical Mapping** : `1` - -### Détails du mappage du statut - -Chaque valeur de statut doit être définie sur l'ID d'un Workflow State de votre équipe Linear. Les ID de Workflow State sont propres à chaque espace de travail ; il n'existe donc pas de valeurs par défaut. Vous pouvez lister les Workflow States et leurs ID en appelant l'API GraphQL de Linear : - -``` -curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ - -d '{"query":"{ workflowStates { nodes { id name type team { key } } } }"}' https://api.linear.app/graphql -``` - -- **Status Field Name** : `Workflow State ID` -- **Active Mapping** : l'ID d'un état démarré ou non démarré, par exemple `Todo` ou `In Progress`. -- **Closed Mapping** : l'ID d'un état terminé, par exemple `Done`. Lorsqu'une Constatation est supprimée dans DefectDojo, son ticket est déplacé vers cet état. - -## Opsgenie - -L'intégration Opsgenie vous permet de transmettre les Constatations et Groupes de constatations de DefectDojo sous forme d'alertes Opsgenie, éventuellement routées vers une équipe Opsgenie en tant que répondant. - -### Configuration de l'instance - -- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur `https://api.opsgenie.com`. Si votre compte Opsgenie est hébergé dans la région de service UE, utilisez plutôt `https://api.eu.opsgenie.com`. Si vos alertes se trouvent dans Jira Service Management Operations (Atlassian intègre progressivement Opsgenie à JSM), utilisez `https://api.atlassian.com/jsm/ops/integration`. -- **API Key** doit être définie sur une clé d'**intégration API** Opsgenie. Un administrateur de compte peut en créer une dans l'application web Opsgenie, sous **Settings > Integrations** : ajoutez une intégration de type **API** et accordez-lui *Create and Update Access* (ainsi que *Read Access* afin que DefectDojo puisse vérifier la connexion). Notez qu'il s'agit d'une clé d'intégration, et non d'une clé API personnelle - DefectDojo s'authentifie avec l'autorisation `GenieKey`, que seules les clés d'intégration prennent en charge. - -### Mappage du suivi des tickets - -- **Team Name** *(facultatif)* doit correspondre au nom de l'équipe Opsgenie à ajouter comme répondant sur les alertes créées. Vous pouvez le laisser vide : si la clé d'intégration API est limitée à une équipe, les alertes sont routées automatiquement vers celle-ci, et sinon ce sont les règles de routage propres à votre compte qui déterminent les répondants. - -### Détails du mappage de la sévérité - -Les sévérités correspondent au champ **Priority** des alertes Opsgenie, qui utilise l'échelle fixe d'Opsgenie allant de `P1` (critique) à `P5` (informatif) : - -- **Severity Field Name** : `Priority` -- **Info Mapping** : `P5` -- **Low Mapping** : `P4` -- **Medium Mapping** : `P3` -- **High Mapping** : `P2` -- **Critical Mapping** : `P1` - -Si une sévérité est mappée à une valeur non reconnue, la priorité est omise et Opsgenie applique sa propre valeur par défaut (`P3`). - -### Détails du mappage du statut - -Les alertes Opsgenie sont `open` ou `closed`, et une alerte ouverte peut en outre être `acknowledged` : - -- **Status Field Name** : `Status` -- **Active Mapping** : `open` -- **Closed Mapping** : `closed` -- **False Positive Mapping** : `closed` -- **Risk Accepted Mapping** : `acknowledged` - -Notez que `closed` est un statut final dans Opsgenie - une alerte fermée ne peut pas être rouverte, et son alias est libéré. Contrairement à certains autres outils, Opsgenie autorise les modifications de contenu après création ; ainsi, la transmission d'une Constatation mise à jour synchronise son message, sa description et sa priorité en plus du statut. - -DefectDojo définit l'**alias** de chaque alerte sur une clé stable dérivée de la Constatation ou du Groupe de constatations, et Opsgenie dé-duplique les alertes ouvertes par alias - ainsi, retransmettre la même Constatation met à jour l'alerte ouverte existante au lieu d'en créer une nouvelle. - -## PagerDuty - -L'intégration PagerDuty vous permet de transmettre les Constatations et Groupes de constatations de DefectDojo sous forme d'incidents PagerDuty, ouverts sur un service PagerDuty de votre choix. - -### Configuration de l'instance - -- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur `https://api.pagerduty.com`. Si votre compte PagerDuty est hébergé dans la région de service UE, utilisez plutôt `https://api.eu.pagerduty.com`. -- **API Token** doit être défini sur une clé API REST PagerDuty. Un administrateur de compte peut en créer une dans l'application web PagerDuty, sous **Integrations > API Access Keys > Create New API Key**. Laissez « Read-only » décoché - DefectDojo doit pouvoir créer et mettre à jour des incidents. -- **From Email** doit correspondre à l'adresse e-mail d'un utilisateur valide de votre compte PagerDuty. PagerDuty exige cette adresse lors de la création ou de la mise à jour d'incidents, et elle sera affichée comme demandeur de l'incident. - -### Mappage du suivi des tickets - -- **Service ID** doit correspondre à l'ID du service PagerDuty sur lequel les incidents seront ouverts. Vous pouvez le trouver à la fin de l'URL lorsque vous consultez le service dans PagerDuty, par exemple `https://{your-subdomain}.pagerduty.com/service-directory/{service id}`. - -### Détails du mappage de la sévérité - -Par défaut, ceci correspond au champ **Urgency** des incidents PagerDuty, qui n'accepte que `high` ou `low` : - -- **Severity Field Name** : `Urgency` -- **Info Mapping** : `low` -- **Low Mapping** : `low` -- **Medium Mapping** : `low` -- **High Mapping** : `high` -- **Critical Mapping** : `high` - -Alternativement, si votre compte PagerDuty a activé les [Priorities](https://support.pagerduty.com/main/docs/incident-priority), vous pouvez mapper les sévérités aux noms de priorité à la place. Définissez le **Severity Field Name** sur `Priority` et utilisez les noms de priorité de votre compte (par exemple de `P1` à `P5`) comme valeurs de mappage. Lors du mappage vers Priority, l'urgence de l'incident est laissée aux propres règles d'urgence de votre service. - -### Détails du mappage du statut - -Les incidents PagerDuty ont trois statuts : `triggered`, `acknowledged` et `resolved`. - -- **Status Field Name** : `Status` -- **Active Mapping** : `triggered` -- **Closed Mapping** : `resolved` -- **False Positive Mapping** : `resolved` -- **Risk Accepted Mapping** : `acknowledged` - -Notez que `resolved` est un statut final dans PagerDuty - un incident résolu ne peut pas être rouvert. Notez également que PagerDuty ne permet pas de modifier le titre ou la description d'un incident après sa création ; ainsi, la transmission d'une Constatation mise à jour synchronisera son statut, son urgence et sa priorité, mais pas les modifications de contenu. - -## ServiceNow - -L'intégration ServiceNow vous permet de pousser les Constatations DefectDojo sous forme d'Incidents ServiceNow. - -### Configuration de l'instance - -DefectDojo s'authentifie auprès de ServiceNow via OAuth 2.0. La façon dont vous créez les identifiants OAuth dépend de votre version de ServiceNow — les versions récentes (Zurich et ultérieures) utilisent un octroi Client Credentials, tandis que les versions antérieures utilisent un jeton d'actualisation (refresh token). - -#### ServiceNow Zurich et versions ultérieures (client credentials) - -Les versions récentes de ServiceNow ont déprécié l'option classique « Create an OAuth API endpoint for external clients » au profit de la **New Inbound Integration Experience**, qui délivre un octroi OAuth **Client Credentials** lié à un compte de service : - -1. Dans la barre de navigation de gauche, recherchez « Application Registry » et sélectionnez-le. -2. Cliquez sur **New**, puis choisissez **New Inbound Integration Experience**. -3. Sélectionnez **New Integration → OAuth - Client credentials grant**. -4. Définissez **OAuth Application User** sur le compte de service qui créera les Incidents. Les rôles de ce compte déterminent ce que DefectDojo est autorisé à écrire. -5. Enregistrez l'inscription. ServiceNow génère automatiquement le **Client ID** et le **Client Secret** (laissez ces champs vides lors de la création de l'inscription). - -Ensuite, dans DefectDojo : - -- **Instance Label** doit être l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur l'URL de votre serveur ServiceNow, par exemple `https://your-organization.service-now.com/`. -- **Client ID** doit être le Client ID provenant de l'inscription OAuth. -- **Client Secret** doit être le Client Secret provenant de l'inscription OAuth. - -Laissez vides les champs Refresh Token, Username et Password — DefectDojo demande un nouveau jeton client-credentials à chaque synchronisation. - -#### Versions antérieures de ServiceNow (jeton d'actualisation) - -Sur les versions qui proposent encore l'inscription classique, obtenez un Refresh Token associé au compte Utilisateur ou de Service qui poussera les Incidents vers ServiceNow : - -1. Dans la barre de navigation de gauche, recherchez « Application Registry » et sélectionnez-le. -2. Cliquez sur « New ». -3. Choisissez « Create an OAuth API endpoint for external clients ». -4. Renseignez les champs requis : - * Name : indiquez un nom explicite pour votre application (par exemple, Vulnerability Integration Client). - * (Facultatif) Ajustez la durée de vie du jeton : - * Access Token Lifespan : la valeur par défaut est 1800 secondes (30 minutes). - * Refresh Token Lifespan : la valeur par défaut est 8640000 secondes (environ 100 jours). -5. Cliquez sur Submit pour créer l'enregistrement de l'application. -6. Après l'envoi, sélectionnez l'application dans la liste et notez les champs **Client ID and Client Secret**. - -Vous devrez ensuite utiliser cette inscription pour obtenir un Refresh Token, qui ne peut être obtenu que via l'API ServiceNow. Ouvrez une fenêtre de terminal et collez ce qui suit (en remplaçant les variables entourées de `{{}}` par les informations réelles de votre utilisateur) - -``` -curl --request POST \ - --url {{INSTANCE_HOST}}/oauth_token.do \ - --header 'content-type: application/x-www-form-urlencoded' \ - --data grant_type=password \ - --data 'client_id={{CLIENT_ID}}' \ - --data 'client_secret={{CLIENT_SECRET}}' \ - --data 'username={{USERNAME}}' \ - --data 'password={{PASSWORD}}' - ``` - -Si vos identifiants ServiceNow sont corrects et permettent un accès de niveau administrateur à ServiceNow, vous devriez recevoir une réponse contenant un RefreshToken. Vous aurez besoin de ce jeton pour terminer l'intégration avec DefectDojo. - -- **Instance Label** doit être l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur l'URL de votre serveur ServiceNow, par exemple `https://your-organization.service-now.com/`. -- **Refresh Token** est l'endroit où le Refresh Token doit être saisi. -- **Client ID** doit être le Client ID défini dans l'OAuth App Registration. -- **Client Secret** doit être le Client Secret défini dans l'OAuth App Registration. - -### Détails de la correspondance des sévérités - -Ceci correspond au champ Impact de ServiceNow. -- **Info Mapping**: `1` -- **Low Mapping**: `1` -- **Medium Mapping**: `2` -- **High Mapping**: `3` -- **Critical Mapping**: `3` - -### Détails de la correspondance des statuts - -- **Status Field Name**: `State` -- **Active Mapping**: `New` -- **Closed Mapping**: `Closed` -- **False Positive Mapping**: `Resolved` -- **Risk Accepted Mapping**: `Resolved` - -Chaque correspondance accepte une étiquette d'état standard (`New`, `In Progress`, `On Hold`, `Resolved`, `Closed`, `Cancelled`) ou une valeur d'état numérique. Sur les instances dont les états d'Incident sont personnalisés — ou lorsque vous ciblez une table autre que `incident` — utilisez la **valeur d'état** numérique de la liste de choix de votre instance ; une valeur numérique en dehors de l'ensemble standard est envoyée à ServiceNow telle quelle. La valeur par défaut intégrée du code de résolution n'accompagne que les états résolu/fermé standard ; associez donc les valeurs d'état personnalisées aux correspondances de champs de clôture et de résolution ci-dessous. - -### Champs de clôture et de résolution - -Certaines instances ServiceNow appliquent une Data Policy qui rend obligatoires des champs tels que le **Resolution code** (`close_code`) dès qu'un Incident passe à un état résolu ou fermé. Si DefectDojo ferme un Incident sans ces champs, ServiceNow rejette l'écriture avec une erreur HTTP 403 *« Data Policy Exception »*, et la raison est enregistrée dans la vue Errors de l'intégration. - -Associez les champs requis au changement d'état avec **Custom Field Mappings**, en définissant **Apply On** sur la disposition qui doit les porter : - -- **Transition to Closed** — envoyé lorsqu'une Constatation est atténuée / fermée. -- **Transition to False Positive** — envoyé lorsqu'une Constatation est marquée comme faux positif. -- **Transition to Risk Accepted** — envoyé lorsqu'une Constatation fait l'objet d'une acceptation du risque. - -Par exemple, pour satisfaire un Resolution code obligatoire : - -| Source | Field Name | Value | Apply On | -|---|---|---|---| -| Static | `close_code` | `Resolved by DefectDojo` | Transition to Closed | -| Static | `close_notes` | `Reviewed by the security team` | Transition to Closed | -| Static | `close_code` | `Not a defect` | Transition to False Positive | - -Remarques : - -- Field Name est le nom de colonne ServiceNow — `close_code`, `close_notes`, ou un champ personnalisé `u_...`. -- Les correspondances de transition se déclenchent lorsque l'état de l'enregistrement change réellement : une Constatation déjà fermée lors de son premier envoi, une mise à jour qui ferme ou rouvre l'enregistrement, et la fermeture forcée lorsqu'un lien de ticket est supprimé. Elles ne sont pas renvoyées lors de mises à jour de routine d'un enregistrement inchangé ; les champs de journal tels que `work_notes` reçoivent donc une seule entrée par transition. -- Les champs de référence tels que `assignment_group` et `assigned_to` attendent un **sys_id**, et non un nom d'affichage. -- Les valeurs qui s'analysent comme du JSON sont envoyées typées : `true`, `42`, `[...]`, `{...}` — et `null`, qui efface le champ. Pour envoyer un tel texte comme chaîne littérale, entourez-le de guillemets doubles (par exemple `"null"`). -- `short_description`, `description`, `state`, `impact`, `urgency` et `priority` sont gérés par le modèle de description et par les correspondances de sévérité/statut ; ils ne peuvent donc pas être définis via une correspondance de champ personnalisée. -- Sur les tables autres que `incident`, les valeurs d'état qui correspondent à l'ensemble Incident standard (`1`, `2`, `3`, `6`, `7`, `8`) sont tout de même interprétées avec la sémantique Incident — y compris la valeur par défaut automatique du Resolution code sur `6`/`7`/`8`. Privilégiez des valeurs d'état en dehors de cette plage sur les tables personnalisées, ou fournissez explicitement les champs de clôture comme ci-dessus. - -## ServiceNow SecOps - -L'intégration ServiceNow SecOps (aussi appelée **ServiceNow SecOps / Vulnerability Response**) pousse les Constatations et Groupes de constatations DefectDojo vers une table de sécurité ServiceNow — un **Security Incident** (`sn_si_incident`) ou un **Vulnerable Item** (`sn_vul_vulnerable_item`) — et la maintient synchronisée à mesure que la Constatation évolue (création, mise à jour et résolution/fermeture). C'est l'équivalent côté opérations de sécurité de l'intégration ServiceNow de suivi des tickets ci-dessus ; utilisez ServiceNow SecOps lorsque vous exploitez les applications Security Incident Response (SIR) ou Vulnerability Response (VR). - -### Configuration de l'instance - -- **Instance Label** doit être l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur l'URL de votre serveur ServiceNow, par exemple `https://your-organization.service-now.com/`. - -ServiceNow SecOps prend en charge trois méthodes d'authentification ; fournissez-en **une seule** : - -- **OAuth 2.0** — saisissez un **Client ID**, un **Client Secret** et un **Refresh Token**. Obtenez-les exactement comme décrit dans la section [ServiceNow](#servicenow) ci-dessus (créez un point de terminaison API OAuth dans l'Application Registry, puis échangez vos identifiants sur `/oauth_token.do` contre un jeton d'actualisation). Vous pouvez aussi fournir le **Client ID** et le **Client Secret** avec un **Username** et un **Password** pour utiliser l'octroi OAuth par mot de passe au lieu d'un jeton d'actualisation. -- **API Key** — saisissez une **API Key**, envoyée dans l'en-tête `x-sn-apikey`. La clé n'authentifie rien tant qu'un Inbound Authentication Profile et une REST API Access Policy ne lui sont pas associés sur l'instance. -- **HTTP Basic** — saisissez le **Username** et le **Password** du compte de service. - -Le compte de service (ou le client OAuth) doit disposer d'un accès en écriture à la table cible. - -### Correspondance du suivi des tickets - -- **Target Table** sélectionne la table ServiceNow dans laquelle les enregistrements sont écrits : **Security Incident** (`sn_si_incident`, valeur par défaut) ou **Vulnerable Item** (`sn_vul_vulnerable_item`). - -### Détails de la correspondance des sévérités - -Pour un Security Incident, ceci correspond au champ **Impact** ; ServiceNow dérive la Priority de l'incident à partir de l'Impact et de l'Urgency, si bien que l'Urgency reflète l'Impact mappé à moins que vous ne la mappiez vous-même. Pour un Vulnerable Item, associez la sévérité au champ de risque utilisé par votre instance. Les valeurs par défaut ci-dessous correspondent à l'échelle Impact SIR standard (`1` High, `2` Medium, `3` Low) et sont modifiables. - -- **Severity Field Name**: `impact` -- **Info Mapping**: `3` -- **Low Mapping**: `3` -- **Medium Mapping**: `2` -- **High Mapping**: `1` -- **Critical Mapping**: `1` - -### Détails de la correspondance des statuts - -Ceci correspond au champ **State** de l'enregistrement. Les valeurs d'état sont des codes numériques qui diffèrent entre les tables Security Incident et Vulnerable Item et peuvent être personnalisées par instance ; vérifiez-les donc par rapport à votre propre configuration. Les valeurs par défaut ci-dessous utilisent les codes d'état SIR standard (`16` Analysis, `3` Closed). - -- **Status Field Name**: `state` -- **Active Mapping**: `16` -- **Closed Mapping**: `3` -- **False Positive Mapping**: `3` -- **Risk Accepted Mapping**: `3` - -Lorsqu'un enregistrement est fermé, DefectDojo définit également le **Close Code** et les **Close Notes** ServiceNow (`Resolved` pour les Constatations fermées, `False positive` et `Risk accepted` pour les états correspondants). - -### Comportements spécifiques à ServiceNow SecOps - -- **Deduplication** — chaque enregistrement est marqué avec l'identifiant DefectDojo de la Constatation ou du Groupe de constatations dans son `correlation_id`. Avant de créer un enregistrement, DefectDojo en recherche un par `correlation_id` ; une correspondance est reprise et mise à jour plutôt que dupliquée, ce qui rend les resynchronisations idempotentes. -- **Updates** sont publiées dans le journal **Work notes** de l'enregistrement (interne), jamais dans les Comments visibles par le client. -- **Resolve on delete** — la suppression d'une Constatation dans DefectDojo résout/ferme l'enregistrement ServiceNow (State + Close Code) plutôt que de le supprimer ; les enregistrements ne sont jamais supprimés définitivement. -- **Reference fields** — les valeurs facultatives `cmdb_ci`, `assignment_group` et `assigned_to` peuvent être fournies sous forme de noms d'affichage ; DefectDojo résout chacune vers son `sys_id`. Un nom qui ne se résout pas est ignoré avec un avertissement plutôt que de faire échouer l'envoi. - -## Shortcut - -L'intégration Shortcut vous permet de pousser les Constatations DefectDojo sous forme de Stories [Shortcut](https://www.shortcut.com/). Les Stories sont créées avec le type Bug et affectées à une Team de votre espace de travail Shortcut. - -### Configuration de l'instance - -- **Label** doit être l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur `https://api.app.shortcut.com`. -- **API Token** doit être un jeton API Shortcut. Les jetons peuvent être générés dans Shortcut sous Settings, puis Your Account, puis [API Tokens](https://app.shortcut.com/settings/account/api-tokens). - -### Correspondance du suivi des tickets - -- **Team (Group) ID** doit être défini sur l'UUID de la Team Shortcut pour laquelle les Stories seront créées. Vous pouvez trouver cet UUID en ouvrant la page Team dans Shortcut et en copiant l'identifiant depuis l'URL, ou en appelant l'API Shortcut : - -``` -curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/groups -``` - -### Détails de la correspondance des sévérités - -Chaque valeur de sévérité est appliquée à la Story sous forme de label. Les labels sont créés automatiquement dans Shortcut s'ils n'existent pas déjà ; les valeurs par défaut ci-dessous peuvent donc être utilisées telles quelles, ou remplacées par des noms de label de votre choix. Lorsque la sévérité d'une Constatation change, l'ancien label de sévérité est retiré de la Story et le nouveau est ajouté. - -- **Severity Field Name**: `Label` -- **Info Mapping**: `sev-info` -- **Low Mapping**: `sev-low` -- **Medium Mapping**: `sev-medium` -- **High Mapping**: `sev-high` -- **Critical Mapping**: `sev-critical` - -### Détails de la correspondance des statuts - -Chaque valeur de statut doit être définie sur l'ID numérique d'un Workflow State dans votre espace de travail Shortcut. Les ID de Workflow State sont propres à chaque espace de travail ; il n'y a donc pas de valeurs par défaut. Vous pouvez lister les Workflow States et leurs ID en appelant l'API Shortcut : - -``` -curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/workflows -``` - -- **Status Field Name**: `Workflow State ID` -- **Active Mapping** : l'ID de l'état pour le travail ouvert, par exemple un état Backlog ou To Do. -- **Closed Mapping** : l'ID d'un état de type Done. Lorsqu'une Constatation est supprimée dans DefectDojo, sa Story est déplacée vers cet état. -- **False Positive Mapping** : l'ID de l'état à utiliser pour les Constatations Faux positif. -- **Risk Accepted Mapping** : l'ID de l'état à utiliser pour les Constatations Risque accepté. - -## Freshservice - -L'intégration Freshservice vous permet de pousser les Constatations et Groupes de constatations DefectDojo sous forme de tickets Freshservice, affectés à un Group d'agents de votre choix. - -### Configuration de l'instance - -- **Label** doit être l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur votre URL Freshservice : `https://yourcompany.freshservice.com`. -- **API Key** doit être une clé API Freshservice. Trouvez-la en cliquant sur votre photo de profil (en haut à droite) > **Profile settings** - la clé apparaît à droite, sous la section **Delegate Approvals**, une fois le captcha complété. Si aucune clé n'y est affichée, l'accès API est peut-être désactivé au niveau du compte et un administrateur doit d'abord l'activer. -- **Requester Email** doit être l'adresse e-mail au nom de laquelle les tickets sont demandés. Freshservice exige un requester sur chaque ticket ; DefectDojo crée donc les tickets avec cette adresse comme requester. - -### Correspondance du suivi des tickets - -- **Group ID** doit être l'ID numérique du groupe d'agents Freshservice auquel les tickets seront affectés. Trouvez-le dans l'URL en consultant le groupe sous **Admin > Agent Groups**. -- **Workspace ID** (facultatif) achemine les tickets vers un espace de travail spécifique sur les comptes multi-espaces. Laissez-le vide pour utiliser l'espace de travail principal. - -### Détails de la correspondance des sévérités - -Ceci correspond au champ **Priority** du ticket Freshservice, qui utilise des codes numériques (`1` Low, `2` Medium, `3` High, `4` Urgent). Les noms de priorité sont également acceptés : - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `1` -- **Low Mapping**: `1` -- **Medium Mapping**: `2` -- **High Mapping**: `3` -- **Critical Mapping**: `4` - -### Détails de la correspondance des statuts - -Ceci correspond au champ **Status** du ticket, qui utilise des codes numériques (`2` Open, `3` Pending, `4` Resolved, `5` Closed). Les noms de statut sont également acceptés : - -- **Status Field Name**: `Status` -- **Active Mapping**: `2` -- **Closed Mapping**: `5` -- **False Positive Mapping**: `5` -- **Risk Accepted Mapping**: `3` - -Quelques comportements spécifiques à Freshservice à connaître : - -- Les mises à jour synchronisent l'intégralité du contenu du ticket - Freshservice permet de modifier l'objet et la description après la création. -- Les tickets sont fermés plutôt que supprimés lorsqu'une Constatation est retirée ; les tickets déjà Resolved ou Closed restent inchangés. Une note de résolution est jointe automatiquement à la fermeture, de sorte que les comptes qui en exigent une (une règle métier courante) acceptent la fermeture. -- Certains comptes calculent la priorité d'un ticket à partir d'une matrice Impact/Urgency ou d'une règle métier, et ignorent la priorité envoyée à la création. DefectDojo détecte ce cas et réapplique la priorité mappée via une mise à jour de suivi, de sorte que la correspondance finit tout de même par s'appliquer. - -## ServiceDesk Plus - -L'intégration ManageEngine ServiceDesk Plus vous permet de pousser les Constatations et Groupes de constatations DefectDojo sous forme de requests ServiceDesk Plus, affectées à un Group de support de votre choix. Les éditions **cloud** (ServiceDesk Plus OnDemand) et **on-premises** sont toutes deux prises en charge par la même intégration - les identifiants que vous fournissez déterminent le mode utilisé. - -### Configuration de l'instance - -- **Label** doit être l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur votre URL ServiceDesk Plus : `https://sdpondemand.manageengine.com` pour l'édition cloud (ou son équivalent régional), ou l'adresse de votre serveur pour les installations on-premises. - -Fournissez ensuite **un seul** des deux jeux d'identifiants : - -#### On-premises : Technician Key - -- **Technician Key** doit être une clé API générée pour un technicien sur votre serveur, sous **Admin > General Settings > API**. Laissez vides les champs Zoho OAuth. - -#### Cloud : Zoho OAuth - -L'édition cloud s'authentifie via Zoho Accounts OAuth : - -1. Ouvrez la [Zoho API Console](https://api-console.zoho.com/) et créez un **Self Client**. -2. Notez le **Client ID** et le **Client Secret**. -3. Dans l'onglet « Generate Code » du Self Client, saisissez le scope `SDPOnDemand.requests.ALL`, choisissez une durée, puis générez le code. -4. Échangez le code contre un jeton d'actualisation : - -``` -curl --request POST \ - --url 'https://accounts.zoho.com/oauth/v2/token' \ - --data 'grant_type=authorization_code' \ - --data 'client_id={{CLIENT_ID}}' \ - --data 'client_secret={{CLIENT_SECRET}}' \ - --data 'code={{GENERATED_CODE}}' -``` - -5. Saisissez le **Client ID**, le **Client Secret** et le **Refresh Token** renvoyé dans le formulaire de l'instance. Si votre compte est hébergé en dehors du centre de données US, définissez **Token URL** sur le point de terminaison Zoho Accounts régional (par exemple `https://accounts.zoho.eu/oauth/v2/token`). - -### Correspondance du suivi des tickets - -- **Group Name** doit être le nom du groupe de support ServiceDesk Plus auquel les requests seront affectées, exactement comme il apparaît sous **Admin > Users > Support Groups**. - -### Détails de la correspondance des sévérités - -Ceci correspond, par nom, au champ **Priority** de la request ServiceDesk Plus, en utilisant les noms de priorité de votre compte : - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `Low` -- **Low Mapping**: `Normal` -- **Medium Mapping**: `Medium` -- **High Mapping**: `High` -- **Critical Mapping**: `High` - -### Détails de la correspondance des statuts - -Ceci correspond, par nom, au champ **Status** de la request. Les valeurs par défaut utilisent les statuts intégrés : - -- **Status Field Name**: `Status` -- **Active Mapping**: `Open` -- **Closed Mapping**: `Closed` -- **False Positive Mapping**: `Closed` -- **Risk Accepted Mapping**: `On Hold` - -Quelques comportements spécifiques à ServiceDesk Plus à connaître : - -- Les mises à jour synchronisent l'intégralité du contenu de la request - contrairement à la plupart des outils de suivi, ServiceDesk Plus permet de modifier l'objet et la description après la création. -- Les requests sont fermées plutôt que supprimées lorsqu'une Constatation est retirée ; les requests déjà Closed ou Resolved restent inchangées. -- Si votre compte rend certains champs obligatoires à la clôture (par exemple une résolution), une fermeture envoyée depuis DefectDojo peut être rejetée par ces règles et apparaîtra dans la table Integration errors. - -## Zendesk - -L'intégration Zendesk vous permet de pousser les Constatations et Groupes de constatations DefectDojo sous forme de tickets Zendesk, affectés à un Group Zendesk de votre choix. - -### Configuration de l'instance - -- **Label** doit être l'étiquette que vous souhaitez utiliser pour identifier cette intégration. -- **Location** doit être définie sur l'URL de votre compte Zendesk, par exemple `https://your-subdomain.zendesk.com`. -- **Email** doit être l'adresse e-mail de l'agent Zendesk auquel appartient le jeton API. -- **API Token** doit être un jeton API Zendesk. Un administrateur peut en créer un dans le Zendesk Admin Center sous **Apps and integrations > APIs > Zendesk API** (l'accès par jeton doit être activé). - -### Correspondance du suivi des tickets - -- **Group ID** doit être l'ID numérique du Group Zendesk auquel les tickets seront affectés. Vous pouvez le trouver dans l'Admin Center sous **People > Team > Groups**, ou dans l'URL en consultant le groupe. - -### Détails de la correspondance des sévérités - -Ceci correspond au champ **Priority** du ticket Zendesk, qui accepte `low`, `normal`, `high` et `urgent` : - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `low` -- **Low Mapping**: `low` -- **Medium Mapping**: `normal` -- **High Mapping**: `high` -- **Critical Mapping**: `urgent` - -### Détails de la correspondance des statuts - -Les tickets Zendesk prennent en charge les statuts `new`, `open`, `pending`, `hold`, `solved` et `closed`. Notez que `hold` doit être activé sur votre compte avant de pouvoir être utilisé. - -- **Status Field Name**: `Status` -- **Active Mapping**: `new` -- **Closed Mapping**: `solved` -- **False Positive Mapping**: `solved` -- **Risk Accepted Mapping**: `pending` - -Quelques comportements spécifiques à Zendesk à connaître : - -- La description du ticket est le premier commentaire dans Zendesk et ne peut pas être modifiée après la création ; l'envoi d'une Constatation mise à jour synchronisera donc l'objet, la priorité et le statut du ticket, mais pas les modifications de la description. -- Les tickets sont marqués `solved` plutôt que supprimés lorsqu'une Constatation est retirée ; Zendesk ferme automatiquement les tickets solved au bout d'un certain temps. -- `closed` est un statut final - les tickets closed ne peuvent plus du tout être mis à jour, et l'envoi d'une Constatation dont le ticket est fermé génèrera une erreur. diff --git a/docs/content/connectors/downstream/downstream_toolreference.ja.md b/docs/content/connectors/downstream/downstream_toolreference.ja.md deleted file mode 100644 index 2c6fcb697e9..00000000000 --- a/docs/content/connectors/downstream/downstream_toolreference.ja.md +++ /dev/null @@ -1,766 +0,0 @@ ---- -title: ダウンストリームコネクタ ツールリファレンス -description: ダウンストリームコネクタの詳細なセットアップガイド -weight: 1 -audience: pro -aliases: -- /ja/en/share_your_findings/integrations_toolreference -- /ja/issue_tracking/pro_integration/integrations_toolreference/ ---- - -DefectDojo のダウンストリームコネクタをサードパーティの Issue トラッカーと連携させるための、具体的な設定手順を以下に示します。 - -## Azure DevOps Boards - -### Instance Setup - -- **Label** は、この統合を識別するために使用したいラベルを設定します。 -- **Location** は、Azure の URL を設定します。例: `https://dev.azure.com/{your organization}` -- **Token** は、Azure のパーソナルアクセストークンを設定します。 - -Azure DevOps での認証には、作業対象の Azure プロジェクトの「Work Items」に対して「Read, Write and Manage」権限を持つ[パーソナルアクセストークン](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows)が必要です。 - -### Issue Tracker Mapping - -これらの項目は、DefectDojo が Finding または Finding Group の属性を Azure DevOps の該当プロジェクトにどのようにマッピングするかを指定します。 - -#### Issue Tracker Mapping Details - -`Project ID` フィールドには、Azure における対象プロジェクトの名前または ID を指定します。 - -#### Severity Mapping Details - -フォームの各項目にはデフォルト値が設定されており、内容は以下のとおりです。 - -- **Severity Field Name**: `/fields/Microsoft.VSTS.Common.Priority` -- **Info Mapping**: `4` -- **Low Mapping**: `4` -- **Medium Mapping**: `3` -- **High Mapping**: `2` -- **Critical Mapping**: `1` - -#### Status Mapping Details - -フォームの各項目にはデフォルト値が設定されており、内容は以下のとおりです。 - -- **Status Field Name**: `/fields/System.State` -- **Active Mapping**: `To Do` -- **Closed Mapping**: `Done` -- **False Positive Mapping**: `Done` -- **Risk Accepted Mapping**: `Done` - -## Bitbucket - -Bitbucket 統合を使うと、Bitbucket Cloud リポジトリの[Issue トラッカー](https://support.atlassian.com/bitbucket-cloud/docs/enable-an-issue-tracker/)に Issue をプッシュできます。 - -Bitbucket では Issue トラッカーはオプション機能であり、DefectDojo が Issue を作成できるようにするには、事前にリポジトリ側で有効にしておく必要があります。有効にするには、Bitbucket でリポジトリを開き、**Repository settings** を選択したうえで、**Features** の下で Issue トラッカーを有効にします。 - -### Instance Setup - -- **Label** は、この統合を識別するために使用したいラベルを設定します。 -- **Location** は、`https://bitbucket.org` を設定します。 -- **Email** は、API トークンの発行元となる Atlassian アカウントのメールアドレスを設定します。 -- **API Token** は、スコープ付きの Atlassian API トークンを設定します。 - -Bitbucket のアプリパスワードは Atlassian によって非推奨とされており、この統合では使用できません。API トークンを作成する手順は以下のとおりです。 - -1. [Atlassian アカウント設定](https://id.atlassian.com/manage-profile/security/api-tokens)を開き、**Security** を選択したうえで、**Create and manage API tokens** を選択します。 -2. **Create API token with scopes** を選択し、トークンに名前を付けて有効期限を設定します。 -3. アプリとして **Bitbucket** を選択します。 -4. リポジトリの読み取り権限、および Issue の読み取り・書き込み権限をトークンに付与します。 - -### Issue Tracker Mapping - -- **Workspace** は、リポジトリを含むワークスペースのスラッグを設定します。bitbucket.org の URL に表示される値です。 -- **Repository Slug** は、Issue を作成したいリポジトリのスラッグを設定します。 - -### Severity Mapping Details - -これは Bitbucket の Issue の Priority フィールドにマッピングされます。フォームの各項目にはデフォルト値が設定されており、各値は Bitbucket の優先度である `trivial`、`minor`、`major`、`critical`、`blocker` のいずれかである必要があります。 - -- **Severity Field Name**: `priority` -- **Info Mapping**: `trivial` -- **Low Mapping**: `minor` -- **Medium Mapping**: `major` -- **High Mapping**: `critical` -- **Critical Mapping**: `blocker` - -### Status Mapping Details - -これは Bitbucket の Issue の State フィールドにマッピングされます。各値は Bitbucket の Issue ステータスである `new`、`open`、`resolved`、`on hold`、`invalid`、`duplicate`、`wontfix`、`closed` のいずれかである必要があります。 - -- **Status Field Name**: `state` -- **Active Mapping**: `new` -- **Closed Mapping**: `resolved` -- **False Positive Mapping**: `invalid` -- **Risk Accepted Mapping**: `wontfix` - -## GitHub - -GitHub 統合を使うと、[GitHub Project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects)に Issue を追加でき、これにより関連付けられた Repo にも Issue が作成されます。これらの Repo/Project は、GitHub Organization または個人の GitHub アカウントのいずれにも関連付けることができます。 - -### Instance Setup - -- **Label** は、この統合を識別するために使用したいラベルを設定します。 -- **Location** は、Issue を作成したい場所に応じて、GitHub のユーザーまたは Organization の URL を設定します。例: `https://github.com/{your-organization}` -- **Token** は、GitHub のパーソナルアクセストークンを設定します。 - -GitHub のパーソナルアクセストークンは https://github.com/settings/tokens で作成できます。トークンには Repo と Project のスコープが必要です。 - -### Issue Tracker Mapping - -- **Issue Tracker Mapping Label** は、Issue を作成したい Project または Repo を識別できるように設定します。 -- **Project Number** は、Issue を送信したい GitHub Project の ID を設定します。この値は、Project を表示中の URL から取得できます。例: `https://github.com/orgs/{your-org}/projects/{project number}` -- **Repository Name** は、Issue をプッシュしたい、Organization（またはユーザー）に紐づくリポジトリの名前を設定します。 - - -### Severity Mapping Details - -**この統合を設定するには、Project 側で Issue の優先度を表すカスタムフィールドを作成しておく必要があります。作成していない場合、深刻度が正しくマッピングされず、Issue が GitHub にプッシュされません。** - -以下のガイドに従って[カスタムフィールド](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/quickstart-for-projects#creating-a-field-to-track-priority)を作成してください。 -各深刻度には、対応する単一選択のオプションを用意する必要があります。例えば、DefectDojo は初期状態で Priority の値として P0、P1、P2、P3、P4 を提案しており、それぞれを Priority カスタムフィールドに追加する必要があります。 - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `P0` -- **Low Mapping**: `P1` -- **Medium Mapping**: `P2` -- **High Mapping**: `P3` -- **Critical Mapping**: `P4` - -### Status Mapping Details - -デフォルトでは、新規作成した GitHub Project には Issue のステータスとして「In Progress」と「Done」が用意されています。誤検知やリスク受容済みのステータスを追跡したい場合は、Project に追加のステータスを設定することもできます。その方法の一つが、Project Board に新しいステータス列を追加する方法です。 - -- **Status Field Name**: `Status` -- **Active Mapping**: `In Progress` -- **Closed Mapping**: `Done` -- **False Positive Mapping**: `Done` -- **Risk Accepted Mapping**: `Done` - -## GitLab - -GitLab 統合を使うと、[GitLab Project](https://docs.gitlab.com/ee/user/project/)に Issue を追加できます。 - -### Instance Setup - -- **Label** は、この統合を識別するために使用したいラベルを設定します。 -- **Location** は、GitLab サーバーへのリンクを設定します。例: `https://gitlab.com/` -- **Token** は、GitLab のパーソナルアクセストークンを設定します。トークンには API スコープが必要です。詳細は[GitLab のパーソナルアクセストークン作成ガイド](https://docs.gitlab.com/user/profile/personal_access_tokens/#create-a-personal-access-token)を参照してください。 - -### Issue Tracker Mapping - -- **Project Name**: Issue を送信したい GitLab のプロジェクト名です。 - -### Severity Mapping Details - -これは GitLab の Priority フィールドにマッピングされます。 -- **Severity Field Name**: `Priority` -- **Info Mapping**: `1` -- **Low Mapping**: `2` -- **Medium Mapping**: `3` -- **High Mapping**: `4` -- **Critical Mapping**: `5` - -### Status Mapping Details - -GitLab には、デフォルトで「opened」と「closed」というステータスがあります。誤検知やリスク受容済みのステータスを追跡したい場合は、追加のステータスラベルを設定できます。詳細は[GitLab のドキュメント](https://docs.gitlab.com/user/work_items/status/)を参照してください。 - -- **Status Field Name**: `Status` -- **Active Mapping**: `opened` -- **Closed Mapping**: `closed` -- **False Positive Mapping**: `closed` -- **Risk Accepted Mapping**: `closed` - -## Jira - -Jira 統合は、DefectDojo の Finding および Finding Group を Jira プロジェクトに Issue としてプッシュし、各 Issue のステータスを Finding と同期し続け、その Finding を作成された Issue にリンクします。Jira **Cloud** と **Data Center / Server** の両方に対応しています。Jira Service Management には対応していません。 - -### Choosing an authentication method - -まず **Jira Deployment** を設定し、続いて **Authentication Method** を選択します。 - -**Jira Cloud** -- **API Token（メールアドレス + トークン）** — Atlassian アカウントのメールアドレスと[API トークン](https://id.atlassian.com/manage-profile/security/api-tokens)を使った HTTP Basic 認証です。呼び出しはサイト URL に対して直接行われます。 -- **OAuth 2.0（推奨）** — ブラウザでの同意操作を一度行うだけで、以降 DefectDojo がトークンの取得と更新を代行します。 -- **Service Account Token** — Atlassian の[サービスアカウント](https://support.atlassian.com/user-management/docs/manage-api-tokens-for-service-accounts/)向けに発行された、スコープ付きの API トークンです。 - -**Jira Data Center / Server** -- **Personal Access Token（推奨）** -- **Username + Password** - -> **Cloud 認証が Jira に到達する仕組み:** OAuth 2.0 と Service Account はいずれも、Atlassian のゲートウェイ — `https://api.atlassian.com/ex/jira/{cloudId}` — に対して Bearer トークンで認証します。これは、あなたの `https://your-site.atlassian.net` というサイト URL とは*別のホスト*です。DefectDojo は API 呼び出しには常にこのゲートウェイを使用しますが、Finding に表示するチケットリンクは常に**サイト URL**から生成するため、ユーザーがクリックするリンクは通常どおりブラウザで開ける `.../browse/{ISSUE-KEY}` 形式のリンクになります。（API Token と Data Center の認証はサイト URL を直接呼び出すため、このような分岐はありません。） - -### Instance Setup - -- **Label** は、この統合を識別するために使用したいラベルを設定します。 -- **Location** は、Jira の**サイト URL**を設定します。例: `https://your-organization.atlassian.net`。この値はブラウザで開けるチケットリンクに使用され、API Token 認証と Data Center 認証では API のベース URL としても使用されます。 -- 残りの項目は、上で選択した認証方法（メールアドレス + API トークン、OAuth クライアント資格情報、サービスアカウントトークン、PAT、またはユーザー名 + パスワード）によって異なります。 - -### OAuth 2.0 setup (Cloud) - -[Atlassian developer console](https://developer.atlassian.com/console/myapps/)で専用のアプリを作成し、DefectDojo から接続します。 - -1. **Create → OAuth 2.0 integration** を選択します。*OAuth 2.0 integration* である必要があります。Connect アプリや Forge アプリでは 3LO 認可コードグラントを使用できません（使用しようとすると `grant_type is not enabled for client` というエラーになります）。 -2. **Access type** の入力を求められたら **Resource-level** を選択します。これにより、トークンのスコープはユーザーが認可した単一の Jira サイトに限定されます。これは、1つの DefectDojo 接続が対象とする範囲とちょうど一致します。（**Account-level** を選択すると、その Atlassian アカウントに属するすべてのサイトへのアクセスが許可されてしまい、必要以上に広い範囲になります。） -3. **Permissions** の下で **Jira platform REST API** を追加し、以下に挙げるスコープを付与します。なお `offline_access` はこの画面には表示されません。これは DefectDojo が認可 URL 内でリクエストする標準の OAuth スコープであり、この画面で追加するものではありません。 -4. **Authorization** の下で、**OAuth 2.0 (3LO)** の横にある **Configure** をクリックし、**Callback URL** を `https:///integrators/jira/oauth/callback` に設定します。この値は DefectDojo のサイト URL と完全に一致している必要があります。これを有効にすることで、認可コードグラントとリフレッシュトークンが使用できるようになります。これを省略すると、`grant_type is not enabled` や `Client is not allowed to use offline_access` といったエラーが発生します。 -5. **Client ID** と **Client Secret** をコピーして DefectDojo のフォームに入力し、**Submit** をクリックして接続を保存します。 -6. **Connect with Jira** をクリックし、同意画面で承認します。Atlassian は DefectDojo にリダイレクトし、DefectDojo がトークンを保存して `cloudId` を自動的に解決します。成功すると「Connected」という表示が現れます。 - -> コールバックのホストは、あなたの DefectDojo の `SITE_URL` です。Atlassian はブラウザをそこにリダイレクトできる必要があり、その値は DefectDojo が送信する値と完全に一致していなければなりません。そのため、社内ネットワークからしか到達できない値ではなく、ユーザーが実際に DefectDojo にアクセスする際に使う正しいホスト名を使用してください。 - -#### Minimum OAuth scopes - -DefectDojo はデフォルトで以下の4つのクラシックスコープをリクエストします。これらは同時に**必要最小限**のスコープでもあり、それぞれが特定の動作を支えています。 - -| Scope | Required for | -|-------|--------------| -| `read:jira-work` | プロジェクト、Issue、利用可能な遷移の読み取り（接続の検証やステータス同期に使用）。 | -| `write:jira-work` | Issue の作成・編集、およびステータス遷移の実行。 | -| `read:jira-user` | 接続時の本人確認 — DefectDojo はアクセス権の検証時に `/myself` を呼び出します。 | -| `offline_access` | **リフレッシュトークン**の発行。これがないと、接続後およそ1時間でアクセストークンが失効し、DefectDojo がそれを更新できなくなるため、接続が機能しなくなります。 | - -Atlassian はグラニュラースコープよりもクラシックスコープの使用を推奨しており、上記の4つでアプリの権限範囲を最小限に保ちつつ、この統合が行うすべての処理をカバーできます。 - -##### Granular scope alternative - -組織の方針でクラシックスコープではなく**グラニュラー**スコープが必要な場合、最小限必要となる同等のスコープセットは以下のとおりです。 - -| Granular scope | Required for | -|----------------|--------------| -| `read:user:jira` | `/myself` による本人確認。 | -| `read:project:jira` | 対象プロジェクトが存在することの検証。 | -| `read:issue:jira` | 同期時に Issue の現在のステータスを読み取る。 | -| `write:issue:jira` | Issue の作成・編集、**およびステータス遷移の実行** — 遷移専用の書き込みスコープは存在せず、遷移も Issue に対する書き込みの一種として扱われます。 | -| `read:issue.transition:jira` | Issue で利用可能な遷移の一覧を取得する。 | -| `offline_access` | リフレッシュトークン（クラシックスコープと同様）。 | - -サイトのフィールド設定によっては、フィールドを展開するために付随する読み取りスコープが追加で必要になる場合があります。最も多いのは `read:status:jira` と `read:field:jira`（作成時にはさらに `read:issue-meta:jira`）です。プッシュが `403`「scope does not match」エラーで失敗した場合は、エラーメッセージに示されている正確なスコープを追加してください。このような付随スコープの広がりこそが、クラシックスコープが推奨される理由です。 - -**Service Account Token** 方式の場合は、トークンに `read:jira-work` と `write:jira-work`（および `read:jira-user`）を付与してください。あるいは、`offline_access` を除いた上記のグラニュラー相当のスコープでも構いません。サービスアカウントトークンは長期間有効で DefectDojo によって更新されることがないため、`offline_access` は適用されません。 - -### Issue Tracker Mapping - -- **Project Key**: Issue を作成する Jira プロジェクトのキーです。例: `SEC` -- **Issue Type**: 作成する Issue の種類です。例: `Bug` や `Task`。デフォルトは `Bug` です。 - -### Severity Mapping Details - -デフォルト値は Jira のデフォルトの優先度スキームに一致しています。プロジェクトの優先度名に合わせて編集してください。 - -- **Severity Field Name**: `priority` -- **Info Mapping**: `Lowest` -- **Low Mapping**: `Low` -- **Medium Mapping**: `Medium` -- **High Mapping**: `High` -- **Critical Mapping**: `Highest` - -### Status Mapping Details - -ステータスはプロジェクトのワークフローごとに異なるため、これらのデフォルト値は**あなたの**ワークフローのステータス名に合わせて編集することを前提としています。 - -- **Status Field Name**: `status` -- **Active Mapping**: `To Do` -- **Closed Mapping**: `Done` -- **False Positive Mapping**: `Done` -- **Risk Accepted Mapping**: `Done` - -### Custom Fields (optional) - -マッピングの **Custom Fields** ステップで、追加の Jira フィールド — 例えばクローズ時に必須となる `resolution` や `labels` など — をマッピングできます。カスタムフィールドのマッピングはそれぞれ4つの要素で構成されます。 - -- **Source** — 値の取得元です。プッシュされる **Finding**、**Test**、**Engagement**、**Asset** のいずれかの属性、または **Static value** です。 -- **Value** — オブジェクトを Source に選んだ場合、読み取る具体的な属性を、そのオブジェクトが持つフィールドの一覧（例えば *Severity*、*CVE*、*Mitigation* のような分かりやすいラベル付き）から選択します。Source が **Static value** の場合は、リテラル値を直接入力するフリーテキストのボックスになります。 -- **Vendor Field** — 書き込み先となる Jira のフィールドです。DefectDojo は Jira のフィールドカタログを読み取れるため、これは各フィールドを**表示名**で一覧表示し、内部 ID に自動的に解決してくれる検索可能なピッカーになっています。そのため、*DD Close Justification* を選択するだけで、DefectDojo は内部的に `customfield_10255` を保存します。このピッカーは接続情報から値を取得するため、接続を保存して検証済みになった後に使用できます。 -- **Application point** — フィールドを送信する*タイミング*です。**ticket creation**（チケット作成時）、**every update**（更新のたびに）、または特定のステータス **transition**（Active / Closed / False Positive / Risk Accepted）の一部として送信するかを選べます。遷移スコープのフィールドは、その遷移の編集内容の一部として送信されます。これは、Jira が遷移画面でのみ受け付ける値 — 多くの場合、Issue を解決する際にワークフローが要求する `resolution` — を渡すための方法です。 - -### Ticket Templates (optional) - -デフォルトでは、Jira の Issue は DefectDojo 組み込みのタイトルと本文を使用します。これをカスタマイズするには、マッピングの **Ticket Template** ステップで**チケットテンプレート**を割り当てます。テンプレートは、**Finding** のサマリーと説明、および **Finding Group** のサマリーと説明という、それぞれ独立して省略可能な4つの要素を定義します。空欄のままにした要素は組み込みのデフォルトにフォールバックするため、タイトルだけ、本文だけ、あるいは4つすべてを上書きすることができます。保存する前に、テンプレートエディタの **Test render** を使ってサンプルデータに対するレンダリング結果をプレビューし、未知のプレースホルダーやフィールドの文字数制限を超える値といったミスを事前に発見できます。テンプレートが後で削除された場合、それを使用していたマッピングは自動的に組み込みのデフォルトに戻ります。 - -### How it works - -- **Create / Update / Delete:** 作成時には新しい Issue がプッシュされ、そのリンクが Finding に記録されます。更新時には既存の Issue が編集されます。Finding を削除すると、対応する Issue は強制的にクローズされます（Jira 側で何かが削除されるわけではありません）。プッシュは手動（「Push to Integrator」）でも、Issue Tracker Assignment の設定に従って自動でも行えます。 -- **Status reconciliation:** 作成後（および更新のたび）、DefectDojo は Issue の現在のステータスを読み取り、マッピング先のステータスと異なる場合は、そこに到達できる単一のワークフロー遷移を探して適用します。該当する遷移が存在しない場合、マッピングはサイレントに失敗するのではなくエラーを記録します。遷移スコープのカスタムフィールドがあれば、その遷移と一緒に送信されます。 -- **Ticket link:** Finding に表示されるリンクは `https://your-site.atlassian.net/browse/{ISSUE-KEY}` の形式で、常にあなたの公開サイト URL であり、内部ゲートウェイではありません。 -- **Token lifecycle (OAuth):** DefectDojo がフロー全体を管理します。認可コードの交換を行い、アクセストークンとリフレッシュトークンを保存し、プッシュの前に必要に応じてトークンを更新し、更新のたびに新しいリフレッシュトークンを保存します（Atlassian は更新のたびにリフレッシュトークンをローテーションします）。 -- **Credential storage:** 接続に関するすべての認証情報（パスワード、トークン、クライアントシークレット、OAuth トークン）は保存時に暗号化され、API を通じて返却されることはありません。接続を編集する際、保存済みのシークレットには「leave blank to keep」（空欄のままにすると現在の値を維持）というプレースホルダーが表示されます。 - -## Linear - -Linear 統合を使うと、DefectDojo の Finding を[Linear](https://linear.app/)の Issue としてプッシュできます。Issue は Linear ワークスペース内の Team に作成されます。 - -### Instance Setup - -- **Label** は、この統合を識別するために使用したいラベルを設定します。 -- **Location** は、`https://api.linear.app/graphql` を設定します。 -- **API Key** は、Linear のパーソナル API キーを設定します。キーは Linear の Settings、Security & access、[API](https://linear.app/settings/account/security)から生成できます。このキーは Linear の GraphQL API に `Authorization` ヘッダーで送信されます。 - -### Issue Tracker Mapping - -- **Team (Group) ID** は、Issue の作成先となる Linear Team の ID を設定します。以下のように Linear の GraphQL API を呼び出すことで、Team とその ID の一覧を取得できます。 - -``` -curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ - -d '{"query":"{ teams { nodes { id name key } } }"}' https://api.linear.app/graphql -``` - -### Severity Mapping Details - -Linear の Issue には深刻度フィールドではなく、数値の **priority** があります。DefectDojo の各深刻度は、`1` が Urgent、`4` が Low となる Linear の優先度にマッピングされます。 - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `4` -- **Low Mapping**: `4` -- **Medium Mapping**: `3` -- **High Mapping**: `2` -- **Critical Mapping**: `1` - -### Status Mapping Details - -各ステータス値には、Linear Team 内の Workflow State の ID を設定する必要があります。Workflow State の ID はワークスペースごとに異なるため、デフォルト値はありません。以下のように Linear の GraphQL API を呼び出すことで、Workflow State とその ID の一覧を取得できます。 - -``` -curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ - -d '{"query":"{ workflowStates { nodes { id name type team { key } } } }"}' https://api.linear.app/graphql -``` - -- **Status Field Name**: `Workflow State ID` -- **Active Mapping** は、開始済みまたは未開始の状態の ID です。例: `Todo` や `In Progress` -- **Closed Mapping** は、完了状態の ID です。例: `Done`。DefectDojo で Finding が削除されると、対応する Issue はこの状態に移動します。 - -## Opsgenie - -Opsgenie 統合を使うと、DefectDojo の Finding および Finding Group を Opsgenie のアラートとしてプッシュでき、必要に応じて Opsgenie の Team をレスポンダーとして割り当てることもできます。 - -### Instance Setup - -- **Label** は、この統合を識別するために使用したいラベルを設定します。 -- **Location** は、`https://api.opsgenie.com` を設定します。Opsgenie アカウントが EU サービスリージョンでホストされている場合は、代わりに `https://api.eu.opsgenie.com` を使用してください。アラートが Jira Service Management Operations 上にある場合（Atlassian は Opsgenie を JSM に統合しつつあります）は、`https://api.atlassian.com/jsm/ops/integration` を使用してください。 -- **API Key** は、Opsgenie の **API integration** キーを設定します。アカウント管理者は、Opsgenie の Web アプリの **Settings > Integrations** から、タイプ **API** の統合を追加し、*Create and Update Access*（DefectDojo が接続を検証できるように *Read Access* も）を付与することで作成できます。これはパーソナル API キーではなく統合キーである点に注意してください。DefectDojo は `GenieKey` 認証方式を使用しており、これに対応しているのは統合キーのみです。 - -### Issue Tracker Mapping - -- **Team Name**（オプション）は、作成されたアラートにレスポンダーとして追加したい Opsgenie Team の名前です。空欄のままにもできます。API integration キーが特定のチームにスコープされている場合、アラートは自動的にそのチームにルーティングされ、そうでない場合はアカウント自身のルーティングルールがレスポンダーを決定します。 - -### Severity Mapping Details - -深刻度は、Opsgenie の固定スケールである `P1`（critical）から `P5`（informational）までを使う、アラートの **Priority** フィールドにマッピングされます。 - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `P5` -- **Low Mapping**: `P4` -- **Medium Mapping**: `P3` -- **High Mapping**: `P2` -- **Critical Mapping**: `P1` - -深刻度が認識されない値にマッピングされている場合、priority は省略され、Opsgenie 側のデフォルト値（`P3`）が適用されます。 - -### Status Mapping Details - -Opsgenie のアラートは `open` または `closed` であり、open のアラートはさらに `acknowledged` にもなり得ます。 - -- **Status Field Name**: `Status` -- **Active Mapping**: `open` -- **Closed Mapping**: `closed` -- **False Positive Mapping**: `closed` -- **Risk Accepted Mapping**: `acknowledged` - -なお、Opsgenie では `closed` は最終ステータスであり、クローズされたアラートは再オープンできず、そのエイリアスも解放されます。他の一部のツールとは異なり、Opsgenie は作成後もコンテンツの編集を許可しているため、更新された Finding をプッシュすると、ステータスとあわせてメッセージ、説明、priority も同期されます。 - -DefectDojo は、Finding または Finding Group から導出した安定したキーを各アラートの **alias** として設定し、Opsgenie はこの alias によって open 状態のアラートを重複排除します。そのため、同じ Finding を再度プッシュすると、新しいアラートを作成するのではなく、既存の open なアラートが更新されます。 - -## PagerDuty - -PagerDuty 統合を使うと、DefectDojo の Finding および Finding Group を、選択した PagerDuty の Service 上で開かれる PagerDuty のインシデントとしてプッシュできます。 - -### Instance Setup - -- **Label** は、この統合を識別するために使用したいラベルを設定します。 -- **Location** は、`https://api.pagerduty.com` を設定します。PagerDuty アカウントが EU サービスリージョンでホストされている場合は、代わりに `https://api.eu.pagerduty.com` を使用してください。 -- **API Token** は、PagerDuty の REST API キーを設定します。アカウント管理者は、PagerDuty の Web アプリの **Integrations > API Access Keys > Create New API Key** から作成できます。「Read-only」はチェックしないでください。DefectDojo はインシデントの作成・更新を行う必要があります。 -- **From Email** は、PagerDuty アカウント上の有効なユーザーのメールアドレスを設定します。PagerDuty はインシデントの作成・更新時にこのアドレスを必要とし、インシデントのリクエスターとして表示されます。 - -### Issue Tracker Mapping - -- **Service ID** は、インシデントを開く PagerDuty の Service の ID を設定します。PagerDuty で該当の Service を表示中の URL の末尾から取得できます。例: `https://{your-subdomain}.pagerduty.com/service-directory/{service id}` - -### Severity Mapping Details - -デフォルトでは、`high` または `low` のみを受け付ける PagerDuty のインシデント **Urgency** フィールドにマッピングされます。 - -- **Severity Field Name**: `Urgency` -- **Info Mapping**: `low` -- **Low Mapping**: `low` -- **Medium Mapping**: `low` -- **High Mapping**: `high` -- **Critical Mapping**: `high` - -代わりに、PagerDuty アカウントで[Priorities](https://support.pagerduty.com/main/docs/incident-priority)が有効になっている場合は、深刻度を Priority 名にマッピングすることもできます。その場合は **Severity Field Name** を `Priority` に設定し、マッピング値としてアカウントの Priority 名（例えば `P1` から `P5` まで）を使用します。Priority にマッピングする場合、インシデントの Urgency は Service 自体の urgency ルールに委ねられます。 - -### Status Mapping Details - -PagerDuty のインシデントには、`triggered`、`acknowledged`、`resolved` という3つのステータスがあります。 - -- **Status Field Name**: `Status` -- **Active Mapping**: `triggered` -- **Closed Mapping**: `resolved` -- **False Positive Mapping**: `resolved` -- **Risk Accepted Mapping**: `acknowledged` - -なお、`resolved` は PagerDuty における最終ステータスであり、resolved のインシデントは再オープンできません。また、PagerDuty はインシデントの作成後にタイトルや説明を編集することを許可していないため、更新された Finding をプッシュすると、ステータス、urgency、priority は同期されますが、コンテンツの変更は同期されません。 - -## ServiceNow - -ServiceNow 連携を使用すると、DefectDojo の検出事項を ServiceNow のインシデントとしてプッシュできます。 - -### インスタンスのセットアップ - -DefectDojo は OAuth 2.0 経由で ServiceNow に認証します。OAuth 認証情報の作成方法は ServiceNow のリリースによって異なります。新しいリリース(Zurich 以降)ではクライアントクレデンシャルグラントを使用し、それより前のリリースではリフレッシュトークンを使用します。 - -#### ServiceNow Zurich 以降(クライアントクレデンシャル) - -最近の ServiceNow リリースでは、従来の「外部クライアント用の OAuth API エンドポイントの作成」オプションは非推奨となり、代わりに **新しいインバウンド統合エクスペリエンス(New Inbound Integration Experience)** が採用されています。これはサービスアカウントに紐づいた OAuth **クライアントクレデンシャル** グラントを発行します。 - -1. 左側のナビゲーションバーで「Application Registry」を検索して選択します。 -2. **New** をクリックし、**New Inbound Integration Experience** を選択します。 -3. **New Integration → OAuth - Client credentials grant** を選択します。 -4. **OAuth Application User** に、インシデントを作成するサービスアカウントを設定します。このアカウントのロールによって、DefectDojo が書き込める内容が決まります。 -5. 登録を保存します。ServiceNow が **Client ID** と **Client Secret** を自動生成します(登録作成時にはこれらのフィールドを空欄のままにしてください)。 - -その後、DefectDojo 側で以下を設定します。 - -- **Instance Label** には、この連携を識別するために使用したいラベルを設定します。 -- **Location** には、ServiceNow サーバーの URL を設定します。例: `https://your-organization.service-now.com/`。 -- **Client ID** には、OAuth 登録で取得した Client ID を設定します。 -- **Client Secret** には、OAuth 登録で取得した Client Secret を設定します。 - -Refresh Token、Username、Password の各フィールドは空欄のままにしてください。DefectDojo は同期のたびに新しいクライアントクレデンシャルトークンをリクエストします。 - -#### それ以前の ServiceNow リリース(リフレッシュトークン) - -従来の登録方式がまだ利用できるリリースでは、ServiceNow にインシデントをプッシュする User または Service アカウントに紐づいたリフレッシュトークンを取得します。 - -1. 左側のナビゲーションバーで「Application Registry」を検索して選択します。 -2. 「New」をクリックします。 -3. 「Create an OAuth API endpoint for external clients」を選択します。 -4. 必須フィールドを入力します。 - * Name: アプリケーションの分かりやすい名前を入力します(例: Vulnerability Integration Client)。 - * (任意)トークンの有効期間を調整します。 - * Access Token Lifespan: デフォルトは 1800 秒(30 分)です。 - * Refresh Token Lifespan: デフォルトは 8640000 秒(約 100 日)です。 -5. 「Submit」をクリックしてアプリケーションレコードを作成します。 -6. 送信後、リストからアプリケーションを選択し、**Client ID と Client Secret** フィールドを控えておきます。 - -次に、この登録を使用してリフレッシュトークンを取得する必要がありますが、これは ServiceNow API 経由でのみ取得できます。ターミナルウィンドウを開き、以下を貼り付けてください(`{{}}` で囲まれた変数は実際のユーザー情報に置き換えます)。 - -``` -curl --request POST \ - --url {{INSTANCE_HOST}}/oauth_token.do \ - --header 'content-type: application/x-www-form-urlencoded' \ - --data grant_type=password \ - --data 'client_id={{CLIENT_ID}}' \ - --data 'client_secret={{CLIENT_SECRET}}' \ - --data 'username={{USERNAME}}' \ - --data 'password={{PASSWORD}}' - ``` - -ServiceNow の認証情報が正しく、ServiceNow への管理者レベルのアクセスが許可されている場合、RefreshToken を含むレスポンスが返されます。DefectDojo との連携を完了するには、そのトークンが必要です。 - -- **Instance Label** には、この連携を識別するために使用したいラベルを設定します。 -- **Location** には、ServiceNow サーバーの URL を設定します。例: `https://your-organization.service-now.com/`。 -- **Refresh Token** には、取得したリフレッシュトークンを入力します。 -- **Client ID** には、OAuth App Registration で設定した Client ID を設定します。 -- **Client Secret** には、OAuth App Registration で設定した Client Secret を設定します。 - -### 深刻度マッピングの詳細 - -これは ServiceNow の Impact フィールドにマッピングされます。 -- **情報マッピング**: `1` -- **低マッピング**: `1` -- **中マッピング**: `2` -- **高マッピング**: `3` -- **重大マッピング**: `3` - -### ステータスマッピングの詳細 - -- **ステータスフィールド名**: `State` -- **アクティブマッピング**: `New` -- **クローズマッピング**: `Closed` -- **誤検知マッピング**: `Resolved` -- **リスク受容済みマッピング**: `Resolved` - -各マッピングには、標準のステートラベル(`New`、`In Progress`、`On Hold`、`Resolved`、`Closed`、`Cancelled`)または数値のステート値を指定できます。インシデントのステートがカスタマイズされているインスタンス、または `incident` 以外のテーブルを対象とする場合は、インスタンスの選択リストにある数値の **ステート値** を使用してください。標準セット外の数値は、設定したとおりにそのまま ServiceNow へ送信されます。組み込みの Resolution コードのデフォルトは、標準の resolved/closed ステートにのみ付随するため、カスタムのステート値を使用する場合は、下記のクローズおよび解決フィールドのマッピングと組み合わせてください。 - -### クローズおよび解決フィールド - -一部の ServiceNow インスタンスでは、インシデントが resolved または closed ステートに移行する際に、**Resolution code**(`close_code`)などのフィールドを必須とする Data Policy が適用されています。これらのフィールドを指定せずに DefectDojo がインシデントをクローズしようとすると、ServiceNow は HTTP 403 の *「Data Policy Exception」* で書き込みを拒否し、その理由は連携のエラー表示に記録されます。 - -**Custom Field Mappings** を使用して、必須フィールドをステート変更に紐づけ、**Apply On** にそれらを適用すべき区分を設定します。 - -- **Transition to Closed** — 検出事項が緩和済み/クローズになったときに送信されます。 -- **Transition to False Positive** — 検出事項が誤検知としてマークされたときに送信されます。 -- **Transition to Risk Accepted** — 検出事項がリスク受容されたときに送信されます。 - -たとえば、必須の Resolution code を満たすには次のようにします。 - -| Source | Field Name | Value | Apply On | -|---|---|---|---| -| Static | `close_code` | `Resolved by DefectDojo` | Transition to Closed | -| Static | `close_notes` | `Reviewed by the security team` | Transition to Closed | -| Static | `close_code` | `Not a defect` | Transition to False Positive | - -注記: - -- Field Name は ServiceNow のカラム名です — `close_code`、`close_notes`、またはカスタムの `u_...` フィールドなど。 -- Transition マッピングは、レコードのステートが実際に変化したときに発火します。たとえば、最初にプッシュされた時点で既にクローズしている検出事項、レコードをクローズまたは再オープンする更新、チケットリンクが削除されたときの強制クローズなどです。変化のないレコードの通常の更新では再送信されないため、`work_notes` などのジャーナルフィールドには遷移ごとに 1 件のエントリが記録されます。 -- `assignment_group` や `assigned_to` などの参照フィールドには、表示名ではなく **sys_id** を指定する必要があります。 -- JSON として解釈できる値は、型付きで送信されます: `true`、`42`、`[...]`、`{...}` — および、フィールドをクリアする `null`。このようなテキストをリテラルの文字列として送信するには、二重引用符で囲みます(例: `"null"`)。 -- `short_description`、`description`、`state`、`impact`、`urgency`、`priority` は説明テンプレートおよび深刻度/ステータスのマッピングによって管理されるため、カスタムフィールドマッピングでは設定できません。 -- `incident` 以外のテーブルでも、標準のインシデントセットに一致するステート値(`1`、`2`、`3`、`6`、`7`、`8`)は、`6`/`7`/`8` での自動 Resolution コードのデフォルトを含め、引き続きインシデントの意味で解釈されます。カスタムテーブルではその範囲外のステート値を使用するか、上記のようにクローズフィールドを明示的に指定することを推奨します。 - -## ServiceNow SecOps - -ServiceNow SecOps 連携(**ServiceNow SecOps / Vulnerability Response** とも呼ばれます)は、DefectDojo の検出事項および検出事項グループを ServiceNow のセキュリティテーブル — **Security Incident**(`sn_si_incident`)または **Vulnerable Item**(`sn_vul_vulnerable_item`)— にプッシュし、検出事項の変化(作成、更新、解決/クローズ)に応じて同期を維持します。これは上記の ServiceNow 課題管理連携に対応するセキュリティ運用版であり、Security Incident Response(SIR)または Vulnerability Response(VR)アプリケーションを利用している場合は ServiceNow SecOps を使用してください。 - -### インスタンスのセットアップ - -- **Instance Label** には、この連携を識別するために使用したいラベルを設定します。 -- **Location** には、ServiceNow サーバーの URL を設定します。例: `https://your-organization.service-now.com/`。 - -ServiceNow SecOps は 3 種類の認証方式をサポートしています。**いずれか 1 つ** を指定してください。 - -- **OAuth 2.0** — **Client ID**、**Client Secret**、**Refresh Token** を入力します。取得方法は上記の[ServiceNow](#servicenow)セクションで説明した手順とまったく同じです(Application Registry で OAuth API エンドポイントを作成し、`/oauth_token.do` で認証情報をリフレッシュトークンと交換します)。あるいは、リフレッシュトークンの代わりに OAuth のパスワードグラントを使用する場合は、**Client ID** と **Client Secret** に加えて **Username** と **Password** を指定します。 -- **API Key** — **API Key** を入力します。これは `x-sn-apikey` ヘッダーとして送信されます。このキーは、インスタンス側で Inbound Authentication Profile と REST API Access Policy が紐づけられるまでは、何も認証しません。 -- **HTTP Basic** — サービスアカウントの **Username** と **Password** を入力します。 - -サービスアカウント(または OAuth クライアント)には、対象テーブルへの書き込みアクセス権が必要です。 - -### 課題管理マッピング - -- **Target Table** は、レコードの書き込み先となる ServiceNow テーブルを選択します: **Security Incident**(`sn_si_incident`、デフォルト)または **Vulnerable Item**(`sn_vul_vulnerable_item`)。 - -### 深刻度マッピングの詳細 - -Security Incident の場合、これは **Impact** フィールドにマッピングされます。ServiceNow はインシデントの Priority を Impact と Urgency から導出するため、自分で Urgency をマッピングしない限り、Urgency はマッピングされた Impact と同じ値になります。Vulnerable Item の場合は、インスタンスで使用しているリスクフィールドに深刻度をマッピングしてください。以下のデフォルト値は、標準の SIR Impact スケール(`1` 高、`2` 中、`3` 低)に対応しており、編集可能です。 - -- **深刻度フィールド名**: `impact` -- **情報マッピング**: `3` -- **低マッピング**: `3` -- **中マッピング**: `2` -- **高マッピング**: `1` -- **重大マッピング**: `1` - -### ステータスマッピングの詳細 - -これはレコードの **State** フィールドにマッピングされます。ステート値は数値コードであり、Security Incident テーブルと Vulnerable Item テーブルで異なり、インスタンスごとにカスタマイズできるため、自分の設定と照らし合わせて確認してください。以下のデフォルト値は、標準の SIR ステートコード(`16` Analysis、`3` Closed)を使用しています。 - -- **ステータスフィールド名**: `state` -- **アクティブマッピング**: `16` -- **クローズマッピング**: `3` -- **誤検知マッピング**: `3` -- **リスク受容済みマッピング**: `3` - -レコードがクローズされると、DefectDojo は ServiceNow の **Close Code** と **Close Notes** も設定します(クローズした検出事項には `Resolved`、対応するステートには `False positive` および `Risk accepted`)。 - -### ServiceNow SecOps 固有の動作 - -- **重複排除** — 各レコードには、検出事項または検出事項グループの DefectDojo 識別子が `correlation_id` にタグ付けされます。レコードを作成する前に、DefectDojo は `correlation_id` で既存のレコードを検索します。一致するものが見つかった場合は、重複作成せずにそれを採用して更新するため、再同期はべき等です。 -- **更新内容** は、顧客に見える Comments ではなく、レコードの **Work notes** ジャーナル(内部用)に投稿されます。 -- **削除時の解決(Resolve on delete)** — DefectDojo で検出事項を削除すると、ServiceNow のレコードは削除されるのではなく、解決/クローズされます(State + Close Code)。レコードが物理削除されることはありません。 -- **参照フィールド** — 任意項目の `cmdb_ci`、`assignment_group`、`assigned_to` の値は表示名として指定できます。DefectDojo はそれぞれを `sys_id` に解決します。解決できない名前は、プッシュを失敗させることなく、警告とともに除外されます。 - -## Shortcut - -Shortcut 連携を使用すると、DefectDojo の検出事項を [Shortcut](https://www.shortcut.com/) の Story としてプッシュできます。Story は Story タイプ Bug で作成され、Shortcut ワークスペース内の Team に割り当てられます。 - -### インスタンスのセットアップ - -- **Label** には、この連携を識別するために使用したいラベルを設定します。 -- **Location** には `https://api.app.shortcut.com` を設定します。 -- **API Token** には、Shortcut の API トークンを設定します。トークンは Shortcut の Settings > Your Account > [API Tokens](https://app.shortcut.com/settings/account/api-tokens) で生成できます。 - -### 課題管理マッピング - -- **Team (Group) ID** には、Story の作成先となる Shortcut Team の UUID を設定します。この UUID は、Shortcut で Team ページを開いて URL から識別子をコピーするか、Shortcut API を呼び出すことで確認できます。 - -``` -curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/groups -``` - -### 深刻度マッピングの詳細 - -各深刻度の値は、ラベルとして Story に適用されます。ラベルが Shortcut にまだ存在しない場合は自動的に作成されるため、以下のデフォルト値をそのまま使用することも、任意のラベル名に置き換えることもできます。検出事項の深刻度が変更されると、古い深刻度ラベルが Story から削除され、新しいラベルが追加されます。 - -- **深刻度フィールド名**: `Label` -- **情報マッピング**: `sev-info` -- **低マッピング**: `sev-low` -- **中マッピング**: `sev-medium` -- **高マッピング**: `sev-high` -- **重大マッピング**: `sev-critical` - -### ステータスマッピングの詳細 - -各ステータスの値には、Shortcut ワークスペース内の Workflow State の数値 ID を設定する必要があります。Workflow State ID はワークスペースごとに固有であるため、デフォルト値はありません。Workflow State とその ID の一覧は、Shortcut API を呼び出すことで取得できます。 - -``` -curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/workflows -``` - -- **ステータスフィールド名**: `Workflow State ID` -- **アクティブマッピング**: 未着手の作業を表すステート(たとえば Backlog や To Do のステート)の ID。 -- **クローズマッピング**: Done タイプのステートの ID。DefectDojo で検出事項が削除されると、その Story はこのステートに移動します。 -- **誤検知マッピング**: 誤検知の検出事項に使用するステートの ID。 -- **リスク受容済みマッピング**: リスク受容済みの検出事項に使用するステートの ID。 - -## Freshservice - -Freshservice 連携を使用すると、DefectDojo の検出事項および検出事項グループを Freshservice のチケットとしてプッシュし、任意の agent Group に割り当てることができます。 - -### インスタンスのセットアップ - -- **Label** には、この連携を識別するために使用したいラベルを設定します。 -- **Location** には、Freshservice の URL を設定します: `https://yourcompany.freshservice.com`。 -- **API Key** には、Freshservice の API キーを設定します。プロフィール画像(右上)をクリックして **Profile settings** を開き、キャプチャを完了すると、**Delegate Approvals** セクションの下、右側にキーが表示されます。キーが表示されない場合は、アカウントレベルで API アクセスが無効になっている可能性があるため、管理者に先に有効化してもらう必要があります。 -- **Requester Email** には、チケットの依頼元となるメールアドレスを設定します。Freshservice はすべてのチケットに依頼者を必須としているため、DefectDojo はこのアドレスを依頼者としてチケットを作成します。 - -### 課題管理マッピング - -- **Group ID** には、チケットの割り当て先となる Freshservice の agent group の数値 ID を設定します。**Admin > Agent Groups** でグループを表示しているときの URL から確認できます。 -- **Workspace ID**(任意)は、複数ワークスペースのアカウントで、チケットを特定のワークスペースに振り分けます。プライマリワークスペースを使用する場合は空欄のままにします。 - -### 深刻度マッピングの詳細 - -これは Freshservice チケットの **Priority** フィールドにマッピングされます。このフィールドは数値コード(`1` Low、`2` Medium、`3` High、`4` Urgent)を使用しますが、優先度名で指定することもできます。 - -- **深刻度フィールド名**: `Priority` -- **情報マッピング**: `1` -- **低マッピング**: `1` -- **中マッピング**: `2` -- **高マッピング**: `3` -- **重大マッピング**: `4` - -### ステータスマッピングの詳細 - -これはチケットの **Status** フィールドにマッピングされます。このフィールドは数値コード(`2` Open、`3` Pending、`4` Resolved、`5` Closed)を使用しますが、ステータス名で指定することもできます。 - -- **ステータスフィールド名**: `Status` -- **アクティブマッピング**: `2` -- **クローズマッピング**: `5` -- **誤検知マッピング**: `5` -- **リスク受容済みマッピング**: `3` - -Freshservice 固有の動作として、いくつか注意すべき点があります。 - -- 更新はチケットの内容全体を同期します。Freshservice では、作成後に件名と説明を編集できます。 -- 検出事項が削除されると、チケットは削除されるのではなくクローズされます。既に Resolved または Closed になっているチケットはそのままにされます。クローズ時には解決メモが自動的に添付されるため、これを必須とするアカウント(よくあるビジネスルール)でもクローズが受け付けられます。 -- 一部のアカウントでは、チケットの優先度を Impact/Urgency マトリクスやビジネスルールから算出し、作成時に送信された優先度を無視します。DefectDojo はこれを検知し、後続の更新でマッピングされた優先度を再適用するため、マッピングは引き続き反映されます。 - -## ServiceDesk Plus - -ManageEngine ServiceDesk Plus 連携を使用すると、DefectDojo の検出事項および検出事項グループを ServiceDesk Plus のリクエストとしてプッシュし、任意の support Group に割り当てることができます。**クラウド版**(ServiceDesk Plus OnDemand)と **オンプレミス版** の両方が同じ連携でサポートされており、どちらのモードが使われるかは指定した認証情報によって決まります。 - -### インスタンスのセットアップ - -- **Label** には、この連携を識別するために使用したいラベルを設定します。 -- **Location** には、ServiceDesk Plus の URL を設定します。クラウド版の場合は `https://sdpondemand.manageengine.com`(またはお使いのリージョンに対応する URL)、オンプレミスインストールの場合はサーバーのアドレスを設定します。 - -続いて、以下の 2 種類の認証情報セットのうち **いずれか一方** を指定します。 - -#### オンプレミス: Technician Key - -- **Technician Key** には、サーバーの **Admin > General Settings > API** で技術者(Technician)向けに生成した API キーを設定します。Zoho OAuth の各フィールドは空欄のままにしてください。 - -#### クラウド: Zoho OAuth - -クラウド版は Zoho Accounts OAuth を通じて認証します。 - -1. [Zoho API Console](https://api-console.zoho.com/) を開き、**Self Client** を作成します。 -2. **Client ID** と **Client Secret** を控えておきます。 -3. Self Client の「Generate Code」タブで、スコープ `SDPOnDemand.requests.ALL` を入力し、有効期間を選択してコードを生成します。 -4. コードをリフレッシュトークンと交換します。 - -``` -curl --request POST \ - --url 'https://accounts.zoho.com/oauth/v2/token' \ - --data 'grant_type=authorization_code' \ - --data 'client_id={{CLIENT_ID}}' \ - --data 'client_secret={{CLIENT_SECRET}}' \ - --data 'code={{GENERATED_CODE}}' -``` - -5. インスタンスのフォームに **Client ID**、**Client Secret**、および取得した **Refresh Token** を入力します。アカウントが米国データセンター以外でホストされている場合は、**Token URL** をお使いのリージョンの Zoho Accounts エンドポイント(例: `https://accounts.zoho.eu/oauth/v2/token`)に設定してください。 - -### 課題管理マッピング - -- **Group Name** には、リクエストの割り当て先となる ServiceDesk Plus の support group の名前を、**Admin > Users > Support Groups** に表示されるとおりに設定します。 - -### 深刻度マッピングの詳細 - -これは、アカウントの優先度名を使用して、ServiceDesk Plus のリクエストの **Priority** フィールドに名前でマッピングされます。 - -- **深刻度フィールド名**: `Priority` -- **情報マッピング**: `Low` -- **低マッピング**: `Normal` -- **中マッピング**: `Medium` -- **高マッピング**: `High` -- **重大マッピング**: `High` - -### ステータスマッピングの詳細 - -これは、リクエストの **Status** フィールドに名前でマッピングされます。デフォルトでは組み込みのステータスを使用します。 - -- **ステータスフィールド名**: `Status` -- **アクティブマッピング**: `Open` -- **クローズマッピング**: `Closed` -- **誤検知マッピング**: `Closed` -- **リスク受容済みマッピング**: `On Hold` - -ServiceDesk Plus 固有の動作として、いくつか注意すべき点があります。 - -- 更新はリクエストの内容全体を同期します。多くのトラッカーとは異なり、ServiceDesk Plus では作成後に件名と説明を編集できます。 -- 検出事項が削除されると、リクエストは削除されるのではなくクローズされます。既に Closed または Resolved になっているリクエストはそのままにされます。 -- アカウント側でクローズ時にフィールド(たとえば resolution)を必須にしている場合、DefectDojo からプッシュされたクローズがそのルールによって拒否されることがあり、その場合は Integration errors テーブルに表示されます。 - -## Zendesk - -Zendesk 連携を使用すると、DefectDojo の検出事項および検出事項グループを Zendesk のチケットとしてプッシュし、任意の Zendesk Group に割り当てることができます。 - -### インスタンスのセットアップ - -- **Label** には、この連携を識別するために使用したいラベルを設定します。 -- **Location** には、Zendesk アカウントの URL を設定します。例: `https://your-subdomain.zendesk.com`。 -- **Email** には、API トークンの持ち主である Zendesk エージェントのメールアドレスを設定します。 -- **API Token** には、Zendesk の API トークンを設定します。管理者は Zendesk Admin Center の **Apps and integrations > APIs > Zendesk API** でトークンを作成できます(トークンアクセスを有効化しておく必要があります)。 - -### 課題管理マッピング - -- **Group ID** には、チケットの割り当て先となる Zendesk Group の数値 ID を設定します。Admin Center の **People > Team > Groups** で確認するか、グループを表示しているときの URL から確認できます。 - -### 深刻度マッピングの詳細 - -これは Zendesk チケットの **Priority** フィールドにマッピングされます。このフィールドには `low`、`normal`、`high`、`urgent` を指定できます。 - -- **深刻度フィールド名**: `Priority` -- **情報マッピング**: `low` -- **低マッピング**: `low` -- **中マッピング**: `normal` -- **高マッピング**: `high` -- **重大マッピング**: `urgent` - -### ステータスマッピングの詳細 - -Zendesk チケットは、`new`、`open`、`pending`、`hold`、`solved`、`closed` のステータスをサポートしています。`hold` を使用するには、事前にアカウントで有効化しておく必要がある点に注意してください。 - -- **ステータスフィールド名**: `Status` -- **アクティブマッピング**: `new` -- **クローズマッピング**: `solved` -- **誤検知マッピング**: `solved` -- **リスク受容済みマッピング**: `pending` - -Zendesk 固有の動作として、いくつか注意すべき点があります。 - -- Zendesk ではチケットの説明が最初のコメントとして扱われ、作成後は編集できません。そのため、更新された検出事項をプッシュすると、チケットの件名・優先度・ステータスは同期されますが、説明の変更は同期されません。 -- 検出事項が削除されると、チケットは削除されるのではなく `solved` にマークされます。Zendesk は solved になったチケットを一定期間後に自動的にクローズします。 -- `closed` は最終ステータスです。クローズされたチケットはまったく更新できず、チケットがクローズ済みの検出事項をプッシュするとエラーが報告されます。 diff --git a/docs/content/connectors/downstream/downstream_toolreference.md b/docs/content/connectors/downstream/downstream_toolreference.md deleted file mode 100644 index bbde7166200..00000000000 --- a/docs/content/connectors/downstream/downstream_toolreference.md +++ /dev/null @@ -1,766 +0,0 @@ ---- -title: "Downstream Connectors Tool Reference" -description: "Detailed setup guides for Downstream Connectors" -weight: 1 -audience: pro -aliases: - - /en/share_your_findings/integrations_toolreference - - /issue_tracking/pro_integration/integrations_toolreference/ ---- -Here are specific instructions detailing how to set up a DefectDojo Downstream Connector with a third party Issue Tracker. - -## Azure DevOps Boards - -### Instance Setup - -- **Label** should be the label that you want to use to identify this integration. -- **Location** should be set to your Azure URL - for example `https://dev.azure.com/{your organization}` -- **Token** should be set to a personal access token from Azure. - -Authentication with Azure DevOps requires a [personal access token](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows) -with permissions set to "Read, Write and Manage" for "Work Items" for the Azure Project that you wish to work with. - -### Issue Tracker Mapping - -These details dictate how DefectDojo will map Finding or Finding Group attributes to a given Project in Azure DevOps: - -#### Issue Tracker Mapping Details - -The `Project ID` field corresponds to the name or the ID of the Project in Azure. - -#### Severity Mapping Details - -The attributes in the form are supplied as defaults, and are as follows: - -- **Severity Field Name**: `/fields/Microsoft.VSTS.Common.Priority` -- **Info Mapping**: `4` -- **Low Mapping**: `4` -- **Medium Mapping**: `3` -- **High Mapping**: `2` -- **Critical Mapping**: `1` - -#### Status Mapping Details - -The attributes in the form are supplied as defaults and are as follows: - -- **Status Field Name**: `/fields/System.State` -- **Active Mapping**: `To Do` -- **Closed Mapping**: `Done` -- **False Positive Mapping**: `Done` -- **Risk Accepted Mapping**: `Done` - -## Bitbucket - -The Bitbucket integration allows you to push issues to the [issue tracker](https://support.atlassian.com/bitbucket-cloud/docs/enable-an-issue-tracker/) of a Bitbucket Cloud repository. - -The issue tracker is optional in Bitbucket and must be enabled on the repository before DefectDojo can create Issues in it. To enable it, open the repository in Bitbucket and select **Repository settings**, then enable the issue tracker under **Features**. - -### Instance Setup - -- **Label** should be the label that you want to use to identify this integration. -- **Location** should be set to `https://bitbucket.org`. -- **Email** should be the email address of the Atlassian account that the API token belongs to. -- **API Token** should be set to a scoped Atlassian API token. - -Bitbucket app passwords are deprecated by Atlassian and will not work with this integration. To create an API token: - -1. Open [Atlassian account settings](https://id.atlassian.com/manage-profile/security/api-tokens) and choose **Security**, then **Create and manage API tokens**. -2. Choose **Create API token with scopes**, name the token, and set an expiry date. -3. Select **Bitbucket** as the app. -4. Grant the token permission to read repositories and to read and write issues. - -### Issue Tracker Mapping - -- **Workspace** should be the slug of the workspace that contains the repository, as it appears in bitbucket.org URLs. -- **Repository Slug** should be the slug of the repository that you want to create Issues in. - -### Severity Mapping Details - -This maps to the Bitbucket issue Priority field. The attributes in the form are supplied as defaults, and each value must be one of Bitbucket's priorities: `trivial`, `minor`, `major`, `critical`, or `blocker`. - -- **Severity Field Name**: `priority` -- **Info Mapping**: `trivial` -- **Low Mapping**: `minor` -- **Medium Mapping**: `major` -- **High Mapping**: `critical` -- **Critical Mapping**: `blocker` - -### Status Mapping Details - -This maps to the Bitbucket issue State field. Each value must be one of Bitbucket's issue states: `new`, `open`, `resolved`, `on hold`, `invalid`, `duplicate`, `wontfix`, or `closed`. - -- **Status Field Name**: `state` -- **Active Mapping**: `new` -- **Closed Mapping**: `resolved` -- **False Positive Mapping**: `invalid` -- **Risk Accepted Mapping**: `wontfix` - -## GitHub - -The GitHub integration allows you to add issues to a [GitHub Project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects), which also open Issues in an associated Repo. These Repos/Projects can be associated with either a GitHub Organization or a personal GitHub account. - -### Instance Setup - -- **Label** should be the label that you want to use to identify this integration. -- **Location** should be set to your GitHub User or Organization URL, depending on where you wish to create issues. for example `https://github.com/{your-organization}` -- **Token** should be set to a personal access token from GitHub. - -Personal access tokens for GitHub can be created at https://github.com/settings/tokens. The token must have Repo and Project scopes. - -### Issue Tracker Mapping - -- **Issue Tracker Mapping Label** should be set to identify the Project or Repo that you wish to create Issues in. -- **Project Number** should be the ID of a GitHub project that you want to send items to. You can get this from the URL while looking at a Project, for example `https://github.com/orgs/{your-org}/projects/{project number}`. -- **Repository Name** should be the name of a repo associated with your organization (or user) that you want to push Issues to. - - -### Severity Mapping Details - -**In order to set up the integration, the Project MUST have a custom field created to represent Issue Priority, otherwise Severity will not be mapped correctly and Issues will not push to GitHub.** - -Follow this guide to create a [custom field](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/quickstart-for-projects#creating-a-field-to-track-priority). -Each Severity will need to have a corresponding single-select option available. For example, out of the box DefectDojo suggests P0, P1, P2, P3, P4 as possible Priority values, and each of those will need to be added to the Priority custom field. - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `P0` -- **Low Mapping**: `P1` -- **Medium Mapping**: `P2` -- **High Mapping**: `P3` -- **Critical Mapping**: `P4` - -### Status Mapping Details - -By default, new GitHub Projects will have Statuses for Issues of "In Progress" and "Done". Additional statuses can be added to the Project to track False Positive or Risk Accepted status if you wish. One of the ways this can be done is by adding a new Status Column to the Project Board. - -- **Status Field Name**: `Status` -- **Active Mapping**: `In Progress` -- **Closed Mapping**: `Done` -- **False Positive Mapping**: `Done` -- **Risk Accepted Mapping**: `Done` - -## GitLab - -The GitLab integration allows you to add issues to a [GitLab Project](https://docs.gitlab.com/ee/user/project/). - -### Instance Setup - -- **Label** should be the label that you want to use to identify this integration. -- **Location** should be set to the link to your GitLab server, for example `https://gitlab.com/`. -- **Token** should be set to a personal access token from GitLab. The token must have API scopes. See [GitLab’s guide to creating a personal access token](https://docs.gitlab.com/user/profile/personal_access_tokens/#create-a-personal-access-token). - -### Issue Tracker Mapping - -- **Project Name**: The name of the project in GitLab that you want to send issues to. - -### Severity Mapping Details - -This maps to the GitLab Priority field. -- **Severity Field Name**: `Priority` -- **Info Mapping**: `1` -- **Low Mapping**: `2` -- **Medium Mapping**: `3` -- **High Mapping**: `4` -- **Critical Mapping**: `5` - -### Status Mapping Details - -By default, GitLab has statuses of 'opened' and 'closed'. Additional status labels can be added if you want to track False Positive or Risk Accepted status. See [GitLab Docs](https://docs.gitlab.com/user/work_items/status/) for details. - -- **Status Field Name**: `Status` -- **Active Mapping**: `opened` -- **Closed Mapping**: `closed` -- **False Positive Mapping**: `closed` -- **Risk Accepted Mapping**: `closed` - -## Jira - -The Jira integration pushes DefectDojo Findings and Finding Groups to a Jira project as issues, keeps each issue's status in sync with the Finding, and links the Finding back to the created issue. Both Jira **Cloud** and **Data Center / Server** are supported. Jira Service Management is not supported. - -### Choosing an authentication method - -Set **Jira Deployment** first, then pick an **Authentication Method**: - -**Jira Cloud** -- **API Token (email + token)** — HTTP Basic auth using an Atlassian account email and an [API token](https://id.atlassian.com/manage-profile/security/api-tokens). Calls go directly to your site URL. -- **OAuth 2.0 (recommended)** — a one-time browser consent; DefectDojo obtains and refreshes the tokens for you. -- **Service Account Token** — a scoped API token created for an Atlassian [service account](https://support.atlassian.com/user-management/docs/manage-api-tokens-for-service-accounts/). - -**Jira Data Center / Server** -- **Personal Access Token (recommended)** -- **Username + Password** - -> **How Cloud auth reaches Jira:** OAuth 2.0 and Service Account both authenticate as a Bearer token against Atlassian's gateway — `https://api.atlassian.com/ex/jira/{cloudId}` — which is a *different host* than your `https://your-site.atlassian.net` site URL. DefectDojo uses the gateway for every API call but always builds the ticket link shown on a Finding from your **site URL**, so the link a user clicks is a normal, browsable `.../browse/{ISSUE-KEY}` link. (API Token and Data Center auth call the site URL directly, so there is no split.) - -### Instance Setup - -- **Label** should be the label you want to use to identify this integration. -- **Location** should be set to your Jira **site URL**, for example `https://your-organization.atlassian.net`. This is used for the browsable ticket links, and — for API Token and Data Center auth — as the API base URL. -- The remaining fields depend on the method you chose above (email + API token, OAuth client credentials, service-account token, PAT, or username + password). - -### OAuth 2.0 setup (Cloud) - -Create a dedicated app in the [Atlassian developer console](https://developer.atlassian.com/console/myapps/), then connect from DefectDojo. - -1. Choose **Create → OAuth 2.0 integration**. It must be an *OAuth 2.0 integration* — a Connect or Forge app cannot use the 3LO authorization-code grant (you'd get `grant_type is not enabled for client`). -2. When prompted for **Access type**, choose **Resource-level**. This scopes the token to the single Jira site the user authorizes, which is exactly what one DefectDojo connection targets. (**Account-level** grants access to every site in the Atlassian account — broader than needed.) -3. Under **Permissions**, add the **Jira platform REST API** and grant the scopes listed below. Note: `offline_access` is *not* listed here — it is a standard OAuth scope DefectDojo requests in the authorization URL, not something you add on this screen. -4. Under **Authorization**, next to **OAuth 2.0 (3LO)** click **Configure** and set the **Callback URL** to `https:///integrators/jira/oauth/callback` — it must match your DefectDojo site URL exactly. Enabling this is what turns on the authorization-code grant and refresh tokens; skipping it causes the `grant_type is not enabled` / `Client is not allowed to use offline_access` errors. -5. Copy the **Client ID** and **Client Secret** into the DefectDojo form and **Submit** to save the connection. -6. Click **Connect with Jira** and approve the consent screen. Atlassian redirects back to DefectDojo, which stores the tokens and resolves your `cloudId` automatically. A "Connected" indicator appears when it succeeds. - -> The callback host is your DefectDojo `SITE_URL`. Atlassian must be able to redirect the browser there, and the value must match what DefectDojo sends exactly — so use the real hostname your users reach DefectDojo at, not a value only reachable from inside the network. - -#### Minimum OAuth scopes - -DefectDojo requests these four classic scopes by default, and they are also the **absolute minimum** required — each one backs a specific behavior: - -| Scope | Required for | -|-------|--------------| -| `read:jira-work` | Reading the project, issues, and available transitions (connection validation and status sync). | -| `write:jira-work` | Creating and editing issues, and executing status transitions. | -| `read:jira-user` | The connection's identity check — DefectDojo calls `/myself` when validating access. | -| `offline_access` | Issuing a **refresh token**. Without it the access token expires (~1 hour after you connect) and the connection stops working, because DefectDojo can no longer refresh it. | - -Atlassian recommends classic scopes over granular ones; the four above keep the app's footprint minimal and are sufficient for everything the integration does. - -##### Granular scope alternative - -If your organization requires **granular** scopes instead of classic, the minimum equivalent set is: - -| Granular scope | Required for | -|----------------|--------------| -| `read:user:jira` | The `/myself` identity check. | -| `read:project:jira` | Validating the target project exists. | -| `read:issue:jira` | Reading an issue's current status during sync. | -| `write:issue:jira` | Creating and editing issues **and executing status transitions** — there is no separate transition-write scope; a transition is a write to the issue. | -| `read:issue.transition:jira` | Listing the transitions available on an issue. | -| `offline_access` | The refresh token (same as classic). | - -Depending on your site's field configuration, an endpoint may also require companion read scopes to expand fields — most commonly `read:status:jira` and `read:field:jira` (and `read:issue-meta:jira` for create). If a push fails with a `403` "scope does not match" error, add the exact scope named in the error. This companion-scope sprawl is precisely why classic scopes are recommended. - -For the **Service Account Token** method, grant the token `read:jira-work` and `write:jira-work` (plus `read:jira-user`) — or the granular equivalents above without `offline_access`. `offline_access` does not apply — a service-account token is long-lived and is not refreshed by DefectDojo. - -### Issue Tracker Mapping - -- **Project Key**: the key of the Jira project to create issues in, for example `SEC`. -- **Issue Type**: the issue type to create, for example `Bug` or `Task`. Defaults to `Bug`. - -### Severity Mapping Details - -Defaults match Jira's default priority scheme. Edit them to match the priority names in your project: - -- **Severity Field Name**: `priority` -- **Info Mapping**: `Lowest` -- **Low Mapping**: `Low` -- **Medium Mapping**: `Medium` -- **High Mapping**: `High` -- **Critical Mapping**: `Highest` - -### Status Mapping Details - -Statuses vary per project workflow, so these defaults are meant to be edited to **your** workflow's status names: - -- **Status Field Name**: `status` -- **Active Mapping**: `To Do` -- **Closed Mapping**: `Done` -- **False Positive Mapping**: `Done` -- **Risk Accepted Mapping**: `Done` - -### Custom Fields (optional) - -You can map additional Jira fields — for example a required `resolution` on close, or `labels` — in the mapping's **Custom Fields** step. Each custom-field mapping has four parts: - -- **Source** — where the value comes from: an attribute of the **Finding**, **Test**, **Engagement**, or **Asset** being pushed, or a **Static value**. -- **Value** — for an object source, the specific attribute to read, chosen from a list of that object's fields with human-readable labels (for example *Severity*, *CVE*, *Mitigation*). For a **Static value** source this is a free-text box you type the literal value into. -- **Vendor Field** — the Jira field to write to. Because DefectDojo can read Jira's field catalog, this is a searchable picker that lists each field by its **display name** and resolves it to the internal id for you — so you select *DD Close Justification* and DefectDojo stores `customfield_10255`. The picker is populated from the connection, so it works once the connection is saved and validated. -- **Application point** — *when* to send the field: on **ticket creation**, on **every update**, or as part of a specific status **transition** (Active / Closed / False Positive / Risk Accepted). A transition-scoped field is sent as part of that transition's edit — this is how you supply a value Jira only accepts on a transition screen, most commonly a `resolution` your workflow requires when an issue is resolved. - -### Ticket Templates (optional) - -By default Jira issues use DefectDojo's built-in title and body. To customize them, attach a **Ticket Template** to the mapping in its **Ticket Template** step. A template defines four independently-optional pieces — the **Finding** summary and description, and the **Finding Group** summary and description. Any piece left blank falls back to the built-in default, so you can override just the title, just the body, or all four. Use **Test render** in the template editor to preview the rendered output against sample data — catching mistakes such as unknown placeholders or values that exceed a field's length limit — before saving. If a template is later deleted, the mappings that used it revert to the built-in defaults automatically. - -### How it works - -- **Create / Update / Delete:** creating pushes a new issue and records the link on the Finding; updating edits the existing issue; deleting a Finding force-closes its issue (nothing is deleted in Jira). Pushes can be manual ("Push to Integrator") or automatic per the Issue Tracker Assignment. -- **Status reconciliation:** after creating (and on every update) DefectDojo reads the issue's current status and, if it differs from the mapped target, finds a single workflow transition that reaches it and applies it. If no such transition exists, the mapping records an error rather than failing silently. Any transition-scoped custom fields are sent with that transition. -- **Ticket link:** the link surfaced on the Finding is `https://your-site.atlassian.net/browse/{ISSUE-KEY}` — always your public site URL, never the internal gateway. -- **Token lifecycle (OAuth):** DefectDojo owns the whole flow — it performs the authorization-code exchange, stores the access and refresh tokens, and refreshes on demand before a push, persisting the new refresh token each time (Atlassian rotates it on every refresh). -- **Credential storage:** all connection credentials (passwords, tokens, client secrets, OAuth tokens) are encrypted at rest and are never returned through the API — editing a connection shows a "leave blank to keep" placeholder for stored secrets. - -## Linear - -The Linear integration allows you to push DefectDojo Findings as [Linear](https://linear.app/) Issues. Issues are created in a Team in your Linear workspace. - -### Instance Setup - -- **Label** should be the label that you want to use to identify this integration. -- **Location** should be set to `https://api.linear.app/graphql`. -- **API Key** should be set to a Linear personal API key. Keys can be generated in Linear under Settings, then Security & access, then [API](https://linear.app/settings/account/security). The key is sent to Linear's GraphQL API in the `Authorization` header. - -### Issue Tracker Mapping - -- **Team (Group) ID** should be set to the ID of the Linear Team that Issues will be created for. You can list your Teams and their IDs by calling the Linear GraphQL API: - -``` -curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ - -d '{"query":"{ teams { nodes { id name key } } }"}' https://api.linear.app/graphql -``` - -### Severity Mapping Details - -A Linear Issue carries a numeric **priority** rather than a severity field. Each DefectDojo severity maps to a Linear priority, where `1` is Urgent and `4` is Low: - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `4` -- **Low Mapping**: `4` -- **Medium Mapping**: `3` -- **High Mapping**: `2` -- **Critical Mapping**: `1` - -### Status Mapping Details - -Each status value must be set to the ID of a Workflow State in your Linear Team. Workflow State IDs are unique to each workspace, so there are no default values. You can list the Workflow States and their IDs by calling the Linear GraphQL API: - -``` -curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ - -d '{"query":"{ workflowStates { nodes { id name type team { key } } } }"}' https://api.linear.app/graphql -``` - -- **Status Field Name**: `Workflow State ID` -- **Active Mapping**: the ID of a started or unstarted state, for example `Todo` or `In Progress`. -- **Closed Mapping**: the ID of a completed state, for example `Done`. When a Finding is deleted in DefectDojo, its Issue is moved to this state. - -## Opsgenie - -The Opsgenie Integration allows you to push DefectDojo Findings and Finding Groups as Opsgenie Alerts, optionally routed to an Opsgenie Team as a responder. - -### Instance Setup - -- **Label** should be the label that you want to use to identify this integration. -- **Location** should be set to `https://api.opsgenie.com`. If your Opsgenie account is hosted in the EU service region, use `https://api.eu.opsgenie.com` instead. If your alerts live in Jira Service Management Operations (Atlassian is folding Opsgenie into JSM), use `https://api.atlassian.com/jsm/ops/integration`. -- **API Key** should be set to an Opsgenie **API integration** key. An account administrator can create one in the Opsgenie web app under **Settings > Integrations**: add an integration of type **API** and give it *Create and Update Access* (and *Read Access* so DefectDojo can verify the connection). Note that this is an integration key, not a personal API key - DefectDojo authenticates with `GenieKey` authorization, which only integration keys support. - -### Issue Tracker Mapping - -- **Team Name** *(optional)* should be the name of the Opsgenie Team to add as a responder on created alerts. You can leave it empty: if the API integration key is team-scoped, alerts route to that team automatically, and otherwise your account's own routing rules decide the responders. - -### Severity Mapping Details - -Severities map to the Opsgenie alert **Priority** field, which uses Opsgenie's fixed `P1` (critical) through `P5` (informational) scale: - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `P5` -- **Low Mapping**: `P4` -- **Medium Mapping**: `P3` -- **High Mapping**: `P2` -- **Critical Mapping**: `P1` - -If a severity is mapped to an unrecognized value, the priority is omitted and Opsgenie applies its own default (`P3`). - -### Status Mapping Details - -Opsgenie alerts are `open` or `closed`, and an open alert can additionally be `acknowledged`: - -- **Status Field Name**: `Status` -- **Active Mapping**: `open` -- **Closed Mapping**: `closed` -- **False Positive Mapping**: `closed` -- **Risk Accepted Mapping**: `acknowledged` - -Note that `closed` is a final status in Opsgenie - a closed alert cannot be reopened, and its alias is released. Unlike some other tools, Opsgenie does allow content edits after creation, so pushing an updated Finding syncs its message, description, and priority alongside the status. - -DefectDojo sets each alert's **alias** to a stable key derived from the Finding or Finding Group, and Opsgenie de-duplicates open alerts by alias - so re-pushing the same Finding updates the existing open alert instead of creating a duplicate. - -## PagerDuty - -The PagerDuty Integration allows you to push DefectDojo Findings and Finding Groups as PagerDuty Incidents, opened on a PagerDuty Service of your choice. - -### Instance Setup - -- **Label** should be the label that you want to use to identify this integration. -- **Location** should be set to `https://api.pagerduty.com`. If your PagerDuty account is hosted in the EU service region, use `https://api.eu.pagerduty.com` instead. -- **API Token** should be set to a PagerDuty REST API key. An account administrator can create one in the PagerDuty web app under **Integrations > API Access Keys > Create New API Key**. Leave "Read-only" unchecked - DefectDojo needs to create and update incidents. -- **From Email** should be the email address of a valid user on your PagerDuty account. PagerDuty requires this address when creating or updating incidents, and it will be shown as the incident requester. - -### Issue Tracker Mapping - -- **Service ID** should be the ID of the PagerDuty Service that incidents will be opened on. You can find it at the end of the URL while looking at the Service in PagerDuty, for example `https://{your-subdomain}.pagerduty.com/service-directory/{service id}`. - -### Severity Mapping Details - -By default this maps to the PagerDuty incident **Urgency** field, which only accepts `high` or `low`: - -- **Severity Field Name**: `Urgency` -- **Info Mapping**: `low` -- **Low Mapping**: `low` -- **Medium Mapping**: `low` -- **High Mapping**: `high` -- **Critical Mapping**: `high` - -Alternatively, if your PagerDuty account has [Priorities](https://support.pagerduty.com/main/docs/incident-priority) enabled, you can map severities to Priority names instead. Set the **Severity Field Name** to `Priority` and use your account's Priority names (for example `P1` through `P5`) as the mapping values. When mapping to Priority, the incident's Urgency is left to your Service's own urgency rules. - -### Status Mapping Details - -PagerDuty incidents have three statuses: `triggered`, `acknowledged`, and `resolved`. - -- **Status Field Name**: `Status` -- **Active Mapping**: `triggered` -- **Closed Mapping**: `resolved` -- **False Positive Mapping**: `resolved` -- **Risk Accepted Mapping**: `acknowledged` - -Note that `resolved` is a final status in PagerDuty - a resolved incident cannot be reopened. Also note that PagerDuty does not allow an incident's title or description to be edited after creation, so pushing an updated Finding will sync its status, urgency, and priority, but not content changes. - -## ServiceNow - -The ServiceNow Integration allows you to push DefectDojo Findings as ServiceNow Incidents. - -### Instance Setup - -DefectDojo authenticates to ServiceNow over OAuth 2.0. How you create the OAuth credentials depends on your ServiceNow release — newer releases (Zurich and later) use a Client Credentials grant, while earlier releases use a refresh token. - -#### ServiceNow Zurich and later (client credentials) - -Recent ServiceNow releases deprecated the classic "Create an OAuth API endpoint for external clients" option in favor of the **New Inbound Integration Experience**, which issues an OAuth **Client Credentials** grant bound to a service account: - -1. In the left-hand navigation bar, search for "Application Registry" and select it. -2. Click **New**, then choose **New Inbound Integration Experience**. -3. Select **New Integration → OAuth - Client credentials grant**. -4. Set the **OAuth Application User** to the service account that will create Incidents. That account's roles determine what DefectDojo is allowed to write. -5. Save the registration. ServiceNow auto-generates the **Client ID** and **Client Secret** (leave those fields blank when creating the registration). - -Then, in DefectDojo: - -- **Instance Label** should be the label that you want to use to identify this integration. -- **Location** should be set to the URL for your ServiceNow server, for example `https://your-organization.service-now.com/`. -- **Client ID** should be the Client ID from the OAuth registration. -- **Client Secret** should be the Client Secret from the OAuth registration. - -Leave the Refresh Token, Username, and Password fields empty — DefectDojo requests a fresh client-credentials token for each sync. - -#### Earlier ServiceNow releases (refresh token) - -On releases that still offer the classic registration, obtain a Refresh Token associated with the User or Service account that will push Incidents to ServiceNow: - -1. In the left-hand navigation bar, search for "Application Registry" and select it. -2. Click "New". -3. Choose "Create an OAuth API endpoint for external clients". -4. Fill in the required fields: - * Name: Provide a meaningful name for your application (e.g., Vulnerability Integration Client). - * (Optional) Adjust the Token Lifespan: - * Access Token Lifespan: Default is 1800 seconds (30 minutes). - * Refresh Token Lifespan: The default is 8640000 seconds (approximately 100 days). -5. Click Submit to create the application record. -6. After submission, select the application from the list and take note of the **Client ID and Client Secret** fields. - -You will then need to use this registration to obtain a Refresh Token, which can only be obtained through the ServiceNow API. Open a terminal window and paste the following (substituting the variables wrapped in `{{}}` with your user's actual information) - -``` -curl --request POST \ - --url {{INSTANCE_HOST}}/oauth_token.do \ - --header 'content-type: application/x-www-form-urlencoded' \ - --data grant_type=password \ - --data 'client_id={{CLIENT_ID}}' \ - --data 'client_secret={{CLIENT_SECRET}}' \ - --data 'username={{USERNAME}}' \ - --data 'password={{PASSWORD}}' - ``` - -If your ServiceNow credentials are correct, and allow for admin level-access to ServiceNow, you should receive a response with a RefreshToken. You'll need that token to complete integration with DefectDojo. - -- **Instance Label** should be the label that you want to use to identify this integration. -- **Location** should be set to the URL for your ServiceNow server, for example `https://your-organization.service-now.com/`. -- **Refresh Token** is where the Refresh Token should be entered. -- **Client ID** should be the Client ID set in the OAuth App Registration. -- **Client Secret** should be the Client Secret set in the OAuth App Registration. - -### Severity Mapping Details - -This maps to the ServiceNow Impact field. -- **Info Mapping**: `1` -- **Low Mapping**: `1` -- **Medium Mapping**: `2` -- **High Mapping**: `3` -- **Critical Mapping**: `3` - -### Status Mapping Details - -- **Status Field Name**: `State` -- **Active Mapping**: `New` -- **Closed Mapping**: `Closed` -- **False Positive Mapping**: `Resolved` -- **Risk Accepted Mapping**: `Resolved` - -Each mapping accepts a standard state label (`New`, `In Progress`, `On Hold`, `Resolved`, `Closed`, `Cancelled`) or a numeric state value. On instances with customized Incident states — or when targeting a table other than `incident` — use the numeric **state value** from your instance's choice list; a numeric value outside the standard set is sent to ServiceNow exactly as configured. The built-in Resolution-code default only accompanies the standard resolved/closed states, so pair custom state values with the close and resolution field mappings below. - -### Close and resolution fields - -Some ServiceNow instances enforce a Data Policy that makes fields such as the **Resolution code** (`close_code`) mandatory whenever an Incident moves to a resolved or closed state. If DefectDojo closes an Incident without them, ServiceNow rejects the write with an HTTP 403 *"Data Policy Exception"* and the reason is recorded in the integration's Errors view. - -Attach the required fields to the state change with **Custom Field Mappings**, setting **Apply On** to the disposition that should carry them: - -- **Transition to Closed** — sent when a Finding is mitigated / closed. -- **Transition to False Positive** — sent when a Finding is marked a false positive. -- **Transition to Risk Accepted** — sent when a Finding is risk accepted. - -For example, to satisfy a mandatory Resolution code: - -| Source | Field Name | Value | Apply On | -|---|---|---|---| -| Static | `close_code` | `Resolved by DefectDojo` | Transition to Closed | -| Static | `close_notes` | `Reviewed by the security team` | Transition to Closed | -| Static | `close_code` | `Not a defect` | Transition to False Positive | - -Notes: - -- Field Name is the ServiceNow column name — `close_code`, `close_notes`, or a custom `u_...` field. -- Transition mappings fire when the record's state actually changes: a Finding that is already closed when first pushed, an update that closes or reopens the record, and the forced close when a ticket link is deleted. They are not re-sent on routine updates of an unchanged record, so journal fields such as `work_notes` receive one entry per transition. -- Reference fields such as `assignment_group` and `assigned_to` expect a **sys_id**, not a display name. -- Values that parse as JSON are sent typed: `true`, `42`, `[...]`, `{...}` — and `null`, which clears the field. To send such text as a literal string, wrap it in double quotes (e.g. `"null"`). -- `short_description`, `description`, `state`, `impact`, `urgency`, and `priority` are owned by the description template and the severity/status mappings, so they cannot be set through a custom field mapping. -- On tables other than `incident`, state values that match the standard Incident set (`1`, `2`, `3`, `6`, `7`, `8`) are still interpreted with Incident semantics — including the automatic Resolution code default on `6`/`7`/`8`. Prefer state values outside that range on custom tables, or supply the close fields explicitly as above. - -## ServiceNow SecOps - -The ServiceNow SecOps integration (also known as **ServiceNow SecOps / Vulnerability Response**) pushes DefectDojo Findings and Finding Groups into a ServiceNow security table — a **Security Incident** (`sn_si_incident`) or a **Vulnerable Item** (`sn_vul_vulnerable_item`) — and keeps it in sync as the Finding changes (create, update, and resolve/close). It is the security-operations counterpart to the ServiceNow issue-tracker integration above; use ServiceNow SecOps when you run the Security Incident Response (SIR) or Vulnerability Response (VR) applications. - -### Instance Setup - -- **Instance Label** should be the label that you want to use to identify this integration. -- **Location** should be set to the URL for your ServiceNow server, for example `https://your-organization.service-now.com/`. - -ServiceNow SecOps supports three authentication methods; provide **one**: - -- **OAuth 2.0** — enter a **Client ID**, **Client Secret**, and **Refresh Token**. Obtain them exactly as described in the [ServiceNow](#servicenow) section above (create an OAuth API endpoint in the Application Registry, then exchange your credentials at `/oauth_token.do` for a refresh token). Alternatively, provide the **Client ID** and **Client Secret** together with a **Username** and **Password** to use the OAuth password grant instead of a refresh token. -- **API Key** — enter an **API Key**, sent as the `x-sn-apikey` header. The key authenticates nothing until an Inbound Authentication Profile and a REST API Access Policy are attached to it on the instance. -- **HTTP Basic** — enter the **Username** and **Password** of the service account. - -The service account (or OAuth client) needs write access to the target table. - -### Issue Tracker Mapping - -- **Target Table** selects the ServiceNow table records are written to: **Security Incident** (`sn_si_incident`, the default) or **Vulnerable Item** (`sn_vul_vulnerable_item`). - -### Severity Mapping Details - -For a Security Incident this maps to the **Impact** field; ServiceNow derives the incident Priority from Impact and Urgency, so Urgency mirrors the mapped Impact unless you map it yourself. For a Vulnerable Item, map severity to the risk field your instance uses. The defaults below match the standard SIR Impact scale (`1` High, `2` Medium, `3` Low) and are editable. - -- **Severity Field Name**: `impact` -- **Info Mapping**: `3` -- **Low Mapping**: `3` -- **Medium Mapping**: `2` -- **High Mapping**: `1` -- **Critical Mapping**: `1` - -### Status Mapping Details - -This maps to the record's **State** field. State values are numeric codes that differ between the Security Incident and Vulnerable Item tables and can be customized per instance, so review these against your own configuration. The defaults below use the standard SIR state codes (`16` Analysis, `3` Closed). - -- **Status Field Name**: `state` -- **Active Mapping**: `16` -- **Closed Mapping**: `3` -- **False Positive Mapping**: `3` -- **Risk Accepted Mapping**: `3` - -When a record is closed, DefectDojo also sets the ServiceNow **Close Code** and **Close Notes** (`Resolved` for closed Findings, `False positive` and `Risk accepted` for the corresponding states). - -### ServiceNow SecOps-specific behaviors - -- **Deduplication** — each record is tagged with the Finding or Finding Group's DefectDojo identifier in its `correlation_id`. Before creating a record DefectDojo looks one up by `correlation_id`; a match is adopted and updated rather than duplicated, so re-syncs are idempotent. -- **Updates** are posted to the record's **Work notes** journal (internal), never to customer-visible Comments. -- **Resolve on delete** — deleting a Finding in DefectDojo resolves/closes the ServiceNow record (State + Close Code) rather than deleting it; records are never hard-deleted. -- **Reference fields** — optional `cmdb_ci`, `assignment_group`, and `assigned_to` values may be supplied as display names; DefectDojo resolves each to its `sys_id`. A name that does not resolve is dropped with a warning rather than failing the push. - -## Shortcut - -The Shortcut integration allows you to push DefectDojo Findings as [Shortcut](https://www.shortcut.com/) Stories. Stories are created with the story type of Bug and assigned to a Team in your Shortcut workspace. - -### Instance Setup - -- **Label** should be the label that you want to use to identify this integration. -- **Location** should be set to `https://api.app.shortcut.com`. -- **API Token** should be set to a Shortcut API token. Tokens can be generated in Shortcut under Settings, then Your Account, then [API Tokens](https://app.shortcut.com/settings/account/api-tokens). - -### Issue Tracker Mapping - -- **Team (Group) ID** should be set to the UUID of the Shortcut Team that Stories will be created for. You can find this UUID by opening the Team page in Shortcut and copying the identifier from the URL, or by calling the Shortcut API: - -``` -curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/groups -``` - -### Severity Mapping Details - -Each severity value is applied to the Story as a label. Labels are created automatically in Shortcut if they do not already exist, so the default values below can be used as they are, or replaced with label names of your choosing. When a Finding's severity changes, the old severity label is removed from the Story and the new one is added. - -- **Severity Field Name**: `Label` -- **Info Mapping**: `sev-info` -- **Low Mapping**: `sev-low` -- **Medium Mapping**: `sev-medium` -- **High Mapping**: `sev-high` -- **Critical Mapping**: `sev-critical` - -### Status Mapping Details - -Each status value must be set to the numeric ID of a Workflow State in your Shortcut workspace. Workflow State IDs are unique to each workspace, so there are no default values. You can list the Workflow States and their IDs by calling the Shortcut API: - -``` -curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/workflows -``` - -- **Status Field Name**: `Workflow State ID` -- **Active Mapping**: the ID of the state for open work, for example a Backlog or To Do state. -- **Closed Mapping**: the ID of a Done type state. When a Finding is deleted in DefectDojo, its Story is moved to this state. -- **False Positive Mapping**: the ID of the state to use for False Positive Findings. -- **Risk Accepted Mapping**: the ID of the state to use for Risk Accepted Findings. - -## Freshservice - -The Freshservice Integration allows you to push DefectDojo Findings and Finding Groups as Freshservice tickets, assigned to an agent Group of your choice. - -### Instance Setup - -- **Label** should be the label that you want to use to identify this integration. -- **Location** should be set to your Freshservice URL: `https://yourcompany.freshservice.com`. -- **API Key** should be a Freshservice API key. Find it by clicking your profile picture (top right) > **Profile settings** - the key appears on the right below the **Delegate Approvals** section, after you complete the captcha. If no key is shown there, API access may be disabled at the account level and an administrator has to enable it first. -- **Requester Email** should be the email address tickets are requested on behalf of. Freshservice requires a requester on every ticket, so DefectDojo creates tickets with this address as the requester. - -### Issue Tracker Mapping - -- **Group ID** should be the numeric ID of the Freshservice agent group tickets will be assigned to. Find it in the URL while viewing the group under **Admin > Agent Groups**. -- **Workspace ID** (optional) routes tickets to a specific workspace on multi-workspace accounts. Leave it empty to use the primary workspace. - -### Severity Mapping Details - -This maps to the Freshservice ticket **Priority** field, which uses numeric codes (`1` Low, `2` Medium, `3` High, `4` Urgent). The priority names are also accepted: - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `1` -- **Low Mapping**: `1` -- **Medium Mapping**: `2` -- **High Mapping**: `3` -- **Critical Mapping**: `4` - -### Status Mapping Details - -This maps to the ticket **Status** field, which uses numeric codes (`2` Open, `3` Pending, `4` Resolved, `5` Closed). The status names are also accepted: - -- **Status Field Name**: `Status` -- **Active Mapping**: `2` -- **Closed Mapping**: `5` -- **False Positive Mapping**: `5` -- **Risk Accepted Mapping**: `3` - -A few Freshservice-specific behaviors to be aware of: - -- Updates sync the full ticket content - Freshservice allows the subject and description to be edited after creation. -- Tickets are closed rather than deleted when a Finding is removed; tickets already Resolved or Closed are left untouched. A resolution note is attached automatically on closure, so accounts that require one (a common business rule) accept the close. -- Some accounts compute a ticket's priority from an Impact/Urgency matrix or a business rule and ignore the priority sent at creation. DefectDojo detects this and re-applies the mapped priority with a follow-up update, so the mapping still takes effect. - -## ServiceDesk Plus - -The ManageEngine ServiceDesk Plus Integration allows you to push DefectDojo Findings and Finding Groups as ServiceDesk Plus requests, assigned to a support Group of your choice. Both the **cloud** (ServiceDesk Plus OnDemand) and **on-premises** editions are supported by the same integration - the credentials you provide determine which mode is used. - -### Instance Setup - -- **Label** should be the label that you want to use to identify this integration. -- **Location** should be set to your ServiceDesk Plus URL: `https://sdpondemand.manageengine.com` for the cloud edition (or your regional equivalent), or your server's address for on-premises installs. - -Then provide **one** of the two credential sets: - -#### On-premises: Technician Key - -- **Technician Key** should be an API key generated for a technician on your server, under **Admin > General Settings > API**. Leave the Zoho OAuth fields empty. - -#### Cloud: Zoho OAuth - -The cloud edition authenticates through Zoho Accounts OAuth: - -1. Open the [Zoho API Console](https://api-console.zoho.com/) and create a **Self Client**. -2. Note the **Client ID** and **Client Secret**. -3. In the Self Client's "Generate Code" tab, enter the scope `SDPOnDemand.requests.ALL`, choose a duration, and generate the code. -4. Exchange the code for a refresh token: - -``` -curl --request POST \ - --url 'https://accounts.zoho.com/oauth/v2/token' \ - --data 'grant_type=authorization_code' \ - --data 'client_id={{CLIENT_ID}}' \ - --data 'client_secret={{CLIENT_SECRET}}' \ - --data 'code={{GENERATED_CODE}}' -``` - -5. Enter the **Client ID**, **Client Secret**, and the returned **Refresh Token** in the instance form. If your account is hosted outside the US data center, set **Token URL** to your regional Zoho Accounts endpoint (for example `https://accounts.zoho.eu/oauth/v2/token`). - -### Issue Tracker Mapping - -- **Group Name** should be the name of the ServiceDesk Plus support group requests will be assigned to, exactly as it appears under **Admin > Users > Support Groups**. - -### Severity Mapping Details - -This maps to the ServiceDesk Plus request **Priority** field by name, using your account's priority names: - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `Low` -- **Low Mapping**: `Normal` -- **Medium Mapping**: `Medium` -- **High Mapping**: `High` -- **Critical Mapping**: `High` - -### Status Mapping Details - -This maps to the request **Status** field by name. The defaults use the built-in statuses: - -- **Status Field Name**: `Status` -- **Active Mapping**: `Open` -- **Closed Mapping**: `Closed` -- **False Positive Mapping**: `Closed` -- **Risk Accepted Mapping**: `On Hold` - -A few ServiceDesk Plus-specific behaviors to be aware of: - -- Updates sync the full request content - unlike most trackers, ServiceDesk Plus allows the subject and description to be edited after creation. -- Requests are closed rather than deleted when a Finding is removed; requests already Closed or Resolved are left untouched. -- If your account makes fields mandatory on closure (for example a resolution), a close pushed from DefectDojo may be rejected by those rules and will appear in the Integration errors table. - -## Zendesk - -The Zendesk Integration allows you to push DefectDojo Findings and Finding Groups as Zendesk tickets, assigned to a Zendesk Group of your choice. - -### Instance Setup - -- **Label** should be the label that you want to use to identify this integration. -- **Location** should be set to your Zendesk account URL, for example `https://your-subdomain.zendesk.com`. -- **Email** should be the email address of the Zendesk agent the API token belongs to. -- **API Token** should be set to a Zendesk API token. An administrator can create one in the Zendesk Admin Center under **Apps and integrations > APIs > Zendesk API** (token access must be enabled). - -### Issue Tracker Mapping - -- **Group ID** should be the numeric ID of the Zendesk Group that tickets will be assigned to. You can find it in the Admin Center under **People > Team > Groups**, or in the URL while viewing the group. - -### Severity Mapping Details - -This maps to the Zendesk ticket **Priority** field, which accepts `low`, `normal`, `high`, and `urgent`: - -- **Severity Field Name**: `Priority` -- **Info Mapping**: `low` -- **Low Mapping**: `low` -- **Medium Mapping**: `normal` -- **High Mapping**: `high` -- **Critical Mapping**: `urgent` - -### Status Mapping Details - -Zendesk tickets support the statuses `new`, `open`, `pending`, `hold`, `solved`, and `closed`. Note that `hold` must be enabled on your account before it can be used. - -- **Status Field Name**: `Status` -- **Active Mapping**: `new` -- **Closed Mapping**: `solved` -- **False Positive Mapping**: `solved` -- **Risk Accepted Mapping**: `pending` - -A few Zendesk-specific behaviors to be aware of: - -- The ticket description is the first comment in Zendesk and cannot be edited after creation, so pushing an updated Finding will sync the ticket's subject, priority, and status, but not description changes. -- Tickets are marked `solved` rather than deleted when a Finding is removed; Zendesk closes solved tickets automatically after a period of time. -- `closed` is a final status - closed tickets cannot be updated at all, and pushing a Finding whose ticket has closed will report an error. diff --git a/docs/content/connectors/issue_tracking.de.md b/docs/content/connectors/issue_tracking.de.md index 3c3cd24a953..e60eec2b522 100644 --- a/docs/content/connectors/issue_tracking.de.md +++ b/docs/content/connectors/issue_tracking.de.md @@ -2,7 +2,7 @@ title: Issue-Tracking-Integration description: Synchronisieren Sie DefectDojo-Findings mit Ihrem Issue-Tracking-System, um Behebung und Verantwortlichkeit zu optimieren. -weight: 5 +weight: 6 aliases: - /de/issue_tracking/ - /de/issue_tracking/intro/ @@ -16,7 +16,7 @@ Die Issue-Tracking-Integrationen von DefectDojo verbinden Ihre Workflows für da | Edition | Unterstützte Issue-Tracking-Integrationen | |--------------|---------------------------------------| | Community Edition | * [Jira](/connectors/os_jira/os__jira_guide/) | -| Pro | * [Jira](/connectors/downstream/downstream_toolreference/#jira) ([Legacy-Anleitung](/connectors/downstream/pro__jira_guide/))
* [Azure DevOps](/connectors/downstream/downstream_toolreference/#azure-devops-boards)
* [Bitbucket](/connectors/downstream/downstream_toolreference/#bitbucket)
* [Freshservice](/connectors/downstream/downstream_toolreference/#freshservice)
* [GitHub](/connectors/downstream/downstream_toolreference/#github)
* [GitLab Boards](/connectors/downstream/downstream_toolreference/#gitlab)
* [Linear](/connectors/downstream/downstream_toolreference/#linear)
* [PagerDuty](/connectors/downstream/downstream_toolreference/#pagerduty)
* [ServiceDesk Plus](/connectors/downstream/downstream_toolreference/#servicedesk-plus)
* [ServiceNow](/connectors/downstream/downstream_toolreference/#servicenow)
* [Shortcut](/connectors/downstream/downstream_toolreference/#shortcut)
* [Zendesk](/connectors/downstream/downstream_toolreference/#zendesk) | +| Pro | * [Jira](/connectors/toolreference/jira/) ([Legacy-Anleitung](/connectors/downstream/pro__jira_guide/))
* [Azure DevOps](/connectors/toolreference/azure_devops_boards/)
* [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector)
* [Freshservice](/connectors/toolreference/freshservice/)
* [GitHub](/connectors/toolreference/github/#downstream-connector)
* [GitLab Boards](/connectors/toolreference/gitlab/#downstream-connector)
* [Linear](/connectors/toolreference/linear/)
* [PagerDuty](/connectors/toolreference/pagerduty/)
* [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/)
* [ServiceNow](/connectors/toolreference/servicenow/)
* [Shortcut](/connectors/toolreference/shortcut/)
* [Zendesk](/connectors/toolreference/zendesk/) | Wenn diese Funktion aktiviert ist, kann DefectDojo Issues automatisch oder selektiv aus Products oder Engagements erstellen. Wenn Findings in DefectDojo aktualisiert werden — resolved, mitigated oder reactivated — können die entsprechenden Issues synchron gehalten werden, sodass beide Systeme den aktuellen Risikostatus widerspiegeln. diff --git a/docs/content/connectors/issue_tracking.es.md b/docs/content/connectors/issue_tracking.es.md index dfe9f3c81d6..8afb11353ee 100644 --- a/docs/content/connectors/issue_tracking.es.md +++ b/docs/content/connectors/issue_tracking.es.md @@ -2,7 +2,7 @@ title: Integración de seguimiento de incidencias description: Sincronice los hallazgos de DefectDojo con su sistema de seguimiento de incidencias para agilizar la remediación y la rendición de cuentas. -weight: 5 +weight: 6 aliases: - /es/issue_tracking/ - /es/issue_tracking/intro/ @@ -16,7 +16,7 @@ Las integraciones de seguimiento de incidencias de DefectDojo conectan sus flujo | Edición | Integraciones de seguimiento de incidencias admitidas | |--------------|---------------------------------------| | Community Edition | * [Jira](/connectors/os_jira/os__jira_guide/) | -| Pro | * [Jira](/connectors/downstream/downstream_toolreference/#jira) ([guía heredada](/connectors/downstream/pro__jira_guide/))
* [Azure DevOps](/connectors/downstream/downstream_toolreference/#azure-devops-boards)
* [Bitbucket](/connectors/downstream/downstream_toolreference/#bitbucket)
* [Freshservice](/connectors/downstream/downstream_toolreference/#freshservice)
* [GitHub](/connectors/downstream/downstream_toolreference/#github)
* [GitLab Boards](/connectors/downstream/downstream_toolreference/#gitlab)
* [Linear](/connectors/downstream/downstream_toolreference/#linear)
* [PagerDuty](/connectors/downstream/downstream_toolreference/#pagerduty)
* [ServiceDesk Plus](/connectors/downstream/downstream_toolreference/#servicedesk-plus)
* [ServiceNow](/connectors/downstream/downstream_toolreference/#servicenow)
* [Shortcut](/connectors/downstream/downstream_toolreference/#shortcut)
* [Zendesk](/connectors/downstream/downstream_toolreference/#zendesk) | +| Pro | * [Jira](/connectors/toolreference/jira/) ([guía heredada](/connectors/downstream/pro__jira_guide/))
* [Azure DevOps](/connectors/toolreference/azure_devops_boards/)
* [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector)
* [Freshservice](/connectors/toolreference/freshservice/)
* [GitHub](/connectors/toolreference/github/#downstream-connector)
* [GitLab Boards](/connectors/toolreference/gitlab/#downstream-connector)
* [Linear](/connectors/toolreference/linear/)
* [PagerDuty](/connectors/toolreference/pagerduty/)
* [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/)
* [ServiceNow](/connectors/toolreference/servicenow/)
* [Shortcut](/connectors/toolreference/shortcut/)
* [Zendesk](/connectors/toolreference/zendesk/) | Cuando está habilitada, DefectDojo puede crear incidencias automáticamente, o de forma selectiva desde Productos o Compromisos. A medida que los Hallazgos se actualizan en DefectDojo —resueltos, mitigados o reactivados—, las incidencias correspondientes se pueden mantener sincronizadas, garantizando que ambos sistemas reflejen el estado actual del riesgo. diff --git a/docs/content/connectors/issue_tracking.fr.md b/docs/content/connectors/issue_tracking.fr.md index 7be6e69694c..fef5a508469 100644 --- a/docs/content/connectors/issue_tracking.fr.md +++ b/docs/content/connectors/issue_tracking.fr.md @@ -2,7 +2,7 @@ title: Intégration de suivi des tickets description: Synchronisez les constatations DefectDojo avec votre système de suivi des tickets pour simplifier la remédiation et la responsabilisation. -weight: 5 +weight: 6 aliases: - /fr/issue_tracking/ - /fr/issue_tracking/intro/ @@ -16,7 +16,7 @@ Les intégrations de suivi des tickets de DefectDojo relient vos flux de gestion | Edition | Supported Issue Tracking Integrations | |--------------|---------------------------------------| | Édition Community | * [Jira](/connectors/os_jira/os__jira_guide/) | -| Pro | * [Jira](/connectors/downstream/downstream_toolreference/#jira) ([guide historique](/connectors/downstream/pro__jira_guide/))
* [Azure DevOps](/connectors/downstream/downstream_toolreference/#azure-devops-boards)
* [Bitbucket](/connectors/downstream/downstream_toolreference/#bitbucket)
* [Freshservice](/connectors/downstream/downstream_toolreference/#freshservice)
* [GitHub](/connectors/downstream/downstream_toolreference/#github)
* [GitLab Boards](/connectors/downstream/downstream_toolreference/#gitlab)
* [Linear](/connectors/downstream/downstream_toolreference/#linear)
* [PagerDuty](/connectors/downstream/downstream_toolreference/#pagerduty)
* [ServiceDesk Plus](/connectors/downstream/downstream_toolreference/#servicedesk-plus)
* [ServiceNow](/connectors/downstream/downstream_toolreference/#servicenow)
* [Shortcut](/connectors/downstream/downstream_toolreference/#shortcut)
* [Zendesk](/connectors/downstream/downstream_toolreference/#zendesk) | +| Pro | * [Jira](/connectors/toolreference/jira/) ([guide historique](/connectors/downstream/pro__jira_guide/))
* [Azure DevOps](/connectors/toolreference/azure_devops_boards/)
* [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector)
* [Freshservice](/connectors/toolreference/freshservice/)
* [GitHub](/connectors/toolreference/github/#downstream-connector)
* [GitLab Boards](/connectors/toolreference/gitlab/#downstream-connector)
* [Linear](/connectors/toolreference/linear/)
* [PagerDuty](/connectors/toolreference/pagerduty/)
* [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/)
* [ServiceNow](/connectors/toolreference/servicenow/)
* [Shortcut](/connectors/toolreference/shortcut/)
* [Zendesk](/connectors/toolreference/zendesk/) | Une fois activée, DefectDojo peut créer des tickets automatiquement, ou de façon sélective à partir des Produits ou des Engagements. Lorsque des Constatations sont mises à jour dans DefectDojo—résolues, atténuées ou réactivées—les tickets correspondants peuvent être synchronisés, garantissant que les deux systèmes reflètent l'état actuel du risque. diff --git a/docs/content/connectors/issue_tracking.ja.md b/docs/content/connectors/issue_tracking.ja.md index 61b711c8750..23a297861e9 100644 --- a/docs/content/connectors/issue_tracking.ja.md +++ b/docs/content/connectors/issue_tracking.ja.md @@ -1,7 +1,7 @@ --- title: 課題管理連携 description: DefectDojo の検出事項を課題管理システムと同期させ、修復と説明責任を効率化します。 -weight: 5 +weight: 6 aliases: - /ja/issue_tracking/ - /ja/issue_tracking/intro/ @@ -15,7 +15,7 @@ DefectDojo の課題管理連携は、脆弱性管理のワークフローを既 | エディション | 対応する課題管理連携 | |--------------|---------------------------------------| | Community Edition | * [Jira](/connectors/os_jira/os__jira_guide/) | -| Pro | * [Jira](/connectors/downstream/downstream_toolreference/#jira)([旧ガイド](/connectors/downstream/pro__jira_guide/))
* [Azure DevOps](/connectors/downstream/downstream_toolreference/#azure-devops-boards)
* [Bitbucket](/connectors/downstream/downstream_toolreference/#bitbucket)
* [Freshservice](/connectors/downstream/downstream_toolreference/#freshservice)
* [GitHub](/connectors/downstream/downstream_toolreference/#github)
* [GitLab Boards](/connectors/downstream/downstream_toolreference/#gitlab)
* [Linear](/connectors/downstream/downstream_toolreference/#linear)
* [PagerDuty](/connectors/downstream/downstream_toolreference/#pagerduty)
* [ServiceDesk Plus](/connectors/downstream/downstream_toolreference/#servicedesk-plus)
* [ServiceNow](/connectors/downstream/downstream_toolreference/#servicenow)
* [Shortcut](/connectors/downstream/downstream_toolreference/#shortcut)
* [Zendesk](/connectors/downstream/downstream_toolreference/#zendesk) | +| Pro | * [Jira](/connectors/toolreference/jira/)([旧ガイド](/connectors/downstream/pro__jira_guide/))
* [Azure DevOps](/connectors/toolreference/azure_devops_boards/)
* [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector)
* [Freshservice](/connectors/toolreference/freshservice/)
* [GitHub](/connectors/toolreference/github/#downstream-connector)
* [GitLab Boards](/connectors/toolreference/gitlab/#downstream-connector)
* [Linear](/connectors/toolreference/linear/)
* [PagerDuty](/connectors/toolreference/pagerduty/)
* [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/)
* [ServiceNow](/connectors/toolreference/servicenow/)
* [Shortcut](/connectors/toolreference/shortcut/)
* [Zendesk](/connectors/toolreference/zendesk/) | 有効にすると、DefectDojo は課題を自動的に、または製品やエンゲージメントから選択的に作成できます。検出事項が DefectDojo 内で更新される(解決、緩和済み、再アクティブ化される)と、対応する課題も同期を保つことができ、両方のシステムが現在のリスク状態を反映するようになります。 diff --git a/docs/content/connectors/issue_tracking.md b/docs/content/connectors/issue_tracking.md index 8ae2dbbdb5a..d30a6bb2f67 100644 --- a/docs/content/connectors/issue_tracking.md +++ b/docs/content/connectors/issue_tracking.md @@ -1,7 +1,7 @@ --- title: "Issue Tracking Integration" description: "Sync DefectDojo findings with your issue tracking system to streamline remediation and accountability." -weight: 5 +weight: 6 aliases: - /issue_tracking/ - /issue_tracking/intro/ @@ -15,7 +15,7 @@ The DefectDojo issue tracking integrations connect your vulnerability management | Edition | Supported Issue Tracking Integrations | |--------------|---------------------------------------| | Community Edition | * [Jira](/connectors/os_jira/os__jira_guide/) | -| Pro | * [Jira](/connectors/downstream/downstream_toolreference/#jira) ([legacy guide](/connectors/downstream/pro__jira_guide/))
* [Azure DevOps](/connectors/downstream/downstream_toolreference/#azure-devops-boards)
* [Bitbucket](/connectors/downstream/downstream_toolreference/#bitbucket)
* [Freshservice](/connectors/downstream/downstream_toolreference/#freshservice)
* [GitHub](/connectors/downstream/downstream_toolreference/#github)
* [GitLab Boards](/connectors/downstream/downstream_toolreference/#gitlab)
* [Linear](/connectors/downstream/downstream_toolreference/#linear)
* [PagerDuty](/connectors/downstream/downstream_toolreference/#pagerduty)
* [ServiceDesk Plus](/connectors/downstream/downstream_toolreference/#servicedesk-plus)
* [ServiceNow](/connectors/downstream/downstream_toolreference/#servicenow)
* [Shortcut](/connectors/downstream/downstream_toolreference/#shortcut)
* [Zendesk](/connectors/downstream/downstream_toolreference/#zendesk) | +| Pro | * [Jira](/connectors/toolreference/jira/) ([legacy guide](/connectors/downstream/pro__jira_guide/))
* [Azure DevOps](/connectors/toolreference/azure_devops_boards/)
* [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector)
* [Freshservice](/connectors/toolreference/freshservice/)
* [GitHub](/connectors/toolreference/github/#downstream-connector)
* [GitLab Boards](/connectors/toolreference/gitlab/#downstream-connector)
* [Linear](/connectors/toolreference/linear/)
* [PagerDuty](/connectors/toolreference/pagerduty/)
* [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/)
* [ServiceNow](/connectors/toolreference/servicenow/)
* [Shortcut](/connectors/toolreference/shortcut/)
* [Zendesk](/connectors/toolreference/zendesk/) | When enabled, DefectDojo can create issues automatically, or selectively from Assets or Engagement. As Findings are updated in DefectDojo—resolved, mitigated, or reactivated—the corresponding issues can be kept in sync, ensuring both systems reflect the current state of risk. diff --git a/docs/content/connectors/os_jira/_index.de.md b/docs/content/connectors/os_jira/_index.de.md index 3e0feb72adc..44dd125ab2c 100644 --- a/docs/content/connectors/os_jira/_index.de.md +++ b/docs/content/connectors/os_jira/_index.de.md @@ -5,7 +5,7 @@ summary: '' date: 2023-09-07 16:06:50+02:00 lastmod: 2023-09-07 16:06:50+02:00 draft: false -weight: 4 +weight: 5 chapter: true audience: opensource seo: diff --git a/docs/content/connectors/os_jira/_index.es.md b/docs/content/connectors/os_jira/_index.es.md index 1e3e3d71244..c5c799c61c4 100644 --- a/docs/content/connectors/os_jira/_index.es.md +++ b/docs/content/connectors/os_jira/_index.es.md @@ -5,7 +5,7 @@ summary: '' date: 2023-09-07 16:06:50+02:00 lastmod: 2023-09-07 16:06:50+02:00 draft: false -weight: 4 +weight: 5 chapter: true audience: opensource seo: diff --git a/docs/content/connectors/os_jira/_index.fr.md b/docs/content/connectors/os_jira/_index.fr.md index 527bf49e1c7..685522da69b 100644 --- a/docs/content/connectors/os_jira/_index.fr.md +++ b/docs/content/connectors/os_jira/_index.fr.md @@ -5,7 +5,7 @@ summary: '' date: 2023-09-07 16:06:50+02:00 lastmod: 2023-09-07 16:06:50+02:00 draft: false -weight: 4 +weight: 5 chapter: true audience: opensource seo: diff --git a/docs/content/connectors/os_jira/_index.ja.md b/docs/content/connectors/os_jira/_index.ja.md index 1338f4a3750..bb7002b4713 100644 --- a/docs/content/connectors/os_jira/_index.ja.md +++ b/docs/content/connectors/os_jira/_index.ja.md @@ -5,7 +5,7 @@ summary: '' date: 2023-09-07 16:06:50+02:00 lastmod: 2023-09-07 16:06:50+02:00 draft: false -weight: 4 +weight: 5 chapter: true audience: opensource seo: diff --git a/docs/content/connectors/os_jira/_index.md b/docs/content/connectors/os_jira/_index.md index 67813b07d16..f232adf774f 100644 --- a/docs/content/connectors/os_jira/_index.md +++ b/docs/content/connectors/os_jira/_index.md @@ -5,7 +5,7 @@ summary: "" date: 2023-09-07T16:06:50+02:00 lastmod: 2023-09-07T16:06:50+02:00 draft: false -weight: 4 +weight: 5 chapter: true audience: opensource seo: diff --git a/docs/content/connectors/toolreference/_index.de.md b/docs/content/connectors/toolreference/_index.de.md new file mode 100644 index 00000000000..a3c8e415d03 --- /dev/null +++ b/docs/content/connectors/toolreference/_index.de.md @@ -0,0 +1,16 @@ +--- +title: Tool-Referenz +description: Einrichtungsanleitungen für alle von Upstream- und Downstream-Connectors + unterstützten Tools +summary: '' +draft: false +weight: 4 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +audience: pro +exclude_search: true +--- diff --git a/docs/content/connectors/toolreference/_index.es.md b/docs/content/connectors/toolreference/_index.es.md new file mode 100644 index 00000000000..4f7db567e8b --- /dev/null +++ b/docs/content/connectors/toolreference/_index.es.md @@ -0,0 +1,16 @@ +--- +title: Referencia de herramientas +description: Guías de configuración para cada herramienta compatible con los Conectores + Upstream y Downstream +summary: '' +draft: false +weight: 4 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +audience: pro +exclude_search: true +--- diff --git a/docs/content/connectors/toolreference/_index.fr.md b/docs/content/connectors/toolreference/_index.fr.md new file mode 100644 index 00000000000..176f6f444b0 --- /dev/null +++ b/docs/content/connectors/toolreference/_index.fr.md @@ -0,0 +1,16 @@ +--- +title: Référence des outils +description: Guides de configuration pour chaque outil pris en charge par les connecteurs + Upstream et Downstream +summary: '' +draft: false +weight: 4 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +audience: pro +exclude_search: true +--- diff --git a/docs/content/connectors/toolreference/_index.ja.md b/docs/content/connectors/toolreference/_index.ja.md new file mode 100644 index 00000000000..a436d7ad8ec --- /dev/null +++ b/docs/content/connectors/toolreference/_index.ja.md @@ -0,0 +1,15 @@ +--- +title: ツールリファレンス +description: Upstream / ダウンストリームコネクタが対応する各ツールのセットアップガイド +summary: '' +draft: false +weight: 4 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +audience: pro +exclude_search: true +--- diff --git a/docs/content/connectors/toolreference/_index.md b/docs/content/connectors/toolreference/_index.md new file mode 100644 index 00000000000..427dd162a42 --- /dev/null +++ b/docs/content/connectors/toolreference/_index.md @@ -0,0 +1,15 @@ +--- +title: "Tool Reference" +description: "Setup guides for each tool supported by Upstream and Downstream Connectors" +summary: "" +draft: false +weight: 4 +chapter: true +seo: + title: "" # custom title (optional) + description: "" # custom description (recommended) + canonical: "" # custom canonical URL (optional) + robots: "" # custom robot tags (optional) +audience: pro +exclude_search: true +--- diff --git a/docs/content/connectors/toolreference/accuknox.md b/docs/content/connectors/toolreference/accuknox.md new file mode 100644 index 00000000000..52ae7e6fc25 --- /dev/null +++ b/docs/content/connectors/toolreference/accuknox.md @@ -0,0 +1,22 @@ +--- +title: "AccuKnox" +description: "How to set up the AccuKnox Upstream Connector for DefectDojo" +weight: 10 +audience: pro +--- +The AccuKnox connector imports **cloud security posture (CSPM) findings** across your whole AccuKnox tenant. DefectDojo creates a Record for each **connected cloud account**, plus a tenant\-level catch\-all Record — findings that match no specific account land there, so nothing is silently dropped. + +#### Prerequisites + +An AccuKnox **access key**. An access key inherits the permissions of the user who created it, and the **Viewer** role is sufficient. + +**Access keys expire.** When one does, the Sync fails with an authentication error rather than degrading quietly — so an authentication failure on a previously working connector usually means the key needs replacing, not that the connection is misconfigured. + +#### Connector Mappings + +1. Enter your AccuKnox CSPM host in the **Location** field. +2. Enter the access key in the **Secret** field. +3. Optionally, enter your AccuKnox **Tenant ID** (workspace ID). It is sent with every read request. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each connected cloud account becomes a Record, with AccuKnox's own four severity levels (Critical, High, Medium, Low) carried through. diff --git a/docs/content/connectors/toolreference/action1.md b/docs/content/connectors/toolreference/action1.md new file mode 100644 index 00000000000..fcec5ee0dc5 --- /dev/null +++ b/docs/content/connectors/toolreference/action1.md @@ -0,0 +1,20 @@ +--- +title: "Action1" +description: "How to set up the Action1 Upstream Connector for DefectDojo" +weight: 11 +audience: pro +--- +The Action1 connector imports **endpoint vulnerability findings** from Action1. DefectDojo creates a Record for each **endpoint (host)**. + +#### Prerequisites + +An Action1 **API key and secret** pair. The key acts as the OAuth client ID and the secret is never logged. + +#### Connector Mappings + +1. Enter `https://app.action1.com/api/3.0` in the **Location** field. +2. Enter the API key in the **API Key (Client ID)** field. +3. Enter the API secret in the **API Secret** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +**One finding is created per endpoint-and-vulnerability pair**, so a single CVE present on fifty hosts produces fifty findings, each attached to its own host's Record. This is what makes per\-host remediation tracking possible, but it does mean finding counts scale with fleet size rather than with the number of distinct CVEs. diff --git a/docs/content/connectors/toolreference/acunetix_360.de.md b/docs/content/connectors/toolreference/acunetix_360.de.md new file mode 100644 index 00000000000..7b43ce90a98 --- /dev/null +++ b/docs/content/connectors/toolreference/acunetix_360.de.md @@ -0,0 +1,22 @@ +--- +title: "Acunetix 360" +description: "Einrichtung des Acunetix 360 Upstream-Connectors für DefectDojo" +weight: 12 +audience: pro +--- +Der Acunetix-360-Connector importiert **DAST-Schwachstellenbefunde** von der Acunetix-360-Cloud-Plattform (der Invicti-Plattform). DefectDojo ermittelt die gescannten Websites Ihres Kontos und erstellt für jede **Website** einen Eintrag; die Befunde einer Website stammen aus deren letztem abgeschlossenen Scan. + +**Bitte beachten Sie:** Dieser Connector ist für **Acunetix 360** (das Cloud-Produkt unter `online.acunetix360.com`). Er ist nicht für den On-Premises-Scanner Acunetix Standard/Premium gedacht, der über eine andere API verfügt. + +#### Voraussetzungen + +Ein Acunetix-360-Konto und eine **API-Anmeldeinformation**: Öffnen Sie in Acunetix 360 Ihr Kontomenü \> **API Settings**, und notieren Sie sich die **API User ID** und generieren Sie ein **API Token**. Der Connector authentifiziert sich damit als HTTP-Basic-Anmeldedaten, daher wird ein dediziertes Service-Konto empfohlen, um automatisierte Aktivitäten von manuellen Team-Aktionen zu unterscheiden. + +#### Connector-Zuordnungen + +1. Geben Sie Ihre Acunetix-360-URL in das Feld **Location** ein: `https://online.acunetix360.com`. +2. Geben Sie die API User ID in das Feld **API User ID** ein. +3. Geben Sie das API Token in das Feld **API Token** ein. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jede gescannte Website wird zu einem Eintrag. Die Befunde stammen aus dem letzten abgeschlossenen Scan der Website; Schwachstellen, die Acunetix 360 als **Accepted Risk** oder **False Positive** markiert hat, werden weiterhin importiert, aber als inaktiv gekennzeichnet (risikoakzeptiert oder falsch-positiv), damit das DefectDojo-Produkt die Triage des Herstellers widerspiegelt. diff --git a/docs/content/connectors/toolreference/acunetix_360.es.md b/docs/content/connectors/toolreference/acunetix_360.es.md new file mode 100644 index 00000000000..9117c1a6ed0 --- /dev/null +++ b/docs/content/connectors/toolreference/acunetix_360.es.md @@ -0,0 +1,22 @@ +--- +title: "Acunetix 360" +description: "Cómo configurar el Conector Upstream de Acunetix 360 para DefectDojo" +weight: 12 +audience: pro +--- +El conector de Acunetix 360 importa **hallazgos de vulnerabilidades DAST** desde la plataforma en la nube de Acunetix 360 (la plataforma Invicti). DefectDojo descubre los sitios web escaneados de su cuenta y crea un Registro para cada **sitio web**; los hallazgos de un sitio web provienen de su último análisis completado. + +**Tenga en cuenta:** este conector es para **Acunetix 360** (el producto en la nube en `online.acunetix360.com`). No es para el escáner local Acunetix Standard/Premium, que tiene una API diferente. + +#### Requisitos previos + +Una cuenta de Acunetix 360 y una **credencial de API**: en Acunetix 360, abra el menú de su cuenta \> **API Settings**, anote el **API User ID** y genere un **API Token**. El conector se autentica con estos valores como credenciales HTTP Basic, por lo que se recomienda una cuenta de servicio dedicada para distinguir la actividad automatizada de las acciones manuales del equipo. + +#### Asignaciones del conector + +1. Ingrese la URL de su Acunetix 360 en el campo **Location**: `https://online.acunetix360.com`. +2. Ingrese el API User ID en el campo **API User ID**. +3. Ingrese el API Token en el campo **API Token**. +4. Opcionalmente, configure una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada sitio web escaneado se convierte en un Registro. Los hallazgos provienen del último análisis completado del sitio web; las vulnerabilidades que Acunetix 360 ha marcado como **Riesgo aceptado** o **Falso positivo** igualmente se importan, pero se marcan como inactivas (riesgo aceptado o falso positivo) para que el producto de DefectDojo refleje la clasificación del proveedor. diff --git a/docs/content/connectors/toolreference/acunetix_360.fr.md b/docs/content/connectors/toolreference/acunetix_360.fr.md new file mode 100644 index 00000000000..5f9551a0868 --- /dev/null +++ b/docs/content/connectors/toolreference/acunetix_360.fr.md @@ -0,0 +1,22 @@ +--- +title: "Acunetix 360" +description: "Comment configurer le Connecteur Upstream Acunetix 360 pour DefectDojo" +weight: 12 +audience: pro +--- +Le connecteur Acunetix 360 importe des **constatations de vulnérabilités DAST** depuis la plateforme cloud Acunetix 360 (la plateforme Invicti). DefectDojo découvre les sites web analysés de votre compte et crée un Enregistrement pour chaque **site web** ; les constatations d'un site web proviennent de son dernier scan terminé. + +**Veuillez noter :** ce connecteur est destiné à **Acunetix 360** (le produit cloud à l'adresse `online.acunetix360.com`). Il ne concerne pas le scanner Acunetix Standard/Premium sur site, qui dispose d'une API différente. + +#### Prérequis + +Un compte Acunetix 360 et des **identifiants API** : dans Acunetix 360, ouvrez le menu de votre compte \> **API Settings**, notez l'**API User ID** et générez un **API Token**. Le connecteur s'authentifie avec ces identifiants au format HTTP Basic ; un compte de service dédié est donc recommandé pour distinguer l'activité automatisée des actions manuelles de l'équipe. + +#### Mappages du Connecteur + +1. Saisissez l'URL de votre Acunetix 360 dans le champ **Location** : `https://online.acunetix360.com`. +2. Saisissez l'API User ID dans le champ **API User ID**. +3. Saisissez l'API Token dans le champ **API Token**. +4. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque site web analysé devient un Enregistrement. Les constatations proviennent du dernier scan terminé du site web ; les vulnérabilités qu'Acunetix 360 a marquées **Accepted Risk** ou **False Positive** sont tout de même importées, mais signalées comme inactives (risque accepté ou faux positif) afin que le produit DefectDojo reflète le triage effectué par l'éditeur. diff --git a/docs/content/connectors/toolreference/acunetix_360.ja.md b/docs/content/connectors/toolreference/acunetix_360.ja.md new file mode 100644 index 00000000000..4fb42ca3696 --- /dev/null +++ b/docs/content/connectors/toolreference/acunetix_360.ja.md @@ -0,0 +1,22 @@ +--- +title: "Acunetix 360" +description: "DefectDojo で Acunetix 360 の Upstream Connector をセットアップする方法" +weight: 12 +audience: pro +--- +Acunetix 360 コネクタは、Acunetix 360 クラウドプラットフォーム(Invicti プラットフォーム)から**DAST 脆弱性の検出事項**をインポートします。DefectDojo はアカウント内でスキャンされた Web サイトを検出し、**Web サイト**ごとにレコードを作成します。Web サイトの検出事項は、その最新の完了済みスキャンから取得されます。 + +**ご注意ください:** このコネクタは(`online.acunetix360.com` のクラウド製品である)**Acunetix 360** 用です。異なる API を持つオンプレミス版の Acunetix Standard/Premium スキャナ用ではありません。 + +#### Prerequisites + +Acunetix 360 のアカウントと**API 認証情報**が必要です。Acunetix 360 でアカウントメニュー \> **API Settings** を開き、**API User ID** を確認して **API Token** を生成してください。コネクタはこれらを HTTP Basic 認証情報として使用するため、手動によるチーム操作と自動操作を区別するために専用のサービスアカウントを利用することをお勧めします。 + +#### Connector Mappings + +1. **Location** フィールドに Acunetix 360 の URL を入力します: `https://online.acunetix360.com`。 +2. **API User ID** フィールドに API User ID を入力します。 +3. **API Token** フィールドに API Token を入力します。 +4. 必要に応じて、インポートする検出事項を制限するために **Minimum Severity** を設定します。 + +スキャンされた各 Web サイトが 1 件のレコードになります。検出事項はその Web サイトの最新の完了済みスキャンから取得されます。Acunetix 360 で **Accepted Risk** または **False Positive** としてマークされた脆弱性もインポートされますが、非アクティブ(risk-accepted または false-positive)としてフラグされるため、DefectDojo 側の製品にベンダーによるトリアージ結果が反映されます。 diff --git a/docs/content/connectors/toolreference/acunetix_360.md b/docs/content/connectors/toolreference/acunetix_360.md new file mode 100644 index 00000000000..728cd111976 --- /dev/null +++ b/docs/content/connectors/toolreference/acunetix_360.md @@ -0,0 +1,22 @@ +--- +title: "Acunetix 360" +description: "How to set up the Acunetix 360 Upstream Connector for DefectDojo" +weight: 12 +audience: pro +--- +The Acunetix 360 connector imports **DAST vulnerability findings** from the Acunetix 360 cloud platform (the Invicti platform). DefectDojo discovers your account's scanned websites and creates a Record for each **website**; the findings for a website come from its latest completed scan. + +**Please note:** this connector is for **Acunetix 360** (the cloud product at `online.acunetix360.com`). It is not for the on\-premises Acunetix Standard/Premium scanner, which has a different API. + +#### Prerequisites + +An Acunetix 360 account and an **API credential**: in Acunetix 360, open your account menu \> **API Settings**, and note the **API User ID** and generate an **API Token**. The connector authenticates with these as HTTP Basic credentials, so a dedicated service account is recommended to distinguish automated activity from manual team actions. + +#### Connector Mappings + +1. Enter your Acunetix 360 URL in the **Location** field: `https://online.acunetix360.com`. +2. Enter the API User ID in the **API User ID** field. +3. Enter the API Token in the **API Token** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each scanned website becomes a Record. Findings come from the website's latest completed scan; vulnerabilities Acunetix 360 has marked **Accepted Risk** or **False Positive** are still imported but flagged inactive (risk\-accepted or false\-positive) so the DefectDojo product reflects the vendor's triage. diff --git a/docs/content/connectors/toolreference/akamai.de.md b/docs/content/connectors/toolreference/akamai.de.md new file mode 100644 index 00000000000..4cd1c5def23 --- /dev/null +++ b/docs/content/connectors/toolreference/akamai.de.md @@ -0,0 +1,18 @@ +--- +title: "Akamai API Security" +description: "Einrichtung des Akamai API Security Upstream-Connectors für DefectDojo" +weight: 13 +audience: pro +--- +Der Akamai-API-Security-Connector verwendet einen API-Schlüssel, um Sicherheitsbefunde von der Akamai-API abzurufen. DefectDojo ermittelt Ihre Akamai-Umgebung und erstellt separate Einträge für jede in Ihrem Konto konfigurierte **Application** und jeden **Host**. + +#### Voraussetzungen + +Sie benötigen einen API-Schlüssel mit Zugriff auf die Akamai-API. Wir empfehlen, für DefectDojo ein dediziertes Service-Konto anzulegen, um automatisierte Aktivitäten klar von manuellen Team-Aktionen zu unterscheiden. + +#### Connector-Zuordnungen + +1. Geben Sie die Basis-URL Ihrer Akamai-API in das Feld **Location** ein. Diese URL ist spezifisch für Ihre Akamai-Instanz, zum Beispiel +2. Geben Sie einen gültigen **API Key** in das Feld **Secret** ein. + +DefectDojo ordnet **Applications** und **Hosts** als separate Einträge zu. Jede Application erscheint als `{name} (application)` und jeder Host als `{name} (host)` in Ihrer Eintragsliste. diff --git a/docs/content/connectors/toolreference/akamai.es.md b/docs/content/connectors/toolreference/akamai.es.md new file mode 100644 index 00000000000..09bbad3c700 --- /dev/null +++ b/docs/content/connectors/toolreference/akamai.es.md @@ -0,0 +1,18 @@ +--- +title: "Akamai API Security" +description: "Cómo configurar el Conector Upstream de Akamai API Security para DefectDojo" +weight: 13 +audience: pro +--- +El conector de Akamai API Security usa una clave de API para extraer hallazgos de seguridad desde la API de Akamai. DefectDojo descubrirá su entorno de Akamai y creará Registros independientes para cada **Application** y **Host** configurados en su cuenta. + +#### Prerrequisitos + +Necesitará una clave de API con acceso a la API de Akamai. Recomendamos crear una cuenta de servicio dedicada para DefectDojo, de modo que se distinga claramente la actividad automatizada de las acciones manuales del equipo. + +#### Asignaciones del conector + +1. Ingrese la URL base de la API de Akamai en el campo **Location**. Esta URL es específica de su instancia de Akamai: por ejemplo +2. Ingrese una **API Key** válida en el campo **Secret**. + +DefectDojo asignará las **Applications** y los **Hosts** como Registros independientes. Cada Application aparecerá como `{name} (application)` y cada Host como `{name} (host)` en su lista de Registros. diff --git a/docs/content/connectors/toolreference/akamai.fr.md b/docs/content/connectors/toolreference/akamai.fr.md new file mode 100644 index 00000000000..f73fac9c823 --- /dev/null +++ b/docs/content/connectors/toolreference/akamai.fr.md @@ -0,0 +1,18 @@ +--- +title: "Akamai API Security" +description: "Comment configurer le Connecteur Upstream Akamai API Security pour DefectDojo" +weight: 13 +audience: pro +--- +Le connecteur Akamai API Security utilise une clé API pour récupérer les constatations de sécurité depuis l'API Akamai. DefectDojo découvre votre environnement Akamai et crée des Enregistrements distincts pour chaque **Application** et **Host** configurés dans votre compte. + +#### Prérequis + +Vous aurez besoin d'une clé API ayant accès à l'API Akamai. Nous recommandons de créer un compte de service dédié pour DefectDojo afin de bien distinguer l'activité automatisée des actions manuelles de l'équipe. + +#### Mappages du Connecteur + +1. Saisissez l'URL de base de votre API Akamai dans le champ **Location**. Cette URL est spécifique à votre instance Akamai : par exemple +2. Saisissez une **API Key** valide dans le champ **Secret**. + +DefectDojo mappe les **Applications** et les **Hosts** sous forme d'Enregistrements distincts. Chaque Application apparaîtra sous la forme `{name} (application)` et chaque Host sous la forme `{name} (host)` dans votre liste d'Enregistrements. diff --git a/docs/content/connectors/toolreference/akamai.ja.md b/docs/content/connectors/toolreference/akamai.ja.md new file mode 100644 index 00000000000..5ed3f600193 --- /dev/null +++ b/docs/content/connectors/toolreference/akamai.ja.md @@ -0,0 +1,18 @@ +--- +title: "Akamai API Security" +description: "DefectDojo で Akamai API Security の Upstream Connector をセットアップする方法" +weight: 13 +audience: pro +--- +Akamai API Security コネクタは API キーを使用して Akamai API からセキュリティの検出事項を取得します。DefectDojo は Akamai 環境を検出し、アカウントに設定された**Application** と **Host** ごとに個別のレコードを作成します。 + +#### Prerequisites + +Akamai API へのアクセス権を持つ API キーが必要です。自動操作とチームによる手動操作を明確に区別するため、DefectDojo 専用のサービスアカウントを作成することをお勧めします。 + +#### Connector Mappings + +1. **Location** フィールドに Akamai API のベース URL を入力します。この URL は Akamai インスタンス固有のものです。例: +2. **Secret** フィールドに有効な **API Key** を入力します。 + +DefectDojo は **Application** と **Host** をそれぞれ別のレコードとしてマッピングします。各 Application はレコード一覧に `{name} (application)` として、各 Host は `{name} (host)` として表示されます。 diff --git a/docs/content/connectors/toolreference/akamai.md b/docs/content/connectors/toolreference/akamai.md new file mode 100644 index 00000000000..48ab8af1daa --- /dev/null +++ b/docs/content/connectors/toolreference/akamai.md @@ -0,0 +1,18 @@ +--- +title: "Akamai" +description: "How to set up the Akamai Upstream Connector for DefectDojo" +weight: 13 +audience: pro +--- +The Akamai API Security connector uses an API key to pull security findings from the Akamai API. DefectDojo will discover your Akamai environment and create separate Records for each **Application** and **Host** configured in your account. + +#### Prerequisites + +You will need an API key with access to the Akamai API. We recommend creating a dedicated service account for DefectDojo to clearly distinguish automated activity from manual team actions. + +#### Connector Mappings + +1. Enter your Akamai API base URL in the **Location** field. This URL is specific to your Akamai instance: for example +2. Enter a valid **API Key** in the **Secret** field. + +DefectDojo will map **Applications** and **Hosts** as separate Records. Each Application will appear as `{name} (application)` and each Host as `{name} (host)` in your Records list. diff --git a/docs/content/connectors/toolreference/akto.md b/docs/content/connectors/toolreference/akto.md new file mode 100644 index 00000000000..65a871b5262 --- /dev/null +++ b/docs/content/connectors/toolreference/akto.md @@ -0,0 +1,19 @@ +--- +title: "Akto" +description: "How to set up the Akto Upstream Connector for DefectDojo" +weight: 14 +audience: pro +--- +The Akto connector imports **API security testing findings** from Akto. DefectDojo creates a Record for each Akto **API collection**. + +#### Prerequisites + +An Akto **API key**, created under **Settings \> Integrations \> Akto APIs** in the Akto dashboard. It is sent as the `X-API-KEY` header and is never logged. + +#### Connector Mappings + +1. Enter `https://app.akto.io` in the **Location** field for Akto's SaaS platform. If you run Akto self\-hosted, enter your own dashboard URL instead. +2. Enter your Akto API key in the **API Key** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each API collection becomes a Record. Only **open** issues are imported, so issues you resolve in Akto are reflected in DefectDojo on the next Sync. Both Akto SaaS and self\-hosted deployments use this connector — the only difference is the **Location** you supply. diff --git a/docs/content/connectors/toolreference/alert_logic.md b/docs/content/connectors/toolreference/alert_logic.md new file mode 100644 index 00000000000..3e1af8f8e78 --- /dev/null +++ b/docs/content/connectors/toolreference/alert_logic.md @@ -0,0 +1,21 @@ +--- +title: "Alert Logic" +description: "How to set up the Alert Logic Upstream Connector for DefectDojo" +weight: 15 +audience: pro +--- +The Alert Logic connector imports **vulnerability exposures** from your Alert Logic account. DefectDojo creates a Record for each Alert Logic **deployment**, with no per\-deployment configuration required. + +#### Prerequisites + +An Alert Logic **access key ID and secret key**, created under **Configure \> API Keys**. DefectDojo exchanges them for a short\-lived session token on each Sync; neither the secret nor the token is ever logged. + +#### Connector Mappings + +1. Enter your region's API URL in the **Location** field — `https://api.cloudinsight.alertlogic.com` (US) or `https://api.cloudinsight.alertlogic.co.uk` (UK). Alert Logic is region\-partitioned, so this must match the region your account lives in. +2. Enter the access key ID in the **Access Key ID** field. +3. Enter the secret in the **Secret Key** field. +4. Optionally, enter an **Account ID** to override the account the credentials authenticate into. This is intended for managed\-service parent accounts operating on a child account. +5. Optionally, set a **Minimum Severity** to limit which findings are imported. + +This connector imports **vulnerability exposures only** — MDR incidents are deliberately out of scope. diff --git a/docs/content/connectors/toolreference/anchore_enterprise.de.md b/docs/content/connectors/toolreference/anchore_enterprise.de.md new file mode 100644 index 00000000000..f91f8643ad1 --- /dev/null +++ b/docs/content/connectors/toolreference/anchore_enterprise.de.md @@ -0,0 +1,14 @@ +--- +title: "Anchore" +description: "Einrichtung des Anchore Upstream-Connectors für DefectDojo" +weight: 16 +audience: pro +--- +Der Anchore-Connector verwendet das API-Token eines Benutzers, um Daten von Anchore Enterprise abzurufen. Produkte werden anhand von „Applications" zugeordnet und ermittelt, die sich in Anchore aus mehreren Images zusammensetzen - siehe [Anchore Enterprise Documentation](https://docs.anchore.com/current/docs/sbom_management/application_groups/application_management_anchorectl/) für weitere Informationen. + +#### Connector-Zuordnungen + +1. Die Anchore-URL in das Feld **Location**: Dies ist die URL, unter der Sie auf Anchore zugreifen. +2. Geben Sie einen gültigen API-Schlüssel in das Feld Secret ein. Dies ist der API-Schlüssel, der mit Ihrem Burp-Service-Konto verknüpft ist. + +Weitere Informationen zum Erstellen eines Tokens für Anchore finden Sie in der offiziellen [Anchore-Dokumentation](https://docs.anchore.com/current/docs/). diff --git a/docs/content/connectors/toolreference/anchore_enterprise.es.md b/docs/content/connectors/toolreference/anchore_enterprise.es.md new file mode 100644 index 00000000000..a0229b8a702 --- /dev/null +++ b/docs/content/connectors/toolreference/anchore_enterprise.es.md @@ -0,0 +1,14 @@ +--- +title: "Anchore" +description: "Cómo configurar el Conector Upstream de Anchore para DefectDojo" +weight: 16 +audience: pro +--- +El conector de Anchore usa el token de API de un usuario para extraer datos de Anchore Enterprise. Los Productos se asignarán y descubrirán en función de las "Applications", que se componen de varias Images en Anchore - consulte la [documentación de Anchore Enterprise](https://docs.anchore.com/current/docs/sbom_management/application_groups/application_management_anchorectl/) para obtener más información. + +#### Asignaciones del conector + +1. La URL de Anchore en el campo **Location**: esta es la URL donde accede a Anchore. +2. Ingrese una API Key válida en el campo Secret. Esta es la clave de API asociada con su cuenta de servicio de Burp. + +Consulte la [documentación oficial de Anchore](https://docs.anchore.com/current/docs/) para obtener más información sobre cómo crear un token para Anchore. diff --git a/docs/content/connectors/toolreference/anchore_enterprise.fr.md b/docs/content/connectors/toolreference/anchore_enterprise.fr.md new file mode 100644 index 00000000000..35ded3fc0ed --- /dev/null +++ b/docs/content/connectors/toolreference/anchore_enterprise.fr.md @@ -0,0 +1,14 @@ +--- +title: "Anchore" +description: "Comment configurer le Connecteur Upstream Anchore pour DefectDojo" +weight: 16 +audience: pro +--- +Le connecteur Anchore utilise le jeton API d'un utilisateur pour récupérer des données depuis Anchore Enterprise. Les Produits sont mappés et découverts à partir des « Applications », qui sont composées de plusieurs Images dans Anchore - voir la [documentation Anchore Enterprise](https://docs.anchore.com/current/docs/sbom_management/application_groups/application_management_anchorectl/) pour plus d'informations. + +#### Mappages du Connecteur + +1. L'URL d'Anchore dans le champ **Location** : il s'agit de l'URL à laquelle vous accédez à Anchore. +2. Saisissez une clé API valide dans le champ Secret. Il s'agit de la clé API associée à votre compte de service Burp. + +Consultez la [documentation officielle d'Anchore](https://docs.anchore.com/current/docs/) pour plus d'informations sur la création d'un jeton pour Anchore. diff --git a/docs/content/connectors/toolreference/anchore_enterprise.ja.md b/docs/content/connectors/toolreference/anchore_enterprise.ja.md new file mode 100644 index 00000000000..13031bacf5f --- /dev/null +++ b/docs/content/connectors/toolreference/anchore_enterprise.ja.md @@ -0,0 +1,14 @@ +--- +title: "Anchore" +description: "DefectDojo で Anchore の Upstream Connector をセットアップする方法" +weight: 16 +audience: pro +--- +Anchore コネクタはユーザーの API トークンを使用して Anchore Enterprise からデータを取得します。製品は「Applications」に基づいてマッピング・検出されます。Applications は Anchore 内の複数の Image で構成されます。詳細は [Anchore Enterprise Documentation](https://docs.anchore.com/current/docs/sbom_management/application_groups/application_management_anchorectl/) を参照してください。 + +#### Connector Mappings + +1. **Location** フィールドに Anchore の URL を入力します。これは Anchore にアクセスする際の URL です。 +2. Secret フィールドに有効な API Key を入力します。これは Burp Service アカウントに紐づく API キーです。 + +Anchore のトークン作成に関する詳細は、公式の [Anchore documentation](https://docs.anchore.com/current/docs/) を参照してください。 diff --git a/docs/content/connectors/toolreference/anchore_enterprise.md b/docs/content/connectors/toolreference/anchore_enterprise.md new file mode 100644 index 00000000000..6f54484b78e --- /dev/null +++ b/docs/content/connectors/toolreference/anchore_enterprise.md @@ -0,0 +1,14 @@ +--- +title: "Anchore Enterprise" +description: "How to set up the Anchore Enterprise Upstream Connector for DefectDojo" +weight: 16 +audience: pro +--- +The Anchore connector uses a user's API token to pull data from Anchore Enterprise. Assets will be mapped and discovered based on "Applications", which are composed of multiple Images in Anchore - see [Anchore Enterprise Documentation](https://docs.anchore.com/current/docs/sbom_management/application_groups/application_management_anchorectl/) for more information. + +#### Connector Mappings + +1. The Anchore URL in the **Location** field: this is the URL where you access the Anchore. +2. Enter a valid API Key in the Secret field. This is the API key associated with your Burp Service account. + +See the official [Anchore documentation](https://docs.anchore.com/current/docs/) for more information on creating a token for Anchore. diff --git a/docs/content/connectors/toolreference/appcheck.md b/docs/content/connectors/toolreference/appcheck.md new file mode 100644 index 00000000000..a0afc6b601e --- /dev/null +++ b/docs/content/connectors/toolreference/appcheck.md @@ -0,0 +1,21 @@ +--- +title: "AppCheck" +description: "How to set up the AppCheck Upstream Connector for DefectDojo" +weight: 17 +audience: pro +--- +The AppCheck connector imports **DAST vulnerability findings** from the AppCheck NG platform. DefectDojo discovers every scan on your account and creates a Record for each **scan** — there is no per\-scan configuration. + +#### Prerequisites + +An AppCheck **API key**, from the **API** section of your AppCheck account. + +**Treat this key like a password.** AppCheck sends it as part of the request path rather than in a header, so it forms part of the URL. DefectDojo registers the key for redaction and never logs a full request URL, but apply the same care wherever else you store it. + +#### Connector Mappings + +1. Enter `https://api.appcheck-ng.com` in the **Location** field. +2. Enter your AppCheck API key in the **API Key** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each scan becomes a Record, and its findings come from that scan's most recent **completed** run — so a scan that is still in flight never truncates the finding set. AppCheck fans a scan out across several engines (its own scanner, **Nmap**, and **OpenVAS**) and normalizes the output, so each finding carries the engine that reported it. diff --git a/docs/content/connectors/toolreference/aqua_security.md b/docs/content/connectors/toolreference/aqua_security.md new file mode 100644 index 00000000000..ad415721377 --- /dev/null +++ b/docs/content/connectors/toolreference/aqua_security.md @@ -0,0 +1,20 @@ +--- +title: "Aqua Security" +description: "How to set up the Aqua Security Upstream Connector for DefectDojo" +weight: 18 +audience: pro +--- +The Aqua Security connector imports **container image and workload vulnerability findings** across your whole Aqua tenant. DefectDojo creates a Record for each scanned **registry/repository**. + +#### Prerequisites + +An **admin-generated** Aqua **API key and secret**, created under **Account Management \> API Keys**. The secret is shown only once when the key is generated, so capture it at that point. Neither value is ever logged. + +#### Connector Mappings + +1. Enter your Aqua tenant URL in the **Location** field — `https://.cloud.aquasec.com`. DefectDojo appends the API path itself. +2. Enter the API key in the **API Key** field. +3. Enter the API secret in the **API Secret** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each scanned registry/repository becomes a Record, and its image and workload vulnerabilities are imported as findings. diff --git a/docs/content/connectors/toolreference/automox.md b/docs/content/connectors/toolreference/automox.md new file mode 100644 index 00000000000..51edad44d19 --- /dev/null +++ b/docs/content/connectors/toolreference/automox.md @@ -0,0 +1,21 @@ +--- +title: "Automox" +description: "How to set up the Automox Upstream Connector for DefectDojo" +weight: 19 +audience: pro +--- +The Automox connector imports **missing patches** from Automox. DefectDojo creates a Record for each Automox **device group**. + +**A finding here is a missing patch**, not a scanner result — this connector reports patches Automox is waiting to apply, so use it to track patch coverage rather than as a vulnerability scanner. + +#### Prerequisites + +An Automox **API key**, from **Settings \> API** in the Automox console. It is sent as a bearer token and never logged. + +#### Connector Mappings + +1. Enter `https://console.automox.com/api` in the **Location** field. +2. Enter your Automox API key in the **API Key** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each device group becomes a Record, carrying the patches awaiting installation on the devices in that group. diff --git a/docs/content/connectors/toolreference/azure_devops.de.md b/docs/content/connectors/toolreference/azure_devops.de.md new file mode 100644 index 00000000000..c6d28248c96 --- /dev/null +++ b/docs/content/connectors/toolreference/azure_devops.de.md @@ -0,0 +1,23 @@ +--- +title: "Azure DevOps" +description: "Einrichtung des Azure DevOps Upstream-Connectors für DefectDojo" +weight: 20 +audience: pro +--- +Der Azure-DevOps-Connector ist ein **Asset-Connector**: Er zählt die Git-Repositories in jedem Projekt Ihrer Azure-DevOps-Organisation auf und erstellt für jedes Repository ein DefectDojo-Asset, gruppiert in Organisationen nach Azure-DevOps-Projekt. Es werden keine Befunde importiert. + +#### Voraussetzungen + +Sie benötigen ein Personal Access Token (PAT) für die Organisation. Wir empfehlen, das Token von einem dedizierten Service-Konto aus zu erstellen. Es werden nur Lese-Scopes benötigt: + +1. Öffnen Sie in Azure DevOps **User settings \> Personal access tokens \> New Token**. +2. Klicken Sie auf **Show all scopes** und wählen Sie dann **Code: Read** und **Project and Team: Read**. + +Nur Azure DevOps Services (dev.azure.com) wird unterstützt; der On-Premise Azure DevOps Server wird derzeit nicht unterstützt. + +#### Connector-Zuordnungen + +1. Geben Sie Ihre Organisations-URL in das Feld **Location** ein: `https://dev.azure.com/{your-organization}`. Auch die alten `https://{your-organization}.visualstudio.com`-URLs werden akzeptiert, und zusätzliche Pfadsegmente (zum Beispiel ein Link zu einem bestimmten Projekt) werden ignoriert. +2. Geben Sie das PAT in das Feld **Secret** ein. + +Jedes Repository wird zu einem nach dem Repository benannten Eintrag, gruppiert nach seinem Azure-DevOps-**Projekt**. Deaktivierte Repositories werden übersprungen; das Deaktivieren oder Löschen eines Repositorys markiert seinen Eintrag beim nächsten Sync daher als `MISSING`. diff --git a/docs/content/connectors/toolreference/azure_devops.es.md b/docs/content/connectors/toolreference/azure_devops.es.md new file mode 100644 index 00000000000..fb070c3ae91 --- /dev/null +++ b/docs/content/connectors/toolreference/azure_devops.es.md @@ -0,0 +1,23 @@ +--- +title: "Azure DevOps" +description: "Cómo configurar el Conector Upstream de Azure DevOps para DefectDojo" +weight: 20 +audience: pro +--- +El conector de Azure DevOps es un **Conector de activos**: enumera los repositorios git de cada proyecto de su organización de Azure DevOps y crea un Activo de DefectDojo para cada repositorio, agrupados en Organizaciones según el proyecto de Azure DevOps. No se importa ningún hallazgo. + +#### Prerrequisitos + +Necesitará un Personal Access Token (PAT) para la organización. Recomendamos generar el token desde una cuenta de servicio dedicada. Solo se requieren ámbitos de lectura: + +1. En Azure DevOps, abra **User settings \> Personal access tokens \> New Token**. +2. Haga clic en **Show all scopes** y, a continuación, seleccione **Code: Read** y **Project and Team: Read**. + +Solo se admite Azure DevOps Services (dev.azure.com); actualmente no se admite Azure DevOps Server on-premise. + +#### Asignaciones del conector + +1. Ingrese la URL de su organización en el campo **Location**: `https://dev.azure.com/{your-organization}`. También se aceptan las URL heredadas `https://{your-organization}.visualstudio.com`, y cualquier segmento de ruta adicional (por ejemplo, un enlace a un proyecto específico) se ignora. +2. Ingrese el PAT en el campo **Secret**. + +Cada repositorio se convierte en un Registro con el nombre del repositorio, agrupado por su **proyecto** de Azure DevOps. Los repositorios deshabilitados se omiten, por lo que deshabilitar o eliminar un repositorio marca su Registro como `MISSING` en la siguiente Sync. diff --git a/docs/content/connectors/toolreference/azure_devops.fr.md b/docs/content/connectors/toolreference/azure_devops.fr.md new file mode 100644 index 00000000000..5ec55bc5425 --- /dev/null +++ b/docs/content/connectors/toolreference/azure_devops.fr.md @@ -0,0 +1,23 @@ +--- +title: "Azure DevOps" +description: "Comment configurer le Connecteur Upstream Azure DevOps pour DefectDojo" +weight: 20 +audience: pro +--- +Le connecteur Azure DevOps est un **Connecteur d'actifs** : il énumère les dépôts git de chaque projet de votre organisation Azure DevOps et crée un Actif DefectDojo pour chaque dépôt, regroupé en Organisations par projet Azure DevOps. Aucune constatation n'est importée. + +#### Prérequis + +Vous aurez besoin d'un jeton d'accès personnel (PAT) pour l'organisation. Nous recommandons de générer ce jeton depuis un compte de service dédié. Seuls des scopes en lecture sont nécessaires : + +1. Dans Azure DevOps, ouvrez **User settings \> Personal access tokens \> New Token**. +2. Cliquez sur **Show all scopes**, puis sélectionnez **Code: Read** et **Project and Team: Read**. + +Seul Azure DevOps Services (dev.azure.com) est pris en charge ; Azure DevOps Server sur site n'est pas pris en charge pour le moment. + +#### Mappages du Connecteur + +1. Saisissez l'URL de votre organisation dans le champ **Location** : `https://dev.azure.com/{your-organization}`. Les URL héritées `https://{your-organization}.visualstudio.com` sont également acceptées, et tout segment de chemin supplémentaire (par exemple, un lien vers un projet spécifique) est ignoré. +2. Saisissez le PAT dans le champ **Secret**. + +Chaque dépôt devient un Enregistrement portant le nom du dépôt, regroupé par **projet** Azure DevOps. Les dépôts désactivés sont ignorés, si bien que désactiver ou supprimer un dépôt marque son Enregistrement comme `MISSING` lors de la prochaine synchronisation. diff --git a/docs/content/connectors/toolreference/azure_devops.ja.md b/docs/content/connectors/toolreference/azure_devops.ja.md new file mode 100644 index 00000000000..0b4081b199a --- /dev/null +++ b/docs/content/connectors/toolreference/azure_devops.ja.md @@ -0,0 +1,23 @@ +--- +title: "Azure DevOps" +description: "DefectDojo で Azure DevOps の Upstream Connector をセットアップする方法" +weight: 20 +audience: pro +--- +Azure DevOps コネクタは**Asset Connector**です。Azure DevOps 組織内のすべてのプロジェクトにある git リポジトリを列挙し、リポジトリごとに DefectDojo のアセットを作成し、Azure DevOps のプロジェクト単位で組織にグループ化します。検出事項はインポートされません。 + +#### Prerequisites + +組織用の Personal Access Token(PAT)が必要です。専用のサービスアカウントからトークンを作成することをお勧めします。必要なのは読み取りスコープのみです。 + +1. Azure DevOps で **User settings \> Personal access tokens \> New Token** を開きます。 +2. **Show all scopes** をクリックし、**Code: Read** と **Project and Team: Read** を選択します。 + +対応しているのは Azure DevOps Services(dev.azure.com)のみです。オンプレミスの Azure DevOps Server には現時点で対応していません。 + +#### Connector Mappings + +1. **Location** フィールドに組織の URL を入力します: `https://dev.azure.com/{your-organization}`。従来の `https://{your-organization}.visualstudio.com` 形式の URL も受け付けられ、余分なパスセグメント(例えば特定プロジェクトへのリンク)は無視されます。 +2. **Secret** フィールドに PAT を入力します。 + +各リポジトリは、そのリポジトリ名を冠したレコードとなり、Azure DevOps の**プロジェクト**単位でグループ化されます。無効化されたリポジトリはスキップされるため、リポジトリを無効化または削除すると、次の Sync でそのレコードは `MISSING` としてフラグされます。 diff --git a/docs/content/connectors/toolreference/azure_devops.md b/docs/content/connectors/toolreference/azure_devops.md new file mode 100644 index 00000000000..3393d4c4594 --- /dev/null +++ b/docs/content/connectors/toolreference/azure_devops.md @@ -0,0 +1,23 @@ +--- +title: "Azure DevOps" +description: "How to set up the Azure DevOps Upstream Connector for DefectDojo" +weight: 20 +audience: pro +--- +The Azure DevOps connector is an **Asset Connector**: it enumerates the git repositories in every project of your Azure DevOps organization and creates a DefectDojo Asset for each repository, grouped into Organizations by Azure DevOps project. No findings are imported. + +#### Prerequisites + +You will need a Personal Access Token (PAT) for the organization. We recommend creating the token from a dedicated service account. Only read scopes are required: + +1. In Azure DevOps, open **User settings \> Personal access tokens \> New Token**. +2. Click **Show all scopes**, then select **Code: Read** and **Project and Team: Read**. + +Only Azure DevOps Services (dev.azure.com) is supported; on-premise Azure DevOps Server is not supported at this time. + +#### Connector Mappings + +1. Enter your organization URL in the **Location** field: `https://dev.azure.com/{your-organization}`. Legacy `https://{your-organization}.visualstudio.com` URLs are also accepted, and any extra path segments (for example, a link to a specific project) are ignored. +2. Enter the PAT in the **Secret** field. + +Each repository becomes a Record named after the repository, grouped by its Azure DevOps **project**. Disabled repositories are skipped, so disabling or deleting a repository flags its Record as `MISSING` on the next Sync. diff --git a/docs/content/connectors/toolreference/azure_devops_boards.de.md b/docs/content/connectors/toolreference/azure_devops_boards.de.md new file mode 100644 index 00000000000..22e315e5695 --- /dev/null +++ b/docs/content/connectors/toolreference/azure_devops_boards.de.md @@ -0,0 +1,43 @@ +--- +title: "Azure DevOps Boards" +description: "Einrichtung des Azure DevOps Boards Downstream-Connectors für DefectDojo" +weight: 21 +audience: pro +--- +### Instanz-Einrichtung + +- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf Ihre Azure-URL gesetzt werden, zum Beispiel `https://dev.azure.com/{your organization}` +- **Token** sollte auf ein persönliches Zugriffstoken aus Azure gesetzt werden. + +Die Authentifizierung bei Azure DevOps erfordert ein [persönliches Zugriffstoken](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows) +mit der Berechtigung „Read, Write and Manage“ für „Work Items“ im Azure-Projekt, mit dem Sie arbeiten möchten. + +### Issue-Tracker-Zuordnung + +Diese Angaben legen fest, wie DefectDojo Attribute von Befunden oder Befundgruppen einem bestimmten Projekt in Azure DevOps zuordnet: + +#### Details zur Issue-Tracker-Zuordnung + +Das Feld `Project ID` entspricht dem Namen oder der ID des Projekts in Azure. + +#### Details zur Schweregrad-Zuordnung + +Die Attribute im Formular sind als Standardwerte vorbelegt und lauten wie folgt: + +- **Name des Schweregrad-Felds**: `/fields/Microsoft.VSTS.Common.Priority` +- **Info-Zuordnung**: `4` +- **Niedrig-Zuordnung**: `4` +- **Mittel-Zuordnung**: `3` +- **Hoch-Zuordnung**: `2` +- **Kritisch-Zuordnung**: `1` + +#### Details zur Status-Zuordnung + +Die Attribute im Formular sind als Standardwerte vorbelegt und lauten wie folgt: + +- **Name des Status-Felds**: `/fields/System.State` +- **Aktiv-Zuordnung**: `To Do` +- **Geschlossen-Zuordnung**: `Done` +- **Falsch-positiv-Zuordnung**: `Done` +- **Risiko-akzeptiert-Zuordnung**: `Done` diff --git a/docs/content/connectors/toolreference/azure_devops_boards.es.md b/docs/content/connectors/toolreference/azure_devops_boards.es.md new file mode 100644 index 00000000000..1f3c1f5bc0c --- /dev/null +++ b/docs/content/connectors/toolreference/azure_devops_boards.es.md @@ -0,0 +1,43 @@ +--- +title: "Azure DevOps Boards" +description: "Cómo configurar el Conector Downstream de Azure DevOps Boards para DefectDojo" +weight: 21 +audience: pro +--- +### Configuración de la instancia + +- **Label** debe ser la etiqueta que desea usar para identificar esta integración. +- **Location** debe establecerse en su URL de Azure - por ejemplo `https://dev.azure.com/{your organization}` +- **Token** debe establecerse en un token de acceso personal de Azure. + +La autenticación con Azure DevOps requiere un [token de acceso personal](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows) +con permisos establecidos en "Read, Write and Manage" para "Work Items" en el proyecto de Azure con el que desea trabajar. + +### Mapeo del Issue Tracker + +Estos detalles determinan cómo DefectDojo mapeará los atributos de un Hallazgo o Grupo de Hallazgos a un Proyecto dado en Azure DevOps: + +#### Detalles del mapeo del Issue Tracker + +El campo `Project ID` corresponde al nombre o al ID del proyecto en Azure. + +#### Detalles del mapeo de severidad + +Los atributos del formulario se proporcionan como valores predeterminados y son los siguientes: + +- **Severity Field Name**: `/fields/Microsoft.VSTS.Common.Priority` +- **Info Mapping**: `4` +- **Low Mapping**: `4` +- **Medium Mapping**: `3` +- **High Mapping**: `2` +- **Critical Mapping**: `1` + +#### Detalles del mapeo de estado + +Los atributos del formulario se proporcionan como valores predeterminados y son los siguientes: + +- **Status Field Name**: `/fields/System.State` +- **Active Mapping**: `To Do` +- **Closed Mapping**: `Done` +- **False Positive Mapping**: `Done` +- **Risk Accepted Mapping**: `Done` diff --git a/docs/content/connectors/toolreference/azure_devops_boards.fr.md b/docs/content/connectors/toolreference/azure_devops_boards.fr.md new file mode 100644 index 00000000000..24b700260d1 --- /dev/null +++ b/docs/content/connectors/toolreference/azure_devops_boards.fr.md @@ -0,0 +1,43 @@ +--- +title: "Azure DevOps Boards" +description: "Comment configurer le Connecteur Downstream Azure DevOps Boards pour DefectDojo" +weight: 21 +audience: pro +--- +### Configuration de l'instance + +- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur votre URL Azure - par exemple `https://dev.azure.com/{your organization}` +- **Token** doit être défini sur un jeton d'accès personnel Azure. + +L'authentification avec Azure DevOps nécessite un [jeton d'accès personnel](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows) +dont les autorisations sont définies sur « Read, Write and Manage » pour les « Work Items » du projet Azure avec lequel vous souhaitez travailler. + +### Mappage du suivi des tickets + +Ces informations déterminent la façon dont DefectDojo associe les attributs d'une Constatation ou d'un Groupe de constatations à un projet donné dans Azure DevOps : + +#### Détails du mappage du suivi des tickets + +Le champ `Project ID` correspond au nom ou à l'ID du projet dans Azure. + +#### Détails du mappage de la sévérité + +Les attributs du formulaire sont fournis par défaut et sont les suivants : + +- **Severity Field Name** : `/fields/Microsoft.VSTS.Common.Priority` +- **Info Mapping** : `4` +- **Low Mapping** : `4` +- **Medium Mapping** : `3` +- **High Mapping** : `2` +- **Critical Mapping** : `1` + +#### Détails du mappage du statut + +Les attributs du formulaire sont fournis par défaut et sont les suivants : + +- **Status Field Name** : `/fields/System.State` +- **Active Mapping** : `To Do` +- **Closed Mapping** : `Done` +- **False Positive Mapping** : `Done` +- **Risk Accepted Mapping** : `Done` diff --git a/docs/content/connectors/toolreference/azure_devops_boards.ja.md b/docs/content/connectors/toolreference/azure_devops_boards.ja.md new file mode 100644 index 00000000000..072ca9acd27 --- /dev/null +++ b/docs/content/connectors/toolreference/azure_devops_boards.ja.md @@ -0,0 +1,42 @@ +--- +title: "Azure DevOps Boards" +description: "DefectDojo で Azure DevOps Boards のダウンストリームコネクタをセットアップする方法" +weight: 21 +audience: pro +--- +### Instance Setup + +- **Label** は、この統合を識別するために使用したいラベルを設定します。 +- **Location** は、Azure の URL を設定します。例: `https://dev.azure.com/{your organization}` +- **Token** は、Azure のパーソナルアクセストークンを設定します。 + +Azure DevOps での認証には、作業対象の Azure プロジェクトの「Work Items」に対して「Read, Write and Manage」権限を持つ[パーソナルアクセストークン](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows)が必要です。 + +### Issue Tracker Mapping + +これらの項目は、DefectDojo が Finding または Finding Group の属性を Azure DevOps の該当プロジェクトにどのようにマッピングするかを指定します。 + +#### Issue Tracker Mapping Details + +`Project ID` フィールドには、Azure における対象プロジェクトの名前または ID を指定します。 + +#### Severity Mapping Details + +フォームの各項目にはデフォルト値が設定されており、内容は以下のとおりです。 + +- **Severity Field Name**: `/fields/Microsoft.VSTS.Common.Priority` +- **Info Mapping**: `4` +- **Low Mapping**: `4` +- **Medium Mapping**: `3` +- **High Mapping**: `2` +- **Critical Mapping**: `1` + +#### Status Mapping Details + +フォームの各項目にはデフォルト値が設定されており、内容は以下のとおりです。 + +- **Status Field Name**: `/fields/System.State` +- **Active Mapping**: `To Do` +- **Closed Mapping**: `Done` +- **False Positive Mapping**: `Done` +- **Risk Accepted Mapping**: `Done` diff --git a/docs/content/connectors/toolreference/azure_devops_boards.md b/docs/content/connectors/toolreference/azure_devops_boards.md new file mode 100644 index 00000000000..1aeaf02f1de --- /dev/null +++ b/docs/content/connectors/toolreference/azure_devops_boards.md @@ -0,0 +1,43 @@ +--- +title: "Azure DevOps Boards" +description: "How to set up the Azure DevOps Boards Downstream Connector for DefectDojo" +weight: 21 +audience: pro +--- +### Instance Setup + +- **Label** should be the label that you want to use to identify this integration. +- **Location** should be set to your Azure URL - for example `https://dev.azure.com/{your organization}` +- **Token** should be set to a personal access token from Azure. + +Authentication with Azure DevOps requires a [personal access token](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows) +with permissions set to "Read, Write and Manage" for "Work Items" for the Azure Project that you wish to work with. + +### Issue Tracker Mapping + +These details dictate how DefectDojo will map Finding or Finding Group attributes to a given Project in Azure DevOps: + +#### Issue Tracker Mapping Details + +The `Project ID` field corresponds to the name or the ID of the Project in Azure. + +#### Severity Mapping Details + +The attributes in the form are supplied as defaults, and are as follows: + +- **Severity Field Name**: `/fields/Microsoft.VSTS.Common.Priority` +- **Info Mapping**: `4` +- **Low Mapping**: `4` +- **Medium Mapping**: `3` +- **High Mapping**: `2` +- **Critical Mapping**: `1` + +#### Status Mapping Details + +The attributes in the form are supplied as defaults and are as follows: + +- **Status Field Name**: `/fields/System.State` +- **Active Mapping**: `To Do` +- **Closed Mapping**: `Done` +- **False Positive Mapping**: `Done` +- **Risk Accepted Mapping**: `Done` diff --git a/docs/content/connectors/toolreference/backstage.de.md b/docs/content/connectors/toolreference/backstage.de.md new file mode 100644 index 00000000000..72c7d8f38ea --- /dev/null +++ b/docs/content/connectors/toolreference/backstage.de.md @@ -0,0 +1,63 @@ +--- +title: "Backstage" +description: "Einrichtung des Backstage Upstream-Connectors für DefectDojo" +weight: 22 +audience: pro +--- +Der Backstage-Connector ist ein **Asset-Connector**: Anstatt Befunde zu importieren, überträgt er Ihren [Backstage](https://backstage.io)-Software-Katalog in DefectDojo und hält Ihre Produkthierarchie und Team-Zuständigkeit damit synchron. Er ist für Organisationen konzipiert, die ihr Service-Inventar und ihre Organisationsstruktur in Backstage pflegen und möchten, dass DefectDojo diese Struktur widerspiegelt, statt sie manuell zu pflegen. + +#### Was zugeordnet wird + +| Backstage | DefectDojo | +|---|---| +| **System** | Produkttyp (Components ohne System werden unter einem konfigurierbaren Produkttyp „Backstage / Uncategorized" gruppiert) | +| **Component** | Produkt — benannt nach dem `title` der Entität (Rückgriff auf `name`), mit der Katalogbeschreibung | +| **Owning Group** (`ownedBy`-Beziehung) | Eine mit dem Produkt verknüpfte DefectDojo-Gruppe (Standardrolle: Maintainer, konfigurierbar) | +| **Owner email** (E-Mail des Gruppenprofils oder E-Mail eines User-Owners) | Ein Produktmitglied, sofern bereits ein DefectDojo-Benutzer mit dieser E-Mail-Adresse existiert (es werden nie Benutzer angelegt) | +| `metadata.tags`, `spec.type`, `spec.lifecycle`, Namespace, Domain | Produkt-Tags mit dem Präfix `backstage:` | +| `metadata.annotations` | Wird am Eintrag gespeichert (begrenzt); ausgewählte Annotationen können über **Annotation Mappings** zu vollwertigen Attributen oder Tags hochgestuft werden | + +Einträge werden über die vom Server vergebene `metadata.uid` der Entität identifiziert, sodass Umbenennungen in Backstage das zugeordnete Produkt beim nächsten Sync **an Ort und Stelle** aktualisieren — keine Duplikate. Der Produktname folgt stets dem Katalog: Um ein von diesem Connector verwaltetes Produkt umzubenennen, benennen Sie die Component in Backstage um (eine Umbenennung auf DefectDojo-Seite oder ein bei der manuellen Zuordnung vergebener eigener Name wird beim nächsten Sync auf den Katalognamen zurückgesetzt, sofern dies nicht mit einem anderen Produkt kollidieren würde). Eigentümerwechsel verschieben die Gruppenzuordnung des Produkts. Components, die aus dem Katalog verschwinden (oder mit der Annotation `backstage.io/orphan` gekennzeichnet sind), werden als **MISSING** markiert — DefectDojo löscht nie von sich aus ein Produkt. Domain- und Group-Hierarchie (übergeordnete Teams) werden nur als Tags/Metadaten erfasst; sie erzeugen keine zusätzlichen Hierarchieebenen. + +#### Voraussetzungen + +Der Connector authentifiziert sich mit einem **statischen externen Zugriffstoken** gegenüber dem Backstage-Backend. Definieren Sie in Ihrer Backstage-App-Konfiguration ein Token und beschränken Sie es (empfohlen) auf das Catalog-Plugin: + +```yaml +backend: + auth: + externalAccess: + - type: static + options: + token: ${DEFECTDOJO_BACKSTAGE_TOKEN} + subject: defectdojo-connector + accessRestrictions: + - plugin: catalog +``` + +Generieren Sie ein starkes Zufallstoken (zum Beispiel mit `openssl rand -hex 32`) und speichern Sie es in der Umgebung Ihrer Backstage-Bereitstellung. Einzelheiten finden Sie in der [Backstage-Dokumentation zur Service-to-Service-Authentifizierung](https://backstage.io/docs/auth/service-to-service-auth). + +#### Connector-Zuordnungen + +1. Geben Sie Ihre **Backstage-Backend-Root-URL** in das Feld **Location** ein: zum Beispiel `https://backstage.example.com` (der Connector hängt `/api/catalog` an). Dies muss die **Backend**-URL sein, nicht die Frontend-Web-UI. +2. Geben Sie das statische externe Zugriffstoken in das Feld **Secret** ein. + +Optionale Felder (für die Standardwerte leer lassen): + +* **Namespaces** — kommagetrennte Katalog-Namespaces, die importiert werden sollen; bei leerem Feld werden alle Namespaces importiert. +* **Component Types** — kommagetrennte `spec.type`-Werte (z. B. `service,website`); bei leerem Feld werden alle Typen importiert. +* **Page Size** — Seitengröße der Katalogabfrage (1\-500, Standard 250). +* **TLS Verification** — nur auf `false` setzen, wenn Backstage ein Zertifikat verwendet, das DefectDojo nicht verifizieren kann (interne CA); nicht empfohlen. +* **Uncategorized Product Type** — der Produkttyp für Components ohne System (Standard `Backstage / Uncategorized`). +* **Owner Group Role** — die Rolle, die dem verantwortlichen Team bei zugeordneten Produkten gewährt wird (Standard `Maintainer`). +* **Annotation Mappings** — ein JSON-Objekt, das Annotationsschlüssel auf Namen von Eintragsattributen abbildet, oder auf `"tag"`, um eine Annotation als Produkt-Tag zu importieren, z. B. `{"github.com/project-slug": "GITHUB_PROJECT", "example.com/tier": "tag"}`. + +Bei aktiviertem **Auto\-Map** baut ein einziger Discover \+ Sync die vollständige Struktur aus Produkttyp/Produkt/Eigentümerschaft ohne manuelle Schritte auf. Bei deaktiviertem Auto\-Map erscheinen ermittelte Components als Einträge, die auf Ihre Zuordnungsentscheidung warten. + +#### Einschränkungen (v1) + +* Die **Group-Mitgliedschaft von Backstage wird nicht synchronisiert**: Der Connector erstellt/verknüpft das verantwortliche Team als DefectDojo-Gruppe, aber das Befüllen dieser Gruppe mit Benutzern bleibt Ihrem Identity-Provider oder Ihren Administratoren überlassen. +* Nur Components werden zu Produkten; APIs, Resources und Domains werden nicht als Assets importiert (Domains erscheinen als Tags). +* Tags und Annotationen werden normalisiert und begrenzt, um in die DefectDojo-Feldgrenzen zu passen (überlange Werte werden gekürzt). + +**Ein Hinweis zur umgekehrten Richtung:** Die Anzeige von DefectDojo-Befunden und -Bewertungen *innerhalb* von Backstage (auf Entitätsseiten) wäre ein naheliegender nächster Schritt, der als Backstage-Frontend-Plugin umgesetzt würde, das die DefectDojo-REST-API konsumiert — dies liegt bewusst außerhalb des Umfangs dieses Connectors, der ausschließlich Katalogdaten in DefectDojo überträgt. diff --git a/docs/content/connectors/toolreference/backstage.es.md b/docs/content/connectors/toolreference/backstage.es.md new file mode 100644 index 00000000000..210c4730234 --- /dev/null +++ b/docs/content/connectors/toolreference/backstage.es.md @@ -0,0 +1,63 @@ +--- +title: "Backstage" +description: "Cómo configurar el Conector Upstream de Backstage para DefectDojo" +weight: 22 +audience: pro +--- +El conector de Backstage es un **conector de activos**: en lugar de importar Hallazgos, extrae su Software Catalog de [Backstage](https://backstage.io) hacia DefectDojo y mantiene sincronizada su jerarquía de Productos y la propiedad de los equipos con ella. Está diseñado para organizaciones que mantienen su inventario de servicios y su estructura organizativa en Backstage y desean que DefectDojo refleje esa estructura en lugar de mantenerla manualmente. + +#### Qué se asigna + +| Backstage | DefectDojo | +|---|---| +| **System** | Tipo de producto (los Components sin System se agrupan bajo un Tipo de producto configurable "Backstage / Uncategorized") | +| **Component** | Producto — con el nombre tomado de la entidad `title` (o de `name` si no existe), junto con la descripción del catálogo | +| **Owning Group** (relación `ownedBy`) | Un Grupo de DefectDojo vinculado al Producto (rol predeterminado: Maintainer, configurable) | +| **Owner email** (correo del perfil del Group, o correo del propietario User) | Un miembro del Producto, cuando ya existe un usuario de DefectDojo con ese correo (nunca se crean usuarios) | +| `metadata.tags`, `spec.type`, `spec.lifecycle`, namespace, domain | Etiquetas de Producto con el prefijo `backstage:` | +| `metadata.annotations` | Se almacena en el Registro (con límite); ciertas anotaciones seleccionadas pueden promoverse a atributos de primera clase o a etiquetas mediante **Annotation Mappings** | + +Los Registros se identifican mediante el `metadata.uid` asignado por el servidor de la entidad, por lo que los cambios de nombre en Backstage actualizan el Producto asignado **en el mismo lugar** en la siguiente sincronización — sin duplicados. El nombre del Producto siempre sigue al catálogo: para cambiar el nombre de un Producto gestionado por este conector, cambie el nombre del Component en Backstage (un cambio de nombre realizado del lado de DefectDojo, o un nombre personalizado asignado durante la asignación manual, se concilia con el nombre del catálogo en la siguiente sincronización a menos que colisione con otro Producto). Los cambios de propiedad mueven la asignación de grupo del Producto. Los Components que desaparecen del catálogo (o que están marcados con la anotación `backstage.io/orphan`) se marcan como **MISSING** — DefectDojo nunca elimina un Producto por sí mismo. La jerarquía de Domain y Group (equipos superiores) se registra únicamente como etiquetas/metadatos; no crea niveles de jerarquía adicionales. + +#### Prerrequisitos + +El conector se autentica con un **token de acceso externo estático** frente al backend de Backstage. En la configuración de su aplicación Backstage, defina un token y (recomendado) restríjalo al plugin de catálogo: + +```yaml +backend: + auth: + externalAccess: + - type: static + options: + token: ${DEFECTDOJO_BACKSTAGE_TOKEN} + subject: defectdojo-connector + accessRestrictions: + - plugin: catalog +``` + +Genere un token aleatorio robusto (por ejemplo `openssl rand -hex 32`) y guárdelo en el entorno de su implementación de Backstage. Consulte la [documentación de autenticación servicio a servicio de Backstage](https://backstage.io/docs/auth/service-to-service-auth) para obtener más detalles. + +#### Asignaciones del conector + +1. Ingrese la **URL raíz del backend de Backstage** en el campo **Location**: por ejemplo `https://backstage.example.com` (el conector añade `/api/catalog`). Debe ser la URL del **backend**, no la de la interfaz web frontend. +2. Ingrese el token de acceso externo estático en el campo **Secret**. + +Campos opcionales (déjelos en blanco para usar los valores predeterminados): + +* **Namespaces** — namespaces del catálogo a importar, separados por comas; en blanco se importan todos los namespaces. +* **Component Types** — valores de `spec.type` separados por comas (p. ej. `service,website`); en blanco se importan todos los tipos. +* **Page Size** — tamaño de página para las consultas al catálogo (1\-500, valor predeterminado 250). +* **TLS Verification** — establézcalo en `false` solo si Backstage sirve un certificado que DefectDojo no puede verificar (CA interna); no se recomienda. +* **Uncategorized Product Type** — el Tipo de producto usado para los Components sin System (valor predeterminado `Backstage / Uncategorized`). +* **Owner Group Role** — el rol otorgado al equipo propietario en los Productos asignados (valor predeterminado `Maintainer`). +* **Annotation Mappings** — un objeto JSON que asigna claves de anotación a nombres de atributos del Registro, o a `"tag"` para importar una anotación como etiqueta de Producto, p. ej. `{"github.com/project-slug": "GITHUB_PROJECT", "example.com/tier": "tag"}`. + +Con **Auto\-Map** habilitado, un único Discover \+ Sync genera toda la estructura de Tipo de producto / Producto / propiedad sin pasos manuales. Con Auto\-Map deshabilitado, los Components descubiertos aparecen como Registros a la espera de su decisión de asignación. + +#### Limitaciones (v1) + +* La **pertenencia a Group de Backstage no se sincroniza**: el conector crea/vincula el equipo propietario como un Grupo de DefectDojo, pero completar los usuarios de ese grupo queda a cargo de su proveedor de identidad o de los administradores. +* Solo los Components se convierten en Productos; las APIs, Resources y Domains no se importan como activos (los domains aparecen como etiquetas). +* Las etiquetas y anotaciones se normalizan y se limitan para ajustarse a los límites de campo de DefectDojo (los valores demasiado grandes se truncan). + +**Una nota sobre la dirección inversa:** mostrar los hallazgos y las calificaciones de DefectDojo *dentro* de Backstage (en las páginas de entidad) es una extensión natural que se implementaría como un plugin de frontend de Backstage que consume la REST API de DefectDojo — queda deliberadamente fuera del alcance de este conector, que solo extrae datos del catálogo hacia DefectDojo. diff --git a/docs/content/connectors/toolreference/backstage.fr.md b/docs/content/connectors/toolreference/backstage.fr.md new file mode 100644 index 00000000000..29c6c9eb06c --- /dev/null +++ b/docs/content/connectors/toolreference/backstage.fr.md @@ -0,0 +1,63 @@ +--- +title: "Backstage" +description: "Comment configurer le Connecteur Upstream Backstage pour DefectDojo" +weight: 22 +audience: pro +--- +Le connecteur Backstage est un **connecteur d'actifs** : au lieu d'importer des constatations, il récupère votre Software Catalog [Backstage](https://backstage.io) dans DefectDojo et maintient votre hiérarchie de Produits et la propriété des équipes synchronisées avec celui-ci. Il est conçu pour les organisations qui maintiennent leur inventaire de services et leur structure organisationnelle dans Backstage et souhaitent que DefectDojo reflète cette structure au lieu de la maintenir manuellement. + +#### Ce qui est mappé + +| Backstage | DefectDojo | +|---|---| +| **System** | Type de produit (les Components sans System sont regroupés sous un Type de produit configurable « Backstage / Uncategorized ») | +| **Component** | Produit — nommé à partir du `title` de l'entité (avec repli sur `name`), avec la description du catalogue | +| **Owning Group** (relation `ownedBy`) | Un Groupe DefectDojo lié au Produit (rôle par défaut : Maintainer, configurable) | +| **Owner email** (e-mail du profil du Groupe, ou e-mail d'un propriétaire Utilisateur) | Un Membre de produit, lorsqu'un utilisateur DefectDojo possédant cet e-mail existe déjà (aucun utilisateur n'est jamais créé) | +| `metadata.tags`, `spec.type`, `spec.lifecycle`, namespace, domain | Étiquettes de produit sous un préfixe `backstage:` | +| `metadata.annotations` | Stocké sur l'Enregistrement (avec une limite) ; certaines annotations peuvent être promues en attributs de premier niveau ou en étiquettes via **Annotation Mappings** | + +Les Enregistrements sont indexés par le `metadata.uid` attribué par le serveur de l'entité ; ainsi, les renommages effectués dans Backstage mettent à jour le Produit mappé **sur place** lors de la prochaine synchronisation — sans doublons. Le nom du Produit suit toujours le catalogue : pour renommer un Produit géré par ce connecteur, renommez le Component dans Backstage (un renommage effectué côté DefectDojo, ou un nom personnalisé attribué lors du mappage manuel, est réconcilié avec le nom du catalogue lors de la prochaine synchronisation, sauf s'il entre en collision avec un autre Produit). Les changements de propriété déplacent l'affectation de groupe du Produit. Les Components qui disparaissent du catalogue (ou qui sont signalés par l'annotation `backstage.io/orphan`) sont marqués **MISSING** — DefectDojo ne supprime jamais un Produit de lui-même. La hiérarchie de Domain et de Group (équipes parentes) est uniquement enregistrée sous forme d'étiquettes/métadonnées ; elle ne crée pas de niveaux de hiérarchie supplémentaires. + +#### Prérequis + +Le connecteur s'authentifie à l'aide d'un **jeton d'accès externe statique** auprès du backend Backstage. Dans la configuration de votre application Backstage, définissez un jeton et (recommandé) restreignez-le au plugin catalog : + +```yaml +backend: + auth: + externalAccess: + - type: static + options: + token: ${DEFECTDOJO_BACKSTAGE_TOKEN} + subject: defectdojo-connector + accessRestrictions: + - plugin: catalog +``` + +Générez un jeton aléatoire fort (par exemple `openssl rand -hex 32`) et stockez-le dans l'environnement de votre déploiement Backstage. Consultez la [documentation Backstage sur l'authentification de service à service](https://backstage.io/docs/auth/service-to-service-auth) pour plus de détails. + +#### Mappages du Connecteur + +1. Saisissez l'**URL racine du backend Backstage** dans le champ **Location** : par exemple `https://backstage.example.com` (le connecteur ajoute `/api/catalog`). Il doit s'agir de l'URL du **backend**, et non de l'interface web frontend. +2. Saisissez le jeton d'accès externe statique dans le champ **Secret**. + +Champs facultatifs (laissez vide pour les valeurs par défaut) : + +* **Namespaces** — espaces de noms du catalogue à importer, séparés par des virgules ; vide importe tous les espaces de noms. +* **Component Types** — valeurs `spec.type` séparées par des virgules (par ex. `service,website`) ; vide importe tous les types. +* **Page Size** — taille de page pour les requêtes du catalogue (1\-500, valeur par défaut 250). +* **TLS Verification** — à définir sur `false` uniquement si Backstage sert un certificat que DefectDojo ne peut pas vérifier (AC interne) ; non recommandé. +* **Uncategorized Product Type** — le Type de produit utilisé pour les Components sans System (par défaut `Backstage / Uncategorized`). +* **Owner Group Role** — le rôle accordé à l'équipe propriétaire sur les Produits mappés (par défaut `Maintainer`). +* **Annotation Mappings** — un objet JSON associant des clés d'annotation à des noms d'attributs d'Enregistrement, ou à `"tag"` pour importer une annotation en tant qu'étiquette de Produit, par ex. `{"github.com/project-slug": "GITHUB_PROJECT", "example.com/tier": "tag"}`. + +Lorsque **Auto\-Map** est activé, un seul cycle Discover \+ Sync construit l'intégralité de la structure Type de produit / Produit / propriété sans étape manuelle. Lorsque Auto\-Map est désactivé, les Components découverts apparaissent comme des Enregistrements en attente de votre décision de mappage. + +#### Limitations (v1) + +* **L'appartenance aux Groups Backstage n'est pas synchronisée** : le connecteur crée/associe l'équipe propriétaire en tant que Groupe DefectDojo, mais le peuplement des utilisateurs de ce groupe est laissé à votre fournisseur d'identité ou à vos administrateurs. +* Seuls les Components deviennent des Produits ; les API, Resources et Domains ne sont pas importés comme actifs (les domains apparaissent sous forme d'étiquettes). +* Les étiquettes et annotations sont normalisées et limitées pour respecter les contraintes de longueur des champs DefectDojo (les valeurs trop longues sont tronquées). + +**Remarque sur le sens inverse :** afficher les constatations et les notes DefectDojo *à l'intérieur* de Backstage (sur les pages d'entité) constituerait un prolongement naturel, qui serait développé sous la forme d'un plugin frontend Backstage consommant l'API REST de DefectDojo — cela sort délibérément du périmètre de ce connecteur, qui se contente d'importer les données du catalogue dans DefectDojo. diff --git a/docs/content/connectors/toolreference/backstage.ja.md b/docs/content/connectors/toolreference/backstage.ja.md new file mode 100644 index 00000000000..5baf7bb0965 --- /dev/null +++ b/docs/content/connectors/toolreference/backstage.ja.md @@ -0,0 +1,63 @@ +--- +title: "Backstage" +description: "DefectDojo で Backstage の Upstream Connector をセットアップする方法" +weight: 22 +audience: pro +--- +Backstage コネクタは**asset connector**です。検出事項をインポートする代わりに、[Backstage](https://backstage.io) の Software Catalog を DefectDojo に取り込み、製品階層とチームの所有関係をそれと同期させます。サービスインベントリと組織構造を Backstage で管理しており、DefectDojo にはそれを手作業ではなく自動的にミラーしてほしい組織向けに設計されています。 + +#### What gets mapped + +| Backstage | DefectDojo | +|---|---| +| **System** | 製品タイプ(System を持たない Component は、設定可能な「Backstage / Uncategorized」製品タイプの下にグループ化されます) | +| **Component** | 製品 — エンティティの `title`(なければ `name` にフォールバック)から命名され、カタログの description が付与されます | +| **Owning Group**(`ownedBy` リレーション) | 製品に紐づく DefectDojo のグループ(デフォルトのロール: Maintainer、設定変更可能) | +| **Owner email**(グループプロファイルの email、または User オーナーの email) | 同じ email を持つ DefectDojo ユーザーが既に存在する場合、そのユーザーが製品メンバーになります(ユーザーが新規作成されることはありません) | +| `metadata.tags`、`spec.type`、`spec.lifecycle`、namespace、domain | `backstage:` プレフィックス付きの製品タグ | +| `metadata.annotations` | レコードに(上限付きで)保存されます。特定の annotation は **Annotation Mappings** を通じて第一級の属性やタグに昇格できます | + +レコードはエンティティのサーバー側で割り当てられた `metadata.uid` をキーとするため、Backstage 上でのリネームは次回の同期でマッピング済みの製品を**その場で**更新します。重複は発生しません。製品名は常にカタログに追従します。このコネクタが管理する製品をリネームするには、Backstage 上で Component をリネームしてください(DefectDojo 側でのリネーム、または手動マッピング時に付けたカスタム名は、他の製品と衝突しない限り、次回の同期でカタログ名に合わせて調整されます)。所有者の変更は、製品のグループ割り当てを移動させます。カタログから消えた(または `backstage.io/orphan` annotation が付いた)Component は **MISSING** としてマークされます。DefectDojo が自ら製品を削除することはありません。Domain と Group の階層(親チーム)はタグ/メタデータとしてのみ記録され、追加の階層レベルを作成することはありません。 + +#### Prerequisites + +このコネクタは、Backstage バックエンドに対して**静的な external access token**で認証します。Backstage アプリの設定でトークンを定義し、(推奨として)catalog プラグインに限定してください。 + +```yaml +backend: + auth: + externalAccess: + - type: static + options: + token: ${DEFECTDOJO_BACKSTAGE_TOKEN} + subject: defectdojo-connector + accessRestrictions: + - plugin: catalog +``` + +強力なランダムトークンを生成し(例えば `openssl rand -hex 32`)、Backstage デプロイの環境変数に保存してください。詳細は [Backstage service-to-service auth documentation](https://backstage.io/docs/auth/service-to-service-auth) を参照してください。 + +#### Connector Mappings + +1. **Location** フィールドに **Backstage バックエンドのルート URL** を入力します。例: `https://backstage.example.com`(コネクタが `/api/catalog` を自動的に付加します)。これは**バックエンド**の URL である必要があり、フロントエンドの Web UI ではありません。 +2. **Secret** フィールドに静的な external access token を入力します。 + +以下はオプションのフィールドです(デフォルトのままにする場合は空欄にしてください)。 + +* **Namespaces** — インポート対象のカタログ namespace をカンマ区切りで指定します。空欄の場合はすべての namespace をインポートします。 +* **Component Types** — `spec.type` の値をカンマ区切りで指定します(例: `service,website`)。空欄の場合はすべてのタイプをインポートします。 +* **Page Size** — カタログクエリのページサイズ(1\-500、デフォルト 250)。 +* **TLS Verification** — Backstage が DefectDojo で検証できない証明書(内部 CA)を提供している場合にのみ `false` に設定してください。推奨されません。 +* **Uncategorized Product Type** — System を持たない Component に使用される製品タイプ(デフォルト `Backstage / Uncategorized`)。 +* **Owner Group Role** — マッピングされた製品に対して所有チームに付与されるロール(デフォルト `Maintainer`)。 +* **Annotation Mappings** — annotation キーをレコード属性名にマッピングする JSON オブジェクト、または annotation を製品タグとしてインポートするための `"tag"`。例: `{"github.com/project-slug": "GITHUB_PROJECT", "example.com/tier": "tag"}`。 + +**Auto\-Map** を有効にすると、1 回の Discover \+ Sync で製品タイプ / 製品 / 所有関係の構造全体が手作業なしで構築されます。Auto-Map を無効にした場合、検出された Component はマッピング判断待ちのレコードとして表示されます。 + +#### Limitations (v1) + +* Backstage の**グループメンバーシップは同期されません**。コネクタは所有チームを DefectDojo のグループとして作成・リンクしますが、そのグループへのユーザーの登録は ID プロバイダや管理者に委ねられます。 +* Component のみが製品になります。API、Resource、Domain はアセットとしてインポートされません(Domain はタグとして反映されます)。 +* タグと annotation は DefectDojo のフィールド上限に収まるよう正規化・制限されます(過大な値は切り詰められます)。 + +**逆方向についての補足:** Backstage の内部(エンティティページ上)で DefectDojo の検出事項やグレードを表示することは、DefectDojo REST API を利用する Backstage フロントエンドプラグインとして構築するのが自然な発展形ですが、これはこのコネクタの意図的なスコープ外です。このコネクタはあくまでカタログデータを DefectDojo に取り込むだけです。 diff --git a/docs/content/connectors/toolreference/backstage.md b/docs/content/connectors/toolreference/backstage.md new file mode 100644 index 00000000000..cacc9dd26a1 --- /dev/null +++ b/docs/content/connectors/toolreference/backstage.md @@ -0,0 +1,63 @@ +--- +title: "Backstage" +description: "How to set up the Backstage Upstream Connector for DefectDojo" +weight: 22 +audience: pro +--- +The Backstage connector is an **asset connector**: instead of importing Findings, it pulls your [Backstage](https://backstage.io) Software Catalog into DefectDojo and keeps your Asset hierarchy and team ownership in sync with it. It is designed for organizations that maintain their service inventory and org structure in Backstage and want DefectDojo to mirror that structure instead of maintaining it by hand. + +#### What gets mapped + +| Backstage | DefectDojo | +|---|---| +| **System** | Organization (Components with no System are grouped under a configurable "Backstage / Uncategorized" Organization) | +| **Component** | Asset — named from the entity `title` (falling back to `name`), with the catalog description | +| **Owning Group** (`ownedBy` relation) | A DefectDojo Group linked to the Asset (default role: Maintainer, configurable) | +| **Owner email** (Group profile email, or a User owner's email) | An Asset Member, when a DefectDojo user with that email already exists (users are never created) | +| `metadata.tags`, `spec.type`, `spec.lifecycle`, namespace, domain | Asset tags under a `backstage:` prefix | +| `metadata.annotations` | Stored on the Record (bounded); selected annotations can be promoted to first-class attributes or tags via **Annotation Mappings** | + +Records are keyed by the entity's server\-assigned `metadata.uid`, so renames in Backstage update the mapped Asset **in place** on the next sync — no duplicates. The Asset name always tracks the catalog: to rename an Asset managed by this connector, rename the Component in Backstage (a DefectDojo\-side rename, or a custom name given during manual mapping, is reconciled back to the catalog name on the next sync unless it would collide with another Asset). Ownership changes move the Asset's group assignment. Components that disappear from the catalog (or are flagged with the `backstage.io/orphan` annotation) are marked **MISSING** — DefectDojo never deletes an Asset on its own. Domain and Group hierarchy (parent teams) are recorded as tags/metadata only; they do not create extra hierarchy levels. + +#### Prerequisites + +The connector authenticates with a **static external access token** against the Backstage backend. In your Backstage app config, define a token and (recommended) restrict it to the catalog plugin: + +```yaml +backend: + auth: + externalAccess: + - type: static + options: + token: ${DEFECTDOJO_BACKSTAGE_TOKEN} + subject: defectdojo-connector + accessRestrictions: + - plugin: catalog +``` + +Generate a strong random token (for example `openssl rand -hex 32`) and store it in your Backstage deployment's environment. See the [Backstage service-to-service auth documentation](https://backstage.io/docs/auth/service-to-service-auth) for details. + +#### Connector Mappings + +1. Enter your **Backstage backend root URL** in the **Location** field: for example `https://backstage.example.com` (the connector appends `/api/catalog`). This must be the **backend** URL, not the frontend web UI. +2. Enter the static external access token in the **Secret** field. + +Optional fields (leave blank for the defaults): + +* **Namespaces** — comma\-separated catalog namespaces to import; blank imports every namespace. +* **Component Types** — comma\-separated `spec.type` values (e.g. `service,website`); blank imports every type. +* **Page Size** — catalog query page size (1\-500, default 250). +* **TLS Verification** — set to `false` only if Backstage serves a certificate DefectDojo cannot verify (internal CA); not recommended. +* **Uncategorized Organization** — the Organization used for Components with no System (default `Backstage / Uncategorized`). +* **Owner Group Role** — the role granted to the owning team on mapped Assets (default `Maintainer`). +* **Annotation Mappings** — a JSON object mapping annotation keys to Record attribute names, or to `"tag"` to import an annotation as an Asset tag, e.g. `{"github.com/project-slug": "GITHUB_PROJECT", "example.com/tier": "tag"}`. + +With **Auto\-Map** enabled, a single Discover \+ Sync builds the complete Organization / Asset / ownership structure with no manual steps. With Auto\-Map disabled, discovered Components appear as Records awaiting your mapping decision. + +#### Limitations (v1) + +* Backstage **Group membership is not synchronized**: the connector creates/links the owning team as a DefectDojo Group, but populating that group's users is left to your identity provider or admins. +* Only Components become Assets; APIs, Resources, and Domains are not imported as assets (domains surface as tags). +* Tags and annotations are normalized and bounded to fit DefectDojo field limits (oversized values are truncated). + +**A note on the reverse direction:** displaying DefectDojo findings and grades *inside* Backstage (on entity pages) is a natural follow\-on that would be built as a Backstage frontend plugin consuming the DefectDojo REST API — it is deliberately out of scope for this connector, which only pulls catalog data into DefectDojo. diff --git a/docs/content/connectors/toolreference/beagle_security.md b/docs/content/connectors/toolreference/beagle_security.md new file mode 100644 index 00000000000..9bea15bba35 --- /dev/null +++ b/docs/content/connectors/toolreference/beagle_security.md @@ -0,0 +1,21 @@ +--- +title: "Beagle Security" +description: "How to set up the Beagle Security Upstream Connector for DefectDojo" +weight: 23 +audience: pro +--- +The Beagle Security connector imports **DAST findings** from Beagle Security. DefectDojo creates a Record for each **verified** application in your Beagle project tree — applications that have not been verified are not imported. + +#### Prerequisites + +A Beagle Security **personal access token**, sent as a bearer token. + +**Beagle access tokens expire.** When one does, Beagle returns an HTML error page rather than a JSON error, so an expired token can present as an unclear Sync failure. If a previously working connector starts failing, check the token first. + +#### Connector Mappings + +1. Enter your Beagle API URL in the **Location** field — `https://api.beaglesecurity.com/rest/v2`. +2. Enter the personal access token in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each verified application becomes a Record, and its findings come from that application's most recently **finished** test session — so a test still in progress does not replace your existing results. diff --git a/docs/content/connectors/toolreference/bigid.md b/docs/content/connectors/toolreference/bigid.md new file mode 100644 index 00000000000..44d946ae941 --- /dev/null +++ b/docs/content/connectors/toolreference/bigid.md @@ -0,0 +1,21 @@ +--- +title: "BigID" +description: "How to set up the BigID Upstream Connector for DefectDojo" +weight: 24 +audience: pro +--- +The BigID connector imports **data security posture (DSPM) findings** — exposed sensitive data, over-permissive access, and unprotected PII stores — from BigID's actionable insights. DefectDojo creates a Record for each BigID **data source**. + +> **Your sensitive data is never copied into DefectDojo.** Findings carry only identifiers, classifications, and affected-object **counts**. No sample or preview of the underlying sensitive data is read or written into a finding — which is what makes it safe to surface DSPM results alongside your other findings. + +#### Prerequisites + +A BigID **user token**, from **Administration \> Access Management**. DefectDojo exchanges it for a short\-lived system token on each Sync; the user token is never logged. + +#### Connector Mappings + +1. Enter your BigID instance URL in the **Location** field. +2. Enter the user token in the **User Token** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each BigID data source becomes a Record, carrying the actionable-insight cases raised against it. diff --git a/docs/content/connectors/toolreference/bitbucket.de.md b/docs/content/connectors/toolreference/bitbucket.de.md new file mode 100644 index 00000000000..01fb40d613b --- /dev/null +++ b/docs/content/connectors/toolreference/bitbucket.de.md @@ -0,0 +1,73 @@ +--- +title: "Bitbucket" +description: "Einrichtung der Upstream- und Downstream-Connectors für Bitbucket" +weight: 25 +audience: pro +--- +## Upstream-Connector + +Der Bitbucket-Connector ist ein **Asset-Connector**: Er zählt die Repositories in den von Ihnen benannten Bitbucket-Cloud-Workspaces auf und erstellt für jedes Repository ein DefectDojo-Asset, gruppiert in Organisationen nach Bitbucket-Projekt. Es werden keine Befunde importiert. + +#### Voraussetzungen + +Bitbucket Cloud erfordert ein **scoped** Atlassian-API-Token — klassische (nicht-scoped) Atlassian-API-Tokens werden von Bitbucket mit dem Fehler „API Token provided has no Bitbucket scopes" abgelehnt. + +1. Gehen Sie zu [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens) und wählen Sie **Create API token with scopes**. +2. Wählen Sie die **Bitbucket**-App und gewähren Sie dann die Lese-Scopes: `read:account:bitbucket`, `read:workspace:bitbucket`, `read:repository:bitbucket` und `read:project:bitbucket`. + +Nur Bitbucket Cloud (bitbucket.org) wird unterstützt. Bitbucket Server hat 2024 das Ende seiner Lebensdauer erreicht, und Bitbucket Data Center wird nicht unterstützt. + +#### Connector-Zuordnungen + +1. Geben Sie `https://bitbucket.org` in das Feld **Location** ein. +2. Geben Sie die Atlassian-Konto-E-Mail-Adresse, zu der das Token gehört, in das Feld **Email** ein. +3. Geben Sie das scoped API-Token in das Feld **Secret** ein. +4. Geben Sie einen oder mehrere Workspace-Slugs (kommagetrennt) in das Feld **Workspace Slugs** ein. Dieses Feld ist erforderlich: Die scoped API-Tokens von Bitbucket können Workspaces nicht automatisch auflisten, daher muss DefectDojo mitgeteilt werden, welche Workspaces gelesen werden sollen. + +Jedes Repository wird zu einem nach dem Repository benannten Eintrag, gruppiert nach seinem Bitbucket-**Projekt**. + +## Downstream-Connector + +Die Bitbucket-Integration ermöglicht es Ihnen, Issues in den [Issue-Tracker](https://support.atlassian.com/bitbucket-cloud/docs/enable-an-issue-tracker/) eines Bitbucket-Cloud-Repositorys zu übertragen. + +Der Issue-Tracker ist in Bitbucket optional und muss im Repository aktiviert werden, bevor DefectDojo dort Issues erstellen kann. Öffnen Sie zum Aktivieren das Repository in Bitbucket, wählen Sie **Repository settings** und aktivieren Sie den Issue-Tracker anschließend unter **Features**. + +### Instanz-Einrichtung + +- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf `https://bitbucket.org` gesetzt werden. +- **Email** sollte die E-Mail-Adresse des Atlassian-Kontos sein, zu dem das API-Token gehört. +- **API Token** sollte auf ein Atlassian-API-Token mit Scopes gesetzt werden. + +Bitbucket-App-Passwörter wurden von Atlassian abgekündigt und funktionieren mit dieser Integration nicht. So erstellen Sie ein API-Token: + +1. Öffnen Sie die [Atlassian-Kontoeinstellungen](https://id.atlassian.com/manage-profile/security/api-tokens) und wählen Sie **Security** und dann **Create and manage API tokens**. +2. Wählen Sie **Create API token with scopes**, benennen Sie das Token und legen Sie ein Ablaufdatum fest. +3. Wählen Sie **Bitbucket** als App aus. +4. Erteilen Sie dem Token die Berechtigung, Repositorys zu lesen sowie Issues zu lesen und zu schreiben. + +### Issue-Tracker-Zuordnung + +- **Workspace** sollte der Slug des Workspace sein, der das Repository enthält, so wie er in bitbucket.org-URLs erscheint. +- **Repository Slug** sollte der Slug des Repositorys sein, in dem Sie Issues erstellen möchten. + +### Details zur Schweregrad-Zuordnung + +Dies wird dem Bitbucket-Feld „Priority“ eines Issues zugeordnet. Die Attribute im Formular sind als Standardwerte vorbelegt, und jeder Wert muss eine der Bitbucket-Prioritäten sein: `trivial`, `minor`, `major`, `critical` oder `blocker`. + +- **Name des Schweregrad-Felds**: `priority` +- **Info-Zuordnung**: `trivial` +- **Niedrig-Zuordnung**: `minor` +- **Mittel-Zuordnung**: `major` +- **Hoch-Zuordnung**: `critical` +- **Kritisch-Zuordnung**: `blocker` + +### Details zur Status-Zuordnung + +Dies wird dem Bitbucket-Feld „State“ eines Issues zugeordnet. Jeder Wert muss einer der Bitbucket-Issue-Status sein: `new`, `open`, `resolved`, `on hold`, `invalid`, `duplicate`, `wontfix` oder `closed`. + +- **Name des Status-Felds**: `state` +- **Aktiv-Zuordnung**: `new` +- **Geschlossen-Zuordnung**: `resolved` +- **Falsch-positiv-Zuordnung**: `invalid` +- **Risiko-akzeptiert-Zuordnung**: `wontfix` diff --git a/docs/content/connectors/toolreference/bitbucket.es.md b/docs/content/connectors/toolreference/bitbucket.es.md new file mode 100644 index 00000000000..3ae7e093a46 --- /dev/null +++ b/docs/content/connectors/toolreference/bitbucket.es.md @@ -0,0 +1,73 @@ +--- +title: "Bitbucket" +description: "Configuración de los Conectores Upstream y Downstream de Bitbucket" +weight: 25 +audience: pro +--- +## Conector Upstream + +El conector de Bitbucket es un **Conector de activos**: enumera los repositorios de los workspaces de Bitbucket Cloud que usted indique y crea un Activo de DefectDojo para cada repositorio, agrupados en Organizaciones según el proyecto de Bitbucket. No se importa ningún hallazgo. + +#### Prerrequisitos + +Bitbucket Cloud requiere un token de API de Atlassian **con ámbitos (scoped)** — los tokens de API de Atlassian clásicos (sin ámbitos) son rechazados por Bitbucket con un error "API Token provided has no Bitbucket scopes". + +1. Vaya a [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens) y elija **Create API token with scopes**. +2. Seleccione la aplicación **Bitbucket** y, a continuación, otorgue los ámbitos de lectura: `read:account:bitbucket`, `read:workspace:bitbucket`, `read:repository:bitbucket` y `read:project:bitbucket`. + +Solo se admite Bitbucket Cloud (bitbucket.org). Bitbucket Server llegó a su fin de vida en 2024, y Bitbucket Data Center no es compatible. + +#### Asignaciones del conector + +1. Ingrese `https://bitbucket.org` en el campo **Location**. +2. Ingrese el correo de la cuenta de Atlassian a la que pertenece el token en el campo **Email**. +3. Ingrese el token de API con ámbitos en el campo **Secret**. +4. Ingrese uno o más slugs de workspace (separados por comas) en el campo **Workspace Slugs**. Este campo es obligatorio: los tokens de API con ámbitos de Bitbucket no pueden listar workspaces automáticamente, por lo que hay que indicarle a DefectDojo qué workspaces leer. + +Cada repositorio se convierte en un Registro con el nombre del repositorio, agrupado por su **proyecto** de Bitbucket. + +## Conector Downstream + +La integración de Bitbucket le permite enviar incidencias al [rastreador de incidencias](https://support.atlassian.com/bitbucket-cloud/docs/enable-an-issue-tracker/) de un repositorio de Bitbucket Cloud. + +El rastreador de incidencias es opcional en Bitbucket y debe habilitarse en el repositorio antes de que DefectDojo pueda crear incidencias en él. Para habilitarlo, abra el repositorio en Bitbucket y seleccione **Repository settings**, luego habilite el rastreador de incidencias en **Features**. + +### Configuración de la instancia + +- **Label** debe ser la etiqueta que desea usar para identificar esta integración. +- **Location** debe establecerse en `https://bitbucket.org`. +- **Email** debe ser la dirección de correo electrónico de la cuenta de Atlassian a la que pertenece el token de la API. +- **API Token** debe establecerse en un token de API de Atlassian con alcance limitado (scoped). + +Atlassian ha declarado obsoletas las contraseñas de aplicación de Bitbucket y no funcionarán con esta integración. Para crear un token de API: + +1. Abra la [configuración de la cuenta de Atlassian](https://id.atlassian.com/manage-profile/security/api-tokens) y elija **Security**, luego **Create and manage API tokens**. +2. Elija **Create API token with scopes**, asigne un nombre al token y establezca una fecha de vencimiento. +3. Seleccione **Bitbucket** como la aplicación. +4. Otorgue al token permiso para leer repositorios y para leer y escribir incidencias. + +### Mapeo del Issue Tracker + +- **Workspace** debe ser el slug del espacio de trabajo que contiene el repositorio, tal como aparece en las URL de bitbucket.org. +- **Repository Slug** debe ser el slug del repositorio en el que desea crear incidencias. + +### Detalles del mapeo de severidad + +Esto se mapea al campo Priority de la incidencia de Bitbucket. Los atributos del formulario se proporcionan como valores predeterminados, y cada valor debe ser una de las prioridades de Bitbucket: `trivial`, `minor`, `major`, `critical` o `blocker`. + +- **Severity Field Name**: `priority` +- **Info Mapping**: `trivial` +- **Low Mapping**: `minor` +- **Medium Mapping**: `major` +- **High Mapping**: `critical` +- **Critical Mapping**: `blocker` + +### Detalles del mapeo de estado + +Esto se mapea al campo State de la incidencia de Bitbucket. Cada valor debe ser uno de los estados de incidencia de Bitbucket: `new`, `open`, `resolved`, `on hold`, `invalid`, `duplicate`, `wontfix` o `closed`. + +- **Status Field Name**: `state` +- **Active Mapping**: `new` +- **Closed Mapping**: `resolved` +- **False Positive Mapping**: `invalid` +- **Risk Accepted Mapping**: `wontfix` diff --git a/docs/content/connectors/toolreference/bitbucket.fr.md b/docs/content/connectors/toolreference/bitbucket.fr.md new file mode 100644 index 00000000000..5bf4f6274ff --- /dev/null +++ b/docs/content/connectors/toolreference/bitbucket.fr.md @@ -0,0 +1,73 @@ +--- +title: "Bitbucket" +description: "Configuration des Connecteurs Upstream et Downstream pour Bitbucket" +weight: 25 +audience: pro +--- +## Connecteur Upstream + +Le connecteur Bitbucket est un **Connecteur d'actifs** : il énumère les dépôts des espaces de travail (workspaces) Bitbucket Cloud que vous indiquez et crée un Actif DefectDojo pour chaque dépôt, regroupé en Organisations par projet Bitbucket. Aucune constatation n'est importée. + +#### Prérequis + +Bitbucket Cloud nécessite un jeton API Atlassian **à portée définie (scoped)** — les jetons API Atlassian classiques (sans portée) sont rejetés par Bitbucket avec une erreur « API Token provided has no Bitbucket scopes ». + +1. Rendez-vous sur [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens) et choisissez **Create API token with scopes**. +2. Sélectionnez l'application **Bitbucket**, puis accordez les portées en lecture : `read:account:bitbucket`, `read:workspace:bitbucket`, `read:repository:bitbucket` et `read:project:bitbucket`. + +Seul Bitbucket Cloud (bitbucket.org) est pris en charge. Bitbucket Server a atteint sa fin de vie en 2024, et Bitbucket Data Center n'est pas pris en charge. + +#### Mappages du Connecteur + +1. Saisissez `https://bitbucket.org` dans le champ **Location**. +2. Saisissez l'e-mail du compte Atlassian auquel appartient le jeton dans le champ **Email**. +3. Saisissez le jeton API à portée définie dans le champ **Secret**. +4. Saisissez un ou plusieurs slugs d'espace de travail (séparés par des virgules) dans le champ **Workspace Slugs**. Ce champ est obligatoire : les jetons API à portée définie de Bitbucket ne peuvent pas lister automatiquement les espaces de travail, DefectDojo doit donc être informé des espaces de travail à lire. + +Chaque dépôt devient un Enregistrement portant le nom du dépôt, regroupé par **projet** Bitbucket. + +## Connecteur Downstream + +L'intégration Bitbucket vous permet de transmettre des tickets vers le [suivi des tickets](https://support.atlassian.com/bitbucket-cloud/docs/enable-an-issue-tracker/) d'un dépôt Bitbucket Cloud. + +Le suivi des tickets est optionnel dans Bitbucket et doit être activé sur le dépôt avant que DefectDojo puisse y créer des tickets. Pour l'activer, ouvrez le dépôt dans Bitbucket, sélectionnez **Repository settings**, puis activez le suivi des tickets sous **Features**. + +### Configuration de l'instance + +- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur `https://bitbucket.org`. +- **Email** doit être l'adresse e-mail du compte Atlassian auquel appartient le jeton API. +- **API Token** doit être défini sur un jeton API Atlassian à portée limitée. + +Les mots de passe d'application Bitbucket sont dépréciés par Atlassian et ne fonctionneront pas avec cette intégration. Pour créer un jeton API : + +1. Ouvrez les [paramètres du compte Atlassian](https://id.atlassian.com/manage-profile/security/api-tokens) et choisissez **Security**, puis **Create and manage API tokens**. +2. Choisissez **Create API token with scopes**, nommez le jeton et définissez une date d'expiration. +3. Sélectionnez **Bitbucket** comme application. +4. Accordez au jeton l'autorisation de lire les dépôts, ainsi que de lire et écrire des tickets. + +### Mappage du suivi des tickets + +- **Workspace** doit correspondre au slug de l'espace de travail contenant le dépôt, tel qu'il apparaît dans les URL de bitbucket.org. +- **Repository Slug** doit correspondre au slug du dépôt dans lequel vous souhaitez créer des tickets. + +### Détails du mappage de la sévérité + +Ceci correspond au champ Priority des tickets Bitbucket. Les attributs du formulaire sont fournis par défaut, et chaque valeur doit être l'une des priorités de Bitbucket : `trivial`, `minor`, `major`, `critical` ou `blocker`. + +- **Severity Field Name** : `priority` +- **Info Mapping** : `trivial` +- **Low Mapping** : `minor` +- **Medium Mapping** : `major` +- **High Mapping** : `critical` +- **Critical Mapping** : `blocker` + +### Détails du mappage du statut + +Ceci correspond au champ State des tickets Bitbucket. Chaque valeur doit être l'un des états de ticket de Bitbucket : `new`, `open`, `resolved`, `on hold`, `invalid`, `duplicate`, `wontfix` ou `closed`. + +- **Status Field Name** : `state` +- **Active Mapping** : `new` +- **Closed Mapping** : `resolved` +- **False Positive Mapping** : `invalid` +- **Risk Accepted Mapping** : `wontfix` diff --git a/docs/content/connectors/toolreference/bitbucket.ja.md b/docs/content/connectors/toolreference/bitbucket.ja.md new file mode 100644 index 00000000000..dcbe1b65458 --- /dev/null +++ b/docs/content/connectors/toolreference/bitbucket.ja.md @@ -0,0 +1,73 @@ +--- +title: "Bitbucket" +description: "Bitbucket の Upstream / ダウンストリームコネクタのセットアップ" +weight: 25 +audience: pro +--- +## アップストリームコネクタ + +Bitbucket コネクタは**Asset Connector**です。指定した Bitbucket Cloud ワークスペース内のリポジトリを列挙し、リポジトリごとに DefectDojo のアセットを作成し、Bitbucket のプロジェクト単位で組織にグループ化します。検出事項はインポートされません。 + +#### Prerequisites + +Bitbucket Cloud では**スコープ付き**の Atlassian API トークンが必要です。従来の(スコープなしの)Atlassian API トークンは、Bitbucket 側で「API Token provided has no Bitbucket scopes」エラーとして拒否されます。 + +1. [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens) にアクセスし、**Create API token with scopes** を選択します。 +2. **Bitbucket** アプリを選択し、読み取りスコープ `read:account:bitbucket`、`read:workspace:bitbucket`、`read:repository:bitbucket`、`read:project:bitbucket` を付与します。 + +対応しているのは Bitbucket Cloud(bitbucket.org)のみです。Bitbucket Server は 2024 年にサポートが終了しており、Bitbucket Data Center にも対応していません。 + +#### Connector Mappings + +1. **Location** フィールドに `https://bitbucket.org` を入力します。 +2. **Email** フィールドにトークンが紐づく Atlassian アカウントの email を入力します。 +3. **Secret** フィールドにスコープ付き API トークンを入力します。 +4. **Workspace Slugs** フィールドに、1 つ以上のワークスペース slug をカンマ区切りで入力します。このフィールドは必須です。Bitbucket のスコープ付き API トークンはワークスペースを自動的に一覧取得できないため、読み取り対象のワークスペースを DefectDojo に明示的に伝える必要があります。 + +各リポジトリは、そのリポジトリ名を冠したレコードとなり、Bitbucket の**プロジェクト**単位でグループ化されます。 + +## ダウンストリームコネクタ + +Bitbucket 統合を使うと、Bitbucket Cloud リポジトリの[Issue トラッカー](https://support.atlassian.com/bitbucket-cloud/docs/enable-an-issue-tracker/)に Issue をプッシュできます。 + +Bitbucket では Issue トラッカーはオプション機能であり、DefectDojo が Issue を作成できるようにするには、事前にリポジトリ側で有効にしておく必要があります。有効にするには、Bitbucket でリポジトリを開き、**Repository settings** を選択したうえで、**Features** の下で Issue トラッカーを有効にします。 + +### Instance Setup + +- **Label** は、この統合を識別するために使用したいラベルを設定します。 +- **Location** は、`https://bitbucket.org` を設定します。 +- **Email** は、API トークンの発行元となる Atlassian アカウントのメールアドレスを設定します。 +- **API Token** は、スコープ付きの Atlassian API トークンを設定します。 + +Bitbucket のアプリパスワードは Atlassian によって非推奨とされており、この統合では使用できません。API トークンを作成する手順は以下のとおりです。 + +1. [Atlassian アカウント設定](https://id.atlassian.com/manage-profile/security/api-tokens)を開き、**Security** を選択したうえで、**Create and manage API tokens** を選択します。 +2. **Create API token with scopes** を選択し、トークンに名前を付けて有効期限を設定します。 +3. アプリとして **Bitbucket** を選択します。 +4. リポジトリの読み取り権限、および Issue の読み取り・書き込み権限をトークンに付与します。 + +### Issue Tracker Mapping + +- **Workspace** は、リポジトリを含むワークスペースのスラッグを設定します。bitbucket.org の URL に表示される値です。 +- **Repository Slug** は、Issue を作成したいリポジトリのスラッグを設定します。 + +### Severity Mapping Details + +これは Bitbucket の Issue の Priority フィールドにマッピングされます。フォームの各項目にはデフォルト値が設定されており、各値は Bitbucket の優先度である `trivial`、`minor`、`major`、`critical`、`blocker` のいずれかである必要があります。 + +- **Severity Field Name**: `priority` +- **Info Mapping**: `trivial` +- **Low Mapping**: `minor` +- **Medium Mapping**: `major` +- **High Mapping**: `critical` +- **Critical Mapping**: `blocker` + +### Status Mapping Details + +これは Bitbucket の Issue の State フィールドにマッピングされます。各値は Bitbucket の Issue ステータスである `new`、`open`、`resolved`、`on hold`、`invalid`、`duplicate`、`wontfix`、`closed` のいずれかである必要があります。 + +- **Status Field Name**: `state` +- **Active Mapping**: `new` +- **Closed Mapping**: `resolved` +- **False Positive Mapping**: `invalid` +- **Risk Accepted Mapping**: `wontfix` diff --git a/docs/content/connectors/toolreference/bitbucket.md b/docs/content/connectors/toolreference/bitbucket.md new file mode 100644 index 00000000000..cb124d65088 --- /dev/null +++ b/docs/content/connectors/toolreference/bitbucket.md @@ -0,0 +1,73 @@ +--- +title: "Bitbucket" +description: "Upstream and Downstream Connector setup for Bitbucket" +weight: 25 +audience: pro +--- +## Upstream Connector + +The Bitbucket connector is an **Asset Connector**: it enumerates the repositories in the Bitbucket Cloud workspaces you name and creates a DefectDojo Asset for each repository, grouped into Organizations by Bitbucket project. No findings are imported. + +#### Prerequisites + +Bitbucket Cloud requires a **scoped** Atlassian API token — classic (unscoped) Atlassian API tokens are rejected by Bitbucket with an "API Token provided has no Bitbucket scopes" error. + +1. Go to [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens) and choose **Create API token with scopes**. +2. Select the **Bitbucket** app, then grant the read scopes: `read:account:bitbucket`, `read:workspace:bitbucket`, `read:repository:bitbucket`, and `read:project:bitbucket`. + +Only Bitbucket Cloud (bitbucket.org) is supported. Bitbucket Server reached end of life in 2024, and Bitbucket Data Center is not supported. + +#### Connector Mappings + +1. Enter `https://bitbucket.org` in the **Location** field. +2. Enter the Atlassian account email the token belongs to in the **Email** field. +3. Enter the scoped API token in the **Secret** field. +4. Enter one or more workspace slugs (comma-separated) in the **Workspace Slugs** field. This field is required: Bitbucket's scoped API tokens cannot list workspaces automatically, so DefectDojo needs to be told which workspaces to read. + +Each repository becomes a Record named after the repository, grouped by its Bitbucket **project**. + +## Downstream Connector + +The Bitbucket integration allows you to push issues to the [issue tracker](https://support.atlassian.com/bitbucket-cloud/docs/enable-an-issue-tracker/) of a Bitbucket Cloud repository. + +The issue tracker is optional in Bitbucket and must be enabled on the repository before DefectDojo can create Issues in it. To enable it, open the repository in Bitbucket and select **Repository settings**, then enable the issue tracker under **Features**. + +### Instance Setup + +- **Label** should be the label that you want to use to identify this integration. +- **Location** should be set to `https://bitbucket.org`. +- **Email** should be the email address of the Atlassian account that the API token belongs to. +- **API Token** should be set to a scoped Atlassian API token. + +Bitbucket app passwords are deprecated by Atlassian and will not work with this integration. To create an API token: + +1. Open [Atlassian account settings](https://id.atlassian.com/manage-profile/security/api-tokens) and choose **Security**, then **Create and manage API tokens**. +2. Choose **Create API token with scopes**, name the token, and set an expiry date. +3. Select **Bitbucket** as the app. +4. Grant the token permission to read repositories and to read and write issues. + +### Issue Tracker Mapping + +- **Workspace** should be the slug of the workspace that contains the repository, as it appears in bitbucket.org URLs. +- **Repository Slug** should be the slug of the repository that you want to create Issues in. + +### Severity Mapping Details + +This maps to the Bitbucket issue Priority field. The attributes in the form are supplied as defaults, and each value must be one of Bitbucket's priorities: `trivial`, `minor`, `major`, `critical`, or `blocker`. + +- **Severity Field Name**: `priority` +- **Info Mapping**: `trivial` +- **Low Mapping**: `minor` +- **Medium Mapping**: `major` +- **High Mapping**: `critical` +- **Critical Mapping**: `blocker` + +### Status Mapping Details + +This maps to the Bitbucket issue State field. Each value must be one of Bitbucket's issue states: `new`, `open`, `resolved`, `on hold`, `invalid`, `duplicate`, `wontfix`, or `closed`. + +- **Status Field Name**: `state` +- **Active Mapping**: `new` +- **Closed Mapping**: `resolved` +- **False Positive Mapping**: `invalid` +- **Risk Accepted Mapping**: `wontfix` diff --git a/docs/content/connectors/toolreference/black_duck.de.md b/docs/content/connectors/toolreference/black_duck.de.md new file mode 100644 index 00000000000..42a1d551a58 --- /dev/null +++ b/docs/content/connectors/toolreference/black_duck.de.md @@ -0,0 +1,21 @@ +--- +title: "Black Duck" +description: "Einrichtung des Black Duck Upstream-Connectors für DefectDojo" +weight: 26 +audience: pro +--- +Der Black-Duck-Connector importiert **Software-Composition-Analysis(SCA)**-Befunde von einer Black-Duck(Synopsys/Black-Duck)-Hub-Instanz. DefectDojo ermittelt jedes Projekt in der Instanz und erstellt für jedes **Projekt** einen Eintrag; die Befunde eines Projekts stammen aus den anfälligen BOM-Komponenten der ausgewählten Version. + +#### Voraussetzungen + +Ein Black-Duck-**API-Token** für einen Benutzer, der die zu importierenden Projekte sehen kann. Öffnen Sie in Black Duck Ihr Benutzermenü \> **My Access Tokens** \> **Create New Token**, gewähren Sie (mindestens) Lesezugriff, und kopieren Sie das Token, wenn es angezeigt wird — es wird nur einmal angezeigt. Der Connector tauscht dieses Token bei jedem Sync gegen ein kurzlebiges Bearer-Token ein; es wird über das Secret-Feld des Connectors hinaus nie im Klartext gespeichert. + +#### Connector-Zuordnungen + +1. Geben Sie Ihre Black-Duck-Hub-URL in das Feld **Location** ein — zum Beispiel `https://your-company.app.blackduck.com`. +2. Geben Sie das API-Token in das Feld **Secret** ein. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jedes Black-Duck-Projekt wird zu einem Eintrag. Standardmäßig importiert der Connector die **released**-Version des Projekts (mit Rückgriff auf dessen erste Version); jede anfällige BOM-Komponente dieser Version wird zu einem Befund mit dem Titel `{vulnerability} in {component}:{version}`. + +Dieser Connector unterscheidet sich von den dateibasierten Black-Duck-Parsern — seine Befunde verwenden den dedizierten Scan-Typ **Black Duck - Connectors Import**. diff --git a/docs/content/connectors/toolreference/black_duck.es.md b/docs/content/connectors/toolreference/black_duck.es.md new file mode 100644 index 00000000000..2829d216b1c --- /dev/null +++ b/docs/content/connectors/toolreference/black_duck.es.md @@ -0,0 +1,21 @@ +--- +title: "Black Duck" +description: "Cómo configurar el Conector Upstream de Black Duck para DefectDojo" +weight: 26 +audience: pro +--- +El conector de Black Duck importa hallazgos de **análisis de composición de software (SCA)** desde una instancia de Black Duck Hub (Synopsys / Black Duck). DefectDojo descubre todos los proyectos de la instancia y crea un Registro para cada **proyecto**; los hallazgos de un proyecto provienen de los componentes de la BOM vulnerables de su versión seleccionada. + +#### Prerrequisitos + +Un **token de API** de Black Duck para un usuario que pueda ver los proyectos que desea importar. En Black Duck, abra el menú de usuario \> **My Access Tokens** \> **Create New Token**, otórguele (como mínimo) acceso de lectura y copie el token cuando se muestre — solo se exhibe una vez. El conector intercambia este token por un bearer de corta duración en cada sincronización; nunca se almacena en texto claro más allá del campo secreto del conector. + +#### Asignaciones del conector + +1. Ingrese la URL de su hub de Black Duck en el campo **Location** — por ejemplo `https://your-company.app.blackduck.com`. +2. Ingrese el token de API en el campo **Secret**. +3. Opcionalmente, configure una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada proyecto de Black Duck se convierte en un Registro. Por defecto el conector importa la versión **released** del proyecto (recurriendo a su primera versión si no existe); cada componente de la BOM vulnerable de esa versión se convierte en un hallazgo, titulado `{vulnerability} in {component}:{version}`. + +Este conector es distinto de los parsers de Black Duck basados en archivos — sus hallazgos usan el tipo de análisis dedicado **Black Duck - Connectors Import**. diff --git a/docs/content/connectors/toolreference/black_duck.fr.md b/docs/content/connectors/toolreference/black_duck.fr.md new file mode 100644 index 00000000000..0c1c8ccd19c --- /dev/null +++ b/docs/content/connectors/toolreference/black_duck.fr.md @@ -0,0 +1,21 @@ +--- +title: "Black Duck" +description: "Comment configurer le Connecteur Upstream Black Duck pour DefectDojo" +weight: 26 +audience: pro +--- +Le connecteur Black Duck importe des constatations d'**analyse de composition logicielle (SCA)** depuis une instance Black Duck Hub (Synopsys / Black Duck). DefectDojo découvre tous les projets de l'instance et crée un Enregistrement pour chaque **projet** ; les constatations d'un projet proviennent des composants du BOM vulnérables de sa version sélectionnée. + +#### Prérequis + +Un **jeton API** Black Duck pour un utilisateur pouvant voir les projets que vous souhaitez importer. Dans Black Duck, ouvrez votre menu utilisateur \> **My Access Tokens** \> **Create New Token**, accordez-lui (au moins) un accès en lecture, et copiez le jeton lorsqu'il s'affiche — il n'est affiché qu'une seule fois. Le connecteur échange ce jeton contre un jeton porteur (bearer) de courte durée à chaque synchronisation ; il n'est jamais stocké en clair en dehors du champ secret du connecteur. + +#### Mappages du Connecteur + +1. Saisissez l'URL de votre hub Black Duck dans le champ **Location** — par exemple `https://your-company.app.blackduck.com`. +2. Saisissez le jeton API dans le champ **Secret**. +3. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque projet Black Duck devient un Enregistrement. Par défaut, le connecteur importe la version **released** du projet (avec repli sur sa première version) ; chaque composant du BOM vulnérable de cette version devient une constatation, intitulée `{vulnerability} in {component}:{version}`. + +Ce connecteur est distinct des parseurs Black Duck basés sur fichiers — ses constatations utilisent le type de scan dédié **Black Duck - Connectors Import**. diff --git a/docs/content/connectors/toolreference/black_duck.ja.md b/docs/content/connectors/toolreference/black_duck.ja.md new file mode 100644 index 00000000000..9df42f92d4c --- /dev/null +++ b/docs/content/connectors/toolreference/black_duck.ja.md @@ -0,0 +1,21 @@ +--- +title: "Black Duck" +description: "DefectDojo で Black Duck の Upstream Connector をセットアップする方法" +weight: 26 +audience: pro +--- +Black Duck コネクタは、Black Duck(Synopsys / Black Duck)Hub インスタンスから**ソフトウェア構成分析(SCA)**の検出事項をインポートします。DefectDojo はインスタンス内のすべてのプロジェクトを検出し、**プロジェクト**ごとにレコードを作成します。プロジェクトの検出事項は、選択されたバージョンの脆弱な BOM コンポーネントから取得されます。 + +#### Prerequisites + +インポートしたいプロジェクトを閲覧できるユーザーの Black Duck **API トークン**が必要です。Black Duck でユーザーメニュー \> **My Access Tokens** \> **Create New Token** を開き、(少なくとも)読み取りアクセスを付与して、表示されたトークンをコピーしてください(表示されるのは一度きりです)。コネクタは各同期時にこのトークンを短命なベアラートークンと交換します。コネクタの secret フィールド以外に平文で保存されることはありません。 + +#### Connector Mappings + +1. **Location** フィールドに Black Duck の hub URL を入力します。例: `https://your-company.app.blackduck.com`。 +2. **Secret** フィールドに API トークンを入力します。 +3. 必要に応じて、インポートする検出事項を制限するために **Minimum Severity** を設定します。 + +各 Black Duck プロジェクトが 1 件のレコードになります。デフォルトでは、コネクタはプロジェクトの**リリース済み**バージョン(存在しない場合は最初のバージョンにフォールバック)をインポートします。そのバージョンの脆弱な BOM コンポーネントごとに、`{vulnerability} in {component}:{version}` というタイトルの検出事項が作成されます。 + +このコネクタは、ファイルベースの Black Duck パーサーとは別物です。このコネクタの検出事項は専用の **Black Duck - Connectors Import** スキャンタイプを使用します。 diff --git a/docs/content/connectors/toolreference/black_duck.md b/docs/content/connectors/toolreference/black_duck.md new file mode 100644 index 00000000000..b2fdb01f25e --- /dev/null +++ b/docs/content/connectors/toolreference/black_duck.md @@ -0,0 +1,21 @@ +--- +title: "Black Duck" +description: "How to set up the Black Duck Upstream Connector for DefectDojo" +weight: 26 +audience: pro +--- +The Black Duck connector imports **software composition analysis (SCA)** findings from a Black Duck (Synopsys / Black Duck) Hub instance. DefectDojo discovers every project in the instance and creates a Record for each **project**; the findings for a project come from the vulnerable BOM components of its selected version. + +#### Prerequisites + +A Black Duck **API token** for a user that can see the projects you want to import. In Black Duck, open your user menu \> **My Access Tokens** \> **Create New Token**, grant it (at least) read access, and copy the token when it is shown — it is displayed only once. The connector exchanges this token for a short\-lived bearer on each sync; it is never stored in cleartext beyond the connector's secret field. + +#### Connector Mappings + +1. Enter your Black Duck hub URL in the **Location** field — for example `https://your-company.app.blackduck.com`. +2. Enter the API token in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each Black Duck project becomes a Record. By default the connector imports the project's **released** version (falling back to its first version); each vulnerable BOM component of that version becomes a finding, titled `{vulnerability} in {component}:{version}`. + +This connector is distinct from the file-based Black Duck parsers — its findings use the dedicated **Black Duck - Connectors Import** scan type. diff --git a/docs/content/connectors/toolreference/black_duck_continuous_dynamic.md b/docs/content/connectors/toolreference/black_duck_continuous_dynamic.md new file mode 100644 index 00000000000..006aa97b8b2 --- /dev/null +++ b/docs/content/connectors/toolreference/black_duck_continuous_dynamic.md @@ -0,0 +1,21 @@ +--- +title: "Black Duck Continuous Dynamic" +description: "How to set up the Black Duck Continuous Dynamic Upstream Connector for DefectDojo" +weight: 27 +audience: pro +--- +The Black Duck Continuous Dynamic connector imports **DAST findings** from the Continuous Dynamic platform. DefectDojo creates a Record for each **site** on your account, with no per\-site configuration. + +**Please note:** findings from this connector use the **WhiteHat Sentinel** scan type. Continuous Dynamic was sold as WhiteHat Sentinel Dynamic before the acquisition, and DefectDojo reuses that established mapping — so this is expected, not a misconfiguration. + +#### Prerequisites + +A Continuous Dynamic **API key**, from **Account \> API Keys**. Black Duck treats this key as equivalent to a username and password, so store it accordingly. + +#### Connector Mappings + +1. Enter `https://sentinel.whitehatsec.com` in the **Location** field. +2. Enter the API key in the **API Key** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each site becomes a Record. DefectDojo requests attack vectors, risk scores and descriptions from the API so that findings arrive complete — the same detail the file\-based WhiteHat Sentinel parser expects. diff --git a/docs/content/connectors/toolreference/bright_security.de.md b/docs/content/connectors/toolreference/bright_security.de.md new file mode 100644 index 00000000000..b24ece3c4b2 --- /dev/null +++ b/docs/content/connectors/toolreference/bright_security.de.md @@ -0,0 +1,21 @@ +--- +title: "Bright Security" +description: "Einrichtung des Bright Security Upstream-Connectors für DefectDojo" +weight: 28 +audience: pro +--- +Der Bright-Security-Connector verwendet die [Bright](https://brightsec.com)-API (ehemals NeuraLegion), um **DAST-Befunde** zu importieren. DefectDojo ermittelt jeden Scan, auf den das Token zugreifen kann, und erstellt für jeden abgeschlossenen Scan einen Eintrag; anschließend werden die Issues dieses Scans als Befunde importiert. + +#### Voraussetzungen + +Sie benötigen einen Bright-**API-Schlüssel**, der in der Bright-App unter **User settings → API keys** erstellt wird (ein `Org`- oder persönlicher Schlüssel). Der Schlüssel wird im Header `Authorization: Api-Key` gesendet und nie protokolliert. + +#### Connector-Zuordnungen + +1. Lassen Sie das Feld **Location** leer, um `https://app.brightsec.com` zu verwenden, oder geben Sie Ihren Bright-Host explizit an. +2. Geben Sie den Bright-API-Schlüssel in das Feld **Secret** ein. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo ordnet jeden abgeschlossenen **Scan** einem Eintrag zu und jedes **Issue** einem Befund: Der Schweregrad stammt aus Brights eigener Bewertung (Critical/High/Medium/Low), der CVSS-Score, die CWE und die Abhilfemaßnahme werden übernommen, der betroffene Entry Point wird zum Endpunkt, und der Request/Response-Nachweis wird in die Beschreibung aufgenommen. Befunde werden als dynamische Befunde erfasst und anhand der Bright-Issue-ID dedupliziert. + +Weitere Informationen finden Sie in der [Bright-API-Dokumentation](https://docs.brightsec.com/). diff --git a/docs/content/connectors/toolreference/bright_security.es.md b/docs/content/connectors/toolreference/bright_security.es.md new file mode 100644 index 00000000000..67bef79497f --- /dev/null +++ b/docs/content/connectors/toolreference/bright_security.es.md @@ -0,0 +1,21 @@ +--- +title: "Bright Security" +description: "Cómo configurar el Conector Upstream de Bright Security para DefectDojo" +weight: 28 +audience: pro +--- +El conector de Bright Security usa la API de [Bright](https://brightsec.com) (anteriormente NeuraLegion) para importar **hallazgos DAST**. DefectDojo descubre todos los scans a los que el token tiene acceso y crea un Registro para cada scan completado, e importa luego los issues de ese scan como hallazgos. + +#### Prerrequisitos + +Necesitará una **API key** de Bright, creada en la aplicación Bright en **User settings → API keys** (una clave `Org` o personal). La clave se envía en el encabezado `Authorization: Api-Key` y nunca se registra en logs. + +#### Asignaciones del conector + +1. Deje el campo **Location** en blanco para usar `https://app.brightsec.com`, o ingrese explícitamente su host de Bright. +2. Ingrese la API key de Bright en el campo **Secret**. +3. Opcionalmente, configure una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo asigna cada **scan** completado a un Registro y cada **issue** a un hallazgo: la severidad proviene de la propia calificación de Bright (Crítica/Alta/Media/Baja), se trasladan el puntaje CVSS, el CWE y la remediación, el punto de entrada afectado se convierte en el endpoint, y la evidencia de la solicitud/respuesta se incluye en la descripción. Los hallazgos se registran como hallazgos dinámicos y se deduplican según el id de issue de Bright. + +Consulte la [documentación de la API de Bright](https://docs.brightsec.com/) para obtener más información. diff --git a/docs/content/connectors/toolreference/bright_security.fr.md b/docs/content/connectors/toolreference/bright_security.fr.md new file mode 100644 index 00000000000..4d3a7aa7559 --- /dev/null +++ b/docs/content/connectors/toolreference/bright_security.fr.md @@ -0,0 +1,21 @@ +--- +title: "Bright Security" +description: "Comment configurer le Connecteur Upstream Bright Security pour DefectDojo" +weight: 28 +audience: pro +--- +Le connecteur Bright Security utilise l'API [Bright](https://brightsec.com) (anciennement NeuraLegion) pour importer des **constatations DAST**. DefectDojo découvre tous les scans auxquels le jeton a accès et crée un Enregistrement pour chaque scan terminé, puis importe les issues de ce scan sous forme de constatations. + +#### Prérequis + +Vous aurez besoin d'une **clé API** Bright, créée dans l'application Bright sous **User settings → API keys** (une clé `Org` ou personnelle). La clé est envoyée dans l'en-tête `Authorization: Api-Key` et n'est jamais journalisée. + +#### Mappages du Connecteur + +1. Laissez le champ **Location** vide pour utiliser `https://app.brightsec.com`, ou saisissez explicitement votre hôte Bright. +2. Saisissez la clé API Bright dans le champ **Secret**. +3. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +DefectDojo mappe chaque **scan** terminé sur un Enregistrement et chaque **issue** sur une constatation : la sévérité provient de la notation propre à Bright (Critical/High/Medium/Low), le score CVSS, le CWE et la remédiation sont repris, le point d'entrée affecté devient le point de terminaison, et les preuves de requête/réponse sont incluses dans la description. Les constatations sont enregistrées comme des constatations dynamiques et dédupliquées sur l'ID d'issue de Bright. + +Consultez la [documentation de l'API Bright](https://docs.brightsec.com/) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/bright_security.ja.md b/docs/content/connectors/toolreference/bright_security.ja.md new file mode 100644 index 00000000000..3a8860b3451 --- /dev/null +++ b/docs/content/connectors/toolreference/bright_security.ja.md @@ -0,0 +1,21 @@ +--- +title: "Bright Security" +description: "DefectDojo で Bright Security の Upstream Connector をセットアップする方法" +weight: 28 +audience: pro +--- +Bright Security コネクタは [Bright](https://brightsec.com)(旧 NeuraLegion)の API を使用して**DAST の検出事項**をインポートします。DefectDojo はトークンがアクセスできるすべてのスキャンを検出し、完了済みスキャンごとにレコードを作成して、そのスキャンの issue を検出事項としてインポートします。 + +#### Prerequisites + +Bright アプリの **User settings → API keys** で作成した Bright の**API キー**(`Org` または個人キー)が必要です。このキーは `Authorization: Api-Key` ヘッダーで送信され、ログに記録されることはありません。 + +#### Connector Mappings + +1. **Location** フィールドを空欄のままにすると `https://app.brightsec.com` が使用されます。または Bright のホストを明示的に入力してください。 +2. **Secret** フィールドに Bright の API キーを入力します。 +3. 必要に応じて、インポートする検出事項を制限するために **Minimum Severity** を設定します。 + +DefectDojo は完了済みの各**スキャン**を 1 件のレコードにマッピングし、各**issue**を検出事項にマッピングします。深刻度は Bright 自身の評価(Critical/High/Medium/Low)から取得され、CVSS スコア、CWE、修復情報が引き継がれ、影響を受けるエントリーポイントがエンドポイントとなり、リクエスト/レスポンスの証跡が説明に含まれます。検出事項は動的な検出事項として記録され、Bright の issue id で重複排除されます。 + +詳細は [Bright API documentation](https://docs.brightsec.com/) を参照してください。 diff --git a/docs/content/connectors/toolreference/bright_security.md b/docs/content/connectors/toolreference/bright_security.md new file mode 100644 index 00000000000..d323959b427 --- /dev/null +++ b/docs/content/connectors/toolreference/bright_security.md @@ -0,0 +1,21 @@ +--- +title: "Bright Security" +description: "How to set up the Bright Security Upstream Connector for DefectDojo" +weight: 28 +audience: pro +--- +The Bright Security connector uses the [Bright](https://brightsec.com) (formerly NeuraLegion) API to import **DAST findings**. DefectDojo discovers every scan the token can access and creates a Record for each completed scan, then imports that scan's issues as findings. + +#### Prerequisites + +You will need a Bright **API key**, created in the Bright app under **User settings → API keys** (an `Org` or personal key). The key is sent in the `Authorization: Api-Key` header and is never logged. + +#### Connector Mappings + +1. Leave the **Location** field blank to use `https://app.brightsec.com`, or enter your Bright host explicitly. +2. Enter the Bright API key in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo maps each completed **scan** to a Record and each **issue** to a finding: the severity comes from Bright's own rating (Critical/High/Medium/Low), the CVSS score, CWE and remediation are carried over, the affected entry point becomes the endpoint, and the request/response evidence is included in the description. Findings are recorded as dynamic findings and de-duplicated on Bright's issue id. + +See the [Bright API documentation](https://docs.brightsec.com/) for more information. diff --git a/docs/content/connectors/toolreference/bugcrowd.de.md b/docs/content/connectors/toolreference/bugcrowd.de.md new file mode 100644 index 00000000000..97d1b5827f8 --- /dev/null +++ b/docs/content/connectors/toolreference/bugcrowd.de.md @@ -0,0 +1,19 @@ +--- +title: "Bugcrowd" +description: "Einrichtung des Bugcrowd Upstream-Connectors für DefectDojo" +weight: 29 +audience: pro +--- +Der Bugcrowd-Connector verwendet die Bugcrowd-REST-API, um Einreichungen aus Ihren Bug-Bounty- und Vulnerability-Disclosure-Programmen zu importieren. DefectDojo ermittelt die Programme, auf die Ihr API-Token zugreifen kann, und erstellt für jedes einen Eintrag, wobei die Einreichungen des Programms als Befunde importiert werden. + +#### Voraussetzungen + +Sie benötigen ein Bugcrowd-**API-Token** mit Zugriff auf die zu importierenden Programme. Wir empfehlen, für DefectDojo ein dediziertes Service-Konto anzulegen, damit automatisierte Aktivitäten leicht von manuellen Team-Aktionen zu unterscheiden sind. Generieren Sie das Token in Bugcrowd unter **Organization settings \> API credentials**; Lesezugriff auf Submissions, Programme und Targets ist ausreichend. + +#### Connector-Zuordnungen + +1. Geben Sie `https://api.bugcrowd.com` in das Feld **Location** ein. +2. Geben Sie Ihr Bugcrowd-API-Token in das Feld **Secret** ein. Es wird als `Authorization: Token`-Header gesendet. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jedes Bugcrowd-**Programm** wird zu einem Eintrag, und seine Einreichungen werden mit dem beibehaltenen Bugcrowd-Schweregrad als Befunde importiert. Doppelte Einreichungen werden ausgeschlossen, sodass ein erneuter Import keine wiederholten Befunde für dasselbe Problem erzeugt. diff --git a/docs/content/connectors/toolreference/bugcrowd.es.md b/docs/content/connectors/toolreference/bugcrowd.es.md new file mode 100644 index 00000000000..49028f0ba1c --- /dev/null +++ b/docs/content/connectors/toolreference/bugcrowd.es.md @@ -0,0 +1,19 @@ +--- +title: "Bugcrowd" +description: "Cómo configurar el Conector Upstream de Bugcrowd para DefectDojo" +weight: 29 +audience: pro +--- +El conector de Bugcrowd usa la REST API de Bugcrowd para importar submissions de sus programas de bug bounty y de divulgación de vulnerabilidades. DefectDojo descubre los programas a los que su token de API tiene acceso y crea un Registro para cada uno, importando las submissions de ese programa como hallazgos. + +#### Prerrequisitos + +Necesitará un **token de API** de Bugcrowd con acceso a los programas que desea importar. Recomendamos crear una cuenta de servicio dedicada para DefectDojo, de modo que la actividad automatizada se distinga fácilmente de las acciones manuales del equipo. Genere el token en Bugcrowd en **Organization settings \> API credentials**; basta con acceso de lectura a submissions, programs y targets. + +#### Asignaciones del conector + +1. Ingrese `https://api.bugcrowd.com` en el campo **Location**. +2. Ingrese su token de API de Bugcrowd en el campo **Secret**. Se envía como encabezado `Authorization: Token`. +3. Opcionalmente, configure una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada **program** de Bugcrowd se convierte en un Registro, y sus submissions se importan como hallazgos conservando la severidad de Bugcrowd. Las submissions duplicadas se excluyen, por lo que volver a importar no crea hallazgos repetidos para el mismo problema. diff --git a/docs/content/connectors/toolreference/bugcrowd.fr.md b/docs/content/connectors/toolreference/bugcrowd.fr.md new file mode 100644 index 00000000000..788abccb8c8 --- /dev/null +++ b/docs/content/connectors/toolreference/bugcrowd.fr.md @@ -0,0 +1,19 @@ +--- +title: "Bugcrowd" +description: "Comment configurer le Connecteur Upstream Bugcrowd pour DefectDojo" +weight: 29 +audience: pro +--- +Le connecteur Bugcrowd utilise l'API REST de Bugcrowd pour importer les soumissions de vos programmes de bug bounty et de divulgation de vulnérabilités. DefectDojo découvre les programmes auxquels votre jeton API a accès et crée un Enregistrement pour chacun d'eux, en important les soumissions de ce programme sous forme de constatations. + +#### Prérequis + +Vous aurez besoin d'un **jeton API** Bugcrowd ayant accès aux programmes que vous souhaitez importer. Nous recommandons de créer un compte de service dédié pour DefectDojo afin que l'activité automatisée soit facile à distinguer des actions manuelles de l'équipe. Générez le jeton dans Bugcrowd sous **Organization settings \> API credentials** ; un accès en lecture aux submissions, programs et targets est suffisant. + +#### Mappages du Connecteur + +1. Saisissez `https://api.bugcrowd.com` dans le champ **Location**. +2. Saisissez votre jeton API Bugcrowd dans le champ **Secret**. Il est envoyé sous forme d'en-tête `Authorization: Token`. +3. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque **programme** Bugcrowd devient un Enregistrement, et ses soumissions sont importées comme constatations en conservant la sévérité Bugcrowd. Les soumissions en doublon sont exclues, si bien qu'une réimportation ne crée pas de constatations répétées pour le même problème. diff --git a/docs/content/connectors/toolreference/bugcrowd.ja.md b/docs/content/connectors/toolreference/bugcrowd.ja.md new file mode 100644 index 00000000000..f98cd14e8c3 --- /dev/null +++ b/docs/content/connectors/toolreference/bugcrowd.ja.md @@ -0,0 +1,19 @@ +--- +title: "Bugcrowd" +description: "DefectDojo で Bugcrowd の Upstream Connector をセットアップする方法" +weight: 29 +audience: pro +--- +Bugcrowd コネクタは、Bugcrowd REST API を使用してバグバウンティおよび脆弱性開示プログラムからの提出をインポートします。DefectDojo は API トークンがアクセスできるプログラムを検出し、プログラムごとにレコードを作成して、そのプログラムの提出内容を検出事項としてインポートします。 + +#### Prerequisites + +インポートしたいプログラムへのアクセス権を持つ Bugcrowd の **API トークン**が必要です。自動操作をチームによる手動操作と区別しやすくするため、DefectDojo 専用のサービスアカウントを作成することをお勧めします。トークンは Bugcrowd の **Organization settings \> API credentials** で生成します。提出、プログラム、ターゲットへの読み取りアクセスがあれば十分です。 + +#### Connector Mappings + +1. **Location** フィールドに `https://api.bugcrowd.com` を入力します。 +2. **Secret** フィールドに Bugcrowd API トークンを入力します。これは `Authorization: Token` ヘッダーとして送信されます。 +3. 必要に応じて、インポートする検出事項を制限するために **Minimum Severity** を設定します。 + +各 Bugcrowd **プログラム**が 1 件のレコードになり、その提出内容は Bugcrowd の深刻度を維持したまま検出事項としてインポートされます。重複した提出は除外されるため、再インポートしても同じ問題に対して重複した検出事項が作成されることはありません。 diff --git a/docs/content/connectors/toolreference/bugcrowd.md b/docs/content/connectors/toolreference/bugcrowd.md new file mode 100644 index 00000000000..e47e47ef19e --- /dev/null +++ b/docs/content/connectors/toolreference/bugcrowd.md @@ -0,0 +1,19 @@ +--- +title: "Bugcrowd" +description: "How to set up the Bugcrowd Upstream Connector for DefectDojo" +weight: 29 +audience: pro +--- +The Bugcrowd connector uses the Bugcrowd REST API to import submissions from your bug bounty and vulnerability disclosure programs. DefectDojo discovers the programs your API token can access and creates a Record for each one, importing that program's submissions as findings. + +#### Prerequisites + +You will need a Bugcrowd **API token** with access to the programs you want to import. We recommend creating a dedicated service account for DefectDojo so automated activity is easy to distinguish from manual team actions. Generate the token in Bugcrowd under **Organization settings \> API credentials**; read access to submissions, programs, and targets is sufficient. + +#### Connector Mappings + +1. Enter `https://api.bugcrowd.com` in the **Location** field. +2. Enter your Bugcrowd API token in the **Secret** field. It is sent as an `Authorization: Token` header. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each Bugcrowd **program** becomes a Record, and its submissions are imported as findings with the Bugcrowd severity preserved. Duplicate submissions are excluded, so reimport does not create repeated findings for the same issue. diff --git a/docs/content/connectors/toolreference/burp_suite_enterprise.de.md b/docs/content/connectors/toolreference/burp_suite_enterprise.de.md new file mode 100644 index 00000000000..e3955d3cc89 --- /dev/null +++ b/docs/content/connectors/toolreference/burp_suite_enterprise.de.md @@ -0,0 +1,20 @@ +--- +title: "BurpSuite" +description: "Einrichtung des BurpSuite Upstream-Connectors für DefectDojo" +weight: 30 +audience: pro +--- +Der Burp-Connector von DefectDojo ruft die GraphQL-API von Burp auf, um Daten abzurufen. + +#### Voraussetzungen + +Bevor Sie diesen Connector einrichten können, benötigen Sie einen API-Schlüssel eines Burp-Service-Kontos. Burp-Benutzerkonten verfügen standardmäßig nicht über API-Schlüssel, daher müssen Sie möglicherweise eigens dafür einen neuen Benutzer anlegen. + +Eine Anleitung zum Einrichten eines Service-Account-Benutzers mit einem API-Schlüssel finden Sie in der [Burp-Dokumentation](https://portswigger.net/burp/documentation/enterprise/user-guide/api-documentation/create-api-user). + +#### Connector-Zuordnungen + +1. Geben Sie die Root-URL von Burp in das Feld **Location** ein: Dies ist die URL, unter der Sie auf das Burp-Tool zugreifen. +2. Geben Sie einen gültigen API-Schlüssel in das Feld Secret ein. Dies ist der API-Schlüssel, der mit Ihrem Burp-Service-Konto verknüpft ist. + +Weitere Informationen zur Burp-API finden Sie in der offiziellen [Burp-Dokumentation](https://portswigger.net/burp/extensibility/enterprise/graphql-api/index.html). diff --git a/docs/content/connectors/toolreference/burp_suite_enterprise.es.md b/docs/content/connectors/toolreference/burp_suite_enterprise.es.md new file mode 100644 index 00000000000..434d86aba6b --- /dev/null +++ b/docs/content/connectors/toolreference/burp_suite_enterprise.es.md @@ -0,0 +1,20 @@ +--- +title: "BurpSuite" +description: "Cómo configurar el Conector Upstream de BurpSuite para DefectDojo" +weight: 30 +audience: pro +--- +El conector de Burp de DefectDojo llama a la GraphQL API de Burp para obtener datos. + +#### Prerrequisitos + +Antes de configurar este conector, necesitará una clave de API de una Burp Service Account. Las cuentas de usuario de Burp no tienen claves de API de forma predeterminada, por lo que quizás deba crear un nuevo usuario específicamente para este fin. + +Consulte la [documentación de Burp](https://portswigger.net/burp/documentation/enterprise/user-guide/api-documentation/create-api-user) para obtener una guía sobre cómo configurar un usuario Service Account con una clave de API. + +#### Asignaciones del conector + +1. Ingrese la URL raíz de Burp en el campo **Location**: esta es la URL donde accede a la herramienta Burp. +2. Ingrese una API Key válida en el campo Secret. Esta es la clave de API asociada con su cuenta de Burp Service. + +Consulte la [documentación oficial de Burp](https://portswigger.net/burp/extensibility/enterprise/graphql-api/index.html) para obtener más información sobre la API de Burp. diff --git a/docs/content/connectors/toolreference/burp_suite_enterprise.fr.md b/docs/content/connectors/toolreference/burp_suite_enterprise.fr.md new file mode 100644 index 00000000000..db4fe8ae6d4 --- /dev/null +++ b/docs/content/connectors/toolreference/burp_suite_enterprise.fr.md @@ -0,0 +1,20 @@ +--- +title: "BurpSuite" +description: "Comment configurer le Connecteur Upstream BurpSuite pour DefectDojo" +weight: 30 +audience: pro +--- +Le connecteur Burp de DefectDojo appelle l'API GraphQL de Burp pour récupérer les données. + +#### Prérequis + +Avant de pouvoir configurer ce connecteur, vous aurez besoin d'une clé API provenant d'un Burp Service Account. Les comptes utilisateur Burp n'ont pas de clé API par défaut ; vous devrez donc peut-être créer un nouvel utilisateur spécifiquement à cette fin. + +Consultez la [documentation Burp](https://portswigger.net/burp/documentation/enterprise/user-guide/api-documentation/create-api-user) pour un guide sur la configuration d'un utilisateur Service Account avec une clé API. + +#### Mappages du Connecteur + +1. Saisissez l'URL racine de Burp dans le champ **Location** : il s'agit de l'URL à laquelle vous accédez à l'outil Burp. +2. Saisissez une clé API valide dans le champ Secret. Il s'agit de la clé API associée à votre compte Burp Service. + +Consultez la [documentation officielle de Burp](https://portswigger.net/burp/extensibility/enterprise/graphql-api/index.html) pour plus d'informations sur l'API Burp. diff --git a/docs/content/connectors/toolreference/burp_suite_enterprise.ja.md b/docs/content/connectors/toolreference/burp_suite_enterprise.ja.md new file mode 100644 index 00000000000..53298a60f09 --- /dev/null +++ b/docs/content/connectors/toolreference/burp_suite_enterprise.ja.md @@ -0,0 +1,20 @@ +--- +title: "BurpSuite" +description: "DefectDojo で BurpSuite の Upstream Connector をセットアップする方法" +weight: 30 +audience: pro +--- +DefectDojo の Burp コネクタは、データを取得するために Burp の GraphQL API を呼び出します。 + +#### Prerequisites + +このコネクタをセットアップする前に、Burp Service Account の API キーが必要です。Burp のユーザーアカウントにはデフォルトで API キーがないため、この目的のために新しいユーザーを作成する必要がある場合があります。 + +API キーを持つ Service Account ユーザーのセットアップ方法については、[Burp Documentation](https://portswigger.net/burp/documentation/enterprise/user-guide/api-documentation/create-api-user) を参照してください。 + +#### Connector Mappings + +1. **Location** フィールドに Burp のルート URL を入力します。これは Burp ツールにアクセスする際の URL です。 +2. Secret フィールドに有効な API Key を入力します。これは Burp Service アカウントに紐づく API キーです。 + +Burp API の詳細については、公式の [Burp documentation](https://portswigger.net/burp/extensibility/enterprise/graphql-api/index.html) を参照してください。 diff --git a/docs/content/connectors/toolreference/burp_suite_enterprise.md b/docs/content/connectors/toolreference/burp_suite_enterprise.md new file mode 100644 index 00000000000..f87a4bfc187 --- /dev/null +++ b/docs/content/connectors/toolreference/burp_suite_enterprise.md @@ -0,0 +1,20 @@ +--- +title: "Burp Suite Enterprise" +description: "How to set up the Burp Suite Enterprise Upstream Connector for DefectDojo" +weight: 30 +audience: pro +--- +DefectDojo’s Burp connector calls Burp’s GraphQL API to fetch data. + +#### Prerequisites + +Before you can set up this connector, you will need an API key from a Burp Service Account. Burp user accounts don’t have API keys by default, so you may need to create a new user specifically for this purpose. + +See [Burp Documentation](https://portswigger.net/burp/documentation/enterprise/user-guide/api-documentation/create-api-user) for a guide on setting up a Service Account user with an API key. + +#### Connector Mappings + +1. Enter Burp’s root URL in the **Location** field: this is the URL where you access the Burp tool. +2. Enter a valid API Key in the Secret field. This is the API key associated with your Burp Service account. + +See the official [Burp documentation](https://portswigger.net/burp/extensibility/enterprise/graphql-api/index.html) for more information on the Burp API. diff --git a/docs/content/connectors/toolreference/calico_cloud.md b/docs/content/connectors/toolreference/calico_cloud.md new file mode 100644 index 00000000000..1c7d2487bdb --- /dev/null +++ b/docs/content/connectors/toolreference/calico_cloud.md @@ -0,0 +1,21 @@ +--- +title: "Calico Cloud" +description: "How to set up the Calico Cloud Upstream Connector for DefectDojo" +weight: 31 +audience: pro +--- +The Calico Cloud connector imports **container image vulnerability findings** from Calico Cloud Image Assurance. DefectDojo creates a Record for each scanned **image repository**. + +#### Prerequisites + +An Image Assurance **API token**, from **Image Assurance \> Access Settings** in the Calico Cloud UI. This is the same token the `tigera-scanner` CLI uses, and it is never logged. + +#### Connector Mappings + +1. Enter your Image Assurance API URL in the **Location** field — the same value you would pass to `tigera-scanner` as `--apiurl`. +2. Enter the token in the **API Token** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each scanned image repository becomes a Record, carrying the CVE results of its images. + +**Images whose scan results are not ready yet are skipped, not reported as clean.** Calico's registry scanner runs asynchronously, so an image can be absent from a Sync simply because its scan is still in progress — it will appear once results exist. This is worth knowing before reading a short finding list as a coverage gap. diff --git a/docs/content/connectors/toolreference/censys.de.md b/docs/content/connectors/toolreference/censys.de.md new file mode 100644 index 00000000000..c42605b3816 --- /dev/null +++ b/docs/content/connectors/toolreference/censys.de.md @@ -0,0 +1,28 @@ +--- +title: "Censys" +description: "Einrichtung des Censys Upstream-Connectors für DefectDojo" +weight: 32 +audience: pro +--- +Der Censys-Connector liest Host-Assets aus der Censys Platform und importiert die exponierten Dienste jedes Hosts als Befunde. Er verwendet die globale Such-API der Censys Platform, um die Hosts zu ermitteln, auf die Sie ihn beschränken. + +#### Voraussetzungen + +Sie benötigen ein Censys-**Platform**-Konto mit API-Zugriff: + +* Ein **Personal Access Token**, erstellt in der Censys Platform Console unter Personal Access Tokens. +* Ihre **Organization ID**, die auf derselben Einstellungsseite unter „Current Organization" angezeigt wird. Der API-Zugriff auf den Such-Endpunkt erfordert eine Organisation, daher ist mindestens ein Starter-Tier erforderlich. Free-Tier-Tokens haben keine Organization ID und können die Such-API nicht nutzen. + +Pro-Host-CVE- und Risikodaten sind nur in den Censys-Core(Enterprise)-Tiers verfügbar, sodass Befunde in niedrigeren Tiers exponierte Dienste statt Schwachstellen darstellen. + +Weitere Informationen finden Sie in der [Censys-Platform-API-Dokumentation](https://docs.censys.com/reference/get-started). + +#### Connector-Zuordnungen + +1. Geben Sie `https://api.platform.censys.io` in das Feld **Location** ein. +2. Geben Sie Ihr Personal Access Token in das Feld **API Key** ein. +3. Geben Sie Ihre **Organization ID** ein. +4. Geben Sie eine **Search Query** ein, die den Import auf Ihre eigenen Assets beschränkt, zum Beispiel `host.autonomous_system.asn: ` oder `host.ip: 203.0.113.0/24`. +5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo erstellt für jeden Host einen Eintrag und importiert dessen exponierte Dienste als Befunde. diff --git a/docs/content/connectors/toolreference/censys.es.md b/docs/content/connectors/toolreference/censys.es.md new file mode 100644 index 00000000000..52873e0a11e --- /dev/null +++ b/docs/content/connectors/toolreference/censys.es.md @@ -0,0 +1,28 @@ +--- +title: "Censys" +description: "Cómo configurar el Conector Upstream de Censys para DefectDojo" +weight: 32 +audience: pro +--- +El conector de Censys lee activos de tipo host desde Censys Platform e importa los servicios expuestos de cada host como hallazgos. Usa la API de búsqueda global de Censys Platform para enumerar los hosts a los que lo delimite. + +#### Prerrequisitos + +Necesitará una cuenta de Censys **Platform** con acceso a la API: + +* Un **Personal Access Token**, creado en Censys Platform Console, en Personal Access Tokens. +* Su **Organization ID**, que se muestra en la misma página de configuración bajo "Current Organization". El acceso de la API al endpoint de búsqueda requiere una organización, por lo que se necesita un plan Starter o superior. Los tokens del plan gratuito no tienen Organization ID y no pueden usar la API de búsqueda. + +Los datos de CVE y riesgo por host solo están disponibles en los planes Censys Core (enterprise), por lo que en planes inferiores los hallazgos representan servicios expuestos en lugar de vulnerabilidades. + +Consulte la [documentación de la API de Censys Platform](https://docs.censys.com/reference/get-started) para obtener más información. + +#### Asignaciones del conector + +1. Ingrese `https://api.platform.censys.io` en el campo **Location**. +2. Ingrese su Personal Access Token en el campo **API Key**. +3. Ingrese su **Organization ID**. +4. Ingrese una **Search Query** que delimite la importación a sus propios activos, por ejemplo `host.autonomous_system.asn: ` o `host.ip: 203.0.113.0/24`. +5. Opcionalmente, configure una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo crea un Registro para cada host e importa sus servicios expuestos como hallazgos. diff --git a/docs/content/connectors/toolreference/censys.fr.md b/docs/content/connectors/toolreference/censys.fr.md new file mode 100644 index 00000000000..39e8b10ec06 --- /dev/null +++ b/docs/content/connectors/toolreference/censys.fr.md @@ -0,0 +1,28 @@ +--- +title: "Censys" +description: "Comment configurer le Connecteur Upstream Censys pour DefectDojo" +weight: 32 +audience: pro +--- +Le connecteur Censys lit les actifs de type host depuis la Censys Platform et importe les services exposés de chaque host sous forme de constatations. Il utilise l'API de recherche globale de la Censys Platform pour énumérer les hosts sur lesquels vous le limitez. + +#### Prérequis + +Vous aurez besoin d'un compte Censys **Platform** avec accès API : + +* Un **Personal Access Token**, créé dans la Censys Platform Console sous Personal Access Tokens. +* Votre **Organization ID**, affiché sur la même page de paramètres sous « Current Organization ». L'accès API au point de terminaison de recherche nécessite une organisation ; un abonnement Starter ou supérieur est donc requis. Les jetons de niveau gratuit n'ont pas d'Organization ID et ne peuvent pas utiliser l'API de recherche. + +Les données de CVE et de risque par host ne sont disponibles que sur les abonnements Censys Core (entreprise) ; sur les niveaux inférieurs, les constatations représentent donc des services exposés plutôt que des vulnérabilités. + +Consultez la [documentation de l'API Censys Platform](https://docs.censys.com/reference/get-started) pour plus d'informations. + +#### Mappages du Connecteur + +1. Saisissez `https://api.platform.censys.io` dans le champ **Location**. +2. Saisissez votre Personal Access Token dans le champ **API Key**. +3. Saisissez votre **Organization ID**. +4. Saisissez une **Search Query** qui limite l'import à vos propres actifs, par exemple `host.autonomous_system.asn: ` ou `host.ip: 203.0.113.0/24`. +5. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +DefectDojo crée un Enregistrement pour chaque host et importe ses services exposés sous forme de constatations. diff --git a/docs/content/connectors/toolreference/censys.ja.md b/docs/content/connectors/toolreference/censys.ja.md new file mode 100644 index 00000000000..603c004cc59 --- /dev/null +++ b/docs/content/connectors/toolreference/censys.ja.md @@ -0,0 +1,28 @@ +--- +title: "Censys" +description: "DefectDojo で Censys の Upstream Connector をセットアップする方法" +weight: 32 +audience: pro +--- +Censys コネクタは Censys Platform からホストアセットを読み取り、各ホストの公開サービスを検出事項としてインポートします。スコープ対象のホストを列挙するために Censys Platform のグローバル検索 API を使用します。 + +#### Prerequisites + +API アクセスを備えた Censys **Platform** アカウントが必要です。 + +* Censys Platform Console の Personal Access Tokens で作成した**Personal Access Token**。 +* 同じ設定ページの「Current Organization」に表示される**Organization ID**。search エンドポイントへの API アクセスには組織が必要なため、Starter 以上のティアが必要です。無料ティアのトークンには organization ID がなく、search API を利用できません。 + +ホストごとの CVE およびリスクデータは Censys Core(エンタープライズ)ティアでのみ利用可能なため、それより下位のティアでは検出事項は脆弱性ではなく公開サービスを表します。 + +詳細は [Censys Platform API documentation](https://docs.censys.com/reference/get-started) を参照してください。 + +#### Connector Mappings + +1. **Location** フィールドに `https://api.platform.censys.io` を入力します。 +2. **API Key** フィールドに Personal Access Token を入力します。 +3. **Organization ID** を入力します。 +4. インポート対象を自社のアセットに絞り込む**Search Query**を入力します。例: `host.autonomous_system.asn: ` や `host.ip: 203.0.113.0/24`。 +5. 必要に応じて、インポートする検出事項を制限するために **Minimum Severity** を設定します。 + +DefectDojo はホストごとにレコードを作成し、その公開サービスを検出事項としてインポートします。 diff --git a/docs/content/connectors/toolreference/censys.md b/docs/content/connectors/toolreference/censys.md new file mode 100644 index 00000000000..98d0e076ecf --- /dev/null +++ b/docs/content/connectors/toolreference/censys.md @@ -0,0 +1,28 @@ +--- +title: "Censys" +description: "How to set up the Censys Upstream Connector for DefectDojo" +weight: 32 +audience: pro +--- +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: ` 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. diff --git a/docs/content/connectors/toolreference/checkmarx_one.de.md b/docs/content/connectors/toolreference/checkmarx_one.de.md new file mode 100644 index 00000000000..462cbd4b752 --- /dev/null +++ b/docs/content/connectors/toolreference/checkmarx_one.de.md @@ -0,0 +1,37 @@ +--- +title: "Checkmarx ONE" +description: "Einrichtung des Checkmarx ONE Upstream-Connectors für DefectDojo" +weight: 33 +audience: pro +--- +Der Checkmarx-ONE-Connector von DefectDojo ruft die Checkmarx-API auf, um Daten abzurufen. + +#### **Connector-Zuordnungen** + +1. Geben Sie Ihren **Tenant Name** in das Feld **Checkmarx Tenant** ein. Dieser Name sollte auf der Checkmarx-ONE-Anmeldeseite oben rechts sichtbar sein: +" Tenant: \<**Ihr Tenant-Name**\> " +​ +![image](images/connectors_tool_reference_2.png) + +2. Geben Sie einen gültigen API-Schlüssel ein. Möglicherweise müssen Sie einen neuen generieren: siehe [Checkmarx-API-Dokumentation](https://docs.checkmarx.com/en/34965-68618-generating-an-api-key.html#UUID-f3b6481c-47f4-6cd8-9f0d-990896e36cd6_UUID-39ccc262-c7cb-5884-52ed-e1692a635e08) für Einzelheiten. +3. Geben Sie Ihren Tenant-Standort in das Feld **Location** ein. Diese URL ist wie folgt aufgebaut: +​`https://.ast.checkmarx.net/` . Ihre Region finden Sie am Anfang Ihrer Checkmarx-URL, wenn Sie die Checkmarx-App verwenden. **** ist der primäre US-Server (ohne Regionspräfix). + +#### **Branch-Handhabung** + +Standardmäßig importiert jeder Sync die Befunde des **einzigen zuletzt abgeschlossenen Scans** eines Projekts, unabhängig vom Branch. Wenn Ihre CI viele Branches scannt, „gewinnt" bei diesem Sync der Branch, der zuletzt gescannt wurde: Befunde, die nur auf anderen Branches existieren, werden nicht importiert, und der Close-Old-Abgleich des Syncs kann Befunde hin- und herwechselnd öffnen und schließen, je nachdem, welcher Branch gerade der aktuellste Scan ist. + +Zwei optionale Felder steuern dieses Verhalten: + +- **Branch**: fixiert jedes Projekt auf einen Branch-Namen — es werden nur Scans dieses Branches importiert. Dies ist ein einziger globaler Wert für den gesamten Connector und eignet sich daher für Umgebungen, in denen jedes Projekt denselben langlebigen Branch verwendet (z. B. `main`). + - Ein **Platzhalter `*`** wird unterstützt. Ein Branch-Wert, der `*` enthält, wählt über *jeden* passenden Branch statt nur einen aus — zum Beispiel importiert `release/*` jeden Release-Branch, und `*` erfasst jeden Branch. In Kombination mit **Track Scanned Branches** lässt sich damit eine Gruppe von Branches verfolgen, ohne alle einzeln zu verfolgen. + - Wenn ein Platzhalter innerhalb des Scan-Fensters **keinen** Branch trifft, wird dieser Sync **übersprungen**, statt als „der Branch hat keine Befunde" behandelt zu werden — sodass ein Muster, das vorübergehend auf nichts passt, nicht alle Befunde des Assets schließen kann. +- **Track Scanned Branches**: Wenn aktiviert, findet jeder Sync jeden Branch mit einem abgeschlossenen Scan in der jüngsten Scan-Historie des Projekts und importiert **den letzten abgeschlossenen Scan jedes Branches**, einen erneuten Import pro Branch. Die Befunde jedes Branches liegen in einem eigenen Engagement auf dem zugeordneten Asset mit dem Namen „\ \- \", sodass das Schließen veralteter Befunde pro Branch erfolgt: Ein in einen Branch gemergter Fix kann niemals die Befunde eines anderen Branches schließen. Der primäre Branch des Projekts (laut Checkmarx) wird zuerst importiert, sodass erneute Auftritte desselben Befunds auf anderen Branches mit dem Original des primären Branches dedupliziert werden. + +Hinweise zu **Track Scanned Branches**: + +- **Prüfen Sie, welcher Standard für Sie gilt.** Branch-Tracking ist bei **Neuinstallationen standardmäßig aktiviert**. Installationen von vor dieser Änderung behalten ihr bisheriges Verhalten bei, sodass der Schalter dort deaktiviert bleibt, bis ihn jemand einschaltet. +- Wenn beide Felder gesetzt sind, wird nur der fixierte **Branch** verfolgt — auch wenn dieser Branch-Wert ein Platzhaltermuster ist; in diesem Fall wird jeder passende Branch verfolgt. +- Ein Branch, der nicht mehr gescannt wird (gemergt oder gelöscht), erhält keine Updates mehr: Sein Engagement bleibt mit den zuletzt bekannten Befunden sichtbar, die Sie prüfen und gesammelt schließen können. +- Den Schalter später wieder auszuschalten ist unbedenklich: Die Branch-spezifischen Engagements erhalten dann einfach keine Importe mehr, und beim nächsten Sync wird wieder das Standard-Engagement verwendet. +- Connectors gleichen den Zustand nach dem Sync-Zeitplan ab. Branch-Tracking macht jeden Sync über alle Branches hinweg vollständig; es macht die Daten zwischen den Syncs jedoch nicht in Echtzeit verfügbar. diff --git a/docs/content/connectors/toolreference/checkmarx_one.es.md b/docs/content/connectors/toolreference/checkmarx_one.es.md new file mode 100644 index 00000000000..fe76794a3d6 --- /dev/null +++ b/docs/content/connectors/toolreference/checkmarx_one.es.md @@ -0,0 +1,37 @@ +--- +title: "Checkmarx ONE" +description: "Cómo configurar el Conector Upstream de Checkmarx ONE para DefectDojo" +weight: 33 +audience: pro +--- +El conector de Checkmarx ONE de DefectDojo llama a la API de Checkmarx para obtener datos. + +#### **Asignaciones del conector** + +1. Ingrese su **Tenant Name** en el campo **Checkmarx Tenant**. Este nombre debería ser visible en la página de inicio de sesión de Checkmarx ONE, en la esquina superior derecha: +" Tenant: \<**su nombre de tenant**\> " +​ +![imagen](images/connectors_tool_reference_2.png) + +2. Ingrese una clave de API válida. Es posible que deba generar una nueva: consulte la [documentación de la API de Checkmarx](https://docs.checkmarx.com/en/34965-68618-generating-an-api-key.html#UUID-f3b6481c-47f4-6cd8-9f0d-990896e36cd6_UUID-39ccc262-c7cb-5884-52ed-e1692a635e08) para obtener más detalles. +3. Ingrese la ubicación de su tenant en el campo **Location**. Esta URL tiene el siguiente formato: +​`https://.ast.checkmarx.net/` . Su Región se encuentra al comienzo de la URL de Checkmarx cuando usa la aplicación Checkmarx. **** es el servidor principal de EE. UU. (que no tiene prefijo de región). + +#### **Manejo de branches** + +Por defecto, cada sincronización importa los hallazgos del **único scan completado más reciente de un proyecto, sin importar el branch**. Si su CI escanea muchos branches, el branch que resulte haber escaneado en último lugar "gana" esa sincronización: los hallazgos que solo existen en otros branches no se importan, y la conciliación de cierre de antiguos de la sincronización puede hacer que los hallazgos se abran y cierren alternadamente a medida que distintos branches se turnan como el scan más reciente. + +Dos campos opcionales controlan este comportamiento: + +- **Branch**: fija cada proyecto a un único nombre de branch — solo se importan los scans de ese branch. Es un valor global único para todo el conector, por lo que se adapta a flotas donde cada proyecto usa el mismo branch de larga duración (p. ej. `main`). + - Se admite un **comodín `*`**. Un valor de Branch que contenga `*` selecciona *todos* los branches coincidentes en lugar de uno solo — por ejemplo `release/*` importa cada branch de release, y `*` coincide con todos los branches. Combinado con **Track Scanned Branches**, esta es la forma de rastrear una familia de branches sin rastrearlos todos. + - Si un comodín no coincide con **ningún** branch dentro de la ventana de escaneo, esa sincronización se **omite** en lugar de tratarse como "el branch no tiene hallazgos" — de este modo, un patrón que temporalmente no coincide con nada no puede cerrar todos los hallazgos del activo. +- **Track Scanned Branches**: cuando está habilitado, cada sincronización encuentra todos los branches con un scan completado en el historial reciente de scans del proyecto e importa **el scan completado más reciente de cada branch**, con una reimportación por branch. Los hallazgos de cada branch residen en su propio Compromiso en el activo asignado, llamado "\ \- \", por lo que el cierre de hallazgos obsoletos está delimitado por branch: una corrección fusionada en un branch nunca puede cerrar los hallazgos de otro branch. El branch principal del proyecto (según lo informado por Checkmarx) se importa primero, de modo que las reapariciones del mismo hallazgo en otros branches se deduplican contra el original del branch principal. + +Notas sobre **Track Scanned Branches**: + +- **Verifique qué valor predeterminado se aplica en su caso.** El seguimiento de branches está **habilitado por defecto para las instalaciones nuevas**. Las instalaciones anteriores al cambio conservan su comportamiento previo, por lo que la opción permanece deshabilitada para ellas hasta que alguien la active. +- Cuando ambos campos están configurados, solo se rastrea el **Branch** fijado — incluso cuando ese valor de Branch es un patrón comodín, en cuyo caso se rastrea cada branch que coincida con el patrón. +- Un branch que deja de escanearse (fusionado o eliminado) deja de recibir actualizaciones: su Compromiso permanece visible con sus últimos hallazgos conocidos, que puede revisar y cerrar en bloque. +- Deshabilitar la opción más adelante es seguro: los Compromisos por branch simplemente dejan de recibir importaciones y el Compromiso predeterminado se reanuda en la siguiente sincronización. +- Los Conectores concilian el estado según el programa de sincronización. El seguimiento de branches hace que cada sincronización sea completa entre branches; no hace que los datos sean en tiempo real entre sincronizaciones. diff --git a/docs/content/connectors/toolreference/checkmarx_one.fr.md b/docs/content/connectors/toolreference/checkmarx_one.fr.md new file mode 100644 index 00000000000..3afc2d16759 --- /dev/null +++ b/docs/content/connectors/toolreference/checkmarx_one.fr.md @@ -0,0 +1,37 @@ +--- +title: "Checkmarx ONE" +description: "Comment configurer le Connecteur Upstream Checkmarx ONE pour DefectDojo" +weight: 33 +audience: pro +--- +Le connecteur Checkmarx ONE de DefectDojo appelle l'API Checkmarx pour récupérer les données. + +#### **Mappages du Connecteur** + +1. Saisissez votre **Tenant Name** dans le champ **Checkmarx Tenant**. Ce nom doit être visible sur la page de connexion de Checkmarx ONE, dans le coin supérieur droit : +" Tenant : \<**votre nom de tenant**\> " +​ +![image](images/connectors_tool_reference_2.png) + +2. Saisissez une clé API valide. Vous devrez peut-être en générer une nouvelle : consultez la [documentation de l'API Checkmarx](https://docs.checkmarx.com/en/34965-68618-generating-an-api-key.html#UUID-f3b6481c-47f4-6cd8-9f0d-990896e36cd6_UUID-39ccc262-c7cb-5884-52ed-e1692a635e08) pour plus de détails. +3. Saisissez l'emplacement de votre tenant dans le champ **Location**. Cette URL est formatée comme suit : +​`https://.ast.checkmarx.net/` . Votre région se trouve au début de votre URL Checkmarx lorsque vous utilisez l'application Checkmarx. **** est le serveur US principal (qui n'a pas de préfixe de région). + +#### **Gestion des branches** + +Par défaut, chaque synchronisation importe les constatations du **seul scan terminé le plus récent d'un projet, quelle que soit la branche**. Si votre CI analyse de nombreuses branches, la branche qui a été analysée en dernier « remporte » cette synchronisation : les constatations qui n'existent que sur d'autres branches ne sont pas importées, et la réconciliation de fermeture des anciennes constatations lors de la synchronisation peut faire osciller des constatations entre ouvert et fermé à mesure que différentes branches deviennent tour à tour le scan le plus récent. + +Deux champs facultatifs contrôlent ce comportement : + +- **Branch** : épingle chaque projet à un nom de branche unique — seuls les scans de cette branche sont importés. Il s'agit d'une valeur globale unique pour l'ensemble du connecteur, ce qui convient aux parcs où chaque projet utilise la même branche pérenne (par ex. `main`). + - Un **caractère générique `*`** est pris en charge. Une valeur Branch contenant `*` sélectionne *toutes* les branches correspondantes plutôt qu'une seule — par exemple `release/*` importe chaque branche de release, et `*` correspond à toutes les branches. Combiné avec **Track Scanned Branches**, c'est le moyen de suivre une famille de branches sans toutes les suivre. + - Si un caractère générique ne correspond à **aucune** branche dans la fenêtre de scan, cette synchronisation est **ignorée** plutôt que traitée comme « la branche n'a aucune constatation » — ainsi, un motif qui ne correspond temporairement à rien ne peut pas fermer toutes les constatations de l'actif. +- **Track Scanned Branches** : lorsque cette option est activée, chaque synchronisation recherche toutes les branches ayant un scan terminé dans l'historique récent des scans du projet et importe **le dernier scan terminé de chaque branche**, avec une réimportation par branche. Les constatations de chaque branche vivent dans leur propre engagement sur l'actif mappé, nommé « \ \- \ », si bien que la fermeture des constatations obsolètes est limitée à chaque branche : un correctif fusionné sur une branche ne peut jamais fermer les constatations d'une autre branche. La branche principale du projet (telle que rapportée par Checkmarx) est importée en premier, de sorte que les réapparitions d'une même constatation sur d'autres branches se dédupliquent par rapport à l'originale de la branche principale. + +Remarques sur **Track Scanned Branches** : + +- **Vérifiez quel comportement par défaut s'applique à vous.** Le suivi des branches est **activé par défaut pour les nouvelles installations**. Les installations antérieures à ce changement conservent leur comportement précédent ; l'option reste donc désactivée pour elles tant que quelqu'un ne l'active pas. +- Lorsque les deux champs sont renseignés, seule la **Branch** épinglée est suivie — y compris lorsque cette valeur Branch est un motif générique, auquel cas toutes les branches correspondant au motif sont suivies. +- Une branche qui cesse d'être analysée (fusionnée ou supprimée) cesse de recevoir des mises à jour : son engagement reste visible avec ses dernières constatations connues, que vous pouvez examiner et fermer en masse. +- Désactiver l'option ultérieurement est sans risque : les engagements par branche cessent simplement de recevoir des imports, et l'engagement par défaut reprend lors de la prochaine synchronisation. +- Les Connecteurs réconcilient l'état selon le calendrier de synchronisation. Le suivi des branches rend chaque synchronisation complète à travers les branches ; il ne rend pas les données en temps réel entre deux synchronisations. diff --git a/docs/content/connectors/toolreference/checkmarx_one.ja.md b/docs/content/connectors/toolreference/checkmarx_one.ja.md new file mode 100644 index 00000000000..935c9c2a4a6 --- /dev/null +++ b/docs/content/connectors/toolreference/checkmarx_one.ja.md @@ -0,0 +1,37 @@ +--- +title: "Checkmarx ONE" +description: "DefectDojo で Checkmarx ONE の Upstream Connector をセットアップする方法" +weight: 33 +audience: pro +--- +DefectDojo の Checkmarx ONE コネクタは、データを取得するために Checkmarx の API を呼び出します。 + +#### **Connector Mappings** + +1. **Checkmarx Tenant** フィールドに**Tenant Name** を入力します。この名前は Checkmarx ONE のログインページの右上に表示されているはずです。 +" Tenant: \<**your tenant name**\> " +​ +![image](images/connectors_tool_reference_2.png) + +2. 有効な API キーを入力します。新しく生成する必要がある場合があります。詳細は [Checkmarx API Documentation](https://docs.checkmarx.com/en/34965-68618-generating-an-api-key.html#UUID-f3b6481c-47f4-6cd8-9f0d-990896e36cd6_UUID-39ccc262-c7cb-5884-52ed-e1692a635e08) を参照してください。 +3. **Location** フィールドにテナントの場所を入力します。この URL は次の形式です。 +​`https://.ast.checkmarx.net/`。リージョンは、Checkmarx アプリ利用時の Checkmarx URL の先頭に表示されます。**** は主要な US サーバーです(リージョンプレフィックスはありません)。 + +#### **Branch handling** + +デフォルトでは、各同期はブランチに関わらず、プロジェクトの**直近の完了済みスキャン 1 件のみ**の検出事項をインポートします。CI で多数のブランチをスキャンしている場合、たまたま最後にスキャンされたブランチがその同期で「勝ち」となります。他のブランチにのみ存在する検出事項はインポートされず、同期のクローズ処理(close-old reconciliation)によって、異なるブランチが交互に最新スキャンになるたびに検出事項が開いたり閉じたりを繰り返すことがあります。 + +この動作を制御する 2 つのオプションフィールドがあります。 + +- **Branch**: すべてのプロジェクトを 1 つのブランチ名に固定します。そのブランチのスキャンのみがインポートされます。これはコネクタ全体に対する単一のグローバル値であるため、すべてのプロジェクトが同じ長期運用ブランチ(例えば `main`)を使用しているフリート向けです。 + - **`*` ワイルドカード**に対応しています。`*` を含む Branch 値は、単一のブランチではなく*一致するすべてのブランチ*を対象とします。例えば `release/*` は各リリースブランチをインポートし、`*` はすべてのブランチにマッチします。**Track Scanned Branches** と組み合わせることで、すべてを個別に追跡することなく、一群のブランチを追跡する方法になります。 + - ワイルドカードがスキャンウィンドウ内で**どのブランチにもマッチしない**場合、その同期は「ブランチに検出事項がない」として扱われるのではなく**スキップ**されます。これにより、一時的に何にもマッチしないパターンが、アセット上のすべての検出事項をクローズしてしまうことを防ぎます。 +- **Track Scanned Branches**: 有効にすると、各同期はプロジェクトの直近のスキャン履歴の中から完了済みスキャンを持つすべてのブランチを検出し、**各ブランチの最新の完了済みスキャン**をインポートします(ブランチごとに 1 回の再インポート)。各ブランチの検出事項は、マッピングされたアセット上の「\ \- \」という名前の独自のエンゲージメントに格納されるため、古い検出事項のクローズ処理はブランチ単位でスコープされます。あるブランチにマージされた修正が、別のブランチの検出事項をクローズすることはありません。プロジェクトの主要ブランチ(Checkmarx が報告するもの)が最初にインポートされるため、他のブランチで同じ検出事項が再発した場合、主要ブランチのオリジナルと重複排除されます。 + +**Track Scanned Branches** に関する注意点: + +- **自分にどのデフォルトが適用されるか確認してください。** ブランチ追跡は**新規インストールではデフォルトで有効**です。この変更より前から存在するインストールは従来の動作を維持するため、誰かがトグルを有効にするまでオフのままです。 +- 両方のフィールドが設定されている場合、追跡されるのは固定された **Branch** のみです。その Branch 値がワイルドカードパターンである場合も同様で、その場合はパターンに一致するすべてのブランチが追跡されます。 +- スキャンされなくなった(マージまたは削除された)ブランチは更新を受け取らなくなります。そのエンゲージメントは最後に判明している検出事項とともに表示され続けるため、レビューして一括でクローズできます。 +- 後でトグルをオフにしても安全です。ブランチごとのエンゲージメントはインポートを受け取らなくなり、次の同期からデフォルトのエンゲージメントが再開されます。 +- Connector は同期スケジュールに沿って状態を突き合わせます。ブランチ追跡は各同期をブランチ横断で完結させるものであり、同期と同期の間のデータをリアルタイム化するものではありません。 diff --git a/docs/content/connectors/toolreference/checkmarx_one.md b/docs/content/connectors/toolreference/checkmarx_one.md new file mode 100644 index 00000000000..9baa24f75fd --- /dev/null +++ b/docs/content/connectors/toolreference/checkmarx_one.md @@ -0,0 +1,37 @@ +--- +title: "Checkmarx One" +description: "How to set up the Checkmarx One Upstream Connector for DefectDojo" +weight: 33 +audience: pro +--- +DefectDojo's Checkmarx One connector calls the Checkmarx API to fetch data. + +#### **Connector Mappings** + +1. Enter your **Tenant Name** in the **Checkmarx Tenant** field. This name should be visible on the Checkmarx One login page in the top\-right hand corner: +" Tenant: \<**your tenant name**\> " +​ +![image](images/connectors_tool_reference_2.png) + +2. Enter a valid API key. You may need to generate a new one: see [Checkmarx API Documentation](https://docs.checkmarx.com/en/34965-68618-generating-an-api-key.html#UUID-f3b6481c-47f4-6cd8-9f0d-990896e36cd6_UUID-39ccc262-c7cb-5884-52ed-e1692a635e08) for details. +3. Enter your tenant location in the **Location** field. This URL is formatted as follows: +​`https://.ast.checkmarx.net/` . Your Region can be found at the beginning of your Checkmarx URL when using the Checkmarx app. **** is the primary US server (which has no region prefix). + +#### **Branch handling** + +By default, each sync imports the findings of a project's **single most recent completed scan, regardless of branch**. If your CI scans many branches, whichever branch happened to scan last "wins" that sync: findings that only exist on other branches are not imported, and the sync's close-old reconciliation can churn findings open and closed as different branches take turns being the latest scan. + +Two optional fields control this behavior: + +- **Branch**: pins every project to one branch name — only scans of that branch are imported. This is a single global value for the whole connector, so it fits fleets where every project uses the same long-lived branch (e.g. `main`). + - A **`*` wildcard** is supported. A Branch value containing `*` selects across *every* matching branch rather than a single one — for example `release/*` imports each release branch, and `*` matches every branch. Combined with **Track Scanned Branches**, this is the way to track a family of branches without tracking all of them. + - If a wildcard matches **no** branch within the scan window, that sync is **skipped** rather than treated as "the branch has no findings" — so a pattern that temporarily matches nothing cannot close every finding on the asset. +- **Track Scanned Branches**: when enabled, each sync finds every branch with a completed scan in the project's recent scan history and imports **the latest completed scan of each branch**, one reimport per branch. Each branch's findings live in their own engagement on the mapped asset, named "\ \- \", so closing stale findings is scoped per branch: a fix merged to one branch can never close another branch's findings. The project's primary branch (as reported by Checkmarx) is imported first, so re-occurrences of the same finding on other branches deduplicate against the primary branch's original. + +Notes on **Track Scanned Branches**: + +- **Check which default applies to you.** Branch tracking is **on by default for new installations**. Installations that predate the change keep their previous behavior, so the toggle is off for them until someone turns it on. +- When both fields are set, only the pinned **Branch** is tracked — including when that Branch value is a wildcard pattern, in which case every branch matching the pattern is tracked. +- A branch that stops being scanned (merged or deleted) stops receiving updates: its engagement remains visible with its last-known findings, which you can review and close in bulk. +- Turning the toggle off later is safe: per-branch engagements simply stop receiving imports and the default engagement resumes on the next sync. +- Connectors reconcile state on the sync schedule. Branch tracking makes each sync complete across branches; it does not make data real-time between syncs. diff --git a/docs/content/connectors/toolreference/chef_automate.md b/docs/content/connectors/toolreference/chef_automate.md new file mode 100644 index 00000000000..a2098a77b52 --- /dev/null +++ b/docs/content/connectors/toolreference/chef_automate.md @@ -0,0 +1,19 @@ +--- +title: "Chef Automate" +description: "How to set up the Chef Automate Upstream Connector for DefectDojo" +weight: 34 +audience: pro +--- +The Chef Automate connector imports **InSpec compliance findings**. DefectDojo groups the nodes Chef Automate reports on by their **environment**, and creates a Record for each environment. + +#### Prerequisites + +A Chef Automate **API token**. It is never logged. + +#### Connector Mappings + +1. Enter your Chef Automate server URL in the **Location** field. +2. Enter the API token in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each environment becomes a Record, carrying the **failed** InSpec controls from each of its nodes' **latest** compliance runs. Passing and skipped controls are not imported, so the finding list is your outstanding compliance work rather than a full control inventory. diff --git a/docs/content/connectors/toolreference/ci_fuzz.md b/docs/content/connectors/toolreference/ci_fuzz.md new file mode 100644 index 00000000000..b27489a3e8b --- /dev/null +++ b/docs/content/connectors/toolreference/ci_fuzz.md @@ -0,0 +1,19 @@ +--- +title: "CI Fuzz" +description: "How to set up the CI Fuzz Upstream Connector for DefectDojo" +weight: 35 +audience: pro +--- +The CI Fuzz connector imports **fuzzing findings** from Code Intelligence CI Fuzz. DefectDojo creates a Record for each CI Fuzz **project**. + +#### Prerequisites + +A CI Fuzz **API token**, sent as a bearer token and never logged. + +#### Connector Mappings + +1. Enter `https://app.code-intelligence.com` in the **Location** field. +2. Enter the API token in the **API Token** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each CI Fuzz project becomes a Record, carrying that project's fuzzing findings. diff --git a/docs/content/connectors/toolreference/cloudflare.de.md b/docs/content/connectors/toolreference/cloudflare.de.md new file mode 100644 index 00000000000..59951e0d710 --- /dev/null +++ b/docs/content/connectors/toolreference/cloudflare.de.md @@ -0,0 +1,19 @@ +--- +title: "Cloudflare" +description: "Einrichtung des Cloudflare Upstream-Connectors für DefectDojo" +weight: 36 +audience: pro +--- +Der Cloudflare-Connector importiert **Security-Center-Insights** — Probleme mit der Sicherheitslage, die Cloudflare zu Ihrem Konto und Ihren Zonen aufzeigt, etwa einen fehlenden DMARC-Eintrag, nicht aktiviertes DNSSEC oder ein Zertifikatsproblem. DefectDojo erstellt für jede Zone (Domain) mit offenen Insights einen Eintrag, plus einen Eintrag auf Kontoebene für Insights, die keiner bestimmten Zone zugeordnet sind. + +#### Voraussetzungen + +Sie benötigen ein Cloudflare-**API-Token** (nicht den veralteten Global API Key). Erstellen Sie eines im Cloudflare-Dashboard unter **My Profile > API Tokens > Create Token**. Die schnellste Option ist die Vorlage **„Read all resources"**; für ein Token mit minimalen Rechten gewähren Sie **Zone > Zone > Read** (alle Zonen) sowie kontoweiten Lesezugriff für Security Center. + +#### Connector-Zuordnungen + +1. Geben Sie `https://api.cloudflare.com/client/v4` in das Feld **Location** ein. +2. Geben Sie das API-Token in das Feld **Secret** ein. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo ermittelt automatisch die Konten und Zonen, auf die das Token zugreifen kann — es ist keine Konto-ID erforderlich. Es werden nur offene (aktive, nicht verworfene) Insights importiert, sodass Insights, die Sie in Cloudflare beheben oder verwerfen, beim nächsten Sync automatisch in DefectDojo als behoben markiert werden. diff --git a/docs/content/connectors/toolreference/cloudflare.es.md b/docs/content/connectors/toolreference/cloudflare.es.md new file mode 100644 index 00000000000..52663367e4e --- /dev/null +++ b/docs/content/connectors/toolreference/cloudflare.es.md @@ -0,0 +1,19 @@ +--- +title: "Cloudflare" +description: "Cómo configurar el Conector Upstream de Cloudflare para DefectDojo" +weight: 36 +audience: pro +--- +El conector de Cloudflare importa **Security Center insights** — problemas de postura de seguridad que Cloudflare identifica sobre su cuenta y sus zonas, como un registro DMARC faltante, DNSSEC no habilitado o un problema de certificado. DefectDojo crea un Registro para cada zona (dominio) que tenga insights abiertos, además de un Registro a nivel de cuenta para los insights que no están asociados a una zona específica. + +#### Prerrequisitos + +Necesitará un **API token** de Cloudflare (no la Global API Key heredada). Cree uno en **My Profile > API Tokens > Create Token** dentro del panel de Cloudflare. La opción más rápida es la plantilla **"Read all resources"**; para un token con privilegios mínimos, otorgue **Zone > Zone > Read** (todas las zonas) más acceso de lectura a nivel de cuenta para Security Center. + +#### Asignaciones del conector + +1. Ingrese `https://api.cloudflare.com/client/v4` en el campo **Location**. +2. Ingrese el API token en el campo **Secret**. +3. Opcionalmente, configure una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo autodescubre las cuentas y zonas a las que el token tiene acceso — no se requiere un ID de cuenta. Solo se importan los insights abiertos (activos, no descartados), por lo que los insights que resuelva o descarte en Cloudflare se marcan automáticamente como Mitigado en DefectDojo en la siguiente sincronización. diff --git a/docs/content/connectors/toolreference/cloudflare.fr.md b/docs/content/connectors/toolreference/cloudflare.fr.md new file mode 100644 index 00000000000..e4aa28dd893 --- /dev/null +++ b/docs/content/connectors/toolreference/cloudflare.fr.md @@ -0,0 +1,19 @@ +--- +title: "Cloudflare" +description: "Comment configurer le Connecteur Upstream Cloudflare pour DefectDojo" +weight: 36 +audience: pro +--- +Le connecteur Cloudflare importe les **insights Security Center** — des problèmes de posture de sécurité que Cloudflare signale sur votre compte et vos zones, comme un enregistrement DMARC manquant, le DNSSEC non activé, ou un problème de certificat. DefectDojo crée un Enregistrement pour chaque zone (domaine) ayant des insights ouverts, ainsi qu'un Enregistrement au niveau du compte pour les insights qui ne sont liés à aucune zone spécifique. + +#### Prérequis + +Vous aurez besoin d'un **jeton API** Cloudflare (et non de l'ancienne Global API Key). Créez-en un sous **My Profile > API Tokens > Create Token** dans le tableau de bord Cloudflare. L'option la plus rapide est le modèle **« Read all resources »** ; pour un jeton à privilège minimal, accordez **Zone > Zone > Read** (toutes les zones) ainsi qu'un accès en lecture au niveau du compte pour Security Center. + +#### Mappages du Connecteur + +1. Saisissez `https://api.cloudflare.com/client/v4` dans le champ **Location**. +2. Saisissez le jeton API dans le champ **Secret**. +3. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +DefectDojo découvre automatiquement les comptes et zones auxquels le jeton a accès — aucun ID de compte n'est requis. Seuls les insights ouverts (actifs, non ignorés) sont importés ; les insights que vous résolvez ou ignorez dans Cloudflare sont donc automatiquement atténués dans DefectDojo lors de la prochaine synchronisation. diff --git a/docs/content/connectors/toolreference/cloudflare.ja.md b/docs/content/connectors/toolreference/cloudflare.ja.md new file mode 100644 index 00000000000..66ea8286141 --- /dev/null +++ b/docs/content/connectors/toolreference/cloudflare.ja.md @@ -0,0 +1,19 @@ +--- +title: "Cloudflare" +description: "DefectDojo で Cloudflare の Upstream Connector をセットアップする方法" +weight: 36 +audience: pro +--- +Cloudflare コネクタは**Security Center insights** をインポートします。これは、DMARC レコードの欠落、DNSSEC が有効化されていない、証明書の問題など、Cloudflare がアカウントとゾーンについて表示するセキュリティ体制上の問題です。DefectDojo は、未解決の insight を持つゾーン(ドメイン)ごとにレコードを作成し、特定のゾーンに紐づかない insight についてはアカウントレベルのレコードを作成します。 + +#### Prerequisites + +Cloudflare の**API トークン**(従来の Global API Key ではない)が必要です。Cloudflare ダッシュボードの **My Profile > API Tokens > Create Token** で作成してください。最も手軽な方法は**「Read all resources」**テンプレートです。最小権限のトークンにする場合は、**Zone > Zone > Read**(すべてのゾーン)に加えて、Security Center 用のアカウントレベルの読み取りアクセスを付与してください。 + +#### Connector Mappings + +1. **Location** フィールドに `https://api.cloudflare.com/client/v4` を入力します。 +2. **Secret** フィールドに API トークンを入力します。 +3. 必要に応じて、インポートする検出事項を制限するために **Minimum Severity** を設定します。 + +DefectDojo は、トークンがアクセスできるアカウントとゾーンを自動検出します。アカウント ID は不要です。未解決(アクティブで、却下されていない)の insight のみがインポートされるため、Cloudflare 上で解決または却下した insight は、次の同期で DefectDojo 上でも自動的に緩和済みになります。 diff --git a/docs/content/connectors/toolreference/cloudflare.md b/docs/content/connectors/toolreference/cloudflare.md new file mode 100644 index 00000000000..b2b49586f0b --- /dev/null +++ b/docs/content/connectors/toolreference/cloudflare.md @@ -0,0 +1,19 @@ +--- +title: "Cloudflare" +description: "How to set up the Cloudflare Upstream Connector for DefectDojo" +weight: 36 +audience: pro +--- +The Cloudflare connector imports **Security Center insights** — security posture issues Cloudflare surfaces about your account and zones, such as a missing DMARC record, DNSSEC not being enabled, or a certificate problem. DefectDojo creates a Record for each zone (domain) that has open insights, plus an account-level Record for insights that are not tied to a specific zone. + +#### Prerequisites + +You will need a Cloudflare **API token** (not the legacy Global API Key). Create one under **My Profile > API Tokens > Create Token** in the Cloudflare dashboard. The quickest option is the **"Read all resources"** template; for a least-privilege token, grant **Zone > Zone > Read** (all zones) plus account-level read access for Security Center. + +#### Connector Mappings + +1. Enter `https://api.cloudflare.com/client/v4` in the **Location** field. +2. Enter the API token in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo auto-discovers the accounts and zones the token can access — no account ID is required. Only open (active, non-dismissed) insights are imported, so insights you resolve or dismiss in Cloudflare are automatically mitigated in DefectDojo on the next sync. diff --git a/docs/content/connectors/toolreference/cobalt_io.de.md b/docs/content/connectors/toolreference/cobalt_io.de.md new file mode 100644 index 00000000000..a2d54bf901b --- /dev/null +++ b/docs/content/connectors/toolreference/cobalt_io.de.md @@ -0,0 +1,19 @@ +--- +title: "Cobalt.io" +description: "Einrichtung des Cobalt.io Upstream-Connectors für DefectDojo" +weight: 37 +audience: pro +--- +Der Cobalt.io-Connector verwendet die Cobalt.io-API (v2), um Pentest-Befunde aus Ihrer Cobalt.io-Organisation abzurufen. DefectDojo ermittelt jede Organisation, auf die Ihr API-Token zugreifen kann, und erstellt für jedes **Asset** (die Einheit, die Cobalt pentestet) einen separaten Eintrag. + +#### Voraussetzungen + +Sie benötigen ein persönliches Cobalt.io-**API-Token**. Wir empfehlen, für DefectDojo ein dediziertes Service-Konto anzulegen, um automatisierte Aktivitäten klar von manuellen Team-Aktionen zu unterscheiden. Generieren Sie ein Token unter **Settings \> API Tokens** in der Cobalt.io-Oberfläche. Organisations-Tokens werden automatisch ermittelt \- Sie müssen sie nicht angeben. + +#### Connector-Zuordnungen + +1. Geben Sie die Basis-URL der Cobalt.io-API in das Feld **Location** ein: `https://api.cobalt.io` (oder Ihren regionalen Host, zum Beispiel `https://api.us.cobalt.io`). +2. Geben Sie Ihr **persönliches API-Token** in das Feld **Secret** ein. +3. Geben Sie optional ein **Organization Token** ein, um den Sync auf eine einzelne Organisation zu beschränken. Bleibt das Feld leer, synchronisiert DefectDojo jede Organisation, auf die das persönliche API-Token zugreifen kann. + +DefectDojo ordnet jedes Cobalt.io-**Asset** als separaten Eintrag zu. Für jedes zugeordnete Asset werden Befunde importiert, wobei deren Cobalt.io-Status (zum Beispiel `valid_fix`, `wont_fix`, `invalid`) den Befundstatus in DefectDojo bestimmt. diff --git a/docs/content/connectors/toolreference/cobalt_io.es.md b/docs/content/connectors/toolreference/cobalt_io.es.md new file mode 100644 index 00000000000..a0c34068726 --- /dev/null +++ b/docs/content/connectors/toolreference/cobalt_io.es.md @@ -0,0 +1,19 @@ +--- +title: "Cobalt.io" +description: "Cómo configurar el Conector Upstream de Cobalt.io para DefectDojo" +weight: 37 +audience: pro +--- +El conector de Cobalt.io utiliza la API de Cobalt.io (v2) para extraer los hallazgos de pentest de su organización de Cobalt.io. DefectDojo detecta todas las organizaciones a las que su token de API tiene acceso y crea un Registro independiente para cada **activo** (la unidad que Cobalt somete a pentest). + +#### Requisitos previos + +Necesitará un **token de API personal** de Cobalt.io. Recomendamos crear una cuenta de servicio dedicada para DefectDojo, de modo que la actividad automatizada se distinga claramente de las acciones manuales del equipo. Genere un token desde **Settings \> API Tokens** en la interfaz de Cobalt.io. Los tokens de organización se detectan automáticamente \- no es necesario proporcionarlos. + +#### Asignaciones del conector + +1. Introduzca la URL base de la API de Cobalt.io en el campo **Location**: `https://api.cobalt.io` (o el host de su región, por ejemplo `https://api.us.cobalt.io`). +2. Introduzca su **token de API personal** en el campo **Secret**. +3. De forma opcional, introduzca un **Organization Token** para fijar la sincronización a una sola organización. Si se deja en blanco, DefectDojo sincroniza todas las organizaciones a las que el token de API personal tiene acceso. + +DefectDojo asigna cada **activo** de Cobalt.io como un Registro independiente. Los hallazgos se importan para cada activo asignado, y su estado en Cobalt.io (por ejemplo, `valid_fix`, `wont_fix`, `invalid`) determina el estado del hallazgo en DefectDojo. diff --git a/docs/content/connectors/toolreference/cobalt_io.fr.md b/docs/content/connectors/toolreference/cobalt_io.fr.md new file mode 100644 index 00000000000..29ba2cdefb6 --- /dev/null +++ b/docs/content/connectors/toolreference/cobalt_io.fr.md @@ -0,0 +1,19 @@ +--- +title: "Cobalt.io" +description: "Comment configurer le Connecteur Upstream Cobalt.io pour DefectDojo" +weight: 37 +audience: pro +--- +Le connecteur Cobalt.io utilise l'API Cobalt.io (v2) pour récupérer les résultats de pentest de votre organisation Cobalt.io. DefectDojo découvre chaque organisation à laquelle votre jeton d'API a accès et crée un enregistrement distinct pour chaque **actif** (l'unité que Cobalt teste). + +#### Prérequis + +Vous aurez besoin d'un **jeton d'API personnel** Cobalt.io. Nous recommandons de créer un compte de service dédié pour DefectDojo afin de distinguer clairement l'activité automatisée des actions manuelles de l'équipe. Générez un jeton depuis **Settings \> API Tokens** dans l'interface Cobalt.io. Les jetons d'organisation sont découverts automatiquement \- vous n'avez pas besoin de les fournir. + +#### Mappages du connecteur + +1. Saisissez l'URL de base de l'API Cobalt.io dans le champ **Location** : `https://api.cobalt.io` (ou votre hôte régional, par exemple `https://api.us.cobalt.io`). +2. Saisissez votre **jeton d'API personnel** dans le champ **Secret**. +3. Facultativement, saisissez un **Organization Token** pour limiter la synchronisation à une seule organisation. Si ce champ est laissé vide, DefectDojo synchronise toutes les organisations auxquelles le jeton d'API personnel a accès. + +DefectDojo associe chaque **actif** Cobalt.io à un enregistrement distinct. Les constatations sont importées pour chaque actif associé, leur état Cobalt.io (par exemple `valid_fix`, `wont_fix`, `invalid`) déterminant le statut de la constatation dans DefectDojo. diff --git a/docs/content/connectors/toolreference/cobalt_io.ja.md b/docs/content/connectors/toolreference/cobalt_io.ja.md new file mode 100644 index 00000000000..b3550affb62 --- /dev/null +++ b/docs/content/connectors/toolreference/cobalt_io.ja.md @@ -0,0 +1,19 @@ +--- +title: "Cobalt.io" +description: "DefectDojo で Cobalt.io の Upstream Connector をセットアップする方法" +weight: 37 +audience: pro +--- +Cobalt.ioコネクタは、Cobalt.io API（v2）を使用して、Cobalt.io組織からペネトレーションテストの検出事項を取得します。DefectDojoは、APIトークンでアクセスできるすべての組織を検出し、Cobaltがペネトレーションテストを行う単位である**アセット**ごとに個別のレコードを作成します。 + +#### Prerequisites + +Cobalt.ioの**個人用APIトークン**が必要です。自動化された操作とチームによる手動操作を明確に区別できるよう、DefectDojo専用のサービスアカウントを作成することをお勧めします。Cobalt.io UIの**Settings > API Tokens**からトークンを生成してください。組織トークンは自動的に検出されるため、指定する必要はありません。 + +#### Connector Mappings + +1. **Location**フィールドにCobalt.io APIのベースURLを入力します: `https://api.cobalt.io`（またはリージョンごとのホスト、例: `https://api.us.cobalt.io`）。 +2. **Secret**フィールドに**個人用APIトークン**を入力します。 +3. 必要に応じて、同期を単一の組織に固定するために**Organization Token**を入力します。空欄のままにした場合、DefectDojoは個人用APIトークンがアクセスできるすべての組織を同期します。 + +DefectDojoは、Cobalt.ioの各**アセット**を個別のレコードとしてマッピングします。マッピングされた各アセットについて検出事項がインポートされ、Cobalt.io側のステータス（例: `valid_fix`、`wont_fix`、`invalid`）によってDefectDojo内の検出事項のステータスが決まります。 diff --git a/docs/content/connectors/toolreference/cobalt_io.md b/docs/content/connectors/toolreference/cobalt_io.md new file mode 100644 index 00000000000..ce0e669a5eb --- /dev/null +++ b/docs/content/connectors/toolreference/cobalt_io.md @@ -0,0 +1,19 @@ +--- +title: "Cobalt.io" +description: "How to set up the Cobalt.io Upstream Connector for DefectDojo" +weight: 37 +audience: pro +--- +The Cobalt.io connector uses the Cobalt.io API (v2) to pull pentest findings from your Cobalt.io organization. DefectDojo discovers every organization your API token can access and creates a separate Record for each **asset** (the unit Cobalt pentests). + +#### Prerequisites + +You will need a Cobalt.io **personal API token**. We recommend creating a dedicated service account for DefectDojo to clearly distinguish automated activity from manual team actions. Generate a token from **Settings \> API Tokens** in the Cobalt.io UI. Organization tokens are discovered automatically \- you do not need to supply them. + +#### Connector Mappings + +1. Enter the Cobalt.io API base URL in the **Location** field: `https://api.cobalt.io` (or your regional host, for example `https://api.us.cobalt.io`). +2. Enter your **personal API token** in the **Secret** field. +3. Optionally, enter an **Organization Token** to pin the sync to a single organization. When left blank, DefectDojo syncs every organization the personal API token can access. + +DefectDojo maps each Cobalt.io **asset** as a separate Record. Findings are imported for each mapped asset, with their Cobalt.io state (for example `valid_fix`, `wont_fix`, `invalid`) driving the finding status in DefectDojo. diff --git a/docs/content/connectors/toolreference/codacy.md b/docs/content/connectors/toolreference/codacy.md new file mode 100644 index 00000000000..60d67629af8 --- /dev/null +++ b/docs/content/connectors/toolreference/codacy.md @@ -0,0 +1,21 @@ +--- +title: "Codacy" +description: "How to set up the Codacy Upstream Connector for DefectDojo" +weight: 38 +audience: pro +--- +The Codacy connector imports **code quality and security findings** from Codacy. DefectDojo enumerates every organization your token can see and creates a Record for each **repository that carries security issues** — repositories with none are not mapped. + +#### Prerequisites + +You need a Codacy **account** API token. + +> **A repository ("project") token will not work.** Codacy's repository tokens are valid only against its older API version, and this connector uses the current one. Pasting a project token produces authentication failures that look like an invalid key. Make sure you generate an **account** token. + +#### Connector Mappings + +1. Enter `https://app.codacy.com/api/v3` in the **Location** field. +2. Enter your Codacy **account** API token in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each repository with security issues becomes a Record. Only **open** Security and Risk Management items are imported, so items you resolve in Codacy are reflected on the next Sync. diff --git a/docs/content/connectors/toolreference/contrast.de.md b/docs/content/connectors/toolreference/contrast.de.md new file mode 100644 index 00000000000..7e5f84e51cd --- /dev/null +++ b/docs/content/connectors/toolreference/contrast.de.md @@ -0,0 +1,27 @@ +--- +title: "Contrast" +description: "Einrichtung des Contrast Upstream-Connectors für DefectDojo" +weight: 39 +audience: pro +--- +Der Contrast-Connector verwendet die Contrast-Assess-REST-API, um Anwendungsschwachstellen zu importieren. DefectDojo ermittelt die Anwendungen in Ihrer Contrast-Organisation und erstellt für jede einen Eintrag. + +#### Voraussetzungen + +Sie benötigen vier Werte von Contrast. Wir empfehlen, ein dediziertes Service-Konto anzulegen, damit automatisierte Aktivitäten leicht von den manuellen Aktionen Ihres Teams zu unterscheiden sind. In der Contrast-Oberfläche finden Sie unter **User Settings > Profile > Your Keys**: + +* Ihren organisationsweiten **API Key**. +* Ihren persönlichen **Service Key**. +* Den **Benutzernamen**, zu dem die Anmeldedaten gehören (die Login-E-Mail-Adresse des Kontos). +* Ihre **Organization ID** — die UUID der Organisation, aus der importiert werden soll, ebenfalls unter **Organization Settings** angezeigt. + +#### Connector-Zuordnungen + +1. Geben Sie die URL, über die Sie auf Contrast zugreifen, in das Feld **Location** ein — beim gehosteten Produkt ist dies typischerweise `https://app.contrastsecurity.com` (oder Ihre regionale/selbstgehostete Team-Server-URL). +2. Geben Sie die Login-E-Mail-Adresse des Kontos in das Feld **Username** ein. +3. Geben Sie den organisationsweiten **API Key** in das Feld **API Key** ein. +4. Geben Sie den persönlichen **Service Key** in das Feld **Service Key** ein. +5. Geben Sie die **Organization ID** (UUID) in das Feld **Organization ID** ein. +6. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jede Contrast-Anwendung wird zu einem Eintrag, und ihre Schwachstellen werden als Befunde importiert. diff --git a/docs/content/connectors/toolreference/contrast.es.md b/docs/content/connectors/toolreference/contrast.es.md new file mode 100644 index 00000000000..4236dcac809 --- /dev/null +++ b/docs/content/connectors/toolreference/contrast.es.md @@ -0,0 +1,27 @@ +--- +title: "Contrast" +description: "Cómo configurar el Conector Upstream de Contrast para DefectDojo" +weight: 39 +audience: pro +--- +El conector de Contrast utiliza la API REST de Contrast Assess para importar vulnerabilidades de aplicaciones. DefectDojo detecta las aplicaciones de su organización de Contrast y crea un Registro para cada una. + +#### Requisitos previos + +Necesitará cuatro valores de Contrast. Recomendamos crear una cuenta de servicio dedicada para que la actividad automatizada se distinga fácilmente de las acciones manuales de su equipo. En la interfaz de Contrast, en **User Settings > Profile > Your Keys**, encontrará: + +* La **API Key** de su organización. +* Su **Service Key** personal. +* El **username** al que pertenecen las credenciales (el correo electrónico de inicio de sesión de la cuenta). +* Su **Organization ID**: el UUID de la organización desde la que importar, que también se muestra en **Organization Settings**. + +#### Asignaciones del conector + +1. Introduzca la URL base que utiliza para acceder a Contrast en el campo **Location**; para el producto alojado, suele ser `https://app.contrastsecurity.com` (o la URL de su Team Server regional o autoalojado). +2. Introduzca el correo electrónico de inicio de sesión de la cuenta en el campo **Username**. +3. Introduzca la **API Key** de la organización en el campo **API Key**. +4. Introduzca la **Service Key** personal en el campo **Service Key**. +5. Introduzca el **Organization ID** (UUID) en el campo **Organization ID**. +6. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada aplicación de Contrast se convierte en un Registro, y sus vulnerabilidades se importan como hallazgos. diff --git a/docs/content/connectors/toolreference/contrast.fr.md b/docs/content/connectors/toolreference/contrast.fr.md new file mode 100644 index 00000000000..2a2c86b1b2f --- /dev/null +++ b/docs/content/connectors/toolreference/contrast.fr.md @@ -0,0 +1,27 @@ +--- +title: "Contrast" +description: "Comment configurer le Connecteur Upstream Contrast pour DefectDojo" +weight: 39 +audience: pro +--- +Le connecteur Contrast utilise l'API REST Contrast Assess pour importer les vulnérabilités des applications. DefectDojo découvre les applications de votre organisation Contrast et crée un enregistrement pour chacune d'elles. + +#### Prérequis + +Vous aurez besoin de quatre valeurs provenant de Contrast. Nous recommandons de créer un compte de service dédié afin que l'activité automatisée soit facile à distinguer des actions manuelles de votre équipe. Dans l'interface Contrast, sous **User Settings > Profile > Your Keys**, vous trouverez : + +* Votre **API Key** d'organisation. +* Votre **Service Key** personnelle. +* Le **username** auquel appartiennent ces identifiants (l'e-mail de connexion du compte). +* Votre **Organization ID** — l'UUID de l'organisation depuis laquelle importer, également affiché sous **Organization Settings**. + +#### Mappages du connecteur + +1. Saisissez l'URL de base que vous utilisez pour accéder à Contrast dans le champ **Location** — pour le produit hébergé, il s'agit généralement de `https://app.contrastsecurity.com` (ou de l'URL de votre Team Server régional / auto-hébergé). +2. Saisissez l'e-mail de connexion du compte dans le champ **Username**. +3. Saisissez l'**API Key** de l'organisation dans le champ **API Key**. +4. Saisissez la **Service Key** personnelle dans le champ **Service Key**. +5. Saisissez l'**Organization ID** (UUID) dans le champ **Organization ID**. +6. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque application Contrast devient un enregistrement, et ses vulnérabilités sont importées comme constatations. diff --git a/docs/content/connectors/toolreference/contrast.ja.md b/docs/content/connectors/toolreference/contrast.ja.md new file mode 100644 index 00000000000..809c44df021 --- /dev/null +++ b/docs/content/connectors/toolreference/contrast.ja.md @@ -0,0 +1,27 @@ +--- +title: "Contrast" +description: "DefectDojo で Contrast の Upstream Connector をセットアップする方法" +weight: 39 +audience: pro +--- +Contrastコネクタは、Contrast Assess REST APIを使用してアプリケーションの脆弱性をインポートします。DefectDojoはContrast組織内のアプリケーションを検出し、それぞれについてレコードを作成します。 + +#### Prerequisites + +Contrastから4つの値が必要です。自動化された操作をチームの手動操作と区別しやすくするため、専用のサービスアカウントを作成することをお勧めします。Contrast UIの**User Settings > Profile > Your Keys**で以下を確認できます。 + +* 組織の**API Key**。 +* 個人の**Service Key**。 +* 認証情報の所有者である**username**（アカウントのログイン用メールアドレス）。 +* インポート元の組織のUUIDである**Organization ID**（**Organization Settings**にも表示されます）。 + +#### Connector Mappings + +1. **Location**フィールドに、Contrastへのアクセスに使用するベースURLを入力します。ホスト版の場合、通常は`https://app.contrastsecurity.com`です（またはリージョンごと・自己ホスト型のTeam ServerのURL）。 +2. **Username**フィールドにアカウントのログイン用メールアドレスを入力します。 +3. **API Key**フィールドに組織の**API Key**を入力します。 +4. **Service Key**フィールドに個人の**Service Key**を入力します。 +5. **Organization ID**フィールドに**Organization ID**（UUID）を入力します。 +6. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 + +各Contrastアプリケーションはレコードになり、その脆弱性は検出事項としてインポートされます。 diff --git a/docs/content/connectors/toolreference/contrast.md b/docs/content/connectors/toolreference/contrast.md new file mode 100644 index 00000000000..cc78a3b4294 --- /dev/null +++ b/docs/content/connectors/toolreference/contrast.md @@ -0,0 +1,27 @@ +--- +title: "Contrast" +description: "How to set up the Contrast Upstream Connector for DefectDojo" +weight: 39 +audience: pro +--- +The Contrast connector uses the Contrast Assess REST API to import application vulnerabilities. DefectDojo discovers the applications in your Contrast organization and creates a Record for each one. + +#### Prerequisites + +You will need four values from Contrast. We recommend creating a dedicated service account so automated activity is easy to distinguish from your team's manual actions. In the Contrast UI, under **User Settings > Profile > Your Keys**, you can find: + +* Your organization **API Key**. +* Your personal **Service Key**. +* The **username** the credentials belong to (the account's login email). +* Your **Organization ID** — the UUID of the organization to import from, also shown under **Organization Settings**. + +#### Connector Mappings + +1. Enter the base URL you use to access Contrast in the **Location** field — for the hosted product this is typically `https://app.contrastsecurity.com` (or your regional / self-hosted Team Server URL). +2. Enter the account login email in the **Username** field. +3. Enter the organization **API Key** in the **API Key** field. +4. Enter the personal **Service Key** in the **Service Key** field. +5. Enter the **Organization ID** (UUID) in the **Organization ID** field. +6. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each Contrast application becomes a Record, and its vulnerabilities are imported as findings. diff --git a/docs/content/connectors/toolreference/coverity.de.md b/docs/content/connectors/toolreference/coverity.de.md new file mode 100644 index 00000000000..804bad94d15 --- /dev/null +++ b/docs/content/connectors/toolreference/coverity.de.md @@ -0,0 +1,15 @@ +--- +title: "Coverity" +description: "Einrichtung des Coverity Upstream-Connectors für DefectDojo" +weight: 40 +audience: pro +--- +Der Coverity-Connector importiert Befunde von einem **Coverity-Connect**-Server. DefectDojo erstellt für jedes Coverity-**Projekt** einen Eintrag. + +#### Connector-Zuordnungen + +1. Geben Sie die URL Ihres Coverity-Connect-Servers in das Feld **Location** ein. +2. Geben Sie den Coverity-Connect-**Benutzernamen** in das Feld **Username** ein. +3. Geben Sie das Passwort oder den Authentifizierungsschlüssel des Benutzers in das Feld **Secret** ein. +4. Legen Sie optional einen **View Name** fest, um auszuwählen, welche gespeicherte Issue-Ansicht der Connector liest. Leer lassen, um den Standard **Outstanding Issues** zu verwenden. +5. Setzen Sie optional **Import All Issue Kinds** auf `true`, um den Import über den Standardfilter für Security- und Quality-Issues (`RESOURCE_LEAK`) hinaus zu erweitern. diff --git a/docs/content/connectors/toolreference/coverity.es.md b/docs/content/connectors/toolreference/coverity.es.md new file mode 100644 index 00000000000..8ef053990ae --- /dev/null +++ b/docs/content/connectors/toolreference/coverity.es.md @@ -0,0 +1,15 @@ +--- +title: "Coverity" +description: "Cómo configurar el Conector Upstream de Coverity para DefectDojo" +weight: 40 +audience: pro +--- +El conector de Coverity importa hallazgos desde un servidor **Coverity Connect**. DefectDojo crea un Registro para cada **proyecto** de Coverity. + +#### Asignaciones del conector + +1. Introduzca la URL de su servidor Coverity Connect en el campo **Location**. +2. Introduzca el **username** de Coverity Connect en el campo **Username**. +3. Introduzca la contraseña o la clave de autenticación del usuario en el campo **Secret**. +4. De forma opcional, defina un **View Name** para seleccionar qué vista de incidencias guardada lee el conector. Déjelo en blanco para usar la opción predeterminada, **Outstanding Issues**. +5. De forma opcional, defina **Import All Issue Kinds** en `true` para ampliar la importación más allá del filtro predeterminado de incidencias de Security y Quality (`RESOURCE_LEAK`). diff --git a/docs/content/connectors/toolreference/coverity.fr.md b/docs/content/connectors/toolreference/coverity.fr.md new file mode 100644 index 00000000000..eaba31e4452 --- /dev/null +++ b/docs/content/connectors/toolreference/coverity.fr.md @@ -0,0 +1,15 @@ +--- +title: "Coverity" +description: "Comment configurer le Connecteur Upstream Coverity pour DefectDojo" +weight: 40 +audience: pro +--- +Le connecteur Coverity importe des constatations depuis un serveur **Coverity Connect**. DefectDojo crée un enregistrement pour chaque **projet** Coverity. + +#### Mappages du connecteur + +1. Saisissez l'URL de votre serveur Coverity Connect dans le champ **Location**. +2. Saisissez le **username** Coverity Connect dans le champ **Username**. +3. Saisissez le mot de passe ou la clé d'authentification de l'utilisateur dans le champ **Secret**. +4. Facultativement, définissez un **View Name** pour sélectionner la vue d'issues enregistrée que le connecteur doit lire. Laissez vide pour utiliser la vue par défaut, **Outstanding Issues**. +5. Facultativement, définissez **Import All Issue Kinds** sur `true` pour élargir l'import au-delà du filtre d'issues Security and Quality (`RESOURCE_LEAK`) par défaut. diff --git a/docs/content/connectors/toolreference/coverity.ja.md b/docs/content/connectors/toolreference/coverity.ja.md new file mode 100644 index 00000000000..128753f67ff --- /dev/null +++ b/docs/content/connectors/toolreference/coverity.ja.md @@ -0,0 +1,15 @@ +--- +title: "Coverity" +description: "DefectDojo で Coverity の Upstream Connector をセットアップする方法" +weight: 40 +audience: pro +--- +Coverityコネクタは、**Coverity Connect**サーバーから検出事項をインポートします。DefectDojoは、Coverityの**プロジェクト**ごとにレコードを作成します。 + +#### Connector Mappings + +1. **Location**フィールドにCoverity ConnectサーバーのURLを入力します。 +2. **Username**フィールドにCoverity Connectの**username**を入力します。 +3. **Secret**フィールドにユーザーのパスワードまたは認証キーを入力します。 +4. 必要に応じて、コネクタが読み取る保存済みissueビューを選択するために**View Name**を設定します。空欄のままにすると、デフォルトの**Outstanding Issues**が使用されます。 +5. 必要に応じて、デフォルトのSecurityおよびQuality（`RESOURCE_LEAK`）のissueフィルタより広くインポートするために、**Import All Issue Kinds**を`true`に設定します。 diff --git a/docs/content/connectors/toolreference/coverity.md b/docs/content/connectors/toolreference/coverity.md new file mode 100644 index 00000000000..0be73ac08a0 --- /dev/null +++ b/docs/content/connectors/toolreference/coverity.md @@ -0,0 +1,15 @@ +--- +title: "Coverity" +description: "How to set up the Coverity Upstream Connector for DefectDojo" +weight: 40 +audience: pro +--- +The Coverity connector imports findings from a **Coverity Connect** server. DefectDojo creates a Record for each Coverity **project**. + +#### Connector Mappings + +1. Enter your Coverity Connect server URL in the **Location** field. +2. Enter the Coverity Connect **username** in the **Username** field. +3. Enter the user's password or authentication key in the **Secret** field. +4. Optionally, set a **View Name** to select which saved issues view the connector reads. Leave blank to use the default, **Outstanding Issues**. +5. Optionally, set **Import All Issue Kinds** to `true` to widen the import beyond the default Security and Quality (`RESOURCE_LEAK`) issue filter. diff --git a/docs/content/connectors/toolreference/crowdstrike_falcon.de.md b/docs/content/connectors/toolreference/crowdstrike_falcon.de.md new file mode 100644 index 00000000000..cbbf1d46ec8 --- /dev/null +++ b/docs/content/connectors/toolreference/crowdstrike_falcon.de.md @@ -0,0 +1,20 @@ +--- +title: "CrowdStrike Falcon" +description: "Einrichtung des CrowdStrike Falcon Upstream-Connectors für DefectDojo" +weight: 41 +audience: pro +--- +Der CrowdStrike-Falcon-Connector importiert **Spotlight-Schwachstellen** und **EDR-Detections** von der Falcon-Plattform als zwei separate Befundtypen (`CrowdStrike:Spotlight` und `CrowdStrike:Detections`). DefectDojo erstellt für jeden Falcon-**Host** einen Eintrag. + +#### Voraussetzungen + +Ein Falcon-**API-Client** (Client ID und Secret), erstellt in der Falcon-Konsole unter **Support \> API Clients and Keys**. Gewähren Sie ihm die Scopes für die zu importierenden Daten: **Hosts: Read** (erforderlich, für die Host-Ermittlung), **Vulnerabilities (Spotlight): Read** (für Spotlight-Befunde) und **Alerts: Read** (für EDR-Detections). Die beiden Befundtypen sind unabhängig voneinander — fehlt dem Client ein Scope, wird dieser Befundtyp übersprungen, statt den Sync scheitern zu lassen; ein Client ohne **Alerts: Read** importiert also weiterhin Spotlight-Schwachstellen. + +#### Connector-Zuordnungen + +1. Geben Sie die Basis-URL der API Ihrer Falcon-Cloud in das Feld **Location** ein, passend zu Ihrer Konsolen-Region — zum Beispiel `https://api.crowdstrike.com` (US\-1), `https://api.us-2.crowdstrike.com` (US\-2), `https://api.eu-1.crowdstrike.com` (EU\-1) oder `https://api.laggar.gcw.crowdstrike.com` (US\-GOV\-1). +2. Geben Sie die Client ID des API-Clients in das Feld **Client ID** ein. +3. Geben Sie das Secret des API-Clients in das Feld **Client Secret** ein. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jeder Falcon-Host wird zu einem Eintrag, benannt nach Hostname, Betriebssystem und Typ. Es werden nur Spotlight-Schwachstellen mit dem Status **open** und **reopened** importiert, sodass ein erneuter Import behobene Befunde schließt. diff --git a/docs/content/connectors/toolreference/crowdstrike_falcon.es.md b/docs/content/connectors/toolreference/crowdstrike_falcon.es.md new file mode 100644 index 00000000000..06e2b9e9032 --- /dev/null +++ b/docs/content/connectors/toolreference/crowdstrike_falcon.es.md @@ -0,0 +1,20 @@ +--- +title: "CrowdStrike Falcon" +description: "Cómo configurar el Conector Upstream de CrowdStrike Falcon para DefectDojo" +weight: 41 +audience: pro +--- +El conector de CrowdStrike Falcon importa **vulnerabilidades de Spotlight** y **detecciones de EDR** de la plataforma Falcon, como dos tipos de hallazgo independientes (`CrowdStrike:Spotlight` y `CrowdStrike:Detections`). DefectDojo crea un Registro para cada **host** de Falcon. + +#### Requisitos previos + +Un **API client** de Falcon (Client ID y secret), creado en la consola de Falcon en **Support \> API Clients and Keys**. Otórguele los scopes correspondientes a los datos que desea importar: **Hosts: Read** (obligatorio, para la detección de hosts), **Vulnerabilities (Spotlight): Read** (para los hallazgos de Spotlight) y **Alerts: Read** (para las detecciones de EDR). Los dos tipos de hallazgo son independientes: si al cliente le falta un scope, ese tipo de hallazgo se omite en lugar de hacer fallar la sincronización, por lo que un cliente sin **Alerts: Read** sigue importando las vulnerabilidades de Spotlight. + +#### Asignaciones del conector + +1. Introduzca la URL base de la API de su nube de Falcon en el campo **Location**, según la región de su consola; por ejemplo, `https://api.crowdstrike.com` (US\-1), `https://api.us-2.crowdstrike.com` (US\-2), `https://api.eu-1.crowdstrike.com` (EU\-1) o `https://api.laggar.gcw.crowdstrike.com` (US\-GOV\-1). +2. Introduzca el Client ID del API client en el campo **Client ID**. +3. Introduzca el secret del API client en el campo **Client Secret**. +4. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada host de Falcon se convierte en un Registro, nombrado según su hostname, sistema operativo y tipo. Solo se importan las vulnerabilidades de Spotlight **open** y **reopened**, por lo que una nueva importación cierra los hallazgos ya remediados. diff --git a/docs/content/connectors/toolreference/crowdstrike_falcon.fr.md b/docs/content/connectors/toolreference/crowdstrike_falcon.fr.md new file mode 100644 index 00000000000..d7837fb231f --- /dev/null +++ b/docs/content/connectors/toolreference/crowdstrike_falcon.fr.md @@ -0,0 +1,20 @@ +--- +title: "CrowdStrike Falcon" +description: "Comment configurer le Connecteur Upstream CrowdStrike Falcon pour DefectDojo" +weight: 41 +audience: pro +--- +Le connecteur CrowdStrike Falcon importe les **vulnérabilités Spotlight** et les **détections EDR** depuis la plateforme Falcon, sous forme de deux types de constatations distincts (`CrowdStrike:Spotlight` et `CrowdStrike:Detections`). DefectDojo crée un enregistrement pour chaque **hôte** Falcon. + +#### Prérequis + +Un **client API** Falcon (Client ID et secret), créé dans la console Falcon sous **Support \> API Clients and Keys**. Accordez-lui les scopes correspondant aux données que vous souhaitez importer : **Hosts: Read** (requis, pour la découverte des hôtes), **Vulnerabilities (Spotlight): Read** (pour les constatations Spotlight) et **Alerts: Read** (pour les détections EDR). Les deux types de constatations sont indépendants — si le client ne dispose pas d'un scope, ce type de constatation est ignoré plutôt que de faire échouer la synchronisation ; ainsi, un client sans **Alerts: Read** importe tout de même les vulnérabilités Spotlight. + +#### Mappages du connecteur + +1. Saisissez l'URL de base de l'API de votre cloud Falcon dans le champ **Location**, en fonction de la région de votre console — par exemple `https://api.crowdstrike.com` (US\-1), `https://api.us-2.crowdstrike.com` (US\-2), `https://api.eu-1.crowdstrike.com` (EU\-1), ou `https://api.laggar.gcw.crowdstrike.com` (US\-GOV\-1). +2. Saisissez le Client ID du client API dans le champ **Client ID**. +3. Saisissez le secret du client API dans le champ **Client Secret**. +4. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque hôte Falcon devient un enregistrement, nommé d'après son nom d'hôte, son OS et son type. Seules les vulnérabilités Spotlight à l'état **open** et **reopened** sont importées ; une réimportation clôt donc les constatations corrigées. diff --git a/docs/content/connectors/toolreference/crowdstrike_falcon.ja.md b/docs/content/connectors/toolreference/crowdstrike_falcon.ja.md new file mode 100644 index 00000000000..5edd10a25d8 --- /dev/null +++ b/docs/content/connectors/toolreference/crowdstrike_falcon.ja.md @@ -0,0 +1,20 @@ +--- +title: "CrowdStrike Falcon" +description: "DefectDojo で CrowdStrike Falcon の Upstream Connector をセットアップする方法" +weight: 41 +audience: pro +--- +CrowdStrike Falconコネクタは、Falconプラットフォームから**Spotlightの脆弱性**と**EDR検知**を、2つの独立した検出事項タイプ（`CrowdStrike:Spotlight`と`CrowdStrike:Detections`）としてインポートします。DefectDojoは、Falconの**ホスト**ごとにレコードを作成します。 + +#### Prerequisites + +Falconコンソールの**Support > API Clients and Keys**で作成する、Falconの**APIクライアント**（Client IDとsecret）が必要です。インポートしたいデータに応じたスコープを付与してください: **Hosts: Read**（ホスト検出に必須）、**Vulnerabilities (Spotlight): Read**（Spotlightの検出事項用）、**Alerts: Read**（EDR検知用）。この2つの検出事項タイプは独立しており、クライアントに該当スコープがない場合、同期全体が失敗するのではなく、そのタイプの検出事項がスキップされます。そのため、**Alerts: Read**を持たないクライアントでも、Spotlightの脆弱性は問題なくインポートされます。 + +#### Connector Mappings + +1. **Location**フィールドに、コンソールのリージョンに対応するFalconクラウドのAPIベースURLを入力します。例: `https://api.crowdstrike.com`（US-1）、`https://api.us-2.crowdstrike.com`（US-2）、`https://api.eu-1.crowdstrike.com`（EU-1）、`https://api.laggar.gcw.crowdstrike.com`（US-GOV-1）。 +2. **Client ID**フィールドにAPIクライアントのClient IDを入力します。 +3. **Client Secret**フィールドにAPIクライアントのsecretを入力します。 +4. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 + +各Falconホストはレコードとなり、そのホスト名・OS・タイプにちなんで命名されます。Spotlightの脆弱性は**open**および**reopened**のものだけがインポートされるため、再インポートを行うと修復済みの検出事項はクローズされます。 diff --git a/docs/content/connectors/toolreference/crowdstrike_falcon.md b/docs/content/connectors/toolreference/crowdstrike_falcon.md new file mode 100644 index 00000000000..196e2e5a7d3 --- /dev/null +++ b/docs/content/connectors/toolreference/crowdstrike_falcon.md @@ -0,0 +1,20 @@ +--- +title: "CrowdStrike Falcon" +description: "How to set up the CrowdStrike Falcon Upstream Connector for DefectDojo" +weight: 41 +audience: pro +--- +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. diff --git a/docs/content/connectors/toolreference/cyberark_certificate_manager.md b/docs/content/connectors/toolreference/cyberark_certificate_manager.md new file mode 100644 index 00000000000..b3a85656094 --- /dev/null +++ b/docs/content/connectors/toolreference/cyberark_certificate_manager.md @@ -0,0 +1,29 @@ +--- +title: "CyberArk Certificate Manager" +description: "How to set up the CyberArk Certificate Manager Upstream Connector for DefectDojo" +weight: 42 +audience: pro +--- +The CyberArk Certificate Manager connector imports **PKI/certificate posture findings**. DefectDojo creates a Record for each certificate's **owning application** (SaaS) or **policy folder** (self\-hosted). + +**These findings are DefectDojo's own analysis, not a vendor vulnerability list.** The connector enumerates your certificates and evaluates four posture rules against each one — **expiry**, **weak key**, **SHA\-1 signature**, and **self\-signed** — then raises findings from the results. If you go looking for a matching "vulnerabilities" list inside Certificate Manager, there isn't one. + +Both editions are supported, and the connector normalizes them so the same rules apply to each: + +* **`cloud`** — Certificate Manager SaaS, formerly TLS Protect Cloud. +* **`tpp`** — Certificate Manager Self\-Hosted, formerly Trust Protection Platform. + +#### Prerequisites + +* **Cloud:** a SaaS **API key**. +* **Self-hosted:** an **OAuth client ID** registered on the server, plus a **service account username and password**. + +#### Connector Mappings + +1. Enter your Certificate Manager URL in the **Location** field — `https://api.venafi.cloud` (or your region's host) for cloud, or your Trust Protection Platform host for self\-hosted. +2. Set **Edition** to `cloud` or `tpp`. It defaults to `cloud`. +3. For the **cloud** edition, enter the SaaS API key in **API Key (cloud)** and leave the `tpp` fields blank. +4. For the **tpp** edition, enter the **Client ID (tpp)**, **Username (tpp)** and **Password (tpp)**, and leave the cloud API key blank. +5. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Because the credential fields are shared between editions, only the ones matching your chosen **Edition** are required — the others should be left empty. diff --git a/docs/content/connectors/toolreference/cyberwatch.md b/docs/content/connectors/toolreference/cyberwatch.md new file mode 100644 index 00000000000..716a99096de --- /dev/null +++ b/docs/content/connectors/toolreference/cyberwatch.md @@ -0,0 +1,20 @@ +--- +title: "Cyberwatch" +description: "How to set up the Cyberwatch Upstream Connector for DefectDojo" +weight: 43 +audience: pro +--- +The Cyberwatch connector imports **CVEs and security (compliance) issues** from a Cyberwatch appliance — both kinds in a single Sync. DefectDojo creates a Record for each asset, or "server", the appliance knows about. + +#### Prerequisites + +A Cyberwatch **API key ID and secret key**, created in the appliance under **Profile \> API keys**. The secret is never logged. + +#### Connector Mappings + +1. Enter your Cyberwatch appliance URL in the **Location** field. +2. Enter the API key ID in the **API Key** field. +3. Enter the secret in the **Secret Key** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each asset becomes a Record, carrying both its CVEs and its compliance findings. diff --git a/docs/content/connectors/toolreference/cycognito.md b/docs/content/connectors/toolreference/cycognito.md new file mode 100644 index 00000000000..a28f9ca7242 --- /dev/null +++ b/docs/content/connectors/toolreference/cycognito.md @@ -0,0 +1,22 @@ +--- +title: "CyCognito" +description: "How to set up the CyCognito Upstream Connector for DefectDojo" +weight: 44 +audience: pro +--- +The CyCognito connector imports **external attack surface (EASM) findings** from the CyCognito platform. By default DefectDojo creates a Record for each **discovered asset**, across every asset type CyCognito tracks — IPs, domains, certificates, web apps and IP ranges. + +There is deliberately no per\-asset configuration: the point of an EASM source is that it finds assets nobody enumerated in advance, so newly discovered assets appear as Records without anyone editing a configuration. + +#### Prerequisites + +A CyCognito **API key**, created under **Settings \> API** in CyCognito. It is sent as the value of the `Authorization` header. + +#### Connector Mappings + +1. Enter `https://api.platform.cycognito.com` in the **Location** field. +2. Enter your CyCognito API key in the **API Key** field. +3. Optionally, set **Asset Grouping** to `organization` to create one Record per CyCognito **organization** instead of one per asset. Leave it blank for the default, one Record per asset. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Under **organization** grouping, assets that belong to no organization are collected into a Record named **Unattributed Assets**. diff --git a/docs/content/connectors/toolreference/datadog.md b/docs/content/connectors/toolreference/datadog.md new file mode 100644 index 00000000000..8321060fec7 --- /dev/null +++ b/docs/content/connectors/toolreference/datadog.md @@ -0,0 +1,25 @@ +--- +title: "Datadog" +description: "How to set up the Datadog Upstream Connector for DefectDojo" +weight: 45 +audience: pro +--- +The Datadog connector imports **Cloud Security findings** — misconfigurations, identity risks and vulnerabilities — from the Datadog security findings API. DefectDojo creates a Record for each **cloud account** the findings belong to, so no per\-resource configuration is needed. + +#### Prerequisites + +You will need two credentials from Datadog: + +* An **API key**, from **Organization Settings \> API Keys**. +* An **application key**, from **Organization Settings \> Application Keys**, which must carry the **`security_monitoring_findings_read`** scope. + +Neither key is ever logged by DefectDojo. + +#### Connector Mappings + +1. Enter your organization's Datadog **site** in the **Location** field — for example `https://api.datadoghq.com`. Organizations on the EU, US3, US5 or AP1 sites must use their own site hostname. +2. Enter the API key in the **API Key** field. +3. Enter the application key in the **Application Key** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each cloud account that has findings becomes a Record. DefectDojo respects Datadog's rate limits, backing off and retrying rather than failing the Sync. diff --git a/docs/content/connectors/toolreference/deepfence_threatmapper.de.md b/docs/content/connectors/toolreference/deepfence_threatmapper.de.md new file mode 100644 index 00000000000..949b8dfbe16 --- /dev/null +++ b/docs/content/connectors/toolreference/deepfence_threatmapper.de.md @@ -0,0 +1,22 @@ +--- +title: "Deepfence ThreatMapper" +description: "Einrichtung des Deepfence ThreatMapper Upstream-Connectors für DefectDojo" +weight: 46 +audience: pro +--- +Der Deepfence-ThreatMapper-Connector verwendet die REST-API der [ThreatMapper](https://github.com/deepfence/ThreatMapper)-Management-Konsole, um **Schwachstellen-Scan**-Ergebnisse zu importieren. DefectDojo ermittelt jeden Node, den ThreatMapper gescannt hat — ein Container-Image, einen Host oder einen Container — und erstellt für jeden einen Eintrag; anschließend wird der letzte abgeschlossene Scan dieses Nodes als Befunde importiert. + +#### Voraussetzungen + +Sie benötigen ein ThreatMapper-**API-Token**, das Sie in der Konsole unter **Settings → User Management** finden (der API-Schlüssel Ihres Benutzers). Der Connector tauscht dieses bei jedem Sync gegen ein kurzlebiges Zugriffstoken ein; das API-Token wird nie protokolliert. + +#### Connector-Zuordnungen + +1. Geben Sie die URL Ihrer ThreatMapper-Konsole in das Feld **Location** ein (zum Beispiel `https://threatmapper.example.com`). +2. Geben Sie im Feld **Secret** das ThreatMapper-API-Token ein. +3. Wenn Ihre Konsole ein selbstsigniertes Zertifikat verwendet, setzen Sie **Skip TLS Verification** auf `true`. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo ordnet jeden gescannten **Node** einem Eintrag zu und jede **CVE** im letzten abgeschlossenen Schwachstellen-Scan einem Befund. Der Schweregrad stammt aus ThreatMappers eigener Bewertung, und das betroffene Paket, der CVSS-Score, die Fix-Version (als Abhilfemaßnahme), Referenzlinks und ein Detailblock werden übernommen. Befunde werden als dynamische Befunde erfasst und anhand von Node, CVE, Paket und Paketpfad dedupliziert. + +Weitere Informationen finden Sie in der [ThreatMapper-Dokumentation](https://community.deepfence.io/threatmapper/docs/v2.5/). diff --git a/docs/content/connectors/toolreference/deepfence_threatmapper.es.md b/docs/content/connectors/toolreference/deepfence_threatmapper.es.md new file mode 100644 index 00000000000..c9f23a31e25 --- /dev/null +++ b/docs/content/connectors/toolreference/deepfence_threatmapper.es.md @@ -0,0 +1,22 @@ +--- +title: "Deepfence ThreatMapper" +description: "Cómo configurar el Conector Upstream de Deepfence ThreatMapper para DefectDojo" +weight: 46 +audience: pro +--- +El conector de Deepfence ThreatMapper utiliza la API REST de la consola de administración de [ThreatMapper](https://github.com/deepfence/ThreatMapper) para importar resultados de **escaneos de vulnerabilidades**. DefectDojo detecta todos los nodos que ThreatMapper ha escaneado (una imagen de contenedor, un host o un contenedor) y crea un Registro para cada uno; a continuación, importa como hallazgos el escaneo completado más reciente de ese nodo. + +#### Requisitos previos + +Necesitará un **API token** de ThreatMapper, disponible en la consola en **Settings → User Management** (la clave de API de su usuario). El conector lo intercambia por un token de acceso de corta duración en cada sincronización; el API token nunca se registra en los logs. + +#### Asignaciones del conector + +1. Introduzca la URL de la consola de ThreatMapper en el campo **Location** (por ejemplo, `https://threatmapper.example.com`). +2. En el campo **Secret**, introduzca el API token de ThreatMapper. +3. Si su consola utiliza un certificado autofirmado, defina **Skip TLS Verification** en `true`. +4. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo asigna cada **nodo** escaneado a un Registro y cada **CVE** de su escaneo de vulnerabilidades completado más reciente a un hallazgo. La severidad proviene de la propia calificación de ThreatMapper, y se trasladan el paquete afectado, la puntuación CVSS, la versión de corrección (como mitigación), los enlaces de referencia y un bloque de detalles. Los hallazgos se registran como hallazgos dinámicos y se deduplican según el nodo, el CVE, el paquete y la ruta del paquete. + +Consulte la [documentación de ThreatMapper](https://community.deepfence.io/threatmapper/docs/v2.5/) para obtener más información. diff --git a/docs/content/connectors/toolreference/deepfence_threatmapper.fr.md b/docs/content/connectors/toolreference/deepfence_threatmapper.fr.md new file mode 100644 index 00000000000..356f03da4e3 --- /dev/null +++ b/docs/content/connectors/toolreference/deepfence_threatmapper.fr.md @@ -0,0 +1,22 @@ +--- +title: "Deepfence ThreatMapper" +description: "Comment configurer le Connecteur Upstream Deepfence ThreatMapper pour DefectDojo" +weight: 46 +audience: pro +--- +Le connecteur Deepfence ThreatMapper utilise l'API REST de la console de gestion [ThreatMapper](https://github.com/deepfence/ThreatMapper) pour importer les résultats des **scans de vulnérabilités**. DefectDojo découvre chaque nœud scanné par ThreatMapper — une image de conteneur, un hôte ou un conteneur — et crée un enregistrement pour chacun, puis importe le scan complété le plus récent de ce nœud sous forme de constatations. + +#### Prérequis + +Vous aurez besoin d'un **jeton d'API** ThreatMapper, disponible dans la console sous **Settings → User Management** (la clé d'API de votre utilisateur). Le connecteur l'échange contre un jeton d'accès de courte durée à chaque synchronisation ; le jeton d'API n'est jamais journalisé. + +#### Mappages du connecteur + +1. Saisissez l'URL de votre console ThreatMapper dans le champ **Location** (par exemple `https://threatmapper.example.com`). +2. Dans le champ **Secret**, saisissez le jeton d'API ThreatMapper. +3. Si votre console utilise un certificat auto-signé, définissez **Skip TLS Verification** sur `true`. +4. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +DefectDojo associe chaque **nœud** scanné à un enregistrement et chaque **CVE** de son dernier scan de vulnérabilités complété à une constatation. La sévérité provient de la notation propre à ThreatMapper, et le paquet affecté, le score CVSS, la version corrigée (utilisée comme atténuation), les liens de référence et un bloc de détails sont repris. Les constatations sont enregistrées comme constatations dynamiques et dédupliquées sur le nœud, le CVE, le paquet et le chemin du paquet. + +Pour plus d'informations, consultez la [documentation ThreatMapper](https://community.deepfence.io/threatmapper/docs/v2.5/). diff --git a/docs/content/connectors/toolreference/deepfence_threatmapper.ja.md b/docs/content/connectors/toolreference/deepfence_threatmapper.ja.md new file mode 100644 index 00000000000..8ff74a982b4 --- /dev/null +++ b/docs/content/connectors/toolreference/deepfence_threatmapper.ja.md @@ -0,0 +1,22 @@ +--- +title: "Deepfence ThreatMapper" +description: "DefectDojo で Deepfence ThreatMapper の Upstream Connector をセットアップする方法" +weight: 46 +audience: pro +--- +Deepfence ThreatMapperコネクタは、[ThreatMapper](https://github.com/deepfence/ThreatMapper)の管理コンソールREST APIを使用して**脆弱性スキャン**の結果をインポートします。DefectDojoは、ThreatMapperがスキャンしたすべてのノード（コンテナイメージ、ホスト、またはコンテナ）を検出し、それぞれについてレコードを作成したうえで、そのノードの直近に完了したスキャンを検出事項としてインポートします。 + +#### Prerequisites + +ThreatMapperの**APIトークン**が必要です。これはコンソールの**Settings → User Management**（ユーザーのAPIキー）にあります。コネクタは同期のたびにこのトークンを短命のアクセストークンと交換します。APIトークン自体がログに記録されることはありません。 + +#### Connector Mappings + +1. **Location**フィールドにThreatMapperコンソールのURLを入力します（例: `https://threatmapper.example.com`）。 +2. **Secret**フィールドにThreatMapperのAPIトークンを入力します。 +3. コンソールが自己署名証明書を使用している場合は、**Skip TLS Verification**を`true`に設定します。 +4. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 + +DefectDojoは、スキャン済みの各**ノード**をレコードにマッピングし、直近に完了した脆弱性スキャンに含まれる各**CVE**を検出事項にマッピングします。深刻度はThreatMapper自体の評価に基づき、影響を受けるパッケージ、CVSSスコア、修正バージョン（緩和策として）、参照リンク、詳細情報のブロックが引き継がれます。検出事項は動的検出事項として記録され、ノード・CVE・パッケージ・パッケージパスの組み合わせで重複排除されます。 + +詳細については、[ThreatMapperのドキュメント](https://community.deepfence.io/threatmapper/docs/v2.5/)を参照してください。 diff --git a/docs/content/connectors/toolreference/deepfence_threatmapper.md b/docs/content/connectors/toolreference/deepfence_threatmapper.md new file mode 100644 index 00000000000..5e4abdb5551 --- /dev/null +++ b/docs/content/connectors/toolreference/deepfence_threatmapper.md @@ -0,0 +1,22 @@ +--- +title: "Deepfence ThreatMapper" +description: "How to set up the Deepfence ThreatMapper Upstream Connector for DefectDojo" +weight: 46 +audience: pro +--- +The Deepfence ThreatMapper connector uses the [ThreatMapper](https://github.com/deepfence/ThreatMapper) management-console REST API to import **vulnerability scan** results. DefectDojo discovers every node ThreatMapper has scanned — a container image, host, or container — and creates a Record for each, then imports that node's most recent completed scan as findings. + +#### Prerequisites + +You will need a ThreatMapper **API token**, found in the console under **Settings → User Management** (your user's API key). The connector exchanges it for a short-lived access token on each sync; the API token is never logged. + +#### Connector Mappings + +1. Enter your ThreatMapper console URL in the **Location** field (for example `https://threatmapper.example.com`). +2. In the **Secret** field, enter the ThreatMapper API token. +3. If your console uses a self-signed certificate, set **Skip TLS Verification** to `true`. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo maps each scanned **node** to a Record and each **CVE** in its latest completed vulnerability scan to a finding. The severity comes from ThreatMapper's own rating, and the affected package, CVSS score, fix version (as mitigation), reference links, and a details block are carried over. Findings are recorded as dynamic findings and de-duplicated on the node, CVE, package and package path. + +See the [ThreatMapper documentation](https://community.deepfence.io/threatmapper/docs/v2.5/) for more information. diff --git a/docs/content/connectors/toolreference/deepsource.md b/docs/content/connectors/toolreference/deepsource.md new file mode 100644 index 00000000000..a23dc113985 --- /dev/null +++ b/docs/content/connectors/toolreference/deepsource.md @@ -0,0 +1,19 @@ +--- +title: "DeepSource" +description: "How to set up the DeepSource Upstream Connector for DefectDojo" +weight: 47 +audience: pro +--- +The DeepSource connector imports **static analysis findings** from DeepSource. DefectDojo enumerates every account your token can see and creates a Record for each **activated** repository. + +#### Prerequisites + +A DeepSource **personal access token**, sent as a bearer token. + +#### Connector Mappings + +1. Enter your DeepSource GraphQL API URL in the **Location** field — `https://api.deepsource.com/graphql/` for the cloud platform, or your own host's GraphQL path if self\-hosted. +2. Enter the personal access token in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each activated repository becomes a Record. DeepSource reports the currently-open set of issue occurrences rather than a per\-finding status, so each Sync reflects what is open at that moment. diff --git a/docs/content/connectors/toolreference/dependency_track.de.md b/docs/content/connectors/toolreference/dependency_track.de.md new file mode 100644 index 00000000000..a8442372dac --- /dev/null +++ b/docs/content/connectors/toolreference/dependency_track.de.md @@ -0,0 +1,22 @@ +--- +title: "Dependency-Track" +description: "Einrichtung des Dependency-Track Upstream-Connectors für DefectDojo" +weight: 48 +audience: pro +--- +Dieser Connector ruft Daten von einer On-Premise-Dependency\-Track-Instanz über die REST-API ab. + +​**Connector-Zuordnungen** + +1. Geben Sie die URL Ihres lokalen Dependency\-Track-Servers in das Feld **Location** ein. +2. Geben Sie einen gültigen API-Schlüssel in das Feld **Secret** ein. + +So generieren Sie einen Dependency\-Track-API-Schlüssel: + +1. **Access Management**: Navigieren Sie in der Dependency\-Track-Oberfläche zu Administration \> Access Management \> Teams. +2. **Teams Setup**: Sie können entweder ein neues Team erstellen oder ein bestehendes auswählen. Mit Teams können Sie den API-Zugriff anhand der Gruppenmitgliedschaft verwalten. +3. **Generate API Key**: Suchen Sie auf der Detailseite des ausgewählten Teams den Abschnitt „API Keys". Klicken Sie auf die Schaltfläche \+, um einen neuen API-Schlüssel zu generieren. +4. **Assign Permissions**: Klicken Sie im Abschnitt „Permissions" der Team-Seite auf die Schaltfläche \+, um die Berechtigungsauswahl zu öffnen. Wählen Sie die Berechtigungen **VIEW\_PORTFOLIO** und **VIEW\_VULNERABILITY**, um API-Zugriff auf Projekt-Portfolios und Schwachstellendetails zu ermöglichen. +5. Klicken Sie auf „**Select**", um diese Berechtigungen zu bestätigen und zu speichern. + +Weitere Informationen finden Sie in der **[Dependency\-Track-Dokumentation](https://docs.dependencytrack.org/integrations/rest-api/)**. diff --git a/docs/content/connectors/toolreference/dependency_track.es.md b/docs/content/connectors/toolreference/dependency_track.es.md new file mode 100644 index 00000000000..310022d6af0 --- /dev/null +++ b/docs/content/connectors/toolreference/dependency_track.es.md @@ -0,0 +1,22 @@ +--- +title: "Dependency-Track" +description: "Cómo configurar el Conector Upstream de Dependency-Track para DefectDojo" +weight: 48 +audience: pro +--- +Este conector obtiene datos de una instancia on\-premise de Dependency\-Track mediante la API REST. + +​**Asignaciones del conector** + +1. Introduzca la URL de su servidor local de Dependency\-Track en el campo **Location**. +2. Introduzca una clave de API válida en el campo **Secret**. + +Para generar una clave de API de Dependency\-Track: + +1. **Access Management**: navegue hasta Administration \> Access Management \> Teams en la interfaz de Dependency\-Track. +2. **Teams Setup**: puede crear un nuevo equipo o seleccionar uno existente. Los equipos permiten gestionar el acceso a la API según la pertenencia al grupo. +3. **Generate API Key**: en la página de detalles del equipo seleccionado, busque la sección "API Keys". Haga clic en el botón \+ para generar una nueva clave de API. +4. **Assign Permissions**: en la sección "Permissions" de la página del equipo, haga clic en el botón \+ para abrir el selector de permisos. Elija los permisos **VIEW\_PORTFOLIO** y **VIEW\_VULNERABILITY** para habilitar el acceso mediante API a los portafolios de proyectos y a los detalles de vulnerabilidades. +5. Haga clic en "**Select**" para confirmar y guardar estos permisos. + +Para obtener más información, consulte la **[documentación de Dependency\-Track](https://docs.dependencytrack.org/integrations/rest-api/)**. diff --git a/docs/content/connectors/toolreference/dependency_track.fr.md b/docs/content/connectors/toolreference/dependency_track.fr.md new file mode 100644 index 00000000000..1e8b88832c1 --- /dev/null +++ b/docs/content/connectors/toolreference/dependency_track.fr.md @@ -0,0 +1,22 @@ +--- +title: "Dependency-Track" +description: "Comment configurer le Connecteur Upstream Dependency-Track pour DefectDojo" +weight: 48 +audience: pro +--- +Ce connecteur récupère les données d'une instance Dependency\-Track sur site, via l'API REST. + +​**Mappages du connecteur** + +1. Saisissez l'URL de votre serveur Dependency\-Track local dans le champ **Location**. +2. Saisissez une clé d'API valide dans le champ **Secret**. + +Pour générer une clé d'API Dependency\-Track : + +1. **Access Management** : accédez à Administration \> Access Management \> Teams dans l'interface Dependency\-Track. +2. **Teams Setup** : vous pouvez créer une nouvelle équipe ou en sélectionner une existante. Les équipes permettent de gérer l'accès à l'API en fonction de l'appartenance à un groupe. +3. **Generate API Key** : sur la page de détails de l'équipe sélectionnée, trouvez la section « API Keys ». Cliquez sur le bouton \+ pour générer une nouvelle clé d'API. +4. **Assign Permissions** : dans la section « Permissions » de la page de l'équipe, cliquez sur le bouton \+ pour ouvrir le sélecteur de permissions. Choisissez les permissions **VIEW\_PORTFOLIO** et **VIEW\_VULNERABILITY** pour activer l'accès API aux portefeuilles de projets et aux détails des vulnérabilités. +5. Cliquez sur « **Select** » pour confirmer et enregistrer ces permissions. + +Pour plus d'informations, consultez la **[documentation Dependency\-Track](https://docs.dependencytrack.org/integrations/rest-api/)**. diff --git a/docs/content/connectors/toolreference/dependency_track.ja.md b/docs/content/connectors/toolreference/dependency_track.ja.md new file mode 100644 index 00000000000..d2b0f213084 --- /dev/null +++ b/docs/content/connectors/toolreference/dependency_track.ja.md @@ -0,0 +1,22 @@ +--- +title: "Dependency-Track" +description: "DefectDojo で Dependency-Track の Upstream Connector をセットアップする方法" +weight: 48 +audience: pro +--- +このコネクタは、REST API経由でオンプレミスのDependency-Trackインスタンスからデータを取得します。 + +​**Connector Mappings** + +1. **Location**フィールドにローカルのDependency-TrackサーバーのURLを入力します。 +2. **Secret**フィールドに有効なAPIキーを入力します。 + +Dependency-TrackのAPIキーを生成するには: + +1. **Access Management**: Dependency-Trackインターフェースで、Administration > Access Management > Teams に移動します。 +2. **Teams Setup**: 新しいチームを作成することも、既存のチームを選択することもできます。チームを使うことで、グループメンバーシップに基づいてAPIアクセスを管理できます。 +3. **Generate API Key**: 選択したチームの詳細ページで「API Keys」セクションを見つけます。+ボタンをクリックして新しいAPIキーを生成します。 +4. **Assign Permissions**: チームページの「Permissions」セクションで+ボタンをクリックし、権限セレクターを開きます。プロジェクトポートフォリオと脆弱性の詳細へのAPIアクセスを有効にするため、**VIEW_PORTFOLIO**と**VIEW_VULNERABILITY**の権限を選択します。 +5. 「**Select**」をクリックして、これらの権限を確認し保存します。 + +詳細については、**[Dependency-Track Documentation](https://docs.dependencytrack.org/integrations/rest-api/)**を参照してください。 diff --git a/docs/content/connectors/toolreference/dependency_track.md b/docs/content/connectors/toolreference/dependency_track.md new file mode 100644 index 00000000000..977c84aa43e --- /dev/null +++ b/docs/content/connectors/toolreference/dependency_track.md @@ -0,0 +1,22 @@ +--- +title: "Dependency-Track" +description: "How to set up the Dependency-Track Upstream Connector for DefectDojo" +weight: 48 +audience: pro +--- +This connector fetches data from a on\-premise Dependency\-Track instance, via REST API. + +​**Connector Mappings** + +1. Enter your local Dependency\-Track server URL in the **Location** field. +2. Enter a valid API key in the **Secret** field. + +To generate a Dependency\-Track API key: + +1. **Access Management**: Navigate to Administration \> Access Management \> Teams in the Dependency\-Track interface. +2. **Teams Setup**: You can either create a new team or select an existing one. Teams allow you to manage API access based on group membership. +3. **Generate API Key**: In the selected team's details page, find the "API Keys" section. Click the \+ button to generate a new API key. +4. **Assign Permissions**: In the "Permissions" section of the team's page, click the \+ button to open the permissions selector. Choose **VIEW\_PORTFOLIO** and **VIEW\_VULNERABILITY** permissions to enable API access to project portfolios and vulnerability details. +5. Click "**Select**" to confirm and save these permissions. + +For more information, see **[Dependency\-Track Documentation](https://docs.dependencytrack.org/integrations/rest-api/)**. diff --git a/docs/content/connectors/toolreference/detectify.md b/docs/content/connectors/toolreference/detectify.md new file mode 100644 index 00000000000..2e9cb3c5708 --- /dev/null +++ b/docs/content/connectors/toolreference/detectify.md @@ -0,0 +1,22 @@ +--- +title: "Detectify" +description: "How to set up the Detectify Upstream Connector for DefectDojo" +weight: 49 +audience: pro +--- +The Detectify connector imports **vulnerability findings** covering Application Scanning, Surface Monitoring and API Scanning in one connector. DefectDojo creates a Record for each **asset** in your account. + +#### Prerequisites + +A Detectify **API key**, from **Team settings \> API keys**. It is sent as the `X-Detectify-Key` header and never logged. + +Optionally, you can also supply the **base64 secret** paired with that key to have DefectDojo HMAC\-sign its requests. This is a **Professional plan** feature; without it, DefectDojo uses key\-only authentication, which works on all plans. + +#### Connector Mappings + +1. Enter `https://api.detectify.com/rest` in the **Location** field. +2. Enter your Detectify API key in the **API Key** field. +3. Optionally, enter the base64 secret in the **API Secret** field to enable request signing. Leave it blank for key\-only authentication. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each asset becomes a Record, carrying its vulnerabilities from all three Detectify scanning products. diff --git a/docs/content/connectors/toolreference/docker_scout.de.md b/docs/content/connectors/toolreference/docker_scout.de.md new file mode 100644 index 00000000000..0b1c2f83e4b --- /dev/null +++ b/docs/content/connectors/toolreference/docker_scout.de.md @@ -0,0 +1,24 @@ +--- +title: "Docker Scout" +description: "Einrichtung des Docker Scout Upstream-Connectors für DefectDojo" +weight: 50 +audience: pro +--- +Der Docker-Scout-Connector verwendet die Docker-Scout-Metrics-Exporter-API, um den Schwachstellenstatus der Images Ihrer Organisation zu melden. DefectDojo ermittelt jeden Docker-Scout-Stream (Ihre Laufzeitumgebungen) und importiert für jeden eine Zusammenfassung der Schwachstellen und der Richtlinien-Compliance. + +#### Voraussetzungen + +Sie benötigen ein persönliches Docker-Zugriffstoken, das von einem **Owner** einer Docker-Organisation erstellt wurde, die **bei Docker Scout registriert** ist. Der Metrics Exporter ist eine Funktion auf Organisationsebene, daher liefert ein persönliches Konto oder eine nicht bei Docker Scout registrierte Organisation keine Daten. + +Erstellen Sie das Token in Ihren Docker-Kontoeinstellungen unter **Personal access tokens**, und notieren Sie sich Ihren Docker-**Organisations-Namespace**, den Sie ebenfalls benötigen. + +#### Connector-Zuordnungen + +1. Geben Sie `https://api.scout.docker.com` in das Feld **Location** ein. +2. Geben Sie Ihr persönliches Docker-Zugriffstoken in das Feld **Secret** ein. +3. Geben Sie Ihren Docker-**Organization**-Namespace ein. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. + +DefectDojo erstellt für jeden Docker-Scout-Stream einen separaten Eintrag und importiert einen Befund pro Schweregrad für die Schwachstellen, die Docker Scout in diesem Stream zählt, sowie einen Befund für jedes Image, das Ihre Docker-Scout-Richtlinie nicht erfüllt. Die Metrics-API von Docker Scout meldet aggregierte Zählwerte statt einzelner CVEs, daher fassen diese Befunde den Status eines Streams zusammen. Öffnen Sie den Stream in Docker Scout für Details pro Image und pro CVE. + +Weitere Informationen finden Sie in der [Docker-Scout-Dokumentation](https://docs.docker.com/scout/). diff --git a/docs/content/connectors/toolreference/docker_scout.es.md b/docs/content/connectors/toolreference/docker_scout.es.md new file mode 100644 index 00000000000..0b91829bf80 --- /dev/null +++ b/docs/content/connectors/toolreference/docker_scout.es.md @@ -0,0 +1,24 @@ +--- +title: "Docker Scout" +description: "Cómo configurar el Conector Upstream de Docker Scout para DefectDojo" +weight: 50 +audience: pro +--- +El conector de Docker Scout utiliza la API del exportador de métricas de Docker Scout para informar sobre la postura de vulnerabilidades de las imágenes de su organización. DefectDojo detecta cada stream de Docker Scout (sus entornos de ejecución) e importa un resumen de las vulnerabilidades y el cumplimiento de políticas de cada uno. + +#### Requisitos previos + +Necesitará un personal access token de Docker creado por un **owner** de una organización de Docker que esté **inscrita en Docker Scout**. El exportador de métricas es una función a nivel de organización, por lo que una cuenta personal, o una organización no inscrita en Docker Scout, no devolverá datos. + +Cree el token desde la configuración de su cuenta de Docker, en **Personal access tokens**, y anote el **organization namespace** de Docker, que también necesitará. + +#### Asignaciones del conector + +1. Introduzca `https://api.scout.docker.com` en el campo **Location**. +2. Introduzca su personal access token de Docker en el campo **Secret**. +3. Introduzca su namespace de **Organization** de Docker. +4. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importarán. + +DefectDojo crea un Registro independiente para cada stream de Docker Scout, e importa un hallazgo por severidad para las vulnerabilidades que Docker Scout contabiliza en ese stream, además de un hallazgo por cada imagen que incumple su política de Docker Scout. La API de métricas de Docker Scout informa recuentos agregados en lugar de CVE individuales, por lo que estos hallazgos resumen la postura de un stream. Abra el stream en Docker Scout para ver el detalle por imagen y por CVE. + +Consulte la [documentación de Docker Scout](https://docs.docker.com/scout/) para obtener más información. diff --git a/docs/content/connectors/toolreference/docker_scout.fr.md b/docs/content/connectors/toolreference/docker_scout.fr.md new file mode 100644 index 00000000000..22645ca6706 --- /dev/null +++ b/docs/content/connectors/toolreference/docker_scout.fr.md @@ -0,0 +1,24 @@ +--- +title: "Docker Scout" +description: "Comment configurer le Connecteur Upstream Docker Scout pour DefectDojo" +weight: 50 +audience: pro +--- +Le connecteur Docker Scout utilise l'API de l'exportateur de métriques Docker Scout pour rendre compte de la posture de vulnérabilité des images de votre organisation. DefectDojo découvre chaque flux (stream) Docker Scout (vos environnements d'exécution) et importe un résumé des vulnérabilités et de la conformité aux politiques pour chacun. + +#### Prérequis + +Vous aurez besoin d'un jeton d'accès personnel Docker créé par un **owner** d'une organisation Docker **inscrite à Docker Scout**. L'exportateur de métriques est une fonctionnalité au niveau de l'organisation ; un compte personnel, ou une organisation non inscrite à Docker Scout, ne renverra donc aucune donnée. + +Créez le jeton depuis les paramètres de votre compte Docker, sous **Personal access tokens**, et notez votre **espace de noms d'organisation** Docker, qui vous sera également nécessaire. + +#### Mappages du connecteur + +1. Saisissez `https://api.scout.docker.com` dans le champ **Location**. +2. Saisissez votre jeton d'accès personnel Docker dans le champ **Secret**. +3. Saisissez votre espace de noms **Organization** Docker. +4. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. Les constatations d'une sévérité inférieure à celle sélectionnée ne seront pas importées. + +DefectDojo crée un enregistrement distinct pour chaque flux Docker Scout, et importe une constatation par sévérité pour les vulnérabilités que Docker Scout comptabilise dans ce flux, ainsi qu'une constatation pour chaque image qui échoue à votre politique Docker Scout. L'API de métriques de Docker Scout renvoie des comptages agrégés plutôt que des CVE individuels ; ces constatations résument donc la posture d'un flux. Ouvrez le flux dans Docker Scout pour obtenir le détail par image et par CVE. + +Pour plus d'informations, consultez la [documentation Docker Scout](https://docs.docker.com/scout/). diff --git a/docs/content/connectors/toolreference/docker_scout.ja.md b/docs/content/connectors/toolreference/docker_scout.ja.md new file mode 100644 index 00000000000..b34b2ecefeb --- /dev/null +++ b/docs/content/connectors/toolreference/docker_scout.ja.md @@ -0,0 +1,24 @@ +--- +title: "Docker Scout" +description: "DefectDojo で Docker Scout の Upstream Connector をセットアップする方法" +weight: 50 +audience: pro +--- +Docker Scoutコネクタは、Docker Scoutのmetrics exporter APIを使用して、組織のイメージの脆弱性状況を報告します。DefectDojoは、Docker Scoutの各stream（実行環境）を検出し、それぞれについて脆弱性とポリシー準拠状況のサマリーをインポートします。 + +#### Prerequisites + +**Docker Scoutに登録済み**のDocker組織の**owner**が作成した、Dockerのpersonal access tokenが必要です。metrics exporterは組織レベルの機能であるため、個人アカウントや、Docker Scoutに登録されていない組織では、データが返されません。 + +トークンは、Dockerアカウント設定の**Personal access tokens**から作成します。また、Dockerの**organization namespace**も必要になるため控えておいてください。 + +#### Connector Mappings + +1. **Location**フィールドに`https://api.scout.docker.com`を入力します。 +2. **Secret**フィールドにDockerのpersonal access tokenを入力します。 +3. Dockerの**Organization**namespaceを入力します。 +4. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。選択した深刻度未満の検出事項はインポートされません。 + +DefectDojoは、Docker Scoutのstreamごとに個別のレコードを作成し、そのstream内でDocker Scoutが集計した脆弱性について深刻度ごとに1件の検出事項をインポートするほか、Docker Scoutのポリシーに違反する各イメージについても検出事項をインポートします。Docker ScoutのmetricsAPIは個別のCVEではなく集計件数を報告するため、これらの検出事項はstreamの状況をまとめたものになります。イメージ単位・CVE単位の詳細については、Docker Scout上でそのstreamを開いて確認してください。 + +詳細については、[Docker Scoutのドキュメント](https://docs.docker.com/scout/)を参照してください。 diff --git a/docs/content/connectors/toolreference/docker_scout.md b/docs/content/connectors/toolreference/docker_scout.md new file mode 100644 index 00000000000..1849e222e27 --- /dev/null +++ b/docs/content/connectors/toolreference/docker_scout.md @@ -0,0 +1,24 @@ +--- +title: "Docker Scout" +description: "How to set up the Docker Scout Upstream Connector for DefectDojo" +weight: 50 +audience: pro +--- +The Docker Scout connector uses the Docker Scout metrics exporter API to report the vulnerability posture of your organization's images. DefectDojo discovers each Docker Scout stream (your runtime environments) and imports a summary of the vulnerabilities and policy compliance for each. + +#### Prerequisites + +You will need a Docker personal access token created by an **owner** of a Docker organization that is **enrolled in Docker Scout**. The metrics exporter is an organization-level feature, so a personal account, or an organization that is not enrolled in Docker Scout, will not return data. + +Create the token from your Docker account settings under **Personal access tokens**, and note your Docker **organization namespace**, which you will also need. + +#### Connector Mappings + +1. Enter `https://api.scout.docker.com` in the **Location** field. +2. Enter your Docker personal access token in the **Secret** field. +3. Enter your Docker **Organization** namespace. +4. 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 Docker Scout stream, and imports one finding per severity for the vulnerabilities Docker Scout counts in that stream, plus a finding for each image that fails your Docker Scout policy. Docker Scout's metrics API reports aggregate counts rather than individual CVEs, so these findings summarize the posture of a stream. Open the stream in Docker Scout for per-image and per-CVE detail. + +See the [Docker Scout documentation](https://docs.docker.com/scout/) for more information. diff --git a/docs/content/connectors/toolreference/downstream.de.md b/docs/content/connectors/toolreference/downstream.de.md new file mode 100644 index 00000000000..980c528ea6f --- /dev/null +++ b/docs/content/connectors/toolreference/downstream.de.md @@ -0,0 +1,27 @@ +--- +title: Referenz zu Downstream-Connector-Tools +description: Detaillierte Einrichtungsanleitungen für Downstream Connectors +weight: 2 +audience: pro +aliases: +- /de/connectors/downstream/downstream_toolreference/ +- /de/en/share_your_findings/integrations_toolreference +- /de/issue_tracking/pro_integration/integrations_toolreference/ +--- + +Hier finden Sie konkrete Anweisungen dazu, wie Sie einen DefectDojo Downstream Connector mit einem Issue-Tracker eines Drittanbieters einrichten. + +- [Azure DevOps Boards](/connectors/toolreference/azure_devops_boards/) +- [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector) +- [GitHub](/connectors/toolreference/github/#downstream-connector) +- [GitLab](/connectors/toolreference/gitlab/#downstream-connector) +- [Jira](/connectors/toolreference/jira/) +- [Linear](/connectors/toolreference/linear/) +- [Opsgenie](/connectors/toolreference/opsgenie/) +- [PagerDuty](/connectors/toolreference/pagerduty/) +- [ServiceNow](/connectors/toolreference/servicenow/) +- [ServiceNow SecOps](/connectors/toolreference/servicenow_secops/) +- [Shortcut](/connectors/toolreference/shortcut/) +- [Freshservice](/connectors/toolreference/freshservice/) +- [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/) +- [Zendesk](/connectors/toolreference/zendesk/) diff --git a/docs/content/connectors/toolreference/downstream.es.md b/docs/content/connectors/toolreference/downstream.es.md new file mode 100644 index 00000000000..be56d02289e --- /dev/null +++ b/docs/content/connectors/toolreference/downstream.es.md @@ -0,0 +1,27 @@ +--- +title: Referencia de herramientas de Downstream Connectors +description: Guías de configuración detalladas para Downstream Connectors +weight: 2 +audience: pro +aliases: +- /es/connectors/downstream/downstream_toolreference/ +- /es/en/share_your_findings/integrations_toolreference +- /es/issue_tracking/pro_integration/integrations_toolreference/ +--- + +Estas son las instrucciones específicas que detallan cómo configurar un Downstream Connector de DefectDojo con un rastreador de incidencias (Issue Tracker) de un tercero. + +- [Azure DevOps Boards](/connectors/toolreference/azure_devops_boards/) +- [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector) +- [GitHub](/connectors/toolreference/github/#downstream-connector) +- [GitLab](/connectors/toolreference/gitlab/#downstream-connector) +- [Jira](/connectors/toolreference/jira/) +- [Linear](/connectors/toolreference/linear/) +- [Opsgenie](/connectors/toolreference/opsgenie/) +- [PagerDuty](/connectors/toolreference/pagerduty/) +- [ServiceNow](/connectors/toolreference/servicenow/) +- [ServiceNow SecOps](/connectors/toolreference/servicenow_secops/) +- [Shortcut](/connectors/toolreference/shortcut/) +- [Freshservice](/connectors/toolreference/freshservice/) +- [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/) +- [Zendesk](/connectors/toolreference/zendesk/) diff --git a/docs/content/connectors/toolreference/downstream.fr.md b/docs/content/connectors/toolreference/downstream.fr.md new file mode 100644 index 00000000000..88afcc27f5c --- /dev/null +++ b/docs/content/connectors/toolreference/downstream.fr.md @@ -0,0 +1,26 @@ +--- +title: Référence des outils de connecteurs descendants +description: Guides de configuration détaillés pour les connecteurs descendants +weight: 2 +audience: pro +aliases: +- /fr/connectors/downstream/downstream_toolreference/ +- /fr/en/share_your_findings/integrations_toolreference +- /fr/issue_tracking/pro_integration/integrations_toolreference/ +--- + + +- [Azure DevOps Boards](/connectors/toolreference/azure_devops_boards/) +- [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector) +- [GitHub](/connectors/toolreference/github/#downstream-connector) +- [GitLab](/connectors/toolreference/gitlab/#downstream-connector) +- [Jira](/connectors/toolreference/jira/) +- [Linear](/connectors/toolreference/linear/) +- [Opsgenie](/connectors/toolreference/opsgenie/) +- [PagerDuty](/connectors/toolreference/pagerduty/) +- [ServiceNow](/connectors/toolreference/servicenow/) +- [ServiceNow SecOps](/connectors/toolreference/servicenow_secops/) +- [Shortcut](/connectors/toolreference/shortcut/) +- [Freshservice](/connectors/toolreference/freshservice/) +- [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/) +- [Zendesk](/connectors/toolreference/zendesk/) diff --git a/docs/content/connectors/toolreference/downstream.ja.md b/docs/content/connectors/toolreference/downstream.ja.md new file mode 100644 index 00000000000..127477e8a2b --- /dev/null +++ b/docs/content/connectors/toolreference/downstream.ja.md @@ -0,0 +1,27 @@ +--- +title: ダウンストリームコネクタ ツールリファレンス +description: ダウンストリームコネクタの詳細なセットアップガイド +weight: 2 +audience: pro +aliases: +- /ja/connectors/downstream/downstream_toolreference/ +- /ja/en/share_your_findings/integrations_toolreference +- /ja/issue_tracking/pro_integration/integrations_toolreference/ +--- + +DefectDojo のダウンストリームコネクタをサードパーティの Issue トラッカーと連携させるための、具体的な設定手順を以下に示します。 + +- [Azure DevOps Boards](/connectors/toolreference/azure_devops_boards/) +- [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector) +- [GitHub](/connectors/toolreference/github/#downstream-connector) +- [GitLab](/connectors/toolreference/gitlab/#downstream-connector) +- [Jira](/connectors/toolreference/jira/) +- [Linear](/connectors/toolreference/linear/) +- [Opsgenie](/connectors/toolreference/opsgenie/) +- [PagerDuty](/connectors/toolreference/pagerduty/) +- [ServiceNow](/connectors/toolreference/servicenow/) +- [ServiceNow SecOps](/connectors/toolreference/servicenow_secops/) +- [Shortcut](/connectors/toolreference/shortcut/) +- [Freshservice](/connectors/toolreference/freshservice/) +- [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/) +- [Zendesk](/connectors/toolreference/zendesk/) diff --git a/docs/content/connectors/toolreference/downstream.md b/docs/content/connectors/toolreference/downstream.md new file mode 100644 index 00000000000..8255d2afabc --- /dev/null +++ b/docs/content/connectors/toolreference/downstream.md @@ -0,0 +1,26 @@ +--- +title: "Downstream Connectors Tool Reference" +description: "Detailed setup guides for Downstream Connectors" +weight: 2 +audience: pro +aliases: + - /connectors/downstream/downstream_toolreference/ + - /en/share_your_findings/integrations_toolreference + - /issue_tracking/pro_integration/integrations_toolreference/ +--- +Here are specific instructions detailing how to set up a DefectDojo Downstream Connector with a third party Issue Tracker. + +- [Azure DevOps Boards](/connectors/toolreference/azure_devops_boards/) +- [Bitbucket](/connectors/toolreference/bitbucket/#downstream-connector) +- [GitHub](/connectors/toolreference/github/#downstream-connector) +- [GitLab](/connectors/toolreference/gitlab/#downstream-connector) +- [Jira](/connectors/toolreference/jira/) +- [Linear](/connectors/toolreference/linear/) +- [Opsgenie](/connectors/toolreference/opsgenie/) +- [PagerDuty](/connectors/toolreference/pagerduty/) +- [ServiceNow](/connectors/toolreference/servicenow/) +- [ServiceNow SecOps](/connectors/toolreference/servicenow_secops/) +- [Shortcut](/connectors/toolreference/shortcut/) +- [Freshservice](/connectors/toolreference/freshservice/) +- [ServiceDesk Plus](/connectors/toolreference/servicedesk_plus/) +- [Zendesk](/connectors/toolreference/zendesk/) diff --git a/docs/content/connectors/toolreference/dragos.md b/docs/content/connectors/toolreference/dragos.md new file mode 100644 index 00000000000..2e9ea403346 --- /dev/null +++ b/docs/content/connectors/toolreference/dragos.md @@ -0,0 +1,26 @@ +--- +title: "Dragos" +description: "How to set up the Dragos Upstream Connector for DefectDojo" +weight: 51 +audience: pro +--- +The Dragos connector imports **OT/ICS vulnerability findings** from a Dragos SiteStore deployment. DefectDojo creates a Record for each **OT zone** — one SiteStore deployment represents one site, so the zone is the meaningful grouping within it. + +#### Prerequisites + +A Dragos **API key ID and secret**, created under **Admin \> Users \> Add New API Key**. The key needs these read privileges: + +* `asset:read` +* `detection:read` +* `vulnerability:read` + +The secret is shown only once when the key is generated, so capture it then. It is never logged. + +#### Connector Mappings + +1. Enter your Dragos **SiteStore** host in the **Location** field. +2. Enter the API key ID in the **API Key ID** field. +3. Enter the secret in the **API Key Secret** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each OT zone becomes a Record, carrying the vulnerabilities detected on the assets in that zone. diff --git a/docs/content/connectors/toolreference/edgescan.de.md b/docs/content/connectors/toolreference/edgescan.de.md new file mode 100644 index 00000000000..508d91dba03 --- /dev/null +++ b/docs/content/connectors/toolreference/edgescan.de.md @@ -0,0 +1,19 @@ +--- +title: "Edgescan" +description: "Einrichtung des Edgescan Upstream-Connectors für DefectDojo" +weight: 52 +audience: pro +--- +Der Edgescan-Connector verwendet die Edgescan-REST-API, um offene Schwachstellen aus Ihrem gesamten Edgescan-Konto zu importieren. DefectDojo zählt jedes Edgescan-**Asset** auf und erstellt für jedes einen Eintrag; anschließend werden die offenen Schwachstellen dieses Assets als Befunde importiert — es gibt keine Pro-Asset-Konfiguration. + +#### Voraussetzungen + +Sie benötigen ein Edgescan-API-Token. Erstellen Sie eines in Ihrem Edgescan-Konto unter **Account settings \> API tokens**: Geben Sie eine Bezeichnung ein, klicken Sie auf **Create**, und kopieren Sie das generierte Token (es wird nur einmal angezeigt). Wir empfehlen ein dediziertes Konto für den Connector, damit automatisierte Aktivitäten leicht zu unterscheiden sind. + +#### Connector-Zuordnungen + +1. Geben Sie Ihre Edgescan-URL in das Feld **Location** ein — `https://live.edgescan.com` für die Standard-Hosted-Plattform, oder den Host Ihres Tenants, falls abweichend. +2. Geben Sie Ihr Edgescan-API-Token in das Feld **Secret** ein. Es wird als `X-API-TOKEN`-Header gesendet. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jedes Edgescan-Asset wird zu einem Eintrag, und jede offene Schwachstelle dieses Assets wird als Befund importiert. Der Schweregrad wird von Edgescans numerischer Skala (1–5) auf DefectDojos Info–Kritisch abgebildet, und CVE-Referenzen, die CWE sowie ein CVSS-v3-Vektor werden einbezogen, sofern Edgescan sie bereitstellt. diff --git a/docs/content/connectors/toolreference/edgescan.es.md b/docs/content/connectors/toolreference/edgescan.es.md new file mode 100644 index 00000000000..0b18206b176 --- /dev/null +++ b/docs/content/connectors/toolreference/edgescan.es.md @@ -0,0 +1,19 @@ +--- +title: "Edgescan" +description: "Cómo configurar el Conector Upstream de Edgescan para DefectDojo" +weight: 52 +audience: pro +--- +El conector de Edgescan utiliza la API REST de Edgescan para importar las vulnerabilidades abiertas de toda su cuenta de Edgescan. DefectDojo enumera todos los **activos** de Edgescan y crea un Registro para cada uno; a continuación, importa las vulnerabilidades abiertas de ese activo como hallazgos. No existe configuración por activo. + +#### Requisitos previos + +Necesitará un token de API de Edgescan. Créelo desde su cuenta de Edgescan en **Account settings \> API tokens**: introduzca una etiqueta, haga clic en **Create** y copie el token generado (solo se muestra una vez). Recomendamos una cuenta dedicada para el conector, de modo que la actividad automatizada se distinga fácilmente. + +#### Asignaciones del conector + +1. Introduzca su URL de Edgescan en el campo **Location**: `https://live.edgescan.com` para la plataforma alojada estándar, o el host de su tenant si es distinto. +2. Introduzca su token de API de Edgescan en el campo **Secret**. Se envía en el encabezado `X-API-TOKEN`. +3. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada activo de Edgescan se convierte en un Registro, y cada vulnerabilidad abierta de ese activo se importa como un hallazgo. La severidad se asigna desde la escala numérica de Edgescan (1–5) a la escala Informativa–Crítica de DefectDojo, e incluye las referencias CVE, el CWE y un vector CVSS v3 cuando Edgescan los proporciona. diff --git a/docs/content/connectors/toolreference/edgescan.fr.md b/docs/content/connectors/toolreference/edgescan.fr.md new file mode 100644 index 00000000000..1a83de2297e --- /dev/null +++ b/docs/content/connectors/toolreference/edgescan.fr.md @@ -0,0 +1,19 @@ +--- +title: "Edgescan" +description: "Comment configurer le Connecteur Upstream Edgescan pour DefectDojo" +weight: 52 +audience: pro +--- +Le connecteur Edgescan utilise l'API REST Edgescan pour importer les vulnérabilités ouvertes de l'ensemble de votre compte Edgescan. DefectDojo énumère chaque **actif** Edgescan et crée un enregistrement pour chacun, puis importe les vulnérabilités ouvertes de cet actif sous forme de constatations — il n'y a pas de configuration par actif. + +#### Prérequis + +Vous aurez besoin d'un jeton d'API Edgescan. Créez-en un depuis votre compte Edgescan sous **Account settings \> API tokens** : saisissez un libellé, cliquez sur **Create**, puis copiez le jeton généré (il n'est affiché qu'une seule fois). Nous recommandons un compte dédié pour le connecteur afin que l'activité automatisée soit facile à distinguer. + +#### Mappages du connecteur + +1. Saisissez votre URL Edgescan dans le champ **Location** — `https://live.edgescan.com` pour la plateforme hébergée standard, ou l'hôte de votre tenant si différent. +2. Saisissez votre jeton d'API Edgescan dans le champ **Secret**. Il est envoyé dans l'en-tête `X-API-TOKEN`. +3. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque actif Edgescan devient un enregistrement, et chaque vulnérabilité ouverte sur cet actif est importée comme constatation. La sévérité est convertie de l'échelle numérique d'Edgescan (1–5) vers l'échelle Info–Critique de DefectDojo, et les références CVE, la CWE, ainsi qu'un vecteur CVSS v3 sont inclus lorsqu'Edgescan les fournit. diff --git a/docs/content/connectors/toolreference/edgescan.ja.md b/docs/content/connectors/toolreference/edgescan.ja.md new file mode 100644 index 00000000000..c9f0b415dc9 --- /dev/null +++ b/docs/content/connectors/toolreference/edgescan.ja.md @@ -0,0 +1,19 @@ +--- +title: "Edgescan" +description: "DefectDojo で Edgescan の Upstream Connector をセットアップする方法" +weight: 52 +audience: pro +--- +Edgescanコネクタは、Edgescan REST APIを使用して、Edgescanアカウント全体のオープンな脆弱性をインポートします。DefectDojoは、すべてのEdgescanの**アセット**を列挙してそれぞれについてレコードを作成し、そのアセットのオープンな脆弱性を検出事項としてインポートします。アセットごとの個別設定はありません。 + +#### Prerequisites + +EdgescanのAPIトークンが必要です。Edgescanアカウントの**Account settings > API tokens**からラベルを入力し、**Create**をクリックして、生成されたトークンをコピーします（トークンは一度しか表示されません）。自動化された操作を区別しやすくするため、コネクタ専用のアカウントを使用することをお勧めします。 + +#### Connector Mappings + +1. **Location**フィールドにEdgescanのURLを入力します。標準的なホスト版プラットフォームの場合は`https://live.edgescan.com`、異なる場合はテナントのホストを入力してください。 +2. **Secret**フィールドにEdgescanのAPIトークンを入力します。これは`X-API-TOKEN`ヘッダーとして送信されます。 +3. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 + +各Edgescanアセットはレコードとなり、そのアセット上のオープンな脆弱性はそれぞれ検出事項としてインポートされます。深刻度は、Edgescanの数値スケール（1〜5）からDefectDojoの情報〜重大にマッピングされます。また、Edgescanが提供している場合は、CVE参照、CWE、CVSS v3ベクトルも含まれます。 diff --git a/docs/content/connectors/toolreference/edgescan.md b/docs/content/connectors/toolreference/edgescan.md new file mode 100644 index 00000000000..59fcc766a9b --- /dev/null +++ b/docs/content/connectors/toolreference/edgescan.md @@ -0,0 +1,19 @@ +--- +title: "Edgescan" +description: "How to set up the Edgescan Upstream Connector for DefectDojo" +weight: 52 +audience: pro +--- +The Edgescan connector uses the Edgescan REST API to import open vulnerabilities across your whole Edgescan account. DefectDojo enumerates every Edgescan **asset** and creates a Record for each one, then imports that asset's open vulnerabilities as findings — there is no per\-asset configuration. + +#### Prerequisites + +You will need an Edgescan API token. Create one from your Edgescan account under **Account settings \> API tokens**: enter a label, click **Create**, and copy the generated token (it is shown only once). We recommend a dedicated account for the Connector so automated activity is easy to distinguish. + +#### Connector Mappings + +1. Enter your Edgescan URL in the **Location** field — `https://live.edgescan.com` for the standard hosted platform, or your tenant's host if different. +2. Enter your Edgescan API token in the **Secret** field. It is sent as the `X-API-TOKEN` header. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each Edgescan asset becomes a Record, and each open vulnerability on that asset is imported as a finding. Severity is mapped from Edgescan's numeric scale (1–5) to DefectDojo's Info–Critical, and CVE references, the CWE, and a CVSS v3 vector are included where Edgescan provides them. diff --git a/docs/content/connectors/toolreference/elastic_security.md b/docs/content/connectors/toolreference/elastic_security.md new file mode 100644 index 00000000000..55f3afbbf5f --- /dev/null +++ b/docs/content/connectors/toolreference/elastic_security.md @@ -0,0 +1,22 @@ +--- +title: "Elastic Security" +description: "How to set up the Elastic Security Upstream Connector for DefectDojo" +weight: 53 +audience: pro +--- +The Elastic Security connector imports **cloud vulnerability, posture and detection findings** from an Elasticsearch cluster, as three separate finding types. DefectDojo creates a Record for each **cloud account**. + +Not every Elastic finding carries a cloud account, so DefectDojo falls back in order: the **Kubernetes cluster** (for KSPM findings with no cloud account), then the **host**. Anything identifying none of those lands in a single catch\-all Record rather than being dropped. + +#### Prerequisites + +An Elasticsearch **API key**, supplied as the base64 `id:api_key` value. + +**Prefer an API key over a username and password**, because a key can be scoped read\-only to just the security indices. A username and password are supported as a fallback for clusters that do not have API keys enabled. + +#### Connector Mappings + +1. Enter your Elasticsearch cluster URL in the **Location** field. +2. Enter the base64 API key in the **API Key** field. Leave it blank if you are using a username and password instead. +3. If you are not using an API key, enter the **Username** and password for HTTP Basic authentication. These are only used when no API key is supplied. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. diff --git a/docs/content/connectors/toolreference/endor_labs.de.md b/docs/content/connectors/toolreference/endor_labs.de.md new file mode 100644 index 00000000000..1c26f03f748 --- /dev/null +++ b/docs/content/connectors/toolreference/endor_labs.de.md @@ -0,0 +1,26 @@ +--- +title: "Endor Labs" +description: "Einrichtung des Endor Labs Upstream-Connectors für DefectDojo" +weight: 54 +audience: pro +--- +Der Endor-Labs-Connector verwendet die Endor-Labs-REST-API, um einen gesamten Endor-Labs-**Namespace** zu synchronisieren. DefectDojo ermittelt jedes Endor-**Projekt** als Eintrag und importiert die Befunde dieses Projekts, wobei Endors **Reachability**-Bewertung übernommen wird, damit Sie Schwachstellen priorisieren können, deren betroffener Code tatsächlich erreichbar ist. + +#### Voraussetzungen + +Sie benötigen einen Endor-Labs-**API-Schlüssel** (eine Schlüsselkennung plus deren Secret) und den **Namespace**, den Sie synchronisieren möchten. Erstellen Sie den Schlüssel in der Endor-Labs-Plattform unter **Settings \> Access \> API Keys**; der Schlüssel benötigt Lesezugriff auf die Projekte und Befunde in diesem Namespace. + +Der Connector authentifiziert sich, indem er den API-Schlüssel und das Secret gegen ein kurzlebiges Bearer-Token eintauscht — das Secret wird nur für diesen Austausch verwendet und nie im Klartext gespeichert. + +#### Connector-Zuordnungen + +1. Geben Sie `https://api.endorlabs.com` in das Feld **Location** ein. Wenn Ihr Tenant in einer anderen Region gehostet wird, verwenden Sie stattdessen die API-Basis-URL dieser Region. +2. Geben Sie den zu synchronisierenden Endor-Labs-**Namespace** ein (zum Beispiel `your-org` oder `your-org.team`). +3. Geben Sie die **API-Key**-Kennung ein. +4. Geben Sie das zum Schlüssel gehörende **API Secret** ein. +5. Setzen Sie optional **Traverse Child Namespaces** auf `true`, um auch Befunde aus untergeordneten Namespaces des konfigurierten Namespace zu importieren. +6. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. + +DefectDojo erstellt für jedes Endor-Labs-Projekt im Namespace einen Eintrag und importiert dessen Befunde, wobei Endor-Schweregrade auf DefectDojo-Schweregrade, die CVE/GHSA-Kennungen und den CVSS-Score jeder Schwachstelle sowie Endors Reachability-Tags abgebildet werden. Die Reachability-Bewertung (zum Beispiel *Reachable — vulnerable function is called* oder *Unreachable*) wird als Impact des Befunds sowie als Tag angezeigt. + +Weitere Informationen finden Sie in der **[Endor-Labs-REST-API-Dokumentation](https://docs.endorlabs.com/rest-api/)**. diff --git a/docs/content/connectors/toolreference/endor_labs.es.md b/docs/content/connectors/toolreference/endor_labs.es.md new file mode 100644 index 00000000000..28727c6a5e0 --- /dev/null +++ b/docs/content/connectors/toolreference/endor_labs.es.md @@ -0,0 +1,26 @@ +--- +title: "Endor Labs" +description: "Cómo configurar el Conector Upstream de Endor Labs para DefectDojo" +weight: 54 +audience: pro +--- +El conector de Endor Labs utiliza la API REST de Endor Labs para sincronizar un **namespace** completo de Endor Labs. DefectDojo detecta cada **proyecto** de Endor como un Registro e importa los hallazgos de ese proyecto, trasladando el veredicto de **accesibilidad** de Endor para que pueda priorizar las vulnerabilidades cuyo código afectado sea realmente accesible. + +#### Requisitos previos + +Necesitará una **API key** de Endor Labs (un identificador de clave más su secret) y el **namespace** que desea sincronizar. Cree la clave en la plataforma de Endor Labs en **Settings \> Access \> API Keys**; la clave necesita acceso de lectura a los proyectos y hallazgos de ese namespace. + +El conector se autentica intercambiando la API key y el secret por un bearer token de corta duración; el secret se utiliza únicamente para ese intercambio y nunca se almacena en texto plano. + +#### Asignaciones del conector + +1. Introduzca `https://api.endorlabs.com` en el campo **Location**. Si su tenant está alojado en una región distinta, utilice en su lugar la URL base de la API de esa región. +2. Introduzca el **Namespace** de Endor Labs que desea sincronizar (por ejemplo `your-org` o `your-org.team`). +3. Introduzca el identificador de **API Key**. +4. Introduzca el **API Secret** asociado a la clave. +5. De forma opcional, defina **Traverse Child Namespaces** en `true` para importar también los hallazgos de los namespaces hijos del namespace configurado. +6. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importan. + +DefectDojo crea un Registro para cada proyecto de Endor Labs del namespace e importa sus hallazgos, asignando los niveles de severidad de Endor a las severidades de DefectDojo, los identificadores CVE/GHSA y la puntuación CVSS de cada vulnerabilidad, y las etiquetas de accesibilidad de Endor. El veredicto de accesibilidad (por ejemplo, *Reachable — vulnerable function is called* o *Unreachable*) se muestra como el Impact del hallazgo y como una etiqueta. + +Para obtener más información, consulte la **[documentación de la API REST de Endor Labs](https://docs.endorlabs.com/rest-api/)**. diff --git a/docs/content/connectors/toolreference/endor_labs.fr.md b/docs/content/connectors/toolreference/endor_labs.fr.md new file mode 100644 index 00000000000..0978c8aef07 --- /dev/null +++ b/docs/content/connectors/toolreference/endor_labs.fr.md @@ -0,0 +1,26 @@ +--- +title: "Endor Labs" +description: "Comment configurer le Connecteur Upstream Endor Labs pour DefectDojo" +weight: 54 +audience: pro +--- +Le connecteur Endor Labs utilise l'API REST Endor Labs pour synchroniser un **espace de noms (namespace)** Endor Labs entier. DefectDojo découvre chaque **projet** Endor sous forme d'enregistrement et importe les constatations de ce projet, en reprenant le verdict d'**accessibilité (reachability)** d'Endor afin de vous permettre de prioriser les vulnérabilités dont le code affecté est réellement atteignable. + +#### Prérequis + +Vous aurez besoin d'une **API key** Endor Labs (un identifiant de clé accompagné de son secret) et de l'**espace de noms (namespace)** à synchroniser. Créez la clé dans la plateforme Endor Labs sous **Settings \> Access \> API Keys** ; la clé doit disposer d'un accès en lecture aux projets et constatations de cet espace de noms. + +Le connecteur s'authentifie en échangeant la clé d'API et le secret contre un jeton porteur (bearer token) de courte durée — le secret n'est utilisé que pour cet échange et n'est jamais stocké en clair. + +#### Mappages du connecteur + +1. Saisissez `https://api.endorlabs.com` dans le champ **Location**. Si votre tenant est hébergé dans une autre région, utilisez plutôt l'URL de base de l'API de cette région. +2. Saisissez le **Namespace** Endor Labs à synchroniser (par exemple `your-org` ou `your-org.team`). +3. Saisissez l'identifiant de l'**API Key**. +4. Saisissez l'**API Secret** associé à la clé. +5. Facultativement, définissez **Traverse Child Namespaces** sur `true` pour importer également les constatations des espaces de noms enfants de l'espace de noms configuré. +6. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. Les constatations d'une sévérité inférieure à celle sélectionnée ne sont pas importées. + +DefectDojo crée un enregistrement pour chaque projet Endor Labs de l'espace de noms et importe ses constatations, en associant les niveaux de sévérité Endor aux sévérités DefectDojo, les identifiants CVE/GHSA et le score CVSS de chaque vulnérabilité, ainsi que les étiquettes d'accessibilité d'Endor. Le verdict d'accessibilité (par exemple *Reachable — vulnerable function is called* ou *Unreachable*) est présenté comme l'Impact de la constatation et comme une étiquette. + +Pour plus d'informations, consultez la **[documentation de l'API REST Endor Labs](https://docs.endorlabs.com/rest-api/)**. diff --git a/docs/content/connectors/toolreference/endor_labs.ja.md b/docs/content/connectors/toolreference/endor_labs.ja.md new file mode 100644 index 00000000000..29160d0b7a8 --- /dev/null +++ b/docs/content/connectors/toolreference/endor_labs.ja.md @@ -0,0 +1,26 @@ +--- +title: "Endor Labs" +description: "DefectDojo で Endor Labs の Upstream Connector をセットアップする方法" +weight: 54 +audience: pro +--- +Endor Labsコネクタは、Endor Labs REST APIを使用してEndor Labsの**ネームスペース**全体を同期します。DefectDojoは、Endorの各**プロジェクト**をレコードとして検出し、そのプロジェクトの検出事項をインポートします。その際、Endorの**到達可能性（reachability）**判定も引き継がれるため、実際に到達可能なコードに影響する脆弱性を優先的に対応できます。 + +#### Prerequisites + +Endor Labsの**APIキー**（キー識別子とそのsecretの組み合わせ）と、同期したい**ネームスペース**が必要です。キーはEndor Labsプラットフォームの**Settings > Access > API Keys**で作成します。このキーには、対象ネームスペース内のプロジェクトと検出事項への読み取りアクセス権が必要です。 + +コネクタは、APIキーとsecretを短命のベアラートークンと交換することで認証を行います。secretはこの交換にのみ使用され、平文で保存されることはありません。 + +#### Connector Mappings + +1. **Location**フィールドに`https://api.endorlabs.com`を入力します。テナントが別のリージョンでホストされている場合は、そのリージョンのAPIベースURLを使用してください。 +2. 同期したいEndor Labsの**Namespace**を入力します（例: `your-org`や`your-org.team`）。 +3. **API Key**識別子を入力します。 +4. キーに対応する**API Secret**を入力します。 +5. 必要に応じて、設定したネームスペースの子ネームスペースからも検出事項をインポートするために、**Traverse Child Namespaces**を`true`に設定します。 +6. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。選択した深刻度未満の検出事項はインポートされません。 + +DefectDojoは、ネームスペース内のEndor Labsプロジェクトごとにレコードを作成し、その検出事項をインポートします。その際、Endorの深刻度レベルはDefectDojoの深刻度にマッピングされ、各脆弱性のCVE/GHSA識別子とCVSSスコア、およびEndorの到達可能性タグも引き継がれます。到達可能性の判定（例: *Reachable — vulnerable function is called*や*Unreachable*）は、検出事項のImpactおよびタグとして表示されます。 + +詳細については、**[Endor Labs REST APIのドキュメント](https://docs.endorlabs.com/rest-api/)**を参照してください。 diff --git a/docs/content/connectors/toolreference/endor_labs.md b/docs/content/connectors/toolreference/endor_labs.md new file mode 100644 index 00000000000..52f2c18dd5a --- /dev/null +++ b/docs/content/connectors/toolreference/endor_labs.md @@ -0,0 +1,26 @@ +--- +title: "Endor Labs" +description: "How to set up the Endor Labs Upstream Connector for DefectDojo" +weight: 54 +audience: pro +--- +The Endor Labs connector uses the Endor Labs REST API to sync an entire Endor Labs **namespace**. DefectDojo discovers each Endor **project** as a Record and imports that project's findings, carrying Endor's **reachability** verdict so you can prioritize vulnerabilities whose affected code is actually reachable. + +#### Prerequisites + +You will need an Endor Labs **API key** (a key identifier plus its secret) and the **namespace** you want to sync. Create the key in the Endor Labs platform under **Settings \> Access \> API Keys**; the key needs read access to the projects and findings in that namespace. + +The connector authenticates by exchanging the API key and secret for a short-lived bearer token — the secret is used only for that exchange and is never stored in cleartext. + +#### Connector Mappings + +1. Enter `https://api.endorlabs.com` in the **Location** field. If your tenant is hosted in a different region, use that region's API base URL instead. +2. Enter the Endor Labs **Namespace** to sync (for example `your-org` or `your-org.team`). +3. Enter the **API Key** identifier. +4. Enter the **API Secret** paired with the key. +5. Optionally set **Traverse Child Namespaces** to `true` to also import findings from child namespaces of the configured namespace. +6. Optionally set a **Minimum Severity** to limit which findings are imported. Findings below the selected severity are not imported. + +DefectDojo creates a Record for each Endor Labs project in the namespace and imports its findings, mapping Endor severity levels to DefectDojo severities, the CVE/GHSA identifiers and CVSS score of each vulnerability, and Endor's reachability tags. The reachability verdict (for example *Reachable — vulnerable function is called* or *Unreachable*) is surfaced as the finding's Impact and as a tag. + +For more information, see the **[Endor Labs REST API documentation](https://docs.endorlabs.com/rest-api/)**. diff --git a/docs/content/connectors/toolreference/escape.de.md b/docs/content/connectors/toolreference/escape.de.md new file mode 100644 index 00000000000..00e08ec60f3 --- /dev/null +++ b/docs/content/connectors/toolreference/escape.de.md @@ -0,0 +1,21 @@ +--- +title: "Escape" +description: "Einrichtung des Escape Upstream-Connectors für DefectDojo" +weight: 55 +audience: pro +--- +Der Escape-Connector verwendet die [Escape](https://escape.tech)-API, um **API-Sicherheits(DAST)-Befunde** zu importieren. DefectDojo zählt jede Organisation, auf die das Token zugreifen kann, sowie jede Anwendung darin auf, erstellt für jede Anwendung mit einem Scan einen Eintrag und importiert die Issues des letzten Scans dieser Anwendung als Befunde — es gibt keine Pro-Anwendungs-Konfiguration. + +#### Voraussetzungen + +Sie benötigen einen Escape-**API-Schlüssel**, der in der Escape-App unter **Settings → API keys** erstellt wird. Der Schlüssel wird im Header `Authorization: Key` gesendet und nie protokolliert. + +#### Connector-Zuordnungen + +1. Lassen Sie das Feld **Location** leer, um `https://public.escape.tech/v2` zu verwenden, oder geben Sie Ihren Escape-API-Host explizit an. +2. Geben Sie den Escape-API-Schlüssel in das Feld **Secret** ein. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo ordnet jede **Anwendung** einem Eintrag zu und jedes Scan-**Issue** einem Befund: Der Schweregrad stammt aus Escapes Bewertung (Critical/High/Medium/Low), die CWE wird übernommen, die OWASP-Kategorie und die HTTP-Methode werden zu Tags, die betroffene URL wird zum Endpunkt, und die Abhilfehinweise werden einbezogen. Befunde werden als dynamische Befunde erfasst und anhand der Escape-Issue-ID dedupliziert. + +Weitere Informationen finden Sie in der [Escape-API-Dokumentation](https://docs.escape.tech/). diff --git a/docs/content/connectors/toolreference/escape.es.md b/docs/content/connectors/toolreference/escape.es.md new file mode 100644 index 00000000000..d886cd5473a --- /dev/null +++ b/docs/content/connectors/toolreference/escape.es.md @@ -0,0 +1,21 @@ +--- +title: "Escape" +description: "Cómo configurar el Conector Upstream de Escape para DefectDojo" +weight: 55 +audience: pro +--- +El conector de Escape utiliza la API de [Escape](https://escape.tech) para importar **hallazgos de seguridad de API (DAST)**. DefectDojo enumera todas las organizaciones a las que el token tiene acceso y todas las aplicaciones de cada una, crea un Registro para cada aplicación que tenga un escaneo, e importa como hallazgos las incidencias del escaneo más reciente de esa aplicación. No existe configuración por aplicación. + +#### Requisitos previos + +Necesitará una **API key** de Escape, creada en la aplicación de Escape en **Settings → API keys**. La clave se envía en el encabezado `Authorization: Key` y nunca se registra en los logs. + +#### Asignaciones del conector + +1. Deje el campo **Location** en blanco para usar `https://public.escape.tech/v2`, o introduzca explícitamente el host de la API de Escape. +2. Introduzca la clave de API de Escape en el campo **Secret**. +3. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo asigna cada **aplicación** a un Registro y cada **issue** del escaneo a un hallazgo: la severidad proviene de la calificación de Escape (Crítica/Alta/Media/Baja), se traslada el CWE, la categoría OWASP y el método HTTP se convierten en etiquetas, la URL afectada se convierte en el endpoint, y se incluye la guía de remediación. Los hallazgos se registran como hallazgos dinámicos y se deduplican según el id de la issue de Escape. + +Consulte la [documentación de la API de Escape](https://docs.escape.tech/) para obtener más información. diff --git a/docs/content/connectors/toolreference/escape.fr.md b/docs/content/connectors/toolreference/escape.fr.md new file mode 100644 index 00000000000..2b55519ae07 --- /dev/null +++ b/docs/content/connectors/toolreference/escape.fr.md @@ -0,0 +1,21 @@ +--- +title: "Escape" +description: "Comment configurer le Connecteur Upstream Escape pour DefectDojo" +weight: 55 +audience: pro +--- +Le connecteur Escape utilise l'API [Escape](https://escape.tech) pour importer des **constatations de sécurité API (DAST)**. DefectDojo énumère chaque organisation à laquelle le jeton a accès ainsi que chaque application qu'elle contient, crée un enregistrement pour chaque application ayant fait l'objet d'un scan, et importe les issues du dernier scan de cette application sous forme de constatations — il n'y a pas de configuration par application. + +#### Prérequis + +Vous aurez besoin d'une **API key** Escape, créée dans l'application Escape sous **Settings → API keys**. La clé est envoyée dans l'en-tête `Authorization: Key` et n'est jamais journalisée. + +#### Mappages du connecteur + +1. Laissez le champ **Location** vide pour utiliser `https://public.escape.tech/v2`, ou saisissez explicitement l'hôte de votre API Escape. +2. Saisissez la clé d'API Escape dans le champ **Secret**. +3. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +DefectDojo associe chaque **application** à un enregistrement et chaque **issue** de scan à une constatation : la sévérité provient de la notation d'Escape (Critical/High/Medium/Low), la CWE est reprise, la catégorie OWASP et la méthode HTTP deviennent des étiquettes, l'URL affectée devient le point de terminaison, et les recommandations de remédiation sont incluses. Les constatations sont enregistrées comme constatations dynamiques et dédupliquées sur l'identifiant d'issue Escape. + +Pour plus d'informations, consultez la [documentation de l'API Escape](https://docs.escape.tech/). diff --git a/docs/content/connectors/toolreference/escape.ja.md b/docs/content/connectors/toolreference/escape.ja.md new file mode 100644 index 00000000000..9862fc35763 --- /dev/null +++ b/docs/content/connectors/toolreference/escape.ja.md @@ -0,0 +1,21 @@ +--- +title: "Escape" +description: "DefectDojo で Escape の Upstream Connector をセットアップする方法" +weight: 55 +audience: pro +--- +Escapeコネクタは、[Escape](https://escape.tech) APIを使用して**APIセキュリティ（DAST）の検出事項**をインポートします。DefectDojoは、トークンがアクセスできるすべての組織と、それぞれの組織内のすべてのアプリケーションを列挙し、スキャンがあるアプリケーションごとにレコードを作成して、そのアプリケーションの最新スキャンのissueを検出事項としてインポートします。アプリケーションごとの個別設定はありません。 + +#### Prerequisites + +Escapeの**APIキー**が必要です。これはEscapeアプリの**Settings → API keys**で作成します。このキーは`Authorization: Key`ヘッダーで送信され、ログに記録されることはありません。 + +#### Connector Mappings + +1. **Location**フィールドを空欄のままにすると`https://public.escape.tech/v2`が使用されます。あるいは、EscapeのAPIホストを明示的に入力することもできます。 +2. **Secret**フィールドにEscapeのAPIキーを入力します。 +3. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 + +DefectDojoは、各**アプリケーション**をレコードにマッピングし、スキャンの各**issue**を検出事項にマッピングします。深刻度はEscapeの評価（重大/高/中/低）に基づき、CWEが引き継がれ、OWASPカテゴリとHTTPメソッドがタグになり、影響を受けるURLがエンドポイントになり、修復ガイダンスも含まれます。検出事項は動的検出事項として記録され、Escapeのissue IDで重複排除されます。 + +詳細については、[Escape APIのドキュメント](https://docs.escape.tech/)を参照してください。 diff --git a/docs/content/connectors/toolreference/escape.md b/docs/content/connectors/toolreference/escape.md new file mode 100644 index 00000000000..fbb5afe41e7 --- /dev/null +++ b/docs/content/connectors/toolreference/escape.md @@ -0,0 +1,21 @@ +--- +title: "Escape" +description: "How to set up the Escape Upstream Connector for DefectDojo" +weight: 55 +audience: pro +--- +The Escape connector uses the [Escape](https://escape.tech) API to import **API\-security (DAST) findings**. DefectDojo enumerates every organization the token can access and every application within each, creates a Record for each application that has a scan, and imports that application's latest scan issues as findings — there is no per\-application configuration. + +#### Prerequisites + +You will need an Escape **API key**, created in the Escape app under **Settings → API keys**. The key is sent in the `Authorization: Key` header and is never logged. + +#### Connector Mappings + +1. Leave the **Location** field blank to use `https://public.escape.tech/v2`, or enter your Escape API host explicitly. +2. Enter the Escape API key in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo maps each **application** to a Record and each scan **issue** to a finding: the severity comes from Escape's rating (Critical/High/Medium/Low), the CWE is carried over, the OWASP category and HTTP method become tags, the affected URL becomes the endpoint, and the remediation guidance is included. Findings are recorded as dynamic findings and de\-duplicated on Escape's issue id. + +See the [Escape API documentation](https://docs.escape.tech/) for more information. diff --git a/docs/content/connectors/toolreference/fairwinds_insights.de.md b/docs/content/connectors/toolreference/fairwinds_insights.de.md new file mode 100644 index 00000000000..998a0a9f5b7 --- /dev/null +++ b/docs/content/connectors/toolreference/fairwinds_insights.de.md @@ -0,0 +1,22 @@ +--- +title: "Fairwinds Insights" +description: "Einrichtung des Fairwinds Insights Upstream-Connectors für DefectDojo" +weight: 56 +audience: pro +--- +Der Fairwinds-Insights-Connector verwendet die REST-API von [Fairwinds Insights](https://insights.fairwinds.com), um **Kubernetes-Sicherheitsbefunde** aus Ihrer gesamten Organisation zu importieren. DefectDojo zählt jeden aktiven **Cluster** auf und erstellt für jeden einen Eintrag; anschließend werden die Security-**Action Items** dieses Clusters \(von Polaris, Trivy, Kube\-bench, OPA und den anderen Insights-Berichten\) als Befunde importiert — es gibt keine Pro-Cluster-Konfiguration. + +#### Voraussetzungen + +Sie benötigen einen Fairwinds-Insights-**Organisationsnamen** und ein **API-Token**. Erstellen Sie das Token in der Insights-App unter **Organization Settings \> Tokens**; ein `read_only`-Token ist ausreichend. Das Token ist organisationsweit gültig und wird als Bearer-Token gesendet; es wird nie protokolliert. + +#### Connector-Zuordnungen + +1. Lassen Sie das Feld **Location** leer, um `https://insights.fairwinds.com` zu verwenden, oder geben Sie Ihren Insights-Host explizit an. +2. Geben Sie Ihren Insights-**Organization**-Namen ein (den Slug, der in Ihrer Dashboard-URL angezeigt wird). +3. Geben Sie das Insights-API-Token in das Feld **Secret** ein. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo ordnet jeden aktiven **Cluster** einem Eintrag zu und jedes Security-**Action Item** einem Befund: Der Schweregrad stammt aus Fairwinds' numerischer Bewertung \(abgebildet auf DefectDojos Info–Kritisch\), der Fairwinds-Bericht, der das Item erzeugt hat \(`polaris`, `trivy`, `kube-bench`, ...\), wird zu einem Tool-Tag, die betroffene Kubernetes-Ressource und das Container-Image werden einbezogen, und etwaige CVE-Kennungen werden extrahiert. Befunde werden als statische Befunde erfasst und anhand der Fairwinds-Action-Item-ID dedupliziert. + +Weitere Informationen finden Sie in der [Fairwinds-Insights-API-Dokumentation](https://insights.docs.fairwinds.com/technical-details/api/). diff --git a/docs/content/connectors/toolreference/fairwinds_insights.es.md b/docs/content/connectors/toolreference/fairwinds_insights.es.md new file mode 100644 index 00000000000..3304790420b --- /dev/null +++ b/docs/content/connectors/toolreference/fairwinds_insights.es.md @@ -0,0 +1,22 @@ +--- +title: "Fairwinds Insights" +description: "Cómo configurar el Conector Upstream de Fairwinds Insights para DefectDojo" +weight: 56 +audience: pro +--- +El conector de Fairwinds Insights utiliza la API REST de [Fairwinds Insights](https://insights.fairwinds.com) para importar **hallazgos de seguridad de Kubernetes** de toda su organización. DefectDojo enumera todos los **clusters** activos y crea un Registro para cada uno; a continuación, importa como hallazgos los **action items** de seguridad de ese cluster \(de Polaris, Trivy, Kube\-bench, OPA y los demás informes de Insights\). No existe configuración por cluster. + +#### Requisitos previos + +Necesitará un nombre de **organización** de Fairwinds Insights y un **API token**. Cree el token en la aplicación de Insights en **Organization Settings \> Tokens**; basta con un token `read_only`. El token tiene alcance de organización y se envía como bearer token; nunca se registra en los logs. + +#### Asignaciones del conector + +1. Deje el campo **Location** en blanco para usar `https://insights.fairwinds.com`, o introduzca explícitamente el host de Insights. +2. Introduzca el nombre de **Organization** de Insights (el slug que aparece en la URL de su panel). +3. Introduzca el token de API de Insights en el campo **Secret**. +4. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo asigna cada **cluster** activo a un Registro y cada **action item** de Security a un hallazgo: la severidad proviene de la puntuación numérica de Fairwinds \(asignada a la escala Informativa–Crítica de DefectDojo\), el informe de Fairwinds que generó el elemento \(`polaris`, `trivy`, `kube-bench`, ...\) se convierte en una etiqueta de herramienta, se incluyen el recurso de Kubernetes afectado y la imagen del contenedor, y se extraen los identificadores CVE si los hay. Los hallazgos se registran como hallazgos estáticos y se deduplican según el id del action item de Fairwinds. + +Consulte la [documentación de la API de Fairwinds Insights](https://insights.docs.fairwinds.com/technical-details/api/) para obtener más información. diff --git a/docs/content/connectors/toolreference/fairwinds_insights.fr.md b/docs/content/connectors/toolreference/fairwinds_insights.fr.md new file mode 100644 index 00000000000..842d0cb8d70 --- /dev/null +++ b/docs/content/connectors/toolreference/fairwinds_insights.fr.md @@ -0,0 +1,22 @@ +--- +title: "Fairwinds Insights" +description: "Comment configurer le Connecteur Upstream Fairwinds Insights pour DefectDojo" +weight: 56 +audience: pro +--- +Le connecteur Fairwinds Insights utilise l'API REST [Fairwinds Insights](https://insights.fairwinds.com) pour importer des **constatations de sécurité Kubernetes** sur l'ensemble de votre organisation. DefectDojo énumère chaque **cluster** actif et crée un enregistrement pour chacun, puis importe les **action items** de sécurité de ce cluster \(provenant de Polaris, Trivy, Kube\-bench, OPA et des autres rapports Insights\) sous forme de constatations — il n'y a pas de configuration par cluster. + +#### Prérequis + +Vous aurez besoin d'un nom d'**organisation** Fairwinds Insights et d'un **jeton d'API**. Créez le jeton dans l'application Insights sous **Organization Settings \> Tokens** ; un jeton `read_only` suffit. Le jeton est limité à l'organisation (org-scoped) et est envoyé comme jeton porteur (bearer token) ; il n'est jamais journalisé. + +#### Mappages du connecteur + +1. Laissez le champ **Location** vide pour utiliser `https://insights.fairwinds.com`, ou saisissez explicitement l'hôte de votre instance Insights. +2. Saisissez votre nom d'**Organization** Insights (le slug affiché dans l'URL de votre tableau de bord). +3. Saisissez le jeton d'API Insights dans le champ **Secret**. +4. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +DefectDojo associe chaque **cluster** actif à un enregistrement et chaque **action item** de sécurité à une constatation : la sévérité provient du score numérique de Fairwinds \(converti vers l'échelle Info–Critique de DefectDojo\), le rapport Fairwinds à l'origine de l'élément \(`polaris`, `trivy`, `kube-bench`, ...\) devient une étiquette d'outil, la ressource Kubernetes affectée et l'image de conteneur sont incluses, et les identifiants CVE éventuels sont extraits. Les constatations sont enregistrées comme constatations statiques et dédupliquées sur l'identifiant d'action item Fairwinds. + +Pour plus d'informations, consultez la [documentation de l'API Fairwinds Insights](https://insights.docs.fairwinds.com/technical-details/api/). diff --git a/docs/content/connectors/toolreference/fairwinds_insights.ja.md b/docs/content/connectors/toolreference/fairwinds_insights.ja.md new file mode 100644 index 00000000000..e982f0f55ec --- /dev/null +++ b/docs/content/connectors/toolreference/fairwinds_insights.ja.md @@ -0,0 +1,22 @@ +--- +title: "Fairwinds Insights" +description: "DefectDojo で Fairwinds Insights の Upstream Connector をセットアップする方法" +weight: 56 +audience: pro +--- +Fairwinds Insightsコネクタは、[Fairwinds Insights](https://insights.fairwinds.com) REST APIを使用して、組織全体の**Kubernetesセキュリティの検出事項**をインポートします。DefectDojoは、アクティブな**クラスタ**をすべて列挙してそれぞれについてレコードを作成し、そのクラスタのSecurity **アクションアイテム**（Polaris、Trivy、Kube-bench、OPA、その他のInsightsレポートに由来）を検出事項としてインポートします。クラスタごとの個別設定はありません。 + +#### Prerequisites + +Fairwinds Insightsの**organization**名と**APIトークン**が必要です。トークンはInsightsアプリの**Organization Settings > Tokens**で作成します。`read_only`トークンで十分です。このトークンは組織単位のスコープを持ち、ベアラートークンとして送信されます。ログに記録されることはありません。 + +#### Connector Mappings + +1. **Location**フィールドを空欄のままにすると`https://insights.fairwinds.com`が使用されます。あるいは、Insightsのホストを明示的に入力することもできます。 +2. Insightsの**Organization**名（ダッシュボードのURLに表示されるスラッグ）を入力します。 +3. **Secret**フィールドにInsightsのAPIトークンを入力します。 +4. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 + +DefectDojoは、アクティブな各**クラスタ**をレコードにマッピングし、Securityの各**アクションアイテム**を検出事項にマッピングします。深刻度はFairwindsの数値スコア（DefectDojoの情報〜重大にマッピング）に基づき、そのアイテムを生成したFairwindsのレポート（`polaris`、`trivy`、`kube-bench`など）がツールタグになり、影響を受けるKubernetesリソースとコンテナイメージが含まれ、CVE識別子があれば抽出されます。検出事項は静的検出事項として記録され、Fairwindsのアクションアイテムのidで重複排除されます。 + +詳細については、[Fairwinds Insights APIのドキュメント](https://insights.docs.fairwinds.com/technical-details/api/)を参照してください。 diff --git a/docs/content/connectors/toolreference/fairwinds_insights.md b/docs/content/connectors/toolreference/fairwinds_insights.md new file mode 100644 index 00000000000..6581f03f634 --- /dev/null +++ b/docs/content/connectors/toolreference/fairwinds_insights.md @@ -0,0 +1,22 @@ +--- +title: "Fairwinds Insights" +description: "How to set up the Fairwinds Insights Upstream Connector for DefectDojo" +weight: 56 +audience: pro +--- +The Fairwinds Insights connector uses the [Fairwinds Insights](https://insights.fairwinds.com) REST API to import **Kubernetes security findings** across your whole organization. DefectDojo enumerates every active **cluster** and creates a Record for each one, then imports that cluster's Security **action items** \(from Polaris, Trivy, Kube\-bench, OPA and the other Insights reports\) as findings — there is no per\-cluster configuration. + +#### Prerequisites + +You will need a Fairwinds Insights **organization** name and an **API token**. Create the token in the Insights app under **Organization Settings \> Tokens**; a `read_only` token is sufficient. The token is org\-scoped and is sent as a bearer token; it is never logged. + +#### Connector Mappings + +1. Leave the **Location** field blank to use `https://insights.fairwinds.com`, or enter your Insights host explicitly. +2. Enter your Insights **Organization** name (the slug shown in your dashboard URL). +3. Enter the Insights API token in the **Secret** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo maps each active **cluster** to a Record and each Security **action item** to a finding: severity comes from Fairwinds' numeric score \(mapped to DefectDojo's Info–Critical\), the Fairwinds report that produced the item \(`polaris`, `trivy`, `kube-bench`, ...\) becomes a tool tag, the affected Kubernetes resource and container image are included, and any CVE identifiers are extracted. Findings are recorded as static findings and de\-duplicated on the Fairwinds action\-item id. + +See the [Fairwinds Insights API documentation](https://insights.docs.fairwinds.com/technical-details/api/) for more information. diff --git a/docs/content/connectors/toolreference/finite_state.md b/docs/content/connectors/toolreference/finite_state.md new file mode 100644 index 00000000000..eac131511e4 --- /dev/null +++ b/docs/content/connectors/toolreference/finite_state.md @@ -0,0 +1,22 @@ +--- +title: "Finite State" +description: "How to set up the Finite State Upstream Connector for DefectDojo" +weight: 57 +audience: pro +--- +The Finite State connector imports **firmware and embedded-device findings** from Finite State. DefectDojo creates a Record for each **Asset**, which in Finite State is a **product line** rather than an individual firmware build. + +This matters for how your data is organized: a product line's findings are the union of its builds' findings, with the build recorded on each finding as a tag and in the description. One Record therefore accumulates the history of a firmware line, instead of fragmenting into a separate Record per release. + +#### Prerequisites + +A Finite State **API token**. It is sent in the `X-Authorization` header — not `Authorization` — which the connector handles for you. + +#### Connector Mappings + +1. Enter your Finite State subdomain in the **Location** field — for example `https://acme.finitestate.io`. DefectDojo appends the API path itself. +2. Enter the API token in the **API Token** field. +3. Optionally, set **Import Every Firmware Build** to `true` to import findings from **every** build of each asset. Leave it blank to import only the **newest** build, which is what most teams want. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Merged duplicates and deleted findings are excluded automatically, so they never reach DefectDojo. diff --git a/docs/content/connectors/toolreference/fleet.md b/docs/content/connectors/toolreference/fleet.md new file mode 100644 index 00000000000..abd51299ff5 --- /dev/null +++ b/docs/content/connectors/toolreference/fleet.md @@ -0,0 +1,25 @@ +--- +title: "Fleet" +description: "How to set up the Fleet Upstream Connector for DefectDojo" +weight: 58 +audience: pro +--- +The Fleet connector imports **software vulnerabilities** and **failing compliance policies** from Fleet, as two separate finding types. DefectDojo creates a Record for each Fleet **team**. + +Hosts that belong to no team still carry real vulnerabilities, so they are mapped to a synthetic **"No team"** Record rather than being dropped. + +> **Teams are a Fleet Premium feature.** On a free Fleet deployment the team list is unavailable, so **every host** lands in the single synthetic Record. That is expected, not a mapping failure. + +#### Prerequisites + +A Fleet **API token**, from **Account Settings \> Get API token**. The connector needs **read access only** — on Fleet Premium you can issue a scoped API\-only user for it. + +#### Connector Mappings + +1. Enter your Fleet server URL in the **Location** field. +2. Enter the API token in the **API Token** field. +3. Optionally, enable **Skip software vulnerabilities** to leave out CVEs found on installed software. Leave it off to import them. +4. Optionally, enable **Skip compliance policies** to leave out failing osquery policy checks. Leave it off to import them under their own scan type. +5. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Both imports are on by default — the two toggles exist to turn each off if you only want one kind of finding in DefectDojo. diff --git a/docs/content/connectors/toolreference/fortify.de.md b/docs/content/connectors/toolreference/fortify.de.md new file mode 100644 index 00000000000..574e77750c6 --- /dev/null +++ b/docs/content/connectors/toolreference/fortify.de.md @@ -0,0 +1,26 @@ +--- +title: "Fortify" +description: "Einrichtung des Fortify Upstream-Connectors für DefectDojo" +weight: 59 +audience: pro +--- +Der Fortify-Connector importiert SAST-/DAST-Ergebnisse von Fortify (OpenText/Micro Focus) und deckt beide Editionen ab, die sich die Plattform teilen: **SSC** (Software Security Center, selbstgehostet) und **Fortify on Demand (FoD)** (SaaS). Er synchronisiert das gesamte Konto: DefectDojo ermittelt jede Anwendung (SSC-Projektversion/FoD-Release) und erstellt für jede einen Eintrag; anschließend werden die Issues dieser Anwendung als Befunde importiert. + +#### Voraussetzungen + +- **SSC**: ein **FortifyToken** — erstellen Sie eines in der SSC-Oberfläche unter **Administration → Token Management** (ein CIToken/UnifiedLoginToken). +- **FoD**: ein **OAuth2-API-Schlüssel** — eine Client ID und ein Client Secret aus **Settings → API** (mit dem Scope `api-tenant`). + +Das Token und das OAuth-Secret werden nie protokolliert. + +#### Connector-Zuordnungen + +1. Geben Sie die Fortify-Basis-URL in das Feld **Location** ein: für SSC Ihren Server-Host (der Connector ergänzt `/ssc/api/v1`); für FoD den API-Host Ihrer Region, z. B. `https://api.ams.fortify.com`. +2. Setzen Sie **Edition** auf `SSC` oder `FoD`. +3. Geben Sie für **FoD** die OAuth-**Client ID** ein; für SSC leer lassen. +4. Geben Sie in **Token / Client Secret** das SSC-FortifyToken oder das FoD-OAuth-Client-Secret ein. +5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo ordnet jede Fortify-**Anwendung** einem Eintrag zu und jedes **Issue** einem Befund: Der Schweregrad stammt aus Fortifys eigener **Friority**-Bewertung (Critical/High/Medium/Low), der Titel kombiniert die Issue-Kategorie mit Datei und Zeile, und Dateipfad, Zeile, Kingdom, Analyzer und Engine-Typ werden übernommen. Issues von statischen Analyse-Engines (SCA) werden als statische Befunde erfasst und WebInspect(DAST)-Issues als dynamische Befunde; unterdrückte, entfernte und verborgene Issues werden übersprungen, als „Not an Issue" geprüfte Issues werden als falsch-positiv markiert, und „Exploitable"/geprüfte Issues werden als verifiziert markiert. + +Weitere Informationen finden Sie in der Dokumentation zu [Fortify SSC](https://www.microfocus.com/documentation/fortify-software-security-center/) und [Fortify on Demand](https://api.ams.fortify.com/swagger/ui). diff --git a/docs/content/connectors/toolreference/fortify.es.md b/docs/content/connectors/toolreference/fortify.es.md new file mode 100644 index 00000000000..a06e399748c --- /dev/null +++ b/docs/content/connectors/toolreference/fortify.es.md @@ -0,0 +1,26 @@ +--- +title: "Fortify" +description: "Cómo configurar el Conector Upstream de Fortify para DefectDojo" +weight: 59 +audience: pro +--- +El conector de Fortify importa resultados SAST/DAST de Fortify (OpenText/Micro Focus), abarcando las dos ediciones que comparten la plataforma: **SSC** (Software Security Center, autoalojado) y **Fortify on Demand (FoD)** (SaaS). Sincroniza toda la cuenta: DefectDojo detecta todas las aplicaciones (project version de SSC / release de FoD) y crea un Registro para cada una; a continuación, importa las incidencias de esa aplicación como hallazgos. + +#### Requisitos previos + +- **SSC**: un **FortifyToken**; créelo en la interfaz de SSC en **Administration → Token Management** (un CIToken/UnifiedLoginToken). +- **FoD**: una **OAuth2 API key**; un Client ID y un Client Secret desde **Settings → API** (con el scope `api-tenant`). + +El token y el secret de OAuth nunca se registran en los logs. + +#### Asignaciones del conector + +1. Introduzca la URL base de Fortify en el campo **Location**: para SSC, el host de su servidor (el conector añade `/ssc/api/v1`); para FoD, el host de la API de su región, por ejemplo, `https://api.ams.fortify.com`. +2. Defina **Edition** en `SSC` o `FoD`. +3. Para **FoD**, introduzca el **Client ID** de OAuth; déjelo en blanco para SSC. +4. En **Token / Client Secret**, introduzca el FortifyToken de SSC o el client secret de OAuth de FoD. +5. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo asigna cada **aplicación** de Fortify a un Registro y cada **issue** a un hallazgo: la severidad proviene de la propia calificación de **friority** de Fortify (Crítica/Alta/Media/Baja), el título combina la categoría de la incidencia con su archivo y línea, y se trasladan la ruta del archivo, la línea, el kingdom, el analizador y el tipo de motor. Las incidencias de los motores de análisis estático (SCA) se registran como hallazgos estáticos y las incidencias de WebInspect (DAST) como hallazgos dinámicos; las incidencias suprimidas, eliminadas u ocultas se omiten, las incidencias auditadas como "Not an Issue" se marcan como falso positivo, y las incidencias "Exploitable" o revisadas se marcan como verificadas. + +Consulte la documentación de la API de [Fortify SSC](https://www.microfocus.com/documentation/fortify-software-security-center/) y de [Fortify on Demand](https://api.ams.fortify.com/swagger/ui) para obtener más información. diff --git a/docs/content/connectors/toolreference/fortify.fr.md b/docs/content/connectors/toolreference/fortify.fr.md new file mode 100644 index 00000000000..715ce0a60aa --- /dev/null +++ b/docs/content/connectors/toolreference/fortify.fr.md @@ -0,0 +1,26 @@ +--- +title: "Fortify" +description: "Comment configurer le Connecteur Upstream Fortify pour DefectDojo" +weight: 59 +audience: pro +--- +Le connecteur Fortify importe les résultats SAST/DAST de Fortify (OpenText/Micro Focus), couvrant les deux éditions qui partagent la plateforme : **SSC** (Software Security Center, auto-hébergé) et **Fortify on Demand (FoD)** (SaaS). Il synchronise l'ensemble du compte : DefectDojo découvre chaque application (version de projet SSC / release FoD) et crée un enregistrement pour chacune, puis importe les issues de cette application sous forme de constatations. + +#### Prérequis + +- **SSC** : un **FortifyToken** — créez-en un dans l'interface SSC sous **Administration → Token Management** (un CIToken/UnifiedLoginToken). +- **FoD** : une **clé d'API OAuth2** — un Client ID et un Client Secret depuis **Settings → API** (avec le scope `api-tenant`). + +Le jeton et le secret OAuth ne sont jamais journalisés. + +#### Mappages du connecteur + +1. Saisissez l'URL de base de Fortify dans le champ **Location** : pour SSC, l'hôte de votre serveur (le connecteur ajoute `/ssc/api/v1`) ; pour FoD, l'hôte de l'API de votre région, par exemple `https://api.ams.fortify.com`. +2. Définissez **Edition** sur `SSC` ou `FoD`. +3. Pour **FoD**, saisissez le **Client ID** OAuth ; laissez-le vide pour SSC. +4. Dans **Token / Client Secret**, saisissez le FortifyToken SSC ou le client secret OAuth FoD. +5. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +DefectDojo associe chaque **application** Fortify à un enregistrement et chaque **issue** à une constatation : la sévérité provient de la notation **friority** propre à Fortify (Critical/High/Medium/Low), le titre combine la catégorie de l'issue avec son fichier et sa ligne, et le chemin du fichier, la ligne, le kingdom, l'analyzer et le type de moteur sont repris. Les issues provenant des moteurs d'analyse statique (SCA) sont enregistrées comme constatations statiques et les issues WebInspect (DAST) comme constatations dynamiques ; les issues supprimées, retirées ou masquées sont ignorées, les issues auditées « Not an Issue » sont marquées Faux positif, et les issues « Exploitable » / revues sont marquées Vérifié. + +Pour plus d'informations, consultez la documentation de l'API [Fortify SSC](https://www.microfocus.com/documentation/fortify-software-security-center/) et [Fortify on Demand](https://api.ams.fortify.com/swagger/ui). diff --git a/docs/content/connectors/toolreference/fortify.ja.md b/docs/content/connectors/toolreference/fortify.ja.md new file mode 100644 index 00000000000..bdddad4812e --- /dev/null +++ b/docs/content/connectors/toolreference/fortify.ja.md @@ -0,0 +1,26 @@ +--- +title: "Fortify" +description: "DefectDojo で Fortify の Upstream Connector をセットアップする方法" +weight: 59 +audience: pro +--- +Fortifyコネクタは、Fortify（OpenText/Micro Focus）からSAST/DASTの結果をインポートします。同じプラットフォームを共有する2つのエディション、**SSC**（Software Security Center、自己ホスト型）と**Fortify on Demand（FoD）**（SaaS）の両方に対応しています。アカウント全体を同期し、DefectDojoはすべてのアプリケーション（SSCのproject version / FoDのrelease）を検出してそれぞれについてレコードを作成し、そのアプリケーションのissueを検出事項としてインポートします。 + +#### Prerequisites + +- **SSC**: **FortifyToken**が必要です。これはSSC UIの**Administration → Token Management**で作成します（CIToken/UnifiedLoginToken）。 +- **FoD**: **OAuth2 APIキー**が必要です。これは**Settings → API**から取得するClient IDとClient Secretです（`api-tenant`スコープを付与）。 + +トークンとOAuthのsecretがログに記録されることはありません。 + +#### Connector Mappings + +1. **Location**フィールドにFortifyのベースURLを入力します。SSCの場合はサーバーのホスト（コネクタが`/ssc/api/v1`を追加します）、FoDの場合はリージョンに応じたAPIホスト（例: `https://api.ams.fortify.com`）を入力します。 +2. **Edition**を`SSC`または`FoD`に設定します。 +3. **FoD**の場合は、OAuthの**Client ID**を入力します。SSCの場合は空欄のままにします。 +4. **Token / Client Secret**には、SSCのFortifyTokenまたはFoDのOAuthクライアントシークレットを入力します。 +5. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 + +DefectDojoは、Fortifyの各**アプリケーション**をレコードにマッピングし、各**issue**を検出事項にマッピングします。深刻度はFortify独自の**friority**評価（重大/高/中/低）に基づき、タイトルはissueのカテゴリとファイル・行番号を組み合わせたものになります。また、ファイルパス、行番号、kingdom、analyzer、engine typeが引き継がれます。静的解析エンジン（SCA）のissueは静的検出事項として、WebInspect（DAST）のissueは動的検出事項として記録されます。抑制済み・削除済み・非表示のissueはスキップされ、「Not an Issue」と判定されたissueは誤検知としてマークされ、「Exploitable」/レビュー済みのissueは検証済みとしてマークされます。 + +詳細については、[Fortify SSC](https://www.microfocus.com/documentation/fortify-software-security-center/)および[Fortify on Demand](https://api.ams.fortify.com/swagger/ui)のAPIドキュメントを参照してください。 diff --git a/docs/content/connectors/toolreference/fortify.md b/docs/content/connectors/toolreference/fortify.md new file mode 100644 index 00000000000..6150ef9379e --- /dev/null +++ b/docs/content/connectors/toolreference/fortify.md @@ -0,0 +1,26 @@ +--- +title: "Fortify" +description: "How to set up the Fortify Upstream Connector for DefectDojo" +weight: 59 +audience: pro +--- +The Fortify connector imports SAST/DAST results from Fortify (OpenText/Micro Focus), covering both editions that share the platform: **SSC** (Software Security Center, self-hosted) and **Fortify on Demand (FoD)** (SaaS). It syncs the whole account: DefectDojo discovers every application (SSC project version / FoD release) and creates a Record for each, then imports that application's issues as findings. + +#### Prerequisites + +- **SSC**: a **FortifyToken** — create one in the SSC UI under **Administration → Token Management** (a CIToken/UnifiedLoginToken). +- **FoD**: an **OAuth2 API key** — a Client ID and Client Secret from **Settings → API** (with the `api-tenant` scope). + +The token and OAuth secret are never logged. + +#### Connector Mappings + +1. Enter the Fortify base URL in the **Location** field: for SSC your server host (the connector adds `/ssc/api/v1`); for FoD the API host for your region, e.g. `https://api.ams.fortify.com`. +2. Set **Edition** to `SSC` or `FoD`. +3. For **FoD**, enter the OAuth **Client ID**; leave it blank for SSC. +4. In **Token / Client Secret**, enter the SSC FortifyToken or the FoD OAuth client secret. +5. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo maps each Fortify **application** to a Record and each **issue** to a finding: the severity comes from Fortify's own **friority** rating (Critical/High/Medium/Low), the title combines the issue category with its file and line, and the file path, line, kingdom, analyzer and engine type are carried over. Issues from static-analysis engines (SCA) are recorded as static findings and WebInspect (DAST) issues as dynamic findings; suppressed, removed and hidden issues are skipped, issues audited "Not an Issue" are marked false positive, and "Exploitable"/reviewed issues are marked verified. + +See the [Fortify SSC](https://www.microfocus.com/documentation/fortify-software-security-center/) and [Fortify on Demand](https://api.ams.fortify.com/swagger/ui) API documentation for more information. diff --git a/docs/content/connectors/toolreference/fossa.md b/docs/content/connectors/toolreference/fossa.md new file mode 100644 index 00000000000..6824ed6a8cd --- /dev/null +++ b/docs/content/connectors/toolreference/fossa.md @@ -0,0 +1,21 @@ +--- +title: "FOSSA" +description: "How to set up the FOSSA Upstream Connector for DefectDojo" +weight: 60 +audience: pro +--- +The FOSSA connector imports both **security vulnerabilities** and **license-policy violations** from FOSSA. DefectDojo creates a Record for each FOSSA **project**. + +#### Prerequisites + +A FOSSA **Full** API token. + +> **A Push-Only token will not work.** FOSSA's Push-Only tokens cannot read the APIs this connector uses, so the Sync fails to retrieve anything. This is the most common misconfiguration for this connector — make sure the token is a **Full** token. + +#### Connector Mappings + +1. Enter `https://app.fossa.com/api` in the **Location** field. +2. Enter your FOSSA Full API token in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each FOSSA project becomes a Record. Only your organization's **active** issues are imported, covering both vulnerability and license-policy findings — so this connector can drive licence compliance work as well as security remediation. diff --git a/docs/content/connectors/toolreference/freshservice.de.md b/docs/content/connectors/toolreference/freshservice.de.md new file mode 100644 index 00000000000..fe46efac09d --- /dev/null +++ b/docs/content/connectors/toolreference/freshservice.de.md @@ -0,0 +1,46 @@ +--- +title: "Freshservice" +description: "Einrichtung des Freshservice Downstream-Connectors für DefectDojo" +weight: 61 +audience: pro +--- +Die Freshservice-Integration ermöglicht es Ihnen, DefectDojo-Befunde und Befundgruppen als Freshservice-Tickets zu übertragen, die einer Agenten-Gruppe Ihrer Wahl zugewiesen werden. + +### Instanz-Einrichtung + +- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf Ihre Freshservice-URL gesetzt werden: `https://yourcompany.freshservice.com`. +- **API Key** sollte ein Freshservice-API-Key sein. Sie finden ihn, indem Sie auf Ihr Profilbild (oben rechts) > **Profile settings** klicken - der Key erscheint rechts unterhalb des Abschnitts **Delegate Approvals**, nachdem Sie das Captcha gelöst haben. Wird dort kein Key angezeigt, ist der API-Zugriff möglicherweise auf Kontoebene deaktiviert und muss zuerst von einem Administrator aktiviert werden. +- **Requester Email** sollte die E-Mail-Adresse sein, in deren Namen Tickets angefordert werden. Freshservice verlangt für jedes Ticket einen Anforderer, daher erstellt DefectDojo Tickets mit dieser Adresse als Anforderer. + +### Issue-Tracker-Zuordnung + +- **Group ID** sollte die numerische ID der Freshservice-Agenten-Gruppe sein, der Tickets zugewiesen werden. Sie finden sie in der URL, während Sie die Gruppe unter **Admin > Agent Groups** ansehen. +- **Workspace ID** (optional) leitet Tickets bei Konten mit mehreren Workspaces an einen bestimmten Workspace. Lassen Sie das Feld leer, um den primären Workspace zu verwenden. + +### Details zur Schweregrad-Zuordnung + +Dies wird dem Freshservice-Ticketfeld **Priority** zugeordnet, das numerische Codes verwendet (`1` Low, `2` Medium, `3` High, `4` Urgent). Die Prioritätsnamen werden ebenfalls akzeptiert: + +- **Name des Schweregrad-Felds**: `Priority` +- **Info-Zuordnung**: `1` +- **Niedrig-Zuordnung**: `1` +- **Mittel-Zuordnung**: `2` +- **Hoch-Zuordnung**: `3` +- **Kritisch-Zuordnung**: `4` + +### Details zur Status-Zuordnung + +Dies wird dem Ticketfeld **Status** zugeordnet, das numerische Codes verwendet (`2` Open, `3` Pending, `4` Resolved, `5` Closed). Die Statusnamen werden ebenfalls akzeptiert: + +- **Name des Status-Felds**: `Status` +- **Aktiv-Zuordnung**: `2` +- **Geschlossen-Zuordnung**: `5` +- **Falsch-positiv-Zuordnung**: `5` +- **Risiko-akzeptiert-Zuordnung**: `3` + +Einige Freshservice-spezifische Verhaltensweisen, die Sie kennen sollten: + +- Aktualisierungen synchronisieren den vollständigen Ticketinhalt - Freshservice erlaubt es, Betreff und Beschreibung nach dem Erstellen zu bearbeiten. +- Tickets werden geschlossen und nicht gelöscht, wenn ein Befund entfernt wird; Tickets, die bereits Resolved oder Closed sind, bleiben unberührt. Beim Schließen wird automatisch eine Lösungsnotiz angehängt, sodass Konten, die eine solche verlangen (eine verbreitete Geschäftsregel), das Schließen akzeptieren. +- Manche Konten berechnen die Priorität eines Tickets aus einer Impact-/Urgency-Matrix oder einer Geschäftsregel und ignorieren die beim Erstellen gesendete Priorität. DefectDojo erkennt dies und wendet die zugeordnete Priorität mit einer nachgelagerten Aktualisierung erneut an, sodass die Zuordnung dennoch wirksam wird. diff --git a/docs/content/connectors/toolreference/freshservice.es.md b/docs/content/connectors/toolreference/freshservice.es.md new file mode 100644 index 00000000000..0714456613c --- /dev/null +++ b/docs/content/connectors/toolreference/freshservice.es.md @@ -0,0 +1,46 @@ +--- +title: "Freshservice" +description: "Cómo configurar el Conector Downstream de Freshservice para DefectDojo" +weight: 61 +audience: pro +--- +La integración con Freshservice le permite enviar los Hallazgos y Grupos de Hallazgos de DefectDojo como tickets de Freshservice, asignados a un Group de agentes de su elección. + +### Configuración de la instancia + +- **Label** debe ser la etiqueta que desee usar para identificar esta integración. +- **Location** debe configurarse con su URL de Freshservice: `https://yourcompany.freshservice.com`. +- **API Key** debe ser una clave de API de Freshservice. Encuéntrela haciendo clic en su foto de perfil (arriba a la derecha) > **Profile settings**: la clave aparece a la derecha, debajo de la sección **Delegate Approvals**, después de completar el captcha. Si no aparece ninguna clave ahí, es posible que el acceso a la API esté deshabilitado a nivel de cuenta y un administrador deba habilitarlo primero. +- **Requester Email** debe ser la dirección de correo en cuyo nombre se solicitan los tickets. Freshservice exige un solicitante en cada ticket, por lo que DefectDojo crea los tickets con esta dirección como solicitante. + +### Mapeo del sistema de tickets + +- **Group ID** debe ser el ID numérico del Group de agentes de Freshservice al que se asignarán los tickets. Encuéntrelo en la URL al ver el grupo en **Admin > Agent Groups**. +- **Workspace ID** (opcional) enruta los tickets a un espacio de trabajo específico en cuentas con varios espacios de trabajo. Déjelo vacío para usar el espacio de trabajo principal. + +### Detalles del mapeo de severidad + +Esto se corresponde con el campo **Priority** del ticket de Freshservice, que usa códigos numéricos (`1` Low, `2` Medium, `3` High, `4` Urgent). También se aceptan los nombres de prioridad: + +- **Nombre del campo de severidad**: `Priority` +- **Mapeo de Informativa**: `1` +- **Mapeo de Baja**: `1` +- **Mapeo de Media**: `2` +- **Mapeo de Alta**: `3` +- **Mapeo de Crítica**: `4` + +### Detalles del mapeo de estado + +Esto se corresponde con el campo **Status** del ticket, que usa códigos numéricos (`2` Open, `3` Pending, `4` Resolved, `5` Closed). También se aceptan los nombres de estado: + +- **Nombre del campo de estado**: `Status` +- **Mapeo de Activo**: `2` +- **Mapeo de Cerrado**: `5` +- **Mapeo de Falso positivo**: `5` +- **Mapeo de Riesgo aceptado**: `3` + +Algunos comportamientos específicos de Freshservice que debe tener en cuenta: + +- Las actualizaciones sincronizan el contenido completo del ticket: Freshservice permite editar el asunto y la descripción después de la creación. +- Los tickets se cierran en lugar de eliminarse cuando se elimina un Hallazgo; los tickets ya Resolved o Closed se dejan sin modificar. Se adjunta automáticamente una nota de resolución al cerrar, por lo que las cuentas que exigen una (una regla de negocio habitual) aceptan el cierre. +- Algunas cuentas calculan la prioridad de un ticket a partir de una matriz de Impact/Urgency o de una regla de negocio, e ignoran la prioridad enviada en la creación. DefectDojo detecta esto y vuelve a aplicar la prioridad mapeada con una actualización posterior, de modo que el mapeo sigue teniendo efecto. diff --git a/docs/content/connectors/toolreference/freshservice.fr.md b/docs/content/connectors/toolreference/freshservice.fr.md new file mode 100644 index 00000000000..c07f72d4a8d --- /dev/null +++ b/docs/content/connectors/toolreference/freshservice.fr.md @@ -0,0 +1,46 @@ +--- +title: "Freshservice" +description: "Comment configurer le Connecteur Downstream Freshservice pour DefectDojo" +weight: 61 +audience: pro +--- +L'intégration Freshservice vous permet de pousser les Constatations et Groupes de constatations DefectDojo sous forme de tickets Freshservice, affectés à un Group d'agents de votre choix. + +### Configuration de l'instance + +- **Label** doit être l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur votre URL Freshservice : `https://yourcompany.freshservice.com`. +- **API Key** doit être une clé API Freshservice. Trouvez-la en cliquant sur votre photo de profil (en haut à droite) > **Profile settings** - la clé apparaît à droite, sous la section **Delegate Approvals**, une fois le captcha complété. Si aucune clé n'y est affichée, l'accès API est peut-être désactivé au niveau du compte et un administrateur doit d'abord l'activer. +- **Requester Email** doit être l'adresse e-mail au nom de laquelle les tickets sont demandés. Freshservice exige un requester sur chaque ticket ; DefectDojo crée donc les tickets avec cette adresse comme requester. + +### Correspondance du suivi des tickets + +- **Group ID** doit être l'ID numérique du groupe d'agents Freshservice auquel les tickets seront affectés. Trouvez-le dans l'URL en consultant le groupe sous **Admin > Agent Groups**. +- **Workspace ID** (facultatif) achemine les tickets vers un espace de travail spécifique sur les comptes multi-espaces. Laissez-le vide pour utiliser l'espace de travail principal. + +### Détails de la correspondance des sévérités + +Ceci correspond au champ **Priority** du ticket Freshservice, qui utilise des codes numériques (`1` Low, `2` Medium, `3` High, `4` Urgent). Les noms de priorité sont également acceptés : + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `1` +- **Low Mapping**: `1` +- **Medium Mapping**: `2` +- **High Mapping**: `3` +- **Critical Mapping**: `4` + +### Détails de la correspondance des statuts + +Ceci correspond au champ **Status** du ticket, qui utilise des codes numériques (`2` Open, `3` Pending, `4` Resolved, `5` Closed). Les noms de statut sont également acceptés : + +- **Status Field Name**: `Status` +- **Active Mapping**: `2` +- **Closed Mapping**: `5` +- **False Positive Mapping**: `5` +- **Risk Accepted Mapping**: `3` + +Quelques comportements spécifiques à Freshservice à connaître : + +- Les mises à jour synchronisent l'intégralité du contenu du ticket - Freshservice permet de modifier l'objet et la description après la création. +- Les tickets sont fermés plutôt que supprimés lorsqu'une Constatation est retirée ; les tickets déjà Resolved ou Closed restent inchangés. Une note de résolution est jointe automatiquement à la fermeture, de sorte que les comptes qui en exigent une (une règle métier courante) acceptent la fermeture. +- Certains comptes calculent la priorité d'un ticket à partir d'une matrice Impact/Urgency ou d'une règle métier, et ignorent la priorité envoyée à la création. DefectDojo détecte ce cas et réapplique la priorité mappée via une mise à jour de suivi, de sorte que la correspondance finit tout de même par s'appliquer. diff --git a/docs/content/connectors/toolreference/freshservice.ja.md b/docs/content/connectors/toolreference/freshservice.ja.md new file mode 100644 index 00000000000..4e68cb7af34 --- /dev/null +++ b/docs/content/connectors/toolreference/freshservice.ja.md @@ -0,0 +1,46 @@ +--- +title: "Freshservice" +description: "DefectDojo で Freshservice のダウンストリームコネクタをセットアップする方法" +weight: 61 +audience: pro +--- +Freshservice 連携を使用すると、DefectDojo の検出事項および検出事項グループを Freshservice のチケットとしてプッシュし、任意の agent Group に割り当てることができます。 + +### インスタンスのセットアップ + +- **Label** には、この連携を識別するために使用したいラベルを設定します。 +- **Location** には、Freshservice の URL を設定します: `https://yourcompany.freshservice.com`。 +- **API Key** には、Freshservice の API キーを設定します。プロフィール画像(右上)をクリックして **Profile settings** を開き、キャプチャを完了すると、**Delegate Approvals** セクションの下、右側にキーが表示されます。キーが表示されない場合は、アカウントレベルで API アクセスが無効になっている可能性があるため、管理者に先に有効化してもらう必要があります。 +- **Requester Email** には、チケットの依頼元となるメールアドレスを設定します。Freshservice はすべてのチケットに依頼者を必須としているため、DefectDojo はこのアドレスを依頼者としてチケットを作成します。 + +### 課題管理マッピング + +- **Group ID** には、チケットの割り当て先となる Freshservice の agent group の数値 ID を設定します。**Admin > Agent Groups** でグループを表示しているときの URL から確認できます。 +- **Workspace ID**(任意)は、複数ワークスペースのアカウントで、チケットを特定のワークスペースに振り分けます。プライマリワークスペースを使用する場合は空欄のままにします。 + +### 深刻度マッピングの詳細 + +これは Freshservice チケットの **Priority** フィールドにマッピングされます。このフィールドは数値コード(`1` Low、`2` Medium、`3` High、`4` Urgent)を使用しますが、優先度名で指定することもできます。 + +- **深刻度フィールド名**: `Priority` +- **情報マッピング**: `1` +- **低マッピング**: `1` +- **中マッピング**: `2` +- **高マッピング**: `3` +- **重大マッピング**: `4` + +### ステータスマッピングの詳細 + +これはチケットの **Status** フィールドにマッピングされます。このフィールドは数値コード(`2` Open、`3` Pending、`4` Resolved、`5` Closed)を使用しますが、ステータス名で指定することもできます。 + +- **ステータスフィールド名**: `Status` +- **アクティブマッピング**: `2` +- **クローズマッピング**: `5` +- **誤検知マッピング**: `5` +- **リスク受容済みマッピング**: `3` + +Freshservice 固有の動作として、いくつか注意すべき点があります。 + +- 更新はチケットの内容全体を同期します。Freshservice では、作成後に件名と説明を編集できます。 +- 検出事項が削除されると、チケットは削除されるのではなくクローズされます。既に Resolved または Closed になっているチケットはそのままにされます。クローズ時には解決メモが自動的に添付されるため、これを必須とするアカウント(よくあるビジネスルール)でもクローズが受け付けられます。 +- 一部のアカウントでは、チケットの優先度を Impact/Urgency マトリクスやビジネスルールから算出し、作成時に送信された優先度を無視します。DefectDojo はこれを検知し、後続の更新でマッピングされた優先度を再適用するため、マッピングは引き続き反映されます。 diff --git a/docs/content/connectors/toolreference/freshservice.md b/docs/content/connectors/toolreference/freshservice.md new file mode 100644 index 00000000000..d55e9c7fdda --- /dev/null +++ b/docs/content/connectors/toolreference/freshservice.md @@ -0,0 +1,46 @@ +--- +title: "Freshservice" +description: "How to set up the Freshservice Downstream Connector for DefectDojo" +weight: 61 +audience: pro +--- +The Freshservice Integration allows you to push DefectDojo Findings and Finding Groups as Freshservice tickets, assigned to an agent Group of your choice. + +### Instance Setup + +- **Label** should be the label that you want to use to identify this integration. +- **Location** should be set to your Freshservice URL: `https://yourcompany.freshservice.com`. +- **API Key** should be a Freshservice API key. Find it by clicking your profile picture (top right) > **Profile settings** - the key appears on the right below the **Delegate Approvals** section, after you complete the captcha. If no key is shown there, API access may be disabled at the account level and an administrator has to enable it first. +- **Requester Email** should be the email address tickets are requested on behalf of. Freshservice requires a requester on every ticket, so DefectDojo creates tickets with this address as the requester. + +### Issue Tracker Mapping + +- **Group ID** should be the numeric ID of the Freshservice agent group tickets will be assigned to. Find it in the URL while viewing the group under **Admin > Agent Groups**. +- **Workspace ID** (optional) routes tickets to a specific workspace on multi-workspace accounts. Leave it empty to use the primary workspace. + +### Severity Mapping Details + +This maps to the Freshservice ticket **Priority** field, which uses numeric codes (`1` Low, `2` Medium, `3` High, `4` Urgent). The priority names are also accepted: + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `1` +- **Low Mapping**: `1` +- **Medium Mapping**: `2` +- **High Mapping**: `3` +- **Critical Mapping**: `4` + +### Status Mapping Details + +This maps to the ticket **Status** field, which uses numeric codes (`2` Open, `3` Pending, `4` Resolved, `5` Closed). The status names are also accepted: + +- **Status Field Name**: `Status` +- **Active Mapping**: `2` +- **Closed Mapping**: `5` +- **False Positive Mapping**: `5` +- **Risk Accepted Mapping**: `3` + +A few Freshservice-specific behaviors to be aware of: + +- Updates sync the full ticket content - Freshservice allows the subject and description to be edited after creation. +- Tickets are closed rather than deleted when a Finding is removed; tickets already Resolved or Closed are left untouched. A resolution note is attached automatically on closure, so accounts that require one (a common business rule) accept the close. +- Some accounts compute a ticket's priority from an Impact/Urgency matrix or a business rule and ignore the priority sent at creation. DefectDojo detects this and re-applies the mapped priority with a follow-up update, so the mapping still takes effect. diff --git a/docs/content/connectors/toolreference/gitguardian.de.md b/docs/content/connectors/toolreference/gitguardian.de.md new file mode 100644 index 00000000000..d1c5aecbaa4 --- /dev/null +++ b/docs/content/connectors/toolreference/gitguardian.de.md @@ -0,0 +1,23 @@ +--- +title: "GitGuardian" +description: "Einrichtung des GitGuardian Upstream-Connectors für DefectDojo" +weight: 62 +audience: pro +--- +Der GitGuardian-Connector verwendet die GitGuardian-REST-API, um **Secret-Incidents** zu importieren — von GitGuardian erkannte offengelegte Anmeldedaten in Ihren überwachten Quellen. DefectDojo erstellt für jede überwachte Quelle (Repository oder Perimeter) mit derzeit offenen Incidents einen Eintrag und importiert jeden offenen Incident als Befund. + +Zu Ihrer Sicherheit importiert der Connector nur Incident-**Metadaten** — den Detektor, den Schweregrad, die Gültigkeit, den Status und einen Link zurück zu GitGuardian. Der offengelegte Secret-Wert selbst wird von DefectDojo nie abgerufen oder gespeichert; folgen Sie dem Link in jedem Befund, um die betroffenen Stellen in GitGuardian zu prüfen. + +#### Voraussetzungen + +Sie benötigen einen GitGuardian-API-Schlüssel. Wir empfehlen ein **Service-Account-Token** (statt eines persönlichen Zugriffstokens), damit automatisierte Aktivitäten leicht zu unterscheiden sind. Erstellen Sie es unter **API** im GitGuardian-Dashboard und gewähren Sie diese Lese-Scopes: + +* `incidents:read` +* `sources:read` + +#### Connector-Zuordnungen + +1. Geben Sie Ihre GitGuardian-API-URL in das Feld **Location** ein: `https://api.gitguardian.com` für die SaaS-Plattform, oder die API-URL Ihrer selbstgehosteten Instanz. +2. Geben Sie den API-Schlüssel in das Feld **Secret** ein. + +Es werden nur **offene** Incidents (Status `TRIGGERED` oder `ASSIGNED`) importiert; Incidents, die Sie in GitGuardian beheben oder ignorieren, werden beim nächsten Sync automatisch in DefectDojo als behoben markiert. Ein bestätigt aktives Secret (Gültigkeit *valid*) wird als verifizierter Befund importiert. diff --git a/docs/content/connectors/toolreference/gitguardian.es.md b/docs/content/connectors/toolreference/gitguardian.es.md new file mode 100644 index 00000000000..409e3cc2b2d --- /dev/null +++ b/docs/content/connectors/toolreference/gitguardian.es.md @@ -0,0 +1,23 @@ +--- +title: "GitGuardian" +description: "Cómo configurar el Conector Upstream de GitGuardian para DefectDojo" +weight: 62 +audience: pro +--- +El conector de GitGuardian utiliza la API REST de GitGuardian para importar **incidentes de secretos**: credenciales expuestas que GitGuardian ha detectado en sus fuentes monitorizadas. DefectDojo crea un Registro para cada fuente monitorizada (repositorio o perímetro) que actualmente tenga incidentes abiertos, e importa cada incidente abierto como un hallazgo. + +Por su seguridad, el conector importa únicamente los **metadatos** del incidente: el detector, la severidad, la validez, el estado y un enlace de vuelta a GitGuardian. El propio valor del secreto expuesto nunca se recupera ni se almacena en DefectDojo; siga el enlace de cada hallazgo para revisar las ubicaciones afectadas en GitGuardian. + +#### Requisitos previos + +Necesitará una clave de API de GitGuardian. Recomendamos un **Service Account token** (en lugar de un personal access token) para que la actividad automatizada se distinga fácilmente. Créelo en **API** en el panel de GitGuardian y otorgue estos scopes de lectura: + +* `incidents:read` +* `sources:read` + +#### Asignaciones del conector + +1. Introduzca la URL de la API de GitGuardian en el campo **Location**: `https://api.gitguardian.com` para la plataforma SaaS, o la URL de la API de su instancia autoalojada. +2. Introduzca la clave de API en el campo **Secret**. + +Solo se importan los incidentes **open** (con estado `TRIGGERED` o `ASSIGNED`); los incidentes que resuelva o ignore en GitGuardian se mitigan automáticamente en DefectDojo en la siguiente sincronización. Un secreto confirmado como activo (validez *valid*) se importa como un hallazgo verificado. diff --git a/docs/content/connectors/toolreference/gitguardian.fr.md b/docs/content/connectors/toolreference/gitguardian.fr.md new file mode 100644 index 00000000000..75f28935112 --- /dev/null +++ b/docs/content/connectors/toolreference/gitguardian.fr.md @@ -0,0 +1,23 @@ +--- +title: "GitGuardian" +description: "Comment configurer le Connecteur Upstream GitGuardian pour DefectDojo" +weight: 62 +audience: pro +--- +Le connecteur GitGuardian utilise l'API REST GitGuardian pour importer des **incidents de secrets** — des identifiants exposés que GitGuardian a détectés sur l'ensemble de vos sources surveillées. DefectDojo crée un enregistrement pour chaque source surveillée (dépôt ou périmètre) ayant actuellement des incidents ouverts, et importe chaque incident ouvert sous forme de constatation. + +Pour votre sécurité, le connecteur n'importe que les **métadonnées** de l'incident — le détecteur, la sévérité, la validité, le statut, et un lien de retour vers GitGuardian. La valeur du secret exposé elle-même n'est jamais récupérée ni stockée par DefectDojo ; suivez le lien dans chaque constatation pour examiner les emplacements concernés dans GitGuardian. + +#### Prérequis + +Vous aurez besoin d'une clé d'API GitGuardian. Nous recommandons un **jeton de compte de service (Service Account token)** (plutôt qu'un jeton d'accès personnel) afin que l'activité automatisée soit facile à distinguer. Créez-le sous **API** dans le tableau de bord GitGuardian et accordez ces scopes en lecture : + +* `incidents:read` +* `sources:read` + +#### Mappages du connecteur + +1. Saisissez l'URL de l'API GitGuardian dans le champ **Location** : `https://api.gitguardian.com` pour la plateforme SaaS, ou l'URL de l'API de votre instance auto-hébergée. +2. Saisissez la clé d'API dans le champ **Secret**. + +Seuls les incidents à l'état **open** (statut `TRIGGERED` ou `ASSIGNED`) sont importés ; les incidents que vous résolvez ou ignorez dans GitGuardian sont automatiquement atténués dans DefectDojo lors de la prochaine synchronisation. Un secret confirmé actif (validité *valid*) est importé comme une constatation vérifiée. diff --git a/docs/content/connectors/toolreference/gitguardian.ja.md b/docs/content/connectors/toolreference/gitguardian.ja.md new file mode 100644 index 00000000000..9ffb2caf53c --- /dev/null +++ b/docs/content/connectors/toolreference/gitguardian.ja.md @@ -0,0 +1,23 @@ +--- +title: "GitGuardian" +description: "DefectDojo で GitGuardian の Upstream Connector をセットアップする方法" +weight: 62 +audience: pro +--- +GitGuardianコネクタは、GitGuardian REST APIを使用して**secret incident**（GitGuardianが監視対象のソース全体で検出した、漏えいした認証情報）をインポートします。DefectDojoは、現在オープンなincidentを持つ監視対象ソース（リポジトリまたはperimeter）ごとにレコードを作成し、オープンな各incidentを検出事項としてインポートします。 + +セキュリティ上の理由から、コネクタがインポートするのはincidentの**メタデータ**（detector、深刻度、validity、status、GitGuardianへのリンク）のみです。漏えいしたsecretの値そのものがDefectDojoによって取得・保存されることはありません。影響を受けた箇所を確認するには、各検出事項に含まれるリンクからGitGuardianを参照してください。 + +#### Prerequisites + +GitGuardianのAPIキーが必要です。自動化された操作を区別しやすくするため、個人アクセストークンではなく**Service Accountトークン**を使用することをお勧めします。GitGuardianダッシュボードの**API**でトークンを作成し、以下の読み取りスコープを付与してください。 + +* `incidents:read` +* `sources:read` + +#### Connector Mappings + +1. **Location**フィールドにGitGuardianのAPI URLを入力します。SaaSプラットフォームの場合は`https://api.gitguardian.com`、自己ホスト型インスタンスの場合はそのAPI URLを入力します。 +2. **Secret**フィールドにAPIキーを入力します。 + +インポートされるのは**open**なincident（statusが`TRIGGERED`または`ASSIGNED`のもの）のみです。GitGuardian側でresolveまたはignoreにしたincidentは、次回の同期時にDefectDojo側でも自動的に緩和済みになります。有効性が確認済みのsecret（validityが*valid*）は、検証済みの検出事項としてインポートされます。 diff --git a/docs/content/connectors/toolreference/gitguardian.md b/docs/content/connectors/toolreference/gitguardian.md new file mode 100644 index 00000000000..26e38a2d8d6 --- /dev/null +++ b/docs/content/connectors/toolreference/gitguardian.md @@ -0,0 +1,23 @@ +--- +title: "GitGuardian" +description: "How to set up the GitGuardian Upstream Connector for DefectDojo" +weight: 62 +audience: pro +--- +The GitGuardian connector uses the GitGuardian REST API to import **secret incidents** — exposed credentials GitGuardian has detected across your monitored sources. DefectDojo creates a Record for each monitored source (repository or perimeter) that currently has open incidents, and imports each open incident as a finding. + +For your security, the connector imports only incident **metadata** — the detector, severity, validity, status, and a link back to GitGuardian. The exposed secret value itself is never retrieved or stored by DefectDojo; follow the link in each finding to review the affected locations in GitGuardian. + +#### Prerequisites + +You will need a GitGuardian API key. We recommend a **Service Account token** (rather than a personal access token) so automated activity is easy to distinguish. Create it under **API** in the GitGuardian dashboard and grant these read scopes: + +* `incidents:read` +* `sources:read` + +#### Connector Mappings + +1. Enter your GitGuardian API URL in the **Location** field: `https://api.gitguardian.com` for the SaaS platform, or your self-hosted instance's API URL. +2. Enter the API key in the **Secret** field. + +Only **open** incidents (status `TRIGGERED` or `ASSIGNED`) are imported; incidents you resolve or ignore in GitGuardian are automatically mitigated in DefectDojo on the next sync. A confirmed-live secret (validity *valid*) is imported as a verified finding. diff --git a/docs/content/connectors/toolreference/github.de.md b/docs/content/connectors/toolreference/github.de.md new file mode 100644 index 00000000000..f9bfbb0ec54 --- /dev/null +++ b/docs/content/connectors/toolreference/github.de.md @@ -0,0 +1,72 @@ +--- +title: "GitHub" +description: "Einrichtung der Upstream- und Downstream-Connectors für GitHub" +weight: 63 +audience: pro +--- +## Upstream-Connector + +Der GitHub-Connector ist ein **Asset-Connector**: Er zählt die Repositories auf, auf die Ihr Token zugreifen kann, und erstellt für jedes ein DefectDojo-Asset, gruppiert in Organisationen nach GitHub-Owner (Organisation oder Benutzer). Es werden keine Befunde importiert. + +**Bitte beachten Sie:** Dieser Connector importiert nur Ihr Repository-**Inventar**. Um GitHub-Sicherheitswarnungen — Code Scanning, Dependabot und Secret Scanning — als Befunde zu importieren, verwenden Sie den separaten **GitHub-Advanced-Security**-Connector weiter unten. Beide sind unabhängig voneinander und können gemeinsam betrieben werden. + +#### Voraussetzungen + +Der Connector authentifiziert sich mit einem GitHub-**Personal Access Token** und liest nur Repository-**Metadaten** (Name, Beschreibung, URL und Owner) — er greift nicht auf Ihren Code, Ihre Issues oder Sicherheitswarnungen zu. Er importiert jedes Repository, das dem Konto des Tokens gehört, an dem es mitarbeitet oder dessen Organisation es angehört; stellen Sie daher sicher, dass das Konto des Tokens die zu spiegelnden Repositories sehen kann. Wir empfehlen ein dediziertes Service-Konto. + +Das Token benötigt nur lesenden Zugriff auf Repository-Metadaten: + +- Ein *fein-granulares* Token benötigt **Repository permissions → Metadata: Read-only**, gewährt für die zu importierenden Repositories (oder die gesamte Organisation). +- Ein *klassisches* Token benötigt den Scope **`repo`**, um private Repositories einzuschließen (verwenden Sie **`public_repo`**, wenn Sie nur öffentliche benötigen), sowie **`read:org`**, damit organisationseigene Repositories aufgelöst werden. + +Nur GitHub.com (einschließlich GitHub Enterprise Cloud) wird unterstützt. GitHub Enterprise **Server** wird von diesem Connector derzeit nicht unterstützt. + +#### Connector-Zuordnungen + +1. Geben Sie `https://api.github.com` in das Feld **Location** ein. +2. Geben Sie das Personal Access Token in das Feld **Secret** ein. + +Es muss keine Organisations- oder Repository-Liste eingegeben werden — DefectDojo importiert jedes Repository, das das Token sehen kann. Jedes Repository wird zu einem nach dem Repository benannten Eintrag, gruppiert nach seinem GitHub-**Owner** (Organisation oder Benutzer). Wird ein Repository später gelöscht oder verliert das Token den Zugriff darauf, wird sein zugeordneter Eintrag beim nächsten Sync als `MISSING` markiert statt entfernt — DefectDojo löscht niemals stillschweigend ein Produkt. + +## Downstream-Connector + +Die GitHub-Integration ermöglicht es Ihnen, Issues zu einem [GitHub Project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects) hinzuzufügen, wodurch außerdem Issues in einem zugehörigen Repo geöffnet werden. Diese Repos/Projects können entweder mit einer GitHub-Organisation oder mit einem persönlichen GitHub-Konto verknüpft sein. + +### Instanz-Einrichtung + +- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf die URL Ihres GitHub-Benutzers oder Ihrer GitHub-Organisation gesetzt werden, je nachdem, wo Sie Issues erstellen möchten, zum Beispiel `https://github.com/{your-organization}` +- **Token** sollte auf ein persönliches Zugriffstoken aus GitHub gesetzt werden. + +Persönliche Zugriffstoken für GitHub können unter https://github.com/settings/tokens erstellt werden. Das Token muss die Scopes „Repo“ und „Project“ besitzen. + +### Issue-Tracker-Zuordnung + +- **Issue Tracker Mapping Label** sollte so gesetzt werden, dass es das Project oder Repo identifiziert, in dem Sie Issues erstellen möchten. +- **Project Number** sollte die ID eines GitHub-Projects sein, an das Sie Elemente senden möchten. Sie finden sie in der URL, während Sie ein Project ansehen, zum Beispiel `https://github.com/orgs/{your-org}/projects/{project number}`. +- **Repository Name** sollte der Name eines Repos sein, das Ihrer Organisation (oder Ihrem Benutzer) zugeordnet ist und in das Sie Issues übertragen möchten. + + +### Details zur Schweregrad-Zuordnung + +**Damit die Integration eingerichtet werden kann, MUSS im Project ein benutzerdefiniertes Feld für die Issue-Priorität angelegt sein, andernfalls wird der Schweregrad nicht korrekt zugeordnet und Issues werden nicht an GitHub übertragen.** + +Folgen Sie dieser Anleitung, um ein [benutzerdefiniertes Feld](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/quickstart-for-projects#creating-a-field-to-track-priority) zu erstellen. +Für jeden Schweregrad muss eine entsprechende Single-Select-Option verfügbar sein. Standardmäßig schlägt DefectDojo zum Beispiel P0, P1, P2, P3, P4 als mögliche Prioritätswerte vor, und jeder dieser Werte muss dem benutzerdefinierten Feld „Priority“ hinzugefügt werden. + +- **Name des Schweregrad-Felds**: `Priority` +- **Info-Zuordnung**: `P0` +- **Niedrig-Zuordnung**: `P1` +- **Mittel-Zuordnung**: `P2` +- **Hoch-Zuordnung**: `P3` +- **Kritisch-Zuordnung**: `P4` + +### Details zur Status-Zuordnung + +Standardmäßig haben neue GitHub Projects für Issues die Status „In Progress“ und „Done“. Dem Project können weitere Status hinzugefügt werden, um bei Bedarf den Status Falsch-positiv oder Risiko akzeptiert nachzuverfolgen. Eine Möglichkeit dafür ist, dem Project-Board eine neue Statusspalte hinzuzufügen. + +- **Name des Status-Felds**: `Status` +- **Aktiv-Zuordnung**: `In Progress` +- **Geschlossen-Zuordnung**: `Done` +- **Falsch-positiv-Zuordnung**: `Done` +- **Risiko-akzeptiert-Zuordnung**: `Done` diff --git a/docs/content/connectors/toolreference/github.es.md b/docs/content/connectors/toolreference/github.es.md new file mode 100644 index 00000000000..88beff86134 --- /dev/null +++ b/docs/content/connectors/toolreference/github.es.md @@ -0,0 +1,72 @@ +--- +title: "GitHub" +description: "Configuración de los Conectores Upstream y Downstream de GitHub" +weight: 63 +audience: pro +--- +## Conector Upstream + +El conector de GitHub es un **Asset Connector**: enumera los repositorios a los que su token tiene acceso y crea un Activo de DefectDojo para cada uno, agrupados en Organizaciones según el propietario de GitHub (organización o usuario). No se importa ningún hallazgo. + +**Tenga en cuenta:** este conector importa únicamente el **inventario** de sus repositorios. Para importar las alertas de seguridad de GitHub (code scanning, Dependabot y secret scanning) como hallazgos, utilice el conector independiente **GitHub Advanced Security** que se describe más adelante. Ambos son independientes y pueden ejecutarse juntos. + +#### Requisitos previos + +El conector se autentica con un **personal access token** de GitHub y solo lee los **metadatos** del repositorio (nombre, descripción, URL y propietario); no accede a su código, incidencias ni alertas de seguridad. Importa todos los repositorios que la cuenta del token posee, en los que colabora, o de cuya organización es miembro, así que confirme que la cuenta del token puede ver los repositorios que desea reflejar. Recomendamos una cuenta de servicio dedicada. + +El token solo necesita acceso de solo lectura a los metadatos del repositorio: + +- Un token *fine-grained* necesita **Repository permissions → Metadata: Read-only**, otorgado a los repositorios (o a toda la organización) que desea importar. +- Un token *classic* necesita el scope **`repo`** para incluir repositorios privados (use **`public_repo`** si solo necesita los públicos), además de **`read:org`** para que se resuelvan los repositorios propiedad de la organización. + +Solo se admite GitHub.com (incluido GitHub Enterprise Cloud). GitHub Enterprise **Server** no está soportado actualmente por este conector. + +#### Asignaciones del conector + +1. Introduzca `https://api.github.com` en el campo **Location**. +2. Introduzca el personal access token en el campo **Secret**. + +No es necesario introducir ninguna lista de organizaciones ni de repositorios: DefectDojo importa todos los repositorios que el token puede ver. Cada repositorio se convierte en un Registro con el nombre del repositorio, agrupado por su **owner** de GitHub (organización o usuario). Si un repositorio se elimina más adelante, o el token pierde el acceso a él, su Registro asignado se marca como `MISSING` en la siguiente sincronización en lugar de eliminarse: DefectDojo nunca elimina un Producto de forma silenciosa. + +## Conector Downstream + +La integración de GitHub le permite añadir incidencias a un [GitHub Project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects), que también abre incidencias en un Repo asociado. Estos Repos/Proyectos pueden asociarse tanto a una organización de GitHub como a una cuenta personal de GitHub. + +### Configuración de la instancia + +- **Label** debe ser la etiqueta que desea usar para identificar esta integración. +- **Location** debe establecerse en la URL de su usuario u organización de GitHub, según dónde desee crear las incidencias. por ejemplo `https://github.com/{your-organization}` +- **Token** debe establecerse en un token de acceso personal de GitHub. + +Los tokens de acceso personal para GitHub pueden crearse en https://github.com/settings/tokens. El token debe tener los alcances (scopes) Repo y Project. + +### Mapeo del Issue Tracker + +- **Issue Tracker Mapping Label** debe establecerse para identificar el Proyecto o Repo en el que desea crear incidencias. +- **Project Number** debe ser el ID de un proyecto de GitHub al que desea enviar los elementos. Puede obtenerlo de la URL al ver un Proyecto, por ejemplo `https://github.com/orgs/{your-org}/projects/{project number}`. +- **Repository Name** debe ser el nombre de un repositorio asociado a su organización (o usuario) al que desea enviar las incidencias. + + +### Detalles del mapeo de severidad + +**Para configurar la integración, el proyecto DEBE tener un campo personalizado creado para representar la prioridad de la incidencia; de lo contrario, la severidad no se mapeará correctamente y las incidencias no se enviarán a GitHub.** + +Siga esta guía para crear un [campo personalizado](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/quickstart-for-projects#creating-a-field-to-track-priority). +Cada severidad necesitará tener una opción de selección única correspondiente disponible. Por ejemplo, de forma predeterminada DefectDojo sugiere P0, P1, P2, P3, P4 como posibles valores de Priority, y cada uno de ellos deberá añadirse al campo personalizado Priority. + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `P0` +- **Low Mapping**: `P1` +- **Medium Mapping**: `P2` +- **High Mapping**: `P3` +- **Critical Mapping**: `P4` + +### Detalles del mapeo de estado + +De forma predeterminada, los nuevos proyectos de GitHub tendrán estados para las incidencias de "In Progress" y "Done". Se pueden añadir estados adicionales al proyecto para rastrear el estado Falso positivo o Riesgo aceptado si lo desea. Una de las formas de hacerlo es añadiendo una nueva columna de estado al tablero del proyecto. + +- **Status Field Name**: `Status` +- **Active Mapping**: `In Progress` +- **Closed Mapping**: `Done` +- **False Positive Mapping**: `Done` +- **Risk Accepted Mapping**: `Done` diff --git a/docs/content/connectors/toolreference/github.fr.md b/docs/content/connectors/toolreference/github.fr.md new file mode 100644 index 00000000000..4e47d964bf3 --- /dev/null +++ b/docs/content/connectors/toolreference/github.fr.md @@ -0,0 +1,72 @@ +--- +title: "GitHub" +description: "Configuration des Connecteurs Upstream et Downstream pour GitHub" +weight: 63 +audience: pro +--- +## Connecteur Upstream + +Le connecteur GitHub est un **connecteur d'actifs (Asset Connector)** : il énumère les dépôts auxquels votre jeton a accès et crée un actif DefectDojo pour chacun, regroupés en organisations par propriétaire GitHub (organisation ou utilisateur). Aucune constatation n'est importée. + +**Remarque :** ce connecteur importe uniquement l'**inventaire** de vos dépôts. Pour importer les alertes de sécurité GitHub — code scanning, Dependabot et secret scanning — sous forme de constatations, utilisez le connecteur **GitHub Advanced Security** distinct décrit plus bas. Les deux sont indépendants et peuvent être exécutés ensemble. + +#### Prérequis + +Le connecteur s'authentifie avec un **jeton d'accès personnel** GitHub et ne lit que les **métadonnées** du dépôt (nom, description, URL et propriétaire) — il n'accède ni à votre code, ni à vos issues, ni à vos alertes de sécurité. Il importe chaque dépôt dont le compte du jeton est propriétaire, collaborateur, ou membre de l'organisation propriétaire ; vérifiez donc que le compte du jeton peut voir les dépôts que vous souhaitez refléter. Nous recommandons un compte de service dédié. + +Le jeton n'a besoin que d'un accès en lecture seule aux métadonnées du dépôt : + +- Un jeton *fine-grained* nécessite **Repository permissions → Metadata: Read-only**, accordé aux dépôts (ou à l'ensemble de l'organisation) que vous souhaitez importer. +- Un jeton *classic* nécessite le scope **`repo`** pour inclure les dépôts privés (utilisez **`public_repo`** si vous n'avez besoin que des dépôts publics), ainsi que **`read:org`** pour que les dépôts appartenant à une organisation soient résolus. + +Seul GitHub.com (y compris GitHub Enterprise Cloud) est pris en charge. GitHub Enterprise **Server** n'est pas pris en charge par ce connecteur pour le moment. + +#### Mappages du connecteur + +1. Saisissez `https://api.github.com` dans le champ **Location**. +2. Saisissez le jeton d'accès personnel dans le champ **Secret**. + +Aucune liste d'organisations ou de dépôts n'est à saisir — DefectDojo importe tous les dépôts que le jeton peut voir. Chaque dépôt devient un enregistrement nommé d'après le dépôt, regroupé par **owner** GitHub (organisation ou utilisateur). Si un dépôt est supprimé par la suite, ou si le jeton perd l'accès à celui-ci, son enregistrement associé est marqué `MISSING` lors de la prochaine synchronisation plutôt que supprimé — DefectDojo ne supprime jamais silencieusement un Produit. + +## Connecteur Downstream + +L'intégration GitHub vous permet d'ajouter des tickets à un [GitHub Project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects), ce qui ouvre également des tickets dans un dépôt (Repo) associé. Ces dépôts/projets peuvent être associés soit à une organisation GitHub, soit à un compte GitHub personnel. + +### Configuration de l'instance + +- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur l'URL de votre utilisateur ou organisation GitHub, selon l'endroit où vous souhaitez créer des tickets, par exemple `https://github.com/{your-organization}` +- **Token** doit être défini sur un jeton d'accès personnel GitHub. + +Les jetons d'accès personnels pour GitHub peuvent être créés à l'adresse https://github.com/settings/tokens. Le jeton doit disposer des portées Repo et Project. + +### Mappage du suivi des tickets + +- **Issue Tracker Mapping Label** doit être défini pour identifier le projet ou le dépôt dans lequel vous souhaitez créer des tickets. +- **Project Number** doit correspondre à l'ID du projet GitHub vers lequel vous souhaitez envoyer les éléments. Vous pouvez l'obtenir depuis l'URL affichée lorsque vous consultez un projet, par exemple `https://github.com/orgs/{your-org}/projects/{project number}`. +- **Repository Name** doit correspondre au nom d'un dépôt associé à votre organisation (ou utilisateur) vers lequel vous souhaitez transmettre des tickets. + + +### Détails du mappage de la sévérité + +**Pour configurer l'intégration, le projet DOIT disposer d'un champ personnalisé créé pour représenter la priorité des tickets ; sinon, la sévérité ne sera pas correctement mappée et les tickets ne seront pas transmis à GitHub.** + +Suivez ce guide pour créer un [champ personnalisé](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/quickstart-for-projects#creating-a-field-to-track-priority). +Chaque sévérité doit disposer d'une option à sélection unique correspondante. Par exemple, par défaut, DefectDojo propose P0, P1, P2, P3, P4 comme valeurs possibles de priorité, et chacune d'elles doit être ajoutée au champ personnalisé Priority. + +- **Severity Field Name** : `Priority` +- **Info Mapping** : `P0` +- **Low Mapping** : `P1` +- **Medium Mapping** : `P2` +- **High Mapping** : `P3` +- **Critical Mapping** : `P4` + +### Détails du mappage du statut + +Par défaut, les nouveaux projets GitHub disposent des statuts « In Progress » et « Done » pour les tickets. Des statuts supplémentaires peuvent être ajoutés au projet pour suivre les statuts Faux positif ou Risque accepté si vous le souhaitez. L'une des façons d'y parvenir consiste à ajouter une nouvelle colonne de statut au tableau du projet. + +- **Status Field Name** : `Status` +- **Active Mapping** : `In Progress` +- **Closed Mapping** : `Done` +- **False Positive Mapping** : `Done` +- **Risk Accepted Mapping** : `Done` diff --git a/docs/content/connectors/toolreference/github.ja.md b/docs/content/connectors/toolreference/github.ja.md new file mode 100644 index 00000000000..09baab15f69 --- /dev/null +++ b/docs/content/connectors/toolreference/github.ja.md @@ -0,0 +1,72 @@ +--- +title: "GitHub" +description: "GitHub の Upstream / ダウンストリームコネクタのセットアップ" +weight: 63 +audience: pro +--- +## アップストリームコネクタ + +GitHubコネクタは**アセットコネクタ**です。トークンがアクセスできるリポジトリを列挙し、それぞれについてDefectDojoのアセットを作成します。作成されたアセットは、GitHubのowner（組織またはユーザー）ごとにOrganizationsにグループ化されます。検出事項はインポートされません。 + +**Please note:** このコネクタがインポートするのはリポジトリの**インベントリ**のみです。GitHubのセキュリティアラート（code scanning、Dependabot、secret scanning）を検出事項としてインポートするには、以下の別途用意された**GitHub Advanced Security**コネクタを使用してください。この2つは互いに独立しており、併用することもできます。 + +#### Prerequisites + +コネクタはGitHubの**個人アクセストークン**で認証を行い、リポジトリの**メタデータ**（名前、説明、URL、owner）のみを読み取ります。コードやissue、セキュリティアラートにはアクセスしません。トークンのアカウントが所有・コラボレーション・組織メンバーとして参加しているすべてのリポジトリがインポートされるため、ミラーしたいリポジトリをそのアカウントが参照できることを確認してください。専用のサービスアカウントを使用することをお勧めします。 + +トークンに必要なのは、リポジトリメタデータへの読み取り専用アクセスのみです。 + +- *fine-grained*トークンの場合、インポート対象のリポジトリ（または組織全体）に対して**Repository permissions → Metadata: Read-only**の権限が必要です。 +- *classic*トークンの場合、プライベートリポジトリを含めるには**`repo`**スコープが必要です（パブリックリポジトリのみでよい場合は**`public_repo`**を使用してください）。加えて、組織所有のリポジトリを解決するために**`read:org`**も必要です。 + +サポートされるのはGitHub.com（GitHub Enterprise Cloudを含む）のみです。GitHub Enterprise **Server**は現時点でこのコネクタではサポートされていません。 + +#### Connector Mappings + +1. **Location**フィールドに`https://api.github.com`を入力します。 +2. **Secret**フィールドに個人アクセストークンを入力します。 + +組織やリポジトリのリストを入力する必要はありません。DefectDojoは、トークンが参照できるすべてのリポジトリをインポートします。各リポジトリはそのリポジトリ名にちなんだレコードとなり、GitHubの**owner**（組織またはユーザー）ごとにグループ化されます。リポジトリが後で削除されたり、トークンがそのアクセス権を失ったりした場合、対応するレコードは削除されるのではなく、次回の同期時に`MISSING`としてフラグが付けられます。DefectDojoが製品を黙って削除することはありません。 + +## ダウンストリームコネクタ + +GitHub 統合を使うと、[GitHub Project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects)に Issue を追加でき、これにより関連付けられた Repo にも Issue が作成されます。これらの Repo/Project は、GitHub Organization または個人の GitHub アカウントのいずれにも関連付けることができます。 + +### Instance Setup + +- **Label** は、この統合を識別するために使用したいラベルを設定します。 +- **Location** は、Issue を作成したい場所に応じて、GitHub のユーザーまたは Organization の URL を設定します。例: `https://github.com/{your-organization}` +- **Token** は、GitHub のパーソナルアクセストークンを設定します。 + +GitHub のパーソナルアクセストークンは https://github.com/settings/tokens で作成できます。トークンには Repo と Project のスコープが必要です。 + +### Issue Tracker Mapping + +- **Issue Tracker Mapping Label** は、Issue を作成したい Project または Repo を識別できるように設定します。 +- **Project Number** は、Issue を送信したい GitHub Project の ID を設定します。この値は、Project を表示中の URL から取得できます。例: `https://github.com/orgs/{your-org}/projects/{project number}` +- **Repository Name** は、Issue をプッシュしたい、Organization（またはユーザー）に紐づくリポジトリの名前を設定します。 + + +### Severity Mapping Details + +**この統合を設定するには、Project 側で Issue の優先度を表すカスタムフィールドを作成しておく必要があります。作成していない場合、深刻度が正しくマッピングされず、Issue が GitHub にプッシュされません。** + +以下のガイドに従って[カスタムフィールド](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/quickstart-for-projects#creating-a-field-to-track-priority)を作成してください。 +各深刻度には、対応する単一選択のオプションを用意する必要があります。例えば、DefectDojo は初期状態で Priority の値として P0、P1、P2、P3、P4 を提案しており、それぞれを Priority カスタムフィールドに追加する必要があります。 + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `P0` +- **Low Mapping**: `P1` +- **Medium Mapping**: `P2` +- **High Mapping**: `P3` +- **Critical Mapping**: `P4` + +### Status Mapping Details + +デフォルトでは、新規作成した GitHub Project には Issue のステータスとして「In Progress」と「Done」が用意されています。誤検知やリスク受容済みのステータスを追跡したい場合は、Project に追加のステータスを設定することもできます。その方法の一つが、Project Board に新しいステータス列を追加する方法です。 + +- **Status Field Name**: `Status` +- **Active Mapping**: `In Progress` +- **Closed Mapping**: `Done` +- **False Positive Mapping**: `Done` +- **Risk Accepted Mapping**: `Done` diff --git a/docs/content/connectors/toolreference/github.md b/docs/content/connectors/toolreference/github.md new file mode 100644 index 00000000000..457879a7029 --- /dev/null +++ b/docs/content/connectors/toolreference/github.md @@ -0,0 +1,72 @@ +--- +title: "GitHub" +description: "Upstream and Downstream Connector setup for GitHub" +weight: 63 +audience: pro +--- +## Upstream Connector + +The GitHub connector is an **Asset Connector**: it enumerates the repositories your token can access and creates a DefectDojo Asset for each one, grouped into Organizations by GitHub owner (organization or user). No findings are imported. + +**Please note:** this connector imports your repository **inventory** only. To import GitHub security alerts — code scanning, Dependabot, and secret scanning — as findings, use the separate [GitHub Advanced Security](/connectors/toolreference/github_advanced_security/) connector. The two are independent and can be run together. + +#### Prerequisites + +The connector authenticates with a GitHub **personal access token** and reads only repository **metadata** (name, description, URL, and owner) — it does not access your code, issues, or security alerts. It imports every repository the token's account owns, collaborates on, or is an organization member of, so confirm the token's account can see the repositories you want to mirror. We recommend a dedicated service account. + +The token only needs read-only access to repository metadata: + +- A *fine-grained* token needs **Repository permissions → Metadata: Read-only**, granted to the repositories (or the whole organization) you want to import. +- A *classic* token needs the **`repo`** scope to include private repositories (use **`public_repo`** if you only need public ones), plus **`read:org`** so organization-owned repositories resolve. + +Only GitHub.com (including GitHub Enterprise Cloud) is supported. GitHub Enterprise **Server** is not supported by this connector at this time. + +#### Connector Mappings + +1. Enter `https://api.github.com` in the **Location** field. +2. Enter the personal access token in the **Secret** field. + +No organization or repository list needs to be entered — DefectDojo imports every repository the token can see. Each repository becomes a Record named after the repository, grouped by its GitHub **owner** (organization or user). If a repository is later deleted, or the token loses access to it, its mapped Record is flagged `MISSING` on the next Sync rather than removed — DefectDojo never silently deletes an Asset. + +## Downstream Connector + +The GitHub integration allows you to add issues to a [GitHub Project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects), which also open Issues in an associated Repo. These Repos/Projects can be associated with either a GitHub Organization or a personal GitHub account. + +### Instance Setup + +- **Label** should be the label that you want to use to identify this integration. +- **Location** should be set to your GitHub User or Organization URL, depending on where you wish to create issues. for example `https://github.com/{your-organization}` +- **Token** should be set to a personal access token from GitHub. + +Personal access tokens for GitHub can be created at https://github.com/settings/tokens. The token must have Repo and Project scopes. + +### Issue Tracker Mapping + +- **Issue Tracker Mapping Label** should be set to identify the Project or Repo that you wish to create Issues in. +- **Project Number** should be the ID of a GitHub project that you want to send items to. You can get this from the URL while looking at a Project, for example `https://github.com/orgs/{your-org}/projects/{project number}`. +- **Repository Name** should be the name of a repo associated with your organization (or user) that you want to push Issues to. + + +### Severity Mapping Details + +**In order to set up the integration, the Project MUST have a custom field created to represent Issue Priority, otherwise Severity will not be mapped correctly and Issues will not push to GitHub.** + +Follow this guide to create a [custom field](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/quickstart-for-projects#creating-a-field-to-track-priority). +Each Severity will need to have a corresponding single-select option available. For example, out of the box DefectDojo suggests P0, P1, P2, P3, P4 as possible Priority values, and each of those will need to be added to the Priority custom field. + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `P0` +- **Low Mapping**: `P1` +- **Medium Mapping**: `P2` +- **High Mapping**: `P3` +- **Critical Mapping**: `P4` + +### Status Mapping Details + +By default, new GitHub Projects will have Statuses for Issues of "In Progress" and "Done". Additional statuses can be added to the Project to track False Positive or Risk Accepted status if you wish. One of the ways this can be done is by adding a new Status Column to the Project Board. + +- **Status Field Name**: `Status` +- **Active Mapping**: `In Progress` +- **Closed Mapping**: `Done` +- **False Positive Mapping**: `Done` +- **Risk Accepted Mapping**: `Done` diff --git a/docs/content/connectors/toolreference/github_advanced_security.de.md b/docs/content/connectors/toolreference/github_advanced_security.de.md new file mode 100644 index 00000000000..f34abce264c --- /dev/null +++ b/docs/content/connectors/toolreference/github_advanced_security.de.md @@ -0,0 +1,24 @@ +--- +title: "GitHub Advanced Security" +description: "Einrichtung des GitHub Advanced Security Upstream-Connectors für DefectDojo" +weight: 64 +audience: pro +--- +Der GitHub-Advanced-Security-Connector importiert **Code-Scanning-**, **Dependabot-** und **Secret-Scanning**-Warnungen von GitHub als drei separate Befundtypen (`GitHub:CodeScanning`, `GitHub:Dependabot` und `GitHub:SecretScanning`). DefectDojo ermittelt jedes nicht archivierte Repository in der konfigurierten Organisation und erstellt für jedes einen Eintrag. + +#### Voraussetzungen + +GitHub-Advanced-Security-Funktionen müssen für die zu importierenden Repositories aktiviert sein. Der Connector authentifiziert sich mit einem GitHub-**Personal Access Token**: + +1. Öffnen Sie in GitHub **Settings \> Developer settings \> Personal access tokens** und erstellen Sie ein Token, das der Zielorganisation gehört (oder Zugriff darauf hat). +2. Gewähren Sie ihm Lesezugriff auf die Sicherheitswarnungen: Ein *fein-granulares* Token benötigt **Read-only**-Zugriff auf **Code scanning alerts**, **Dependabot alerts** und **Secret scanning alerts** der Repositories der Organisation; ein *klassisches* Token benötigt die Scopes **`repo`** und **`security_events`**. +3. Stellen Sie sicher, dass der Owner des Tokens die zu importierenden Repositories sehen kann — der Connector sieht nur Repositories, auf die das Token zugreifen kann. + +#### Connector-Zuordnungen + +1. Geben Sie `https://api.github.com` in das Feld **Location** ein. Verwenden Sie für GitHub Enterprise Server `https:///api/v3`. +2. Geben Sie den Organisations-Login in das Feld **Organization** ein. +3. Geben Sie das Personal Access Token in das Feld **Secret** ein. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jedes nicht archivierte Repository wird zu einem Eintrag, der über die drei Warnungsfamilien nach offenen Warnungen abgefragt wird. Eine Warnungsfamilie, die für ein Repository nicht aktiviert ist, wird übersprungen statt als behoben gemeldet, sodass deaktivierte Funktionen keine falschen Schließungen verursachen. diff --git a/docs/content/connectors/toolreference/github_advanced_security.es.md b/docs/content/connectors/toolreference/github_advanced_security.es.md new file mode 100644 index 00000000000..8f0c4d8182e --- /dev/null +++ b/docs/content/connectors/toolreference/github_advanced_security.es.md @@ -0,0 +1,24 @@ +--- +title: "GitHub Advanced Security" +description: "Cómo configurar el Conector Upstream de GitHub Advanced Security para DefectDojo" +weight: 64 +audience: pro +--- +El conector de GitHub Advanced Security importa alertas de **code scanning**, **Dependabot** y **secret scanning** de GitHub, como tres tipos de hallazgo independientes (`GitHub:CodeScanning`, `GitHub:Dependabot` y `GitHub:SecretScanning`). DefectDojo detecta todos los repositorios no archivados de la organización configurada y crea un Registro para cada uno. + +#### Requisitos previos + +Las funciones de GitHub Advanced Security deben estar habilitadas en los repositorios que desea importar. El conector se autentica con un **personal access token** de GitHub: + +1. En GitHub, abra **Settings \> Developer settings \> Personal access tokens** y cree un token propiedad de (o con acceso a) la organización de destino. +2. Otórguele acceso de lectura a las alertas de seguridad: un token *fine\-grained* necesita acceso **Read\-only** a **Code scanning alerts**, **Dependabot alerts** y **Secret scanning alerts** en los repositorios de la organización; un token *classic* necesita los scopes **`repo`** y **`security_events`**. +3. Confirme que el propietario del token puede ver los repositorios que pretende importar: el conector solo ve los repositorios a los que el token tiene acceso. + +#### Asignaciones del conector + +1. Introduzca `https://api.github.com` en el campo **Location**. Para GitHub Enterprise Server, utilice `https:///api/v3`. +2. Introduzca el login de la organización en el campo **Organization**. +3. Introduzca el personal access token en el campo **Secret**. +4. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada repositorio no archivado se convierte en un Registro, consultado en las tres familias de alertas en busca de alertas abiertas. Una familia de alertas que no esté habilitada para un repositorio se omite en lugar de reportarse como resuelta, de modo que las funciones deshabilitadas no provocan cierres falsos. diff --git a/docs/content/connectors/toolreference/github_advanced_security.fr.md b/docs/content/connectors/toolreference/github_advanced_security.fr.md new file mode 100644 index 00000000000..15003439bdf --- /dev/null +++ b/docs/content/connectors/toolreference/github_advanced_security.fr.md @@ -0,0 +1,24 @@ +--- +title: "GitHub Advanced Security" +description: "Comment configurer le Connecteur Upstream GitHub Advanced Security pour DefectDojo" +weight: 64 +audience: pro +--- +Le connecteur GitHub Advanced Security importe les alertes **code scanning**, **Dependabot** et **secret scanning** de GitHub, sous forme de trois types de constatations distincts (`GitHub:CodeScanning`, `GitHub:Dependabot` et `GitHub:SecretScanning`). DefectDojo découvre chaque dépôt non archivé de l'organisation configurée et crée un enregistrement pour chacun. + +#### Prérequis + +Les fonctionnalités GitHub Advanced Security doivent être activées pour les dépôts que vous souhaitez importer. Le connecteur s'authentifie avec un **jeton d'accès personnel** GitHub : + +1. Dans GitHub, ouvrez **Settings \> Developer settings \> Personal access tokens** et créez un jeton appartenant à (ou ayant accès à) l'organisation cible. +2. Accordez-lui un accès en lecture aux alertes de sécurité : un jeton *fine\-grained* nécessite un accès **Read\-only** à **Code scanning alerts**, **Dependabot alerts** et **Secret scanning alerts** sur les dépôts de l'organisation ; un jeton *classic* nécessite les scopes **`repo`** et **`security_events`**. +3. Vérifiez que le propriétaire du jeton peut voir les dépôts que vous prévoyez d'importer — le connecteur ne voit que les dépôts auxquels le jeton a accès. + +#### Mappages du connecteur + +1. Saisissez `https://api.github.com` dans le champ **Location**. Pour GitHub Enterprise Server, utilisez `https:///api/v3`. +2. Saisissez le login de l'organisation dans le champ **Organization**. +3. Saisissez le jeton d'accès personnel dans le champ **Secret**. +4. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque dépôt non archivé devient un enregistrement, interrogé sur les trois familles d'alertes pour les alertes ouvertes. Une famille d'alertes non activée pour un dépôt est ignorée plutôt que signalée comme résolue, de sorte que les fonctionnalités désactivées ne provoquent pas de fermetures erronées. diff --git a/docs/content/connectors/toolreference/github_advanced_security.ja.md b/docs/content/connectors/toolreference/github_advanced_security.ja.md new file mode 100644 index 00000000000..2ac654335b2 --- /dev/null +++ b/docs/content/connectors/toolreference/github_advanced_security.ja.md @@ -0,0 +1,24 @@ +--- +title: "GitHub Advanced Security" +description: "DefectDojo で GitHub Advanced Security の Upstream Connector をセットアップする方法" +weight: 64 +audience: pro +--- +GitHub Advanced Securityコネクタは、GitHubから**code scanning**、**Dependabot**、**secret scanning**のアラートを、3つの独立した検出事項タイプ（`GitHub:CodeScanning`、`GitHub:Dependabot`、`GitHub:SecretScanning`）としてインポートします。DefectDojoは、設定した組織内のアーカイブされていないすべてのリポジトリを検出し、それぞれについてレコードを作成します。 + +#### Prerequisites + +インポートしたいリポジトリでは、GitHub Advanced Security機能が有効になっている必要があります。コネクタはGitHubの**個人アクセストークン**で認証を行います。 + +1. GitHubで**Settings > Developer settings > Personal access tokens**を開き、対象の組織が所有する（またはアクセス権を持つ）トークンを作成します。 +2. セキュリティアラートへの読み取りアクセス権を付与します。*fine-grained*トークンの場合、組織のリポジトリに対して**Code scanning alerts**、**Dependabot alerts**、**Secret scanning alerts**への**Read-only**アクセスが必要です。*classic*トークンの場合は**`repo`**と**`security_events`**のスコープが必要です。 +3. トークンのownerがインポート対象のリポジトリを参照できることを確認してください。コネクタは、トークンがアクセスできるリポジトリしか参照できません。 + +#### Connector Mappings + +1. **Location**フィールドに`https://api.github.com`を入力します。GitHub Enterprise Serverの場合は`https:///api/v3`を使用してください。 +2. **Organization**フィールドに組織のログイン名を入力します。 +3. **Secret**フィールドに個人アクセストークンを入力します。 +4. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 + +アーカイブされていない各リポジトリはレコードとなり、3種類のアラートファミリーそれぞれについてオープンなアラートが照会されます。あるリポジトリで特定のアラートファミリーが有効になっていない場合、それはresolvedとして報告されるのではなくスキップされるため、無効化された機能によって誤ってクローズされることはありません。 diff --git a/docs/content/connectors/toolreference/github_advanced_security.md b/docs/content/connectors/toolreference/github_advanced_security.md new file mode 100644 index 00000000000..955b1b1b867 --- /dev/null +++ b/docs/content/connectors/toolreference/github_advanced_security.md @@ -0,0 +1,24 @@ +--- +title: "GitHub Advanced Security" +description: "How to set up the GitHub Advanced Security Upstream Connector for DefectDojo" +weight: 64 +audience: pro +--- +The GitHub Advanced Security connector imports **code scanning**, **Dependabot**, and **secret scanning** alerts from GitHub, as three separate finding types (`GitHub:CodeScanning`, `GitHub:Dependabot`, and `GitHub:SecretScanning`). DefectDojo discovers every non\-archived repository in the configured organization and creates a Record for each one. + +#### Prerequisites + +GitHub Advanced Security features must be enabled for the repositories you want to import. The connector authenticates with a GitHub **personal access token**: + +1. In GitHub, open **Settings \> Developer settings \> Personal access tokens** and create a token owned by (or with access to) the target organization. +2. Grant it read access to the security alerts: a *fine\-grained* token needs **Read\-only** access to **Code scanning alerts**, **Dependabot alerts**, and **Secret scanning alerts** on the organization's repositories; a *classic* token needs the **`repo`** and **`security_events`** scopes. +3. Confirm the token's owner can see the repositories you intend to import — the connector only sees repositories the token can access. + +#### Connector Mappings + +1. Enter `https://api.github.com` in the **Location** field. For GitHub Enterprise Server, use `https:///api/v3`. +2. Enter the organization login in the **Organization** field. +3. Enter the personal access token in the **Secret** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each non\-archived repository becomes a Record, queried across the three alert families for open alerts. An alert family that is not enabled for a repository is skipped rather than reported as resolved, so disabled features do not cause false closures. diff --git a/docs/content/connectors/toolreference/gitlab.de.md b/docs/content/connectors/toolreference/gitlab.de.md new file mode 100644 index 00000000000..ca457cfb981 --- /dev/null +++ b/docs/content/connectors/toolreference/gitlab.de.md @@ -0,0 +1,54 @@ +--- +title: "GitLab" +description: "Einrichtung der Upstream- und Downstream-Connectors für GitLab" +weight: 65 +audience: pro +--- +## Upstream-Connector + +Der GitLab-Connector ist ein **Asset-Connector**: Er zählt jedes Projekt (Repository) auf, auf das Ihr Token zugreifen kann, und erstellt für jedes ein DefectDojo-Asset, gruppiert in Organisationen nach GitLab-Namespace (Gruppe oder Benutzer). Es werden keine Befunde importiert. + +#### Voraussetzungen + +Sie benötigen ein Personal Access Token mit dem Scope **read_api**. Wir empfehlen, das Token von einem dedizierten Service-Konto aus zu erstellen; der Connector listet die Projekte auf, in denen dieses Konto Mitglied ist. + +#### Connector-Zuordnungen + +1. Geben Sie Ihre GitLab-URL in das Feld **Location** ein: `https://gitlab.com`, oder die Basis-URL Ihrer selbstgehosteten Instanz. +2. Geben Sie das Personal Access Token in das Feld **Secret** ein. + +Jedes Projekt wird zu einem nach dem Projekt benannten Eintrag, gruppiert nach seinem **Namespace**. Projekte, die in GitLab zur Löschung vorgesehen sind (von einem Benutzer gelöscht, aber noch nicht durch den Hintergrundjob von GitLab endgültig entfernt), werden automatisch ausgeschlossen; das Löschen eines Projekts markiert seinen Eintrag daher beim nächsten Sync als `MISSING`, statt ein umbenanntes Geister-Asset zu hinterlassen. + +## Downstream-Connector + +Die GitLab-Integration ermöglicht es Ihnen, Issues zu einem [GitLab-Projekt](https://docs.gitlab.com/ee/user/project/) hinzuzufügen. + +### Instanz-Einrichtung + +- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf den Link zu Ihrem GitLab-Server gesetzt werden, zum Beispiel `https://gitlab.com/`. +- **Token** sollte auf ein persönliches Zugriffstoken aus GitLab gesetzt werden. Das Token muss API-Scopes besitzen. Siehe [GitLabs Anleitung zum Erstellen eines persönlichen Zugriffstokens](https://docs.gitlab.com/user/profile/personal_access_tokens/#create-a-personal-access-token). + +### Issue-Tracker-Zuordnung + +- **Project Name**: Der Name des Projekts in GitLab, an das Sie Issues senden möchten. + +### Details zur Schweregrad-Zuordnung + +Dies wird dem GitLab-Feld „Priority“ zugeordnet. +- **Name des Schweregrad-Felds**: `Priority` +- **Info-Zuordnung**: `1` +- **Niedrig-Zuordnung**: `2` +- **Mittel-Zuordnung**: `3` +- **Hoch-Zuordnung**: `4` +- **Kritisch-Zuordnung**: `5` + +### Details zur Status-Zuordnung + +Standardmäßig kennt GitLab die Status „opened“ und „closed“. Zusätzliche Status-Labels können hinzugefügt werden, wenn Sie den Status Falsch-positiv oder Risiko akzeptiert nachverfolgen möchten. Details finden Sie in den [GitLab-Docs](https://docs.gitlab.com/user/work_items/status/). + +- **Name des Status-Felds**: `Status` +- **Aktiv-Zuordnung**: `opened` +- **Geschlossen-Zuordnung**: `closed` +- **Falsch-positiv-Zuordnung**: `closed` +- **Risiko-akzeptiert-Zuordnung**: `closed` diff --git a/docs/content/connectors/toolreference/gitlab.es.md b/docs/content/connectors/toolreference/gitlab.es.md new file mode 100644 index 00000000000..e7fda6a7fb3 --- /dev/null +++ b/docs/content/connectors/toolreference/gitlab.es.md @@ -0,0 +1,54 @@ +--- +title: "GitLab" +description: "Configuración de los Conectores Upstream y Downstream de GitLab" +weight: 65 +audience: pro +--- +## Conector Upstream + +El conector de GitLab es un **Asset Connector**: enumera todos los proyectos (repositorios) a los que su token tiene acceso y crea un Activo de DefectDojo para cada uno, agrupados en Organizaciones según el namespace de GitLab (grupo o usuario). No se importa ningún hallazgo. + +#### Requisitos previos + +Necesitará un Personal Access Token con el scope **read_api**. Recomendamos crear el token desde una cuenta de servicio dedicada; el conector enumera los proyectos de los que esa cuenta es miembro. + +#### Asignaciones del conector + +1. Introduzca su URL de GitLab en el campo **Location**: `https://gitlab.com`, o la URL base de su instancia autoalojada. +2. Introduzca el Personal Access Token en el campo **Secret**. + +Cada proyecto se convierte en un Registro con el nombre del proyecto, agrupado por su **namespace**. Los proyectos pendientes de eliminación en GitLab (eliminados por un usuario, pero aún no purgados por el trabajo en segundo plano de GitLab) se excluyen automáticamente, de modo que eliminar un proyecto marca su Registro como `MISSING` en la siguiente sincronización en lugar de dejar un activo fantasma renombrado. + +## Conector Downstream + +La integración de GitLab le permite añadir incidencias a un [Proyecto de GitLab](https://docs.gitlab.com/ee/user/project/). + +### Configuración de la instancia + +- **Label** debe ser la etiqueta que desea usar para identificar esta integración. +- **Location** debe establecerse en el enlace de su servidor de GitLab, por ejemplo `https://gitlab.com/`. +- **Token** debe establecerse en un token de acceso personal de GitLab. El token debe tener alcances de API. Consulte la [guía de GitLab para crear un token de acceso personal](https://docs.gitlab.com/user/profile/personal_access_tokens/#create-a-personal-access-token). + +### Mapeo del Issue Tracker + +- **Project Name**: el nombre del proyecto en GitLab al que desea enviar incidencias. + +### Detalles del mapeo de severidad + +Esto se mapea al campo Priority de GitLab. +- **Severity Field Name**: `Priority` +- **Info Mapping**: `1` +- **Low Mapping**: `2` +- **Medium Mapping**: `3` +- **High Mapping**: `4` +- **Critical Mapping**: `5` + +### Detalles del mapeo de estado + +De forma predeterminada, GitLab tiene los estados 'opened' y 'closed'. Se pueden añadir etiquetas de estado adicionales si desea rastrear el estado Falso positivo o Riesgo aceptado. Consulte la [documentación de GitLab](https://docs.gitlab.com/user/work_items/status/) para más detalles. + +- **Status Field Name**: `Status` +- **Active Mapping**: `opened` +- **Closed Mapping**: `closed` +- **False Positive Mapping**: `closed` +- **Risk Accepted Mapping**: `closed` diff --git a/docs/content/connectors/toolreference/gitlab.fr.md b/docs/content/connectors/toolreference/gitlab.fr.md new file mode 100644 index 00000000000..b8acba1c04d --- /dev/null +++ b/docs/content/connectors/toolreference/gitlab.fr.md @@ -0,0 +1,54 @@ +--- +title: "GitLab" +description: "Configuration des Connecteurs Upstream et Downstream pour GitLab" +weight: 65 +audience: pro +--- +## Connecteur Upstream + +Le connecteur GitLab est un **connecteur d'actifs (Asset Connector)** : il énumère chaque projet (dépôt) auquel votre jeton a accès et crée un actif DefectDojo pour chacun, regroupés en organisations par espace de noms (namespace) GitLab (groupe ou utilisateur). Aucune constatation n'est importée. + +#### Prérequis + +Vous aurez besoin d'un jeton d'accès personnel (Personal Access Token) avec le scope **read_api**. Nous recommandons de créer le jeton depuis un compte de service dédié ; le connecteur liste les projets dont ce compte est membre. + +#### Mappages du connecteur + +1. Saisissez votre URL GitLab dans le champ **Location** : `https://gitlab.com`, ou l'URL de base de votre instance auto-hébergée. +2. Saisissez le Personal Access Token dans le champ **Secret**. + +Chaque projet devient un enregistrement nommé d'après le projet, regroupé par son **namespace**. Les projets en attente de suppression dans GitLab (supprimés par un utilisateur, mais pas encore purgés par la tâche de fond de GitLab) sont exclus automatiquement ; la suppression d'un projet marque donc son enregistrement comme `MISSING` lors de la prochaine synchronisation, au lieu de laisser un actif fantôme renommé. + +## Connecteur Downstream + +L'intégration GitLab vous permet d'ajouter des tickets à un [projet GitLab](https://docs.gitlab.com/ee/user/project/). + +### Configuration de l'instance + +- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur le lien de votre serveur GitLab, par exemple `https://gitlab.com/`. +- **Token** doit être défini sur un jeton d'accès personnel GitLab. Le jeton doit disposer des portées API. Consultez le [guide GitLab pour créer un jeton d'accès personnel](https://docs.gitlab.com/user/profile/personal_access_tokens/#create-a-personal-access-token). + +### Mappage du suivi des tickets + +- **Project Name** : le nom du projet dans GitLab vers lequel vous souhaitez envoyer les tickets. + +### Détails du mappage de la sévérité + +Ceci correspond au champ Priority de GitLab. +- **Severity Field Name** : `Priority` +- **Info Mapping** : `1` +- **Low Mapping** : `2` +- **Medium Mapping** : `3` +- **High Mapping** : `4` +- **Critical Mapping** : `5` + +### Détails du mappage du statut + +Par défaut, GitLab dispose des statuts « opened » et « closed ». Des étiquettes de statut supplémentaires peuvent être ajoutées si vous souhaitez suivre les statuts Faux positif ou Risque accepté. Consultez la [documentation GitLab](https://docs.gitlab.com/user/work_items/status/) pour plus de détails. + +- **Status Field Name** : `Status` +- **Active Mapping** : `opened` +- **Closed Mapping** : `closed` +- **False Positive Mapping** : `closed` +- **Risk Accepted Mapping** : `closed` diff --git a/docs/content/connectors/toolreference/gitlab.ja.md b/docs/content/connectors/toolreference/gitlab.ja.md new file mode 100644 index 00000000000..0ca518c1407 --- /dev/null +++ b/docs/content/connectors/toolreference/gitlab.ja.md @@ -0,0 +1,54 @@ +--- +title: "GitLab" +description: "GitLab の Upstream / ダウンストリームコネクタのセットアップ" +weight: 65 +audience: pro +--- +## アップストリームコネクタ + +GitLabコネクタは**アセットコネクタ**です。トークンがアクセスできるすべてのproject（リポジトリ）を列挙し、それぞれについてDefectDojoのアセットを作成します。作成されたアセットは、GitLabのnamespace（グループまたはユーザー）ごとにOrganizationsにグループ化されます。検出事項はインポートされません。 + +#### Prerequisites + +**read_api**スコープを持つPersonal Access Tokenが必要です。専用のサービスアカウントからトークンを作成することをお勧めします。コネクタは、そのアカウントがメンバーになっているprojectを一覧表示します。 + +#### Connector Mappings + +1. **Location**フィールドにGitLabのURLを入力します: `https://gitlab.com`、または自己ホスト型インスタンスのベースURL。 +2. **Secret**フィールドにPersonal Access Tokenを入力します。 + +各projectはそのproject名にちなんだレコードとなり、**namespace**ごとにグループ化されます。GitLab上で削除待ち状態のproject（ユーザーによって削除されたが、GitLabのバックグラウンドジョブによってまだ完全に削除されていないもの）は自動的に除外されます。そのため、projectを削除すると、名前が変更された幽霊のようなアセットが残るのではなく、次回の同期時に対応するレコードが`MISSING`としてフラグ付けされます。 + +## ダウンストリームコネクタ + +GitLab 統合を使うと、[GitLab Project](https://docs.gitlab.com/ee/user/project/)に Issue を追加できます。 + +### Instance Setup + +- **Label** は、この統合を識別するために使用したいラベルを設定します。 +- **Location** は、GitLab サーバーへのリンクを設定します。例: `https://gitlab.com/` +- **Token** は、GitLab のパーソナルアクセストークンを設定します。トークンには API スコープが必要です。詳細は[GitLab のパーソナルアクセストークン作成ガイド](https://docs.gitlab.com/user/profile/personal_access_tokens/#create-a-personal-access-token)を参照してください。 + +### Issue Tracker Mapping + +- **Project Name**: Issue を送信したい GitLab のプロジェクト名です。 + +### Severity Mapping Details + +これは GitLab の Priority フィールドにマッピングされます。 +- **Severity Field Name**: `Priority` +- **Info Mapping**: `1` +- **Low Mapping**: `2` +- **Medium Mapping**: `3` +- **High Mapping**: `4` +- **Critical Mapping**: `5` + +### Status Mapping Details + +GitLab には、デフォルトで「opened」と「closed」というステータスがあります。誤検知やリスク受容済みのステータスを追跡したい場合は、追加のステータスラベルを設定できます。詳細は[GitLab のドキュメント](https://docs.gitlab.com/user/work_items/status/)を参照してください。 + +- **Status Field Name**: `Status` +- **Active Mapping**: `opened` +- **Closed Mapping**: `closed` +- **False Positive Mapping**: `closed` +- **Risk Accepted Mapping**: `closed` diff --git a/docs/content/connectors/toolreference/gitlab.md b/docs/content/connectors/toolreference/gitlab.md new file mode 100644 index 00000000000..74e1e6406df --- /dev/null +++ b/docs/content/connectors/toolreference/gitlab.md @@ -0,0 +1,54 @@ +--- +title: "GitLab" +description: "Upstream and Downstream Connector setup for GitLab" +weight: 65 +audience: pro +--- +## Upstream Connector + +The GitLab connector is an **Asset Connector**: it enumerates every project (repository) your token can access and creates a DefectDojo Asset for each one, grouped into Organizations by GitLab namespace (group or user). No findings are imported. + +#### Prerequisites + +You will need a Personal Access Token with the **read_api** scope. We recommend creating the token from a dedicated service account; the connector lists the projects that account is a member of. + +#### Connector Mappings + +1. Enter your GitLab URL in the **Location** field: `https://gitlab.com`, or the base URL of your self-hosted instance. +2. Enter the Personal Access Token in the **Secret** field. + +Each project becomes a Record named after the project, grouped by its **namespace**. Projects that are pending deletion in GitLab (deleted by a user, but not yet purged by GitLab's background job) are excluded automatically, so deleting a project flags its Record as `MISSING` on the next Sync instead of leaving behind a renamed ghost asset. + +## Downstream Connector + +The GitLab integration allows you to add issues to a [GitLab Project](https://docs.gitlab.com/ee/user/project/). + +### Instance Setup + +- **Label** should be the label that you want to use to identify this integration. +- **Location** should be set to the link to your GitLab server, for example `https://gitlab.com/`. +- **Token** should be set to a personal access token from GitLab. The token must have API scopes. See [GitLab’s guide to creating a personal access token](https://docs.gitlab.com/user/profile/personal_access_tokens/#create-a-personal-access-token). + +### Issue Tracker Mapping + +- **Project Name**: The name of the project in GitLab that you want to send issues to. + +### Severity Mapping Details + +This maps to the GitLab Priority field. +- **Severity Field Name**: `Priority` +- **Info Mapping**: `1` +- **Low Mapping**: `2` +- **Medium Mapping**: `3` +- **High Mapping**: `4` +- **Critical Mapping**: `5` + +### Status Mapping Details + +By default, GitLab has statuses of 'opened' and 'closed'. Additional status labels can be added if you want to track False Positive or Risk Accepted status. See [GitLab Docs](https://docs.gitlab.com/user/work_items/status/) for details. + +- **Status Field Name**: `Status` +- **Active Mapping**: `opened` +- **Closed Mapping**: `closed` +- **False Positive Mapping**: `closed` +- **Risk Accepted Mapping**: `closed` diff --git a/docs/content/connectors/toolreference/google_artifact_analysis.md b/docs/content/connectors/toolreference/google_artifact_analysis.md new file mode 100644 index 00000000000..e2c22b2f0e3 --- /dev/null +++ b/docs/content/connectors/toolreference/google_artifact_analysis.md @@ -0,0 +1,20 @@ +--- +title: "Google Artifact Analysis" +description: "How to set up the Google Artifact Analysis Upstream Connector for DefectDojo" +weight: 66 +audience: pro +--- +The Google Artifact Analysis connector imports **container image vulnerability findings** from Google Cloud. DefectDojo creates a Record for each **active** GCP project the service account can list — no per\-image or per\-repository configuration is needed. + +#### Prerequisites + +A Google **service account** with the **Container Analysis Occurrences Viewer** role, and a **JSON key** for it. Neither the key nor the token derived from it is ever logged. + +#### Connector Mappings + +1. Leave the **Location** field at the default unless you use a non\-standard endpoint. +2. Paste the **entire contents** of the service account JSON key file into the **Service Account Key** field. +3. Optionally, set **Parent** to narrow the sync to `organizations/{id}`, `folders/{id}` or `projects/{id}`. Leave it blank to sync every project the service account can list. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each active GCP project becomes a Record, carrying the vulnerability occurrences Artifact Analysis has recorded against its images. diff --git a/docs/content/connectors/toolreference/google_cloud_scc.de.md b/docs/content/connectors/toolreference/google_cloud_scc.de.md new file mode 100644 index 00000000000..e659ed831d0 --- /dev/null +++ b/docs/content/connectors/toolreference/google_cloud_scc.de.md @@ -0,0 +1,24 @@ +--- +title: "Google Cloud Security Command Center" +description: "Einrichtung des Google Cloud Security Command Center Upstream-Connectors für DefectDojo" +weight: 67 +audience: pro +--- +Der Google-Cloud-SCC-Connector verwendet die Security-Command-Center-v2-REST-API, um aktive Sicherheitsbefunde aus Ihrer Google-Cloud-Organisation, -Ordner oder -Projekt zu importieren. DefectDojo erstellt für jedes Google-Cloud-**Projekt** mit offenen Befunden einen Eintrag. + +#### Voraussetzungen + +Security Command Center muss für Ihre Organisation **aktiviert** sein (das Standard-Tier ist kostenlos). Anschließend benötigen Sie ein Service-Konto, das Befunde auflisten kann, sowie einen JSON-Schlüssel dafür: + +1. Erstellen Sie in Google Cloud ein Service-Konto — ein dediziertes für DefectDojo wird empfohlen. +2. Gewähren Sie ihm die Rolle **Security Center Findings Viewer** (`roles/securitycenter.findingsViewer`) auf der Ebene, aus der Sie importieren möchten (Organisation, Ordner oder Projekt). +3. Erstellen Sie einen **JSON-Schlüssel** für das Service-Konto und laden Sie ihn herunter. + +#### Connector-Zuordnungen + +1. Lassen Sie das Feld **Location** auf dem Standardwert `https://securitycenter.googleapis.com`, sofern Sie keinen nicht standardmäßigen Endpunkt verwenden. +2. Geben Sie im Feld **Parent Resource** den Geltungsbereich für den Import ein: `organizations/{id}`, `folders/{id}` oder `projects/{id}`. +3. Fügen Sie den vollständigen Inhalt der **JSON-Schlüssel**-Datei des Service-Kontos in das Feld **Service Account Key** ein. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Es werden nur `ACTIVE`, nicht stummgeschaltete Befunde importiert, sodass Befunde, die Sie in SCC deaktivieren oder stummschalten, beim nächsten Sync automatisch in DefectDojo als behoben markiert werden. Das betroffene GCP-Projekt jedes Befunds wird zu dessen Eintrag. diff --git a/docs/content/connectors/toolreference/google_cloud_scc.es.md b/docs/content/connectors/toolreference/google_cloud_scc.es.md new file mode 100644 index 00000000000..d3a8910133e --- /dev/null +++ b/docs/content/connectors/toolreference/google_cloud_scc.es.md @@ -0,0 +1,24 @@ +--- +title: "Google Cloud Security Command Center" +description: "Cómo configurar el Conector Upstream de Google Cloud Security Command Center para DefectDojo" +weight: 67 +audience: pro +--- +El conector de Google Cloud SCC utiliza la API REST v2 de Security Command Center para importar los hallazgos de seguridad activos de su organización, carpeta o proyecto de Google Cloud. DefectDojo crea un Registro para cada **proyecto** de Google Cloud que tenga hallazgos abiertos. + +#### Requisitos previos + +Security Command Center debe estar **activado** en su organización (el nivel Standard es gratuito). A continuación, necesitará una cuenta de servicio que pueda listar hallazgos, y una clave JSON para ella: + +1. En Google Cloud, cree una cuenta de servicio; se recomienda una dedicada para DefectDojo. +2. Otórguele el rol **Security Center Findings Viewer** (`roles/securitycenter.findingsViewer`) en el alcance que desea importar (organización, carpeta o proyecto). +3. Cree una **clave JSON** para la cuenta de servicio y descárguela. + +#### Asignaciones del conector + +1. Deje el campo **Location** con el valor predeterminado `https://securitycenter.googleapis.com`, salvo que utilice un endpoint no estándar. +2. En el campo **Parent Resource**, introduzca el alcance desde el que importar: `organizations/{id}`, `folders/{id}` o `projects/{id}`. +3. Pegue el contenido completo del archivo de **clave JSON** de la cuenta de servicio en el campo **Service Account Key**. +4. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. + +Solo se importan los hallazgos `ACTIVE` y no silenciados, por lo que los hallazgos que desactive o silencie en SCC se mitigan automáticamente en DefectDojo en la siguiente sincronización. El proyecto de GCP afectado de cada hallazgo se convierte en su Registro. diff --git a/docs/content/connectors/toolreference/google_cloud_scc.fr.md b/docs/content/connectors/toolreference/google_cloud_scc.fr.md new file mode 100644 index 00000000000..9ebe994bef8 --- /dev/null +++ b/docs/content/connectors/toolreference/google_cloud_scc.fr.md @@ -0,0 +1,24 @@ +--- +title: "Google Cloud Security Command Center" +description: "Comment configurer le Connecteur Upstream Google Cloud Security Command Center pour DefectDojo" +weight: 67 +audience: pro +--- +Le connecteur Google Cloud SCC utilise l'API REST Security Command Center v2 pour importer les constatations de sécurité actives de votre organisation, dossier ou projet Google Cloud. DefectDojo crée un enregistrement pour chaque **projet** Google Cloud ayant des constatations ouvertes. + +#### Prérequis + +Security Command Center doit être **activé** sur votre organisation (le niveau Standard est gratuit). Vous aurez ensuite besoin d'un compte de service capable de lister les constatations, ainsi que d'une clé JSON pour celui-ci : + +1. Dans Google Cloud, créez un compte de service — un compte dédié pour DefectDojo est recommandé. +2. Accordez-lui le rôle **Security Center Findings Viewer** (`roles/securitycenter.findingsViewer`) au niveau (organisation, dossier ou projet) que vous souhaitez importer. +3. Créez une **clé JSON** pour le compte de service et téléchargez-la. + +#### Mappages du connecteur + +1. Laissez le champ **Location** à sa valeur par défaut `https://securitycenter.googleapis.com`, sauf si vous utilisez un point de terminaison non standard. +2. Dans le champ **Parent Resource**, saisissez le périmètre depuis lequel importer : `organizations/{id}`, `folders/{id}`, ou `projects/{id}`. +3. Collez le contenu complet du fichier de **clé JSON** du compte de service dans le champ **Service Account Key**. +4. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Seules les constatations à l'état `ACTIVE` et non mises en sourdine sont importées ; les constatations que vous désactivez ou mettez en sourdine dans SCC sont donc automatiquement atténuées dans DefectDojo lors de la prochaine synchronisation. Le projet GCP affecté par chaque constatation devient son enregistrement. diff --git a/docs/content/connectors/toolreference/google_cloud_scc.ja.md b/docs/content/connectors/toolreference/google_cloud_scc.ja.md new file mode 100644 index 00000000000..d2ebfdb6a33 --- /dev/null +++ b/docs/content/connectors/toolreference/google_cloud_scc.ja.md @@ -0,0 +1,24 @@ +--- +title: "Google Cloud Security Command Center" +description: "DefectDojo で Google Cloud Security Command Center の Upstream Connector をセットアップする方法" +weight: 67 +audience: pro +--- +Google Cloud SCCコネクタは、Security Command Center v2 REST APIを使用して、Google Cloudのorganization、folder、またはprojectからアクティブなセキュリティの検出事項をインポートします。DefectDojoは、オープンな検出事項を持つGoogle Cloudの**project**ごとにレコードを作成します。 + +#### Prerequisites + +組織でSecurity Command Centerが**有効化**されている必要があります（Standardティアは無料です）。次に、検出事項を一覧取得できるサービスアカウントと、そのJSONキーが必要です。 + +1. Google Cloudでサービスアカウントを作成します。DefectDojo専用のアカウントを作成することをお勧めします。 +2. インポートしたいスコープ（organization、folder、またはproject）に対して、**Security Center Findings Viewer**ロール（`roles/securitycenter.findingsViewer`）を付与します。 +3. そのサービスアカウントの**JSONキー**を作成してダウンロードします。 + +#### Connector Mappings + +1. 標準以外のエンドポイントを使用しない限り、**Location**フィールドはデフォルトの`https://securitycenter.googleapis.com`のままにします。 +2. **Parent Resource**フィールドに、インポート元のスコープを入力します: `organizations/{id}`、`folders/{id}`、または`projects/{id}`。 +3. サービスアカウントの**JSONキー**ファイルの内容全体を**Service Account Key**フィールドに貼り付けます。 +4. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 + +インポートされるのは`ACTIVE`かつミュートされていない検出事項のみです。そのため、SCCで非アクティブ化またはミュートした検出事項は、次回の同期時にDefectDojo側でも自動的に緩和済みになります。各検出事項が影響するGCPのprojectが、そのレコードになります。 diff --git a/docs/content/connectors/toolreference/google_cloud_scc.md b/docs/content/connectors/toolreference/google_cloud_scc.md new file mode 100644 index 00000000000..7adb1597a46 --- /dev/null +++ b/docs/content/connectors/toolreference/google_cloud_scc.md @@ -0,0 +1,24 @@ +--- +title: "Google Cloud SCC" +description: "How to set up the Google Cloud SCC Upstream Connector for DefectDojo" +weight: 67 +audience: pro +--- +The Google Cloud SCC connector uses the Security Command Center v2 REST API to import active security findings from your Google Cloud organization, folder, or project. DefectDojo creates a Record for each Google Cloud **project** that has open findings. + +#### Prerequisites + +Security Command Center must be **activated** on your organization (the Standard tier is free). You will then need a service account that can list findings, and a JSON key for it: + +1. In Google Cloud, create a service account — a dedicated one for DefectDojo is recommended. +2. Grant it the **Security Center Findings Viewer** role (`roles/securitycenter.findingsViewer`) at the scope you want to import (organization, folder, or project). +3. Create a **JSON key** for the service account and download it. + +#### Connector Mappings + +1. Leave the **Location** field at the default `https://securitycenter.googleapis.com` unless you use a non-standard endpoint. +2. In the **Parent Resource** field, enter the scope to import from: `organizations/{id}`, `folders/{id}`, or `projects/{id}`. +3. Paste the full contents of the service-account **JSON key** file into the **Service Account Key** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Only `ACTIVE`, un-muted findings are imported, so findings you deactivate or mute in SCC are automatically mitigated in DefectDojo on the next sync. Each finding's affected GCP project becomes its Record. diff --git a/docs/content/connectors/toolreference/group_ib_asm.de.md b/docs/content/connectors/toolreference/group_ib_asm.de.md new file mode 100644 index 00000000000..2a880919871 --- /dev/null +++ b/docs/content/connectors/toolreference/group_ib_asm.de.md @@ -0,0 +1,37 @@ +--- +title: "Group-IB ASM" +description: "Einrichtung des Group-IB ASM Upstream-Connectors für DefectDojo" +weight: 68 +audience: pro +--- +Der Group-IB-ASM(Attack Surface Management)-Connector verwendet die Group-IB-ASM-REST-API, um externe Angriffsflächen-**Issues** (Befunde) in DefectDojo zu übertragen. DefectDojo ermittelt jedes Group-IB-**Unternehmen/Tenant** als separaten Eintrag und importiert die Issues dieses Unternehmens geplant und inkrementell. Das Asset, auf das sich jedes Issue bezieht (eine Domain, IP oder URL), wird dem resultierenden Befund als **Endpunkt** angehängt. + +#### Voraussetzungen + +Sie benötigen Ihren Group-IB-ASM-Login und einen API-Schlüssel. Wir empfehlen, für DefectDojo ein dediziertes Service-Konto anzulegen, damit automatisierte Aktivitäten von manuellen Team-Aktionen unterschieden werden können. + +So generieren Sie einen API-Schlüssel: + +1. Öffnen Sie Group-IB Attack Surface Management, klicken Sie unten links auf **Help** und wählen Sie **API**. +2. Klicken Sie auf **Generate API Key** (oben rechts, unter Ihrem Benutzernamen). +3. Geben Sie Ihr SSO-Passwort ein und klicken Sie auf **Next**, dann auf **Copy token**. +4. Speichern Sie den Schlüssel in einem Secret Manager und planen Sie eine regelmäßige Rotation ein. + +#### Connector-Zuordnungen + +Group-IB ASM authentifiziert sich mit HTTP Basic Auth, wobei der Benutzername Ihr ASM-Login und das Passwort Ihr API-Schlüssel ist. **Beide Werte sind erforderlich** — der API-Schlüssel allein reicht nicht aus. + +1. Geben Sie `https://asm.group-ib.com` in das Feld **Location** ein. Dies ist für alle Group-IB-ASM-Tenants gleich. +2. Geben Sie Ihren ASM-Login (in der Regel eine E-Mail-Adresse) in das Feld **Username** ein. +3. Geben Sie Ihren API-Schlüssel in das Feld **API Key** (Secret) ein. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. + +DefectDojo ordnet jedes Group-IB-**Unternehmen** als separaten Eintrag zu, wobei die Unternehmens-ID als Kennung verwendet wird. Beim ersten Sync trägt DefectDojo die jüngste Issue-Historie nach; nachfolgende Syncs erfolgen inkrementell und rufen nur seit dem letzten Sync geänderte Issues ab (anhand des jeweils neuesten `lastSeen`-Zeitstempels jedes Issues). + +#### Beschränkung auf ein einzelnes Unternehmen (optional) + +Standardmäßig ermittelt der Connector automatisch die für Ihre API-Anmeldedaten verfügbaren Unternehmen (über den ASM-Endpunkt `clients`) und erstellt einen Eintrag pro Unternehmen. Dies ist die empfohlene Einrichtung und erfordert keine zusätzliche Konfiguration. + +Ist der Endpunkt `clients` für Ihren Tenant nicht verfügbar — zum Beispiel, weil er auf Partner-/MSP-Konten beschränkt ist —, kann der Connector auf ein Unternehmen beschränkt werden, indem dessen **Unternehmens-ID** als toolspezifisches Feld `company_id` in der Connector-Konfiguration angegeben wird. Ist `company_id` gesetzt, verwendet DefectDojo dieses Unternehmen direkt, statt Unternehmen aufzuzählen. Lassen Sie es nicht gesetzt, um die automatische Ermittlung zu verwenden. + +Weitere Informationen finden Sie im Group-IB-ASM-REST-API-Handbuch (im Produkt verfügbar über **Help → API**). diff --git a/docs/content/connectors/toolreference/group_ib_asm.es.md b/docs/content/connectors/toolreference/group_ib_asm.es.md new file mode 100644 index 00000000000..99ebd3d0ed8 --- /dev/null +++ b/docs/content/connectors/toolreference/group_ib_asm.es.md @@ -0,0 +1,37 @@ +--- +title: "Group-IB ASM" +description: "Cómo configurar el Conector Upstream de Group-IB ASM para DefectDojo" +weight: 68 +audience: pro +--- +El conector Group-IB ASM (Attack Surface Management) usa la API REST de Group-IB ASM para importar a DefectDojo **incidencias** (hallazgos) de superficie de ataque externa. DefectDojo detecta cada **empresa/tenant** de Group-IB como un Registro independiente e importa las incidencias de esa empresa de forma programada e incremental. El activo al que se refiere cada incidencia (un dominio, una IP o una URL) se adjunta al hallazgo resultante como un **Endpoint**. + +#### Requisitos previos + +Necesitará su inicio de sesión de Group-IB ASM y una clave de API. Recomendamos crear una cuenta de servicio dedicada para DefectDojo, de modo que la actividad automatizada pueda distinguirse de las acciones manuales del equipo. + +Para generar una clave de API: + +1. Abra Group-IB Attack Surface Management, haga clic en **Help** en la esquina inferior izquierda y seleccione **API**. +2. Haga clic en **Generate API Key** (arriba a la derecha, debajo de su nombre de usuario). +3. Introduzca su contraseña de SSO y haga clic en **Next**, luego haga clic en **Copy token**. +4. Guarde la clave en un gestor de secretos y planifique su rotación periódica. + +#### Asignaciones del conector + +Group-IB ASM se autentica mediante HTTP Basic Auth, donde el nombre de usuario es su inicio de sesión de ASM y la contraseña es su clave de API. **Se requieren ambos valores**: la clave de API por sí sola no es suficiente. + +1. Introduzca `https://asm.group-ib.com` en el campo **Location**. Es el mismo para todos los tenants de Group-IB ASM. +2. Introduzca su inicio de sesión de ASM (normalmente una dirección de correo electrónico) en el campo **Username**. +3. Introduzca su clave de API en el campo **API Key** (Secret). +4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importan. + +DefectDojo asigna cada **empresa** de Group-IB como un Registro independiente, usando el ID de la empresa como identificador. En la primera Sincronización, DefectDojo recupera el historial reciente de incidencias; las Sincronizaciones posteriores son incrementales y solo obtienen las incidencias modificadas desde la última Sincronización (según la marca de tiempo `lastSeen` más reciente de cada incidencia). + +#### Limitar a una sola empresa (opcional) + +De forma predeterminada, el conector detecta automáticamente las empresas disponibles para sus credenciales de API (mediante el endpoint `clients` de ASM) y crea un Registro por empresa. Esta es la configuración recomendada y no requiere configuración adicional. + +Si el endpoint `clients` no está disponible para su tenant — por ejemplo, cuando está restringido a cuentas de socios/MSP —, el conector puede limitarse a una sola empresa proporcionando su **ID de empresa** como campo específico de la herramienta `company_id` en la configuración del conector. Cuando se establece `company_id`, DefectDojo usa esa empresa directamente en lugar de enumerar las empresas. Déjelo sin establecer para usar la detección automática. + +Consulte el manual de la API REST de Group-IB ASM (disponible en el propio producto en **Help → API**) para obtener más información. diff --git a/docs/content/connectors/toolreference/group_ib_asm.fr.md b/docs/content/connectors/toolreference/group_ib_asm.fr.md new file mode 100644 index 00000000000..98200899790 --- /dev/null +++ b/docs/content/connectors/toolreference/group_ib_asm.fr.md @@ -0,0 +1,37 @@ +--- +title: "Group-IB ASM" +description: "Comment configurer le Connecteur Upstream Group-IB ASM pour DefectDojo" +weight: 68 +audience: pro +--- +Le connecteur Group-IB ASM (Attack Surface Management) utilise l'API REST Group-IB ASM pour importer dans DefectDojo les **issues** (constatations) de surface d'attaque externe. DefectDojo découvre chaque **entreprise/locataire** Group-IB comme un Enregistrement distinct et importe les issues de cette entreprise de façon planifiée et incrémentale. L'actif auquel se rapporte chaque issue (un domaine, une IP ou une URL) est rattaché à la constatation résultante en tant que **Point de terminaison**. + +#### Prérequis + +Vous aurez besoin de votre identifiant de connexion Group-IB ASM et d'une clé API. Nous recommandons de créer un compte de service dédié pour DefectDojo afin de pouvoir distinguer l'activité automatisée des actions manuelles de l'équipe. + +Pour générer une clé API : + +1. Ouvrez Group-IB Attack Surface Management, cliquez sur **Help** dans le coin inférieur gauche, puis sélectionnez **API**. +2. Cliquez sur **Generate API Key** (en haut à droite, sous votre nom d'utilisateur). +3. Saisissez votre mot de passe SSO, cliquez sur **Next**, puis cliquez sur **Copy token**. +4. Stockez la clé dans un gestionnaire de secrets et prévoyez une rotation régulière. + +#### Mappages du connecteur + +Group-IB ASM s'authentifie via HTTP Basic Auth, où le nom d'utilisateur est votre identifiant de connexion ASM et le mot de passe est votre clé API. **Les deux valeurs sont requises** — la clé API seule ne suffit pas. + +1. Saisissez `https://asm.group-ib.com` dans le champ **Location**. Cette valeur est identique pour tous les locataires Group-IB ASM. +2. Saisissez votre identifiant de connexion ASM (généralement une adresse e-mail) dans le champ **Username**. +3. Saisissez votre clé API dans le champ **API Key** (Secret). +4. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. Les constatations en dessous de la sévérité sélectionnée ne sont pas importées. + +DefectDojo mappe chaque **entreprise** Group-IB comme un Enregistrement distinct, en utilisant l'identifiant de l'entreprise comme identifiant. Lors de la première synchronisation, DefectDojo réimporte l'historique récent des issues ; les synchronisations suivantes sont incrémentales et ne récupèrent que les issues modifiées depuis la dernière synchronisation (suivies via l'horodatage `lastSeen` le plus récent de chaque issue). + +#### Limiter à une seule entreprise (optionnel) + +Par défaut, le connecteur découvre automatiquement les entreprises accessibles avec vos identifiants API (via le point de terminaison ASM `clients`) et crée un Enregistrement par entreprise. C'est la configuration recommandée et elle ne nécessite aucune configuration supplémentaire. + +Si le point de terminaison `clients` n'est pas disponible pour votre locataire — par exemple lorsqu'il est réservé aux comptes partenaires/MSP —, le connecteur peut être limité à une seule entreprise en fournissant son **identifiant d'entreprise** en tant que champ spécifique à l'outil `company_id` dans la configuration du connecteur. Lorsque `company_id` est défini, DefectDojo utilise directement cette entreprise au lieu d'énumérer les entreprises. Laissez ce champ vide pour utiliser la découverte automatique. + +Consultez le manuel de l'API REST Group-IB ASM (disponible dans le produit via **Help → API**) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/group_ib_asm.ja.md b/docs/content/connectors/toolreference/group_ib_asm.ja.md new file mode 100644 index 00000000000..74724112511 --- /dev/null +++ b/docs/content/connectors/toolreference/group_ib_asm.ja.md @@ -0,0 +1,37 @@ +--- +title: "Group-IB ASM" +description: "DefectDojo で Group-IB ASM の Upstream Connector をセットアップする方法" +weight: 68 +audience: pro +--- +Group-IB ASM(Attack Surface Management)コネクタは、Group-IB ASM REST APIを使用して、外部の攻撃対象領域の**issue**(検出事項)をDefectDojoに取り込みます。DefectDojoは各Group-IBの**company/tenant**を個別のRecordとして検出し、そのcompanyのissueをスケジュールに基づいて増分的にインポートします。各issueが関連するアセット(ドメイン、IP、またはURL)は、生成された検出事項に**Endpoint**として付加されます。 + +#### Prerequisites + +Group-IB ASMのログイン情報とAPIキーが必要です。自動化された操作を手動のチーム操作と区別できるよう、DefectDojo専用のサービスアカウントを作成することをお勧めします。 + +APIキーを生成するには: + +1. Group-IB Attack Surface Managementを開き、左下の**Help**をクリックして**API**を選択します。 +2. (右上、ユーザー名の下にある)**Generate API Key**をクリックします。 +3. SSOパスワードを入力して**Next**をクリックし、次に**Copy token**をクリックします。 +4. キーをシークレットマネージャーに保管し、定期的なローテーションを計画してください。 + +#### Connector Mappings + +Group-IB ASMはHTTP Basic認証で認証を行います。ユーザー名はASMのログイン情報、パスワードはAPIキーです。**両方の値が必要です** — APIキーだけでは十分ではありません。 + +1. **Location**フィールドに`https://asm.group-ib.com`を入力します。これはすべてのGroup-IB ASMテナントで共通です。 +2. **Username**フィールドにASMのログイン情報(通常はメールアドレス)を入力します。 +3. **API Key**(Secret)フィールドにAPIキーを入力します。 +4. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。選択した深刻度を下回る検出事項はインポートされません。 + +DefectDojoは各Group-IBの**company**をcompany IDを識別子として個別のRecordにマッピングします。最初のSyncでは、DefectDojoは最近のissue履歴をバックフィルします。以降のSyncは増分的で、前回のSync以降に変更されたissueのみを(各issueの最新の`lastSeen`タイムスタンプで追跡して)取り込みます。 + +#### Scoping to a single company (optional) + +デフォルトでは、コネクタはお使いのAPI資格情報でアクセス可能なcompanyを(ASMの`clients`エンドポイント経由で)自動的に検出し、company一つにつき一つのRecordを作成します。これが推奨のセットアップであり、追加の設定は不要です。 + +`clients`エンドポイントがお使いのテナントで利用できない場合(たとえばパートナー/MSPアカウントに制限されている場合など)、コネクタの設定でツール固有フィールド`company_id`にそのcompanyの**company ID**を指定することで、単一のcompanyにスコープを限定できます。`company_id`が設定されている場合、DefectDojoはcompanyを列挙する代わりにそのcompanyを直接使用します。自動検出を使用するには未設定のままにしてください。 + +詳細については、Group-IB ASM REST APIマニュアル(製品内の**Help → API**から利用可能)を参照してください。 diff --git a/docs/content/connectors/toolreference/group_ib_asm.md b/docs/content/connectors/toolreference/group_ib_asm.md new file mode 100644 index 00000000000..4c49377ea23 --- /dev/null +++ b/docs/content/connectors/toolreference/group_ib_asm.md @@ -0,0 +1,37 @@ +--- +title: "Group-IB ASM" +description: "How to set up the Group-IB ASM Upstream Connector for DefectDojo" +weight: 68 +audience: pro +--- +The Group-IB ASM (Attack Surface Management) connector uses the Group-IB ASM REST API to pull external attack-surface **issues** (findings) into DefectDojo. DefectDojo discovers each Group-IB **company/tenant** as a separate Record and imports that company's issues on a scheduled, incremental basis. The asset each issue relates to (a domain, IP, or URL) is attached to the resulting finding as an **Endpoint**. + +#### Prerequisites + +You will need your Group-IB ASM login and an API key. We recommend creating a dedicated service account for DefectDojo so that automated activity can be distinguished from manual team actions. + +To generate an API key: + +1. Open Group-IB Attack Surface Management, click **Help** in the lower-left corner, and select **API**. +2. Click **Generate API Key** (top-right, under your username). +3. Enter your SSO password and click **Next**, then click **Copy token**. +4. Store the key in a secret manager and plan for regular rotation. + +#### Connector Mappings + +Group-IB ASM authenticates with HTTP Basic Auth, where the username is your ASM login and the password is your API key. **Both values are required** — the API key alone is not sufficient. + +1. Enter `https://asm.group-ib.com` in the **Location** field. This is the same for all Group-IB ASM tenants. +2. Enter your ASM login (usually an email address) in the **Username** field. +3. Enter your API key in the **API Key** (Secret) field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. Findings below the selected severity are not imported. + +DefectDojo maps each Group-IB **company** as a separate Record, using the company ID as the identifier. On the first Sync, DefectDojo backfills recent issue history; subsequent Syncs are incremental, pulling only issues changed since the last Sync (tracked by each issue's most recent `lastSeen` timestamp). + +#### Scoping to a single company (optional) + +By default, the connector automatically discovers the companies available to your API credentials (via the ASM `clients` endpoint) and creates one Record per company. This is the recommended setup and requires no extra configuration. + +If the `clients` endpoint is not available for your tenant — for example, when it is restricted to partner/MSP accounts — the connector can be scoped to one company by supplying its **company ID** as a `company_id` tool-specific field on the connector configuration. When `company_id` is set, DefectDojo uses that company directly instead of enumerating companies. Leave it unset to use automatic discovery. + +See the Group-IB ASM REST API manual (available in-product via **Help → API**) for more information. diff --git a/docs/content/connectors/toolreference/hackerone.de.md b/docs/content/connectors/toolreference/hackerone.de.md new file mode 100644 index 00000000000..426402e51a3 --- /dev/null +++ b/docs/content/connectors/toolreference/hackerone.de.md @@ -0,0 +1,23 @@ +--- +title: "HackerOne" +description: "Einrichtung des HackerOne Upstream-Connectors für DefectDojo" +weight: 69 +audience: pro +--- +Der HackerOne-Connector verwendet die HackerOne-REST-API, um Reports aus Ihrem Bug-Bounty- oder Vulnerability-Disclosure-Programm zu importieren. DefectDojo erstellt für jedes Programm, auf das das Token zugreifen kann, einen Eintrag und importiert dessen Reports als Befunde. + +#### Voraussetzungen + +Der Connector verwendet die **Customer**-API von HackerOne, die ein **Organization-API-Token** erfordert — ein persönliches Token aus Ihren Benutzereinstellungen funktioniert nur gegen die Hacker-API und authentifiziert sich hier nicht. + +1. Gehen Sie in HackerOne zu **Organization Settings > API Tokens**. +2. Erstellen Sie ein Token und notieren Sie sowohl die **Identifier** als auch den **Token**-Wert. Lesezugriff auf das Programm ist ausreichend. + +#### Connector-Zuordnungen + +1. Geben Sie `https://api.hackerone.com` in das Feld **Location** ein. +2. Geben Sie die Token-**Identifier** in das Feld **API Token Identifier** ein. +3. Geben Sie den Token-Wert in das Feld **API Token** ein. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jedes Programm wird zu einem Eintrag, und seine Reports werden mit der beibehaltenen HackerOne-Schweregrad-Bewertung als Befunde importiert. diff --git a/docs/content/connectors/toolreference/hackerone.es.md b/docs/content/connectors/toolreference/hackerone.es.md new file mode 100644 index 00000000000..23e1faf5334 --- /dev/null +++ b/docs/content/connectors/toolreference/hackerone.es.md @@ -0,0 +1,23 @@ +--- +title: "HackerOne" +description: "Cómo configurar el Conector Upstream de HackerOne para DefectDojo" +weight: 69 +audience: pro +--- +El conector HackerOne usa la API REST de HackerOne para importar reportes de su programa de recompensas por errores (bug bounty) o de divulgación de vulnerabilidades. DefectDojo crea un Registro para cada programa al que el token pueda acceder e importa sus reportes como hallazgos. + +#### Requisitos previos + +El conector usa la API **customer** de HackerOne, que requiere un **token de API de la organización**; un token personal de la configuración de su usuario solo funciona con la API de hacker y no se autenticará aquí. + +1. En HackerOne, vaya a **Organization Settings > API Tokens**. +2. Cree un token y anote tanto el **identifier** como el valor del **token**. El acceso de lectura al programa es suficiente. + +#### Asignaciones del conector + +1. Introduzca `https://api.hackerone.com` en el campo **Location**. +2. Introduzca el **identifier** del token en el campo **API Token Identifier**. +3. Introduzca el valor del token en el campo **API Token**. +4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada programa se convierte en un Registro, y sus reportes se importan como hallazgos conservando la calificación de severidad de HackerOne. diff --git a/docs/content/connectors/toolreference/hackerone.fr.md b/docs/content/connectors/toolreference/hackerone.fr.md new file mode 100644 index 00000000000..1ef469387f5 --- /dev/null +++ b/docs/content/connectors/toolreference/hackerone.fr.md @@ -0,0 +1,23 @@ +--- +title: "HackerOne" +description: "Comment configurer le Connecteur Upstream HackerOne pour DefectDojo" +weight: 69 +audience: pro +--- +Le connecteur HackerOne utilise l'API REST HackerOne pour importer les rapports de votre programme de bug bounty ou de divulgation de vulnérabilités. DefectDojo crée un Enregistrement pour chaque programme auquel le jeton peut accéder et importe ses rapports en tant que constatations. + +#### Prérequis + +Le connecteur utilise l'API **customer** de HackerOne, qui nécessite un **jeton API d'organisation** — un jeton personnel provenant de vos paramètres utilisateur ne fonctionne qu'avec l'API hacker et ne permettra pas de s'authentifier ici. + +1. Dans HackerOne, accédez à **Organization Settings > API Tokens**. +2. Créez un jeton et notez à la fois l'**identifiant** et la valeur du **jeton**. Un accès en lecture au programme suffit. + +#### Mappages du connecteur + +1. Saisissez `https://api.hackerone.com` dans le champ **Location**. +2. Saisissez l'**identifiant** du jeton dans le champ **API Token Identifier**. +3. Saisissez la valeur du jeton dans le champ **API Token**. +4. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. + +Chaque programme devient un Enregistrement, et ses rapports sont importés en tant que constatations en conservant la note de sévérité HackerOne. diff --git a/docs/content/connectors/toolreference/hackerone.ja.md b/docs/content/connectors/toolreference/hackerone.ja.md new file mode 100644 index 00000000000..6e4c488afff --- /dev/null +++ b/docs/content/connectors/toolreference/hackerone.ja.md @@ -0,0 +1,23 @@ +--- +title: "HackerOne" +description: "DefectDojo で HackerOne の Upstream Connector をセットアップする方法" +weight: 69 +audience: pro +--- +HackerOneコネクタは、HackerOne REST APIを使用して、バグバウンティまたは脆弱性開示プログラムからレポートをインポートします。DefectDojoはトークンがアクセスできる各プログラムのRecordを作成し、そのレポートを検出事項としてインポートします。 + +#### Prerequisites + +このコネクタはHackerOneの**customer** APIを使用しており、**organization APIトークン**が必要です。ユーザー設定の個人トークンはhacker APIに対してのみ有効で、ここでは認証できません。 + +1. HackerOneで**Organization Settings > API Tokens**に移動します。 +2. トークンを作成し、**identifier**と**token**の両方の値を控えておきます。プログラムへの読み取りアクセスがあれば十分です。 + +#### Connector Mappings + +1. **Location**フィールドに`https://api.hackerone.com`を入力します。 +2. **API Token Identifier**フィールドにトークンの**identifier**を入力します。 +3. **API Token**フィールドにトークンの値を入力します。 +4. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。 + +各プログラムがRecordとなり、そのレポートはHackerOneの深刻度評価を維持したまま検出事項としてインポートされます。 diff --git a/docs/content/connectors/toolreference/hackerone.md b/docs/content/connectors/toolreference/hackerone.md new file mode 100644 index 00000000000..965fafbd4e3 --- /dev/null +++ b/docs/content/connectors/toolreference/hackerone.md @@ -0,0 +1,23 @@ +--- +title: "HackerOne" +description: "How to set up the HackerOne Upstream Connector for DefectDojo" +weight: 69 +audience: pro +--- +The HackerOne connector uses the HackerOne REST API to import reports from your bug bounty or vulnerability disclosure program. DefectDojo creates a Record for each program the token can access and imports its reports as findings. + +#### Prerequisites + +The connector uses HackerOne's **customer** API, which requires an **organization API token** — a personal token from your user settings only works against the hacker API and will not authenticate here. + +1. In HackerOne, go to **Organization Settings > API Tokens**. +2. Create a token and note both the **identifier** and the **token** value. Read access to the program is sufficient. + +#### Connector Mappings + +1. Enter `https://api.hackerone.com` in the **Location** field. +2. Enter the token **identifier** in the **API Token Identifier** field. +3. Enter the token value in the **API Token** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each program becomes a Record, and its reports are imported as findings with the HackerOne severity rating preserved. diff --git a/docs/content/connectors/toolreference/halo_security.md b/docs/content/connectors/toolreference/halo_security.md new file mode 100644 index 00000000000..ac73e7372cd --- /dev/null +++ b/docs/content/connectors/toolreference/halo_security.md @@ -0,0 +1,21 @@ +--- +title: "Halo Security" +description: "How to set up the Halo Security Upstream Connector for DefectDojo" +weight: 70 +audience: pro +--- +The Halo Security connector imports **attack surface findings** from Halo Security. DefectDojo creates a Record for each **monitored target**. + +#### Prerequisites + +A Halo Security **API key**. This connector uses a single key — there is no secret, key pair, or OAuth flow to configure. + +#### Connector Mappings + +1. Enter `https://api.halosecurity.com/api/v1` in the **Location** field. +2. Enter your Halo Security API key in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each monitored target becomes a Record, carrying the account's **active** issues that affect it, enriched from Halo's issue catalogue. + +A finding's identity combines the issue **and** the target it was found on. Halo's issue IDs are catalogue identifiers shared across targets, so the same issue affecting two targets is correctly tracked as two findings rather than collapsing into one. diff --git a/docs/content/connectors/toolreference/harbor.de.md b/docs/content/connectors/toolreference/harbor.de.md new file mode 100644 index 00000000000..aeca28c953d --- /dev/null +++ b/docs/content/connectors/toolreference/harbor.de.md @@ -0,0 +1,20 @@ +--- +title: "Harbor" +description: "Einrichtung des Harbor Upstream-Connectors für DefectDojo" +weight: 71 +audience: pro +--- +Der Harbor-Connector verwendet die Harbor-v2.0-REST-API, um Container-Image-Schwachstellen aus Ihrer gesamten Registry zu importieren. DefectDojo zählt jedes Harbor-**Projekt** auf und erstellt für jedes einen Eintrag; anschließend durchläuft er die Repositories und Artefakte des Projekts und importiert die Schwachstellen aus jedem **gescannten** Artefakt — wobei das Image (Repository + Tag/Digest) als Befundkontext übernommen wird. Es gibt keine Pro-Image-Konfiguration. + +#### Voraussetzungen + +Sie benötigen ein Harbor-Konto (oder ein **Robot-Konto**) mit Pull-/Lesezugriff auf die zu importierenden Projekte. Wir empfehlen ein dediziertes Robot-Konto: Öffnen Sie in Harbor ein Projekt (oder **Administration \> Robot Accounts** für ein System-Robot), erstellen Sie einen Robot mit der Berechtigung **pull** auf Repositories und Artefakte, und kopieren Sie dessen vollständigen Namen und Secret. Robot-Namen beginnen standardmäßig mit `robot$`, das Präfix ist jedoch pro Harbor-Instanz konfigurierbar (manche verwenden `robot_`) — kopieren Sie den Namen exakt so, wie Harbor ihn anzeigt. Ein normaler Benutzername/Passwort funktioniert ebenfalls. + +#### Connector-Zuordnungen + +1. Geben Sie Ihre Harbor-URL in das Feld **Location** ein — zum Beispiel `https://harbor.example.com`. DefectDojo hängt den API-Pfad `/api/v2.0` automatisch an. +2. Geben Sie den Harbor-Benutzernamen oder einen Robot-Kontonamen exakt so, wie Harbor ihn anzeigt (standardmäßig `robot$`), in das Feld **Username** ein. +3. Geben Sie das Passwort oder das Robot-Konto-Secret in das Feld **Secret** ein. Es wird per HTTP-Basic-Authentifizierung gesendet. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jedes Harbor-Projekt wird zu einem Eintrag. Für jedes Artefakt mit einem abgeschlossenen Scan werden dessen Schwachstellen als Befunde importiert; das betroffene Paket/die Version, ein von CVSS abgeleiteter Schweregrad, die CVE, die CWE und eine Abhilfemaßnahme (Fix-Version) werden einbezogen, sofern Harbor sie bereitstellt. Es werden nur gescannte Artefakte importiert — lösen Sie in Harbor einen Scan für noch nicht gescannte Images aus. diff --git a/docs/content/connectors/toolreference/harbor.es.md b/docs/content/connectors/toolreference/harbor.es.md new file mode 100644 index 00000000000..2f4b99b2660 --- /dev/null +++ b/docs/content/connectors/toolreference/harbor.es.md @@ -0,0 +1,20 @@ +--- +title: "Harbor" +description: "Cómo configurar el Conector Upstream de Harbor para DefectDojo" +weight: 71 +audience: pro +--- +El conector Harbor usa la API REST v2.0 de Harbor para importar vulnerabilidades de imágenes de contenedor de todo su registro. DefectDojo enumera cada **proyecto** de Harbor y crea un Registro para cada uno, luego recorre los repositorios y artefactos del proyecto e importa las vulnerabilidades de cada artefacto **escaneado** — incorporando la imagen (repositorio + etiqueta/digest) como contexto del hallazgo. No existe configuración por imagen. + +#### Requisitos previos + +Necesitará una cuenta de Harbor (o una **cuenta robot**) con acceso de extracción/lectura a los proyectos que desea importar. Recomendamos una cuenta robot dedicada: en Harbor, abra un proyecto (o **Administration > Robot Accounts** para un robot de sistema), cree un robot con el permiso **pull** sobre repositorios y artefactos, y copie su nombre completo y su secreto. Los nombres de robot comienzan con `robot$` de forma predeterminada, pero el prefijo es configurable por instancia de Harbor (algunas usan `robot_`) — copie el nombre exactamente como lo muestra Harbor. Un nombre de usuario y contraseña normales también funcionan. + +#### Asignaciones del conector + +1. Introduzca su URL de Harbor en el campo **Location** — por ejemplo `https://harbor.example.com`. DefectDojo añade automáticamente la ruta de la API `/api/v2.0`. +2. Introduzca el nombre de usuario de Harbor, o el nombre de una cuenta robot exactamente como lo muestra Harbor (`robot$` de forma predeterminada), en el campo **Username**. +3. Introduzca la contraseña o el secreto de la cuenta robot en el campo **Secret**. Se envía mediante autenticación HTTP Basic. +4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada proyecto de Harbor se convierte en un Registro. Para cada artefacto que tenga un escaneo completado, sus vulnerabilidades se importan como hallazgos; se incluyen el paquete/versión afectados, una severidad derivada de CVSS, el CVE, el CWE y una corrección (versión reparada) cuando Harbor los proporciona. Solo se importan los artefactos escaneados — active un escaneo en Harbor para las imágenes que aún no se hayan escaneado. diff --git a/docs/content/connectors/toolreference/harbor.fr.md b/docs/content/connectors/toolreference/harbor.fr.md new file mode 100644 index 00000000000..acdb1d26fcb --- /dev/null +++ b/docs/content/connectors/toolreference/harbor.fr.md @@ -0,0 +1,20 @@ +--- +title: "Harbor" +description: "Comment configurer le Connecteur Upstream Harbor pour DefectDojo" +weight: 71 +audience: pro +--- +Le connecteur Harbor utilise l'API REST Harbor v2.0 pour importer les vulnérabilités des images de conteneurs sur l'ensemble de votre registre. DefectDojo énumère chaque **projet** Harbor et crée un Enregistrement pour chacun, puis parcourt les dépôts et artefacts du projet et importe les vulnérabilités de chaque artefact **scanné** — en conservant l'image (dépôt + tag/digest) comme contexte de la constatation. Il n'y a pas de configuration par image. + +#### Prérequis + +Vous aurez besoin d'un compte Harbor (ou d'un **compte robot**) disposant d'un accès pull/lecture aux projets que vous souhaitez importer. Nous recommandons un compte robot dédié : dans Harbor, ouvrez un projet (ou **Administration > Robot Accounts** pour un robot système), créez un robot avec la permission **pull** sur les dépôts et artefacts, et copiez son nom complet et son secret. Les noms de robot commencent par `robot$` par défaut, mais le préfixe est configurable selon l'instance Harbor (certaines utilisent `robot_`) — copiez le nom exactement tel qu'affiché par Harbor. Un nom d'utilisateur/mot de passe classique fonctionne aussi. + +#### Mappages du connecteur + +1. Saisissez votre URL Harbor dans le champ **Location** — par exemple `https://harbor.example.com`. DefectDojo ajoute automatiquement le chemin d'API `/api/v2.0`. +2. Saisissez le nom d'utilisateur Harbor, ou un nom de compte robot exactement tel qu'affiché par Harbor (`robot$` par défaut), dans le champ **Username**. +3. Saisissez le mot de passe ou le secret du compte robot dans le champ **Secret**. Il est envoyé via authentification HTTP Basic. +4. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. + +Chaque projet Harbor devient un Enregistrement. Pour chaque artefact ayant un scan terminé, ses vulnérabilités sont importées en tant que constatations ; le paquet/version affecté, une sévérité dérivée du CVSS, le CVE, le CWE et une remédiation (version corrigée) sont inclus lorsque Harbor les fournit. Seuls les artefacts scannés sont importés — déclenchez un scan dans Harbor pour les images qui n'ont pas encore été scannées. diff --git a/docs/content/connectors/toolreference/harbor.ja.md b/docs/content/connectors/toolreference/harbor.ja.md new file mode 100644 index 00000000000..2aadc5a0875 --- /dev/null +++ b/docs/content/connectors/toolreference/harbor.ja.md @@ -0,0 +1,20 @@ +--- +title: "Harbor" +description: "DefectDojo で Harbor の Upstream Connector をセットアップする方法" +weight: 71 +audience: pro +--- +Harborコネクタは、Harbor v2.0 REST APIを使用して、レジストリ全体のコンテナイメージの脆弱性をインポートします。DefectDojoはすべてのHarbor**project**を列挙し、それぞれにRecordを作成した上で、そのprojectのリポジトリとアーティファクトを走査し、**スキャン済み**の各アーティファクトから脆弱性をインポートします — その際、イメージ(リポジトリ+タグ/ダイジェスト)を検出事項のコンテキストとして保持します。イメージごとの個別設定はありません。 + +#### Prerequisites + +インポート対象のprojectへのpull/読み取りアクセス権を持つHarborアカウント(または**robotアカウント**)が必要です。専用のrobotアカウントの使用をお勧めします。Harborでprojectを開き(システムrobotの場合は**Administration > Robot Accounts**)、リポジトリとアーティファクトに対する**pull**権限を持つrobotを作成し、そのフルネームとシークレットをコピーします。robot名はデフォルトで`robot$`から始まりますが、このプレフィックスはHarborインスタンスごとに設定可能です(`robot_`を使用するものもあります) — Harborに表示されている名前をそのままコピーしてください。通常のユーザー名/パスワードも使用できます。 + +#### Connector Mappings + +1. **Location**フィールドにHarborのURLを入力します — 例: `https://harbor.example.com`。DefectDojoは`/api/v2.0`のAPIパスを自動的に付加します。 +2. **Username**フィールドにHarborのユーザー名、またはHarborに表示されているとおりのrobotアカウント名(デフォルトでは`robot$`)を入力します。 +3. **Secret**フィールドにパスワードまたはrobotアカウントのシークレットを入力します。これはHTTP Basic認証で送信されます。 +4. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。 + +各Harbor projectがRecordとなります。スキャンが完了しているアーティファクトごとに、その脆弱性が検出事項としてインポートされます。影響を受けるパッケージ/バージョン、CVSSに基づく深刻度、CVE、CWE、および修復方法(修正済みバージョン)は、Harborが提供している場合に含まれます。インポートされるのはスキャン済みのアーティファクトのみです — まだスキャンされていないイメージについては、Harbor側でスキャンを実行してください。 diff --git a/docs/content/connectors/toolreference/harbor.md b/docs/content/connectors/toolreference/harbor.md new file mode 100644 index 00000000000..faa8deb1bca --- /dev/null +++ b/docs/content/connectors/toolreference/harbor.md @@ -0,0 +1,20 @@ +--- +title: "Harbor" +description: "How to set up the Harbor Upstream Connector for DefectDojo" +weight: 71 +audience: pro +--- +The Harbor connector uses the Harbor v2.0 REST API to import container image vulnerabilities across your whole registry. DefectDojo enumerates every Harbor **project** and creates a Record for each one, then walks the project's repositories and artifacts and imports the vulnerabilities from each **scanned** artifact — carrying the image (repository + tag/digest) as finding context. There is no per\-image configuration. + +#### Prerequisites + +You will need a Harbor account (or a **robot account**) with pull/read access to the projects you want to import. We recommend a dedicated robot account: in Harbor, open a project (or **Administration \> Robot Accounts** for a system robot), create a robot with the **pull** permission on repositories and artifacts, and copy its full name and secret. Robot names start with `robot$` by default, but the prefix is configurable per Harbor instance (some use `robot_`) — copy the name exactly as Harbor displays it. A regular username/password also works. + +#### Connector Mappings + +1. Enter your Harbor URL in the **Location** field — for example `https://harbor.example.com`. DefectDojo appends the `/api/v2.0` API path automatically. +2. Enter the Harbor username, or a robot account name exactly as Harbor shows it (`robot$` by default), in the **Username** field. +3. Enter the password or robot account secret in the **Secret** field. It is sent using HTTP Basic authentication. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each Harbor project becomes a Record. For every artifact that has a completed scan, its vulnerabilities are imported as findings; the affected package/version, a CVSS\-derived severity, the CVE, the CWE, and a remediation (fixed version) are included where Harbor provides them. Only scanned artifacts are imported — trigger a scan in Harbor for images that have not been scanned yet. diff --git a/docs/content/connectors/toolreference/have_i_been_pwned.de.md b/docs/content/connectors/toolreference/have_i_been_pwned.de.md new file mode 100644 index 00000000000..5989bfd597b --- /dev/null +++ b/docs/content/connectors/toolreference/have_i_been_pwned.de.md @@ -0,0 +1,23 @@ +--- +title: "Have I Been Pwned" +description: "Einrichtung des Have I Been Pwned Upstream-Connectors für DefectDojo" +weight: 72 +audience: pro +--- +Der Have-I-Been-Pwned(HIBP)-Connector verwendet die HIBP-REST-API, um zu melden, welche Konten auf den eigenen Domains Ihrer Organisation in bekannten Datenpannen aufgetaucht sind. DefectDojo ermittelt jede von Ihnen bei HIBP verifizierte Domain und importiert einen Befund pro Datenpanne, die diese Domain betrifft. + +#### Voraussetzungen + +Sie benötigen einen Have-I-Been-Pwned-API-Schlüssel mit Domain-Suche, wofür mindestens ein **Core**-Abonnement erforderlich ist. Sie können einen Schlüssel über Ihr [Have-I-Been-Pwned-Konto](https://haveibeenpwned.com/API/Key) erhalten. + +Sie müssen außerdem **mindestens eine Domain verifizieren**, bevor Datenpannen-Daten verfügbar sind. HIBP ermöglicht die Verifizierung einer Domain per DNS-TXT-Eintrag, Meta-Tag, Datei-Upload oder E-Mail, unter **Domain search** in Ihrem Konto. Solange keine Domain verifiziert ist, ermittelt der Connector keine Domains und importiert keine Befunde. + +#### Connector-Zuordnungen + +1. Geben Sie `https://haveibeenpwned.com` in das Feld **Location** ein. +2. Geben Sie Ihren API-Schlüssel in das Feld **Secret** ein. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. + +DefectDojo erstellt für jede von Ihnen bei HIBP verifizierte Domain einen separaten Eintrag und importiert einen Befund pro Datenpanne, die Konten auf dieser Domain betrifft. Der Schweregrad jedes Befunds spiegelt die Art der durch die Datenpanne offengelegten Daten wider, und seine Beschreibung listet die betroffenen Konten auf Ihrer Domain auf, damit Ihr Team handeln kann. + +Weitere Informationen finden Sie in der [Have-I-Been-Pwned-API-Dokumentation](https://haveibeenpwned.com/API/v3). diff --git a/docs/content/connectors/toolreference/have_i_been_pwned.es.md b/docs/content/connectors/toolreference/have_i_been_pwned.es.md new file mode 100644 index 00000000000..25daed8626d --- /dev/null +++ b/docs/content/connectors/toolreference/have_i_been_pwned.es.md @@ -0,0 +1,23 @@ +--- +title: "Have I Been Pwned" +description: "Cómo configurar el Conector Upstream de Have I Been Pwned para DefectDojo" +weight: 72 +audience: pro +--- +El conector Have I Been Pwned (HIBP) usa la API REST de HIBP para informar de qué cuentas de los dominios propios de su organización han aparecido en filtraciones de datos conocidas. DefectDojo detecta cada dominio que haya verificado con HIBP e importa un hallazgo por cada filtración que afecte a ese dominio. + +#### Requisitos previos + +Necesitará una clave de API de Have I Been Pwned con búsqueda de dominio, lo que requiere un nivel de suscripción **Core** o superior. Puede obtener una clave desde su [cuenta de Have I Been Pwned](https://haveibeenpwned.com/API/Key). + +También debe **verificar al menos un dominio** en su cuenta de HIBP antes de que haya datos de filtraciones disponibles. HIBP permite verificar un dominio mediante registro TXT de DNS, metaetiqueta, carga de archivo o correo electrónico, en **Domain search** dentro de su cuenta. Hasta que un dominio esté verificado, el conector no detecta ningún dominio y no importa ningún hallazgo. + +#### Asignaciones del conector + +1. Introduzca `https://haveibeenpwned.com` en el campo **Location**. +2. Introduzca su clave de API en el campo **Secret**. +3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importarán. + +DefectDojo crea un Registro independiente para cada dominio que haya verificado con HIBP, e importa un hallazgo por cada filtración que afecte a las cuentas de ese dominio. La severidad de cada hallazgo refleja el tipo de datos que expuso la filtración, y su descripción enumera las cuentas afectadas de su dominio para que su equipo pueda actuar sobre ellas. + +Consulte la [documentación de la API de Have I Been Pwned](https://haveibeenpwned.com/API/v3) para obtener más información. diff --git a/docs/content/connectors/toolreference/have_i_been_pwned.fr.md b/docs/content/connectors/toolreference/have_i_been_pwned.fr.md new file mode 100644 index 00000000000..627239e07b7 --- /dev/null +++ b/docs/content/connectors/toolreference/have_i_been_pwned.fr.md @@ -0,0 +1,23 @@ +--- +title: "Have I Been Pwned" +description: "Comment configurer le Connecteur Upstream Have I Been Pwned pour DefectDojo" +weight: 72 +audience: pro +--- +Le connecteur Have I Been Pwned (HIBP) utilise l'API REST HIBP pour signaler quels comptes des domaines de votre propre organisation sont apparus dans des fuites de données connues. DefectDojo découvre chaque domaine que vous avez vérifié auprès de HIBP et importe une constatation par fuite affectant ce domaine. + +#### Prérequis + +Vous aurez besoin d'une clé API Have I Been Pwned avec recherche par domaine, ce qui nécessite un abonnement de niveau **Core** ou supérieur. Vous pouvez obtenir une clé depuis votre [compte Have I Been Pwned](https://haveibeenpwned.com/API/Key). + +Vous devez également **vérifier au moins un domaine** sur votre compte HIBP avant que des données de fuite soient disponibles. HIBP permet de vérifier un domaine par enregistrement DNS TXT, balise meta, téléversement de fichier ou e-mail, sous **Domain search** dans votre compte. Tant qu'aucun domaine n'est vérifié, le connecteur ne découvre aucun domaine et n'importe aucune constatation. + +#### Mappages du connecteur + +1. Saisissez `https://haveibeenpwned.com` dans le champ **Location**. +2. Saisissez votre clé API dans le champ **Secret**. +3. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. Les constatations en dessous de la sévérité sélectionnée ne seront pas importées. + +DefectDojo crée un Enregistrement distinct pour chaque domaine que vous avez vérifié auprès de HIBP, et importe une constatation par fuite affectant les comptes de ce domaine. La sévérité de chaque constatation reflète le type de données exposées par la fuite, et sa description répertorie les comptes affectés sur votre domaine afin que votre équipe puisse agir. + +Consultez la [documentation de l'API Have I Been Pwned](https://haveibeenpwned.com/API/v3) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/have_i_been_pwned.ja.md b/docs/content/connectors/toolreference/have_i_been_pwned.ja.md new file mode 100644 index 00000000000..7cedb7713d8 --- /dev/null +++ b/docs/content/connectors/toolreference/have_i_been_pwned.ja.md @@ -0,0 +1,23 @@ +--- +title: "Have I Been Pwned" +description: "DefectDojo で Have I Been Pwned の Upstream Connector をセットアップする方法" +weight: 72 +audience: pro +--- +Have I Been Pwned(HIBP)コネクタは、HIBP REST APIを使用して、組織自身のドメイン上のどのアカウントが既知のデータ漏洩に含まれているかを報告します。DefectDojoはHIBPで検証済みの各ドメインを検出し、そのドメインに影響する漏洩ごとに1件の検出事項をインポートします。 + +#### Prerequisites + +ドメイン検索機能付きのHave I Been Pwned APIキーが必要です。これには**Core**サブスクリプション以上のプランが必要です。キーは[Have I Been Pwnedアカウント](https://haveibeenpwned.com/API/Key)から取得できます。 + +また、漏洩データを利用できるようにするには、HIBPアカウントで**少なくとも1つのドメインを検証**する必要があります。HIBPでは、アカウントの**Domain search**セクションから、DNS TXTレコード、metaタグ、ファイルアップロード、またはメールでドメインを検証できます。ドメインが検証されるまで、コネクタはドメインを検出せず、検出事項もインポートされません。 + +#### Connector Mappings + +1. **Location**フィールドに`https://haveibeenpwned.com`を入力します。 +2. **Secret**フィールドにAPIキーを入力します。 +3. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。選択した深刻度を下回る検出事項はインポートされません。 + +DefectDojoは、HIBPで検証済みの各ドメインごとに個別のRecordを作成し、そのドメイン上のアカウントに影響する漏洩ごとに1件の検出事項をインポートします。各検出事項の深刻度は漏洩で公開されたデータの種類を反映し、説明にはあなたのドメイン上で影響を受けたアカウントが記載されるため、チームが対応を取ることができます。 + +詳細については、[Have I Been Pwned APIドキュメント](https://haveibeenpwned.com/API/v3)を参照してください。 diff --git a/docs/content/connectors/toolreference/have_i_been_pwned.md b/docs/content/connectors/toolreference/have_i_been_pwned.md new file mode 100644 index 00000000000..9379680b2e0 --- /dev/null +++ b/docs/content/connectors/toolreference/have_i_been_pwned.md @@ -0,0 +1,23 @@ +--- +title: "Have I Been Pwned" +description: "How to set up the Have I Been Pwned Upstream Connector for DefectDojo" +weight: 72 +audience: pro +--- +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. diff --git a/docs/content/connectors/toolreference/hcl_appscan.de.md b/docs/content/connectors/toolreference/hcl_appscan.de.md new file mode 100644 index 00000000000..be20a1359ba --- /dev/null +++ b/docs/content/connectors/toolreference/hcl_appscan.de.md @@ -0,0 +1,22 @@ +--- +title: "HCL AppScan" +description: "Einrichtung des HCL AppScan Upstream-Connectors für DefectDojo" +weight: 73 +audience: pro +--- +Der HCL-AppScan-Connector verwendet die AppScan-v4-REST-API, um Issues aus **AppScan on Cloud (ASoC)** oder einem selbstgehosteten **AppScan 360°** zu importieren (beide teilen sich die API). Er synchronisiert das gesamte Konto: DefectDojo ermittelt jede Anwendung und erstellt für jede einen Eintrag; anschließend werden die Issues dieser Anwendung (DAST, SAST und IAST) als Befunde importiert. + +#### Voraussetzungen + +Sie benötigen einen AppScan-**API-Schlüssel** — eine Key ID und ein Key Secret, generiert unter Ihren AppScan-Kontoeinstellungen (API Key). Der Connector tauscht diese bei jedem Lauf gegen ein kurzlebiges Session-Token ein; Key ID, Key Secret und Token werden nie protokolliert. + +#### Connector-Zuordnungen + +1. Geben Sie die AppScan-Konsolen-URL in das Feld **Location** ein: Verwenden Sie für ASoC `https://cloud.appscan.com` (oder `https://eu.cloud.appscan.com` für die EU-Region); verwenden Sie für AppScan 360° den Host Ihrer Instanz. +2. Setzen Sie **Provider** auf `ASOC` für AppScan on Cloud oder auf `A360` für ein selbstgehostetes AppScan 360°. +3. Geben Sie die **API Key ID** und das **API Key Secret** ein. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo ordnet jede AppScan-**Anwendung** einem Eintrag (VEP) zu und jedes **Issue** einem Befund: Der Titel ist der Issue-Typ mit angehängter Domain/Entität/Cause-ID/URL/Pfad; der Schweregrad bildet Informational auf Info ab (Low/Medium/High/Critical werden unverändert übernommen); die CWE, eine beschriftete Beschreibung, die Abhilfemaßnahme und der Hinweis sowie der Host/Port-Endpunkt werden übernommen. Issues aus statischer Analyse werden als statische Befunde erfasst und dynamische/interaktive Issues als dynamische Befunde; offene Issues sind aktiv, und behobene/bestandene Issues sind behoben. + +Weitere Informationen finden Sie in der [AppScan-REST-API-Dokumentation](https://help.hcl-software.com/appscan/ASoC/appseccloud_rest_apis.html). diff --git a/docs/content/connectors/toolreference/hcl_appscan.es.md b/docs/content/connectors/toolreference/hcl_appscan.es.md new file mode 100644 index 00000000000..4e4363421f1 --- /dev/null +++ b/docs/content/connectors/toolreference/hcl_appscan.es.md @@ -0,0 +1,22 @@ +--- +title: "HCL AppScan" +description: "Cómo configurar el Conector Upstream de HCL AppScan para DefectDojo" +weight: 73 +audience: pro +--- +El conector HCL AppScan usa la API REST v4 de AppScan para importar incidencias de **AppScan on Cloud (ASoC)** o de una instancia autoalojada de **AppScan 360°** (ambas comparten la API). Sincroniza toda la cuenta: DefectDojo detecta todas las aplicaciones y crea un Registro para cada una, y luego importa las incidencias de esa aplicación (DAST, SAST e IAST) como hallazgos. + +#### Requisitos previos + +Necesitará una **API key** de AppScan — un Key ID y un Key Secret generados en la configuración de su cuenta de AppScan (API Key). El conector los intercambia por un token de sesión de corta duración en cada ejecución; el Key ID, el Key Secret y el token nunca se registran en los logs. + +#### Asignaciones del conector + +1. Introduzca la URL de la consola de AppScan en el campo **Location**: para ASoC use `https://cloud.appscan.com` (o `https://eu.cloud.appscan.com` para la región de la UE); para AppScan 360° use el host de su instancia. +2. Establezca **Provider** en `ASOC` para AppScan on Cloud, o en `A360` para una instancia autoalojada de AppScan 360°. +3. Introduzca el **API Key ID** y el **API Key Secret**. +4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo asigna cada **aplicación** de AppScan a un Registro (VEP) y cada **incidencia** a un hallazgo: el título es el tipo de incidencia con su dominio/entidad/cause-id/URL/ruta añadidos; la severidad asigna Informational a Info (Low/Medium/High/Critical se transfieren sin cambios); se incluyen el CWE, una descripción etiquetada, la corrección y el aviso, y el endpoint de host/puerto. Las incidencias de análisis estático se registran como hallazgos estáticos y las incidencias dinámicas/interactivas como hallazgos dinámicos; las incidencias abiertas quedan activas y las corregidas/aprobadas quedan mitigadas. + +Consulte la [documentación de la API REST de AppScan](https://help.hcl-software.com/appscan/ASoC/appseccloud_rest_apis.html) para obtener más información. diff --git a/docs/content/connectors/toolreference/hcl_appscan.fr.md b/docs/content/connectors/toolreference/hcl_appscan.fr.md new file mode 100644 index 00000000000..7a85f5aa829 --- /dev/null +++ b/docs/content/connectors/toolreference/hcl_appscan.fr.md @@ -0,0 +1,22 @@ +--- +title: "HCL AppScan" +description: "Comment configurer le Connecteur Upstream HCL AppScan pour DefectDojo" +weight: 73 +audience: pro +--- +Le connecteur HCL AppScan utilise l'API REST AppScan v4 pour importer les issues depuis **AppScan on Cloud (ASoC)** ou une instance auto-hébergée **AppScan 360°** (les deux partagent la même API). Il synchronise l'ensemble du compte : DefectDojo découvre chaque application et crée un Enregistrement pour chacune, puis importe les issues de cette application (DAST, SAST et IAST) en tant que constatations. + +#### Prérequis + +Vous aurez besoin d'une **clé API** AppScan — un Key ID et un Key Secret générés dans les paramètres de votre compte AppScan (API Key). Le connecteur les échange contre un jeton de session de courte durée à chaque exécution ; le Key ID, le Key Secret et le jeton ne sont jamais journalisés. + +#### Mappages du connecteur + +1. Saisissez l'URL de la console AppScan dans le champ **Location** : pour ASoC, utilisez `https://cloud.appscan.com` (ou `https://eu.cloud.appscan.com` pour la région UE) ; pour AppScan 360°, utilisez l'hôte de votre instance. +2. Définissez **Provider** sur `ASOC` pour AppScan on Cloud, ou `A360` pour une instance AppScan 360° auto-hébergée. +3. Saisissez l'**API Key ID** et l'**API Key Secret**. +4. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. + +DefectDojo mappe chaque **application** AppScan à un Enregistrement (VEP) et chaque **issue** à une constatation : le titre est le type d'issue avec son domaine / entité / cause-id / URL / chemin ajouté ; la sévérité mappe Informational → Info (Low/Medium/High/Critical sont conservées telles quelles) ; le CWE, une description étiquetée, la remédiation et l'avis, ainsi que le point de terminaison hôte/port sont repris. Les issues issues de l'analyse statique sont enregistrées comme constatations statiques et les issues dynamiques/interactives comme constatations dynamiques ; les issues ouvertes sont actives et les issues corrigées/passées sont atténuées. + +Consultez la [documentation de l'API REST AppScan](https://help.hcl-software.com/appscan/ASoC/appseccloud_rest_apis.html) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/hcl_appscan.ja.md b/docs/content/connectors/toolreference/hcl_appscan.ja.md new file mode 100644 index 00000000000..dfb62c4ad0c --- /dev/null +++ b/docs/content/connectors/toolreference/hcl_appscan.ja.md @@ -0,0 +1,22 @@ +--- +title: "HCL AppScan" +description: "DefectDojo で HCL AppScan の Upstream Connector をセットアップする方法" +weight: 73 +audience: pro +--- +HCL AppScanコネクタは、AppScan v4 REST APIを使用して、**AppScan on Cloud(ASoC)**またはセルフホスト型の**AppScan 360°**(両者はAPIを共有しています)からissueをインポートします。アカウント全体を同期します。DefectDojoはすべてのアプリケーションを検出してそれぞれにRecordを作成し、そのアプリケーションのissue(DAST、SAST、IAST)を検出事項としてインポートします。 + +#### Prerequisites + +AppScanの**APIキー**が必要です — これはAppScanアカウント設定(API Key)で生成されるKey IDとKey Secretです。コネクタは実行ごとにこれらを短命のセッショントークンと交換します。Key ID、Key Secret、トークンはログに記録されません。 + +#### Connector Mappings + +1. **Location**フィールドにAppScanコンソールのURLを入力します。ASoCの場合は`https://cloud.appscan.com`(EUリージョンの場合は`https://eu.cloud.appscan.com`)、セルフホスト型のAppScan 360°の場合はインスタンスのホストを使用します。 +2. AppScan on Cloudの場合は**Provider**を`ASOC`に、セルフホスト型のAppScan 360°の場合は`A360`に設定します。 +3. **API Key ID**と**API Key Secret**を入力します。 +4. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。 + +DefectDojoは各AppScanの**application**をRecord(VEP)にマッピングし、各**issue**を検出事項にマッピングします。タイトルはissueの種類にドメイン/エンティティ/cause-id/URL/パスを付加したものになります。深刻度はInformational→情報にマッピングされます(Low/Medium/High/Criticalはそのまま渡されます)。CWE、ラベル付きの説明、修復方法とアドバイザリ、およびhost/portエンドポイントが引き継がれます。静的解析によるissueは静的検出事項として、動的/インタラクティブなissueは動的検出事項として記録され、openなissueはアクティブ、fixed/passedのissueは緩和済みになります。 + +詳細については、[AppScan REST APIドキュメント](https://help.hcl-software.com/appscan/ASoC/appseccloud_rest_apis.html)を参照してください。 diff --git a/docs/content/connectors/toolreference/hcl_appscan.md b/docs/content/connectors/toolreference/hcl_appscan.md new file mode 100644 index 00000000000..6ec7972ae5a --- /dev/null +++ b/docs/content/connectors/toolreference/hcl_appscan.md @@ -0,0 +1,22 @@ +--- +title: "HCL AppScan" +description: "How to set up the HCL AppScan Upstream Connector for DefectDojo" +weight: 73 +audience: pro +--- +The HCL AppScan connector uses the AppScan v4 REST API to import issues from **AppScan on Cloud (ASoC)** or a self-hosted **AppScan 360°** (both share the API). It syncs the whole account: DefectDojo discovers every application and creates a Record for each, then imports that application's issues (DAST, SAST and IAST) as findings. + +#### Prerequisites + +You will need an AppScan **API key** — a Key ID and Key Secret generated under your AppScan account settings (API Key). The connector exchanges them for a short-lived session token on each run; the Key ID, Key Secret and token are never logged. + +#### Connector Mappings + +1. Enter the AppScan console URL in the **Location** field: for ASoC use `https://cloud.appscan.com` (or `https://eu.cloud.appscan.com` for the EU region); for AppScan 360° use your instance host. +2. Set **Provider** to `ASOC` for AppScan on Cloud, or `A360` for a self-hosted AppScan 360°. +3. Enter the **API Key ID** and **API Key Secret**. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo maps each AppScan **application** to a Record (VEP) and each **issue** to a finding: the title is the issue type with its domain / entity / cause-id / URL / path appended; the severity maps Informational → Info (Low/Medium/High/Critical pass through); the CWE, a labeled description, the remediation and advisory, and the host/port endpoint are carried over. Issues from static analysis are recorded as static findings and dynamic/interactive issues as dynamic findings; open issues are active and fixed/passed issues are mitigated. + +See the [AppScan REST API documentation](https://help.hcl-software.com/appscan/ASoC/appseccloud_rest_apis.html) for more information. diff --git a/docs/content/connectors/toolreference/hiddenlayer.md b/docs/content/connectors/toolreference/hiddenlayer.md new file mode 100644 index 00000000000..db1819dbfc7 --- /dev/null +++ b/docs/content/connectors/toolreference/hiddenlayer.md @@ -0,0 +1,20 @@ +--- +title: "HiddenLayer" +description: "How to set up the HiddenLayer Upstream Connector for DefectDojo" +weight: 74 +audience: pro +--- +The HiddenLayer connector imports **AI/ML model scan findings** from HiddenLayer's Model Scanner. DefectDojo creates a Record for each **scanned model**. + +#### Prerequisites + +A HiddenLayer API **client ID and client secret**, created under **Model Scanner \> API Access**. DefectDojo exchanges them for a short\-lived bearer token on each Sync; the secret is never logged. + +#### Connector Mappings + +1. Enter your tenant's regional API URL in the **Location** field — `https://api.us.hiddenlayer.ai` or `https://api.eu.hiddenlayer.ai`. +2. Enter the client ID in the **Client ID** field. +3. Enter the client secret in the **Client Secret** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +HiddenLayer returns model scan results as **SARIF** logs, and DefectDojo maps them the same way it maps an uploaded SARIF report — so these findings behave like SARIF imports elsewhere in the Asset. diff --git a/docs/content/connectors/toolreference/holm_security.md b/docs/content/connectors/toolreference/holm_security.md new file mode 100644 index 00000000000..2bb0b225e9f --- /dev/null +++ b/docs/content/connectors/toolreference/holm_security.md @@ -0,0 +1,19 @@ +--- +title: "Holm Security" +description: "How to set up the Holm Security Upstream Connector for DefectDojo" +weight: 75 +audience: pro +--- +The Holm Security connector imports findings across **both** of Holm's asset classes — network/infrastructure scanning and web application scanning — through one connector. DefectDojo creates a Record for each **asset**. + +#### Prerequisites + +A Holm Security **API token**, from **Security Center \> API**. It is never logged. + +#### Connector Mappings + +1. Enter your **region's** API host in the **Location** field — for example `https://se-api.holmsecurity.com` for the Swedish region. Holm Security's API host is region\-specific, so this must match the region your account is in. +2. Enter the API token in the **API Token** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each asset becomes a Record, whether it was found by a network scan or a web scan. diff --git a/docs/content/connectors/toolreference/immuniweb.md b/docs/content/connectors/toolreference/immuniweb.md new file mode 100644 index 00000000000..e5de4233213 --- /dev/null +++ b/docs/content/connectors/toolreference/immuniweb.md @@ -0,0 +1,21 @@ +--- +title: "ImmuniWeb" +description: "How to set up the ImmuniWeb Upstream Connector for DefectDojo" +weight: 76 +audience: pro +--- +The ImmuniWeb connector imports **web application security findings** from ImmuniWeb. DefectDojo creates a Record for each **tested asset** (website) on the account. + +#### Prerequisites + +An ImmuniWeb **premium API key**. + +> **A premium key is required, even though ImmuniWeb treats its API key as optional.** Without one, ImmuniWeb **truncates the vulnerability list** it returns. DefectDojo requires the key rather than importing a silently incomplete set of findings — an import that under\-reports is worse than one that will not start. + +#### Connector Mappings + +1. Enter your ImmuniWeb API URL in the **Location** field. +2. Enter your premium API key in the **API Key** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each tested asset becomes a Record, carrying that asset's detected vulnerabilities. diff --git a/docs/content/connectors/toolreference/insightcloudsec.md b/docs/content/connectors/toolreference/insightcloudsec.md new file mode 100644 index 00000000000..9863c0a2f68 --- /dev/null +++ b/docs/content/connectors/toolreference/insightcloudsec.md @@ -0,0 +1,21 @@ +--- +title: "InsightCloudSec" +description: "How to set up the InsightCloudSec Upstream Connector for DefectDojo" +weight: 77 +audience: pro +--- +The InsightCloudSec connector imports **cloud security posture findings** from Rapid7 InsightCloudSec. DefectDojo creates a Record for each **onboarded cloud account**. + +**Please note:** InsightCloudSec (formerly DivvyCloud) is a **distinct Rapid7 product** from InsightVM and InsightAppSec, each of which has its own connector in this list. Make sure you are configuring the one that matches your Asset. + +#### Prerequisites + +An InsightCloudSec **API key**, from the **API Keys** page in your user profile. It is never logged. + +#### Connector Mappings + +1. Enter `https://cloudsec.insight.rapid7.com` in the **Location** field. Self\-hosted InsightCloudSec deployments use their own host. +2. Enter the API key in the **API Key** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +One finding is created per **insight and failing resource** pair, so a single policy failing across many resources produces a finding for each — grouped under the cloud account the resource belongs to. diff --git a/docs/content/connectors/toolreference/intigriti.de.md b/docs/content/connectors/toolreference/intigriti.de.md new file mode 100644 index 00000000000..a17d75e84f1 --- /dev/null +++ b/docs/content/connectors/toolreference/intigriti.de.md @@ -0,0 +1,21 @@ +--- +title: "Intigriti" +description: "Einrichtung des Intigriti Upstream-Connectors für DefectDojo" +weight: 78 +audience: pro +--- +Der Intigriti-Connector verwendet die externe Unternehmens-API von Intigriti, um Bug-Bounty-/Pentest-**Submissions** in DefectDojo zu übertragen. Er synchronisiert das gesamte Unternehmenskonto: DefectDojo ermittelt jedes Programm, auf das das Token zugreifen kann, und erstellt für jedes einen Eintrag; anschließend werden die Submissions dieses Programms als Befunde importiert. + +#### Voraussetzungen + +Sie benötigen ein Intigriti-**Company-API-Token**. Generieren Sie im Intigriti-Unternehmensportal unter **Company Settings > API** (Scope `company_external_api`) ein Zugriffstoken mit Lesezugriff auf Ihre Programme und Submissions. Ein dediziertes Token für DefectDojo wird empfohlen. Das Token wird als Bearer-Token gesendet und nie protokolliert. + +#### Connector-Zuordnungen + +1. Geben Sie die Basis-URL der externen Intigriti-Unternehmens-API in das Feld **Location** ein: `https://api.intigriti.com/external/company`. Die URL muss HTTPS verwenden. +2. Geben Sie das Unternehmens-API-Token in das Feld **Secret** ein. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo ordnet jedes Intigriti-**Programm** einem Eintrag zu und jede **Submission** einem Befund, mit dem Submission-Code als Schlüssel. Der Schweregrad des Befunds folgt der Bewertung von Intigriti (Exceptional/Critical → Critical, dann High/Medium/Low, ansonsten Informational), und der Lifecycle-Status der Submission wird auf den Befundstatus abgebildet: offene/in Triage befindliche Submissions sind aktiv, akzeptierte Submissions sind verifiziert, und geschlossene Submissions werden je nach Schließungsgrund zu behoben, einem Duplikat, außerhalb des Geltungsbereichs, falsch-positiv oder risikoakzeptiert. Die Befundbeschreibung übernimmt den Schwachstellentyp des Reports, das betroffene Asset, den Proof of Concept und die Antworten des Forschers. + +Weitere Informationen finden Sie in der [Intigriti-API-Dokumentation](https://kb.intigriti.com/en/articles/6117846-intigriti-api). diff --git a/docs/content/connectors/toolreference/intigriti.es.md b/docs/content/connectors/toolreference/intigriti.es.md new file mode 100644 index 00000000000..9a71613bc7c --- /dev/null +++ b/docs/content/connectors/toolreference/intigriti.es.md @@ -0,0 +1,21 @@ +--- +title: "Intigriti" +description: "Cómo configurar el Conector Upstream de Intigriti para DefectDojo" +weight: 78 +audience: pro +--- +El conector Intigriti usa la API externa de empresa de Intigriti para importar **envíos** de bug bounty / pentest a DefectDojo. Sincroniza toda la cuenta de la empresa: DefectDojo detecta todos los programas a los que el token puede acceder y crea un Registro para cada uno, luego importa los envíos de ese programa como hallazgos. + +#### Requisitos previos + +Necesitará un **token de API de empresa** de Intigriti. En el portal de empresa de Intigriti, en **Company Settings > API** (el ámbito `company_external_api`), genere un token de acceso con acceso de lectura a sus programas y envíos. Se recomienda un token dedicado para DefectDojo. El token se envía como Bearer token y nunca se registra en los logs. + +#### Asignaciones del conector + +1. Introduzca la URL base de la API externa de empresa de Intigriti en el campo **Location**: `https://api.intigriti.com/external/company`. La URL debe ser HTTPS. +2. Introduzca el token de API de empresa en el campo **Secret**. +3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo asigna cada **programa** de Intigriti a un Registro y cada **envío** a un hallazgo, identificado por el código del envío. La severidad del hallazgo sigue la calificación de Intigriti (Exceptional/Critical → Crítica, luego Alta/Media/Baja, o en caso contrario Informational), y el estado del ciclo de vida del envío se asigna al estado del hallazgo: los envíos open/triage están activos, los envíos accepted están verificados, y los envíos closed pasan a ser duplicado, fuera de alcance, falso positivo o riesgo aceptado según su motivo de cierre. La descripción del hallazgo incluye el tipo de vulnerabilidad del reporte, el activo afectado, la prueba de concepto y las respuestas del investigador. + +Consulte la [documentación de la API de Intigriti](https://kb.intigriti.com/en/articles/6117846-intigriti-api) para obtener más información. diff --git a/docs/content/connectors/toolreference/intigriti.fr.md b/docs/content/connectors/toolreference/intigriti.fr.md new file mode 100644 index 00000000000..f03e6166a25 --- /dev/null +++ b/docs/content/connectors/toolreference/intigriti.fr.md @@ -0,0 +1,21 @@ +--- +title: "Intigriti" +description: "Comment configurer le Connecteur Upstream Intigriti pour DefectDojo" +weight: 78 +audience: pro +--- +Le connecteur Intigriti utilise l'API externe Intigriti pour les entreprises afin d'importer dans DefectDojo les **soumissions** de bug bounty / pentest. Il synchronise l'ensemble du compte de l'entreprise : DefectDojo découvre chaque programme auquel le jeton peut accéder et crée un Enregistrement pour chacun, puis importe les soumissions de ce programme en tant que constatations. + +#### Prérequis + +Vous aurez besoin d'un **jeton API d'entreprise** Intigriti. Dans le portail entreprise Intigriti, sous **Company Settings > API** (le périmètre `company_external_api`), générez un jeton d'accès avec un accès en lecture à vos programmes et soumissions. Un jeton dédié pour DefectDojo est recommandé. Le jeton est envoyé en tant que jeton Bearer et n'est jamais journalisé. + +#### Mappages du connecteur + +1. Saisissez l'URL de base de l'API externe Intigriti pour les entreprises dans le champ **Location** : `https://api.intigriti.com/external/company`. L'URL doit être en HTTPS. +2. Saisissez le jeton API d'entreprise dans le champ **Secret**. +3. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. + +DefectDojo mappe chaque **programme** Intigriti à un Enregistrement et chaque **soumission** à une constatation, indexée par le code de la soumission. La sévérité de la constatation suit la notation Intigriti (Exceptional/Critical → Critique, puis High/Medium/Low, sinon Informational), et l'état du cycle de vie de la soumission se mappe au statut de la constatation : les soumissions ouvertes/en triage sont actives, les soumissions acceptées sont vérifiées, et les soumissions fermées deviennent atténuées, doublon, hors périmètre, faux positif ou risque accepté selon leur motif de fermeture. La description de la constatation reprend le type de vulnérabilité du rapport, l'actif affecté, la preuve de concept et les réponses du chercheur. + +Consultez la [documentation de l'API Intigriti](https://kb.intigriti.com/en/articles/6117846-intigriti-api) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/intigriti.ja.md b/docs/content/connectors/toolreference/intigriti.ja.md new file mode 100644 index 00000000000..1ed61da4874 --- /dev/null +++ b/docs/content/connectors/toolreference/intigriti.ja.md @@ -0,0 +1,21 @@ +--- +title: "Intigriti" +description: "DefectDojo で Intigriti の Upstream Connector をセットアップする方法" +weight: 78 +audience: pro +--- +Intigritiコネクタは、Intigritiの外部company APIを使用して、バグバウンティ/ペンテストの**submissions**をDefectDojoに取り込みます。companyアカウント全体を同期します。DefectDojoはトークンがアクセスできるすべてのプログラムを検出してそれぞれにRecordを作成し、そのプログラムのsubmissionを検出事項としてインポートします。 + +#### Prerequisites + +Intigritiの**company APIトークン**が必要です。Intigriti companyポータルの**Company Settings > API**(`company_external_api`スコープ)で、プログラムとsubmissionへの読み取りアクセス権を持つアクセストークンを生成します。DefectDojo専用のトークンを使用することをお勧めします。トークンはBearerトークンとして送信され、ログには記録されません。 + +#### Connector Mappings + +1. **Location**フィールドにIntigritiの外部company APIベースURLを入力します: `https://api.intigriti.com/external/company`。URLはHTTPSである必要があります。 +2. **Secret**フィールドにcompany APIトークンを入力します。 +3. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。 + +DefectDojoは各Intigritiの**program**をRecordに、各**submission**をsubmissionコードをキーとして検出事項にマッピングします。検出事項の深刻度はIntigritiの評価に従います(Exceptional/Critical→重大、続いてHigh/Medium/Low、それ以外はInformational)。submissionのライフサイクル状態は検出事項のステータスにマッピングされます — open/triageのsubmissionはアクティブ、acceptedのsubmissionは検証済み、closedのsubmissionはそのクローズ理由に応じて緩和済み、重複、対象外、誤検知、またはリスク受容済みになります。検出事項の説明には、レポートの脆弱性タイプ、影響を受けるアセット、証拠となるPoC(proof of concept)、および研究者の回答が記載されます。 + +詳細については、[Intigriti APIドキュメント](https://kb.intigriti.com/en/articles/6117846-intigriti-api)を参照してください。 diff --git a/docs/content/connectors/toolreference/intigriti.md b/docs/content/connectors/toolreference/intigriti.md new file mode 100644 index 00000000000..6985df73032 --- /dev/null +++ b/docs/content/connectors/toolreference/intigriti.md @@ -0,0 +1,21 @@ +--- +title: "Intigriti" +description: "How to set up the Intigriti Upstream Connector for DefectDojo" +weight: 78 +audience: pro +--- +The Intigriti connector uses the Intigriti external company API to pull bug-bounty / pentest **submissions** into DefectDojo. It syncs the whole company account: DefectDojo discovers every program the token can access and creates a Record for each, then imports that program's submissions as findings. + +#### Prerequisites + +You will need an Intigriti **company API token**. In the Intigriti company portal, under **Company Settings > API** (the `company_external_api` scope), generate an access token with read access to your programs and submissions. A dedicated token for DefectDojo is recommended. The token is sent as a Bearer token and is never logged. + +#### Connector Mappings + +1. Enter the Intigriti external company API base URL in the **Location** field: `https://api.intigriti.com/external/company`. The URL must be HTTPS. +2. Enter the company API token in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo maps each Intigriti **program** to a Record and each **submission** to a finding, keyed by the submission code. The finding severity follows Intigriti's rating (Exceptional/Critical → Critical, then High/Medium/Low, otherwise Informational), and the submission's lifecycle state maps to the finding's status: open/triage submissions are active, accepted submissions are verified, and closed submissions become mitigated, a duplicate, out-of-scope, false-positive or risk-accepted according to their close reason. The finding description carries the report's vulnerability type, affected asset, proof of concept and the researcher's answers. + +See the [Intigriti API documentation](https://kb.intigriti.com/en/articles/6117846-intigriti-api) for more information. diff --git a/docs/content/connectors/toolreference/intruder.de.md b/docs/content/connectors/toolreference/intruder.de.md new file mode 100644 index 00000000000..cb8aa7102f1 --- /dev/null +++ b/docs/content/connectors/toolreference/intruder.de.md @@ -0,0 +1,16 @@ +--- +title: "Intruder" +description: "Einrichtung des Intruder Upstream-Connectors für DefectDojo" +weight: 79 +audience: pro +--- +Der Intruder-Connector verwendet die [Intruder-REST-API](https://developers.intruder.io/), um den Status Ihres gesamten Kontos in DefectDojo zu übertragen. Jedes Intruder-**Target** wird als Eintrag (Produkt) ermittelt; jedes **Vorkommen** eines Issues auf einem Target wird zu einem Befund. + +#### Connector-Zuordnungen + +1. Lassen Sie das Feld **Location** auf `https://api.intruder.io/` (dem Standard-Intruder-API-Server). +2. Geben Sie ein Intruder-**API-Zugriffstoken** in das Feld **Secret** ein. + +Generieren Sie ein Zugriffstoken in Intruder unter **My account > API Access Tokens** (Sie benötigen Ihr Kontopasswort, um es zu erstellen, und das Token wird nur einmal angezeigt). Einzelheiten finden Sie in der [Intruder-API-Dokumentation](https://developers.intruder.io/docs/creating-an-access-token). + +Befunde werden pro Vorkommen abgeleitet: Der Schweregrad stammt aus dem Issue-Schweregrad, CVEs und CVSS aus dem Vorkommen, der Standort aus Target/Port, und ein zurückgestelltes (snoozed) Vorkommen wird als inaktiver Befund (falsch-positiv oder risikoakzeptiert) importiert. diff --git a/docs/content/connectors/toolreference/intruder.es.md b/docs/content/connectors/toolreference/intruder.es.md new file mode 100644 index 00000000000..3d46cff0187 --- /dev/null +++ b/docs/content/connectors/toolreference/intruder.es.md @@ -0,0 +1,16 @@ +--- +title: "Intruder" +description: "Cómo configurar el Conector Upstream de Intruder para DefectDojo" +weight: 79 +audience: pro +--- +El conector Intruder usa la [API REST de Intruder](https://developers.intruder.io/) para importar la postura de toda su cuenta a DefectDojo. Cada **destino** de Intruder se detecta como un Registro (Producto); cada **aparición** de una incidencia en un destino se convierte en un Hallazgo. + +#### Asignaciones del conector + +1. Deje el campo **Location** como `https://api.intruder.io/` (el servidor de API predeterminado de Intruder). +2. Introduzca un **token de acceso de API** de Intruder en el campo **Secret**. + +Genere un token de acceso en Intruder en **My account > API Access Tokens** (necesitará la contraseña de su cuenta para crearlo, y el token solo se muestra una vez). Consulte la [documentación de la API de Intruder](https://developers.intruder.io/docs/creating-an-access-token) para más detalles. + +Los hallazgos se derivan por aparición: la severidad proviene de la severidad de la incidencia, los CVE y CVSS de la aparición, la ubicación del destino/puerto, y una aparición en estado "snoozed" se importa como un hallazgo inactivo (falso positivo o riesgo aceptado). diff --git a/docs/content/connectors/toolreference/intruder.fr.md b/docs/content/connectors/toolreference/intruder.fr.md new file mode 100644 index 00000000000..58d64eb5885 --- /dev/null +++ b/docs/content/connectors/toolreference/intruder.fr.md @@ -0,0 +1,16 @@ +--- +title: "Intruder" +description: "Comment configurer le Connecteur Upstream Intruder pour DefectDojo" +weight: 79 +audience: pro +--- +Le connecteur Intruder utilise l'[API REST Intruder](https://developers.intruder.io/) pour importer dans DefectDojo la posture de l'ensemble de votre compte. Chaque **cible** Intruder est découverte comme un Enregistrement (Produit) ; chaque **occurrence** d'une issue sur une cible devient une Constatation. + +#### Mappages du connecteur + +1. Laissez le champ **Location** à `https://api.intruder.io/` (le serveur API Intruder par défaut). +2. Saisissez un **jeton d'accès API** Intruder dans le champ **Secret**. + +Générez un jeton d'accès dans Intruder sous **My account > API Access Tokens** (vous aurez besoin du mot de passe de votre compte pour le créer, et le jeton n'est affiché qu'une seule fois). Consultez la [documentation de l'API Intruder](https://developers.intruder.io/docs/creating-an-access-token) pour plus de détails. + +Les constatations sont dérivées par occurrence : la sévérité provient de la sévérité de l'issue, les CVE et le CVSS proviennent de l'occurrence, l'emplacement provient de la cible/du port, et une occurrence mise en sommeil (snoozed) est importée comme une constatation inactive (faux positif ou risque accepté). diff --git a/docs/content/connectors/toolreference/intruder.ja.md b/docs/content/connectors/toolreference/intruder.ja.md new file mode 100644 index 00000000000..f35c84d3741 --- /dev/null +++ b/docs/content/connectors/toolreference/intruder.ja.md @@ -0,0 +1,16 @@ +--- +title: "Intruder" +description: "DefectDojo で Intruder の Upstream Connector をセットアップする方法" +weight: 79 +audience: pro +--- +Intruderコネクタは、[Intruder REST API](https://developers.intruder.io/)を使用して、アカウント全体のセキュリティ状況をDefectDojoに取り込みます。各Intruderの**target**はRecord(Product)として検出され、target上のissueの各**occurrence**がFindingになります。 + +#### Connector Mappings + +1. **Location**フィールドは`https://api.intruder.io/`(デフォルトのIntruder APIサーバー)のままにしておきます。 +2. **Secret**フィールドにIntruderの**APIアクセストークン**を入力します。 + +Intruderの**My account > API Access Tokens**でアクセストークンを生成します(作成にはアカウントパスワードが必要で、トークンは一度しか表示されません)。詳細は[Intruder APIドキュメント](https://developers.intruder.io/docs/creating-an-access-token)を参照してください。 + +検出事項はoccurrenceごとに導出されます。深刻度はissueの深刻度から、CVEとCVSSはoccurrenceから、locationはtarget/portから取得され、snooze(一時停止)されたoccurrenceは非アクティブ(誤検知またはリスク受容済み)な検出事項としてインポートされます。 diff --git a/docs/content/connectors/toolreference/intruder.md b/docs/content/connectors/toolreference/intruder.md new file mode 100644 index 00000000000..ab7019d2ab2 --- /dev/null +++ b/docs/content/connectors/toolreference/intruder.md @@ -0,0 +1,16 @@ +--- +title: "Intruder" +description: "How to set up the Intruder Upstream Connector for DefectDojo" +weight: 79 +audience: pro +--- +The Intruder connector uses the [Intruder REST API](https://developers.intruder.io/) to pull your whole account's posture into DefectDojo. Each Intruder **target** is discovered as a Record (Asset); each **occurrence** of an issue on a target becomes a Finding. + +#### Connector Mappings + +1. Leave the **Location** field as `https://api.intruder.io/` (the default Intruder API server). +2. Enter an Intruder **API access token** in the **Secret** field. + +Generate an access token in Intruder under **My account > API Access Tokens** (you'll need your account password to create it, and the token is shown only once). See the [Intruder API documentation](https://developers.intruder.io/docs/creating-an-access-token) for details. + +Findings are derived per occurrence: severity comes from the issue severity, CVEs and CVSS from the occurrence, the location from the target/port, and a snoozed occurrence is imported as an inactive (false-positive or risk-accepted) finding. diff --git a/docs/content/connectors/toolreference/iriusrisk.de.md b/docs/content/connectors/toolreference/iriusrisk.de.md new file mode 100644 index 00000000000..47c3c1f146c --- /dev/null +++ b/docs/content/connectors/toolreference/iriusrisk.de.md @@ -0,0 +1,25 @@ +--- +title: "IriusRisk" +description: "Einrichtung des IriusRisk Upstream-Connectors für DefectDojo" +weight: 80 +audience: pro +--- +Der IriusRisk-Connector verwendet ein API-Token, um Threat-Modeling-Daten aus Ihrer IriusRisk-Instanz abzurufen. + +#### Voraussetzungen + +Sie benötigen ein API-Token aus Ihrem IriusRisk-Konto. Wir empfehlen, für DefectDojo ein dediziertes Service-Konto anzulegen, um automatisierte Aktivitäten klar von manuellen Team-Aktionen zu unterscheiden. + +So generieren Sie ein API-Token in IriusRisk: + +1. Melden Sie sich bei Ihrer IriusRisk-Instanz an. +2. Navigieren Sie zu Ihrem **User Profile** im Menü oben rechts. +3. Wählen Sie **API Token** und generieren Sie ein neues Token. + +Weitere Informationen finden Sie in der [IriusRisk-API-Dokumentation](https://support.iriusrisk.com/hc/en-us/categories/360001148511). + +#### Connector-Zuordnungen + +1. Geben Sie die URL Ihrer IriusRisk-Instanz in das Feld **Location URL** ein. Bei Cloud-gehosteten Instanzen ist dies typischerweise `https://{your-subdomain}.iriusrisk.com`. Verwenden Sie bei On-Premise-Installationen die Basis-URL Ihrer Instanz. +2. Geben Sie Ihr **API Token** in das Feld **Secret** ein. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. diff --git a/docs/content/connectors/toolreference/iriusrisk.es.md b/docs/content/connectors/toolreference/iriusrisk.es.md new file mode 100644 index 00000000000..467afbe24d8 --- /dev/null +++ b/docs/content/connectors/toolreference/iriusrisk.es.md @@ -0,0 +1,25 @@ +--- +title: "IriusRisk" +description: "Cómo configurar el Conector Upstream de IriusRisk para DefectDojo" +weight: 80 +audience: pro +--- +El conector IriusRisk usa un token de API para importar datos de modelado de amenazas desde su instancia de IriusRisk. + +#### Requisitos previos + +Necesitará un token de API de su cuenta de IriusRisk. Recomendamos crear una cuenta de servicio dedicada para DefectDojo, de modo que se distinga claramente la actividad automatizada de las acciones manuales del equipo. + +Para generar un token de API en IriusRisk: + +1. Inicie sesión en su instancia de IriusRisk. +2. Vaya a su **User Profile** en el menú superior derecho. +3. Seleccione **API Token** y genere un nuevo token. + +Consulte la [documentación de la API de IriusRisk](https://support.iriusrisk.com/hc/en-us/categories/360001148511) para obtener más información. + +#### Asignaciones del conector + +1. Introduzca la URL de su instancia de IriusRisk en el campo **Location URL**. Para instancias alojadas en la nube, suele ser `https://{your-subdomain}.iriusrisk.com`. Para instalaciones locales, use la URL base de su instancia. +2. Introduzca su **API Token** en el campo **Secret**. +3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importarán. diff --git a/docs/content/connectors/toolreference/iriusrisk.fr.md b/docs/content/connectors/toolreference/iriusrisk.fr.md new file mode 100644 index 00000000000..cef41be35de --- /dev/null +++ b/docs/content/connectors/toolreference/iriusrisk.fr.md @@ -0,0 +1,25 @@ +--- +title: "IriusRisk" +description: "Comment configurer le Connecteur Upstream IriusRisk pour DefectDojo" +weight: 80 +audience: pro +--- +Le connecteur IriusRisk utilise un jeton API pour importer les données de modélisation de menaces de votre instance IriusRisk. + +#### Prérequis + +Vous aurez besoin d'un jeton API provenant de votre compte IriusRisk. Nous recommandons de créer un compte de service dédié pour DefectDojo afin de bien distinguer l'activité automatisée des actions manuelles de l'équipe. + +Pour générer un jeton API dans IriusRisk : + +1. Connectez-vous à votre instance IriusRisk. +2. Accédez à votre **User Profile** dans le menu en haut à droite. +3. Sélectionnez **API Token** et générez un nouveau jeton. + +Consultez la [documentation de l'API IriusRisk](https://support.iriusrisk.com/hc/en-us/categories/360001148511) pour plus d'informations. + +#### Mappages du connecteur + +1. Saisissez l'URL de votre instance IriusRisk dans le champ **Location URL**. Pour les instances hébergées dans le cloud, il s'agit généralement de `https://{your-subdomain}.iriusrisk.com`. Pour les installations sur site, utilisez l'URL de base de votre instance. +2. Saisissez votre **jeton API** dans le champ **Secret**. +3. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. Les constatations en dessous de la sévérité sélectionnée ne seront pas importées. diff --git a/docs/content/connectors/toolreference/iriusrisk.ja.md b/docs/content/connectors/toolreference/iriusrisk.ja.md new file mode 100644 index 00000000000..39a85142150 --- /dev/null +++ b/docs/content/connectors/toolreference/iriusrisk.ja.md @@ -0,0 +1,25 @@ +--- +title: "IriusRisk" +description: "DefectDojo で IriusRisk の Upstream Connector をセットアップする方法" +weight: 80 +audience: pro +--- +IriusRiskコネクタは、APIトークンを使用して、お使いのIriusRiskインスタンスから脅威モデリングデータを取り込みます。 + +#### Prerequisites + +IriusRiskアカウントのAPIトークンが必要です。自動化された操作を手動のチーム操作と明確に区別できるよう、DefectDojo専用のサービスアカウントを作成することをお勧めします。 + +IriusRiskでAPIトークンを生成するには: + +1. IriusRiskインスタンスにログインします。 +2. 右上のメニューから**User Profile**に移動します。 +3. **API Token**を選択し、新しいトークンを生成します。 + +詳細については、[IriusRisk APIドキュメント](https://support.iriusrisk.com/hc/en-us/categories/360001148511)を参照してください。 + +#### Connector Mappings + +1. **Location URL**フィールドにIriusRiskインスタンスのURLを入力します。クラウドホスト型インスタンスの場合、通常は`https://{your-subdomain}.iriusrisk.com`です。オンプレミス環境の場合は、インスタンスのベースURLを使用してください。 +2. **Secret**フィールドに**API Token**を入力します。 +3. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。選択した深刻度を下回る検出事項はインポートされません。 diff --git a/docs/content/connectors/toolreference/iriusrisk.md b/docs/content/connectors/toolreference/iriusrisk.md new file mode 100644 index 00000000000..6ef94309aef --- /dev/null +++ b/docs/content/connectors/toolreference/iriusrisk.md @@ -0,0 +1,25 @@ +--- +title: "IriusRisk" +description: "How to set up the IriusRisk Upstream Connector for DefectDojo" +weight: 80 +audience: pro +--- +The IriusRisk connector uses an API token to pull threat modeling data from your IriusRisk instance. + +#### Prerequisites + +You will need an API token from your IriusRisk account. We recommend creating a dedicated service account for DefectDojo to clearly distinguish automated activity from manual team actions. + +To generate an API token in IriusRisk: + +1. Log in to your IriusRisk instance. +2. Navigate to your **User Profile** in the top-right menu. +3. Select **API Token** and generate a new token. + +See the [IriusRisk API documentation](https://support.iriusrisk.com/hc/en-us/categories/360001148511) for more information. + +#### Connector Mappings + +1. Enter your IriusRisk instance URL in the **Location URL** field. For cloud-hosted instances this is typically `https://{your-subdomain}.iriusrisk.com`. For on-premise installations, use your instance's base URL. +2. Enter your **API Token** 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. diff --git a/docs/content/connectors/toolreference/jfrog_xray.de.md b/docs/content/connectors/toolreference/jfrog_xray.de.md new file mode 100644 index 00000000000..151bfaae7c2 --- /dev/null +++ b/docs/content/connectors/toolreference/jfrog_xray.de.md @@ -0,0 +1,73 @@ +--- +title: "JFrog Xray" +description: "Einrichtung des JFrog Xray Upstream-Connectors für DefectDojo" +weight: 81 +audience: pro +--- +Der JFrog-Xray-Connector verwendet die JFrog-Xray-REST-API, um Schwachstellendaten aus Ihren Artifactory-Repositories abzurufen. DefectDojo ermittelt alle Repositories in Ihrer JFrog-Instanz und erzeugt über Xray Schwachstellenberichte, wobei Befunde geplant importiert werden. + +#### Voraussetzungen + +Sie benötigen ein API-Token mit Zugriff auf sowohl die Artifactory- als auch die Xray-API. Wir empfehlen, für DefectDojo ein dediziertes Service-Konto anzulegen. Das Konto benötigt: + +* Lesezugriff auf Artifactory-Repositories +* Berechtigung, Xray-Schwachstellenberichte zu erzeugen und anzuzeigen (Berechtigung `Apply on Watches` in Xray oder gleichwertig) + +#### Connector-Zuordnungen + +1. Geben Sie die Basis-URL Ihrer JFrog-Instanz in das Feld **Location** ein. Dies sollte die Root-URL Ihrer JFrog-Instanz sein, zum Beispiel `https://your-instance.jfrog.io`. Geben Sie keinen abschließenden Pfad an — DefectDojo erstellt die passenden API-Pfade automatisch. +2. Geben Sie ein gültiges **Reference Token** in das Feld **Secret** ein. Tokens können unter **User Management \> Access Tokens** in der JFrog-Platform-Oberfläche generiert werden. +Sie müssen ein **Reference Token** generieren und diesen Wert verwenden. + +Erforderliche Token-Scopes für JFrog Xray: + +- **All Services**, da DefectDojo Zugriff sowohl auf den XRay- als auch auf den Artifactory-Dienst benötigt +- Mindestens **Manage Reports + Manage Resources**. + +Standardmäßig ordnet DefectDojo jedes Artifactory-**Repository** als separaten Eintrag zu. Jeder Sync erzeugt über Xray einen vollständigen Schwachstellenbericht pro Repository, sodass die Befundstatus in DefectDojo stets den aktuellen Zustand des Repositorys widerspiegeln. + +#### Repository-Filter (optional) + +Standardmäßig ermittelt der Connector **jedes** Repository in Ihrer JFrog-Instanz. Bei Instanzen mit einer großen Anzahl von Repositories — von denen viele für die Sicherheitsprüfung möglicherweise nicht relevant sind — kann die Ermittlung mit dem optionalen Feld **Repository Filter** unter **Import Filters** im Connector-Formular eingegrenzt werden. + +Der Filter wird während der Ermittlung angewendet, **bevor irgendeine Arbeit pro Repository erfolgt**. Ein Repository außerhalb des Filters verursacht keine Kosten: Für dieses wird kein Xray-Bericht erzeugt, und im Artefakt-Modus werden keine seiner Artefakte der ersten Ebene aufgelistet. Dies macht ihn zur effektivsten Methode, um sowohl die Sync-Zeit als auch die Last zu reduzieren, die DefectDojo auf Ihre JFrog-Instanz legt — mehr als jede später im Sync angewendete Einstellung. Er wird insbesondere in Kombination mit **Artifact-Level Records** bei großen Instanzen empfohlen. + +**Syntax:** eine kommagetrennte Liste von Repository-Schlüsseln. Jeder Eintrag kann `*`-Platzhalter verwenden: + +* Ein Eintrag, der `*` enthält, wird als Muster abgeglichen — `releases-*` erfasst jeden Repository-Schlüssel, der mit `releases-` beginnt, und `*docker-pr-local*` erfasst jeden Schlüssel, der `docker-pr-local` enthält. Ein `*` erfasst eine beliebige Zeichenfolge, auch `/`. +* Ein Eintrag ohne `*` muss einem Repository-Schlüssel **exakt** entsprechen. +* Ein Repository wird ermittelt, wenn es auf **einen beliebigen** Eintrag der Liste passt. Leerzeichen um Kommas werden ignoriert. + +``` +releases-*, snapshots +``` + +Das obige Beispiel ermittelt jedes Repository, dessen Schlüssel mit `releases-` beginnt, sowie das einzelne Repository mit dem exakten Namen `snapshots`. + +Hinweise: + +* Der Filter ist eine **Allow-Liste** — eine Übereinstimmung wählt ein Repository aus. Es gibt keine Ausschluss- oder Negationssyntax, sodass sich „alles außer X" nicht direkt ausdrücken lässt. +* Der Abgleich erfolgt **groß-/kleinschreibungssensitiv**, sowohl bei exakten Einträgen als auch bei Platzhaltern. `*` ist das einzige Platzhalterzeichen; `?` und Zeichenbereiche werden nicht unterstützt. +* **Leer lassen, um jedes Repository zu ermitteln.** Ein Wert, der nur aus Leerzeichen oder Kommas besteht, wird als leer behandelt. +* Ein Filter, der auf nichts passt, ermittelt einfach nichts — es gibt keine Fehlermeldung. Findet ein Sync unerwartet keine Repositories, prüfen Sie im Connector-Log den Eintrag `repository filter scoped discovery`, der meldet, wie viele der insgesamt vorhandenen Repositories getroffen wurden. +* Das Feld kann nach dem Erstellen der Verbindung geändert werden. + +**Den Filter später ändern:** Repositories, die ein neu eingeengter Filter jetzt ausschließt, werden nicht mehr ermittelt, und ihre bestehenden Einträge durchlaufen den normalen Lebenszyklus für Produkte, die das Tool nicht mehr meldet — **zugeordnete** Einträge werden beim nächsten Sync als `MISSING` markiert, und nicht zugeordnete `NEW`-Einträge werden entfernt. Bereits in DefectDojo importierte Befunde werden nicht gelöscht; der Filter steuert nur die Ermittlung. + +#### Artifact-Level Records + +Der Schalter **Artifact-Level Records** ändert die Ermittlung auf eine Ebene unterhalb des Repositorys: Jeder Eintrag der ersten Ebene unter einer Repository-Root (bei Docker-Repositories jedes Image; bei generischen Repositories jede Datei oder jeder Ordner der obersten Ebene) wird zu einem eigenen Eintrag. Jeder Sync erzeugt weiterhin einen einzigen Xray-Bericht pro Repository — DefectDojo ordnet jede Schwachstelle den Artefakten zu, die sie betrifft, sodass sich die Last auf Ihre JFrog-Instanz nicht erhöht. + +> **Prüfen Sie vor Ihrem ersten Sync, in welchem Modus Sie sich befinden.** Artifact-Level Records ist bei **Neuinstallationen standardmäßig aktiviert**. Installationen von vor Einführung dieser Funktion behalten ihr bestehendes Repository-Level-Layout bei, sodass der Schalter dort deaktiviert bleibt, bis ihn jemand einschaltet. In beiden Fällen kann der Schalter jederzeit geändert werden — siehe *Eine bestehende Verbindung umstellen* unten. + +Bei aktiviertem Artifact-Level Records: + +* Repositories bleiben als Einträge bestehen und werden zu **übergeordneten Assets**: Sie tragen selbst keine Befunde, aber wenn die Asset-Hierarchie-Funktion aktiviert ist, verknüpft DefectDojo jedes Artefakt-Asset automatisch mit einer `parent`-Beziehung mit seinem Repository-Asset. Assets können dann nach Parent/Child gefiltert werden, und Befunde werden in der Hierarchie nach oben aggregiert. +* Eine Schwachstelle, die mehrere Artefakte betrifft, wird in das Asset jedes betroffenen Artefakts importiert, sodass jedes Asset die vollständige Menge der es betreffenden Befunde zeigt. +* Befunde beziehen sich auf den **neuesten Build** jedes Artefakts, sodass die Befunde eines Artefakts dessen aktuellen Build beschreiben, statt Ergebnisse aus jedem von Xray je gescannten Build anzusammeln. +* Von diesem Connector erzeugte Hierarchiebeziehungen überschreiben nie von Ihnen manuell erstellte Beziehungen. Hat ein Asset bereits einen von Ihnen zugewiesenen Parent, lässt der Connector ihn unangetastet. +* Das Token benötigt zusätzlich Lesezugriff auf die Artifactory-Storage-API (in den obigen Scopes enthalten). + +**Eine bestehende Verbindung auf Artifact-Level Records umstellen:** Der Schalter kann jederzeit geändert werden. Beim ersten Sync danach erscheinen neue Artefakt-Einträge zur Zuordnung — aktivieren Sie **Auto Map** für die Verbindung beim Umschalten, damit Befunde ohne Lücke übertragen werden. Die Repository-Level-Assets erhalten keine Befunde mehr, und ihre zuvor importierten Befunde werden beim nächsten Sync geschlossen (dieselben Befunde werden mit neuem Status unter den neuen Artefakt-Assets erneut importiert); Notizen und Historie zu den alten Repository-Level-Befunden bleiben am Repository-Asset erhalten. Ein Zurückschalten kehrt dies um: Repository-Einträge tragen wieder Befunde (zuvor geschlossene Befunde werden bei erneuter Übereinstimmung wieder geöffnet), und Artefakt-Einträge werden als MISSING markiert — ihre Assets und Befunde bleiben erhalten, erhalten aber keine Updates mehr, sodass Sie sie nach Belieben archivieren können. + +Weitere Informationen finden Sie in der [JFrog-Xray-REST-API-Dokumentation](https://jfrog.com/help/r/jfrog-rest-apis/xray-rest-apis). diff --git a/docs/content/connectors/toolreference/jfrog_xray.es.md b/docs/content/connectors/toolreference/jfrog_xray.es.md new file mode 100644 index 00000000000..e67ab2c0fb8 --- /dev/null +++ b/docs/content/connectors/toolreference/jfrog_xray.es.md @@ -0,0 +1,73 @@ +--- +title: "JFrog Xray" +description: "Cómo configurar el Conector Upstream de JFrog Xray para DefectDojo" +weight: 81 +audience: pro +--- +El conector JFrog Xray usa la API REST de JFrog Xray para obtener datos de vulnerabilidades de sus repositorios de Artifactory. DefectDojo detectará todos los repositorios de su instancia de JFrog y generará informes de vulnerabilidades mediante Xray, importando hallazgos de forma programada. + +#### Requisitos previos + +Necesitará un token de API con acceso tanto a la API de Artifactory como a la de Xray. Recomendamos crear una cuenta de servicio dedicada para DefectDojo. La cuenta requiere: + +* Acceso de lectura a los repositorios de Artifactory +* Permiso para generar y ver informes de vulnerabilidades de Xray (permiso `Apply on Watches` en Xray, o equivalente) + +#### Asignaciones del conector + +1. Introduzca la URL base de su instancia de JFrog en el campo **Location**. Debe ser la URL raíz de su instancia de JFrog, por ejemplo `https://your-instance.jfrog.io`. No incluya una ruta final — DefectDojo construirá automáticamente las rutas de API correspondientes. +2. Introduzca un **Reference Token** válido en el campo **Secret**. Los tokens se pueden generar en **User Management > Access Tokens** en la interfaz de JFrog Platform. +Deberá generar un **Reference Token** y usar ese valor. + +Ámbitos de token necesarios para JFrog Xray: + +- **All Services**, ya que DefectDojo necesita acceso tanto a los servicios de XRay como de Artifactory +- **Manage Reports + Manage Resources** como mínimo. + +De forma predeterminada, DefectDojo asigna cada **repositorio** de Artifactory como un Registro independiente. Cada Sincronización genera un informe de vulnerabilidades completo por repositorio mediante Xray, de modo que los estados de los hallazgos en DefectDojo siempre reflejan el estado actual del repositorio. + +#### Filtro de repositorio (opcional) + +De forma predeterminada, el conector detecta **todos** los repositorios de su instancia de JFrog. En instancias con un gran número de repositorios — muchos de los cuales pueden no ser relevantes para la revisión de seguridad —, la detección se puede limitar con el campo opcional **Repository Filter**, en **Import Filters** en el formulario del conector. + +El filtro se aplica durante la detección, **antes de realizar cualquier trabajo por repositorio**. Un repositorio fuera del filtro no tiene ningún coste: no se genera ningún informe de Xray para él y, en el modo de artefactos, no se enumera ninguno de sus artefactos de primer nivel. Esto lo convierte en la forma más eficaz de reducir tanto el tiempo de Sincronización como la carga que DefectDojo impone a su instancia de JFrog — más que cualquier ajuste aplicado más adelante en la Sincronización. Se recomienda especialmente junto con **Artifact-Level Records** en instancias grandes. + +**Sintaxis:** una lista de claves de repositorio separadas por comas. Cada entrada puede usar comodines `*`: + +* Una entrada que contenga `*` se compara como un patrón — `releases-*` coincide con toda clave de repositorio que comience por `releases-`, y `*docker-pr-local*` coincide con cualquier clave que contenga `docker-pr-local`. Un `*` coincide con cualquier secuencia de caracteres, incluido `/`. +* Una entrada sin `*` debe coincidir **exactamente** con una clave de repositorio. +* Un repositorio se detecta si coincide con **cualquier** entrada de la lista. Los espacios alrededor de las comas se ignoran. + +``` +releases-*, snapshots +``` + +El ejemplo anterior detecta todos los repositorios cuya clave comience por `releases-`, más el único repositorio llamado exactamente `snapshots`. + +Notas: + +* El filtro es una **lista de permitidos** (allow-list) — una coincidencia selecciona un repositorio. No existe sintaxis de exclusión o negación, por lo que no se puede expresar directamente "todo excepto X". +* La comparación es **sensible a mayúsculas y minúsculas**, tanto para entradas exactas como para comodines. `*` es el único carácter comodín; `?` y los rangos de caracteres no son compatibles. +* **Déjelo en blanco para detectar todos los repositorios.** Un valor que solo contiene espacios o comas se trata como en blanco. +* Un filtro que no coincide con nada simplemente no detecta nada — no se produce ningún error. Si una Sincronización no encuentra repositorios inesperadamente, revise el log del conector en busca de la entrada `repository filter scoped discovery`, que indica cuántos de los repositorios totales coincidieron. +* El campo se puede modificar después de crear la conexión. + +**Cambiar el filtro más adelante:** los repositorios que un filtro recién restringido ya no incluye dejan de detectarse, y sus Registros existentes siguen el ciclo de vida normal de los productos que la herramienta ya no reporta — los Registros **mapeados** se marcan como `MISSING` en la siguiente Sincronización, y los Registros `NEW` sin mapear se eliminan. Los hallazgos ya importados en DefectDojo no se eliminan; el filtro solo rige la detección. + +#### Registros a nivel de artefacto + +El interruptor **Artifact-Level Records** cambia la detección a un nivel por debajo del repositorio: cada entrada de primer nivel bajo la raíz de un repositorio (para repositorios Docker, cada imagen; para repositorios genéricos, cada archivo o carpeta de nivel superior) se convierte en su propio Registro. Cada Sincronización sigue generando un único informe de Xray por repositorio — DefectDojo atribuye cada vulnerabilidad a los artefactos a los que afecta, de modo que la carga sobre su instancia de JFrog no aumenta. + +> **Compruebe en qué modo se encuentra antes de su primera Sincronización.** Artifact-Level Records está **activado de forma predeterminada para las instalaciones nuevas**. Las instalaciones anteriores a esta función conservan su diseño existente a nivel de repositorio, por lo que el interruptor permanece desactivado hasta que alguien lo active. En ambos casos, el interruptor se puede cambiar en cualquier momento — consulte *Cambiar una conexión existente* más abajo. + +Con Artifact-Level Records habilitado: + +* Los repositorios permanecen como Registros y se convierten en **activos principales**: no contienen hallazgos propios, pero cuando la función Asset Hierarchy está habilitada, DefectDojo relaciona automáticamente cada activo de artefacto con su activo de repositorio mediante una relación `parent`. Los activos se pueden filtrar entonces por elemento principal/secundario, y los hallazgos se propagan hacia arriba en la jerarquía. +* Una vulnerabilidad que afecta a varios artefactos se importa en el activo de cada artefacto afectado, de modo que cada activo muestra el conjunto completo de hallazgos que le afectan. +* Los hallazgos se limitan a la **última build** de cada artefacto, de modo que los hallazgos de un artefacto describen su build actual en lugar de acumular resultados de todas las builds que Xray haya escaneado alguna vez. +* Las relaciones jerárquicas creadas por el conector nunca sobrescriben las relaciones que usted haya creado manualmente. Si un activo ya tiene un elemento principal asignado, el conector lo deja tal cual. +* El token necesita además acceso de lectura a la API de almacenamiento de Artifactory (incluido en los ámbitos anteriores). + +**Cambiar una conexión existente a Artifact-Level Records:** el interruptor se puede cambiar en cualquier momento. En la primera Sincronización posterior, aparecen nuevos Registros de artefactos para mapear — habilite **Auto Map** en la conexión al cambiar el interruptor para que los hallazgos se muevan sin interrupción. Los activos a nivel de repositorio dejan de recibir hallazgos y sus hallazgos importados previamente se cierran en su siguiente Sincronización (los mismos hallazgos se vuelven a importar bajo los nuevos activos de artefacto, con un estado nuevo); las notas y el historial de los hallazgos antiguos a nivel de repositorio permanecen en el activo de repositorio. Volver al modo anterior invierte esto: los Registros de repositorio vuelven a recibir hallazgos (los hallazgos previamente cerrados se reabren al volver a coincidir), y los Registros de artefacto se marcan como MISSING — sus activos y hallazgos se conservan pero dejan de actualizarse, por lo que puede archivarlos cuando le convenga. + +Consulte la [documentación de la API REST de JFrog Xray](https://jfrog.com/help/r/jfrog-rest-apis/xray-rest-apis) para obtener más información. diff --git a/docs/content/connectors/toolreference/jfrog_xray.fr.md b/docs/content/connectors/toolreference/jfrog_xray.fr.md new file mode 100644 index 00000000000..2b1a3f24ae1 --- /dev/null +++ b/docs/content/connectors/toolreference/jfrog_xray.fr.md @@ -0,0 +1,73 @@ +--- +title: "JFrog Xray" +description: "Comment configurer le Connecteur Upstream JFrog Xray pour DefectDojo" +weight: 81 +audience: pro +--- +Le connecteur JFrog Xray utilise l'API REST JFrog Xray pour récupérer les données de vulnérabilité de vos dépôts Artifactory. DefectDojo découvrira tous les dépôts de votre instance JFrog et générera des rapports de vulnérabilité via Xray, en important les constatations de façon planifiée. + +#### Prérequis + +Vous aurez besoin d'un jeton API ayant accès aux API Artifactory et Xray. Nous recommandons de créer un compte de service dédié pour DefectDojo. Le compte nécessite : + +* Un accès en lecture aux dépôts Artifactory +* La permission de générer et consulter les rapports de vulnérabilité Xray (permission `Apply on Watches` dans Xray, ou équivalent) + +#### Mappages du connecteur + +1. Saisissez l'URL de base de votre instance JFrog dans le champ **Location**. Il doit s'agir de l'URL racine de votre instance JFrog, par exemple `https://your-instance.jfrog.io`. N'incluez pas de chemin final — DefectDojo construira automatiquement les chemins d'API appropriés. +2. Saisissez un **Reference Token** valide dans le champ **Secret**. Les jetons peuvent être générés sous **User Management > Access Tokens** dans l'interface JFrog Platform. +Vous devrez générer un **Reference Token** et utiliser cette valeur. + +Portées de jeton requises pour JFrog Xray : + +- **All Services**, car DefectDojo a besoin d'accéder à la fois aux services XRay et Artifactory +- **Manage Reports + Manage Resources** au minimum. + +Par défaut, DefectDojo mappe chaque **dépôt** Artifactory comme un Enregistrement distinct. Chaque synchronisation génère un rapport de vulnérabilité complet par dépôt via Xray, de sorte que les statuts des constatations dans DefectDojo reflètent toujours l'état actuel du dépôt. + +#### Filtre de dépôt (optionnel) + +Par défaut, le connecteur découvre **tous** les dépôts de votre instance JFrog. Sur les instances comptant un grand nombre de dépôts — dont beaucoup peuvent ne pas être pertinents pour la revue de sécurité —, la découverte peut être limitée avec le champ optionnel **Repository Filter**, sous **Import Filters** sur le formulaire du connecteur. + +Le filtre est appliqué pendant la découverte, **avant que tout travail par dépôt ne soit effectué**. Un dépôt en dehors du filtre ne coûte rien : aucun rapport Xray n'est généré pour lui et, en mode artefact, aucun de ses artefacts de premier niveau n'est énuméré. C'est donc le moyen le plus efficace de réduire à la fois le temps de synchronisation et la charge que DefectDojo impose à votre instance JFrog — plus que tout paramètre appliqué plus tard dans la synchronisation. Il est particulièrement recommandé en complément des **Artifact-Level Records** sur les grandes instances. + +**Syntaxe :** une liste de clés de dépôt séparées par des virgules. Chaque entrée peut utiliser des jokers `*` : + +* Une entrée contenant `*` est traitée comme un motif — `releases-*` correspond à toute clé de dépôt commençant par `releases-`, et `*docker-pr-local*` correspond à toute clé contenant `docker-pr-local`. Un `*` correspond à toute suite de caractères, y compris `/`. +* Une entrée sans `*` doit correspondre **exactement** à une clé de dépôt. +* Un dépôt est découvert s'il correspond à **n'importe quelle** entrée de la liste. Les espaces autour des virgules sont ignorés. + +``` +releases-*, snapshots +``` + +L'exemple ci-dessus découvre tous les dépôts dont la clé commence par `releases-`, plus le seul dépôt nommé exactement `snapshots`. + +Remarques : + +* Le filtre est une **liste d'autorisation** — une correspondance sélectionne un dépôt. Il n'existe pas de syntaxe d'exclusion ou de négation, vous ne pouvez donc pas exprimer directement « tout sauf X ». +* La correspondance est **sensible à la casse**, aussi bien pour les entrées exactes que pour les jokers. `*` est le seul caractère joker ; `?` et les plages de caractères ne sont pas pris en charge. +* **Laissez-le vide pour découvrir tous les dépôts.** Une valeur composée uniquement d'espaces ou de virgules est traitée comme vide. +* Un filtre qui ne correspond à rien ne découvre simplement rien — il n'y a pas d'erreur. Si une synchronisation ne trouve inopinément aucun dépôt, vérifiez l'entrée `repository filter scoped discovery` dans le journal du connecteur, qui indique combien de dépôts sur le total ont correspondu. +* Le champ peut être modifié après la création de la connexion. + +**Modifier le filtre ultérieurement :** les dépôts qu'un filtre nouvellement restreint exclut désormais ne sont plus découverts, et leurs Enregistrements existants suivent le cycle de vie normal des produits que l'outil ne signale plus — les Enregistrements **mappés** sont marqués `MISSING` lors de la synchronisation suivante, et les Enregistrements `NEW` non mappés sont supprimés. Les constatations déjà importées dans DefectDojo ne sont pas supprimées ; le filtre régit uniquement la découverte. + +#### Enregistrements au niveau des artefacts + +Le bouton **Artifact-Level Records** modifie la découverte pour descendre d'un niveau sous le dépôt : chaque entrée de premier niveau sous la racine d'un dépôt (pour les dépôts Docker, chaque image ; pour les dépôts génériques, chaque fichier ou dossier de premier niveau) devient son propre Enregistrement. Chaque synchronisation génère toujours un seul rapport Xray par dépôt — DefectDojo attribue chaque vulnérabilité aux artefacts qu'elle impacte, de sorte que la charge sur votre instance JFrog n'augmente pas. + +> **Vérifiez dans quel mode vous vous trouvez avant votre première synchronisation.** Artifact-Level Records est **activé par défaut pour les nouvelles installations**. Les installations antérieures à cette fonctionnalité conservent leur disposition existante au niveau du dépôt, le bouton est donc désactivé pour elles jusqu'à ce que quelqu'un l'active. Dans les deux cas, le bouton peut être modifié à tout moment — voir *Basculer une connexion existante* ci-dessous. + +Avec Artifact-Level Records activé : + +* Les dépôts restent des Enregistrements et deviennent des **actifs parents** : ils ne portent aucune constatation eux-mêmes, mais lorsque la fonctionnalité Asset Hierarchy est activée, DefectDojo relie automatiquement chaque actif artefact à son actif dépôt avec une relation `parent`. Les actifs peuvent alors être filtrés par parent/enfant, et les constatations remontent la hiérarchie. +* Une vulnérabilité qui impacte plusieurs artefacts est importée dans l'actif de chaque artefact affecté, de sorte que chaque actif affiche l'ensemble complet des constatations qui le concernent. +* Les constatations sont limitées à la **dernière build** de chaque artefact, de sorte que les constatations d'un artefact décrivent sa build actuelle plutôt que d'accumuler les résultats de toutes les builds que Xray a jamais analysées. +* Les relations hiérarchiques créées par le connecteur n'écrasent jamais les relations que vous avez créées manuellement. Si un actif a déjà un parent que vous avez attribué, le connecteur le laisse tel quel. +* Le jeton nécessite en plus un accès en lecture à l'API de stockage Artifactory (inclus dans les portées ci-dessus). + +**Basculer une connexion existante vers Artifact-Level Records :** le bouton peut être modifié à tout moment. Lors de la synchronisation suivante, de nouveaux Enregistrements d'artefacts apparaissent pour le mappage — activez **Auto Map** sur la connexion lors du basculement pour que les constatations soient transférées sans interruption. Les actifs au niveau du dépôt cessent de recevoir des constatations et leurs constatations précédemment importées sont fermées lors de leur prochaine synchronisation (les mêmes constatations sont réimportées sous les nouveaux actifs artefacts, avec un statut actualisé) ; les notes et l'historique des anciennes constatations au niveau du dépôt restent sur l'actif dépôt. Revenir en arrière inverse ce processus : les Enregistrements de dépôt recommencent à porter des constatations (les constatations précédemment fermées se rouvrent lorsqu'elles correspondent à nouveau), et les Enregistrements d'artefacts sont marqués MISSING — leurs actifs et constatations sont conservés mais cessent d'être mis à jour, afin que vous puissiez les archiver à votre convenance. + +Consultez la [documentation de l'API REST JFrog Xray](https://jfrog.com/help/r/jfrog-rest-apis/xray-rest-apis) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/jfrog_xray.ja.md b/docs/content/connectors/toolreference/jfrog_xray.ja.md new file mode 100644 index 00000000000..379dfbd7ace --- /dev/null +++ b/docs/content/connectors/toolreference/jfrog_xray.ja.md @@ -0,0 +1,73 @@ +--- +title: "JFrog Xray" +description: "DefectDojo で JFrog Xray の Upstream Connector をセットアップする方法" +weight: 81 +audience: pro +--- +JFrog Xrayコネクタは、JFrog Xray REST APIを使用して、Artifactoryリポジトリから脆弱性データを取得します。DefectDojoはJFrogインスタンス内のすべてのリポジトリを検出し、Xray経由で脆弱性レポートを生成して、スケジュールに基づいて検出事項をインポートします。 + +#### Prerequisites + +ArtifactoryとXrayの両方のAPIにアクセスできるAPIトークンが必要です。DefectDojo専用のサービスアカウントの作成をお勧めします。このアカウントには以下が必要です。 + +* Artifactoryリポジトリへの読み取りアクセス +* Xrayの脆弱性レポートを生成・閲覧する権限(Xrayの`Apply on Watches`権限、またはそれに相当するもの) + +#### Connector Mappings + +1. **Location**フィールドにJFrogインスタンスのベースURLを入力します。これはJFrogインスタンスのルートURLである必要があります。例: `https://your-instance.jfrog.io`。末尾にパスを含めないでください — DefectDojoが適切なAPIパスを自動的に構築します。 +2. **Secret**フィールドに有効な**Reference Token**を入力します。トークンはJFrog PlatformのUIの**User Management > Access Tokens**から生成できます。 +**Reference Token**を生成し、その値を使用する必要があります。 + +JFrog Xrayに必要なトークンスコープ: + +- **All Services** — DefectDojoはXRayとArtifactoryの両方のサービスへのアクセスが必要なため +- 最低限**Manage Reports + Manage Resources**が必要です。 + +デフォルトでは、DefectDojoは各Artifactory**リポジトリ**を個別のRecordとしてマッピングします。各Syncでリポジトリごとに完全な脆弱性レポートがXray経由で生成されるため、DefectDojo内の検出事項のステータスは常にリポジトリの現在の状態を反映します。 + +#### Repository Filter (optional) + +デフォルトでは、コネクタはJFrogインスタンス内の**すべて**のリポジトリを検出します。リポジトリ数が非常に多いインスタンス(その多くはセキュリティレビューに関係ない場合もあります)では、コネクタフォームの**Import Filters**の下にある任意項目の**Repository Filter**フィールドで検出範囲を絞り込むことができます。 + +このフィルタは検出時、つまり**リポジトリごとの処理が行われる前**に適用されます。フィルタ範囲外のリポジトリにはコストがかかりません — そのリポジトリのXrayレポートは生成されず、アーティファクトモードでは第1階層のアーティファクトも列挙されません。これにより、Syncにかかる時間とDefectDojoがJFrogインスタンスにかける負荷の両方を削減する、最も効果的な方法となります — これはSync後半に適用される他のどの設定よりも効果的です。特に大規模なインスタンスでは、**Artifact-Level Records**と併用することが推奨されます。 + +**構文:** リポジトリキーのカンマ区切りリストです。各項目には`*`ワイルドカードを使用できます。 + +* `*`を含む項目はパターンとして照合されます — `releases-*`は`releases-`で始まるすべてのリポジトリキーに一致し、`*docker-pr-local*`は`docker-pr-local`を含むすべてのキーに一致します。`*`は`/`を含む任意の文字列に一致します。 +* `*`を含まない項目は、リポジトリキーに**完全一致**する必要があります。 +* リストの**いずれかの**項目に一致すれば、そのリポジトリは検出されます。カンマの前後の空白は無視されます。 + +``` +releases-*, snapshots +``` + +上記の例では、`releases-`で始まるすべてのリポジトリキーに加えて、`snapshots`という名前に完全一致する単一のリポジトリを検出します。 + +補足: + +* このフィルタは**許可リスト(allow-list)**です — 一致するとそのリポジトリが選択されます。除外や否定の構文はないため、「Xを除くすべて」を直接表現することはできません。 +* 一致は完全一致・ワイルドカードともに**大文字小文字を区別します**。ワイルドカード文字は`*`のみで、`?`や文字範囲はサポートされていません。 +* **すべてのリポジトリを検出するには空欄のままにしてください。** 空白またはカンマのみの値は空欄として扱われます。 +* 何にも一致しないフィルタは単に何も検出しません — エラーにはなりません。Syncで予期せずリポジトリが見つからない場合は、コネクタログの`repository filter scoped discovery`のエントリを確認してください。これは全リポジトリ数のうち何件が一致したかを報告します。 +* このフィールドは接続作成後にも変更できます。 + +**後からフィルタを変更する場合:** 新たに絞り込まれたフィルタによって除外されたリポジトリは検出されなくなり、その既存のRecordはツールがそれ以上報告しなくなったproductに対する通常のライフサイクルに従います — **マッピング済み**のRecordは次のSyncで`MISSING`とフラグが立てられ、未マッピングの`NEW`のRecordは削除されます。すでにDefectDojoにインポートされた検出事項は削除されません。フィルタが管理するのは検出のみです。 + +#### Artifact-Level Records + +**Artifact-Level Records**のトグルをオンにすると、検出範囲がリポジトリの1階層下に変わります。リポジトリルート直下の第1階層の各エントリ(Dockerリポジトリの場合は各イメージ、汎用リポジトリの場合は各トップレベルのファイルまたはフォルダ)が、それぞれ独自のRecordになります。各Syncは引き続きリポジトリごとに1つのXrayレポートを生成しますが、DefectDojoは各脆弱性を影響を受けるアーティファクトに割り当てるため、JFrogインスタンスへの負荷は増加しません。 + +> **最初のSyncを行う前に、どちらのモードになっているか確認してください。** Artifact-Level Recordsは**新規インストールではデフォルトで有効**です。この機能より前から存在するインストールでは、既存のリポジトリレベルのレイアウトが維持されるため、誰かが有効化するまでトグルはオフのままです。どちらの場合も、トグルはいつでも変更できます。詳細は以下の*既存の接続の切り替え*を参照してください。 + +Artifact-Level Recordsを有効にすると: + +* リポジトリはRecordのままですが、**親アセット**になります。リポジトリ自体は検出事項を持ちませんが、Asset Hierarchy機能が有効な場合、DefectDojoは各アーティファクトアセットをそのリポジトリアセットに`parent`関係で自動的に関連付けます。これにより、アセットを親/子でフィルタリングでき、検出事項は階層をロールアップします。 +* 複数のアーティファクトに影響する脆弱性は、影響を受ける各アーティファクトのアセットにインポートされるため、すべてのアセットにそれぞれへ影響する検出事項の完全なセットが表示されます。 +* 検出事項は各アーティファクトの**最新ビルド**にスコープされるため、アーティファクトの検出事項は、Xrayがこれまでスキャンしたすべてのビルドの結果を蓄積するのではなく、現在のビルドを表します。 +* コネクタが作成した階層関係が、あなたが手動で作成した関係を上書きすることはありません。アセットにすでに割り当てた親がある場合、コネクタはそれに手を加えません。 +* トークンにはさらにArtifactory storage APIへの読み取りアクセスが必要です(上記のスコープに含まれています)。 + +**既存の接続をArtifact-Level Recordsに切り替える:** このトグルはいつでも変更できます。切り替え後の最初のSyncでは、マッピング対象として新しいアーティファクトRecordが表示されます — トグルを切り替える際は、検出事項が途切れなく移行するよう、接続で**Auto Map**を有効にしてください。リポジトリレベルのアセットは検出事項を受け取らなくなり、以前にインポートされた検出事項は次のSyncでクローズされます(同じ検出事項は新しいステータスで新しいアーティファクトアセットの下に再インポートされます)。古いリポジトリレベルの検出事項に付いていたメモと履歴は、リポジトリアセットに残ります。元に戻すとこの逆になります — リポジトリRecordが検出事項を持つ状態に戻り(以前にクローズされた検出事項は再一致して再オープンします)、アーティファクトRecordはMISSINGとしてマークされます。そのアセットと検出事項は保持されますが更新されなくなるため、任意のタイミングでアーカイブできます。 + +詳細については、[JFrog Xray REST APIドキュメント](https://jfrog.com/help/r/jfrog-rest-apis/xray-rest-apis)を参照してください。 diff --git a/docs/content/connectors/toolreference/jfrog_xray.md b/docs/content/connectors/toolreference/jfrog_xray.md new file mode 100644 index 00000000000..90a7cd6e5c0 --- /dev/null +++ b/docs/content/connectors/toolreference/jfrog_xray.md @@ -0,0 +1,73 @@ +--- +title: "JFrog XRay" +description: "How to set up the JFrog XRay Upstream Connector for DefectDojo" +weight: 81 +audience: pro +--- +The JFrog Xray connector uses the JFrog Xray REST API to fetch vulnerability data from your Artifactory repositories. DefectDojo will discover all repositories in your JFrog instance and generate vulnerability reports via Xray, importing findings on a scheduled basis. + +#### Prerequisites + +You will need an API token with access to both Artifactory and Xray APIs. We recommend creating a dedicated service account for DefectDojo. The account requires: + +* Read access to Artifactory repositories +* Permission to generate and view Xray vulnerability reports (`Apply on Watches` permission in Xray, or equivalent) + +#### Connector Mappings + +1. Enter your JFrog instance base URL in the **Location** field. This should be the root URL of your JFrog instance, for example `https://your-instance.jfrog.io`. Do not include a trailing path — DefectDojo will construct the appropriate API paths automatically. +2. Enter a valid **Reference Token** in the **Secret** field. Tokens can be generated under **User Management \> Access Tokens** in the JFrog Platform UI. +You'll need to generate a **Reference Token** and use that value. + +Required token scopes for JFrog Xray: + +- **All Services**, as DefectDojo needs access to both access to both XRay and Artifactory services +- **Manage Reports + Manage Resources** at a minimum. + +By default, DefectDojo maps each Artifactory **repository** as a separate Record. Each Sync generates a complete vulnerability report per repository via Xray, so finding statuses in DefectDojo always reflect the current state of the repository. + +#### Repository Filter (optional) + +By default the connector discovers **every** repository in your JFrog instance. On instances with a large number of repositories — many of which may not be relevant to security review — discovery can be narrowed with the optional **Repository Filter** field, under **Import Filters** on the connector form. + +The filter is applied during discovery, **before any per\-repository work is done**. A repository outside the filter costs nothing: no Xray report is generated for it and, in artifact mode, none of its first\-level artifacts are enumerated. This makes it the most effective way to cut both Sync time and the load DefectDojo places on your JFrog instance — more so than any setting applied later in the Sync. It is especially recommended alongside **Artifact\-Level Records** on large instances. + +**Syntax:** a comma\-separated list of repository keys. Each entry may use `*` wildcards: + +* An entry containing `*` is matched as a pattern — `releases-*` matches every repository key beginning `releases-`, and `*docker-pr-local*` matches any key containing `docker-pr-local`. A `*` matches any run of characters, including `/`. +* An entry with no `*` must match a repository key **exactly**. +* A repository is discovered if it matches **any** entry in the list. Spaces around commas are ignored. + +``` +releases-*, snapshots +``` + +The example above discovers every repository whose key starts with `releases-`, plus the single repository named exactly `snapshots`. + +Notes: + +* The filter is an **allow\-list** — a match selects a repository. There is no exclusion or negation syntax, so you cannot express "everything except X" directly. +* Matching is **case\-sensitive**, for both exact entries and wildcards. `*` is the only wildcard character; `?` and character ranges are not supported. +* **Leave it blank to discover every repository.** A value that is only spaces or commas is treated as blank. +* A filter that matches nothing simply discovers nothing — there is no error. If a Sync unexpectedly finds no repositories, check the connector log for the `repository filter scoped discovery` entry, which reports how many of the total repositories matched. +* The field can be changed after the connection is created. + +**Changing the filter later:** repositories that a newly narrowed filter now excludes are no longer discovered, and their existing Records follow the normal lifecycle for Assets the tool no longer reports — **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. + +#### Artifact-Level Records + +The **Artifact-Level Records** toggle changes discovery to one level below the repository: every first-level entry under a repository root (for Docker repositories, each image; for generic repositories, each top-level file or folder) becomes its own Record. Each Sync still generates a single Xray report per repository — DefectDojo attributes each vulnerability to the artifacts it impacts, so the load on your JFrog instance does not increase. + +> **Check which mode you are in before your first Sync.** Artifact\-Level Records is **on by default for new installations**. Installations that predate the feature keep their existing repository\-level layout, so the toggle is off for them until someone turns it on. In both cases the toggle can be changed at any time — see *Switching an existing connection* below. + +With Artifact-Level Records enabled: + +* Repositories remain as Records and become **parent assets**: they carry no findings themselves, but when the Asset Hierarchy feature is enabled, DefectDojo automatically relates each artifact asset to its repository asset with a `parent` relationship. Assets can then be filtered by parent/child, and findings roll up the hierarchy. +* A vulnerability that impacts several artifacts is imported into each affected artifact's asset, so every asset shows the complete set of findings that affect it. +* Findings are scoped to each artifact's **latest build**, so an artifact's findings describe its current build rather than accumulating results from every build Xray has ever scanned. +* Hierarchy relationships created by the connector never overwrite relationships you created by hand. If an asset already has a parent you assigned, the connector leaves it alone. +* The token additionally needs read access to the Artifactory storage API (included in the scopes above). + +**Switching an existing connection to Artifact-Level Records:** the toggle can be changed at any time. On the first Sync afterward, new artifact Records appear for mapping — enable **Auto Map** on the connection when flipping the toggle so findings move without a gap. The repository-level assets stop receiving findings and their previously imported findings are closed on their next Sync (the same findings are re-imported under the new artifact assets, with fresh status); notes and history on the old repository-level findings stay on the repository asset. Switching back reverses this: repository Records resume carrying findings (previously closed findings re-open as they re-match), and artifact Records are marked MISSING — their assets and findings are kept but stop updating, so you can archive them at your convenience. + +See the [JFrog Xray REST API documentation](https://jfrog.com/help/r/jfrog-rest-apis/xray-rest-apis) for more information. diff --git a/docs/content/connectors/toolreference/jira.de.md b/docs/content/connectors/toolreference/jira.de.md new file mode 100644 index 00000000000..918736c8c77 --- /dev/null +++ b/docs/content/connectors/toolreference/jira.de.md @@ -0,0 +1,118 @@ +--- +title: "Jira" +description: "Einrichtung des Jira Downstream-Connectors für DefectDojo" +weight: 82 +audience: pro +--- +Die Jira-Integration überträgt DefectDojo-Befunde und Befundgruppen als Issues in ein Jira-Projekt, hält den Status jedes Issues mit dem Befund synchron und verknüpft den Befund mit dem erstellten Issue. Sowohl Jira **Cloud** als auch **Data Center / Server** werden unterstützt. Jira Service Management wird nicht unterstützt. + +### Auswahl einer Authentifizierungsmethode + +Legen Sie zuerst **Jira Deployment** fest und wählen Sie dann eine **Authentication Method**: + +**Jira Cloud** +- **API Token (E-Mail + Token)** – HTTP-Basic-Authentifizierung mit der E-Mail-Adresse eines Atlassian-Kontos und einem [API-Token](https://id.atlassian.com/manage-profile/security/api-tokens). Aufrufe gehen direkt an Ihre Site-URL. +- **OAuth 2.0 (empfohlen)** – eine einmalige Zustimmung im Browser; DefectDojo bezieht und erneuert die Token für Sie. +- **Service Account Token** – ein API-Token mit Scopes, das für ein Atlassian-[Servicekonto](https://support.atlassian.com/user-management/docs/manage-api-tokens-for-service-accounts/) erstellt wurde. + +**Jira Data Center / Server** +- **Personal Access Token (empfohlen)** +- **Benutzername + Passwort** + +> **Wie die Cloud-Authentifizierung Jira erreicht:** OAuth 2.0 und Service Account authentifizieren sich beide per Bearer-Token gegenüber Atlassians Gateway – `https://api.atlassian.com/ex/jira/{cloudId}` – und das ist ein *anderer Host* als Ihre Site-URL `https://your-site.atlassian.net`. DefectDojo verwendet für jeden API-Aufruf das Gateway, bildet den auf einem Befund angezeigten Ticket-Link jedoch immer aus Ihrer **Site-URL**, sodass der Link, den ein Benutzer anklickt, ein normaler, im Browser aufrufbarer `.../browse/{ISSUE-KEY}`-Link ist. (Bei API-Token- und Data-Center-Authentifizierung wird die Site-URL direkt aufgerufen, es gibt dort also keine Aufteilung.) + +### Instanz-Einrichtung + +- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf Ihre Jira-**Site-URL** gesetzt werden, zum Beispiel `https://your-organization.atlassian.net`. Sie wird für die im Browser aufrufbaren Ticket-Links verwendet und – bei API-Token- und Data-Center-Authentifizierung – als API-Basis-URL. +- Die übrigen Felder hängen von der oben gewählten Methode ab (E-Mail + API-Token, OAuth-Client-Anmeldedaten, Servicekonto-Token, PAT oder Benutzername + Passwort). + +### OAuth-2.0-Einrichtung (Cloud) + +Erstellen Sie eine dedizierte App in der [Atlassian Developer Console](https://developer.atlassian.com/console/myapps/) und verbinden Sie sie anschließend aus DefectDojo heraus. + +1. Wählen Sie **Create → OAuth 2.0 integration**. Es muss eine *OAuth 2.0 integration* sein – eine Connect- oder Forge-App kann den 3LO-Authorization-Code-Grant nicht nutzen (Sie würden `grant_type is not enabled for client` erhalten). +2. Wählen Sie bei der Frage nach dem **Access type** die Option **Resource-level**. Damit wird das Token auf die eine Jira-Site beschränkt, die der Benutzer autorisiert – genau das, worauf eine DefectDojo-Verbindung zielt. (**Account-level** gewährt Zugriff auf jede Site des Atlassian-Kontos – mehr als erforderlich.) +3. Fügen Sie unter **Permissions** die **Jira platform REST API** hinzu und erteilen Sie die unten aufgeführten Scopes. Hinweis: `offline_access` ist hier *nicht* aufgeführt – es ist ein Standard-OAuth-Scope, den DefectDojo in der Autorisierungs-URL anfordert, und nichts, das Sie auf diesem Bildschirm hinzufügen. +4. Klicken Sie unter **Authorization** neben **OAuth 2.0 (3LO)** auf **Configure** und setzen Sie die **Callback URL** auf `https:///integrators/jira/oauth/callback` – sie muss exakt Ihrer DefectDojo-Site-URL entsprechen. Erst dadurch werden der Authorization-Code-Grant und Refresh-Token aktiviert; wird dies übersprungen, treten die Fehler `grant_type is not enabled` / `Client is not allowed to use offline_access` auf. +5. Kopieren Sie die **Client ID** und das **Client Secret** in das DefectDojo-Formular und klicken Sie auf **Submit**, um die Verbindung zu speichern. +6. Klicken Sie auf **Connect with Jira** und bestätigen Sie den Zustimmungsbildschirm. Atlassian leitet zurück zu DefectDojo, das die Token speichert und Ihre `cloudId` automatisch auflöst. Bei Erfolg erscheint die Anzeige „Connected“. + +> Der Callback-Host ist die `SITE_URL` Ihrer DefectDojo-Instanz. Atlassian muss den Browser dorthin weiterleiten können, und der Wert muss exakt dem entsprechen, was DefectDojo sendet – verwenden Sie deshalb den echten Hostnamen, über den Ihre Benutzer DefectDojo erreichen, und keinen Wert, der nur aus dem internen Netzwerk erreichbar ist. + +#### Minimale OAuth-Scopes + +DefectDojo fordert standardmäßig diese vier klassischen Scopes an, und sie sind gleichzeitig das **absolute Minimum** – jeder davon deckt ein bestimmtes Verhalten ab: + +| Scope | Erforderlich für | +|-------|--------------| +| `read:jira-work` | Lesen des Projekts, der Issues und der verfügbaren Übergänge (Verbindungsprüfung und Statussynchronisierung). | +| `write:jira-work` | Erstellen und Bearbeiten von Issues sowie Ausführen von Statusübergängen. | +| `read:jira-user` | Die Identitätsprüfung der Verbindung – DefectDojo ruft beim Prüfen des Zugriffs `/myself` auf. | +| `offline_access` | Ausgeben eines **Refresh-Tokens**. Ohne ihn läuft das Access-Token ab (etwa eine Stunde nach dem Verbinden) und die Verbindung funktioniert nicht mehr, weil DefectDojo es nicht länger erneuern kann. | + +Atlassian empfiehlt klassische Scopes gegenüber granularen; die vier oben genannten halten den Footprint der App minimal und genügen für alles, was die Integration tut. + +##### Alternative mit granularen Scopes + +Wenn Ihre Organisation **granulare** Scopes anstelle klassischer verlangt, lautet der minimale äquivalente Satz: + +| Granularer Scope | Erforderlich für | +|----------------|--------------| +| `read:user:jira` | Die Identitätsprüfung über `/myself`. | +| `read:project:jira` | Prüfen, ob das Zielprojekt existiert. | +| `read:issue:jira` | Lesen des aktuellen Status eines Issues während der Synchronisierung. | +| `write:issue:jira` | Erstellen und Bearbeiten von Issues **sowie Ausführen von Statusübergängen** – es gibt keinen separaten Schreib-Scope für Übergänge, denn ein Übergang ist ein Schreibvorgang am Issue. | +| `read:issue.transition:jira` | Auflisten der für ein Issue verfügbaren Übergänge. | +| `offline_access` | Das Refresh-Token (wie bei den klassischen Scopes). | + +Je nach Feldkonfiguration Ihrer Site kann ein Endpunkt zusätzlich begleitende Lese-Scopes benötigen, um Felder zu expandieren – am häufigsten `read:status:jira` und `read:field:jira` (sowie `read:issue-meta:jira` beim Erstellen). Schlägt eine Übertragung mit einem `403`-Fehler „scope does not match“ fehl, fügen Sie genau den im Fehler genannten Scope hinzu. Genau dieses Ausufern begleitender Scopes ist der Grund, warum klassische Scopes empfohlen werden. + +Für die Methode **Service Account Token** erteilen Sie dem Token `read:jira-work` und `write:jira-work` (sowie `read:jira-user`) – oder die oben genannten granularen Entsprechungen ohne `offline_access`. `offline_access` ist hier nicht relevant – ein Servicekonto-Token ist langlebig und wird von DefectDojo nicht erneuert. + +### Issue-Tracker-Zuordnung + +- **Project Key**: der Schlüssel des Jira-Projekts, in dem Issues erstellt werden, zum Beispiel `SEC`. +- **Issue Type**: der zu erstellende Issue-Typ, zum Beispiel `Bug` oder `Task`. Standard ist `Bug`. + +### Details zur Schweregrad-Zuordnung + +Die Standardwerte entsprechen dem Standard-Prioritätsschema von Jira. Passen Sie sie an die Prioritätsnamen in Ihrem Projekt an: + +- **Name des Schweregrad-Felds**: `priority` +- **Info-Zuordnung**: `Lowest` +- **Niedrig-Zuordnung**: `Low` +- **Mittel-Zuordnung**: `Medium` +- **Hoch-Zuordnung**: `High` +- **Kritisch-Zuordnung**: `Highest` + +### Details zur Status-Zuordnung + +Status unterscheiden sich je nach Projekt-Workflow, daher sind diese Standardwerte dafür gedacht, an die Statusnamen **Ihres** Workflows angepasst zu werden: + +- **Name des Status-Felds**: `status` +- **Aktiv-Zuordnung**: `To Do` +- **Geschlossen-Zuordnung**: `Done` +- **Falsch-positiv-Zuordnung**: `Done` +- **Risiko-akzeptiert-Zuordnung**: `Done` + +### Benutzerdefinierte Felder (optional) + +Sie können weitere Jira-Felder zuordnen – zum Beispiel eine beim Schließen erforderliche `resolution` oder `labels` – und zwar im Schritt **Custom Fields** der Zuordnung. Jede Zuordnung eines benutzerdefinierten Felds besteht aus vier Teilen: + +- **Source** – woher der Wert kommt: ein Attribut des übertragenen **Befunds**, **Tests**, **Engagements** oder **Assets** oder ein **statischer Wert**. +- **Value** – bei einer Objektquelle das konkrete auszulesende Attribut, ausgewählt aus einer Liste der Felder dieses Objekts mit lesbaren Bezeichnungen (zum Beispiel *Schweregrad*, *CVE*, *Mitigation*). Bei der Quelle **Static value** ist dies ein Freitextfeld, in das Sie den wörtlichen Wert eingeben. +- **Vendor Field** – das Jira-Feld, in das geschrieben wird. Da DefectDojo den Feldkatalog von Jira lesen kann, ist dies eine durchsuchbare Auswahl, die jedes Feld mit seinem **Anzeigenamen** auflistet und für Sie in die interne ID auflöst – Sie wählen also *DD Close Justification* und DefectDojo speichert `customfield_10255`. Die Auswahl wird aus der Verbindung befüllt und funktioniert daher, sobald die Verbindung gespeichert und geprüft ist. +- **Application point** – *wann* das Feld gesendet wird: bei der **Ticket-Erstellung**, bei **jeder Aktualisierung** oder als Teil eines bestimmten Status-**Übergangs** (Aktiv / Geschlossen / Falsch-positiv / Risiko akzeptiert). Ein auf einen Übergang beschränktes Feld wird als Teil der Bearbeitung dieses Übergangs gesendet – so liefern Sie einen Wert, den Jira nur auf einem Übergangsbildschirm akzeptiert, meist eine `resolution`, die Ihr Workflow beim Auflösen eines Issues verlangt. + +### Ticket-Vorlagen (optional) + +Standardmäßig verwenden Jira-Issues den integrierten Titel und Textkörper von DefectDojo. Um sie anzupassen, hängen Sie im Schritt **Ticket Template** der Zuordnung eine **Ticket-Vorlage** an. Eine Vorlage definiert vier unabhängig voneinander optionale Bestandteile – Zusammenfassung und Beschreibung für den **Befund** sowie Zusammenfassung und Beschreibung für die **Befundgruppe**. Jeder leer gelassene Bestandteil fällt auf den integrierten Standard zurück, sodass Sie nur den Titel, nur den Textkörper oder alle vier überschreiben können. Verwenden Sie **Test render** im Vorlagen-Editor, um die gerenderte Ausgabe anhand von Beispieldaten vorab zu prüfen – so erkennen Sie Fehler wie unbekannte Platzhalter oder Werte, die die Längenbegrenzung eines Felds überschreiten – bevor Sie speichern. Wird eine Vorlage später gelöscht, fallen die Zuordnungen, die sie verwendet haben, automatisch auf die integrierten Standardwerte zurück. + +### Funktionsweise + +- **Erstellen / Aktualisieren / Löschen:** Beim Erstellen wird ein neues Issue übertragen und der Link am Befund vermerkt; beim Aktualisieren wird das bestehende Issue bearbeitet; beim Löschen eines Befunds wird sein Issue zwangsweise geschlossen (in Jira wird nichts gelöscht). Übertragungen können manuell erfolgen („Push to Integrator“) oder automatisch gemäß der Issue-Tracker-Zuweisung. +- **Statusabgleich:** Nach dem Erstellen (und bei jeder Aktualisierung) liest DefectDojo den aktuellen Status des Issues und sucht, falls er vom zugeordneten Ziel abweicht, einen einzelnen Workflow-Übergang, der ihn erreicht, und wendet diesen an. Existiert kein solcher Übergang, vermerkt die Zuordnung einen Fehler, anstatt stillschweigend zu scheitern. Alle auf Übergänge beschränkten benutzerdefinierten Felder werden mit diesem Übergang gesendet. +- **Ticket-Link:** Der am Befund angezeigte Link ist `https://your-site.atlassian.net/browse/{ISSUE-KEY}` – immer Ihre öffentliche Site-URL, niemals das interne Gateway. +- **Token-Lebenszyklus (OAuth):** DefectDojo verantwortet den gesamten Ablauf – es führt den Authorization-Code-Austausch durch, speichert Access- und Refresh-Token und erneuert sie bei Bedarf vor einer Übertragung, wobei das neue Refresh-Token jedes Mal gespeichert wird (Atlassian rotiert es bei jeder Erneuerung). +- **Speicherung der Anmeldedaten:** Alle Verbindungsdaten (Passwörter, Token, Client Secrets, OAuth-Token) werden verschlüsselt gespeichert und niemals über die API zurückgegeben – beim Bearbeiten einer Verbindung erscheint für gespeicherte Geheimnisse ein Platzhalter „leer lassen, um beizubehalten“. diff --git a/docs/content/connectors/toolreference/jira.es.md b/docs/content/connectors/toolreference/jira.es.md new file mode 100644 index 00000000000..09c75e911af --- /dev/null +++ b/docs/content/connectors/toolreference/jira.es.md @@ -0,0 +1,118 @@ +--- +title: "Jira" +description: "Cómo configurar el Conector Downstream de Jira para DefectDojo" +weight: 82 +audience: pro +--- +La integración de Jira envía los Hallazgos y Grupos de Hallazgos de DefectDojo a un proyecto de Jira como incidencias, mantiene sincronizado el estado de cada incidencia con el Hallazgo y enlaza el Hallazgo de vuelta a la incidencia creada. Se admiten tanto Jira **Cloud** como **Data Center / Server**. Jira Service Management no es compatible. + +### Elegir un método de autenticación + +Establezca primero **Jira Deployment**, luego elija un **Authentication Method**: + +**Jira Cloud** +- **API Token (email + token)** — autenticación HTTP Basic usando un correo electrónico de cuenta de Atlassian y un [token de API](https://id.atlassian.com/manage-profile/security/api-tokens). Las llamadas se dirigen directamente a la URL de su sitio. +- **OAuth 2.0 (recomendado)** — un consentimiento del navegador de una sola vez; DefectDojo obtiene y renueva los tokens por usted. +- **Service Account Token** — un token de API con alcance limitado creado para una [cuenta de servicio](https://support.atlassian.com/user-management/docs/manage-api-tokens-for-service-accounts/) de Atlassian. + +**Jira Data Center / Server** +- **Personal Access Token (recomendado)** +- **Username + Password** + +> **Cómo llega la autenticación de Cloud a Jira:** tanto OAuth 2.0 como Service Account se autentican como un token Bearer contra la puerta de enlace de Atlassian — `https://api.atlassian.com/ex/jira/{cloudId}` —, que es un *host distinto* de la URL de su sitio `https://your-site.atlassian.net`. DefectDojo usa la puerta de enlace para cada llamada a la API, pero siempre construye el enlace del ticket que se muestra en un Hallazgo a partir de la **URL de su sitio**, de modo que el enlace en el que hace clic un usuario es un enlace normal y navegable `.../browse/{ISSUE-KEY}`. (La autenticación de API Token y Data Center llama directamente a la URL del sitio, por lo que no existe esa división.) + +### Configuración de la instancia + +- **Label** debe ser la etiqueta que desea usar para identificar esta integración. +- **Location** debe establecerse en la **URL del sitio** de Jira, por ejemplo `https://your-organization.atlassian.net`. Esto se usa para los enlaces de ticket navegables y, para la autenticación de API Token y Data Center, como URL base de la API. +- Los campos restantes dependen del método elegido anteriormente (email + token de API, credenciales de cliente OAuth, token de cuenta de servicio, PAT, o nombre de usuario + contraseña). + +### Configuración de OAuth 2.0 (Cloud) + +Cree una aplicación dedicada en la [consola de desarrolladores de Atlassian](https://developer.atlassian.com/console/myapps/) y luego conéctese desde DefectDojo. + +1. Elija **Create → OAuth 2.0 integration**. Debe ser una *integración OAuth 2.0* — una aplicación Connect o Forge no puede usar el grant de código de autorización 3LO (obtendría `grant_type is not enabled for client`). +2. Cuando se le solicite el **Access type**, elija **Resource-level**. Esto limita el token al único sitio de Jira que autoriza el usuario, que es exactamente lo que apunta una conexión de DefectDojo. (**Account-level** otorga acceso a todos los sitios de la cuenta de Atlassian — más amplio de lo necesario.) +3. En **Permissions**, añada la **Jira platform REST API** y otorgue los alcances listados a continuación. Nota: `offline_access` *no* aparece aquí — es un alcance OAuth estándar que DefectDojo solicita en la URL de autorización, no algo que se añada en esta pantalla. +4. En **Authorization**, junto a **OAuth 2.0 (3LO)**, haga clic en **Configure** y establezca la **Callback URL** en `https:///integrators/jira/oauth/callback` — debe coincidir exactamente con la URL de su sitio de DefectDojo. Habilitar esto es lo que activa el grant de código de autorización y los tokens de renovación; omitirlo provoca los errores `grant_type is not enabled` / `Client is not allowed to use offline_access`. +5. Copie el **Client ID** y el **Client Secret** en el formulario de DefectDojo y haga clic en **Submit** para guardar la conexión. +6. Haga clic en **Connect with Jira** y apruebe la pantalla de consentimiento. Atlassian redirige de vuelta a DefectDojo, que almacena los tokens y resuelve su `cloudId` automáticamente. Aparece un indicador "Connected" cuando tiene éxito. + +> El host de callback es su `SITE_URL` de DefectDojo. Atlassian debe poder redirigir el navegador allí, y el valor debe coincidir exactamente con lo que envía DefectDojo — así que use el nombre de host real al que sus usuarios acceden a DefectDojo, no un valor solo alcanzable desde dentro de la red. + +#### Alcances mínimos de OAuth + +DefectDojo solicita estos cuatro alcances clásicos de forma predeterminada, y también son el **mínimo absoluto** requerido — cada uno respalda un comportamiento específico: + +| Alcance | Requerido para | +|-------|--------------| +| `read:jira-work` | Leer el proyecto, las incidencias y las transiciones disponibles (validación de conexión y sincronización de estado). | +| `write:jira-work` | Crear y editar incidencias, y ejecutar transiciones de estado. | +| `read:jira-user` | La verificación de identidad de la conexión — DefectDojo llama a `/myself` al validar el acceso. | +| `offline_access` | Emitir un **token de renovación**. Sin él, el token de acceso expira (~1 hora después de conectarse) y la conexión deja de funcionar, porque DefectDojo ya no puede renovarlo. | + +Atlassian recomienda los alcances clásicos sobre los granulares; los cuatro anteriores mantienen mínima la huella de la aplicación y son suficientes para todo lo que hace la integración. + +##### Alternativa de alcances granulares + +Si su organización requiere alcances **granulares** en lugar de clásicos, el conjunto mínimo equivalente es: + +| Alcance granular | Requerido para | +|----------------|--------------| +| `read:user:jira` | La verificación de identidad `/myself`. | +| `read:project:jira` | Validar que el proyecto objetivo existe. | +| `read:issue:jira` | Leer el estado actual de una incidencia durante la sincronización. | +| `write:issue:jira` | Crear y editar incidencias **y ejecutar transiciones de estado** — no existe un alcance de escritura de transición separado; una transición es una escritura en la incidencia. | +| `read:issue.transition:jira` | Listar las transiciones disponibles en una incidencia. | +| `offline_access` | El token de renovación (igual que en el clásico). | + +Dependiendo de la configuración de campos de su sitio, un endpoint también puede requerir alcances de lectura complementarios para expandir campos — lo más común es `read:status:jira` y `read:field:jira` (y `read:issue-meta:jira` para la creación). Si un envío falla con un error `403` de "scope does not match", añada el alcance exacto indicado en el error. Esta proliferación de alcances complementarios es precisamente la razón por la que se recomiendan los alcances clásicos. + +Para el método **Service Account Token**, otorgue al token `read:jira-work` y `write:jira-work` (además de `read:jira-user`) — o los equivalentes granulares anteriores sin `offline_access`. `offline_access` no aplica — un token de cuenta de servicio es de larga duración y DefectDojo no lo renueva. + +### Mapeo del Issue Tracker + +- **Project Key**: la clave del proyecto de Jira en el que se crearán las incidencias, por ejemplo `SEC`. +- **Issue Type**: el tipo de incidencia a crear, por ejemplo `Bug` o `Task`. El valor predeterminado es `Bug`. + +### Detalles del mapeo de severidad + +Los valores predeterminados coinciden con el esquema de prioridad predeterminado de Jira. Edítelos para que coincidan con los nombres de prioridad de su proyecto: + +- **Severity Field Name**: `priority` +- **Info Mapping**: `Lowest` +- **Low Mapping**: `Low` +- **Medium Mapping**: `Medium` +- **High Mapping**: `High` +- **Critical Mapping**: `Highest` + +### Detalles del mapeo de estado + +Los estados varían según el flujo de trabajo de cada proyecto, por lo que estos valores predeterminados están pensados para editarse con los nombres de estado de **su** flujo de trabajo: + +- **Status Field Name**: `status` +- **Active Mapping**: `To Do` +- **Closed Mapping**: `Done` +- **False Positive Mapping**: `Done` +- **Risk Accepted Mapping**: `Done` + +### Campos personalizados (opcional) + +Puede mapear campos adicionales de Jira — por ejemplo, un `resolution` requerido al cerrar, o `labels` — en el paso **Custom Fields** del mapeo. Cada mapeo de campo personalizado tiene cuatro partes: + +- **Source** — de dónde proviene el valor: un atributo del **Finding**, **Test**, **Engagement** o **Asset** que se está enviando, o un **Static value**. +- **Value** — para un origen de objeto, el atributo específico a leer, elegido de una lista de los campos de ese objeto con etiquetas legibles (por ejemplo *Severity*, *CVE*, *Mitigation*). Para un origen **Static value**, esto es un cuadro de texto libre en el que escribe el valor literal. +- **Vendor Field** — el campo de Jira en el que se escribe. Como DefectDojo puede leer el catálogo de campos de Jira, este es un selector con búsqueda que lista cada campo por su **nombre de visualización** y lo resuelve al id interno por usted — así que selecciona *DD Close Justification* y DefectDojo almacena `customfield_10255`. El selector se llena a partir de la conexión, por lo que funciona una vez que la conexión se ha guardado y validado. +- **Application point** — *cuándo* enviar el campo: en la **creación del ticket**, en **cada actualización**, o como parte de una **transición** de estado específica (Active / Closed / False Positive / Risk Accepted). Un campo con alcance de transición se envía como parte de la edición de esa transición — así es como se proporciona un valor que Jira solo acepta en una pantalla de transición, más comúnmente un `resolution` que su flujo de trabajo requiere cuando se resuelve una incidencia. + +### Plantillas de ticket (opcional) + +De forma predeterminada, las incidencias de Jira usan el título y el cuerpo integrados de DefectDojo. Para personalizarlos, adjunte una **Ticket Template** al mapeo en su paso **Ticket Template**. Una plantilla define cuatro piezas independientemente opcionales — el resumen y la descripción del **Finding**, y el resumen y la descripción del **Finding Group**. Cualquier pieza que se deje en blanco recurre al valor predeterminado integrado, por lo que puede anular solo el título, solo el cuerpo, o los cuatro. Use **Test render** en el editor de plantillas para previsualizar la salida renderizada con datos de muestra — detectando errores como marcadores de posición desconocidos o valores que exceden el límite de longitud de un campo — antes de guardar. Si una plantilla se elimina posteriormente, los mapeos que la usaban vuelven automáticamente a los valores predeterminados integrados. + +### Cómo funciona + +- **Crear / Actualizar / Eliminar:** crear envía una nueva incidencia y registra el enlace en el Hallazgo; actualizar edita la incidencia existente; eliminar un Hallazgo fuerza el cierre de su incidencia (nada se elimina en Jira). Los envíos pueden ser manuales ("Push to Integrator") o automáticos según la asignación del Issue Tracker. +- **Reconciliación de estado:** después de crear (y en cada actualización) DefectDojo lee el estado actual de la incidencia y, si difiere del objetivo mapeado, busca una única transición del flujo de trabajo que lo alcance y la aplica. Si no existe tal transición, el mapeo registra un error en lugar de fallar silenciosamente. Cualquier campo personalizado con alcance de transición se envía con esa transición. +- **Enlace del ticket:** el enlace que se muestra en el Hallazgo es `https://your-site.atlassian.net/browse/{ISSUE-KEY}` — siempre la URL pública de su sitio, nunca la puerta de enlace interna. +- **Ciclo de vida del token (OAuth):** DefectDojo gestiona todo el flujo — realiza el intercambio de código de autorización, almacena los tokens de acceso y de renovación, y renueva bajo demanda antes de un envío, guardando el nuevo token de renovación cada vez (Atlassian lo rota en cada renovación). +- **Almacenamiento de credenciales:** todas las credenciales de la conexión (contraseñas, tokens, secretos de cliente, tokens OAuth) se cifran en reposo y nunca se devuelven a través de la API — editar una conexión muestra un marcador de posición "leave blank to keep" para los secretos almacenados. diff --git a/docs/content/connectors/toolreference/jira.fr.md b/docs/content/connectors/toolreference/jira.fr.md new file mode 100644 index 00000000000..b58728b4d7a --- /dev/null +++ b/docs/content/connectors/toolreference/jira.fr.md @@ -0,0 +1,118 @@ +--- +title: "Jira" +description: "Comment configurer le Connecteur Downstream Jira pour DefectDojo" +weight: 82 +audience: pro +--- +L'intégration Jira transmet les Constatations et Groupes de constatations de DefectDojo vers un projet Jira sous forme de tickets, maintient le statut de chaque ticket synchronisé avec la Constatation, et relie la Constatation au ticket créé. Jira **Cloud** et **Data Center / Server** sont tous deux pris en charge. Jira Service Management n'est pas pris en charge. + +### Choisir une méthode d'authentification + +Définissez d'abord **Jira Deployment**, puis choisissez une **Authentication Method** : + +**Jira Cloud** +- **API Token (email + token)** — authentification HTTP Basic utilisant l'e-mail d'un compte Atlassian et un [jeton API](https://id.atlassian.com/manage-profile/security/api-tokens). Les appels sont envoyés directement à l'URL de votre site. +- **OAuth 2.0 (recommended)** — un consentement navigateur unique ; DefectDojo obtient et actualise les jetons pour vous. +- **Service Account Token** — un jeton API à portée limitée créé pour un [compte de service](https://support.atlassian.com/user-management/docs/manage-api-tokens-for-service-accounts/) Atlassian. + +**Jira Data Center / Server** +- **Personal Access Token (recommended)** +- **Username + Password** + +> **Comment l'authentification Cloud atteint Jira :** OAuth 2.0 et Service Account s'authentifient tous deux via un jeton Bearer auprès de la passerelle Atlassian — `https://api.atlassian.com/ex/jira/{cloudId}` — qui est un *hôte différent* de l'URL de votre site `https://your-site.atlassian.net`. DefectDojo utilise la passerelle pour chaque appel API, mais construit toujours le lien du ticket affiché sur une Constatation à partir de l'**URL de votre site**, de sorte que le lien sur lequel un utilisateur clique est un lien normal et navigable de type `.../browse/{ISSUE-KEY}`. (L'authentification API Token et Data Center appelle directement l'URL du site, il n'y a donc pas de séparation.) + +### Configuration de l'instance + +- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur l'**URL de votre site** Jira, par exemple `https://your-organization.atlassian.net`. Elle est utilisée pour les liens de tickets navigables et — pour l'authentification API Token et Data Center — comme URL de base de l'API. +- Les champs restants dépendent de la méthode choisie ci-dessus (e-mail + jeton API, identifiants client OAuth, jeton de compte de service, PAT, ou nom d'utilisateur + mot de passe). + +### Configuration OAuth 2.0 (Cloud) + +Créez une application dédiée dans la [console développeur Atlassian](https://developer.atlassian.com/console/myapps/), puis connectez-vous depuis DefectDojo. + +1. Choisissez **Create → OAuth 2.0 integration**. Il doit s'agir d'une *intégration OAuth 2.0* — une application Connect ou Forge ne peut pas utiliser le flux d'autorisation par code 3LO (vous obtiendriez `grant_type is not enabled for client`). +2. Lorsque l'on vous demande le **Access type**, choisissez **Resource-level**. Cela limite le jeton au seul site Jira que l'utilisateur autorise, ce qui correspond exactement à ce que cible une connexion DefectDojo. (**Account-level** accorde l'accès à tous les sites du compte Atlassian — une portée plus large que nécessaire.) +3. Dans **Permissions**, ajoutez la **Jira platform REST API** et accordez les portées listées ci-dessous. Remarque : `offline_access` n'est *pas* listée ici — il s'agit d'une portée OAuth standard que DefectDojo demande dans l'URL d'autorisation, et non d'un élément à ajouter sur cet écran. +4. Dans **Authorization**, à côté de **OAuth 2.0 (3LO)**, cliquez sur **Configure** et définissez la **Callback URL** sur `https:///integrators/jira/oauth/callback` — elle doit correspondre exactement à l'URL de votre site DefectDojo. C'est cette activation qui active le flux d'autorisation par code et les jetons de rafraîchissement ; l'omettre provoque les erreurs `grant_type is not enabled` / `Client is not allowed to use offline_access`. +5. Copiez le **Client ID** et le **Client Secret** dans le formulaire DefectDojo, puis cliquez sur **Submit** pour enregistrer la connexion. +6. Cliquez sur **Connect with Jira** et approuvez l'écran de consentement. Atlassian redirige ensuite vers DefectDojo, qui stocke les jetons et résout automatiquement votre `cloudId`. Un indicateur « Connected » apparaît en cas de succès. + +> L'hôte de rappel est votre `SITE_URL` DefectDojo. Atlassian doit pouvoir y rediriger le navigateur, et la valeur doit correspondre exactement à ce que DefectDojo envoie — utilisez donc le nom d'hôte réel par lequel vos utilisateurs accèdent à DefectDojo, et non une valeur accessible uniquement depuis l'intérieur du réseau. + +#### Portées OAuth minimales + +DefectDojo demande ces quatre portées classiques par défaut, qui constituent également le **minimum absolu** requis — chacune sous-tend un comportement spécifique : + +| Scope | Required for | +|-------|--------------| +| `read:jira-work` | Lire le projet, les tickets et les transitions disponibles (validation de la connexion et synchronisation du statut). | +| `write:jira-work` | Créer et modifier des tickets, et exécuter des transitions de statut. | +| `read:jira-user` | La vérification d'identité de la connexion — DefectDojo appelle `/myself` lors de la validation de l'accès. | +| `offline_access` | Émettre un **jeton de rafraîchissement**. Sans cela, le jeton d'accès expire (~1 heure après la connexion) et la connexion cesse de fonctionner, car DefectDojo ne peut plus le rafraîchir. | + +Atlassian recommande les portées classiques plutôt que les portées granulaires ; les quatre ci-dessus limitent l'empreinte de l'application au minimum et suffisent pour tout ce que fait l'intégration. + +##### Alternative avec portées granulaires + +Si votre organisation exige des portées **granulaires** plutôt que classiques, l'ensemble minimal équivalent est le suivant : + +| Granular scope | Required for | +|----------------|--------------| +| `read:user:jira` | La vérification d'identité `/myself`. | +| `read:project:jira` | Valider que le projet cible existe. | +| `read:issue:jira` | Lire le statut actuel d'un ticket pendant la synchronisation. | +| `write:issue:jira` | Créer et modifier des tickets **et exécuter des transitions de statut** — il n'existe pas de portée d'écriture distincte pour les transitions ; une transition est une écriture sur le ticket. | +| `read:issue.transition:jira` | Lister les transitions disponibles sur un ticket. | +| `offline_access` | Le jeton de rafraîchissement (identique aux portées classiques). | + +Selon la configuration des champs de votre site, un endpoint peut également nécessiter des portées de lecture complémentaires pour développer les champs — le plus souvent `read:status:jira` et `read:field:jira` (ainsi que `read:issue-meta:jira` pour la création). Si une transmission échoue avec une erreur `403` « scope does not match », ajoutez la portée exacte mentionnée dans l'erreur. C'est précisément cette prolifération de portées complémentaires qui justifie la recommandation des portées classiques. + +Pour la méthode **Service Account Token**, accordez au jeton `read:jira-work` et `write:jira-work` (ainsi que `read:jira-user`) — ou les équivalents granulaires ci-dessus sans `offline_access`. `offline_access` ne s'applique pas — un jeton de compte de service est longue durée et n'est pas rafraîchi par DefectDojo. + +### Mappage du suivi des tickets + +- **Project Key** : la clé du projet Jira dans lequel créer des tickets, par exemple `SEC`. +- **Issue Type** : le type de ticket à créer, par exemple `Bug` ou `Task`. La valeur par défaut est `Bug`. + +### Détails du mappage de la sévérité + +Les valeurs par défaut correspondent au schéma de priorité par défaut de Jira. Modifiez-les pour correspondre aux noms de priorité de votre projet : + +- **Severity Field Name** : `priority` +- **Info Mapping** : `Lowest` +- **Low Mapping** : `Low` +- **Medium Mapping** : `Medium` +- **High Mapping** : `High` +- **Critical Mapping** : `Highest` + +### Détails du mappage du statut + +Les statuts varient selon le workflow de chaque projet ; ces valeurs par défaut sont donc destinées à être modifiées pour correspondre aux noms de statut de **votre** workflow : + +- **Status Field Name** : `status` +- **Active Mapping** : `To Do` +- **Closed Mapping** : `Done` +- **False Positive Mapping** : `Done` +- **Risk Accepted Mapping** : `Done` + +### Champs personnalisés (facultatif) + +Vous pouvez mapper des champs Jira supplémentaires — par exemple un `resolution` requis à la fermeture, ou des `labels` — dans l'étape **Custom Fields** du mappage. Chaque mappage de champ personnalisé comporte quatre parties : + +- **Source** — d'où provient la valeur : un attribut de la **Constatation**, du **Test**, de l'**Engagement**, ou de l'**Asset** transmis, ou une **valeur statique**. +- **Value** — pour une source de type objet, l'attribut spécifique à lire, choisi dans une liste des champs de cet objet avec des libellés lisibles (par exemple *Severity*, *CVE*, *Mitigation*). Pour une source **valeur statique**, il s'agit d'une zone de texte libre dans laquelle vous saisissez la valeur littérale. +- **Vendor Field** — le champ Jira dans lequel écrire. Comme DefectDojo peut lire le catalogue de champs de Jira, il s'agit d'un sélecteur avec recherche qui liste chaque champ par son **nom d'affichage** et le résout pour vous en identifiant interne — vous sélectionnez donc *DD Close Justification* et DefectDojo stocke `customfield_10255`. Le sélecteur est alimenté à partir de la connexion ; il fonctionne donc une fois la connexion enregistrée et validée. +- **Application point** — *quand* envoyer le champ : à la **création du ticket**, à **chaque mise à jour**, ou dans le cadre d'une **transition** de statut spécifique (Actif / Fermé / Faux positif / Risque accepté). Un champ associé à une transition est envoyé dans le cadre de la modification de cette transition — c'est ainsi que vous fournissez une valeur que Jira n'accepte que sur un écran de transition, le plus souvent un `resolution` que votre workflow exige à la résolution d'un ticket. + +### Modèles de tickets (facultatif) + +Par défaut, les tickets Jira utilisent le titre et le corps intégrés de DefectDojo. Pour les personnaliser, associez un **Ticket Template** au mappage dans son étape **Ticket Template**. Un modèle définit quatre éléments indépendamment facultatifs — le résumé et la description de la **Constatation**, ainsi que le résumé et la description du **Groupe de constatations**. Tout élément laissé vide revient à la valeur par défaut intégrée, ce qui vous permet de ne remplacer que le titre, que le corps, ou les quatre. Utilisez **Test render** dans l'éditeur de modèle pour prévisualiser le rendu à partir de données d'exemple — ce qui permet de détecter des erreurs telles que des espaces réservés inconnus ou des valeurs dépassant la limite de longueur d'un champ — avant d'enregistrer. Si un modèle est ensuite supprimé, les mappages qui l'utilisaient reviennent automatiquement aux valeurs par défaut intégrées. + +### Fonctionnement + +- **Create / Update / Delete :** la création transmet un nouveau ticket et enregistre le lien sur la Constatation ; la mise à jour modifie le ticket existant ; la suppression d'une Constatation force la fermeture de son ticket (rien n'est supprimé dans Jira). Les transmissions peuvent être manuelles (« Push to Integrator ») ou automatiques selon l'Issue Tracker Assignment. +- **Réconciliation du statut :** après la création (et à chaque mise à jour), DefectDojo lit le statut actuel du ticket et, s'il diffère de la cible mappée, recherche une transition de workflow unique permettant de l'atteindre et l'applique. Si aucune transition de ce type n'existe, le mappage enregistre une erreur plutôt que d'échouer silencieusement. Tout champ personnalisé associé à une transition est envoyé avec cette transition. +- **Lien du ticket :** le lien affiché sur la Constatation est `https://your-site.atlassian.net/browse/{ISSUE-KEY}` — toujours l'URL publique de votre site, jamais la passerelle interne. +- **Cycle de vie du jeton (OAuth) :** DefectDojo gère l'intégralité du flux — il effectue l'échange du code d'autorisation, stocke les jetons d'accès et de rafraîchissement, et les rafraîchit à la demande avant chaque transmission, en persistant le nouveau jeton de rafraîchissement à chaque fois (Atlassian le fait pivoter à chaque rafraîchissement). +- **Stockage des identifiants :** tous les identifiants de connexion (mots de passe, jetons, secrets client, jetons OAuth) sont chiffrés au repos et ne sont jamais renvoyés par l'API — la modification d'une connexion affiche un texte indicatif « leave blank to keep » pour les secrets stockés. diff --git a/docs/content/connectors/toolreference/jira.ja.md b/docs/content/connectors/toolreference/jira.ja.md new file mode 100644 index 00000000000..6b436194302 --- /dev/null +++ b/docs/content/connectors/toolreference/jira.ja.md @@ -0,0 +1,118 @@ +--- +title: "Jira" +description: "DefectDojo で Jira のダウンストリームコネクタをセットアップする方法" +weight: 82 +audience: pro +--- +Jira 統合は、DefectDojo の Finding および Finding Group を Jira プロジェクトに Issue としてプッシュし、各 Issue のステータスを Finding と同期し続け、その Finding を作成された Issue にリンクします。Jira **Cloud** と **Data Center / Server** の両方に対応しています。Jira Service Management には対応していません。 + +### Choosing an authentication method + +まず **Jira Deployment** を設定し、続いて **Authentication Method** を選択します。 + +**Jira Cloud** +- **API Token（メールアドレス + トークン）** — Atlassian アカウントのメールアドレスと[API トークン](https://id.atlassian.com/manage-profile/security/api-tokens)を使った HTTP Basic 認証です。呼び出しはサイト URL に対して直接行われます。 +- **OAuth 2.0（推奨）** — ブラウザでの同意操作を一度行うだけで、以降 DefectDojo がトークンの取得と更新を代行します。 +- **Service Account Token** — Atlassian の[サービスアカウント](https://support.atlassian.com/user-management/docs/manage-api-tokens-for-service-accounts/)向けに発行された、スコープ付きの API トークンです。 + +**Jira Data Center / Server** +- **Personal Access Token（推奨）** +- **Username + Password** + +> **Cloud 認証が Jira に到達する仕組み:** OAuth 2.0 と Service Account はいずれも、Atlassian のゲートウェイ — `https://api.atlassian.com/ex/jira/{cloudId}` — に対して Bearer トークンで認証します。これは、あなたの `https://your-site.atlassian.net` というサイト URL とは*別のホスト*です。DefectDojo は API 呼び出しには常にこのゲートウェイを使用しますが、Finding に表示するチケットリンクは常に**サイト URL**から生成するため、ユーザーがクリックするリンクは通常どおりブラウザで開ける `.../browse/{ISSUE-KEY}` 形式のリンクになります。（API Token と Data Center の認証はサイト URL を直接呼び出すため、このような分岐はありません。） + +### Instance Setup + +- **Label** は、この統合を識別するために使用したいラベルを設定します。 +- **Location** は、Jira の**サイト URL**を設定します。例: `https://your-organization.atlassian.net`。この値はブラウザで開けるチケットリンクに使用され、API Token 認証と Data Center 認証では API のベース URL としても使用されます。 +- 残りの項目は、上で選択した認証方法（メールアドレス + API トークン、OAuth クライアント資格情報、サービスアカウントトークン、PAT、またはユーザー名 + パスワード）によって異なります。 + +### OAuth 2.0 setup (Cloud) + +[Atlassian developer console](https://developer.atlassian.com/console/myapps/)で専用のアプリを作成し、DefectDojo から接続します。 + +1. **Create → OAuth 2.0 integration** を選択します。*OAuth 2.0 integration* である必要があります。Connect アプリや Forge アプリでは 3LO 認可コードグラントを使用できません（使用しようとすると `grant_type is not enabled for client` というエラーになります）。 +2. **Access type** の入力を求められたら **Resource-level** を選択します。これにより、トークンのスコープはユーザーが認可した単一の Jira サイトに限定されます。これは、1つの DefectDojo 接続が対象とする範囲とちょうど一致します。（**Account-level** を選択すると、その Atlassian アカウントに属するすべてのサイトへのアクセスが許可されてしまい、必要以上に広い範囲になります。） +3. **Permissions** の下で **Jira platform REST API** を追加し、以下に挙げるスコープを付与します。なお `offline_access` はこの画面には表示されません。これは DefectDojo が認可 URL 内でリクエストする標準の OAuth スコープであり、この画面で追加するものではありません。 +4. **Authorization** の下で、**OAuth 2.0 (3LO)** の横にある **Configure** をクリックし、**Callback URL** を `https:///integrators/jira/oauth/callback` に設定します。この値は DefectDojo のサイト URL と完全に一致している必要があります。これを有効にすることで、認可コードグラントとリフレッシュトークンが使用できるようになります。これを省略すると、`grant_type is not enabled` や `Client is not allowed to use offline_access` といったエラーが発生します。 +5. **Client ID** と **Client Secret** をコピーして DefectDojo のフォームに入力し、**Submit** をクリックして接続を保存します。 +6. **Connect with Jira** をクリックし、同意画面で承認します。Atlassian は DefectDojo にリダイレクトし、DefectDojo がトークンを保存して `cloudId` を自動的に解決します。成功すると「Connected」という表示が現れます。 + +> コールバックのホストは、あなたの DefectDojo の `SITE_URL` です。Atlassian はブラウザをそこにリダイレクトできる必要があり、その値は DefectDojo が送信する値と完全に一致していなければなりません。そのため、社内ネットワークからしか到達できない値ではなく、ユーザーが実際に DefectDojo にアクセスする際に使う正しいホスト名を使用してください。 + +#### Minimum OAuth scopes + +DefectDojo はデフォルトで以下の4つのクラシックスコープをリクエストします。これらは同時に**必要最小限**のスコープでもあり、それぞれが特定の動作を支えています。 + +| Scope | Required for | +|-------|--------------| +| `read:jira-work` | プロジェクト、Issue、利用可能な遷移の読み取り（接続の検証やステータス同期に使用）。 | +| `write:jira-work` | Issue の作成・編集、およびステータス遷移の実行。 | +| `read:jira-user` | 接続時の本人確認 — DefectDojo はアクセス権の検証時に `/myself` を呼び出します。 | +| `offline_access` | **リフレッシュトークン**の発行。これがないと、接続後およそ1時間でアクセストークンが失効し、DefectDojo がそれを更新できなくなるため、接続が機能しなくなります。 | + +Atlassian はグラニュラースコープよりもクラシックスコープの使用を推奨しており、上記の4つでアプリの権限範囲を最小限に保ちつつ、この統合が行うすべての処理をカバーできます。 + +##### Granular scope alternative + +組織の方針でクラシックスコープではなく**グラニュラー**スコープが必要な場合、最小限必要となる同等のスコープセットは以下のとおりです。 + +| Granular scope | Required for | +|----------------|--------------| +| `read:user:jira` | `/myself` による本人確認。 | +| `read:project:jira` | 対象プロジェクトが存在することの検証。 | +| `read:issue:jira` | 同期時に Issue の現在のステータスを読み取る。 | +| `write:issue:jira` | Issue の作成・編集、**およびステータス遷移の実行** — 遷移専用の書き込みスコープは存在せず、遷移も Issue に対する書き込みの一種として扱われます。 | +| `read:issue.transition:jira` | Issue で利用可能な遷移の一覧を取得する。 | +| `offline_access` | リフレッシュトークン（クラシックスコープと同様）。 | + +サイトのフィールド設定によっては、フィールドを展開するために付随する読み取りスコープが追加で必要になる場合があります。最も多いのは `read:status:jira` と `read:field:jira`（作成時にはさらに `read:issue-meta:jira`）です。プッシュが `403`「scope does not match」エラーで失敗した場合は、エラーメッセージに示されている正確なスコープを追加してください。このような付随スコープの広がりこそが、クラシックスコープが推奨される理由です。 + +**Service Account Token** 方式の場合は、トークンに `read:jira-work` と `write:jira-work`（および `read:jira-user`）を付与してください。あるいは、`offline_access` を除いた上記のグラニュラー相当のスコープでも構いません。サービスアカウントトークンは長期間有効で DefectDojo によって更新されることがないため、`offline_access` は適用されません。 + +### Issue Tracker Mapping + +- **Project Key**: Issue を作成する Jira プロジェクトのキーです。例: `SEC` +- **Issue Type**: 作成する Issue の種類です。例: `Bug` や `Task`。デフォルトは `Bug` です。 + +### Severity Mapping Details + +デフォルト値は Jira のデフォルトの優先度スキームに一致しています。プロジェクトの優先度名に合わせて編集してください。 + +- **Severity Field Name**: `priority` +- **Info Mapping**: `Lowest` +- **Low Mapping**: `Low` +- **Medium Mapping**: `Medium` +- **High Mapping**: `High` +- **Critical Mapping**: `Highest` + +### Status Mapping Details + +ステータスはプロジェクトのワークフローごとに異なるため、これらのデフォルト値は**あなたの**ワークフローのステータス名に合わせて編集することを前提としています。 + +- **Status Field Name**: `status` +- **Active Mapping**: `To Do` +- **Closed Mapping**: `Done` +- **False Positive Mapping**: `Done` +- **Risk Accepted Mapping**: `Done` + +### Custom Fields (optional) + +マッピングの **Custom Fields** ステップで、追加の Jira フィールド — 例えばクローズ時に必須となる `resolution` や `labels` など — をマッピングできます。カスタムフィールドのマッピングはそれぞれ4つの要素で構成されます。 + +- **Source** — 値の取得元です。プッシュされる **Finding**、**Test**、**Engagement**、**Asset** のいずれかの属性、または **Static value** です。 +- **Value** — オブジェクトを Source に選んだ場合、読み取る具体的な属性を、そのオブジェクトが持つフィールドの一覧（例えば *Severity*、*CVE*、*Mitigation* のような分かりやすいラベル付き）から選択します。Source が **Static value** の場合は、リテラル値を直接入力するフリーテキストのボックスになります。 +- **Vendor Field** — 書き込み先となる Jira のフィールドです。DefectDojo は Jira のフィールドカタログを読み取れるため、これは各フィールドを**表示名**で一覧表示し、内部 ID に自動的に解決してくれる検索可能なピッカーになっています。そのため、*DD Close Justification* を選択するだけで、DefectDojo は内部的に `customfield_10255` を保存します。このピッカーは接続情報から値を取得するため、接続を保存して検証済みになった後に使用できます。 +- **Application point** — フィールドを送信する*タイミング*です。**ticket creation**（チケット作成時）、**every update**（更新のたびに）、または特定のステータス **transition**（Active / Closed / False Positive / Risk Accepted）の一部として送信するかを選べます。遷移スコープのフィールドは、その遷移の編集内容の一部として送信されます。これは、Jira が遷移画面でのみ受け付ける値 — 多くの場合、Issue を解決する際にワークフローが要求する `resolution` — を渡すための方法です。 + +### Ticket Templates (optional) + +デフォルトでは、Jira の Issue は DefectDojo 組み込みのタイトルと本文を使用します。これをカスタマイズするには、マッピングの **Ticket Template** ステップで**チケットテンプレート**を割り当てます。テンプレートは、**Finding** のサマリーと説明、および **Finding Group** のサマリーと説明という、それぞれ独立して省略可能な4つの要素を定義します。空欄のままにした要素は組み込みのデフォルトにフォールバックするため、タイトルだけ、本文だけ、あるいは4つすべてを上書きすることができます。保存する前に、テンプレートエディタの **Test render** を使ってサンプルデータに対するレンダリング結果をプレビューし、未知のプレースホルダーやフィールドの文字数制限を超える値といったミスを事前に発見できます。テンプレートが後で削除された場合、それを使用していたマッピングは自動的に組み込みのデフォルトに戻ります。 + +### How it works + +- **Create / Update / Delete:** 作成時には新しい Issue がプッシュされ、そのリンクが Finding に記録されます。更新時には既存の Issue が編集されます。Finding を削除すると、対応する Issue は強制的にクローズされます（Jira 側で何かが削除されるわけではありません）。プッシュは手動（「Push to Integrator」）でも、Issue Tracker Assignment の設定に従って自動でも行えます。 +- **Status reconciliation:** 作成後（および更新のたび）、DefectDojo は Issue の現在のステータスを読み取り、マッピング先のステータスと異なる場合は、そこに到達できる単一のワークフロー遷移を探して適用します。該当する遷移が存在しない場合、マッピングはサイレントに失敗するのではなくエラーを記録します。遷移スコープのカスタムフィールドがあれば、その遷移と一緒に送信されます。 +- **Ticket link:** Finding に表示されるリンクは `https://your-site.atlassian.net/browse/{ISSUE-KEY}` の形式で、常にあなたの公開サイト URL であり、内部ゲートウェイではありません。 +- **Token lifecycle (OAuth):** DefectDojo がフロー全体を管理します。認可コードの交換を行い、アクセストークンとリフレッシュトークンを保存し、プッシュの前に必要に応じてトークンを更新し、更新のたびに新しいリフレッシュトークンを保存します（Atlassian は更新のたびにリフレッシュトークンをローテーションします）。 +- **Credential storage:** 接続に関するすべての認証情報（パスワード、トークン、クライアントシークレット、OAuth トークン）は保存時に暗号化され、API を通じて返却されることはありません。接続を編集する際、保存済みのシークレットには「leave blank to keep」（空欄のままにすると現在の値を維持）というプレースホルダーが表示されます。 diff --git a/docs/content/connectors/toolreference/jira.md b/docs/content/connectors/toolreference/jira.md new file mode 100644 index 00000000000..c3e2dac49c0 --- /dev/null +++ b/docs/content/connectors/toolreference/jira.md @@ -0,0 +1,118 @@ +--- +title: "Jira" +description: "How to set up the Jira Downstream Connector for DefectDojo" +weight: 82 +audience: pro +--- +The Jira integration pushes DefectDojo Findings and Finding Groups to a Jira project as issues, keeps each issue's status in sync with the Finding, and links the Finding back to the created issue. Both Jira **Cloud** and **Data Center / Server** are supported. Jira Service Management is not supported. + +### Choosing an authentication method + +Set **Jira Deployment** first, then pick an **Authentication Method**: + +**Jira Cloud** +- **API Token (email + token)** — HTTP Basic auth using an Atlassian account email and an [API token](https://id.atlassian.com/manage-profile/security/api-tokens). Calls go directly to your site URL. +- **OAuth 2.0 (recommended)** — a one-time browser consent; DefectDojo obtains and refreshes the tokens for you. +- **Service Account Token** — a scoped API token created for an Atlassian [service account](https://support.atlassian.com/user-management/docs/manage-api-tokens-for-service-accounts/). + +**Jira Data Center / Server** +- **Personal Access Token (recommended)** +- **Username + Password** + +> **How Cloud auth reaches Jira:** OAuth 2.0 and Service Account both authenticate as a Bearer token against Atlassian's gateway — `https://api.atlassian.com/ex/jira/{cloudId}` — which is a *different host* than your `https://your-site.atlassian.net` site URL. DefectDojo uses the gateway for every API call but always builds the ticket link shown on a Finding from your **site URL**, so the link a user clicks is a normal, browsable `.../browse/{ISSUE-KEY}` link. (API Token and Data Center auth call the site URL directly, so there is no split.) + +### Instance Setup + +- **Label** should be the label you want to use to identify this integration. +- **Location** should be set to your Jira **site URL**, for example `https://your-organization.atlassian.net`. This is used for the browsable ticket links, and — for API Token and Data Center auth — as the API base URL. +- The remaining fields depend on the method you chose above (email + API token, OAuth client credentials, service-account token, PAT, or username + password). + +### OAuth 2.0 setup (Cloud) + +Create a dedicated app in the [Atlassian developer console](https://developer.atlassian.com/console/myapps/), then connect from DefectDojo. + +1. Choose **Create → OAuth 2.0 integration**. It must be an *OAuth 2.0 integration* — a Connect or Forge app cannot use the 3LO authorization-code grant (you'd get `grant_type is not enabled for client`). +2. When prompted for **Access type**, choose **Resource-level**. This scopes the token to the single Jira site the user authorizes, which is exactly what one DefectDojo connection targets. (**Account-level** grants access to every site in the Atlassian account — broader than needed.) +3. Under **Permissions**, add the **Jira platform REST API** and grant the scopes listed below. Note: `offline_access` is *not* listed here — it is a standard OAuth scope DefectDojo requests in the authorization URL, not something you add on this screen. +4. Under **Authorization**, next to **OAuth 2.0 (3LO)** click **Configure** and set the **Callback URL** to `https:///integrators/jira/oauth/callback` — it must match your DefectDojo site URL exactly. Enabling this is what turns on the authorization-code grant and refresh tokens; skipping it causes the `grant_type is not enabled` / `Client is not allowed to use offline_access` errors. +5. Copy the **Client ID** and **Client Secret** into the DefectDojo form and **Submit** to save the connection. +6. Click **Connect with Jira** and approve the consent screen. Atlassian redirects back to DefectDojo, which stores the tokens and resolves your `cloudId` automatically. A "Connected" indicator appears when it succeeds. + +> The callback host is your DefectDojo `SITE_URL`. Atlassian must be able to redirect the browser there, and the value must match what DefectDojo sends exactly — so use the real hostname your users reach DefectDojo at, not a value only reachable from inside the network. + +#### Minimum OAuth scopes + +DefectDojo requests these four classic scopes by default, and they are also the **absolute minimum** required — each one backs a specific behavior: + +| Scope | Required for | +|-------|--------------| +| `read:jira-work` | Reading the project, issues, and available transitions (connection validation and status sync). | +| `write:jira-work` | Creating and editing issues, and executing status transitions. | +| `read:jira-user` | The connection's identity check — DefectDojo calls `/myself` when validating access. | +| `offline_access` | Issuing a **refresh token**. Without it the access token expires (~1 hour after you connect) and the connection stops working, because DefectDojo can no longer refresh it. | + +Atlassian recommends classic scopes over granular ones; the four above keep the app's footprint minimal and are sufficient for everything the integration does. + +##### Granular scope alternative + +If your organization requires **granular** scopes instead of classic, the minimum equivalent set is: + +| Granular scope | Required for | +|----------------|--------------| +| `read:user:jira` | The `/myself` identity check. | +| `read:project:jira` | Validating the target project exists. | +| `read:issue:jira` | Reading an issue's current status during sync. | +| `write:issue:jira` | Creating and editing issues **and executing status transitions** — there is no separate transition-write scope; a transition is a write to the issue. | +| `read:issue.transition:jira` | Listing the transitions available on an issue. | +| `offline_access` | The refresh token (same as classic). | + +Depending on your site's field configuration, an endpoint may also require companion read scopes to expand fields — most commonly `read:status:jira` and `read:field:jira` (and `read:issue-meta:jira` for create). If a push fails with a `403` "scope does not match" error, add the exact scope named in the error. This companion-scope sprawl is precisely why classic scopes are recommended. + +For the **Service Account Token** method, grant the token `read:jira-work` and `write:jira-work` (plus `read:jira-user`) — or the granular equivalents above without `offline_access`. `offline_access` does not apply — a service-account token is long-lived and is not refreshed by DefectDojo. + +### Issue Tracker Mapping + +- **Project Key**: the key of the Jira project to create issues in, for example `SEC`. +- **Issue Type**: the issue type to create, for example `Bug` or `Task`. Defaults to `Bug`. + +### Severity Mapping Details + +Defaults match Jira's default priority scheme. Edit them to match the priority names in your project: + +- **Severity Field Name**: `priority` +- **Info Mapping**: `Lowest` +- **Low Mapping**: `Low` +- **Medium Mapping**: `Medium` +- **High Mapping**: `High` +- **Critical Mapping**: `Highest` + +### Status Mapping Details + +Statuses vary per project workflow, so these defaults are meant to be edited to **your** workflow's status names: + +- **Status Field Name**: `status` +- **Active Mapping**: `To Do` +- **Closed Mapping**: `Done` +- **False Positive Mapping**: `Done` +- **Risk Accepted Mapping**: `Done` + +### Custom Fields (optional) + +You can map additional Jira fields — for example a required `resolution` on close, or `labels` — in the mapping's **Custom Fields** step. Each custom-field mapping has four parts: + +- **Source** — where the value comes from: an attribute of the **Finding**, **Test**, **Engagement**, or **Asset** being pushed, or a **Static value**. +- **Value** — for an object source, the specific attribute to read, chosen from a list of that object's fields with human-readable labels (for example *Severity*, *CVE*, *Mitigation*). For a **Static value** source this is a free-text box you type the literal value into. +- **Vendor Field** — the Jira field to write to. Because DefectDojo can read Jira's field catalog, this is a searchable picker that lists each field by its **display name** and resolves it to the internal id for you — so you select *DD Close Justification* and DefectDojo stores `customfield_10255`. The picker is populated from the connection, so it works once the connection is saved and validated. +- **Application point** — *when* to send the field: on **ticket creation**, on **every update**, or as part of a specific status **transition** (Active / Closed / False Positive / Risk Accepted). A transition-scoped field is sent as part of that transition's edit — this is how you supply a value Jira only accepts on a transition screen, most commonly a `resolution` your workflow requires when an issue is resolved. + +### Ticket Templates (optional) + +By default Jira issues use DefectDojo's built-in title and body. To customize them, attach a **Ticket Template** to the mapping in its **Ticket Template** step. A template defines four independently-optional pieces — the **Finding** summary and description, and the **Finding Group** summary and description. Any piece left blank falls back to the built-in default, so you can override just the title, just the body, or all four. Use **Test render** in the template editor to preview the rendered output against sample data — catching mistakes such as unknown placeholders or values that exceed a field's length limit — before saving. If a template is later deleted, the mappings that used it revert to the built-in defaults automatically. + +### How it works + +- **Create / Update / Delete:** creating pushes a new issue and records the link on the Finding; updating edits the existing issue; deleting a Finding force-closes its issue (nothing is deleted in Jira). Pushes can be manual ("Push to Integrator") or automatic per the Issue Tracker Assignment. +- **Status reconciliation:** after creating (and on every update) DefectDojo reads the issue's current status and, if it differs from the mapped target, finds a single workflow transition that reaches it and applies it. If no such transition exists, the mapping records an error rather than failing silently. Any transition-scoped custom fields are sent with that transition. +- **Ticket link:** the link surfaced on the Finding is `https://your-site.atlassian.net/browse/{ISSUE-KEY}` — always your public site URL, never the internal gateway. +- **Token lifecycle (OAuth):** DefectDojo owns the whole flow — it performs the authorization-code exchange, stores the access and refresh tokens, and refreshes on demand before a push, persisting the new refresh token each time (Atlassian rotates it on every refresh). +- **Credential storage:** all connection credentials (passwords, tokens, client secrets, OAuth tokens) are encrypted at rest and are never returned through the API — editing a connection shows a "leave blank to keep" placeholder for stored secrets. diff --git a/docs/content/connectors/toolreference/jsm_assets.de.md b/docs/content/connectors/toolreference/jsm_assets.de.md new file mode 100644 index 00000000000..6568e6bbf9d --- /dev/null +++ b/docs/content/connectors/toolreference/jsm_assets.de.md @@ -0,0 +1,21 @@ +--- +title: "Jira Service Management Assets" +description: "Einrichtung des Jira Service Management Assets Upstream-Connectors für DefectDojo" +weight: 83 +audience: pro +--- +Der JSM-Assets-Connector ist ein **Asset-Connector**: Er zählt die Objekte in Ihrem Jira-Service-Management-Assets-Workspace (ehemals Insight) auf und erstellt für jedes Objekt ein DefectDojo-Asset, gruppiert in Organisationen nach Objektschema. Es werden keine Befunde importiert. + +#### Voraussetzungen + +* Assets erfordert einen **Jira-Service-Management-Premium- oder -Enterprise-Plan**. Bei Free- oder Standard-Plänen antwortet die Assets-API mit `403 "Access to Assets API was denied"`, obwohl der Rest der Site funktioniert. +* Das verwendete Atlassian-Konto muss auf der Site über **Jira-Service-Management-Produktzugriff** verfügen (einen Agent-Sitzplatz) — reiner Site-Zugriff genügt nicht. +* Erstellen Sie ein klassisches Atlassian-API-Token unter [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens). Wir empfehlen ein dediziertes Service-Konto. + +#### Connector-Zuordnungen + +1. Geben Sie Ihre Atlassian-Site-URL in das Feld **Location** ein: `https://{your-site}.atlassian.net`. +2. Geben Sie die Atlassian-Konto-E-Mail-Adresse, zu der das Token gehört, in das Feld **Email** ein. +3. Geben Sie das API-Token in das Feld **Secret** ein. + +Jedes Assets-Objekt wird zu einem nach dem Label des Objekts benannten Eintrag, gruppiert nach seinem **Objektschema**. diff --git a/docs/content/connectors/toolreference/jsm_assets.es.md b/docs/content/connectors/toolreference/jsm_assets.es.md new file mode 100644 index 00000000000..23a5e704fbf --- /dev/null +++ b/docs/content/connectors/toolreference/jsm_assets.es.md @@ -0,0 +1,21 @@ +--- +title: "Jira Service Management Assets" +description: "Cómo configurar el Conector Upstream de Jira Service Management Assets para DefectDojo" +weight: 83 +audience: pro +--- +El conector JSM Assets es un **conector de activos**: enumera los objetos de su espacio de trabajo de Jira Service Management Assets (anteriormente Insight) y crea un Activo de DefectDojo para cada objeto, agrupados en Organizaciones según el esquema del objeto. No se importa ningún hallazgo. + +#### Requisitos previos + +* Assets requiere un plan **Jira Service Management Premium o Enterprise**. En los planes Free o Standard, la API de Assets responde con `403 "Access to Assets API was denied"`, aunque el resto del sitio funcione con normalidad. +* La cuenta de Atlassian utilizada debe tener **acceso de producto a Jira Service Management** (una plaza de agente) en el sitio — el acceso al sitio por sí solo no es suficiente. +* Cree un token de API clásico de Atlassian en [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens). Recomendamos una cuenta de servicio dedicada. + +#### Asignaciones del conector + +1. Introduzca la URL de su sitio de Atlassian en el campo **Location**: `https://{your-site}.atlassian.net`. +2. Introduzca el correo electrónico de la cuenta de Atlassian al que pertenece el token en el campo **Email**. +3. Introduzca el token de API en el campo **Secret**. + +Cada objeto de Assets se convierte en un Registro con el nombre de la etiqueta del objeto, agrupado por su **esquema de objeto**. diff --git a/docs/content/connectors/toolreference/jsm_assets.fr.md b/docs/content/connectors/toolreference/jsm_assets.fr.md new file mode 100644 index 00000000000..6d9bc854adc --- /dev/null +++ b/docs/content/connectors/toolreference/jsm_assets.fr.md @@ -0,0 +1,21 @@ +--- +title: "Jira Service Management Assets" +description: "Comment configurer le Connecteur Upstream Jira Service Management Assets pour DefectDojo" +weight: 83 +audience: pro +--- +Le connecteur JSM Assets est un **Connecteur d'actifs** : il énumère les objets de votre espace de travail Jira Service Management Assets (anciennement Insight) et crée un Actif DefectDojo pour chaque objet, regroupés en Organisations par schéma d'objet. Aucune constatation n'est importée. + +#### Prérequis + +* Assets nécessite un plan **Jira Service Management Premium ou Enterprise**. Sur les plans Free ou Standard, l'API Assets répond avec `403 "Access to Assets API was denied"`, même si le reste du site fonctionne. +* Le compte Atlassian utilisé doit disposer d'un **accès produit Jira Service Management** (un siège agent) sur le site — l'accès au site seul ne suffit pas. +* Créez un jeton API Atlassian classique sur [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens). Nous recommandons un compte de service dédié. + +#### Mappages du connecteur + +1. Saisissez l'URL de votre site Atlassian dans le champ **Location** : `https://{your-site}.atlassian.net`. +2. Saisissez l'e-mail du compte Atlassian auquel appartient le jeton dans le champ **Email**. +3. Saisissez le jeton API dans le champ **Secret**. + +Chaque objet Assets devient un Enregistrement nommé d'après le libellé de l'objet, regroupé par son **schéma d'objet**. diff --git a/docs/content/connectors/toolreference/jsm_assets.ja.md b/docs/content/connectors/toolreference/jsm_assets.ja.md new file mode 100644 index 00000000000..ad254730782 --- /dev/null +++ b/docs/content/connectors/toolreference/jsm_assets.ja.md @@ -0,0 +1,21 @@ +--- +title: "Jira Service Management Assets" +description: "DefectDojo で Jira Service Management Assets の Upstream Connector をセットアップする方法" +weight: 83 +audience: pro +--- +JSM Assetsコネクタは**Asset Connector**です。お使いのJira Service Management Assets(旧Insight)ワークスペース内のオブジェクトを列挙し、それぞれのオブジェクトに対してDefectDojoのAssetを作成します。オブジェクトスキーマごとにOrganizationsにグループ化されます。検出事項はインポートされません。 + +#### Prerequisites + +* AssetsはJira Service Managementの**PremiumまたはEnterprise**プランが必要です。FreeまたはStandardプランでは、サイトの他の部分は動作していても、Assets APIは`403 "Access to Assets API was denied"`を返します。 +* トークンに紐づくAtlassianアカウントは、そのサイトで**Jira Service Managementの製品アクセス権**(エージェントシート)を持っている必要があります。サイトへのアクセスだけでは不十分です。 +* [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens)でクラシックなAtlassian APIトークンを作成します。専用のサービスアカウントの使用をお勧めします。 + +#### Connector Mappings + +1. **Location**フィールドにAtlassianサイトのURLを入力します: `https://{your-site}.atlassian.net`。 +2. **Email**フィールドに、トークンが属するAtlassianアカウントのメールアドレスを入力します。 +3. **Secret**フィールドにAPIトークンを入力します。 + +各AssetsオブジェクトはオブジェクトのラベルにちなんだRecordとなり、その**object schema**でグループ化されます。 diff --git a/docs/content/connectors/toolreference/jsm_assets.md b/docs/content/connectors/toolreference/jsm_assets.md new file mode 100644 index 00000000000..41f7afe5047 --- /dev/null +++ b/docs/content/connectors/toolreference/jsm_assets.md @@ -0,0 +1,21 @@ +--- +title: "JSM Assets" +description: "How to set up the JSM Assets Upstream Connector for DefectDojo" +weight: 83 +audience: pro +--- +The JSM Assets connector is an **Asset Connector**: it enumerates the objects in your Jira Service Management Assets (formerly Insight) workspace and creates a DefectDojo Asset for each object, grouped into Organizations by object schema. No findings are imported. + +#### Prerequisites + +* Assets requires a **Jira Service Management Premium or Enterprise** plan. On Free or Standard plans the Assets API responds with `403 "Access to Assets API was denied"`, even though the rest of the site works. +* The Atlassian account used must have **Jira Service Management product access** (an agent seat) on the site — site access alone is not enough. +* Create a classic Atlassian API token at [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens). We recommend a dedicated service account. + +#### Connector Mappings + +1. Enter your Atlassian site URL in the **Location** field: `https://{your-site}.atlassian.net`. +2. Enter the Atlassian account email the token belongs to in the **Email** field. +3. Enter the API token in the **Secret** field. + +Each Assets object becomes a Record named after the object's label, grouped by its **object schema**. diff --git a/docs/content/connectors/toolreference/klocwork.md b/docs/content/connectors/toolreference/klocwork.md new file mode 100644 index 00000000000..26dc72a6960 --- /dev/null +++ b/docs/content/connectors/toolreference/klocwork.md @@ -0,0 +1,20 @@ +--- +title: "Klocwork" +description: "How to set up the Klocwork Upstream Connector for DefectDojo" +weight: 84 +audience: pro +--- +The Klocwork connector imports **static analysis (SAST) findings** from a Perforce Klocwork server. DefectDojo enumerates the server's projects and creates a Record for each **project**. + +#### Prerequisites + +A Klocwork **username** and its **login token (`ltoken`)** — the token generated by `kwauth` and stored in the ltoken file. The token is never logged. + +#### Connector Mappings + +1. Enter your Klocwork server URL in the **Location** field. +2. Enter the Klocwork username the token belongs to in the **Username** field. +3. Enter the login token in the **Login Token (ltoken)** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each Klocwork project becomes a Record. Only issues Klocwork classes as **actionable** are imported, and only from each project's **latest build** — so the findings describe the current state of the project rather than accumulating across builds. diff --git a/docs/content/connectors/toolreference/kubescape.de.md b/docs/content/connectors/toolreference/kubescape.de.md new file mode 100644 index 00000000000..a11bdc2c5d5 --- /dev/null +++ b/docs/content/connectors/toolreference/kubescape.de.md @@ -0,0 +1,20 @@ +--- +title: "Kubescape" +description: "Einrichtung des Kubescape Upstream-Connectors für DefectDojo" +weight: 85 +audience: pro +--- +Der Kubescape-Connector liest Kubernetes-Posture(Fehlkonfigurations)-Ergebnisse, die vom [Kubescape-Operator](https://kubescape.io/docs/install-operator/) erzeugt werden, direkt aus der Kubernetes-API des Clusters — ein ARMO-SaaS-Konto ist nicht erforderlich. Er liest die `WorkloadConfigurationScan`-Objekte, die von der im Cluster laufenden Storage-Aggregated-API des Operators bereitgestellt werden (`spdx.softwarecomposition.kubescape.io/v1beta1`). Jeder Kubernetes-**Namespace** mit Posture-Ergebnissen wird einem Eintrag (Produkt) zugeordnet; jede fehlgeschlagene Kontrolle auf einer Workload wird zu einem Befund. + +#### Voraussetzungen + +- Der Kubescape-Operator muss im Zielcluster mit aktiviertem Konfigurations-Scanning installiert sein (siehe [Installing in your cluster](https://kubescape.io/docs/install-operator/)). Bestätigen Sie mit `kubectl get workloadconfigurationscans -A`, dass Ergebnisse vorhanden sind. +- Eine **kubeconfig**, die Lesezugriff auf die API-Gruppe `spdx.softwarecomposition.kubescape.io` gewährt (list/get auf `workloadconfigurationscans`) für den Zielcluster. + +#### Connector-Zuordnungen + +1. Geben Sie die API-Server-URL des Clusters (oder eine sprechende Cluster-Kennung) in das Feld **Location** ein. +2. Fügen Sie die **kubeconfig** für den Zielcluster in das Feld `kubeconfig` ein. Setzen Sie optional `kube_context`, um einen Kontext darin auszuwählen, und `cluster_name`, um die ermittelten Produkte zu beschriften. +3. Jeder Namespace mit Posture-Ergebnissen wird als Eintrag ermittelt; ordnen Sie die gewünschten den DefectDojo-Produkten zu. + +Befunde werden pro fehlgeschlagener Kontrolle abgeleitet: Der Kontrollname und die Workload identifizieren den Befund, der Schweregrad stammt aus dem Score-Faktor der Kontrolle, die Kontroll-ID wird zur Schwachstellen-ID, und jeder Befund verlinkt auf seine Kontrollreferenz unter `https://hub.armosec.io/docs/`. diff --git a/docs/content/connectors/toolreference/kubescape.es.md b/docs/content/connectors/toolreference/kubescape.es.md new file mode 100644 index 00000000000..4a325a34671 --- /dev/null +++ b/docs/content/connectors/toolreference/kubescape.es.md @@ -0,0 +1,20 @@ +--- +title: "Kubescape" +description: "Cómo configurar el Conector Upstream de Kubescape para DefectDojo" +weight: 85 +audience: pro +--- +El conector Kubescape lee los resultados de postura (configuraciones incorrectas) de Kubernetes generados por el [operador de Kubescape](https://kubescape.io/docs/install-operator/) directamente desde la API de Kubernetes del clúster — no se requiere ninguna cuenta SaaS de ARMO. Lee los objetos `WorkloadConfigurationScan` que expone la API agregada de almacenamiento dentro del clúster del operador (`spdx.softwarecomposition.kubescape.io/v1beta1`). Cada **namespace** de Kubernetes que tiene resultados de postura se asigna a un Registro (Producto); cada control fallido de una carga de trabajo se convierte en un Hallazgo. + +#### Requisitos previos + +- El operador de Kubescape debe estar instalado en el clúster de destino con el escaneo de configuración habilitado (consulte [Instalación en su clúster](https://kubescape.io/docs/install-operator/)). Confirme que existen resultados con `kubectl get workloadconfigurationscans -A`. +- Un **kubeconfig** que otorgue acceso de lectura al grupo de API `spdx.softwarecomposition.kubescape.io` (list/get sobre `workloadconfigurationscans`) para el clúster de destino. + +#### Asignaciones del conector + +1. Introduzca la URL del servidor de API del clúster (o un identificador descriptivo del clúster) en el campo **Location**. +2. Pegue el **kubeconfig** del clúster de destino en el campo `kubeconfig`. Opcionalmente, establezca `kube_context` para seleccionar un contexto dentro de él, y `cluster_name` para etiquetar los Productos detectados. +3. Cada namespace con resultados de postura se detecta como un Registro; mapee los que desee importar a Productos de DefectDojo. + +Los hallazgos se derivan por control fallido: el nombre del control y la carga de trabajo identifican el Hallazgo, la severidad proviene del factor de puntuación del control, el ID del control se convierte en el ID de vulnerabilidad, y cada Hallazgo enlaza con su referencia de control en `https://hub.armosec.io/docs/`. diff --git a/docs/content/connectors/toolreference/kubescape.fr.md b/docs/content/connectors/toolreference/kubescape.fr.md new file mode 100644 index 00000000000..e93c3916fd9 --- /dev/null +++ b/docs/content/connectors/toolreference/kubescape.fr.md @@ -0,0 +1,20 @@ +--- +title: "Kubescape" +description: "Comment configurer le Connecteur Upstream Kubescape pour DefectDojo" +weight: 85 +audience: pro +--- +Le connecteur Kubescape lit les résultats de posture Kubernetes (mauvaises configurations) produits par l'[opérateur Kubescape](https://kubescape.io/docs/install-operator/) directement depuis l'API Kubernetes du cluster — aucun compte SaaS ARMO n'est requis. Il lit les objets `WorkloadConfigurationScan` servis par l'API agrégée de stockage in-cluster de l'opérateur (`spdx.softwarecomposition.kubescape.io/v1beta1`). Chaque **espace de noms** Kubernetes disposant de résultats de posture est mappé à un Enregistrement (Produit) ; chaque contrôle échoué sur une charge de travail devient une Constatation. + +#### Prérequis + +- L'opérateur Kubescape doit être installé dans le cluster cible avec l'analyse de configuration activée (voir [Installing in your cluster](https://kubescape.io/docs/install-operator/)). Confirmez l'existence de résultats avec `kubectl get workloadconfigurationscans -A`. +- Un **kubeconfig** accordant un accès en lecture au groupe d'API `spdx.softwarecomposition.kubescape.io` (list/get sur `workloadconfigurationscans`) pour le cluster cible. + +#### Mappages du connecteur + +1. Saisissez l'URL du serveur API du cluster (ou un identifiant convivial du cluster) dans le champ **Location**. +2. Collez le **kubeconfig** du cluster cible dans le champ `kubeconfig`. Vous pouvez éventuellement définir `kube_context` pour sélectionner un contexte à l'intérieur de celui-ci, et `cluster_name` pour étiqueter les Produits découverts. +3. Chaque espace de noms disposant de résultats de posture est découvert comme un Enregistrement ; mappez ceux que vous souhaitez importer vers des Produits DefectDojo. + +Les constatations sont dérivées par contrôle échoué : le nom du contrôle et la charge de travail identifient la Constatation, la sévérité provient du facteur de score du contrôle, l'identifiant du contrôle devient l'identifiant de vulnérabilité, et chaque Constatation renvoie vers sa référence de contrôle à l'adresse `https://hub.armosec.io/docs/`. diff --git a/docs/content/connectors/toolreference/kubescape.ja.md b/docs/content/connectors/toolreference/kubescape.ja.md new file mode 100644 index 00000000000..5c56cecacac --- /dev/null +++ b/docs/content/connectors/toolreference/kubescape.ja.md @@ -0,0 +1,20 @@ +--- +title: "Kubescape" +description: "DefectDojo で Kubescape の Upstream Connector をセットアップする方法" +weight: 85 +audience: pro +--- +Kubescapeコネクタは、[Kubescapeオペレーター](https://kubescape.io/docs/install-operator/)によって生成されたKubernetesのposture(構成不備)結果を、クラスタのKubernetes APIから直接読み取ります — ARMO SaaSアカウントは不要です。オペレーターのクラスタ内ストレージ集約APIが提供する`WorkloadConfigurationScan`オブジェクト(`spdx.softwarecomposition.kubescape.io/v1beta1`)を読み取ります。posture結果を持つ各Kubernetesの**namespace**はRecord(Product)にマッピングされ、ワークロード上の失敗したcontrolはそれぞれFindingになります。 + +#### Prerequisites + +- 対象クラスタでKubescapeオペレーターがインストールされ、構成スキャンが有効になっている必要があります([クラスタへのインストール](https://kubescape.io/docs/install-operator/)を参照)。`kubectl get workloadconfigurationscans -A`で結果が存在することを確認してください。 +- 対象クラスタの`spdx.softwarecomposition.kubescape.io` APIグループ(`workloadconfigurationscans`に対するlist/get)への読み取りアクセスを許可する**kubeconfig**。 + +#### Connector Mappings + +1. **Location**フィールドにクラスタのAPIサーバーURL(またはわかりやすいクラスタ識別子)を入力します。 +2. `kubeconfig`フィールドに対象クラスタの**kubeconfig**を貼り付けます。必要に応じて`kube_context`でその中のコンテキストを選択し、`cluster_name`で検出されるProductにラベルを付けられます。 +3. posture結果を持つ各namespaceがRecordとして検出されます。DefectDojoのProductにマッピングしたいものを選択してください。 + +検出事項は失敗したcontrolごとに導出されます。control名とワークロードがFindingを識別し、深刻度はcontrolのスコア係数から取得され、control IDが脆弱性IDになり、各Findingは`https://hub.armosec.io/docs/`のcontrolリファレンスにリンクします。 diff --git a/docs/content/connectors/toolreference/kubescape.md b/docs/content/connectors/toolreference/kubescape.md new file mode 100644 index 00000000000..41255e273c5 --- /dev/null +++ b/docs/content/connectors/toolreference/kubescape.md @@ -0,0 +1,20 @@ +--- +title: "Kubescape" +description: "How to set up the Kubescape Upstream Connector for DefectDojo" +weight: 85 +audience: pro +--- +The Kubescape connector reads Kubernetes posture (misconfiguration) results produced by the [Kubescape operator](https://kubescape.io/docs/install-operator/) directly from the cluster's Kubernetes API — no ARMO SaaS account is required. It reads the `WorkloadConfigurationScan` objects served by the operator's in-cluster storage aggregated API (`spdx.softwarecomposition.kubescape.io/v1beta1`). Each Kubernetes **namespace** that has posture results is mapped to a Record (Asset); each failed control on a workload becomes a Finding. + +#### Prerequisites + +- The Kubescape operator must be installed in the target cluster with configuration scanning enabled (see [Installing in your cluster](https://kubescape.io/docs/install-operator/)). Confirm results exist with `kubectl get workloadconfigurationscans -A`. +- A **kubeconfig** granting read access to the `spdx.softwarecomposition.kubescape.io` API group (list/get on `workloadconfigurationscans`) for the target cluster. + +#### Connector Mappings + +1. Enter the cluster's API server URL (or a friendly cluster identifier) in the **Location** field. +2. Paste the **kubeconfig** for the target cluster in the `kubeconfig` field. Optionally set `kube_context` to select a context within it, and `cluster_name` to label the discovered Assets. +3. Each namespace with posture results is discovered as a Record; map the ones you want to import to DefectDojo Assets. + +Findings are derived per failed control: the control name and workload identify the Finding, severity comes from the control's score factor, the control ID becomes the vulnerability ID, and each Finding links to its control reference at `https://hub.armosec.io/docs/`. diff --git a/docs/content/connectors/toolreference/lacework_forticnapp.de.md b/docs/content/connectors/toolreference/lacework_forticnapp.de.md new file mode 100644 index 00000000000..77262b0a848 --- /dev/null +++ b/docs/content/connectors/toolreference/lacework_forticnapp.de.md @@ -0,0 +1,21 @@ +--- +title: "Lacework / FortiCNAPP" +description: "Einrichtung des Lacework / FortiCNAPP Upstream-Connectors für DefectDojo" +weight: 86 +audience: pro +--- +Der Lacework-/FortiCNAPP-Connector verwendet die Lacework-v2-API, um **Host- und Container-Schwachstellen** für Ihr gesamtes Lacework-Konto zu importieren. + +#### Voraussetzungen + +Sie benötigen einen Lacework-**API-Schlüssel** — eine API-Key-ID und ein Secret, erstellt in der Lacework-Konsole unter **Settings → API keys**. Der Connector tauscht diese bei jedem Sync gegen ein kurzlebiges Zugriffstoken ein; Key-ID, Secret und Token werden nie protokolliert. + +#### Connector-Zuordnungen + +1. Geben Sie Ihre Lacework-Konto-URL in das Feld **Location** ein — zum Beispiel `https://YOUR-ACCOUNT.lacework.net` (ein bloßer Kontoname wird ebenfalls akzeptiert). +2. Geben Sie die **API Key ID** und das **API Secret** ein. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo ordnet das Lacework-**Konto** einem Eintrag zu (der gesamte Konto-Geltungsbereich). Jede **Container**- und **Host**-Schwachstelle wird zu einem Befund: Der Schweregrad stammt aus Laceworks eigener Bewertung, das betroffene Paket und die Version werden zur Komponente, die Fix-Version wird zur Abhilfemaßnahme, und das betroffene Image/der betroffene Host wird als Tags erfasst. Container-Schwachstellen werden als statische Befunde erfasst (Image-Scans) und Host-Schwachstellen als dynamische Befunde (Scans laufender Hosts). + +Weitere Informationen finden Sie in der [Lacework-API-Dokumentation](https://docs.lacework.net/api/v2/docs). diff --git a/docs/content/connectors/toolreference/lacework_forticnapp.es.md b/docs/content/connectors/toolreference/lacework_forticnapp.es.md new file mode 100644 index 00000000000..153696f494a --- /dev/null +++ b/docs/content/connectors/toolreference/lacework_forticnapp.es.md @@ -0,0 +1,21 @@ +--- +title: "Lacework / FortiCNAPP" +description: "Cómo configurar el Conector Upstream de Lacework / FortiCNAPP para DefectDojo" +weight: 86 +audience: pro +--- +El conector Lacework / FortiCNAPP usa la API v2 de Lacework para importar **vulnerabilidades de hosts y contenedores** de toda su cuenta de Lacework. + +#### Requisitos previos + +Necesitará una **API key** de Lacework — un ID de clave de API y un secreto, creados en la consola de Lacework en **Settings → API keys**. El conector los intercambia por un token de acceso de corta duración en cada sincronización; el ID de clave, el secreto y el token nunca se registran en los logs. + +#### Asignaciones del conector + +1. Introduzca la URL de su cuenta de Lacework en el campo **Location** — por ejemplo `https://YOUR-ACCOUNT.lacework.net` (también se acepta un nombre de cuenta simple). +2. Introduzca el **API Key ID** y el **API Secret**. +3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo asigna la **cuenta** de Lacework a un Registro (el ámbito de toda la cuenta). Cada vulnerabilidad de **contenedor** y de **host** se convierte en un hallazgo: la severidad proviene de la propia calificación de Lacework, el paquete y la versión afectados se convierten en el componente, la versión de corrección se convierte en la mitigación, y la imagen/host afectado se registra como etiquetas. Las vulnerabilidades de contenedor se registran como hallazgos estáticos (escaneos de imagen) y las vulnerabilidades de host como hallazgos dinámicos (escaneos de host en ejecución). + +Consulte la [documentación de la API de Lacework](https://docs.lacework.net/api/v2/docs) para obtener más información. diff --git a/docs/content/connectors/toolreference/lacework_forticnapp.fr.md b/docs/content/connectors/toolreference/lacework_forticnapp.fr.md new file mode 100644 index 00000000000..0e26a460d92 --- /dev/null +++ b/docs/content/connectors/toolreference/lacework_forticnapp.fr.md @@ -0,0 +1,21 @@ +--- +title: "Lacework / FortiCNAPP" +description: "Comment configurer le Connecteur Upstream Lacework / FortiCNAPP pour DefectDojo" +weight: 86 +audience: pro +--- +Le connecteur Lacework / FortiCNAPP utilise l'API Lacework v2 pour importer les **vulnérabilités des hôtes et des conteneurs** de l'ensemble de votre compte Lacework. + +#### Prérequis + +Vous aurez besoin d'une **clé API** Lacework — un identifiant de clé API et un secret, créés dans la console Lacework sous **Settings → API keys**. Le connecteur les échange contre un jeton d'accès de courte durée à chaque synchronisation ; l'identifiant de clé, le secret et le jeton ne sont jamais journalisés. + +#### Mappages du connecteur + +1. Saisissez l'URL de votre compte Lacework dans le champ **Location** — par exemple `https://YOUR-ACCOUNT.lacework.net` (un simple nom de compte est également accepté). +2. Saisissez l'**API Key ID** et l'**API Secret**. +3. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. + +DefectDojo mappe le **compte** Lacework à un Enregistrement (le périmètre de l'ensemble du compte). Chaque vulnérabilité de **conteneur** et d'**hôte** devient une constatation : la sévérité provient de la notation propre à Lacework, le paquet et la version affectés deviennent le composant, la version corrigée devient l'atténuation, et l'image/hôte affecté est enregistré sous forme d'étiquettes. Les vulnérabilités de conteneurs sont enregistrées comme constatations statiques (scans d'image) et les vulnérabilités d'hôtes comme constatations dynamiques (scans d'hôte en cours d'exécution). + +Consultez la [documentation de l'API Lacework](https://docs.lacework.net/api/v2/docs) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/lacework_forticnapp.ja.md b/docs/content/connectors/toolreference/lacework_forticnapp.ja.md new file mode 100644 index 00000000000..f4fb063128f --- /dev/null +++ b/docs/content/connectors/toolreference/lacework_forticnapp.ja.md @@ -0,0 +1,21 @@ +--- +title: "Lacework / FortiCNAPP" +description: "DefectDojo で Lacework / FortiCNAPP の Upstream Connector をセットアップする方法" +weight: 86 +audience: pro +--- +Lacework / FortiCNAPPコネクタは、Lacework v2 APIを使用して、Laceworkアカウント全体の**ホストおよびコンテナの脆弱性**をインポートします。 + +#### Prerequisites + +Laceworkの**APIキー**(APIキーIDとシークレット)が必要です。これはLaceworkコンソールの**Settings → API keys**で作成します。コネクタは同期のたびにこれらを短命のアクセストークンと交換します。キーID、シークレット、トークンはログに記録されません。 + +#### Connector Mappings + +1. **Location**フィールドにLaceworkのアカウントURLを入力します — 例: `https://YOUR-ACCOUNT.lacework.net`(アカウント名のみでも受け付けられます)。 +2. **API Key ID**と**API Secret**を入力します。 +3. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。 + +DefectDojoはLaceworkの**アカウント**をRecord(アカウント全体のスコープ)にマッピングします。各**container**と**host**の脆弱性はそれぞれ検出事項になります。深刻度はLacework独自の評価から取得され、影響を受けるパッケージとバージョンがcomponentになり、修正バージョンがmitigationになり、影響を受けるイメージ/ホストはタグとして記録されます。コンテナの脆弱性は静的検出事項(イメージスキャン)として、ホストの脆弱性は動的検出事項(実行中ホストのスキャン)として記録されます。 + +詳細については、[Lacework APIドキュメント](https://docs.lacework.net/api/v2/docs)を参照してください。 diff --git a/docs/content/connectors/toolreference/lacework_forticnapp.md b/docs/content/connectors/toolreference/lacework_forticnapp.md new file mode 100644 index 00000000000..a81a7561a1b --- /dev/null +++ b/docs/content/connectors/toolreference/lacework_forticnapp.md @@ -0,0 +1,21 @@ +--- +title: "Lacework / FortiCNAPP" +description: "How to set up the Lacework / FortiCNAPP Upstream Connector for DefectDojo" +weight: 86 +audience: pro +--- +The Lacework / FortiCNAPP connector uses the Lacework v2 API to import **host and container vulnerabilities** for your whole Lacework account. + +#### Prerequisites + +You will need a Lacework **API key** — an API key id and secret, created in the Lacework console under **Settings → API keys**. The connector exchanges these for a short-lived access token on each sync; the key id, secret and token are never logged. + +#### Connector Mappings + +1. Enter your Lacework account URL in the **Location** field — for example `https://YOUR-ACCOUNT.lacework.net` (a bare account name is also accepted). +2. Enter the **API Key ID** and **API Secret**. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo maps the Lacework **account** to a Record (the whole-account scope). Each **container** and **host** vulnerability becomes a finding: the severity comes from Lacework's own rating, the affected package and version become the component, the fix version becomes the mitigation, and the affected image/host is recorded as tags. Container vulnerabilities are recorded as static findings (image scans) and host vulnerabilities as dynamic findings (running-host scans). + +See the [Lacework API documentation](https://docs.lacework.net/api/v2/docs) for more information. diff --git a/docs/content/connectors/toolreference/linear.de.md b/docs/content/connectors/toolreference/linear.de.md new file mode 100644 index 00000000000..0e38f5b2acf --- /dev/null +++ b/docs/content/connectors/toolreference/linear.de.md @@ -0,0 +1,46 @@ +--- +title: "Linear" +description: "Einrichtung des Linear Downstream-Connectors für DefectDojo" +weight: 87 +audience: pro +--- +Die Linear-Integration ermöglicht es Ihnen, DefectDojo-Befunde als [Linear](https://linear.app/)-Issues zu übertragen. Issues werden in einem Team in Ihrem Linear-Workspace erstellt. + +### Instanz-Einrichtung + +- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf `https://api.linear.app/graphql` gesetzt werden. +- **API Key** sollte auf einen persönlichen Linear-API-Key gesetzt werden. Keys können in Linear unter „Settings“, dann „Security & access“, dann [API](https://linear.app/settings/account/security) generiert werden. Der Key wird im Header `Authorization` an die GraphQL-API von Linear gesendet. + +### Issue-Tracker-Zuordnung + +- **Team (Group) ID** sollte auf die ID des Linear-Teams gesetzt werden, für das Issues erstellt werden. Sie können Ihre Teams und deren IDs auflisten, indem Sie die Linear-GraphQL-API aufrufen: + +``` +curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ + -d '{"query":"{ teams { nodes { id name key } } }"}' https://api.linear.app/graphql +``` + +### Details zur Schweregrad-Zuordnung + +Ein Linear-Issue trägt eine numerische **Priorität** anstelle eines Schweregrad-Felds. Jeder DefectDojo-Schweregrad wird einer Linear-Priorität zugeordnet, wobei `1` „Urgent“ und `4` „Low“ bedeutet: + +- **Name des Schweregrad-Felds**: `Priority` +- **Info-Zuordnung**: `4` +- **Niedrig-Zuordnung**: `4` +- **Mittel-Zuordnung**: `3` +- **Hoch-Zuordnung**: `2` +- **Kritisch-Zuordnung**: `1` + +### Details zur Status-Zuordnung + +Jeder Statuswert muss auf die ID eines Workflow-States in Ihrem Linear-Team gesetzt werden. Workflow-State-IDs sind je Workspace eindeutig, daher gibt es keine Standardwerte. Sie können die Workflow-States und ihre IDs auflisten, indem Sie die Linear-GraphQL-API aufrufen: + +``` +curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ + -d '{"query":"{ workflowStates { nodes { id name type team { key } } } }"}' https://api.linear.app/graphql +``` + +- **Name des Status-Felds**: `Workflow State ID` +- **Aktiv-Zuordnung**: die ID eines gestarteten oder noch nicht gestarteten States, zum Beispiel `Todo` oder `In Progress`. +- **Geschlossen-Zuordnung**: die ID eines abgeschlossenen States, zum Beispiel `Done`. Wenn ein Befund in DefectDojo gelöscht wird, wird sein Issue in diesen State verschoben. diff --git a/docs/content/connectors/toolreference/linear.es.md b/docs/content/connectors/toolreference/linear.es.md new file mode 100644 index 00000000000..bbcaab065e5 --- /dev/null +++ b/docs/content/connectors/toolreference/linear.es.md @@ -0,0 +1,46 @@ +--- +title: "Linear" +description: "Cómo configurar el Conector Downstream de Linear para DefectDojo" +weight: 87 +audience: pro +--- +La integración de Linear le permite enviar los Hallazgos de DefectDojo como incidencias de [Linear](https://linear.app/). Las incidencias se crean en un equipo (Team) de su espacio de trabajo de Linear. + +### Configuración de la instancia + +- **Label** debe ser la etiqueta que desea usar para identificar esta integración. +- **Location** debe establecerse en `https://api.linear.app/graphql`. +- **API Key** debe establecerse en una clave de API personal de Linear. Las claves pueden generarse en Linear en Settings, luego Security & access, luego [API](https://linear.app/settings/account/security). La clave se envía a la API GraphQL de Linear en el encabezado `Authorization`. + +### Mapeo del Issue Tracker + +- **Team (Group) ID** debe establecerse en el ID del equipo de Linear para el que se crearán las incidencias. Puede listar sus equipos y sus ID llamando a la API GraphQL de Linear: + +``` +curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ + -d '{"query":"{ teams { nodes { id name key } } }"}' https://api.linear.app/graphql +``` + +### Detalles del mapeo de severidad + +Una incidencia de Linear lleva una **priority** numérica en lugar de un campo de severidad. Cada severidad de DefectDojo se mapea a una prioridad de Linear, donde `1` es Urgent y `4` es Low: + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `4` +- **Low Mapping**: `4` +- **Medium Mapping**: `3` +- **High Mapping**: `2` +- **Critical Mapping**: `1` + +### Detalles del mapeo de estado + +Cada valor de estado debe establecerse en el ID de un estado de flujo de trabajo (Workflow State) en su equipo de Linear. Los ID de estado de flujo de trabajo son únicos para cada espacio de trabajo, por lo que no hay valores predeterminados. Puede listar los estados de flujo de trabajo y sus ID llamando a la API GraphQL de Linear: + +``` +curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ + -d '{"query":"{ workflowStates { nodes { id name type team { key } } } }"}' https://api.linear.app/graphql +``` + +- **Status Field Name**: `Workflow State ID` +- **Active Mapping**: el ID de un estado started o unstarted, por ejemplo `Todo` o `In Progress`. +- **Closed Mapping**: el ID de un estado completed, por ejemplo `Done`. Cuando se elimina un Hallazgo en DefectDojo, su incidencia se mueve a este estado. diff --git a/docs/content/connectors/toolreference/linear.fr.md b/docs/content/connectors/toolreference/linear.fr.md new file mode 100644 index 00000000000..b2a50ba87c5 --- /dev/null +++ b/docs/content/connectors/toolreference/linear.fr.md @@ -0,0 +1,46 @@ +--- +title: "Linear" +description: "Comment configurer le Connecteur Downstream Linear pour DefectDojo" +weight: 87 +audience: pro +--- +L'intégration Linear vous permet de transmettre les Constatations de DefectDojo sous forme de tickets [Linear](https://linear.app/). Les tickets sont créés dans une équipe (Team) de votre espace de travail Linear. + +### Configuration de l'instance + +- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur `https://api.linear.app/graphql`. +- **API Key** doit être définie sur une clé API personnelle Linear. Les clés peuvent être générées dans Linear sous Settings, puis Security & access, puis [API](https://linear.app/settings/account/security). La clé est envoyée à l'API GraphQL de Linear dans l'en-tête `Authorization`. + +### Mappage du suivi des tickets + +- **Team (Group) ID** doit être défini sur l'ID de l'équipe Linear pour laquelle les tickets seront créés. Vous pouvez lister vos équipes et leurs ID en appelant l'API GraphQL de Linear : + +``` +curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ + -d '{"query":"{ teams { nodes { id name key } } }"}' https://api.linear.app/graphql +``` + +### Détails du mappage de la sévérité + +Un ticket Linear porte une **priority** numérique plutôt qu'un champ de sévérité. Chaque sévérité DefectDojo est mappée à une priorité Linear, où `1` correspond à Urgent et `4` à Low : + +- **Severity Field Name** : `Priority` +- **Info Mapping** : `4` +- **Low Mapping** : `4` +- **Medium Mapping** : `3` +- **High Mapping** : `2` +- **Critical Mapping** : `1` + +### Détails du mappage du statut + +Chaque valeur de statut doit être définie sur l'ID d'un Workflow State de votre équipe Linear. Les ID de Workflow State sont propres à chaque espace de travail ; il n'existe donc pas de valeurs par défaut. Vous pouvez lister les Workflow States et leurs ID en appelant l'API GraphQL de Linear : + +``` +curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ + -d '{"query":"{ workflowStates { nodes { id name type team { key } } } }"}' https://api.linear.app/graphql +``` + +- **Status Field Name** : `Workflow State ID` +- **Active Mapping** : l'ID d'un état démarré ou non démarré, par exemple `Todo` ou `In Progress`. +- **Closed Mapping** : l'ID d'un état terminé, par exemple `Done`. Lorsqu'une Constatation est supprimée dans DefectDojo, son ticket est déplacé vers cet état. diff --git a/docs/content/connectors/toolreference/linear.ja.md b/docs/content/connectors/toolreference/linear.ja.md new file mode 100644 index 00000000000..e56dcaf3a6f --- /dev/null +++ b/docs/content/connectors/toolreference/linear.ja.md @@ -0,0 +1,46 @@ +--- +title: "Linear" +description: "DefectDojo で Linear のダウンストリームコネクタをセットアップする方法" +weight: 87 +audience: pro +--- +Linear 統合を使うと、DefectDojo の Finding を[Linear](https://linear.app/)の Issue としてプッシュできます。Issue は Linear ワークスペース内の Team に作成されます。 + +### Instance Setup + +- **Label** は、この統合を識別するために使用したいラベルを設定します。 +- **Location** は、`https://api.linear.app/graphql` を設定します。 +- **API Key** は、Linear のパーソナル API キーを設定します。キーは Linear の Settings、Security & access、[API](https://linear.app/settings/account/security)から生成できます。このキーは Linear の GraphQL API に `Authorization` ヘッダーで送信されます。 + +### Issue Tracker Mapping + +- **Team (Group) ID** は、Issue の作成先となる Linear Team の ID を設定します。以下のように Linear の GraphQL API を呼び出すことで、Team とその ID の一覧を取得できます。 + +``` +curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ + -d '{"query":"{ teams { nodes { id name key } } }"}' https://api.linear.app/graphql +``` + +### Severity Mapping Details + +Linear の Issue には深刻度フィールドではなく、数値の **priority** があります。DefectDojo の各深刻度は、`1` が Urgent、`4` が Low となる Linear の優先度にマッピングされます。 + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `4` +- **Low Mapping**: `4` +- **Medium Mapping**: `3` +- **High Mapping**: `2` +- **Critical Mapping**: `1` + +### Status Mapping Details + +各ステータス値には、Linear Team 内の Workflow State の ID を設定する必要があります。Workflow State の ID はワークスペースごとに異なるため、デフォルト値はありません。以下のように Linear の GraphQL API を呼び出すことで、Workflow State とその ID の一覧を取得できます。 + +``` +curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ + -d '{"query":"{ workflowStates { nodes { id name type team { key } } } }"}' https://api.linear.app/graphql +``` + +- **Status Field Name**: `Workflow State ID` +- **Active Mapping** は、開始済みまたは未開始の状態の ID です。例: `Todo` や `In Progress` +- **Closed Mapping** は、完了状態の ID です。例: `Done`。DefectDojo で Finding が削除されると、対応する Issue はこの状態に移動します。 diff --git a/docs/content/connectors/toolreference/linear.md b/docs/content/connectors/toolreference/linear.md new file mode 100644 index 00000000000..12a8b53996c --- /dev/null +++ b/docs/content/connectors/toolreference/linear.md @@ -0,0 +1,46 @@ +--- +title: "Linear" +description: "How to set up the Linear Downstream Connector for DefectDojo" +weight: 87 +audience: pro +--- +The Linear integration allows you to push DefectDojo Findings as [Linear](https://linear.app/) Issues. Issues are created in a Team in your Linear workspace. + +### Instance Setup + +- **Label** should be the label that you want to use to identify this integration. +- **Location** should be set to `https://api.linear.app/graphql`. +- **API Key** should be set to a Linear personal API key. Keys can be generated in Linear under Settings, then Security & access, then [API](https://linear.app/settings/account/security). The key is sent to Linear's GraphQL API in the `Authorization` header. + +### Issue Tracker Mapping + +- **Team (Group) ID** should be set to the ID of the Linear Team that Issues will be created for. You can list your Teams and their IDs by calling the Linear GraphQL API: + +``` +curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ + -d '{"query":"{ teams { nodes { id name key } } }"}' https://api.linear.app/graphql +``` + +### Severity Mapping Details + +A Linear Issue carries a numeric **priority** rather than a severity field. Each DefectDojo severity maps to a Linear priority, where `1` is Urgent and `4` is Low: + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `4` +- **Low Mapping**: `4` +- **Medium Mapping**: `3` +- **High Mapping**: `2` +- **Critical Mapping**: `1` + +### Status Mapping Details + +Each status value must be set to the ID of a Workflow State in your Linear Team. Workflow State IDs are unique to each workspace, so there are no default values. You can list the Workflow States and their IDs by calling the Linear GraphQL API: + +``` +curl -H "Authorization: {{API_KEY}}" -H "Content-Type: application/json" \ + -d '{"query":"{ workflowStates { nodes { id name type team { key } } } }"}' https://api.linear.app/graphql +``` + +- **Status Field Name**: `Workflow State ID` +- **Active Mapping**: the ID of a started or unstarted state, for example `Todo` or `In Progress`. +- **Closed Mapping**: the ID of a completed state, for example `Done`. When a Finding is deleted in DefectDojo, its Issue is moved to this state. diff --git a/docs/content/connectors/toolreference/mend.de.md b/docs/content/connectors/toolreference/mend.de.md new file mode 100644 index 00000000000..24625198c0b --- /dev/null +++ b/docs/content/connectors/toolreference/mend.de.md @@ -0,0 +1,19 @@ +--- +title: "Mend" +description: "Einrichtung des Mend Upstream-Connectors für DefectDojo" +weight: 88 +audience: pro +--- +Der Mend-Connector (ehemals **WhiteSource**) verwendet die Mend-API, um Sicherheitsbefunde aus Ihrer Mend-Organisation zu importieren. DefectDojo erstellt für jedes Mend-**Projekt** einen Eintrag. + +#### Voraussetzungen + +Sie benötigen einen Mend-(Service-)Benutzer mit einem **User Key** (einem persönlichen Zugriffstoken) und Ihre Mend-**Organization UUID**. Wir empfehlen ein dediziertes Service-Konto, damit automatisierte Aktivitäten leicht von manuellen Team-Aktionen zu unterscheiden sind. Die Organization UUID finden Sie in der Mend-App unter **Administration > Organization UUID**. + +#### Connector-Zuordnungen + +1. Geben Sie Ihre Mend-API-URL in das Feld **Location** ein. Diese URL ist **regionsspezifisch** — verwenden Sie die API-Basis-URL der Region, in der Ihre Mend-Organisation gehostet wird. +2. Geben Sie die Login-E-Mail-Adresse des Mend-Benutzers in das Feld **Email** ein. +3. Geben Sie Ihre Mend-**Organization UUID** in das Feld **Organization UUID** ein. +4. Geben Sie den Mend-**User Key** in das Feld **User Key** ein. +5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. diff --git a/docs/content/connectors/toolreference/mend.es.md b/docs/content/connectors/toolreference/mend.es.md new file mode 100644 index 00000000000..f3035a27ed6 --- /dev/null +++ b/docs/content/connectors/toolreference/mend.es.md @@ -0,0 +1,19 @@ +--- +title: "Mend" +description: "Cómo configurar el Conector Upstream de Mend para DefectDojo" +weight: 88 +audience: pro +--- +El conector Mend (anteriormente **WhiteSource**) usa la API de Mend para importar hallazgos de seguridad de su organización de Mend. DefectDojo crea un Registro para cada **proyecto** de Mend. + +#### Requisitos previos + +Necesitará un usuario (de servicio) de Mend con una **User Key** (un token de acceso personal) y su **Organization UUID** de Mend. Recomendamos una cuenta de servicio dedicada para que la actividad automatizada sea fácil de distinguir de las acciones manuales del equipo. Encuentre el Organization UUID en la aplicación Mend en **Administration > Organization UUID**. + +#### Asignaciones del conector + +1. Introduzca la URL de la API de Mend en el campo **Location**. Esta URL es **específica de la región** — use la URL base de la API de la región donde está alojada su organización de Mend. +2. Introduzca el correo electrónico de inicio de sesión del usuario de Mend en el campo **Email**. +3. Introduzca su **Organization UUID** de Mend en el campo **Organization UUID**. +4. Introduzca la **User Key** de Mend en el campo **User Key**. +5. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. diff --git a/docs/content/connectors/toolreference/mend.fr.md b/docs/content/connectors/toolreference/mend.fr.md new file mode 100644 index 00000000000..d273dbc6593 --- /dev/null +++ b/docs/content/connectors/toolreference/mend.fr.md @@ -0,0 +1,19 @@ +--- +title: "Mend" +description: "Comment configurer le Connecteur Upstream Mend pour DefectDojo" +weight: 88 +audience: pro +--- +Le connecteur Mend (anciennement **WhiteSource**) utilise l'API Mend pour importer les constatations de sécurité de votre organisation Mend. DefectDojo crée un Enregistrement pour chaque **projet** Mend. + +#### Prérequis + +Vous aurez besoin d'un utilisateur (de service) Mend avec une **User Key** (un jeton d'accès personnel) et de l'**Organization UUID** de votre organisation Mend. Nous recommandons un compte de service dédié afin que l'activité automatisée soit facile à distinguer des actions manuelles de l'équipe. Trouvez l'Organization UUID dans l'application Mend sous **Administration > Organization UUID**. + +#### Mappages du connecteur + +1. Saisissez l'URL de l'API Mend dans le champ **Location**. Cette URL est **spécifique à la région** — utilisez l'URL de base de l'API pour la région où votre organisation Mend est hébergée. +2. Saisissez l'e-mail de connexion de l'utilisateur Mend dans le champ **Email**. +3. Saisissez votre **Organization UUID** Mend dans le champ **Organization UUID**. +4. Saisissez la **User Key** Mend dans le champ **User Key**. +5. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. diff --git a/docs/content/connectors/toolreference/mend.ja.md b/docs/content/connectors/toolreference/mend.ja.md new file mode 100644 index 00000000000..72daa28d6ae --- /dev/null +++ b/docs/content/connectors/toolreference/mend.ja.md @@ -0,0 +1,19 @@ +--- +title: "Mend" +description: "DefectDojo で Mend の Upstream Connector をセットアップする方法" +weight: 88 +audience: pro +--- +Mendコネクタ(旧**WhiteSource**)は、Mend APIを使用して、Mend組織からセキュリティ検出事項をインポートします。DefectDojoは各Mend**project**にRecordを作成します。 + +#### Prerequisites + +Mendの**User Key**(個人アクセストークン)を持つMend(サービス)ユーザーと、Mendの**Organization UUID**が必要です。自動化された操作を手動のチーム操作と区別しやすくするため、専用のサービスアカウントの使用をお勧めします。Organization UUIDは、Mendアプリの**Administration > Organization UUID**にあります。 + +#### Connector Mappings + +1. **Location**フィールドにMendのAPI URLを入力します。このURLは**リージョン固有**です — Mend組織がホストされているリージョンのAPIベースURLを使用してください。 +2. **Email**フィールドにMendユーザーのログインメールアドレスを入力します。 +3. **Organization UUID**フィールドにMendの**Organization UUID**を入力します。 +4. **User Key**フィールドにMendの**User Key**を入力します。 +5. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。 diff --git a/docs/content/connectors/toolreference/mend.md b/docs/content/connectors/toolreference/mend.md new file mode 100644 index 00000000000..fd54d07a3be --- /dev/null +++ b/docs/content/connectors/toolreference/mend.md @@ -0,0 +1,19 @@ +--- +title: "Mend" +description: "How to set up the Mend Upstream Connector for DefectDojo" +weight: 88 +audience: pro +--- +The Mend connector (formerly **WhiteSource**) uses the Mend API to import security findings from your Mend organization. DefectDojo creates a Record for each Mend **project**. + +#### Prerequisites + +You will need a Mend (service) user with a **User Key** (a personal access token) and your Mend **Organization UUID**. We recommend a dedicated service account so automated activity is easy to distinguish from manual team actions. Find the Organization UUID in the Mend App under **Administration > Organization UUID**. + +#### Connector Mappings + +1. Enter your Mend API URL in the **Location** field. This URL is **region-specific** — use the API base URL for the region your Mend organization is hosted in. +2. Enter the login email of the Mend user in the **Email** field. +3. Enter your Mend **Organization UUID** in the **Organization UUID** field. +4. Enter the Mend **User Key** in the **User Key** field. +5. Optionally, set a **Minimum Severity** to limit which findings are imported. diff --git a/docs/content/connectors/toolreference/microsoft_defender.de.md b/docs/content/connectors/toolreference/microsoft_defender.de.md new file mode 100644 index 00000000000..41c761bf227 --- /dev/null +++ b/docs/content/connectors/toolreference/microsoft_defender.de.md @@ -0,0 +1,32 @@ +--- +title: "Microsoft Defender" +description: "Einrichtung des Microsoft Defender Upstream-Connectors für DefectDojo" +weight: 89 +audience: pro +--- +Der Microsoft-Defender-Connector importiert Geräte-Schwachstellenbefunde aus **Microsoft Defender Vulnerability Management (MDVM)** — einen Befund pro Kombination aus Gerät/Softwareversion/CVE, einschließlich Schweregrad, CVSS-Score, Ausnutzbarkeitsgrad und empfohlener Sicherheitsupdates. DefectDojo ermittelt Ihre Defender-**Gerätegruppen** und erstellt für jede einen Eintrag; Geräte, die keiner Gerätegruppe zugewiesen sind, werden unter einer synthetischen Gruppe **Unassigned** zusammengefasst. + +**Bitte beachten Sie:** Dieser Connector unterscheidet sich vom dateibasierten Scan-Typ **„MSDefender Parser"**, der manuell exportierte Defender-Dateien importiert. Wählen Sie pro Produkt einen Importpfad, um doppelte Befunde zu vermeiden. + +#### Voraussetzungen + +Ihr Microsoft-Tenant benötigt eine aktive Lizenz, die die Defender-Vulnerability-Export-APIs einschließt: **Defender for Endpoint Plan 2**, **Microsoft Defender Vulnerability Management Standalone**, oder MDE P1/P2 mit dem MDVM-Add-on. (Das MDVM-*Add-on*-SKU allein reicht nicht aus — es setzt Defender for Endpoint Plan 2 voraus.) + +Der Connector authentifiziert sich als Microsoft-Entra-ID-**App-Registrierung** mittels Client-Credentials-Flow. So erstellen Sie eine: + +1. Öffnen Sie im [Azure-Portal](https://portal.azure.com) **App registrations \> New registration**. Benennen Sie sie (zum Beispiel `defectdojo-connector`), belassen Sie die Standardwerte, und wählen Sie **Register**. +2. Notieren Sie sich auf der **Overview**-Seite der App die **Application (client) ID** und die **Directory (tenant) ID**. +3. Öffnen Sie **API permissions \> Add a permission \> APIs my organization uses** und suchen Sie nach **WindowsDefenderATP**. Erscheint es nicht, wurde das Defender-Backend Ihres Tenants noch nicht bereitgestellt: Stellen Sie sicher, dass die Lizenz aktiv ist, öffnen Sie einmal [security.microsoft.com](https://security.microsoft.com), und versuchen Sie es nach einigen Minuten erneut. +4. Wählen Sie **Application permissions** (*nicht* Delegated — Delegated-Berechtigungen erscheinen nie im Service-Token des Connectors), erweitern Sie **Vulnerability**, markieren Sie **Vulnerability.Read.All**, und wählen Sie **Add permissions**. +5. Wählen Sie **Grant admin consent** und bestätigen Sie. Die Status-Spalte muss ein grünes Häkchen zeigen — ohne diesen Schritt liefert jeder API-Aufruf einen 403-Fehler. +6. Öffnen Sie **Certificates & secrets \> New client secret**, legen Sie ein Ablaufdatum fest, und kopieren Sie den **Value** des Secrets sofort (er wird nur einmal angezeigt). Der Connector funktioniert nicht mehr, wenn das Secret abläuft; notieren Sie sich daher das Datum. + +#### Connector-Zuordnungen + +1. Geben Sie `https://api.security.microsoft.com` in das Feld **Location** ein. +2. Geben Sie die **Directory (tenant) ID** in das Feld **Tenant ID** ein. +3. Geben Sie die **Application (client) ID** in das Feld **Client ID** ein. +4. Geben Sie den Wert des Client-Secrets in das Feld **Client Secret** ein. +5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jede Defender-Gerätegruppe wird zu einem Eintrag. Microsoft erneuert den vom Connector gelesenen Schwachstellen-Snapshot etwa alle 6 Stunden, und neu angebundene Geräte können bis zu ca. 24 Stunden benötigen, um ihre ersten Schwachstellendaten zu liefern — ein brandneuer Tenant wird legitim null Befunde synchronisieren, bis Geräte angebunden und bewertet wurden. Auch die Lizenzaktivierung selbst kann ca. 20 Minuten oder länger benötigen, bis sie die API erreicht (Fehler „No active license found" während dieses Zeitfensters lösen sich von selbst). diff --git a/docs/content/connectors/toolreference/microsoft_defender.es.md b/docs/content/connectors/toolreference/microsoft_defender.es.md new file mode 100644 index 00000000000..24caf607346 --- /dev/null +++ b/docs/content/connectors/toolreference/microsoft_defender.es.md @@ -0,0 +1,32 @@ +--- +title: "Microsoft Defender" +description: "Cómo configurar el Conector Upstream de Microsoft Defender para DefectDojo" +weight: 89 +audience: pro +--- +El conector de Microsoft Defender importa hallazgos de vulnerabilidades de dispositivos desde **Microsoft Defender Vulnerability Management (MDVM)** — un hallazgo por cada combinación de dispositivo / versión de software / CVE, incluyendo severidad, puntuación CVSS, nivel de explotabilidad y las actualizaciones de seguridad recomendadas. DefectDojo descubrirá los **grupos de dispositivos** de Defender y creará un Record para cada uno; los dispositivos que no estén asignados a ningún grupo de dispositivos se agrupan bajo un grupo sintético llamado **Unassigned**. + +**Tenga en cuenta:** este conector es distinto del tipo de escaneo basado en archivos **"MSDefender Parser"**, que importa archivos de Defender exportados manualmente. Elija una única vía de importación por Producto para evitar hallazgos duplicados. + +#### Requisitos previos + +Su tenant de Microsoft necesita una licencia activa que incluya las API de exportación de vulnerabilidades de Defender: **Defender for Endpoint Plan 2**, **Microsoft Defender Vulnerability Management Standalone**, o MDE P1/P2 con el add-on de MDVM. (El SKU *Add-on* de MDVM por sí solo no es suficiente: requiere tener Defender for Endpoint Plan 2 como base.) + +El conector se autentica como un **registro de aplicación (app registration)** de Microsoft Entra ID mediante el flujo de credenciales de cliente. Para crear uno: + +1. En el [portal de Azure](https://portal.azure.com), abra **App registrations > New registration**. Asígnele un nombre (por ejemplo, `defectdojo-connector`), deje los valores predeterminados y seleccione **Register**. +2. En la página **Overview** de la aplicación, anote el **Application (client) ID** y el **Directory (tenant) ID**. +3. Abra **API permissions > Add a permission > APIs my organization uses** y busque **WindowsDefenderATP**. Si no aparece, el backend de Defender de su tenant aún no se ha aprovisionado: asegúrese de que la licencia esté activa, abra [security.microsoft.com](https://security.microsoft.com) una vez y vuelva a intentarlo pasados unos minutos. +4. Elija **Application permissions** (*no* Delegated: los permisos delegados nunca aparecen en el token de servicio del conector), expanda **Vulnerability**, marque **Vulnerability.Read.All** y seleccione **Add permissions**. +5. Seleccione **Grant admin consent** y confirme. La columna Status debe mostrar una marca verde: sin este paso, cada llamada a la API devuelve un error 403. +6. Abra **Certificates & secrets > New client secret**, establezca una fecha de caducidad y copie el **Value** del secreto de inmediato (solo se muestra una vez). El conector deja de funcionar cuando el secreto caduca, así que anote la fecha. + +#### Asignaciones del conector + +1. Ingrese `https://api.security.microsoft.com` en el campo **Location**. +2. Ingrese el **Directory (tenant) ID** en el campo **Tenant ID**. +3. Ingrese el **Application (client) ID** en el campo **Client ID**. +4. Ingrese el valor del secreto de cliente en el campo **Client Secret**. +5. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada grupo de dispositivos de Defender se convierte en un Record. Microsoft regenera la instantánea de vulnerabilidades que lee el conector aproximadamente cada 6 horas, y los dispositivos recién incorporados pueden tardar hasta ~24 horas en producir sus primeros datos de vulnerabilidad: es normal que un tenant recién creado sincronice (Sync) cero hallazgos hasta que los dispositivos se incorporen y evalúen. La propia activación de la licencia también puede tardar ~20 minutos o más en propagarse a la API (los errores "No active license found" durante ese período se resuelven por sí solos). diff --git a/docs/content/connectors/toolreference/microsoft_defender.fr.md b/docs/content/connectors/toolreference/microsoft_defender.fr.md new file mode 100644 index 00000000000..6f6a9c6295b --- /dev/null +++ b/docs/content/connectors/toolreference/microsoft_defender.fr.md @@ -0,0 +1,32 @@ +--- +title: "Microsoft Defender" +description: "Comment configurer le Connecteur Upstream Microsoft Defender pour DefectDojo" +weight: 89 +audience: pro +--- +Le connecteur Microsoft Defender importe les constatations de vulnérabilités des appareils depuis **Microsoft Defender Vulnerability Management (MDVM)** — une constatation par combinaison appareil / version logicielle / CVE, incluant la sévérité, le score CVSS, le niveau d'exploitabilité et les mises à jour de sécurité recommandées. DefectDojo découvre vos **groupes d'appareils** Defender et crée un Record pour chacun ; les appareils qui ne sont assignés à aucun groupe d'appareils sont regroupés sous un groupe synthétique **Unassigned**. + +**Remarque :** ce Connecteur est distinct du type de scan basé sur fichier **« MSDefender Parser »**, qui importe des fichiers Defender exportés manuellement. Choisissez un seul chemin d'import par Produit afin d'éviter les constatations en double. + +#### Prérequis + +Votre tenant Microsoft doit disposer d'une licence active incluant les API d'export de vulnérabilités Defender : **Defender for Endpoint Plan 2**, **Microsoft Defender Vulnerability Management Standalone**, ou MDE P1/P2 avec l'add\-on MDVM. (Le SKU *Add\-on* MDVM seul ne suffit pas — il nécessite Defender for Endpoint Plan 2 en dessous.) + +Le connecteur s'authentifie en tant qu'**app registration** Microsoft Entra ID via le flux client credentials. Pour en créer une : + +1. Dans le [portail Azure](https://portal.azure.com), ouvrez **App registrations \> New registration**. Nommez\-la (par exemple `defectdojo-connector`), laissez les valeurs par défaut, puis sélectionnez **Register**. +2. Sur la page **Overview** de l'application, notez l'**Application (client) ID** et le **Directory (tenant) ID**. +3. Ouvrez **API permissions \> Add a permission \> APIs my organization uses** et recherchez **WindowsDefenderATP**. Si elle n'apparaît pas, le backend Defender de votre tenant n'a pas encore été provisionné : vérifiez que la licence est active, ouvrez une fois [security.microsoft.com](https://security.microsoft.com), puis réessayez après quelques minutes. +4. Choisissez **Application permissions** (*et non* Delegated — les permissions Delegated n'apparaissent jamais dans le jeton de service du connecteur), développez **Vulnerability**, cochez **Vulnerability.Read.All**, puis sélectionnez **Add permissions**. +5. Sélectionnez **Grant admin consent** et confirmez. La colonne Status doit afficher une coche verte — sans cette étape, chaque appel API renvoie une erreur 403. +6. Ouvrez **Certificates & secrets \> New client secret**, définissez une expiration, et copiez immédiatement la **Value** du secret (elle n'est affichée qu'une seule fois). Le Connecteur cesse de fonctionner à l'expiration du secret, notez donc la date. + +#### Correspondances du connecteur + +1. Saisissez `https://api.security.microsoft.com` dans le champ **Location**. +2. Saisissez le **Directory (tenant) ID** dans le champ **Tenant ID**. +3. Saisissez l'**Application (client) ID** dans le champ **Client ID**. +4. Saisissez la valeur du secret client dans le champ **Client Secret**. +5. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque groupe d'appareils Defender devient un Record. Microsoft régénère l'instantané de vulnérabilités que lit le connecteur environ toutes les 6 heures, et les appareils nouvellement intégrés peuvent mettre jusqu'à ~24 heures à produire leurs premières données de vulnérabilité — un tenant tout juste créé effectuera légitimement un Sync avec zéro constatation tant que les appareils n'auront pas été intégrés et évalués. L'activation de la licence elle\-même peut aussi prendre ~20 minutes ou plus avant d'atteindre l'API (les erreurs « No active license found » pendant cette fenêtre se résolvent d'elles\-mêmes). diff --git a/docs/content/connectors/toolreference/microsoft_defender.ja.md b/docs/content/connectors/toolreference/microsoft_defender.ja.md new file mode 100644 index 00000000000..0e90277941a --- /dev/null +++ b/docs/content/connectors/toolreference/microsoft_defender.ja.md @@ -0,0 +1,32 @@ +--- +title: "Microsoft Defender" +description: "DefectDojo で Microsoft Defender の Upstream Connector をセットアップする方法" +weight: 89 +audience: pro +--- +Microsoft Defenderコネクタは、**Microsoft Defender Vulnerability Management (MDVM)** からデバイスの脆弱性検出事項をインポートします。これはデバイス／ソフトウェアバージョン／CVEの組み合わせごとに1件の検出事項であり、深刻度、CVSSスコア、悪用可能性のレベル、推奨されるセキュリティ更新プログラムを含みます。DefectDojoはお使いのDefenderの**デバイスグループ**を検出し、それぞれについてRecordを作成します。どのデバイスグループにも割り当てられていないデバイスは、合成的な**Unassigned**グループの下にまとめられます。 + +**ご注意ください:** このConnectorは、手動でエクスポートしたDefenderファイルをインポートするファイルベースの**「MSDefender Parser」**スキャンタイプとは別のものです。重複した検出事項を避けるため、製品ごとにいずれか一方のインポート経路を選択してください。 + +#### 前提条件 + +お使いのMicrosoftテナントには、Defenderの脆弱性エクスポートAPIを含むアクティブなライセンスが必要です: **Defender for Endpoint Plan 2**、**Microsoft Defender Vulnerability Management Standalone**、またはMDVMアドオン付きのMDE P1/P2のいずれかです。（MDVMの*アドオン*SKU単体では不十分で、その下にDefender for Endpoint Plan 2が必要です。） + +このコネクタは、クライアントクレデンシャルフローを使用してMicrosoft Entra IDの**アプリ登録**として認証を行います。作成手順は次のとおりです。 + +1. [Azureポータル](https://portal.azure.com)で **App registrations > New registration** を開きます。名前を付け（例: `defectdojo-connector`）、デフォルトのまま **Register** を選択します。 +2. アプリの **Overview** ページで、**Application (client) ID** と **Directory (tenant) ID** を控えます。 +3. **API permissions > Add a permission > APIs my organization uses** を開き、**WindowsDefenderATP** を検索します。表示されない場合は、テナントのDefenderバックエンドがまだプロビジョニングされていません。ライセンスがアクティブであることを確認し、一度 [security.microsoft.com](https://security.microsoft.com) を開いてから、数分後に再試行してください。 +4. **Application permissions** を選択し（*Delegated*ではありません — Delegated permissionsはコネクタのサービストークンには決して現れません）、**Vulnerability** を展開して **Vulnerability.Read.All** にチェックを入れ、**Add permissions** を選択します。 +5. **Grant admin consent** を選択して確認します。Statusカラムに緑色のチェックが表示される必要があります。このステップを行わないと、すべてのAPI呼び出しが403エラーを返します。 +6. **Certificates & secrets > New client secret** を開き、有効期限を設定し、シークレットの **Value** をただちにコピーします(一度しか表示されません)。シークレットが期限切れになるとConnectorは動作しなくなるため、期限日を控えておいてください。 + +#### Connector Mappings + +1. **Location** フィールドに `https://api.security.microsoft.com` を入力します。 +2. **Tenant ID** フィールドに **Directory (tenant) ID** を入力します。 +3. **Client ID** フィールドに **Application (client) ID** を入力します。 +4. **Client Secret** フィールドにクライアントシークレットの値を入力します。 +5. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 + +各Defenderデバイスグループが1件のRecordになります。Microsoftは、コネクタが読み取る脆弱性スナップショットをおよそ6時間ごとに再生成し、新しくオンボーディングされたデバイスが最初の脆弱性データを生成するまでに最大で約24時間かかることがあります — 新規テナントでは、デバイスがオンボーディングされ評価が完了するまで、Syncで検出事項が0件になるのが正常です。ライセンスの有効化自体もAPIに反映されるまで約20分以上かかることがあり、この間に発生する「No active license found」というエラーは自然に解消されます。 diff --git a/docs/content/connectors/toolreference/microsoft_defender.md b/docs/content/connectors/toolreference/microsoft_defender.md new file mode 100644 index 00000000000..9a3ac9c71d7 --- /dev/null +++ b/docs/content/connectors/toolreference/microsoft_defender.md @@ -0,0 +1,32 @@ +--- +title: "Microsoft Defender" +description: "How to set up the Microsoft Defender Upstream Connector for DefectDojo" +weight: 89 +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. + +**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 + +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). diff --git a/docs/content/connectors/toolreference/microsoft_defender_for_cloud.de.md b/docs/content/connectors/toolreference/microsoft_defender_for_cloud.de.md new file mode 100644 index 00000000000..e97ca7abfb5 --- /dev/null +++ b/docs/content/connectors/toolreference/microsoft_defender_for_cloud.de.md @@ -0,0 +1,37 @@ +--- +title: "Microsoft Defender for Cloud" +description: "Einrichtung des Microsoft Defender for Cloud Upstream-Connectors für DefectDojo" +weight: 90 +audience: pro +--- +Der Microsoft-Defender-for-Cloud-Connector importiert Schwachstellenbefunde aus **Microsoft Defender Vulnerability Management (MDVM)**, wie sie von Defender for Cloud bereitgestellt werden — sowohl **Server**-Befunde (CVEs des Betriebssystems und der installierten Software von Azure-VMs) als auch **Container-Registry**-Befunde (CVEs von Container-Images), einschließlich Schweregrad, CVSS-Score, dem betroffenen Paket oder Image und Abhilfemaßnahmen. DefectDojo ermittelt die Azure-**Subscriptions**, die Ihr Service Principal lesen kann, und erstellt für jede aktivierte Subscription einen Eintrag. + +**Bitte beachten Sie:** Dieser Connector unterscheidet sich vom **Microsoft-Defender**-Connector, der Gerätebefunde aus der Defender-for-Endpoint-API importiert. Defender for Cloud ist ein Azure-Produkt mit einer anderen API-Oberfläche (Azure Resource Manager/Resource Graph) und einem anderen Berechtigungsmodell (Azure RBAC). Verwenden Sie denjenigen, der zu Ihren Befundquellen passt — oder beide, wenn Sie beide Produkte nutzen. + +#### Voraussetzungen + +Sie benötigen eine oder mehrere **Azure-Subscriptions mit aktiviertem Microsoft Defender for Cloud**, wobei die relevanten Defender-Pläne für die zu scannenden Ressourcen aktiviert sind (unter **Microsoft Defender for Cloud \> Environment settings**, dann Ihre Subscription auswählen): + +* **Defender for Servers (Plan 2)** — CVE-Befunde zum Betriebssystem und zur Software von Azure-VMs (agentloses Vulnerability Scanning). +* **Defender for Containers** — CVE-Befunde von Container-Registry-Images. + +SQL-Vulnerability-Assessment- und Konfigurations-/Posture-Befunde werden bewusst **nicht** importiert — dieser Connector importiert ausschließlich CVE-Schwachstellen. + +Der Connector authentifiziert sich als Microsoft-Entra-ID-**App-Registrierung** mittels Client-Credentials-Flow: + +1. Öffnen Sie im [Azure-Portal](https://portal.azure.com) **App registrations \> New registration**. Benennen Sie sie (zum Beispiel `defectdojo-connector`), belassen Sie die Standardwerte, und wählen Sie **Register**. +2. Notieren Sie sich auf der **Overview**-Seite der App die **Application (client) ID** und die **Directory (tenant) ID**. +3. Öffnen Sie **Certificates & secrets \> New client secret**, legen Sie ein Ablaufdatum fest, und kopieren Sie den **Value** des Secrets sofort (er wird nur einmal angezeigt). Der Connector funktioniert nicht mehr, wenn das Secret abläuft; notieren Sie sich daher das Datum. +4. Gewähren Sie der App Lesezugriff auf jede zu importierende Subscription: Öffnen Sie **Subscriptions**, wählen Sie Ihre Subscription, dann **Access control (IAM) \> Add \> Add role assignment**. Wählen Sie die Rolle **Security Reader** (oder **Reader**), und weisen Sie sie im Tab **Members** der von Ihnen erstellten App zu — suchen Sie sie über den **Namen** oder die **Object ID** der App, da der Picker nicht mit der Client ID abgleicht. Wiederholen Sie dies für jede Subscription. + +Anders als beim gerätebasierten Microsoft-Defender-Connector sind keine API-Berechtigungen oder Admin-Consent erforderlich: Der Zugriff auf Defender for Cloud wird ausschließlich über die oben genannte Azure-RBAC-Rollenzuweisung geregelt. + +#### Connector-Zuordnungen + +1. Geben Sie `https://management.azure.com` in das Feld **Location** ein. (Verwenden Sie bei souveränen Clouds den passenden ARM-Endpunkt, zum Beispiel `https://management.usgovcloudapi.net`.) +2. Geben Sie die **Directory (tenant) ID** in das Feld **Tenant ID** ein. +3. Geben Sie die **Application (client) ID** in das Feld **Client ID** ein. +4. Geben Sie den Wert des Client-Secrets in das Feld **Client Secret** ein. +5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jede aktivierte Azure-Subscription wird zu einem Eintrag. Befunde werden über Azure Resource Graph gelesen, sodass sie zügig sichtbar werden, sobald Defender for Cloud Ihre Ressourcen gescannt hat — die Scans selbst laufen jedoch nach dem Zeitplan von Microsoft: Container-Registry-Images werden meist innerhalb einer Stunde nach dem Push gescannt, während der erste agentlose Schwachstellen-Scan einer VM mehrere Stunden dauern kann. Eine neu aktivierte Subscription wird legitim null Befunde synchronisieren, bis ihre Ressourcen gescannt wurden. diff --git a/docs/content/connectors/toolreference/microsoft_defender_for_cloud.es.md b/docs/content/connectors/toolreference/microsoft_defender_for_cloud.es.md new file mode 100644 index 00000000000..34ebaa47799 --- /dev/null +++ b/docs/content/connectors/toolreference/microsoft_defender_for_cloud.es.md @@ -0,0 +1,37 @@ +--- +title: "Microsoft Defender for Cloud" +description: "Cómo configurar el Conector Upstream de Microsoft Defender for Cloud para DefectDojo" +weight: 90 +audience: pro +--- +El conector de Microsoft Defender for Cloud importa hallazgos de vulnerabilidades de **Microsoft Defender Vulnerability Management (MDVM)** tal como los expone Defender for Cloud, tanto hallazgos de **servidor** (CVEs del sistema operativo y del software instalado en VM de Azure) como hallazgos de **registro de contenedores** (CVEs de imágenes de contenedor), incluyendo severidad, puntuación CVSS, el paquete o la imagen afectados y la remediación. DefectDojo descubre las **suscripciones** de Azure que su entidad de servicio (service principal) puede leer y crea un Record por cada suscripción habilitada. + +**Tenga en cuenta:** este conector es distinto del conector **Microsoft Defender**, que importa hallazgos de dispositivos desde la API de Defender for Endpoint. Defender for Cloud es un producto de Azure con una superficie de API diferente (Azure Resource Manager / Resource Graph) y un modelo de permisos diferente (Azure RBAC). Ejecute el que corresponda según dónde residan sus hallazgos, o ambos si usa los dos productos. + +#### Requisitos previos + +Necesita una o más **suscripciones de Azure con Microsoft Defender for Cloud habilitado**, con los planes de Defender pertinentes activados para los recursos que desea escanear (en **Microsoft Defender for Cloud > Environment settings**, y luego seleccione su suscripción): + +* **Defender for Servers (Plan 2)**: hallazgos de CVE del sistema operativo y del software de VM de Azure (escaneo de vulnerabilidades sin agente). +* **Defender for Containers**: hallazgos de CVE de imágenes del registro de contenedores. + +Los hallazgos de evaluación de vulnerabilidades de SQL y de configuración/postura **no** se importan intencionalmente: este conector solo importa vulnerabilidades CVE. + +El conector se autentica como un **registro de aplicación (app registration)** de Microsoft Entra ID mediante el flujo de credenciales de cliente: + +1. En el [portal de Azure](https://portal.azure.com), abra **App registrations > New registration**. Asígnele un nombre (por ejemplo, `defectdojo-connector`), deje los valores predeterminados y seleccione **Register**. +2. En la página **Overview** de la aplicación, anote el **Application (client) ID** y el **Directory (tenant) ID**. +3. Abra **Certificates & secrets > New client secret**, establezca una fecha de caducidad y copie el **Value** del secreto de inmediato (solo se muestra una vez). El conector deja de funcionar cuando el secreto caduca, así que anote la fecha. +4. Otorgue a la aplicación acceso de lectura a cada suscripción que desee importar: abra **Subscriptions**, seleccione su suscripción y luego **Access control (IAM) > Add > Add role assignment**. Seleccione el rol **Security Reader** (o **Reader**) y, en la pestaña **Members**, asígnelo a la aplicación que creó; búsquela por el **nombre** o el **object ID** de la aplicación, ya que el selector no coincide con el client ID. Repita esto para cada suscripción. + +A diferencia del conector Microsoft Defender basado en dispositivos, no se requieren permisos de API ni consentimiento de administrador: el acceso a Defender for Cloud se rige completamente por la asignación de rol de Azure RBAC descrita arriba. + +#### Asignaciones del conector + +1. Ingrese `https://management.azure.com` en el campo **Location**. (Para nubes soberanas, use el endpoint de ARM correspondiente, por ejemplo `https://management.usgovcloudapi.net`.) +2. Ingrese el **Directory (tenant) ID** en el campo **Tenant ID**. +3. Ingrese el **Application (client) ID** en el campo **Client ID**. +4. Ingrese el valor del secreto de cliente en el campo **Client Secret**. +5. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada suscripción de Azure habilitada se convierte en un Record. Los hallazgos se leen a través de Azure Resource Graph, por lo que aparecen con rapidez una vez que Defender for Cloud ha escaneado sus recursos, pero los escaneos en sí se ejecutan según la programación de Microsoft: las imágenes del registro de contenedores suelen escanearse dentro de la hora siguiente a su carga (push), mientras que el primer escaneo de vulnerabilidades sin agente de una VM puede tardar varias horas. Es normal que una suscripción recién habilitada sincronice (Sync) cero hallazgos hasta que se hayan escaneado sus recursos. diff --git a/docs/content/connectors/toolreference/microsoft_defender_for_cloud.fr.md b/docs/content/connectors/toolreference/microsoft_defender_for_cloud.fr.md new file mode 100644 index 00000000000..f3bb0855fca --- /dev/null +++ b/docs/content/connectors/toolreference/microsoft_defender_for_cloud.fr.md @@ -0,0 +1,37 @@ +--- +title: "Microsoft Defender for Cloud" +description: "Comment configurer le Connecteur Upstream Microsoft Defender for Cloud pour DefectDojo" +weight: 90 +audience: pro +--- +Le connecteur Microsoft Defender for Cloud importe les constatations de vulnérabilités de **Microsoft Defender Vulnerability Management (MDVM)** telles qu'exposées par Defender for Cloud — à la fois les constatations **serveur** (CVE du système d'exploitation et des logiciels installés sur les VM Azure) et les constatations **registre de conteneurs** (CVE des images de conteneurs), incluant la sévérité, le score CVSS, le paquet ou l'image concerné, et la remédiation. DefectDojo découvre les **abonnements** Azure que votre service principal peut lire et crée un Record pour chaque abonnement activé. + +**Remarque :** ce Connecteur est distinct du connecteur **Microsoft Defender**, qui importe les constatations d'appareils depuis l'API Defender for Endpoint. Defender for Cloud est un produit Azure avec une surface d'API différente (Azure Resource Manager / Resource Graph) et un modèle de permissions différent (Azure RBAC). Exécutez celui qui correspond à l'emplacement de vos constatations — ou les deux, si vous utilisez les deux produits. + +#### Prérequis + +Vous avez besoin d'un ou plusieurs **abonnements Azure avec Microsoft Defender for Cloud activé**, avec les plans Defender pertinents activés pour les ressources que vous souhaitez scanner (sous **Microsoft Defender for Cloud \> Environment settings**, puis sélectionnez votre abonnement) : + +* **Defender for Servers (Plan 2)** — constatations CVE du système d'exploitation et des logiciels des VM Azure (scan de vulnérabilités sans agent). +* **Defender for Containers** — constatations CVE des images du registre de conteneurs. + +Les constatations d'évaluation de vulnérabilités SQL et de configuration/posture ne sont intentionnellement **pas** importées — ce connecteur importe uniquement les vulnérabilités CVE. + +Le connecteur s'authentifie en tant qu'**app registration** Microsoft Entra ID via le flux client credentials : + +1. Dans le [portail Azure](https://portal.azure.com), ouvrez **App registrations \> New registration**. Nommez\-la (par exemple `defectdojo-connector`), laissez les valeurs par défaut, puis sélectionnez **Register**. +2. Sur la page **Overview** de l'application, notez l'**Application (client) ID** et le **Directory (tenant) ID**. +3. Ouvrez **Certificates & secrets \> New client secret**, définissez une expiration, et copiez immédiatement la **Value** du secret (elle n'est affichée qu'une seule fois). Le Connecteur cesse de fonctionner à l'expiration du secret, notez donc la date. +4. Accordez à l'application un accès en lecture à chaque abonnement que vous souhaitez importer : ouvrez **Subscriptions**, sélectionnez votre abonnement, puis **Access control (IAM) \> Add \> Add role assignment**. Sélectionnez le rôle **Security Reader** (ou **Reader**), et dans l'onglet **Members**, assignez\-le à l'application que vous avez créée — recherchez\-la par le **nom** ou l'**object ID** de l'application, car le sélecteur ne fait pas correspondre le client ID. Répétez l'opération pour chaque abonnement. + +Contrairement au connecteur Microsoft Defender basé sur les appareils, aucune permission API ni consentement admin n'est requis : l'accès à Defender for Cloud est entièrement régi par l'attribution de rôle Azure RBAC ci\-dessus. + +#### Correspondances du connecteur + +1. Saisissez `https://management.azure.com` dans le champ **Location**. (Pour les clouds souverains, utilisez le endpoint ARM correspondant, par exemple `https://management.usgovcloudapi.net`.) +2. Saisissez le **Directory (tenant) ID** dans le champ **Tenant ID**. +3. Saisissez l'**Application (client) ID** dans le champ **Client ID**. +4. Saisissez la valeur du secret client dans le champ **Client Secret**. +5. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque abonnement Azure activé devient un Record. Les constatations sont lues via Azure Resource Graph, elles apparaissent donc rapidement une fois que Defender for Cloud a scanné vos ressources — mais les scans eux\-mêmes s'exécutent selon le calendrier de Microsoft : les images du registre de conteneurs sont généralement scannées dans l'heure suivant leur push, tandis que le premier scan de vulnérabilités sans agent d'une VM peut prendre plusieurs heures. Un abonnement nouvellement activé effectuera légitimement un Sync avec zéro constatation tant que ses ressources n'auront pas été scannées. diff --git a/docs/content/connectors/toolreference/microsoft_defender_for_cloud.ja.md b/docs/content/connectors/toolreference/microsoft_defender_for_cloud.ja.md new file mode 100644 index 00000000000..4353efaad30 --- /dev/null +++ b/docs/content/connectors/toolreference/microsoft_defender_for_cloud.ja.md @@ -0,0 +1,37 @@ +--- +title: "Microsoft Defender for Cloud" +description: "DefectDojo で Microsoft Defender for Cloud の Upstream Connector をセットアップする方法" +weight: 90 +audience: pro +--- +Microsoft Defender for Cloudコネクタは、Defender for Cloudを通じて表示される **Microsoft Defender Vulnerability Management (MDVM)** の脆弱性検出事項をインポートします。これには**サーバー**の検出事項(Azure VMのオペレーティングシステムおよびインストール済みソフトウェアのCVE)と**コンテナレジストリ**の検出事項(コンテナイメージのCVE)の両方が含まれ、深刻度、CVSSスコア、影響を受けるパッケージまたはイメージ、修復方法を含みます。DefectDojoは、サービスプリンシパルが読み取り可能なAzureの**サブスクリプション**を検出し、有効化されたサブスクリプションごとにRecordを作成します。 + +**ご注意ください:** このConnectorは、Defender for Endpoint APIからデバイスの検出事項をインポートする**Microsoft Defender**コネクタとは別のものです。Defender for Cloudは異なるAPIサーフェス(Azure Resource Manager / Resource Graph)と権限モデル(Azure RBAC)を持つAzure製品です。検出事項がどちらにあるかに応じて実行してください — 両方の製品を使用している場合は両方実行しても構いません。 + +#### 前提条件 + +**Microsoft Defender for Cloudが有効化された**1つ以上のAzureサブスクリプションが必要で、スキャン対象のリソースに応じて関連するDefenderプランを有効にしておく必要があります(**Microsoft Defender for Cloud > Environment settings** の下で、サブスクリプションを選択します): + +* **Defender for Servers (Plan 2)** — Azure VMのオペレーティングシステムおよびソフトウェアのCVE検出事項(エージェントレス脆弱性スキャン)。 +* **Defender for Containers** — コンテナレジストリのイメージCVE検出事項。 + +SQLの脆弱性評価および設定/ポスチャの検出事項は意図的に**インポートされません** — このコネクタはCVEの脆弱性のみをインポートします。 + +このコネクタは、クライアントクレデンシャルフローを使用してMicrosoft Entra IDの**アプリ登録**として認証を行います。 + +1. [Azureポータル](https://portal.azure.com)で **App registrations > New registration** を開きます。名前を付け(例: `defectdojo-connector`)、デフォルトのまま **Register** を選択します。 +2. アプリの **Overview** ページで、**Application (client) ID** と **Directory (tenant) ID** を控えます。 +3. **Certificates & secrets > New client secret** を開き、有効期限を設定し、シークレットの **Value** をただちにコピーします(一度しか表示されません)。シークレットが期限切れになるとConnectorは動作しなくなるため、期限日を控えておいてください。 +4. インポートしたい各サブスクリプションに対してアプリに読み取りアクセス権を付与します: **Subscriptions** を開き、サブスクリプションを選択し、**Access control (IAM) > Add > Add role assignment** を選びます。**Security Reader** ロール(または **Reader**)を選択し、**Members** タブで作成したアプリに割り当てます — ピッカーはクライアントIDと一致しないため、アプリの**名前**または**オブジェクトID**で検索してください。すべてのサブスクリプションについて繰り返します。 + +デバイスベースのMicrosoft Defenderコネクタとは異なり、API permissionやadmin consentは不要です。Defender for Cloudへのアクセスは、上記のAzure RBACロール割り当てのみによって管理されます。 + +#### Connector Mappings + +1. **Location** フィールドに `https://management.azure.com` を入力します。(政府専用クラウドなど特殊な環境では、対応するARMエンドポイントを使用してください。例: `https://management.usgovcloudapi.net`。) +2. **Tenant ID** フィールドに **Directory (tenant) ID** を入力します。 +3. **Client ID** フィールドに **Application (client) ID** を入力します。 +4. **Client Secret** フィールドにクライアントシークレットの値を入力します。 +5. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 + +有効化された各Azureサブスクリプションが1件のRecordになります。検出事項はAzure Resource Graphを通じて読み取られるため、Defender for Cloudがリソースをスキャンし終えるとすぐに反映されますが、スキャン自体はMicrosoftのスケジュールで実行されます — コンテナレジストリのイメージは通常プッシュから1時間以内にスキャンされますが、VMの最初のエージェントレス脆弱性スキャンには数時間かかることがあります。新しく有効化されたサブスクリプションでは、リソースがスキャンされるまでSyncで検出事項が0件になるのが正常です。 diff --git a/docs/content/connectors/toolreference/microsoft_defender_for_cloud.md b/docs/content/connectors/toolreference/microsoft_defender_for_cloud.md new file mode 100644 index 00000000000..4041f2b8827 --- /dev/null +++ b/docs/content/connectors/toolreference/microsoft_defender_for_cloud.md @@ -0,0 +1,37 @@ +--- +title: "Microsoft Defender for Cloud" +description: "How to set up the Microsoft Defender for Cloud Upstream Connector for DefectDojo" +weight: 90 +audience: pro +--- +The Microsoft Defender for Cloud connector imports vulnerability findings from **Microsoft Defender Vulnerability Management (MDVM)** as surfaced by Defender for Cloud — both **server** findings (Azure VM operating\-system and installed\-software CVEs) and **container\-registry** findings (container image CVEs), including severity, CVSS score, the affected package or image, and remediation. DefectDojo discovers the Azure **subscriptions** your service principal can read and creates a Record for each enabled subscription. + +**Please note:** this Connector is distinct from the **Microsoft Defender** connector, which imports device findings from the Defender for Endpoint API. Defender for Cloud is an Azure Asset with a different API surface (Azure Resource Manager / Resource Graph) and permission model (Azure RBAC). Run whichever matches where your findings live — or both, if you use both Assets. + +#### Prerequisites + +You need one or more **Azure subscriptions with Microsoft Defender for Cloud enabled**, with the relevant Defender plans turned on for the resources you want scanned (under **Microsoft Defender for Cloud \> Environment settings**, then select your subscription): + +* **Defender for Servers (Plan 2)** — Azure VM operating\-system and software CVE findings (agentless vulnerability scanning). +* **Defender for Containers** — container\-registry image CVE findings. + +SQL vulnerability\-assessment and configuration/posture findings are intentionally **not** imported — this connector imports CVE vulnerabilities only. + +The connector authenticates as a Microsoft Entra ID **app registration** using the client credentials flow: + +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 **Certificates & secrets \> New client secret**, set an expiry, and copy the secret **Value** immediately (it is shown only once). The Connector stops working when the secret expires, so note the date. +4. Grant the app read access to each subscription you want to import: open **Subscriptions**, select your subscription, then **Access control (IAM) \> Add \> Add role assignment**. Select the **Security Reader** role (or **Reader**), and on the **Members** tab assign it to the app you created — search for it by the app's **name** or **object ID**, as the picker does not match the client ID. Repeat for every subscription. + +Unlike the device\-based Microsoft Defender connector, no API permissions or admin consent are required: Defender for Cloud access is governed entirely by the Azure RBAC role assignment above. + +#### Connector Mappings + +1. Enter `https://management.azure.com` in the **Location** field. (For sovereign clouds, use the matching ARM endpoint, for example `https://management.usgovcloudapi.net`.) +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 enabled Azure subscription becomes a Record. Findings are read through Azure Resource Graph, so they surface promptly once Defender for Cloud has scanned your resources — but the scans themselves run on Microsoft's schedule: container\-registry images are usually scanned within an hour of being pushed, while a VM's first agentless vulnerability scan can take several hours. A newly enabled subscription will legitimately Sync zero findings until its resources have been scanned. diff --git a/docs/content/connectors/toolreference/mobsf.de.md b/docs/content/connectors/toolreference/mobsf.de.md new file mode 100644 index 00000000000..5db33b6e5ab --- /dev/null +++ b/docs/content/connectors/toolreference/mobsf.de.md @@ -0,0 +1,21 @@ +--- +title: "MobSF" +description: "Einrichtung des MobSF Upstream-Connectors für DefectDojo" +weight: 91 +audience: pro +--- +Der MobSF-Connector verwendet die REST-API des [Mobile Security Framework (MobSF)](https://github.com/MobSF/Mobile-Security-Framework-MobSF), um statische Analyseergebnisse mobiler Anwendungen (APK/IPA) zu importieren. DefectDojo ermittelt jede App, die auf Ihrer MobSF-Instanz gescannt wurde, und erstellt für jede einen Eintrag; anschließend werden die statischen Analysebefunde dieser App importiert. + +#### Voraussetzungen + +Sie benötigen Ihren MobSF-**REST-API-Schlüssel**. Sie finden ihn auf der MobSF-Startseite unter **API** (in der MobSF-Dokumentation auch als `Authorization`-Wert angezeigt). Der Schlüssel wird bei jeder Anfrage gesendet und nie protokolliert. + +#### Connector-Zuordnungen + +1. Geben Sie Ihre MobSF-Basis-URL in das Feld **Location** ein (zum Beispiel `https://mobsf.example.com`). +2. Geben Sie im Feld **Secret** den MobSF-REST-API-Schlüssel ein. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo ordnet jede gescannte **App** einem Eintrag zu und importiert deren Befunde aus dem MobSF-JSON-Bericht über mehrere Abschnitte hinweg — Anwendungsberechtigungen, Code-Analyse, das Signaturzertifikat, das Android-Manifest, Android-API-Nutzung und Binäranalyse. Jeder Befund wird mit **CWE 919** (mobil) getaggt, und sein Schweregrad stammt aus MobSFs eigener Bewertung (high, warning, info, secure/good) — eine *gefährliche* Berechtigung wird als High behandelt. Befunde werden als statische Befunde erfasst und anhand von Scan, Abschnitt, Titel, Schweregrad und Dateipfad dedupliziert. + +Weitere Informationen finden Sie in der [MobSF-REST-API-Dokumentation](https://mobsf.github.io/docs/#/rest_api). diff --git a/docs/content/connectors/toolreference/mobsf.es.md b/docs/content/connectors/toolreference/mobsf.es.md new file mode 100644 index 00000000000..5a198db07aa --- /dev/null +++ b/docs/content/connectors/toolreference/mobsf.es.md @@ -0,0 +1,21 @@ +--- +title: "MobSF" +description: "Cómo configurar el Conector Upstream de MobSF para DefectDojo" +weight: 91 +audience: pro +--- +El conector de MobSF usa la API REST de [Mobile Security Framework (MobSF)](https://github.com/MobSF/Mobile-Security-Framework-MobSF) para importar resultados de análisis estático de aplicaciones móviles (APK/IPA). DefectDojo descubre cada app que se ha escaneado en su instancia de MobSF y crea un Record para cada una, y luego importa los hallazgos de análisis estático de esa app. + +#### Requisitos previos + +Necesitará su **REST API key** de MobSF. Encuéntrela en la página de inicio de MobSF, en **API** (también se muestra en la documentación de MobSF como el valor `Authorization`). La clave se envía en cada solicitud y nunca se registra en los logs. + +#### Asignaciones del conector + +1. Ingrese la URL base de MobSF en el campo **Location** (por ejemplo, `https://mobsf.example.com`). +2. En el campo **Secret**, ingrese la REST API key de MobSF. +3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo asigna cada **app** escaneada a un Record e importa sus hallazgos del informe JSON de MobSF en varias secciones: permisos de la aplicación, análisis de código, el certificado de firma, el manifiesto de Android, el uso de la API de Android y el análisis binario. Cada hallazgo se etiqueta con **CWE 919** (móvil), y su severidad proviene de la propia calificación de MobSF (high, warning, info, secure/good); un permiso *dangerous* se trata como Alta. Los hallazgos se registran como hallazgos estáticos y se deduplican por el scan, la sección, el título, la severidad y la ruta del archivo. + +Consulte la [documentación de la API REST de MobSF](https://mobsf.github.io/docs/#/rest_api) para más información. diff --git a/docs/content/connectors/toolreference/mobsf.fr.md b/docs/content/connectors/toolreference/mobsf.fr.md new file mode 100644 index 00000000000..9d2b0658c71 --- /dev/null +++ b/docs/content/connectors/toolreference/mobsf.fr.md @@ -0,0 +1,21 @@ +--- +title: "MobSF" +description: "Comment configurer le Connecteur Upstream MobSF pour DefectDojo" +weight: 91 +audience: pro +--- +Le connecteur MobSF utilise l'API REST de [Mobile Security Framework (MobSF)](https://github.com/MobSF/Mobile-Security-Framework-MobSF) pour importer les résultats d'analyse statique d'applications mobiles (APK/IPA). DefectDojo découvre chaque application scannée sur votre instance MobSF et crée un Record pour chacune, puis importe les constatations d'analyse statique de cette application. + +#### Prérequis + +Vous aurez besoin de votre **clé API REST** MobSF. Trouvez\-la sur la page d'accueil MobSF sous **API** (également indiquée dans la documentation MobSF comme la valeur `Authorization`). La clé est envoyée à chaque requête et n'est jamais journalisée. + +#### Correspondances du connecteur + +1. Saisissez l'URL de base de votre MobSF dans le champ **Location** (par exemple `https://mobsf.example.com`). +2. Dans le champ **Secret**, saisissez la clé API REST MobSF. +3. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +DefectDojo associe chaque **application** scannée à un Record et importe ses constatations depuis le rapport JSON de MobSF, réparties sur plusieurs sections — permissions de l'application, analyse de code, certificat de signature, manifeste Android, utilisation de l'API Android et analyse binaire. Chaque constatation est étiquetée **CWE 919** (mobile), et sa sévérité provient de la notation propre à MobSF (high, warning, info, secure/good) — une permission *dangerous* est traitée comme High. Les constatations sont enregistrées comme des constatations statiques et dédupliquées sur le scan, la section, le titre, la sévérité et le chemin du fichier. + +Consultez la [documentation de l'API REST MobSF](https://mobsf.github.io/docs/#/rest_api) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/mobsf.ja.md b/docs/content/connectors/toolreference/mobsf.ja.md new file mode 100644 index 00000000000..72807e8d182 --- /dev/null +++ b/docs/content/connectors/toolreference/mobsf.ja.md @@ -0,0 +1,21 @@ +--- +title: "MobSF" +description: "DefectDojo で MobSF の Upstream Connector をセットアップする方法" +weight: 91 +audience: pro +--- +MobSFコネクタは、[Mobile Security Framework (MobSF)](https://github.com/MobSF/Mobile-Security-Framework-MobSF) REST APIを使用して、モバイルアプリケーション(APK/IPA)の静的解析結果をインポートします。DefectDojoは、お使いのMobSFインスタンス上でスキャン済みのすべてのアプリを検出し、それぞれについてRecordを作成した上で、そのアプリの静的解析の検出事項をインポートします。 + +#### 前提条件 + +MobSFの**REST APIキー**が必要です。MobSFのホームページの **API** の下にあります(MobSFドキュメントでは `Authorization` 値としても示されています)。このキーはすべてのリクエストで送信され、ログに記録されることはありません。 + +#### Connector Mappings + +1. **Location** フィールドにMobSFのベースURLを入力します(例: `https://mobsf.example.com`)。 +2. **Secret** フィールドに、MobSFのREST APIキーを入力します。 +3. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 + +DefectDojoは、スキャン済みの各**アプリ**をRecordにマッピングし、MobSFのJSONレポートの複数のセクション — アプリケーションの権限、コード解析、署名証明書、Androidマニフェスト、Android APIの使用状況、バイナリ解析 — から検出事項をインポートします。各検出事項には**CWE 919**(モバイル)のタグが付けられ、深刻度はMobSF自身の評価(high、warning、info、secure/good)に基づきます — *dangerous*な権限はHighとして扱われます。検出事項は静的検出事項として記録され、スキャン、セクション、タイトル、深刻度、ファイルパスで重複排除されます。 + +詳細については、[MobSF REST APIドキュメント](https://mobsf.github.io/docs/#/rest_api)を参照してください。 diff --git a/docs/content/connectors/toolreference/mobsf.md b/docs/content/connectors/toolreference/mobsf.md new file mode 100644 index 00000000000..99b0f976dd5 --- /dev/null +++ b/docs/content/connectors/toolreference/mobsf.md @@ -0,0 +1,21 @@ +--- +title: "MobSF" +description: "How to set up the MobSF Upstream Connector for DefectDojo" +weight: 91 +audience: pro +--- +The MobSF connector uses the [Mobile Security Framework (MobSF)](https://github.com/MobSF/Mobile-Security-Framework-MobSF) REST API to import mobile application (APK/IPA) static-analysis results. DefectDojo discovers every app that has been scanned on your MobSF instance and creates a Record for each one, then imports that app's static-analysis findings. + +#### Prerequisites + +You will need your MobSF **REST API key**. Find it on the MobSF home page under **API** (also shown in the MobSF docs as the `Authorization` value). The key is sent on every request and is never logged. + +#### Connector Mappings + +1. Enter your MobSF base URL in the **Location** field (for example `https://mobsf.example.com`). +2. In the **Secret** field, enter the MobSF REST API key. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo maps each scanned **app** to a Record and imports its findings from the MobSF JSON report across several sections — application permissions, code analysis, the signing certificate, the Android manifest, Android API usage and binary analysis. Each finding is tagged with **CWE 919** (mobile), and its severity comes from MobSF's own rating (high, warning, info, secure/good) — a *dangerous* permission is treated as High. Findings are recorded as static findings and de-duplicated on the scan, section, title, severity and file path. + +See the [MobSF REST API documentation](https://mobsf.github.io/docs/#/rest_api) for more information. diff --git a/docs/content/connectors/toolreference/netrise.md b/docs/content/connectors/toolreference/netrise.md new file mode 100644 index 00000000000..68822ab1992 --- /dev/null +++ b/docs/content/connectors/toolreference/netrise.md @@ -0,0 +1,21 @@ +--- +title: "NetRise" +description: "How to set up the NetRise Upstream Connector for DefectDojo" +weight: 92 +audience: pro +--- +The NetRise connector imports **firmware vulnerability findings** from NetRise. DefectDojo enumerates every firmware artifact in your tenant and creates a Record for each **product line** — the vendor and Asset pair — so a product line accumulates the findings of its artifacts. + +#### Prerequisites + +A NetRise API **client ID and secret**, plus the **organization ID** they belong to. The secret is never logged. + +#### Connector Mappings + +1. Enter your NetRise API URL in the **Location** field. +2. Enter the client ID in the **Client ID** field. +3. Enter the client secret in the **Client Secret** field. +4. Enter your **Organization ID**. +5. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each product line becomes a Record, carrying the CVEs found in its firmware artifacts. diff --git a/docs/content/connectors/toolreference/neuvector.de.md b/docs/content/connectors/toolreference/neuvector.de.md new file mode 100644 index 00000000000..712cb1fcf69 --- /dev/null +++ b/docs/content/connectors/toolreference/neuvector.de.md @@ -0,0 +1,22 @@ +--- +title: "NeuVector" +description: "Einrichtung des NeuVector Upstream-Connectors für DefectDojo" +weight: 93 +audience: pro +--- +Der NeuVector-Connector verwendet die Controller-REST-API von [NeuVector](https://github.com/neuvector/neuvector), um Container-**Image-Schwachstellen-Scans** zu importieren. DefectDojo ermittelt jedes von NeuVector gescannte Image und erstellt für jedes einen Eintrag; anschließend wird der Scan-Bericht dieses Images als Befunde importiert. + +#### Voraussetzungen + +Sie benötigen einen NeuVector-**Benutzernamen und ein Passwort** für ein Controller-Konto mit Berechtigung, Scan-Ergebnisse zu lesen. Der Connector meldet sich mit diesen Anmeldedaten an, um ein Session-Token zu erhalten; das Passwort und das Token werden nie protokolliert. + +#### Connector-Zuordnungen + +1. Geben Sie Ihre NeuVector-Controller-URL einschließlich des REST-API-Ports in das Feld **Location** ein — zum Beispiel `https://neuvector.example.com:10443`. +2. Geben Sie den Controller-**Username** und das **Password** ein. +3. Wenn Ihr Controller ein selbstsigniertes Zertifikat verwendet, setzen Sie **Skip TLS Verification** auf `true`. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo ordnet jedes gescannte **Image** einem Eintrag zu und jede **CVE** in dessen Scan-Bericht einem Befund. Der Schweregrad stammt aus NeuVectors eigener Bewertung, und das betroffene Paket und die Version, der CVSSv3-Score und -Vektor, die Fix-Version (als Abhilfemaßnahme) sowie ein Referenzlink werden übernommen. Befunde werden anhand von Image, CVE, Paket, Version und Schweregrad dedupliziert. + +Weitere Informationen finden Sie in der [NeuVector-API-Dokumentation](https://open-docs.neuvector.com/automation/automation). diff --git a/docs/content/connectors/toolreference/neuvector.es.md b/docs/content/connectors/toolreference/neuvector.es.md new file mode 100644 index 00000000000..4aae2bd55cf --- /dev/null +++ b/docs/content/connectors/toolreference/neuvector.es.md @@ -0,0 +1,22 @@ +--- +title: "NeuVector" +description: "Cómo configurar el Conector Upstream de NeuVector para DefectDojo" +weight: 93 +audience: pro +--- +El conector de NeuVector usa la API REST del controlador de [NeuVector](https://github.com/neuvector/neuvector) para importar **escaneos de vulnerabilidades de imágenes** de contenedor. DefectDojo descubre cada imagen que NeuVector ha escaneado y crea un Record para cada una, y luego importa el informe de escaneo de esa imagen como hallazgos. + +#### Requisitos previos + +Necesitará un **nombre de usuario y contraseña** de NeuVector para una cuenta del controlador con permiso para leer los resultados de los escaneos. El conector inicia sesión con estas credenciales para obtener un token de sesión; la contraseña y el token nunca se registran en los logs. + +#### Asignaciones del conector + +1. Ingrese la URL del controlador de NeuVector en el campo **Location**, incluyendo el puerto de la API REST; por ejemplo, `https://neuvector.example.com:10443`. +2. Ingrese el **Username** y **Password** del controlador. +3. Si su controlador usa un certificado autofirmado, establezca **Skip TLS Verification** en `true`. +4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo asigna cada **imagen** escaneada a un Record y cada **CVE** de su informe de escaneo a un hallazgo. La severidad proviene de la propia calificación de NeuVector, y se trasladan el paquete y la versión afectados, la puntuación y el vector CVSSv3, la versión de corrección (como mitigación) y el enlace de referencia. Los hallazgos se deduplican por la imagen, el CVE, el paquete, la versión y la severidad. + +Consulte la [documentación de la API de NeuVector](https://open-docs.neuvector.com/automation/automation) para más información. diff --git a/docs/content/connectors/toolreference/neuvector.fr.md b/docs/content/connectors/toolreference/neuvector.fr.md new file mode 100644 index 00000000000..d825e0a26c2 --- /dev/null +++ b/docs/content/connectors/toolreference/neuvector.fr.md @@ -0,0 +1,22 @@ +--- +title: "NeuVector" +description: "Comment configurer le Connecteur Upstream NeuVector pour DefectDojo" +weight: 93 +audience: pro +--- +Le connecteur NeuVector utilise l'API REST du contrôleur [NeuVector](https://github.com/neuvector/neuvector) pour importer les **scans de vulnérabilités d'images** de conteneurs. DefectDojo découvre chaque image scannée par NeuVector et crée un Record pour chacune, puis importe le rapport de scan de cette image sous forme de constatations. + +#### Prérequis + +Vous aurez besoin d'un **nom d'utilisateur et d'un mot de passe** NeuVector pour un compte du contrôleur disposant de la permission de lire les résultats de scan. Le connecteur se connecte avec ces identifiants pour obtenir un jeton de session ; le mot de passe et le jeton ne sont jamais journalisés. + +#### Correspondances du connecteur + +1. Saisissez l'URL de votre contrôleur NeuVector dans le champ **Location**, en incluant le port de l'API REST — par exemple `https://neuvector.example.com:10443`. +2. Saisissez le **Username** et le **Password** du contrôleur. +3. Si votre contrôleur utilise un certificat auto\-signé, réglez **Skip TLS Verification** sur `true`. +4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +DefectDojo associe chaque **image** scannée à un Record et chaque **CVE** de son rapport de scan à une constatation. La sévérité provient de la notation propre à NeuVector, et le paquet et la version concernés, le score et le vecteur CVSSv3, la version corrigée (en tant que mitigation) et le lien de référence sont repris. Les constatations sont dédupliquées sur l'image, le CVE, le paquet, la version et la sévérité. + +Consultez la [documentation de l'API NeuVector](https://open-docs.neuvector.com/automation/automation) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/neuvector.ja.md b/docs/content/connectors/toolreference/neuvector.ja.md new file mode 100644 index 00000000000..90a67ddf5f1 --- /dev/null +++ b/docs/content/connectors/toolreference/neuvector.ja.md @@ -0,0 +1,22 @@ +--- +title: "NeuVector" +description: "DefectDojo で NeuVector の Upstream Connector をセットアップする方法" +weight: 93 +audience: pro +--- +NeuVectorコネクタは、[NeuVector](https://github.com/neuvector/neuvector) コントローラのREST APIを使用して、コンテナ**イメージの脆弱性スキャン**をインポートします。DefectDojoは、NeuVectorがスキャンしたすべてのイメージを検出し、それぞれについてRecordを作成した上で、そのイメージのスキャンレポートを検出事項としてインポートします。 + +#### 前提条件 + +スキャン結果の読み取り権限を持つコントローラアカウントの、NeuVectorの**ユーザー名とパスワード**が必要です。コネクタはこれらの認証情報でログインしてセッショントークンを取得します。パスワードとトークンはログに記録されることはありません。 + +#### Connector Mappings + +1. **Location** フィールドに、REST APIポートを含むNeuVectorコントローラのURLを入力します — 例: `https://neuvector.example.com:10443`。 +2. コントローラの **Username** と **Password** を入力します。 +3. コントローラが自己署名証明書を使用している場合は、**Skip TLS Verification** を `true` に設定します。 +4. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 + +DefectDojoは、スキャン済みの各**イメージ**をRecordにマッピングし、そのスキャンレポート内の各**CVE**を検出事項にマッピングします。深刻度はNeuVector自身の評価に基づき、影響を受けるパッケージとバージョン、CVSSv3スコアとベクター、修正バージョン(緩和策として)、参照リンクが引き継がれます。検出事項は、イメージ、CVE、パッケージ、バージョン、深刻度で重複排除されます。 + +詳細については、[NeuVector APIドキュメント](https://open-docs.neuvector.com/automation/automation)を参照してください。 diff --git a/docs/content/connectors/toolreference/neuvector.md b/docs/content/connectors/toolreference/neuvector.md new file mode 100644 index 00000000000..bda13fde835 --- /dev/null +++ b/docs/content/connectors/toolreference/neuvector.md @@ -0,0 +1,22 @@ +--- +title: "NeuVector" +description: "How to set up the NeuVector Upstream Connector for DefectDojo" +weight: 93 +audience: pro +--- +The NeuVector connector uses the [NeuVector](https://github.com/neuvector/neuvector) controller REST API to import container **image vulnerability scans**. DefectDojo discovers every image NeuVector has scanned and creates a Record for each, then imports that image's scan report as findings. + +#### Prerequisites + +You will need a NeuVector **username and password** for a controller account with permission to read scan results. The connector logs in with these credentials to obtain a session token; the password and token are never logged. + +#### Connector Mappings + +1. Enter your NeuVector controller URL in the **Location** field, including the REST API port — for example `https://neuvector.example.com:10443`. +2. Enter the controller **Username** and **Password**. +3. If your controller uses a self-signed certificate, set **Skip TLS Verification** to `true`. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo maps each scanned **image** to a Record and each **CVE** in its scan report to a finding. The severity comes from NeuVector's own rating, and the affected package and version, CVSSv3 score and vector, fix version (as mitigation) and reference link are carried over. Findings are de-duplicated on the image, CVE, package, version and severity. + +See the [NeuVector API documentation](https://open-docs.neuvector.com/automation/automation) for more information. diff --git a/docs/content/connectors/toolreference/nightfall_ai.md b/docs/content/connectors/toolreference/nightfall_ai.md new file mode 100644 index 00000000000..1727c42efff --- /dev/null +++ b/docs/content/connectors/toolreference/nightfall_ai.md @@ -0,0 +1,21 @@ +--- +title: "Nightfall AI" +description: "How to set up the Nightfall AI Upstream Connector for DefectDojo" +weight: 94 +audience: pro +--- +The Nightfall AI connector imports **data loss prevention (DLP) violations** — sensitive data Nightfall has detected across your connected SaaS tools. DefectDojo creates a Record for each **connected integration** that has violations. + +The integration is the natural grouping here, because Nightfall's asset is the data source itself: Slack, Google Drive, GitHub, Jira, Confluence, Salesforce, Zendesk, Notion, Teams, OneDrive, the browser extension, and inline email. + +#### Prerequisites + +A Nightfall **API key**, sent as a bearer token and never logged. + +#### Connector Mappings + +1. Enter `https://api.nightfall.ai/dlp/v1` in the **Location** field. +2. Enter your Nightfall API key in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each integration with violations becomes a Record. Integrations with no violations are not mapped. diff --git a/docs/content/connectors/toolreference/nowsecure.md b/docs/content/connectors/toolreference/nowsecure.md new file mode 100644 index 00000000000..ae43ac1d8d3 --- /dev/null +++ b/docs/content/connectors/toolreference/nowsecure.md @@ -0,0 +1,19 @@ +--- +title: "NowSecure" +description: "How to set up the NowSecure Upstream Connector for DefectDojo" +weight: 95 +audience: pro +--- +The NowSecure connector imports **mobile application security findings**, covering both mobile SAST and DAST. DefectDojo creates a Record for each **mobile app** on the account. + +#### Prerequisites + +A NowSecure **Platform API token**, from **Profile \> Tokens \> Generate Token**. It is sent as a bearer token and never logged. + +#### Connector Mappings + +1. Enter `https://lab-api.nowsecure.com` in the **Location** field. +2. Enter the API token in the **API Token** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each mobile app becomes a Record, carrying the findings from that app's **latest assessment** — so results describe the current build rather than accumulating across assessments. diff --git a/docs/content/connectors/toolreference/nozomi_networks.md b/docs/content/connectors/toolreference/nozomi_networks.md new file mode 100644 index 00000000000..90dc8a13d0b --- /dev/null +++ b/docs/content/connectors/toolreference/nozomi_networks.md @@ -0,0 +1,20 @@ +--- +title: "Nozomi Networks" +description: "How to set up the Nozomi Networks Upstream Connector for DefectDojo" +weight: 96 +audience: pro +--- +The Nozomi Networks connector imports **OT/ICS vulnerability findings** from Nozomi Vantage. DefectDojo creates a Record for each **network zone**, so one Record represents one zone of your operational network. + +#### Prerequisites + +A Vantage **access key name** and **key token**, created under **Administration \> Security \> Access Keys**. DefectDojo exchanges them for a short\-lived session token on each Sync; the key token is never logged. + +#### Connector Mappings + +1. Enter `https://api.vantage.nozominetworks.io` in the **Location** field. +2. Enter the access key name in the **Key Name** field. +3. Enter the key token in the **Key Token** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +This connector imports **vulnerabilities only** — it does not import alert-log events — and only those Vantage still reports as **unresolved**, so vulnerabilities you resolve in Vantage are reflected in DefectDojo on the next Sync. diff --git a/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.de.md b/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.de.md new file mode 100644 index 00000000000..b5c634a672c --- /dev/null +++ b/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.de.md @@ -0,0 +1,20 @@ +--- +title: "Nuclei (ProjectDiscovery Cloud)" +description: "Einrichtung des Nuclei (ProjectDiscovery Cloud) Upstream-Connectors für DefectDojo" +weight: 97 +audience: pro +--- +Der Nuclei-Connector verwendet die REST-API der ProjectDiscovery Cloud Platform (PDCP), um [nuclei](https://github.com/projectdiscovery/nuclei)-Scan-Ergebnisse aus Ihrem PDCP-Konto abzurufen. DefectDojo ermittelt jeden Scan im Konto und erstellt für jeden **Scan** einen separaten Eintrag. + +#### Voraussetzungen + +Sie benötigen einen ProjectDiscovery-Cloud-**API-Schlüssel**. Wir empfehlen, für DefectDojo ein dediziertes Service-Konto anzulegen, um automatisierte Aktivitäten klar von manuellen Team-Aktionen zu unterscheiden. Generieren Sie einen Schlüssel unter **Settings \> API Key** in der ProjectDiscovery-Cloud-Oberfläche ([cloud.projectdiscovery.io](https://cloud.projectdiscovery.io)). Ergebnisse gelangen entweder über gehostete Scans oder über die mit `-dashboard` ausgeführte nuclei-CLI zu PDCP. + +#### Connector-Zuordnungen + +1. Geben Sie die Basis-URL der PDCP-API in das Feld **Location** ein: `https://api.projectdiscovery.io`. +2. Geben Sie Ihren **API-Schlüssel** in das Feld **Secret** ein. +3. Geben Sie optional eine **Team ID** ein, um den Sync auf einen Team-Workspace zu beschränken (zu finden unter **Settings \> Team**). Bleibt das Feld leer, synchronisiert DefectDojo Ihren persönlichen Workspace. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo ordnet jeden PDCP-**Scan** als separaten Eintrag zu und importiert dessen Befunde über alle Schweregrade hinweg, einschließlich informativer. diff --git a/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.es.md b/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.es.md new file mode 100644 index 00000000000..477aa18c25b --- /dev/null +++ b/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.es.md @@ -0,0 +1,20 @@ +--- +title: "Nuclei (ProjectDiscovery Cloud)" +description: "Cómo configurar el Conector Upstream de Nuclei (ProjectDiscovery Cloud) para DefectDojo" +weight: 97 +audience: pro +--- +El conector de Nuclei usa la API REST de ProjectDiscovery Cloud Platform (PDCP) para obtener resultados de escaneo de [nuclei](https://github.com/projectdiscovery/nuclei) desde su cuenta de PDCP. DefectDojo descubre cada escaneo de la cuenta y crea un Record independiente para cada **escaneo**. + +#### Requisitos previos + +Necesitará una **API key** de ProjectDiscovery Cloud. Recomendamos crear una cuenta de servicio dedicada para DefectDojo, de modo que la actividad automatizada se distinga claramente de las acciones manuales del equipo. Genere una clave desde **Settings > API Key** en la interfaz de ProjectDiscovery Cloud ([cloud.projectdiscovery.io](https://cloud.projectdiscovery.io)). Los resultados llegan a PDCP ya sea desde escaneos alojados (hosted) o desde la CLI de nuclei ejecutada con `-dashboard`. + +#### Asignaciones del conector + +1. Ingrese la URL base de la API de PDCP en el campo **Location**: `https://api.projectdiscovery.io`. +2. Ingrese su **API key** en el campo **Secret**. +3. Opcionalmente, ingrese un **Team ID** para limitar la sincronización a un espacio de trabajo de equipo (se encuentra en **Settings > Team**). Si se deja en blanco, DefectDojo sincroniza su espacio de trabajo personal. +4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo asigna cada **escaneo** de PDCP como un Record independiente e importa los hallazgos de ese escaneo en todas las severidades, incluida la informativa. diff --git a/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.fr.md b/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.fr.md new file mode 100644 index 00000000000..08a2a83ec9c --- /dev/null +++ b/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.fr.md @@ -0,0 +1,20 @@ +--- +title: "Nuclei (ProjectDiscovery Cloud)" +description: "Comment configurer le Connecteur Upstream Nuclei (ProjectDiscovery Cloud) pour DefectDojo" +weight: 97 +audience: pro +--- +Le connecteur Nuclei utilise l'API REST de la ProjectDiscovery Cloud Platform (PDCP) pour récupérer les résultats de scan [nuclei](https://github.com/projectdiscovery/nuclei) depuis votre compte PDCP. DefectDojo découvre chaque scan du compte et crée un Record distinct pour chaque **scan**. + +#### Prérequis + +Vous aurez besoin d'une **clé API** ProjectDiscovery Cloud. Nous recommandons de créer un compte de service dédié pour DefectDojo afin de bien distinguer l'activité automatisée des actions manuelles de l'équipe. Générez une clé depuis **Settings \> API Key** dans l'interface ProjectDiscovery Cloud ([cloud.projectdiscovery.io](https://cloud.projectdiscovery.io)). Les résultats parviennent à PDCP soit depuis des scans hébergés, soit depuis le CLI nuclei exécuté avec `-dashboard`. + +#### Correspondances du connecteur + +1. Saisissez l'URL de base de l'API PDCP dans le champ **Location** : `https://api.projectdiscovery.io`. +2. Saisissez votre **clé API** dans le champ **Secret**. +3. Optionnellement, saisissez un **Team ID** pour restreindre la synchronisation à un espace de travail d'équipe (trouvable sous **Settings \> Team**). Si laissé vide, DefectDojo synchronise votre espace de travail personnel. +4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +DefectDojo associe chaque **scan** PDCP à un Record distinct et importe les constatations de ce scan pour toutes les sévérités, y compris informationnelle. diff --git a/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.ja.md b/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.ja.md new file mode 100644 index 00000000000..1f228b8af4c --- /dev/null +++ b/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.ja.md @@ -0,0 +1,20 @@ +--- +title: "Nuclei (ProjectDiscovery Cloud)" +description: "DefectDojo で Nuclei (ProjectDiscovery Cloud) の Upstream Connector をセットアップする方法" +weight: 97 +audience: pro +--- +NucleiコネクタはProjectDiscovery Cloud Platform (PDCP) REST APIを使用して、お使いのPDCPアカウントから [nuclei](https://github.com/projectdiscovery/nuclei) のスキャン結果を取得します。DefectDojoはアカウント内のすべてのスキャンを検出し、**スキャン**ごとに個別のRecordを作成します。 + +#### 前提条件 + +ProjectDiscovery Cloudの**APIキー**が必要です。自動化された処理と手動のチーム操作を明確に区別するため、DefectDojo専用のサービスアカウントを作成することをお勧めします。ProjectDiscovery Cloud UI([cloud.projectdiscovery.io](https://cloud.projectdiscovery.io))の **Settings > API Key** からキーを生成します。結果は、ホスト型スキャンから、または `-dashboard` を付けて実行したnuclei CLIからPDCPに届きます。 + +#### Connector Mappings + +1. **Location** フィールドにPDCPのAPIベースURLを入力します: `https://api.projectdiscovery.io`。 +2. **Secret** フィールドに**APIキー**を入力します。 +3. 必要に応じて、**Team ID** を入力してチームワークスペースに同期範囲を絞り込みます(**Settings > Team** の下にあります)。空欄のままにすると、DefectDojoは個人用ワークスペースを同期します。 +4. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 + +DefectDojoは、各PDCPの**スキャン**を個別のRecordとしてマッピングし、情報レベルを含むすべての深刻度にわたって、そのスキャンの検出事項をインポートします。 diff --git a/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.md b/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.md new file mode 100644 index 00000000000..f1a19e2520e --- /dev/null +++ b/docs/content/connectors/toolreference/nuclei_projectdiscovery_cloud.md @@ -0,0 +1,20 @@ +--- +title: "Nuclei (ProjectDiscovery Cloud)" +description: "How to set up the Nuclei (ProjectDiscovery Cloud) Upstream Connector for DefectDojo" +weight: 97 +audience: pro +--- +The Nuclei connector uses the ProjectDiscovery Cloud Platform (PDCP) REST API to pull [nuclei](https://github.com/projectdiscovery/nuclei) scan results from your PDCP account. DefectDojo discovers every scan in the account and creates a separate Record for each **scan**. + +#### Prerequisites + +You will need a ProjectDiscovery Cloud **API key**. We recommend creating a dedicated service account for DefectDojo to clearly distinguish automated activity from manual team actions. Generate a key from **Settings \> API Key** in the ProjectDiscovery Cloud UI ([cloud.projectdiscovery.io](https://cloud.projectdiscovery.io)). Results reach PDCP either from hosted scans or from the nuclei CLI run with `-dashboard`. + +#### Connector Mappings + +1. Enter the PDCP API base URL in the **Location** field: `https://api.projectdiscovery.io`. +2. Enter your **API key** in the **Secret** field. +3. Optionally, enter a **Team ID** to scope the sync to a team workspace (found under **Settings \> Team**). When left blank, DefectDojo syncs your personal workspace. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo maps each PDCP **scan** as a separate Record and imports that scan's findings across every severity, including informational. diff --git a/docs/content/connectors/toolreference/openvas_greenbone.de.md b/docs/content/connectors/toolreference/openvas_greenbone.de.md new file mode 100644 index 00000000000..39dd73a240a --- /dev/null +++ b/docs/content/connectors/toolreference/openvas_greenbone.de.md @@ -0,0 +1,21 @@ +--- +title: "OpenVAS / Greenbone" +description: "Einrichtung des OpenVAS / Greenbone Upstream-Connectors für DefectDojo" +weight: 98 +audience: pro +--- +Der OpenVAS-/Greenbone-Connector importiert **Netzwerk-Schwachstellenbefunde** aus einer Greenbone-Instanz (Greenbone Community Edition oder Greenbone Enterprise). Er kommuniziert mit `gvmd` über **GMP (Greenbone Management Protocol)** — ein XML-Protokoll über ein TLS-Socket, nicht HTTP — und synchronisiert die gesamte Instanz: Er zählt Scan-**Tasks** auf und erstellt für jeden ein DefectDojo-Produkt, wobei die Ergebnisse des jeweils letzten Berichts jedes Tasks importiert werden. + +#### Voraussetzungen + +Ein Greenbone-**GMP-Benutzer** (Benutzername + Passwort) und Netzwerkzugriff auf den GMP-TLS-Port von gvmd (standardmäßig **9390**). Der Compose-Stack der Greenbone Community Edition stellt gvmd über einen Unix-Socket bereit; um ihn von einem vernetzten Connector aus zu erreichen, betreiben Sie den Connector entweder dort, wo er den Socket erreichen kann, oder exponieren Sie den GMP-TLS-Port (zum Beispiel eine `socat`-TLS-Bridge zu `gvmd.sock`). + +#### Connector-Zuordnungen + +1. Geben Sie den gvmd-Host in das Feld **Location** ein (Host oder `host:port`). +2. Geben Sie den GMP-**Username** und das **Password** ein. +3. Legen Sie optional den **GMP Port** fest (Standard 9390). +4. Für das standardmäßige selbstsignierte Zertifikat von gvmd geben Sie entweder ein **CA Certificate (PEM)** zur Verifizierung an, oder setzen Sie **Skip TLS Verification** auf `true`. +5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jeder Greenbone-Task wird zu einem Eintrag. Befunde stammen aus dem letzten abgeschlossenen Bericht des Tasks — einer pro ``. Der Schweregrad wird der Threat-Level-Angabe des Ergebnisses entnommen (Greenbones informative Stufen `Log`/`Debug` werden auf Info abgebildet), wobei der numerische CVSS-Score erfasst wird; CVE-Referenzen werden zu Schwachstellen-IDs, die NVT-Lösung wird zur Abhilfemaßnahme, und Host/Port jedes Ergebnisses werden zu einem Endpunkt. diff --git a/docs/content/connectors/toolreference/openvas_greenbone.es.md b/docs/content/connectors/toolreference/openvas_greenbone.es.md new file mode 100644 index 00000000000..54e67cf1111 --- /dev/null +++ b/docs/content/connectors/toolreference/openvas_greenbone.es.md @@ -0,0 +1,21 @@ +--- +title: "OpenVAS / Greenbone" +description: "Cómo configurar el Conector Upstream de OpenVAS / Greenbone para DefectDojo" +weight: 98 +audience: pro +--- +El conector de OpenVAS / Greenbone importa **hallazgos de vulnerabilidades de red** desde una instancia de Greenbone (Greenbone Community Edition o Greenbone Enterprise). Se comunica con `gvmd` mediante **GMP (Greenbone Management Protocol)** —un protocolo XML sobre un socket TLS, no HTTP— y sincroniza toda la instancia: enumera las **tareas (tasks)** de escaneo y crea un producto de DefectDojo para cada una, importando los resultados del informe más reciente de cada tarea. + +#### Requisitos previos + +Un **usuario GMP** de Greenbone (nombre de usuario + contraseña) y acceso de red al puerto TLS de GMP de gvmd (por defecto **9390**). El stack de compose de Greenbone Community Edition expone gvmd a través de un socket unix, así que para alcanzarlo desde un conector conectado en red debe ejecutar el conector donde pueda acceder al socket, o exponer el puerto TLS de GMP (por ejemplo, un puente TLS con `socat` hacia `gvmd.sock`). + +#### Asignaciones del conector + +1. Ingrese el host de gvmd en el campo **Location** (host o `host:port`). +2. Ingrese el **Username** y **Password** de GMP. +3. Opcionalmente, establezca el **GMP Port** (por defecto 9390). +4. Para el certificado autofirmado predeterminado de gvmd, proporcione un **CA Certificate (PEM)** contra el cual verificar, o bien establezca **Skip TLS Verification** en `true`. +5. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada tarea de Greenbone se convierte en un Record. Los hallazgos provienen del informe finalizado más reciente de la tarea, uno por cada ``. La severidad se toma del nivel de amenaza (threat level) del resultado (los niveles informativos `Log`/`Debug` de Greenbone se asignan a Informativa), y se registra la puntuación CVSS numérica; las referencias CVE se convierten en identificadores de vulnerabilidad, la solución del NVT se convierte en la mitigación, y el host/puerto de cada resultado se convierte en un endpoint. diff --git a/docs/content/connectors/toolreference/openvas_greenbone.fr.md b/docs/content/connectors/toolreference/openvas_greenbone.fr.md new file mode 100644 index 00000000000..652a0781373 --- /dev/null +++ b/docs/content/connectors/toolreference/openvas_greenbone.fr.md @@ -0,0 +1,21 @@ +--- +title: "OpenVAS / Greenbone" +description: "Comment configurer le Connecteur Upstream OpenVAS / Greenbone pour DefectDojo" +weight: 98 +audience: pro +--- +Le connecteur OpenVAS / Greenbone importe les **constatations de vulnérabilités réseau** d'une instance Greenbone (Greenbone Community Edition ou Greenbone Enterprise). Il communique avec `gvmd` via **GMP (Greenbone Management Protocol)** — un protocole XML sur un socket TLS, et non HTTP — et synchronise l'instance entière : il énumère les **tâches** de scan et crée un produit DefectDojo pour chacune, en important les résultats du dernier rapport de chaque tâche. + +#### Prérequis + +Un **utilisateur GMP** Greenbone (nom d'utilisateur + mot de passe) et un accès réseau au port TLS GMP de gvmd (par défaut **9390**). La pile compose de Greenbone Community Edition expose gvmd via un socket unix ; pour l'atteindre depuis un connecteur en réseau, exécutez donc le connecteur là où il peut accéder au socket, ou exposez le port TLS GMP (par exemple un pont TLS `socat` vers `gvmd.sock`). + +#### Correspondances du connecteur + +1. Saisissez l'hôte gvmd dans le champ **Location** (hôte ou `host:port`). +2. Saisissez le **Username** et le **Password** GMP. +3. Optionnellement, définissez le **GMP Port** (par défaut 9390). +4. Pour le certificat auto\-signé par défaut de gvmd, fournissez soit un **CA Certificate (PEM)** pour la vérification, soit réglez **Skip TLS Verification** sur `true`. +5. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque tâche Greenbone devient un Record. Les constatations proviennent du dernier rapport terminé de la tâche — une par ``. La sévérité est tirée du niveau de menace du résultat (les niveaux informationnels `Log`/`Debug` de Greenbone sont associés à Info), avec le score CVSS numérique enregistré ; les références CVE deviennent des identifiants de vulnérabilité, la solution du NVT devient la mitigation, et l'hôte/port de chaque résultat devient un point de terminaison. diff --git a/docs/content/connectors/toolreference/openvas_greenbone.ja.md b/docs/content/connectors/toolreference/openvas_greenbone.ja.md new file mode 100644 index 00000000000..f39a38a3dd3 --- /dev/null +++ b/docs/content/connectors/toolreference/openvas_greenbone.ja.md @@ -0,0 +1,21 @@ +--- +title: "OpenVAS / Greenbone" +description: "DefectDojo で OpenVAS / Greenbone の Upstream Connector をセットアップする方法" +weight: 98 +audience: pro +--- +OpenVAS / Greenboneコネクタは、Greenbone(Greenbone Community EditionまたはGreenbone Enterprise)インスタンスから**ネットワーク脆弱性の検出事項**をインポートします。これは、HTTPではなく**GMP (Greenbone Management Protocol)** — TLSソケット上のXMLプロトコル — を介して `gvmd` と通信し、インスタンス全体を同期します。スキャン**タスク**を列挙してそれぞれについてDefectDojoの製品を作成し、各タスクの最新レポートの結果をインポートします。 + +#### 前提条件 + +Greenboneの**GMPユーザー**(ユーザー名とパスワード)と、gvmdのGMP TLSポート(デフォルトは**9390**)へのネットワークアクセスが必要です。Greenbone Community Editionのcomposeスタックは、unixソケット経由でgvmdをフロントに置いているため、ネットワーク経由のコネクタからそこに到達するには、ソケットに到達できる場所でコネクタを実行するか、GMP TLSポートを公開する必要があります(例: `gvmd.sock` へのTLSブリッジとして `socat` を使用)。 + +#### Connector Mappings + +1. **Location** フィールドにgvmdホストを入力します(ホスト名、または `host:port`)。 +2. GMPの **Username** と **Password** を入力します。 +3. 必要に応じて **GMP Port** を設定します(デフォルトは9390)。 +4. gvmdのデフォルトの自己署名証明書に対しては、検証用に **CA Certificate (PEM)** を指定するか、**Skip TLS Verification** を `true` に設定してください。 +5. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 + +各Greenboneタスクが1件のRecordになります。検出事項はタスクの最新の完了レポートから取得され、`` ごとに1件です。深刻度は結果の脅威レベルから取得され(Greenboneの `Log`/`Debug` の情報レベルはInfoにマッピングされます)、数値のCVSSスコアが記録されます。CVEの参照は脆弱性IDになり、NVTのsolutionは緩和策になり、各結果のホスト/ポートはエンドポイントになります。 diff --git a/docs/content/connectors/toolreference/openvas_greenbone.md b/docs/content/connectors/toolreference/openvas_greenbone.md new file mode 100644 index 00000000000..081dc638da5 --- /dev/null +++ b/docs/content/connectors/toolreference/openvas_greenbone.md @@ -0,0 +1,47 @@ +--- +title: "OpenVAS / Greenbone" +description: "How to set up the OpenVAS / Greenbone Upstream Connector for DefectDojo" +weight: 98 +audience: pro +--- +The OpenVAS / Greenbone connector imports **network vulnerability findings** from a Greenbone (Greenbone Community Edition or Greenbone Enterprise) instance. It talks to `gvmd` over **GMP (Greenbone Management Protocol)** — an XML protocol, not HTTP — and syncs the whole instance: it enumerates scan **tasks** and creates a DefectDojo product for each, importing the results of each task's latest report. + +GMP can be carried two ways, and which one you need depends on your Greenbone version: + +* **SSH** — what Greenbone documents from **GOS 4** onwards, and the right choice for a current instance. +* **TLS** — gvmd's older transport on port **9390**. It was the default only through GOS 3.1, and a current Greenbone commonly exposes no TLS listener at all. + +#### Prerequisites + +A Greenbone **GMP user** (username + password) in all cases. The GMP user is always required: SSH only carries the connection to `gvmd`, and GMP still authenticates over it. + +For the **SSH** transport, an SSH account on the Greenbone host that reaches `gvmd`, plus its host key fingerprint. Either arrangement works and the connector detects which one your host uses: + +* An account whose forced command connects the session to `gvmd` — the arrangement Greenbone appliances ship, and the one `gvm-tools` uses. The default account name is `gmp`. +* An ordinary account permitted to forward to gvmd's unix socket (`AllowStreamLocalForwarding`), which suits self\-managed and containerised installs. + +For the **TLS** transport, network access to gvmd's GMP TLS port (default **9390**). Note that the Greenbone Community Edition compose stack fronts `gvmd` with a unix socket and no TLS listener, so this transport needs something in front of the socket — for example a `socat` TLS bridge to `gvmd.sock`. + +#### Connector Mappings + +1. Enter the Greenbone host in the **Location** field. +2. Enter the GMP **Username** and **Password**. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Then configure one transport. + +**For SSH:** + +1. Set **Transport** to `ssh`. +2. Enter the **SSH Username** (defaults to `gmp`) and, if it is not 22, the **SSH Port**. +3. Provide either an **SSH Private Key** — with its **SSH Key Passphrase** if the key is encrypted — or an **SSH Password**. A key is preferred. +4. Enter the **SSH Host Key Fingerprint**. A server usually offers host keys of several types and there is no telling in advance which one gets negotiated, so paste **all** of them, separated by commas or spaces. `ssh-keyscan | ssh-keygen -lf -` prints them for every key the host offers, and its output can be pasted as\-is. Setting **Skip SSH Host Key Check** to `true` accepts any host key instead, which is not recommended. Note that **Skip TLS Verification** does *not* do this \- it covers the TLS certificate only, so that routinely skipping the check on gvmd's self\-signed certificate cannot quietly un\-pin your host keys. +5. Optionally set the **gvmd Socket Path** if your host permits socket forwarding but keeps the socket somewhere non\-standard. Left blank, the connector probes the usual locations. + +**For TLS:** + +1. Leave **Transport** blank. +2. Optionally set the **GMP Port** (defaults to 9390). +3. For gvmd's default self\-signed certificate, either provide a **CA Certificate (PEM)** to verify against, or set **Skip TLS Verification** to `true`. + +Each Greenbone task becomes a Record. Findings come from the task's latest finished report — one per ``. Severity is taken from the result's threat level (Greenbone's `Log`/`Debug` informational levels map to Info), with the numeric CVSS score recorded; CVE references become vulnerability ids, the NVT solution becomes the mitigation, and each result's host/port becomes an endpoint. diff --git a/docs/content/connectors/toolreference/opsgenie.de.md b/docs/content/connectors/toolreference/opsgenie.de.md new file mode 100644 index 00000000000..c03365861c7 --- /dev/null +++ b/docs/content/connectors/toolreference/opsgenie.de.md @@ -0,0 +1,44 @@ +--- +title: "Opsgenie" +description: "Einrichtung des Opsgenie Downstream-Connectors für DefectDojo" +weight: 99 +audience: pro +--- +Die Opsgenie-Integration ermöglicht es Ihnen, DefectDojo-Befunde und Befundgruppen als Opsgenie-Alerts zu übertragen, die optional an ein Opsgenie-Team als Responder geleitet werden. + +### Instanz-Einrichtung + +- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf `https://api.opsgenie.com` gesetzt werden. Wird Ihr Opsgenie-Konto in der EU-Serviceregion gehostet, verwenden Sie stattdessen `https://api.eu.opsgenie.com`. Liegen Ihre Alerts in Jira Service Management Operations (Atlassian überführt Opsgenie in JSM), verwenden Sie `https://api.atlassian.com/jsm/ops/integration`. +- **API Key** sollte auf einen Opsgenie-**API-Integrations**-Key gesetzt werden. Ein Kontoadministrator kann einen solchen in der Opsgenie-Web-App unter **Settings > Integrations** erstellen: Fügen Sie eine Integration des Typs **API** hinzu und erteilen Sie ihr *Create and Update Access* (sowie *Read Access*, damit DefectDojo die Verbindung prüfen kann). Beachten Sie, dass dies ein Integrations-Key und kein persönlicher API-Key ist - DefectDojo authentifiziert sich mit `GenieKey`-Autorisierung, die nur Integrations-Keys unterstützen. + +### Issue-Tracker-Zuordnung + +- **Team Name** *(optional)* sollte der Name des Opsgenie-Teams sein, das erstellten Alerts als Responder hinzugefügt wird. Sie können das Feld leer lassen: Ist der API-Integrations-Key teambezogen, werden Alerts automatisch an dieses Team geleitet, andernfalls entscheiden die Routing-Regeln Ihres Kontos über die Responder. + +### Details zur Schweregrad-Zuordnung + +Schweregrade werden dem Opsgenie-Alert-Feld **Priority** zugeordnet, das die feste Opsgenie-Skala von `P1` (kritisch) bis `P5` (informativ) verwendet: + +- **Name des Schweregrad-Felds**: `Priority` +- **Info-Zuordnung**: `P5` +- **Niedrig-Zuordnung**: `P4` +- **Mittel-Zuordnung**: `P3` +- **Hoch-Zuordnung**: `P2` +- **Kritisch-Zuordnung**: `P1` + +Ist ein Schweregrad einem unbekannten Wert zugeordnet, wird die Priorität weggelassen und Opsgenie wendet seinen eigenen Standard (`P3`) an. + +### Details zur Status-Zuordnung + +Opsgenie-Alerts sind `open` oder `closed`, und ein offener Alert kann zusätzlich `acknowledged` sein: + +- **Name des Status-Felds**: `Status` +- **Aktiv-Zuordnung**: `open` +- **Geschlossen-Zuordnung**: `closed` +- **Falsch-positiv-Zuordnung**: `closed` +- **Risiko-akzeptiert-Zuordnung**: `acknowledged` + +Beachten Sie, dass `closed` in Opsgenie ein endgültiger Status ist - ein geschlossener Alert kann nicht wieder geöffnet werden, und sein Alias wird freigegeben. Anders als manche anderen Tools erlaubt Opsgenie Inhaltsänderungen nach dem Erstellen, sodass beim Übertragen eines aktualisierten Befunds neben dem Status auch Nachricht, Beschreibung und Priorität synchronisiert werden. + +DefectDojo setzt den **Alias** jedes Alerts auf einen stabilen Schlüssel, der vom Befund oder von der Befundgruppe abgeleitet ist, und Opsgenie dedupliziert offene Alerts anhand des Alias - ein erneutes Übertragen desselben Befunds aktualisiert daher den bestehenden offenen Alert, anstatt ein Duplikat zu erzeugen. diff --git a/docs/content/connectors/toolreference/opsgenie.es.md b/docs/content/connectors/toolreference/opsgenie.es.md new file mode 100644 index 00000000000..de9eab3009a --- /dev/null +++ b/docs/content/connectors/toolreference/opsgenie.es.md @@ -0,0 +1,44 @@ +--- +title: "Opsgenie" +description: "Cómo configurar el Conector Downstream de Opsgenie para DefectDojo" +weight: 99 +audience: pro +--- +La integración de Opsgenie le permite enviar los Hallazgos y Grupos de Hallazgos de DefectDojo como alertas de Opsgenie, opcionalmente enrutadas a un equipo de Opsgenie como responsable. + +### Configuración de la instancia + +- **Label** debe ser la etiqueta que desea usar para identificar esta integración. +- **Location** debe establecerse en `https://api.opsgenie.com`. Si su cuenta de Opsgenie está alojada en la región de servicio de la UE, use `https://api.eu.opsgenie.com` en su lugar. Si sus alertas residen en Jira Service Management Operations (Atlassian está integrando Opsgenie en JSM), use `https://api.atlassian.com/jsm/ops/integration`. +- **API Key** debe establecerse en una clave de **integración API** de Opsgenie. Un administrador de la cuenta puede crear una en la aplicación web de Opsgenie en **Settings > Integrations**: añada una integración de tipo **API** y otórguele *Create and Update Access* (y *Read Access* para que DefectDojo pueda verificar la conexión). Tenga en cuenta que esto es una clave de integración, no una clave de API personal - DefectDojo se autentica con autorización `GenieKey`, que solo admiten las claves de integración. + +### Mapeo del Issue Tracker + +- **Team Name** *(opcional)* debe ser el nombre del equipo de Opsgenie que se añadirá como responsable en las alertas creadas. Puede dejarlo vacío: si la clave de integración de la API tiene alcance de equipo, las alertas se enrutan automáticamente a ese equipo, y en caso contrario las propias reglas de enrutamiento de su cuenta deciden los responsables. + +### Detalles del mapeo de severidad + +Las severidades se mapean al campo **Priority** de la alerta de Opsgenie, que usa la escala fija de Opsgenie de `P1` (crítica) a `P5` (informativa): + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `P5` +- **Low Mapping**: `P4` +- **Medium Mapping**: `P3` +- **High Mapping**: `P2` +- **Critical Mapping**: `P1` + +Si una severidad se mapea a un valor no reconocido, se omite la prioridad y Opsgenie aplica su propio valor predeterminado (`P3`). + +### Detalles del mapeo de estado + +Las alertas de Opsgenie son `open` o `closed`, y una alerta abierta puede además estar `acknowledged`: + +- **Status Field Name**: `Status` +- **Active Mapping**: `open` +- **Closed Mapping**: `closed` +- **False Positive Mapping**: `closed` +- **Risk Accepted Mapping**: `acknowledged` + +Tenga en cuenta que `closed` es un estado final en Opsgenie - una alerta cerrada no se puede reabrir, y su alias queda liberado. A diferencia de otras herramientas, Opsgenie sí permite editar el contenido después de la creación, así que enviar un Hallazgo actualizado sincroniza su mensaje, descripción y prioridad junto con el estado. + +DefectDojo establece el **alias** de cada alerta con una clave estable derivada del Hallazgo o Grupo de Hallazgos, y Opsgenie deduplica las alertas abiertas por alias - así que reenviar el mismo Hallazgo actualiza la alerta abierta existente en lugar de crear un duplicado. diff --git a/docs/content/connectors/toolreference/opsgenie.fr.md b/docs/content/connectors/toolreference/opsgenie.fr.md new file mode 100644 index 00000000000..6a4e439d56d --- /dev/null +++ b/docs/content/connectors/toolreference/opsgenie.fr.md @@ -0,0 +1,44 @@ +--- +title: "Opsgenie" +description: "Comment configurer le Connecteur Downstream Opsgenie pour DefectDojo" +weight: 99 +audience: pro +--- +L'intégration Opsgenie vous permet de transmettre les Constatations et Groupes de constatations de DefectDojo sous forme d'alertes Opsgenie, éventuellement routées vers une équipe Opsgenie en tant que répondant. + +### Configuration de l'instance + +- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur `https://api.opsgenie.com`. Si votre compte Opsgenie est hébergé dans la région de service UE, utilisez plutôt `https://api.eu.opsgenie.com`. Si vos alertes se trouvent dans Jira Service Management Operations (Atlassian intègre progressivement Opsgenie à JSM), utilisez `https://api.atlassian.com/jsm/ops/integration`. +- **API Key** doit être définie sur une clé d'**intégration API** Opsgenie. Un administrateur de compte peut en créer une dans l'application web Opsgenie, sous **Settings > Integrations** : ajoutez une intégration de type **API** et accordez-lui *Create and Update Access* (ainsi que *Read Access* afin que DefectDojo puisse vérifier la connexion). Notez qu'il s'agit d'une clé d'intégration, et non d'une clé API personnelle - DefectDojo s'authentifie avec l'autorisation `GenieKey`, que seules les clés d'intégration prennent en charge. + +### Mappage du suivi des tickets + +- **Team Name** *(facultatif)* doit correspondre au nom de l'équipe Opsgenie à ajouter comme répondant sur les alertes créées. Vous pouvez le laisser vide : si la clé d'intégration API est limitée à une équipe, les alertes sont routées automatiquement vers celle-ci, et sinon ce sont les règles de routage propres à votre compte qui déterminent les répondants. + +### Détails du mappage de la sévérité + +Les sévérités correspondent au champ **Priority** des alertes Opsgenie, qui utilise l'échelle fixe d'Opsgenie allant de `P1` (critique) à `P5` (informatif) : + +- **Severity Field Name** : `Priority` +- **Info Mapping** : `P5` +- **Low Mapping** : `P4` +- **Medium Mapping** : `P3` +- **High Mapping** : `P2` +- **Critical Mapping** : `P1` + +Si une sévérité est mappée à une valeur non reconnue, la priorité est omise et Opsgenie applique sa propre valeur par défaut (`P3`). + +### Détails du mappage du statut + +Les alertes Opsgenie sont `open` ou `closed`, et une alerte ouverte peut en outre être `acknowledged` : + +- **Status Field Name** : `Status` +- **Active Mapping** : `open` +- **Closed Mapping** : `closed` +- **False Positive Mapping** : `closed` +- **Risk Accepted Mapping** : `acknowledged` + +Notez que `closed` est un statut final dans Opsgenie - une alerte fermée ne peut pas être rouverte, et son alias est libéré. Contrairement à certains autres outils, Opsgenie autorise les modifications de contenu après création ; ainsi, la transmission d'une Constatation mise à jour synchronise son message, sa description et sa priorité en plus du statut. + +DefectDojo définit l'**alias** de chaque alerte sur une clé stable dérivée de la Constatation ou du Groupe de constatations, et Opsgenie dé-duplique les alertes ouvertes par alias - ainsi, retransmettre la même Constatation met à jour l'alerte ouverte existante au lieu d'en créer une nouvelle. diff --git a/docs/content/connectors/toolreference/opsgenie.ja.md b/docs/content/connectors/toolreference/opsgenie.ja.md new file mode 100644 index 00000000000..e379ad50be6 --- /dev/null +++ b/docs/content/connectors/toolreference/opsgenie.ja.md @@ -0,0 +1,44 @@ +--- +title: "Opsgenie" +description: "DefectDojo で Opsgenie のダウンストリームコネクタをセットアップする方法" +weight: 99 +audience: pro +--- +Opsgenie 統合を使うと、DefectDojo の Finding および Finding Group を Opsgenie のアラートとしてプッシュでき、必要に応じて Opsgenie の Team をレスポンダーとして割り当てることもできます。 + +### Instance Setup + +- **Label** は、この統合を識別するために使用したいラベルを設定します。 +- **Location** は、`https://api.opsgenie.com` を設定します。Opsgenie アカウントが EU サービスリージョンでホストされている場合は、代わりに `https://api.eu.opsgenie.com` を使用してください。アラートが Jira Service Management Operations 上にある場合（Atlassian は Opsgenie を JSM に統合しつつあります）は、`https://api.atlassian.com/jsm/ops/integration` を使用してください。 +- **API Key** は、Opsgenie の **API integration** キーを設定します。アカウント管理者は、Opsgenie の Web アプリの **Settings > Integrations** から、タイプ **API** の統合を追加し、*Create and Update Access*（DefectDojo が接続を検証できるように *Read Access* も）を付与することで作成できます。これはパーソナル API キーではなく統合キーである点に注意してください。DefectDojo は `GenieKey` 認証方式を使用しており、これに対応しているのは統合キーのみです。 + +### Issue Tracker Mapping + +- **Team Name**（オプション）は、作成されたアラートにレスポンダーとして追加したい Opsgenie Team の名前です。空欄のままにもできます。API integration キーが特定のチームにスコープされている場合、アラートは自動的にそのチームにルーティングされ、そうでない場合はアカウント自身のルーティングルールがレスポンダーを決定します。 + +### Severity Mapping Details + +深刻度は、Opsgenie の固定スケールである `P1`（critical）から `P5`（informational）までを使う、アラートの **Priority** フィールドにマッピングされます。 + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `P5` +- **Low Mapping**: `P4` +- **Medium Mapping**: `P3` +- **High Mapping**: `P2` +- **Critical Mapping**: `P1` + +深刻度が認識されない値にマッピングされている場合、priority は省略され、Opsgenie 側のデフォルト値（`P3`）が適用されます。 + +### Status Mapping Details + +Opsgenie のアラートは `open` または `closed` であり、open のアラートはさらに `acknowledged` にもなり得ます。 + +- **Status Field Name**: `Status` +- **Active Mapping**: `open` +- **Closed Mapping**: `closed` +- **False Positive Mapping**: `closed` +- **Risk Accepted Mapping**: `acknowledged` + +なお、Opsgenie では `closed` は最終ステータスであり、クローズされたアラートは再オープンできず、そのエイリアスも解放されます。他の一部のツールとは異なり、Opsgenie は作成後もコンテンツの編集を許可しているため、更新された Finding をプッシュすると、ステータスとあわせてメッセージ、説明、priority も同期されます。 + +DefectDojo は、Finding または Finding Group から導出した安定したキーを各アラートの **alias** として設定し、Opsgenie はこの alias によって open 状態のアラートを重複排除します。そのため、同じ Finding を再度プッシュすると、新しいアラートを作成するのではなく、既存の open なアラートが更新されます。 diff --git a/docs/content/connectors/toolreference/opsgenie.md b/docs/content/connectors/toolreference/opsgenie.md new file mode 100644 index 00000000000..52b475d49f3 --- /dev/null +++ b/docs/content/connectors/toolreference/opsgenie.md @@ -0,0 +1,44 @@ +--- +title: "Opsgenie" +description: "How to set up the Opsgenie Downstream Connector for DefectDojo" +weight: 99 +audience: pro +--- +The Opsgenie Integration allows you to push DefectDojo Findings and Finding Groups as Opsgenie Alerts, optionally routed to an Opsgenie Team as a responder. + +### Instance Setup + +- **Label** should be the label that you want to use to identify this integration. +- **Location** should be set to `https://api.opsgenie.com`. If your Opsgenie account is hosted in the EU service region, use `https://api.eu.opsgenie.com` instead. If your alerts live in Jira Service Management Operations (Atlassian is folding Opsgenie into JSM), use `https://api.atlassian.com/jsm/ops/integration`. +- **API Key** should be set to an Opsgenie **API integration** key. An account administrator can create one in the Opsgenie web app under **Settings > Integrations**: add an integration of type **API** and give it *Create and Update Access* (and *Read Access* so DefectDojo can verify the connection). Note that this is an integration key, not a personal API key - DefectDojo authenticates with `GenieKey` authorization, which only integration keys support. + +### Issue Tracker Mapping + +- **Team Name** *(optional)* should be the name of the Opsgenie Team to add as a responder on created alerts. You can leave it empty: if the API integration key is team-scoped, alerts route to that team automatically, and otherwise your account's own routing rules decide the responders. + +### Severity Mapping Details + +Severities map to the Opsgenie alert **Priority** field, which uses Opsgenie's fixed `P1` (critical) through `P5` (informational) scale: + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `P5` +- **Low Mapping**: `P4` +- **Medium Mapping**: `P3` +- **High Mapping**: `P2` +- **Critical Mapping**: `P1` + +If a severity is mapped to an unrecognized value, the priority is omitted and Opsgenie applies its own default (`P3`). + +### Status Mapping Details + +Opsgenie alerts are `open` or `closed`, and an open alert can additionally be `acknowledged`: + +- **Status Field Name**: `Status` +- **Active Mapping**: `open` +- **Closed Mapping**: `closed` +- **False Positive Mapping**: `closed` +- **Risk Accepted Mapping**: `acknowledged` + +Note that `closed` is a final status in Opsgenie - a closed alert cannot be reopened, and its alias is released. Unlike some other tools, Opsgenie does allow content edits after creation, so pushing an updated Finding syncs its message, description, and priority alongside the status. + +DefectDojo sets each alert's **alias** to a stable key derived from the Finding or Finding Group, and Opsgenie de-duplicates open alerts by alias - so re-pushing the same Finding updates the existing open alert instead of creating a duplicate. diff --git a/docs/content/connectors/toolreference/orca_security.md b/docs/content/connectors/toolreference/orca_security.md new file mode 100644 index 00000000000..4fa473644bf --- /dev/null +++ b/docs/content/connectors/toolreference/orca_security.md @@ -0,0 +1,21 @@ +--- +title: "Orca Security" +description: "How to set up the Orca Security Upstream Connector for DefectDojo" +weight: 100 +audience: pro +--- +The Orca Security connector imports **open alerts** from Orca — vulnerabilities, misconfigurations, malware and secrets alike. DefectDojo creates a Record for each **connected cloud account**. + +#### Prerequisites + +An Orca **API token**. + +**Orca tokens are region-scoped**, so the token and the API host must belong to the same region. If a Sync fails to authenticate with a token you know is valid, check that the **Location** matches the token's region. + +#### Connector Mappings + +1. Enter your **region-matched** Orca API host in the **Location** field. +2. Enter your Orca API token in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each connected cloud account becomes a Record. Only **open** alerts are imported, so alerts you close in Orca are reflected in DefectDojo on the next Sync. diff --git a/docs/content/connectors/toolreference/ostorlab.md b/docs/content/connectors/toolreference/ostorlab.md new file mode 100644 index 00000000000..7dc58792156 --- /dev/null +++ b/docs/content/connectors/toolreference/ostorlab.md @@ -0,0 +1,19 @@ +--- +title: "Ostorlab" +description: "How to set up the Ostorlab Upstream Connector for DefectDojo" +weight: 101 +audience: pro +--- +The Ostorlab connector imports **mobile, web and attack-surface findings** — all three of Ostorlab's asset classes through one connector. DefectDojo creates a Record for each **scanned asset**, which may be an app bundle ID, a domain, or a host. + +#### Prerequisites + +An Ostorlab **API key**, created under **Settings \> API Keys**. It is sent as the `X-Api-Key` header and is never logged. + +#### Connector Mappings + +1. Enter `https://api.ostorlab.co` in the **Location** field. DefectDojo appends the GraphQL API path itself. +2. Enter your Ostorlab API key in the **API Key** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each scanned asset becomes a Record, and the vulnerabilities from every scan of that asset are imported against it. diff --git a/docs/content/connectors/toolreference/pagerduty.de.md b/docs/content/connectors/toolreference/pagerduty.de.md new file mode 100644 index 00000000000..3bc498c505e --- /dev/null +++ b/docs/content/connectors/toolreference/pagerduty.de.md @@ -0,0 +1,43 @@ +--- +title: "PagerDuty" +description: "Einrichtung des PagerDuty Downstream-Connectors für DefectDojo" +weight: 102 +audience: pro +--- +Die PagerDuty-Integration ermöglicht es Ihnen, DefectDojo-Befunde und Befundgruppen als PagerDuty-Incidents zu übertragen, die auf einem PagerDuty-Service Ihrer Wahl eröffnet werden. + +### Instanz-Einrichtung + +- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf `https://api.pagerduty.com` gesetzt werden. Wird Ihr PagerDuty-Konto in der EU-Serviceregion gehostet, verwenden Sie stattdessen `https://api.eu.pagerduty.com`. +- **API Token** sollte auf einen PagerDuty-REST-API-Key gesetzt werden. Ein Kontoadministrator kann einen solchen in der PagerDuty-Web-App unter **Integrations > API Access Keys > Create New API Key** erstellen. Lassen Sie „Read-only“ deaktiviert - DefectDojo muss Incidents erstellen und aktualisieren. +- **From Email** sollte die E-Mail-Adresse eines gültigen Benutzers in Ihrem PagerDuty-Konto sein. PagerDuty verlangt diese Adresse beim Erstellen oder Aktualisieren von Incidents, und sie wird als Anforderer des Incidents angezeigt. + +### Issue-Tracker-Zuordnung + +- **Service ID** sollte die ID des PagerDuty-Services sein, auf dem Incidents eröffnet werden. Sie finden sie am Ende der URL, während Sie den Service in PagerDuty ansehen, zum Beispiel `https://{your-subdomain}.pagerduty.com/service-directory/{service id}`. + +### Details zur Schweregrad-Zuordnung + +Standardmäßig wird dies dem PagerDuty-Incident-Feld **Urgency** zugeordnet, das nur `high` oder `low` akzeptiert: + +- **Name des Schweregrad-Felds**: `Urgency` +- **Info-Zuordnung**: `low` +- **Niedrig-Zuordnung**: `low` +- **Mittel-Zuordnung**: `low` +- **Hoch-Zuordnung**: `high` +- **Kritisch-Zuordnung**: `high` + +Alternativ können Sie, wenn in Ihrem PagerDuty-Konto [Priorities](https://support.pagerduty.com/main/docs/incident-priority) aktiviert sind, Schweregrade stattdessen Prioritätsnamen zuordnen. Setzen Sie den **Namen des Schweregrad-Felds** auf `Priority` und verwenden Sie die Prioritätsnamen Ihres Kontos (zum Beispiel `P1` bis `P5`) als Zuordnungswerte. Bei einer Zuordnung auf Priority bleibt die Urgency des Incidents den Urgency-Regeln Ihres Services überlassen. + +### Details zur Status-Zuordnung + +PagerDuty-Incidents haben drei Status: `triggered`, `acknowledged` und `resolved`. + +- **Name des Status-Felds**: `Status` +- **Aktiv-Zuordnung**: `triggered` +- **Geschlossen-Zuordnung**: `resolved` +- **Falsch-positiv-Zuordnung**: `resolved` +- **Risiko-akzeptiert-Zuordnung**: `acknowledged` + +Beachten Sie, dass `resolved` in PagerDuty ein endgültiger Status ist - ein aufgelöster Incident kann nicht wieder geöffnet werden. Beachten Sie außerdem, dass PagerDuty es nicht erlaubt, Titel oder Beschreibung eines Incidents nach dem Erstellen zu bearbeiten; beim Übertragen eines aktualisierten Befunds werden daher Status, Urgency und Priority synchronisiert, Inhaltsänderungen jedoch nicht. diff --git a/docs/content/connectors/toolreference/pagerduty.es.md b/docs/content/connectors/toolreference/pagerduty.es.md new file mode 100644 index 00000000000..facc4389734 --- /dev/null +++ b/docs/content/connectors/toolreference/pagerduty.es.md @@ -0,0 +1,43 @@ +--- +title: "PagerDuty" +description: "Cómo configurar el Conector Downstream de PagerDuty para DefectDojo" +weight: 102 +audience: pro +--- +La integración de PagerDuty le permite enviar los Hallazgos y Grupos de Hallazgos de DefectDojo como incidentes de PagerDuty, abiertos en un servicio de PagerDuty de su elección. + +### Configuración de la instancia + +- **Label** debe ser la etiqueta que desea usar para identificar esta integración. +- **Location** debe establecerse en `https://api.pagerduty.com`. Si su cuenta de PagerDuty está alojada en la región de servicio de la UE, use `https://api.eu.pagerduty.com` en su lugar. +- **API Token** debe establecerse en una clave de la API REST de PagerDuty. Un administrador de la cuenta puede crear una en la aplicación web de PagerDuty en **Integrations > API Access Keys > Create New API Key**. Deje sin marcar "Read-only" - DefectDojo necesita crear y actualizar incidentes. +- **From Email** debe ser la dirección de correo electrónico de un usuario válido de su cuenta de PagerDuty. PagerDuty requiere esta dirección al crear o actualizar incidentes, y se mostrará como el solicitante del incidente. + +### Mapeo del Issue Tracker + +- **Service ID** debe ser el ID del servicio de PagerDuty en el que se abrirán los incidentes. Puede encontrarlo al final de la URL al ver el servicio en PagerDuty, por ejemplo `https://{your-subdomain}.pagerduty.com/service-directory/{service id}`. + +### Detalles del mapeo de severidad + +De forma predeterminada, esto se mapea al campo **Urgency** del incidente de PagerDuty, que solo acepta `high` o `low`: + +- **Severity Field Name**: `Urgency` +- **Info Mapping**: `low` +- **Low Mapping**: `low` +- **Medium Mapping**: `low` +- **High Mapping**: `high` +- **Critical Mapping**: `high` + +Alternativamente, si su cuenta de PagerDuty tiene habilitadas las [Priorities](https://support.pagerduty.com/main/docs/incident-priority), puede mapear las severidades a nombres de Priority en su lugar. Establezca **Severity Field Name** en `Priority` y use los nombres de Priority de su cuenta (por ejemplo `P1` a `P5`) como valores de mapeo. Al mapear a Priority, la Urgency del incidente queda a cargo de las propias reglas de urgencia de su servicio. + +### Detalles del mapeo de estado + +Los incidentes de PagerDuty tienen tres estados: `triggered`, `acknowledged` y `resolved`. + +- **Status Field Name**: `Status` +- **Active Mapping**: `triggered` +- **Closed Mapping**: `resolved` +- **False Positive Mapping**: `resolved` +- **Risk Accepted Mapping**: `acknowledged` + +Tenga en cuenta que `resolved` es un estado final en PagerDuty - un incidente resuelto no se puede reabrir. Tenga en cuenta también que PagerDuty no permite editar el título o la descripción de un incidente después de su creación, así que enviar un Hallazgo actualizado sincronizará su estado, urgencia y prioridad, pero no los cambios de contenido. diff --git a/docs/content/connectors/toolreference/pagerduty.fr.md b/docs/content/connectors/toolreference/pagerduty.fr.md new file mode 100644 index 00000000000..fa1b2386cd1 --- /dev/null +++ b/docs/content/connectors/toolreference/pagerduty.fr.md @@ -0,0 +1,43 @@ +--- +title: "PagerDuty" +description: "Comment configurer le Connecteur Downstream PagerDuty pour DefectDojo" +weight: 102 +audience: pro +--- +L'intégration PagerDuty vous permet de transmettre les Constatations et Groupes de constatations de DefectDojo sous forme d'incidents PagerDuty, ouverts sur un service PagerDuty de votre choix. + +### Configuration de l'instance + +- **Label** doit correspondre à l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur `https://api.pagerduty.com`. Si votre compte PagerDuty est hébergé dans la région de service UE, utilisez plutôt `https://api.eu.pagerduty.com`. +- **API Token** doit être défini sur une clé API REST PagerDuty. Un administrateur de compte peut en créer une dans l'application web PagerDuty, sous **Integrations > API Access Keys > Create New API Key**. Laissez « Read-only » décoché - DefectDojo doit pouvoir créer et mettre à jour des incidents. +- **From Email** doit correspondre à l'adresse e-mail d'un utilisateur valide de votre compte PagerDuty. PagerDuty exige cette adresse lors de la création ou de la mise à jour d'incidents, et elle sera affichée comme demandeur de l'incident. + +### Mappage du suivi des tickets + +- **Service ID** doit correspondre à l'ID du service PagerDuty sur lequel les incidents seront ouverts. Vous pouvez le trouver à la fin de l'URL lorsque vous consultez le service dans PagerDuty, par exemple `https://{your-subdomain}.pagerduty.com/service-directory/{service id}`. + +### Détails du mappage de la sévérité + +Par défaut, ceci correspond au champ **Urgency** des incidents PagerDuty, qui n'accepte que `high` ou `low` : + +- **Severity Field Name** : `Urgency` +- **Info Mapping** : `low` +- **Low Mapping** : `low` +- **Medium Mapping** : `low` +- **High Mapping** : `high` +- **Critical Mapping** : `high` + +Alternativement, si votre compte PagerDuty a activé les [Priorities](https://support.pagerduty.com/main/docs/incident-priority), vous pouvez mapper les sévérités aux noms de priorité à la place. Définissez le **Severity Field Name** sur `Priority` et utilisez les noms de priorité de votre compte (par exemple de `P1` à `P5`) comme valeurs de mappage. Lors du mappage vers Priority, l'urgence de l'incident est laissée aux propres règles d'urgence de votre service. + +### Détails du mappage du statut + +Les incidents PagerDuty ont trois statuts : `triggered`, `acknowledged` et `resolved`. + +- **Status Field Name** : `Status` +- **Active Mapping** : `triggered` +- **Closed Mapping** : `resolved` +- **False Positive Mapping** : `resolved` +- **Risk Accepted Mapping** : `acknowledged` + +Notez que `resolved` est un statut final dans PagerDuty - un incident résolu ne peut pas être rouvert. Notez également que PagerDuty ne permet pas de modifier le titre ou la description d'un incident après sa création ; ainsi, la transmission d'une Constatation mise à jour synchronisera son statut, son urgence et sa priorité, mais pas les modifications de contenu. diff --git a/docs/content/connectors/toolreference/pagerduty.ja.md b/docs/content/connectors/toolreference/pagerduty.ja.md new file mode 100644 index 00000000000..d6d2372a89d --- /dev/null +++ b/docs/content/connectors/toolreference/pagerduty.ja.md @@ -0,0 +1,43 @@ +--- +title: "PagerDuty" +description: "DefectDojo で PagerDuty のダウンストリームコネクタをセットアップする方法" +weight: 102 +audience: pro +--- +PagerDuty 統合を使うと、DefectDojo の Finding および Finding Group を、選択した PagerDuty の Service 上で開かれる PagerDuty のインシデントとしてプッシュできます。 + +### Instance Setup + +- **Label** は、この統合を識別するために使用したいラベルを設定します。 +- **Location** は、`https://api.pagerduty.com` を設定します。PagerDuty アカウントが EU サービスリージョンでホストされている場合は、代わりに `https://api.eu.pagerduty.com` を使用してください。 +- **API Token** は、PagerDuty の REST API キーを設定します。アカウント管理者は、PagerDuty の Web アプリの **Integrations > API Access Keys > Create New API Key** から作成できます。「Read-only」はチェックしないでください。DefectDojo はインシデントの作成・更新を行う必要があります。 +- **From Email** は、PagerDuty アカウント上の有効なユーザーのメールアドレスを設定します。PagerDuty はインシデントの作成・更新時にこのアドレスを必要とし、インシデントのリクエスターとして表示されます。 + +### Issue Tracker Mapping + +- **Service ID** は、インシデントを開く PagerDuty の Service の ID を設定します。PagerDuty で該当の Service を表示中の URL の末尾から取得できます。例: `https://{your-subdomain}.pagerduty.com/service-directory/{service id}` + +### Severity Mapping Details + +デフォルトでは、`high` または `low` のみを受け付ける PagerDuty のインシデント **Urgency** フィールドにマッピングされます。 + +- **Severity Field Name**: `Urgency` +- **Info Mapping**: `low` +- **Low Mapping**: `low` +- **Medium Mapping**: `low` +- **High Mapping**: `high` +- **Critical Mapping**: `high` + +代わりに、PagerDuty アカウントで[Priorities](https://support.pagerduty.com/main/docs/incident-priority)が有効になっている場合は、深刻度を Priority 名にマッピングすることもできます。その場合は **Severity Field Name** を `Priority` に設定し、マッピング値としてアカウントの Priority 名（例えば `P1` から `P5` まで）を使用します。Priority にマッピングする場合、インシデントの Urgency は Service 自体の urgency ルールに委ねられます。 + +### Status Mapping Details + +PagerDuty のインシデントには、`triggered`、`acknowledged`、`resolved` という3つのステータスがあります。 + +- **Status Field Name**: `Status` +- **Active Mapping**: `triggered` +- **Closed Mapping**: `resolved` +- **False Positive Mapping**: `resolved` +- **Risk Accepted Mapping**: `acknowledged` + +なお、`resolved` は PagerDuty における最終ステータスであり、resolved のインシデントは再オープンできません。また、PagerDuty はインシデントの作成後にタイトルや説明を編集することを許可していないため、更新された Finding をプッシュすると、ステータス、urgency、priority は同期されますが、コンテンツの変更は同期されません。 diff --git a/docs/content/connectors/toolreference/pagerduty.md b/docs/content/connectors/toolreference/pagerduty.md new file mode 100644 index 00000000000..df9dfeae1b2 --- /dev/null +++ b/docs/content/connectors/toolreference/pagerduty.md @@ -0,0 +1,43 @@ +--- +title: "PagerDuty" +description: "How to set up the PagerDuty Downstream Connector for DefectDojo" +weight: 102 +audience: pro +--- +The PagerDuty Integration allows you to push DefectDojo Findings and Finding Groups as PagerDuty Incidents, opened on a PagerDuty Service of your choice. + +### Instance Setup + +- **Label** should be the label that you want to use to identify this integration. +- **Location** should be set to `https://api.pagerduty.com`. If your PagerDuty account is hosted in the EU service region, use `https://api.eu.pagerduty.com` instead. +- **API Token** should be set to a PagerDuty REST API key. An account administrator can create one in the PagerDuty web app under **Integrations > API Access Keys > Create New API Key**. Leave "Read-only" unchecked - DefectDojo needs to create and update incidents. +- **From Email** should be the email address of a valid user on your PagerDuty account. PagerDuty requires this address when creating or updating incidents, and it will be shown as the incident requester. + +### Issue Tracker Mapping + +- **Service ID** should be the ID of the PagerDuty Service that incidents will be opened on. You can find it at the end of the URL while looking at the Service in PagerDuty, for example `https://{your-subdomain}.pagerduty.com/service-directory/{service id}`. + +### Severity Mapping Details + +By default this maps to the PagerDuty incident **Urgency** field, which only accepts `high` or `low`: + +- **Severity Field Name**: `Urgency` +- **Info Mapping**: `low` +- **Low Mapping**: `low` +- **Medium Mapping**: `low` +- **High Mapping**: `high` +- **Critical Mapping**: `high` + +Alternatively, if your PagerDuty account has [Priorities](https://support.pagerduty.com/main/docs/incident-priority) enabled, you can map severities to Priority names instead. Set the **Severity Field Name** to `Priority` and use your account's Priority names (for example `P1` through `P5`) as the mapping values. When mapping to Priority, the incident's Urgency is left to your Service's own urgency rules. + +### Status Mapping Details + +PagerDuty incidents have three statuses: `triggered`, `acknowledged`, and `resolved`. + +- **Status Field Name**: `Status` +- **Active Mapping**: `triggered` +- **Closed Mapping**: `resolved` +- **False Positive Mapping**: `resolved` +- **Risk Accepted Mapping**: `acknowledged` + +Note that `resolved` is a final status in PagerDuty - a resolved incident cannot be reopened. Also note that PagerDuty does not allow an incident's title or description to be edited after creation, so pushing an updated Finding will sync its status, urgency, and priority, but not content changes. diff --git a/docs/content/connectors/toolreference/parasoft_dtp.md b/docs/content/connectors/toolreference/parasoft_dtp.md new file mode 100644 index 00000000000..e8d32d25692 --- /dev/null +++ b/docs/content/connectors/toolreference/parasoft_dtp.md @@ -0,0 +1,20 @@ +--- +title: "Parasoft DTP" +description: "How to set up the Parasoft DTP Upstream Connector for DefectDojo" +weight: 103 +audience: pro +--- +The Parasoft DTP connector imports **static analysis violations** from a Parasoft DTP server. DefectDojo creates a Record for each DTP **report filter**. + +#### Prerequisites + +A Parasoft DTP **username and password**, used over HTTP Basic authentication. The password is never logged. + +#### Connector Mappings + +1. Enter your Parasoft DTP server URL in the **Location** field, including its port if it uses a non\-standard one. +2. Enter the DTP username in the **Username** field. +3. Enter the password in the **Password** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each report filter becomes a Record, carrying that filter's static analysis violations **from the latest build** — so findings describe the current state of the code rather than accumulating across builds. diff --git a/docs/content/connectors/toolreference/picus_security.md b/docs/content/connectors/toolreference/picus_security.md new file mode 100644 index 00000000000..a2f27243583 --- /dev/null +++ b/docs/content/connectors/toolreference/picus_security.md @@ -0,0 +1,23 @@ +--- +title: "Picus Security" +description: "How to set up the Picus Security Upstream Connector for DefectDojo" +weight: 104 +audience: pro +--- +The Picus Security connector imports **breach and attack simulation (BAS) results** from the Picus platform — whether your existing security controls prevented, logged and alerted on each simulated attack. DefectDojo creates a Record for each **agent group**, so one Record represents one environment under test. + +#### Prerequisites + +You need a Picus **REST API refresh token**, generated by hand at **app.picussecurity.com \> Settings \> Rest API Token**. It is valid for **six months**, and DefectDojo exchanges it for short\-lived access tokens automatically. + +> **Paste the refresh token, not an access token.** Picus also issues a two\-hour **access token** from the same area. An access token pasted into the connector will authenticate at first and then stop working the same afternoon. The connector needs the six\-month refresh token. + +Because the refresh token expires after six months, plan to rotate it — the connector cannot renew it for you. + +#### Connector Mappings + +1. Enter `https://api.picussecurity.com` in the **Location** field. +2. Enter the six\-month REST API refresh token in the **Refresh Token** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each agent group becomes a Record, and its findings come from the **most recent run of every simulation** bound to that group. diff --git a/docs/content/connectors/toolreference/pingcastle.md b/docs/content/connectors/toolreference/pingcastle.md new file mode 100644 index 00000000000..c2eb89be570 --- /dev/null +++ b/docs/content/connectors/toolreference/pingcastle.md @@ -0,0 +1,21 @@ +--- +title: "PingCastle" +description: "How to set up the PingCastle Upstream Connector for DefectDojo" +weight: 105 +audience: pro +--- +The PingCastle connector imports **Active Directory security posture findings** from a PingCastle Enterprise reporting server. DefectDojo creates a Record for each **Active Directory domain** the reporting server monitors, and that domain's **latest HealthCheck report** supplies its findings. + +This is a different category from most connectors in this list — identity and Active Directory posture, rather than application, cloud or container scanning. + +#### Prerequisites + +The PingCastle Enterprise **API key** — the same key your PingCastle agents use when they submit reports (the `--api-key` value passed alongside `--api-endpoint`). It is sent as the `X-API-Key` header. + +#### Connector Mappings + +1. Enter your **PingCastle Enterprise reporting server** URL in the **Location** field — the same address your agents submit to via `--api-endpoint`. +2. Enter the PingCastle Enterprise API key in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each monitored domain becomes a Record. DefectDojo reads the same HealthCheck risk rules that the file-based PingCastle parser reads from a local XML export, so findings are consistent whichever route you use. diff --git a/docs/content/connectors/toolreference/probely.de.md b/docs/content/connectors/toolreference/probely.de.md new file mode 100644 index 00000000000..fc63b29495e --- /dev/null +++ b/docs/content/connectors/toolreference/probely.de.md @@ -0,0 +1,15 @@ +--- +title: "Probely" +description: "Einrichtung des Probely Upstream-Connectors für DefectDojo" +weight: 106 +audience: pro +--- +Dieser Connector verwendet die Probely-REST-API, um Daten abzurufen. + +​**Connector-Zuordnungen** + +1. Geben Sie die passende API-Server-Adresse in das Feld **Location** ein. (entweder oder ) +2. Geben Sie einen gültigen API-Schlüssel in das Feld **Secret** ein. + +Einen API-Schlüssel finden Sie in Probely unter dem Menü User \> API Keys. +Weitere Informationen finden Sie in der [Probely-Dokumentation](https://help.probely.com/en/articles/8592281-how-to-generate-an-api-key). diff --git a/docs/content/connectors/toolreference/probely.es.md b/docs/content/connectors/toolreference/probely.es.md new file mode 100644 index 00000000000..d5ea5246eda --- /dev/null +++ b/docs/content/connectors/toolreference/probely.es.md @@ -0,0 +1,15 @@ +--- +title: "Probely" +description: "Cómo configurar el Conector Upstream de Probely para DefectDojo" +weight: 106 +audience: pro +--- +Este conector usa la API REST de Probely para obtener datos. + +​**Asignaciones del conector** + +1. Ingrese la dirección del servidor de API correspondiente en el campo **Location**. (ya sea o ) +2. Ingrese una API key válida en el campo **Secret**. + +Puede encontrar una API key en el menú User > API Keys de Probely. +Consulte la [documentación de Probely](https://help.probely.com/en/articles/8592281-how-to-generate-an-api-key) para más información. diff --git a/docs/content/connectors/toolreference/probely.fr.md b/docs/content/connectors/toolreference/probely.fr.md new file mode 100644 index 00000000000..3ddd2b45aa1 --- /dev/null +++ b/docs/content/connectors/toolreference/probely.fr.md @@ -0,0 +1,15 @@ +--- +title: "Probely" +description: "Comment configurer le Connecteur Upstream Probely pour DefectDojo" +weight: 106 +audience: pro +--- +Ce connecteur utilise l'API REST de Probely pour récupérer les données. + +​**Correspondances du connecteur** + +1. Saisissez l'adresse du serveur API appropriée dans le champ **Location**. (soit soit ) +2. Saisissez une clé API valide dans le champ **Secret**. + +Vous pouvez trouver une clé API sous le menu User \> API Keys dans Probely. +Consultez la [documentation Probely](https://help.probely.com/en/articles/8592281-how-to-generate-an-api-key) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/probely.ja.md b/docs/content/connectors/toolreference/probely.ja.md new file mode 100644 index 00000000000..06246f29579 --- /dev/null +++ b/docs/content/connectors/toolreference/probely.ja.md @@ -0,0 +1,15 @@ +--- +title: "Probely" +description: "DefectDojo で Probely の Upstream Connector をセットアップする方法" +weight: 106 +audience: pro +--- +このコネクタは、Probely REST APIを使用してデータを取得します。 + +​**Connector Mappings** + +1. **Location** フィールドに適切なAPIサーバーアドレスを入力します。( または のいずれか) +2. **Secret** フィールドに有効なAPIキーを入力します。 + +APIキーは、ProbelyのUser > API Keysメニューから確認できます。 +詳細については[Probelyのドキュメント](https://help.probely.com/en/articles/8592281-how-to-generate-an-api-key)を参照してください。 diff --git a/docs/content/connectors/toolreference/probely.md b/docs/content/connectors/toolreference/probely.md new file mode 100644 index 00000000000..1cceae9edbe --- /dev/null +++ b/docs/content/connectors/toolreference/probely.md @@ -0,0 +1,15 @@ +--- +title: "Probely" +description: "How to set up the Probely Upstream Connector for DefectDojo" +weight: 106 +audience: pro +--- +This connector uses the Probely REST API to fetch data. + +​**Connector Mappings** + +1. Enter the appropriate API server address in the **Location** field. (either or ) +2. Enter a valid API key in the **Secret** field. + +You can find an API key under the User \> API Keys menu in Probely. +See [Probely documentation](https://help.probely.com/en/articles/8592281-how-to-generate-an-api-key) for more info. diff --git a/docs/content/connectors/toolreference/promptfoo.md b/docs/content/connectors/toolreference/promptfoo.md new file mode 100644 index 00000000000..df4c068002e --- /dev/null +++ b/docs/content/connectors/toolreference/promptfoo.md @@ -0,0 +1,19 @@ +--- +title: "Promptfoo" +description: "How to set up the Promptfoo Upstream Connector for DefectDojo" +weight: 107 +audience: pro +--- +The Promptfoo connector imports **LLM red-teaming and evaluation findings** from Promptfoo Cloud. DefectDojo creates a Record for each **target application** (provider) that Promptfoo probed. + +#### Prerequisites + +A Promptfoo Cloud **API token**, sent as a bearer token and never logged. + +#### Connector Mappings + +1. Enter `https://api.promptfoo.app` in the **Location** field. +2. Enter your Promptfoo API token in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo reads every stored evaluation the token can see and works out which targets were probed. A target's findings are its **failing** probes across all evaluations, aggregated **per weakness** rather than one finding per probe run — so repeated evaluations of the same weakness stay a single finding. diff --git a/docs/content/connectors/toolreference/prowler.de.md b/docs/content/connectors/toolreference/prowler.de.md new file mode 100644 index 00000000000..680dda3841b --- /dev/null +++ b/docs/content/connectors/toolreference/prowler.de.md @@ -0,0 +1,21 @@ +--- +title: "Prowler" +description: "Einrichtung des Prowler Upstream-Connectors für DefectDojo" +weight: 108 +audience: pro +--- +Der Prowler-Connector verwendet die **Prowler-App**-REST-API, um Cloud-Security-Posture(CSPM)-Befunde von einer selbstgehosteten Prowler-App-Instanz zu importieren. DefectDojo ermittelt jeden Prowler-**Provider** (Cloud-Konto) als Eintrag und importiert die **FAIL**-Befunde des letzten abgeschlossenen Scans dieses Providers. + +#### Voraussetzungen + +Sie benötigen eine laufende, selbstgehostete **Prowler-App**-Instanz sowie entweder eine Benutzer-E-Mail-Adresse + ein Passwort (für JWT-Authentifizierung) oder einen Prowler-App-**API-Schlüssel**. Befunde erscheinen erst, sobald Sie ein Cloud-Konto (AWS, GCP, Azure, Kubernetes, ...) in der Prowler-App verbunden und einen Scan ausgeführt haben. + +#### Connector-Zuordnungen + +1. Geben Sie Ihre Prowler-App-URL in das Feld **Location** ein (zum Beispiel `https://prowler.your-company.com`). +2. Geben Sie für die JWT-Authentifizierung die **Email** und das **Password** des Prowler-App-Benutzers ein. Alternativ lassen Sie diese leer und geben einen Prowler-App-**API-Schlüssel** ein. Sind beide angegeben, wird E-Mail/Passwort (JWT) verwendet. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. + +DefectDojo erstellt für jeden Prowler-Provider einen Eintrag und importiert die FAIL-Befunde von dessen letztem abgeschlossenem Scan, wobei Prowler-Schweregrade auf DefectDojo-Schweregrade abgebildet werden, die betroffene Cloud-Ressource (ARN/Ressourcen-ID) zur Komponente wird und die Abhilfemaßnahme sowie das Risiko der Prüfung in den Befund übernommen werden. Stummgeschaltete Befunde werden übersprungen. Cloud-Konto, Region und Dienst werden als Tags angehängt. + +Weitere Informationen finden Sie in der **[Prowler-App-API-Dokumentation](https://api.prowler.com/api/v1/docs)**. diff --git a/docs/content/connectors/toolreference/prowler.es.md b/docs/content/connectors/toolreference/prowler.es.md new file mode 100644 index 00000000000..fa56f788699 --- /dev/null +++ b/docs/content/connectors/toolreference/prowler.es.md @@ -0,0 +1,21 @@ +--- +title: "Prowler" +description: "Cómo configurar el Conector Upstream de Prowler para DefectDojo" +weight: 108 +audience: pro +--- +El conector de Prowler usa la API REST de **Prowler App** para importar hallazgos de postura de seguridad en la nube (CSPM) desde una instancia de Prowler App autoalojada. DefectDojo descubre cada **provider** (cuenta en la nube) de Prowler como un Record e importa los hallazgos **FAIL** del escaneo completado más reciente de ese provider. + +#### Requisitos previos + +Necesitará una instancia de **Prowler App** autoalojada en ejecución, y ya sea un correo electrónico y contraseña de usuario (para autenticación JWT) o una **API key** de Prowler App. Los hallazgos solo aparecen una vez que haya conectado una cuenta en la nube (AWS, GCP, Azure, Kubernetes, ...) en Prowler App y ejecutado un escaneo. + +#### Asignaciones del conector + +1. Ingrese la URL de Prowler App en el campo **Location** (por ejemplo, `https://prowler.your-company.com`). +2. Para autenticación JWT, ingrese el **Email** y **Password** del usuario de Prowler App. Alternativamente, deje esos campos en blanco e ingrese una **API Key** de Prowler App. Si se proporcionan ambos, se usa el email/password (JWT). +3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importan. + +DefectDojo crea un Record para cada provider de Prowler e importa los hallazgos FAIL de su escaneo completado más reciente, asignando las severidades de Prowler a las severidades de DefectDojo, el recurso en la nube afectado (ARN/resource id) como componente, y la remediación y el riesgo del check al hallazgo. Los hallazgos silenciados (muted) se omiten. La cuenta en la nube, la región y el servicio se adjuntan como etiquetas (tags). + +Para más información, consulte la **[documentación de la API de Prowler App](https://api.prowler.com/api/v1/docs)**. diff --git a/docs/content/connectors/toolreference/prowler.fr.md b/docs/content/connectors/toolreference/prowler.fr.md new file mode 100644 index 00000000000..25d5f0220f4 --- /dev/null +++ b/docs/content/connectors/toolreference/prowler.fr.md @@ -0,0 +1,21 @@ +--- +title: "Prowler" +description: "Comment configurer le Connecteur Upstream Prowler pour DefectDojo" +weight: 108 +audience: pro +--- +Le connecteur Prowler utilise l'API REST **Prowler App** pour importer les constatations de posture de sécurité cloud (CSPM) depuis une instance Prowler App auto\-hébergée. DefectDojo découvre chaque **provider** (compte cloud) Prowler comme un Record et importe les constatations **FAIL** du dernier scan terminé de ce provider. + +#### Prérequis + +Vous aurez besoin d'une instance **Prowler App** auto\-hébergée en cours d'exécution, et soit d'un e\-mail + mot de passe utilisateur (pour l'authentification JWT), soit d'une **clé API** Prowler App. Les constatations n'apparaissent qu'une fois qu'un compte cloud (AWS, GCP, Azure, Kubernetes, ...) a été connecté dans Prowler App et qu'un scan a été exécuté. + +#### Correspondances du connecteur + +1. Saisissez l'URL de votre Prowler App dans le champ **Location** (par exemple `https://prowler.your-company.com`). +2. Pour l'authentification JWT, saisissez l'**Email** et le **Password** de l'utilisateur Prowler App. Vous pouvez également laisser ces champs vides et saisir une **API Key** Prowler App. Si les deux sont fournis, l'e\-mail/mot de passe (JWT) est utilisé. +3. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. Les constatations en dessous de la sévérité sélectionnée ne sont pas importées. + +DefectDojo crée un Record pour chaque provider Prowler et importe les constatations FAIL de son dernier scan terminé, en associant les sévérités Prowler aux sévérités DefectDojo, la ressource cloud concernée (ARN/resource id) comme composant, et la remédiation et le risque du contrôle dans la constatation. Les constatations mises en sourdine (muted) sont ignorées. Le compte cloud, la région et le service sont attachés en tant qu'étiquettes. + +Pour plus d'informations, consultez la **[documentation de l'API Prowler App](https://api.prowler.com/api/v1/docs)**. diff --git a/docs/content/connectors/toolreference/prowler.ja.md b/docs/content/connectors/toolreference/prowler.ja.md new file mode 100644 index 00000000000..392acac7911 --- /dev/null +++ b/docs/content/connectors/toolreference/prowler.ja.md @@ -0,0 +1,21 @@ +--- +title: "Prowler" +description: "DefectDojo で Prowler の Upstream Connector をセットアップする方法" +weight: 108 +audience: pro +--- +Prowlerコネクタは**Prowler App** REST APIを使用して、セルフホスト型のProwler Appインスタンスからクラウドセキュリティポスチャ (CSPM) の検出事項をインポートします。DefectDojoは各Prowler**プロバイダ**(クラウドアカウント)をRecordとして検出し、そのプロバイダの最新の完了済みスキャンの**FAIL**検出事項をインポートします。 + +#### 前提条件 + +実行中のセルフホスト型**Prowler App**インスタンスと、ユーザーのメールアドレス+パスワード(JWT認証用)またはProwler Appの**APIキー**のいずれかが必要です。検出事項は、Prowler Appでクラウドアカウント(AWS、GCP、Azure、Kubernetesなど)を接続してスキャンを実行して初めて表示されます。 + +#### Connector Mappings + +1. **Location** フィールドにProwler AppのURLを入力します(例: `https://prowler.your-company.com`)。 +2. JWT認証の場合は、Prowler Appユーザーの **Email** と **Password** を入力します。あるいは、それらを空欄のままにして、Prowler Appの **API Key** を入力します。両方が指定された場合は、メール/パスワード(JWT)が使用されます。 +3. 必要に応じて **Minimum Severity** を設定し、インポートする検出事項を絞り込みます。選択した深刻度未満の検出事項はインポートされません。 + +DefectDojoは各ProwlerプロバイダについてRecordを作成し、その最新の完了済みスキャンのFAIL検出事項をインポートします。その際、Prowlerの深刻度をDefectDojoの深刻度にマッピングし、影響を受けるクラウドリソース(ARN/リソースID)をコンポーネントとして、チェックの修復方法とリスクを検出事項に反映します。ミュートされた検出事項はスキップされます。クラウドアカウント、リージョン、サービスはタグとして付与されます。 + +詳細については、**[Prowler App APIドキュメント](https://api.prowler.com/api/v1/docs)**を参照してください。 diff --git a/docs/content/connectors/toolreference/prowler.md b/docs/content/connectors/toolreference/prowler.md new file mode 100644 index 00000000000..2cb6ceee74f --- /dev/null +++ b/docs/content/connectors/toolreference/prowler.md @@ -0,0 +1,21 @@ +--- +title: "Prowler" +description: "How to set up the Prowler Upstream Connector for DefectDojo" +weight: 108 +audience: pro +--- +The Prowler connector uses the **Prowler App** REST API to import cloud security posture (CSPM) findings from a self-hosted Prowler App instance. DefectDojo discovers each Prowler **provider** (cloud account) as a Record and imports the **FAIL** findings of that provider's latest completed scan. + +#### Prerequisites + +You will need a running, self-hosted **Prowler App** instance and either a user email + password (for JWT authentication) or a Prowler App **API key**. Findings only appear once you have connected a cloud account (AWS, GCP, Azure, Kubernetes, ...) in Prowler App and run a scan. + +#### Connector Mappings + +1. Enter your Prowler App URL in the **Location** field (for example `https://prowler.your-company.com`). +2. For JWT authentication, enter the Prowler App user **Email** and **Password**. Alternatively, leave those blank and enter a Prowler App **API Key**. If both are provided, the email/password (JWT) is used. +3. Optionally set a **Minimum Severity** to limit which findings are imported. Findings below the selected severity are not imported. + +DefectDojo creates a Record for each Prowler provider and imports the FAIL findings of its latest completed scan, mapping Prowler severities to DefectDojo severities, the affected cloud resource (ARN/resource id) as the component, and the check's remediation and risk into the finding. Muted findings are skipped. Cloud account, region, and service are attached as tags. + +For more information, see the **[Prowler App API documentation](https://api.prowler.com/api/v1/docs)**. diff --git a/docs/content/connectors/toolreference/qualys.de.md b/docs/content/connectors/toolreference/qualys.de.md new file mode 100644 index 00000000000..2d945f6d3df --- /dev/null +++ b/docs/content/connectors/toolreference/qualys.de.md @@ -0,0 +1,20 @@ +--- +title: "Qualys" +description: "Einrichtung des Qualys Upstream-Connectors für DefectDojo" +weight: 109 +audience: pro +--- +Der Qualys-Connector importiert **VMDR-Host-Schwachstellendetektionen** — jeweils verknüpft mit den Metadaten der Qualys-KnowledgeBase (QID) — von der Qualys Cloud Platform. DefectDojo erstellt für jeden Qualys-**Host** in Ihrer Subscription einen Eintrag. + +#### Voraussetzungen + +Ein Qualys-Benutzerkonto mit **VMDR-API-Zugriff** sowie die **API-Server(Platform)-URL** Ihrer Subscription — diese unterscheidet sich je nach Subscription. Sie finden sie in der Qualys-Oberfläche unter **Help \> About** oder auf der Qualys-Seite [Platform Identification](https://www.qualys.com/platform-identification/) (zum Beispiel `https://qualysapi.qualys.com` für US Platform 1, oder `https://qualysapi.qg2.apps.qualys.com` für US Platform 2). + +#### Connector-Zuordnungen + +1. Geben Sie Ihre Qualys-API-Server-URL in das Feld **Location** ein (zum Beispiel `https://qualysapi.qualys.com`). +2. Geben Sie den Qualys-API-Benutzernamen in das Feld **Username** ein. +3. Geben Sie das Qualys-API-Passwort in das Feld **Secret** ein. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jeder Qualys-Host wird zu einem Eintrag. Detektionen, die Qualys als **Fixed** markiert hat, werden ausgeschlossen, sodass ein erneuter Import behobene Befunde schließt. diff --git a/docs/content/connectors/toolreference/qualys.es.md b/docs/content/connectors/toolreference/qualys.es.md new file mode 100644 index 00000000000..8d42a60dcdc --- /dev/null +++ b/docs/content/connectors/toolreference/qualys.es.md @@ -0,0 +1,20 @@ +--- +title: "Qualys" +description: "Cómo configurar el Conector Upstream de Qualys para DefectDojo" +weight: 109 +audience: pro +--- +El conector de Qualys importa **detecciones de vulnerabilidades de hosts de VMDR** —cada una combinada con sus metadatos de Qualys KnowledgeBase (QID)— desde Qualys Cloud Platform. DefectDojo crea un Record para cada **host** de Qualys en su suscripción. + +#### Requisitos previos + +Una cuenta de usuario de Qualys con **acceso a la API de VMDR**, y la **URL del servidor de API (platform)** de su suscripción, que difiere según la suscripción. Encuéntrela en la interfaz de Qualys, en **Help > About**, o en la página de [Platform Identification](https://www.qualys.com/platform-identification/) de Qualys (por ejemplo, `https://qualysapi.qualys.com` para US Platform 1, o `https://qualysapi.qg2.apps.qualys.com` para US Platform 2). + +#### Asignaciones del conector + +1. Ingrese la URL del servidor de API de Qualys en el campo **Location** (por ejemplo, `https://qualysapi.qualys.com`). +2. Ingrese el nombre de usuario de la API de Qualys en el campo **Username**. +3. Ingrese la contraseña de la API de Qualys en el campo **Secret**. +4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada host de Qualys se convierte en un Record. Las detecciones que Qualys ha marcado como **Fixed** se excluyen, por lo que reimportar cierra los hallazgos remediados. diff --git a/docs/content/connectors/toolreference/qualys.fr.md b/docs/content/connectors/toolreference/qualys.fr.md new file mode 100644 index 00000000000..21cdea22f48 --- /dev/null +++ b/docs/content/connectors/toolreference/qualys.fr.md @@ -0,0 +1,20 @@ +--- +title: "Qualys" +description: "Comment configurer le Connecteur Upstream Qualys pour DefectDojo" +weight: 109 +audience: pro +--- +Le connecteur Qualys importe les **détections de vulnérabilités hôtes VMDR** — chacune jointe aux métadonnées de la base de connaissances Qualys (QID) — depuis la Qualys Cloud Platform. DefectDojo crée un Record pour chaque **hôte** Qualys de votre abonnement. + +#### Prérequis + +Un compte utilisateur Qualys avec **accès API VMDR**, et l'**URL du serveur API (platform)** de votre abonnement — celle\-ci diffère selon l'abonnement. Trouvez\-la dans l'interface Qualys sous **Help \> About**, ou sur la page [Platform Identification](https://www.qualys.com/platform-identification/) de Qualys (par exemple `https://qualysapi.qualys.com` pour US Platform 1, ou `https://qualysapi.qg2.apps.qualys.com` pour US Platform 2). + +#### Correspondances du connecteur + +1. Saisissez l'URL de votre serveur API Qualys dans le champ **Location** (par exemple `https://qualysapi.qualys.com`). +2. Saisissez le nom d'utilisateur API Qualys dans le champ **Username**. +3. Saisissez le mot de passe API Qualys dans le champ **Secret**. +4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque hôte Qualys devient un Record. Les détections que Qualys a marquées **Fixed** sont exclues, de sorte qu'une réimportation clôt les constatations corrigées. diff --git a/docs/content/connectors/toolreference/qualys.ja.md b/docs/content/connectors/toolreference/qualys.ja.md new file mode 100644 index 00000000000..b9fa2d89016 --- /dev/null +++ b/docs/content/connectors/toolreference/qualys.ja.md @@ -0,0 +1,20 @@ +--- +title: "Qualys" +description: "DefectDojo で Qualys の Upstream Connector をセットアップする方法" +weight: 109 +audience: pro +--- +Qualysコネクタは、Qualys Cloud Platformから**VMDRホストの脆弱性検出結果**をインポートします。これは、それぞれQualysのKnowledgeBase (QID) メタデータと結合されています。DefectDojoは、お使いのサブスクリプション内の各Qualys**ホスト**についてRecordを作成します。 + +#### 前提条件 + +**VMDR APIアクセス**を持つQualysユーザーアカウントと、サブスクリプションの**APIサーバー(プラットフォーム)URL**が必要です — これはサブスクリプションごとに異なります。Qualys UIの **Help > About** の下、またはQualysの[Platform Identification](https://www.qualys.com/platform-identification/)ページで確認できます(例: US Platform 1の場合は `https://qualysapi.qualys.com`、US Platform 2の場合は `https://qualysapi.qg2.apps.qualys.com`)。 + +#### Connector Mappings + +1. **Location** フィールドにQualysのAPIサーバーURLを入力します(例: `https://qualysapi.qualys.com`)。 +2. **Username** フィールドにQualys APIのユーザー名を入力します。 +3. **Secret** フィールドにQualys APIのパスワードを入力します。 +4. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 + +各Qualysホストが1件のRecordになります。Qualysが**Fixed**とマークした検出結果は除外されるため、再インポートによって修復済みの検出事項がクローズされます。 diff --git a/docs/content/connectors/toolreference/qualys.md b/docs/content/connectors/toolreference/qualys.md new file mode 100644 index 00000000000..3728165269b --- /dev/null +++ b/docs/content/connectors/toolreference/qualys.md @@ -0,0 +1,50 @@ +--- +title: "Qualys" +description: "How to set up the Qualys Upstream Connector for DefectDojo" +weight: 109 +audience: pro +--- +The Qualys connector imports **VMDR host vulnerability detections** — each joined with its Qualys KnowledgeBase (QID) metadata — from the Qualys Cloud Platform. DefectDojo creates a Record for each Qualys **host** in your subscription. + +#### Prerequisites + +A Qualys user account with **VMDR API access**, and your subscription's **API server (platform) URL** — this differs per subscription. Find it in the Qualys UI under **Help \> About**, or on the Qualys [Platform Identification](https://www.qualys.com/platform-identification/) page (for example `https://qualysapi.qualys.com` for US Platform 1, or `https://qualysapi.qg2.apps.qualys.com` for US Platform 2). + +#### Connector Mappings + +1. Enter your Qualys API server URL in the **Location** field (for example `https://qualysapi.qualys.com`). +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. + +Each Qualys host becomes a Record. Detections Qualys has marked **Fixed** are excluded, so reimport closes remediated findings. + +#### Host Tags (optional) + +By default the connector discovers **every** host in your Qualys subscription. On a large estate that produces a Record list far bigger than most teams want. It also makes every Sync download the detections of every host. + +The optional **Host Tags** field, under **Import Filters** on the connector form, restricts the connector to hosts carrying the Qualys asset tags you name. The restriction travels to Qualys as part of the request, so out-of-scope hosts are never returned. It applies to **both** the host listing and the detection download. Narrowing the scope therefore cuts Sync time and transfer volume, not just the length of the Record list. + +**Syntax:** a comma-separated list of Qualys asset tag **names**, exactly as they appear in the Qualys UI under **Asset Management \> Tags**. + +``` +Prod, Business Unit: Finance +``` + +The example above discovers every host tagged `Prod` plus every host tagged `Business Unit: Finance`. + +Notes: + +* Tag names are matched **exactly**, and **wildcards are not supported**. Qualys offers no pattern matching on tag names, so `Prod-*` matches a tag literally named `Prod-*` and nothing else. This differs from the JFrog Xray **Repository Filter** described above, which does accept `*`. +* A host is discovered if it carries **any** tag in the list, not all of them. +* Spaces **around** the commas are ignored. Spaces **inside** a tag name are kept, so `Business Unit: Finance` works as written. +* A tag name that itself contains a comma cannot be used here, because the comma separates entries. +* The filter is an **allow-list**. There is no exclusion or negation syntax, so you cannot express "everything except X". +* **Leave it blank to discover every host.** A value that is only spaces or commas is treated as blank. +* If the tag names match no host, nothing is discovered. Check the spelling against the Qualys UI, and check the visible-host count reported on the connection. +* The field can be changed after the connection is created. + +**Testing the connection** ignores this field on purpose, so it still confirms your username and password even when the tag names are wrong. + +**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/connectors/toolreference/quay.de.md b/docs/content/connectors/toolreference/quay.de.md new file mode 100644 index 00000000000..ec6ac591c54 --- /dev/null +++ b/docs/content/connectors/toolreference/quay.de.md @@ -0,0 +1,25 @@ +--- +title: "Quay" +description: "Einrichtung des Quay Upstream-Connectors für DefectDojo" +weight: 110 +audience: pro +--- +Der Quay-Connector verwendet die Project-Quay-REST-API, um Container-Repositories zu ermitteln und die von Quays integriertem **Clair**-Scanner erzeugten Schwachstellenberichte zu importieren. DefectDojo erstellt für jedes Quay-**Repository** einen Eintrag und liest bei jedem Sync den Clair-Sicherheitsbericht des Image-Manifests jedes aktiven Tags. + +#### Voraussetzungen + +Security Scanning (Clair) muss auf Ihrer Quay-Instanz aktiviert sein, und Sie benötigen ein Quay-**OAuth-2-Zugriffstoken**: + +* Erstellen (oder öffnen) Sie in Quay eine Organisation, gehen Sie zu **Applications**, erstellen Sie eine OAuth-Anwendung, und dann **Generate Token** mit mindestens dem Scope **Read repositories**. Eine dedizierte Anwendung für DefectDojo wird empfohlen. +* Das Token wird bei jeder Anfrage als Bearer-Token gesendet und nie protokolliert. + +#### Connector-Zuordnungen + +1. Geben Sie Ihre Quay-Basis-URL in das Feld **Location** ein, zum Beispiel `https://quay.io` oder Ihr selbstgehostetes `https://quay.example.com`. Die URL muss HTTPS verwenden; geben Sie keinen abschließenden API-Pfad an — DefectDojo erstellt die API-Pfade automatisch. +2. Geben Sie das OAuth-Zugriffstoken in das Feld **Secret** ein. +3. Legen Sie optional einen **Namespace** fest, um die Ermittlung auf eine einzelne Quay-Organisation oder einen Benutzer zu beschränken. Leer lassen, um jedes Repository zu ermitteln, das das Token lesen kann. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo ordnet jedes Quay-**Repository** einem Eintrag zu. Für jedes Repository listet es die aktiven Tags auf, dedupliziert sie zu ihren eindeutigen Image-Manifesten (ein von mehreren Tags gemeinsam genutztes Manifest wird einmal gescannt) und liest den Clair-Bericht jedes Manifests. Manifeste, deren Scan Clair noch nicht abgeschlossen hat (zum Beispiel eine Multi-Architektur-Manifestliste oder ein noch in der Warteschlange befindliches Image), werden bis zu einem späteren Sync übersprungen. Jede Clair-Schwachstelle wird zu einem Befund — das betroffene Paket ist die Komponente, die Fix-Version wird zur Abhilfemaßnahme, und Clairs Schweregrade **Negligible**/**Unknown** werden als **Informational** erfasst. + +Weitere Informationen finden Sie in der [Project-Quay-API-Dokumentation](https://docs.projectquay.io/api_quay.html) und der [Clair-Dokumentation](https://quay.github.io/clair/). diff --git a/docs/content/connectors/toolreference/quay.es.md b/docs/content/connectors/toolreference/quay.es.md new file mode 100644 index 00000000000..b927c75bd81 --- /dev/null +++ b/docs/content/connectors/toolreference/quay.es.md @@ -0,0 +1,25 @@ +--- +title: "Quay" +description: "Cómo configurar el Conector Upstream de Quay para DefectDojo" +weight: 110 +audience: pro +--- +El conector de Quay usa la API REST de Project Quay para descubrir repositorios de contenedores e importar los informes de vulnerabilidades generados por el escáner **Clair** integrado de Quay. DefectDojo crea un Record para cada **repositorio** de Quay y, en cada Sync, lee el informe de seguridad de Clair del manifiesto de imagen de cada tag activo. + +#### Requisitos previos + +El escaneo de seguridad (Clair) debe estar habilitado en su instancia de Quay, y necesitará un **token de acceso OAuth 2** de Quay: + +* En Quay, cree (o abra) una Organization, vaya a **Applications**, cree una aplicación OAuth y luego **Generate Token** con al menos el alcance (scope) **Read repositories**. Se recomienda una aplicación dedicada para DefectDojo. +* El token se envía como un Bearer token en cada solicitud y nunca se registra en los logs. + +#### Asignaciones del conector + +1. Ingrese la URL base de Quay en el campo **Location**, por ejemplo `https://quay.io` o su instancia autoalojada `https://quay.example.com`. La URL debe ser HTTPS; no incluya una ruta de API al final: DefectDojo construye las rutas de la API automáticamente. +2. Ingrese el token de acceso OAuth en el campo **Secret**. +3. Opcionalmente, establezca un **Namespace** para restringir el descubrimiento a una única organización o usuario de Quay. Déjelo en blanco para descubrir todos los repositorios que el token pueda leer. +4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo asigna cada **repositorio** de Quay a un Record. Para cada repositorio, enumera los tags activos, los deduplica a sus manifiestos de imagen únicos (un manifiesto compartido por varios tags se escanea una sola vez) y lee el informe de Clair de cada manifiesto. Los manifiestos que Clair aún no ha terminado de escanear (por ejemplo, una lista de manifiestos multi-arquitectura, o una imagen aún en cola) se omiten hasta un Sync posterior. Cada vulnerabilidad de Clair se convierte en un hallazgo: el paquete afectado es el componente, la versión corregida se convierte en la mitigación, y las severidades **Negligible**/**Unknown** de Clair se registran como **Informativa**. + +Consulte la [documentación de la API de Project Quay](https://docs.projectquay.io/api_quay.html) y la [documentación de Clair](https://quay.github.io/clair/) para más información. diff --git a/docs/content/connectors/toolreference/quay.fr.md b/docs/content/connectors/toolreference/quay.fr.md new file mode 100644 index 00000000000..5db8d9fb62e --- /dev/null +++ b/docs/content/connectors/toolreference/quay.fr.md @@ -0,0 +1,25 @@ +--- +title: "Quay" +description: "Comment configurer le Connecteur Upstream Quay pour DefectDojo" +weight: 110 +audience: pro +--- +Le connecteur Quay utilise l'API REST de Project Quay pour découvrir les dépôts de conteneurs et importer les rapports de vulnérabilités produits par le scanner **Clair** intégré à Quay. DefectDojo crée un Record pour chaque **dépôt** Quay et, à chaque Sync, lit le rapport de sécurité Clair du manifeste d'image de chaque tag actif. + +#### Prérequis + +Le scan de sécurité (Clair) doit être activé sur votre instance Quay, et vous aurez besoin d'un **jeton d'accès OAuth 2** Quay : + +* Dans Quay, créez (ou ouvrez) une organisation, allez dans **Applications**, créez une application OAuth, puis **Generate Token** avec au minimum le scope **Read repositories**. Une application dédiée pour DefectDojo est recommandée. +* Le jeton est envoyé comme jeton Bearer à chaque requête et n'est jamais journalisé. + +#### Correspondances du connecteur + +1. Saisissez l'URL de base de votre Quay dans le champ **Location**, par exemple `https://quay.io` ou votre instance auto\-hébergée `https://quay.example.com`. L'URL doit être en HTTPS ; n'incluez pas de chemin d'API final — DefectDojo construit automatiquement les chemins d'API. +2. Saisissez le jeton d'accès OAuth dans le champ **Secret**. +3. Optionnellement, définissez un **Namespace** pour restreindre la découverte à une seule organisation ou un seul utilisateur Quay. Laissez vide pour découvrir tous les dépôts que le jeton peut lire. +4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +DefectDojo associe chaque **dépôt** Quay à un Record. Pour chaque dépôt, il liste les tags actifs, les déduplique vers leurs manifestes d'image uniques (un manifeste partagé par plusieurs tags est scanné une seule fois), et lit le rapport Clair de chaque manifeste. Les manifestes que Clair n'a pas terminé de scanner (par exemple une liste de manifestes multi\-architecture, ou une image encore en file d'attente) sont ignorés jusqu'à un Sync ultérieur. Chaque vulnérabilité Clair devient une constatation — le paquet concerné est le composant, la version corrigée devient la mitigation, et les sévérités **Negligible**/**Unknown** de Clair sont enregistrées comme **Informational**. + +Consultez la [documentation de l'API Project Quay](https://docs.projectquay.io/api_quay.html) et la [documentation Clair](https://quay.github.io/clair/) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/quay.ja.md b/docs/content/connectors/toolreference/quay.ja.md new file mode 100644 index 00000000000..db9460d207a --- /dev/null +++ b/docs/content/connectors/toolreference/quay.ja.md @@ -0,0 +1,25 @@ +--- +title: "Quay" +description: "DefectDojo で Quay の Upstream Connector をセットアップする方法" +weight: 110 +audience: pro +--- +QuayコネクタはProject Quay REST APIを使用して、コンテナリポジトリを検出し、Quay組み込みの**Clair**スキャナが生成した脆弱性レポートをインポートします。DefectDojoは各Quay**リポジトリ**についてRecordを作成し、Syncのたびにアクティブな各タグのイメージマニフェストのClairセキュリティレポートを読み取ります。 + +#### 前提条件 + +Quayインスタンスでセキュリティスキャン(Clair)が有効になっている必要があり、Quayの**OAuth 2アクセストークン**が必要です: + +* Quayで、Organizationを作成(または開き)、**Applications** に移動し、OAuthアプリケーションを作成し、少なくとも**Read repositories**スコープで **Generate Token** を実行します。DefectDojo専用のアプリケーションを作成することをお勧めします。 +* トークンはすべてのリクエストでBearerトークンとして送信され、ログに記録されることはありません。 + +#### Connector Mappings + +1. **Location** フィールドにQuayのベースURLを入力します。例: `https://quay.io` またはセルフホストの `https://quay.example.com`。URLはHTTPSである必要があり、末尾にAPIパスを含めないでください — DefectDojoがAPIパスを自動的に構築します。 +2. **Secret** フィールドにOAuthアクセストークンを入力します。 +3. 必要に応じて **Namespace** を設定し、検出範囲を単一のQuay組織またはユーザーに限定します。空欄のままにすると、トークンが読み取れるすべてのリポジトリが検出されます。 +4. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 + +DefectDojoは各Quay**リポジトリ**をRecordにマッピングします。各リポジトリについてアクティブなタグを列挙し、それらを一意のイメージマニフェストへと重複排除した上で(複数のタグで共有されるマニフェストは1回だけスキャンされます)、各マニフェストのClairレポートを読み取ります。Clairがまだスキャンを完了していないマニフェスト(例えばマルチアーキテクチャのマニフェストリストや、まだキュー中のイメージ)は、後のSyncまでスキップされます。各Clairの脆弱性は検出事項になります — 影響を受けるパッケージがコンポーネントとなり、修正バージョンが緩和策となり、Clairの**Negligible**/**Unknown**の深刻度は**Informational**として記録されます。 + +詳細については、[Project Quay APIドキュメント](https://docs.projectquay.io/api_quay.html)および[Clairドキュメント](https://quay.github.io/clair/)を参照してください。 diff --git a/docs/content/connectors/toolreference/quay.md b/docs/content/connectors/toolreference/quay.md new file mode 100644 index 00000000000..334e0a5532d --- /dev/null +++ b/docs/content/connectors/toolreference/quay.md @@ -0,0 +1,25 @@ +--- +title: "Quay" +description: "How to set up the Quay Upstream Connector for DefectDojo" +weight: 110 +audience: pro +--- +The Quay connector uses the Project Quay REST API to discover container repositories and import the vulnerability reports produced by Quay's built-in **Clair** scanner. DefectDojo creates a Record for each Quay **repository** and, on each Sync, reads the Clair security report of every active tag's image manifest. + +#### Prerequisites + +Security scanning (Clair) must be enabled on your Quay instance, and you will need a Quay **OAuth 2 access token**: + +* In Quay, create (or open) an Organization, go to **Applications**, create an OAuth application, then **Generate Token** with at least the **Read repositories** scope. A dedicated application for DefectDojo is recommended. +* The token is sent as a Bearer token on every request and is never logged. + +#### Connector Mappings + +1. Enter your Quay base URL in the **Location** field, for example `https://quay.io` or your self-hosted `https://quay.example.com`. The URL must be HTTPS; do not include a trailing API path — DefectDojo constructs the API paths automatically. +2. Enter the OAuth access token in the **Secret** field. +3. Optionally, set a **Namespace** to restrict discovery to a single Quay organization or user. Leave blank to discover every repository the token can read. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo maps each Quay **repository** to a Record. For each repository it lists the active tags, deduplicates them to their unique image manifests (a manifest shared by multiple tags is scanned once), and reads each manifest's Clair report. Manifests Clair has not finished scanning (for example a multi-architecture manifest list, or an image still queued) are skipped until a later Sync. Each Clair vulnerability becomes a finding — the affected package is the component, the fixed version becomes the mitigation, and Clair's **Negligible**/**Unknown** severities are recorded as **Informational**. + +See the [Project Quay API documentation](https://docs.projectquay.io/api_quay.html) and the [Clair documentation](https://quay.github.io/clair/) for more information. diff --git a/docs/content/connectors/toolreference/qwiet_ai.md b/docs/content/connectors/toolreference/qwiet_ai.md new file mode 100644 index 00000000000..f11f7270c25 --- /dev/null +++ b/docs/content/connectors/toolreference/qwiet_ai.md @@ -0,0 +1,20 @@ +--- +title: "Qwiet AI" +description: "How to set up the Qwiet AI Upstream Connector for DefectDojo" +weight: 111 +audience: pro +--- +The Qwiet AI connector imports **SAST, SCA and secret findings** from Qwiet AI (formerly ShiftLeft), and carries Qwiet's **reachability signal** — an indication of whether vulnerable code is actually reachable — which DefectDojo has no other source for. DefectDojo creates a Record for each **application** in your organization. + +#### Prerequisites + +A Qwiet AI **preZero access token**, sent as a bearer token and never logged. Your organization is read from the token itself, so you do not normally need to supply it. + +#### Connector Mappings + +1. Enter `https://app.shiftleft.io` in the **Location** field — the host is still the legacy ShiftLeft domain. DefectDojo appends the API path itself. +2. Enter the access token in the **Access Token** field. +3. Optionally, enter an **Organization ID** to override the organization. Leave it blank to use the organization encoded in the access token. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each application becomes a Record, carrying its SAST, SCA and secret findings together. diff --git a/docs/content/connectors/toolreference/rapid7_insightappsec.de.md b/docs/content/connectors/toolreference/rapid7_insightappsec.de.md new file mode 100644 index 00000000000..fb2c6083699 --- /dev/null +++ b/docs/content/connectors/toolreference/rapid7_insightappsec.de.md @@ -0,0 +1,23 @@ +--- +title: "Rapid7 InsightAppSec" +description: "Einrichtung des Rapid7 InsightAppSec Upstream-Connectors für DefectDojo" +weight: 112 +audience: pro +--- +Der Rapid7-InsightAppSec-Connector importiert **DAST-Schwachstellenbefunde** von der InsightAppSec-Cloud-Plattform, angereichert mit Attack-Module-Metadaten (zum Beispiel *SQL Injection*), CVSS-Scores und den vom Scan gesammelten Nachweisen. DefectDojo erstellt für jede InsightAppSec-**App** einen Eintrag. + +**Bitte beachten Sie:** Dieser Connector unterscheidet sich vom **Rapid7-InsightVM**-Connector weiter unten — InsightAppSec ist Rapid7s Cloud-DAST-Produkt auf der Insight-Plattform, während InsightVM-Befunde aus Ihrer eigenen Security Console stammen. + +#### Voraussetzungen + +Ein Insight-Platform-Konto mit InsightAppSec sowie ein Platform-**API-Schlüssel**: Öffnen Sie in der [Rapid7-Insight-Plattform](https://insight.rapid7.com) das Einstellungsmenü (Zahnrad) \> **API Keys** und generieren Sie einen **User Key** (beliebige Rolle) oder einen **Organization Key** (Platform-Admins). Kopieren Sie den Schlüssel, wenn er angezeigt wird — er wird nur einmal angezeigt. + +Sie benötigen außerdem Ihre Platform-**Region**, sichtbar in Ihrer Insight-URL (zum Beispiel `us`, `us2`, `us3`, `eu`, `ca`, `au` oder `ap`). + +#### Connector-Zuordnungen + +1. Geben Sie Ihren regionalen API-Endpunkt in das Feld **Location** ein — zum Beispiel `https://us.api.insight.rapid7.com` (ersetzen Sie `us` durch Ihre Region). +2. Geben Sie den API-Schlüssel der Insight-Plattform in das Feld **API Key** ein. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jede InsightAppSec-App wird zu einem Eintrag. Es werden nur **offene** Schwachstellen (Unreviewed oder Verified) importiert — Befunde, die Rapid7 als Remediated, False Positive, Ignored oder Duplicate markiert hat, werden ausgeschlossen, sodass ein erneuter Import sie in DefectDojo schließt. Schweregrade werden direkt abgebildet (`SAFE` und `INFORMATIONAL` werden als Info importiert). diff --git a/docs/content/connectors/toolreference/rapid7_insightappsec.es.md b/docs/content/connectors/toolreference/rapid7_insightappsec.es.md new file mode 100644 index 00000000000..0370ea5ac4c --- /dev/null +++ b/docs/content/connectors/toolreference/rapid7_insightappsec.es.md @@ -0,0 +1,23 @@ +--- +title: "Rapid7 InsightAppSec" +description: "Cómo configurar el Conector Upstream de Rapid7 InsightAppSec para DefectDojo" +weight: 112 +audience: pro +--- +El conector de Rapid7 InsightAppSec importa **hallazgos de vulnerabilidades DAST** desde la plataforma en la nube InsightAppSec, enriquecidos con metadatos del módulo de ataque (por ejemplo, *SQL Injection*), puntuaciones CVSS y la evidencia recopilada por el escaneo. DefectDojo crea un Record para cada **app** de InsightAppSec. + +**Tenga en cuenta:** este conector es distinto del conector **Rapid7 InsightVM** que se describe más abajo: InsightAppSec es el producto DAST en la nube de Rapid7 dentro de la plataforma Insight, mientras que los hallazgos de InsightVM provienen de su propia Security Console. + +#### Requisitos previos + +Una cuenta de la plataforma Insight con InsightAppSec, y una **API key** de la plataforma: en [Rapid7 Insight platform](https://insight.rapid7.com), abra el menú de configuración (el ícono de engranaje) > **API Keys** y genere una **User Key** (cualquier rol) o una **Organization Key** (administradores de la plataforma). Copie la clave cuando se muestre: solo se muestra una vez. + +También necesitará la **región** de su plataforma, visible en su URL de Insight (por ejemplo, `us`, `us2`, `us3`, `eu`, `ca`, `au` o `ap`). + +#### Asignaciones del conector + +1. Ingrese el endpoint de API de su región en el campo **Location**, por ejemplo `https://us.api.insight.rapid7.com` (reemplace `us` por su región). +2. Ingrese la API key de la plataforma Insight en el campo **API Key**. +3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada app de InsightAppSec se convierte en un Record. Solo se importan las vulnerabilidades **abiertas** (Unreviewed o Verified): los hallazgos que Rapid7 ha marcado como Remediated, Falso positivo, Ignored o Duplicado se excluyen, por lo que reimportar los cierra en DefectDojo. Las severidades se asignan directamente (`SAFE` e `INFORMATIONAL` se importan como Informativa). diff --git a/docs/content/connectors/toolreference/rapid7_insightappsec.fr.md b/docs/content/connectors/toolreference/rapid7_insightappsec.fr.md new file mode 100644 index 00000000000..8d47cee5e5a --- /dev/null +++ b/docs/content/connectors/toolreference/rapid7_insightappsec.fr.md @@ -0,0 +1,23 @@ +--- +title: "Rapid7 InsightAppSec" +description: "Comment configurer le Connecteur Upstream Rapid7 InsightAppSec pour DefectDojo" +weight: 112 +audience: pro +--- +Le connecteur Rapid7 InsightAppSec importe les **constatations de vulnérabilités DAST** depuis la plateforme cloud InsightAppSec, enrichies avec les métadonnées de module d'attaque (par exemple *SQL Injection*), les scores CVSS, et les preuves collectées par le scan. DefectDojo crée un Record pour chaque **app** InsightAppSec. + +**Remarque :** ce Connecteur est distinct du connecteur **Rapid7 InsightVM** ci\-dessous — InsightAppSec est le produit DAST cloud de Rapid7 sur la plateforme Insight, tandis que les constatations InsightVM proviennent de votre propre Security Console. + +#### Prérequis + +Un compte de la plateforme Insight avec InsightAppSec, et une **clé API** de plateforme : dans la [plateforme Rapid7 Insight](https://insight.rapid7.com), ouvrez le menu des paramètres (icône d'engrenage) \> **API Keys** et générez une **User Key** (n'importe quel rôle) ou une **Organization Key** (administrateurs de la plateforme). Copiez la clé lorsqu'elle s'affiche — elle n'est affichée qu'une seule fois. + +Vous avez également besoin de votre **région** de plateforme, visible dans votre URL Insight (par exemple `us`, `us2`, `us3`, `eu`, `ca`, `au`, ou `ap`). + +#### Correspondances du connecteur + +1. Saisissez votre endpoint API régional dans le champ **Location** — par exemple `https://us.api.insight.rapid7.com` (remplacez `us` par votre région). +2. Saisissez la clé API de la plateforme Insight dans le champ **API Key**. +3. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque app InsightAppSec devient un Record. Seules les vulnérabilités **ouvertes** (Unreviewed ou Vérifié) sont importées — les constatations que Rapid7 a marquées Remediated, Faux positif, Ignored, ou Doublon sont exclues, de sorte qu'une réimportation les clôt dans DefectDojo. Les sévérités sont associées directement (`SAFE` et `INFORMATIONAL` sont importés comme Info). diff --git a/docs/content/connectors/toolreference/rapid7_insightappsec.ja.md b/docs/content/connectors/toolreference/rapid7_insightappsec.ja.md new file mode 100644 index 00000000000..7d88276a7fc --- /dev/null +++ b/docs/content/connectors/toolreference/rapid7_insightappsec.ja.md @@ -0,0 +1,23 @@ +--- +title: "Rapid7 InsightAppSec" +description: "DefectDojo で Rapid7 InsightAppSec の Upstream Connector をセットアップする方法" +weight: 112 +audience: pro +--- +Rapid7 InsightAppSecコネクタは、InsightAppSecクラウドプラットフォームから**DAST脆弱性検出事項**をインポートし、アタックモジュールのメタデータ(例: *SQL Injection*)、CVSSスコア、スキャンで収集された証拠を付加します。DefectDojoは各InsightAppSecの**アプリ**についてRecordを作成します。 + +**ご注意ください:** このConnectorは、以下の**Rapid7 InsightVM**コネクタとは別のものです — InsightAppSecはInsightプラットフォーム上のRapid7のクラウドDAST製品であり、InsightVMの検出事項はお使いのSecurity Consoleから取得されます。 + +#### 前提条件 + +InsightAppSecを利用するInsightプラットフォームのアカウントと、プラットフォームの**APIキー**が必要です: [Rapid7 Insightプラットフォーム](https://insight.rapid7.com)で設定(歯車)メニュー > **API Keys** を開き、**User Key**(任意のロール)または**Organization Key**(プラットフォーム管理者)を生成します。表示された時点でキーをコピーしてください — 一度しか表示されません。 + +また、Insight URLに表示されるプラットフォームの**リージョン**(例: `us`、`us2`、`us3`、`eu`、`ca`、`au`、`ap`)も必要です。 + +#### Connector Mappings + +1. **Location** フィールドにリージョンのAPIエンドポイントを入力します — 例: `https://us.api.insight.rapid7.com`(`us` をお使いのリージョンに置き換えてください)。 +2. **API Key** フィールドにInsightプラットフォームのAPIキーを入力します。 +3. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 + +各InsightAppSecアプリが1件のRecordになります。**オープン**な脆弱性(UnreviewedまたはVerified)のみがインポートされます — Rapid7がRemediated、False Positive、Ignored、またはDuplicateとマークした検出事項は除外されるため、再インポートによってDefectDojo内でそれらがクローズされます。深刻度は直接マッピングされます(`SAFE` と `INFORMATIONAL` はInfoとしてインポートされます)。 diff --git a/docs/content/connectors/toolreference/rapid7_insightappsec.md b/docs/content/connectors/toolreference/rapid7_insightappsec.md new file mode 100644 index 00000000000..b582991cafb --- /dev/null +++ b/docs/content/connectors/toolreference/rapid7_insightappsec.md @@ -0,0 +1,23 @@ +--- +title: "Rapid7 InsightAppSec" +description: "How to set up the Rapid7 InsightAppSec Upstream Connector for DefectDojo" +weight: 112 +audience: pro +--- +The Rapid7 InsightAppSec connector imports **DAST vulnerability findings** from the InsightAppSec cloud platform, enriched with attack\-module metadata (for example *SQL Injection*), CVSS scores, and the evidence collected by the scan. DefectDojo creates a Record for each InsightAppSec **app**. + +**Please note:** this Connector is distinct from the [Rapid7 InsightVM](/connectors/toolreference/rapid7_insightvm/) connector — InsightAppSec is Rapid7's cloud DAST product on the Insight platform, while InsightVM findings come from your own Security Console. + +#### Prerequisites + +An Insight platform account with InsightAppSec, and a platform **API key**: in the [Rapid7 Insight platform](https://insight.rapid7.com), open the settings (gear) menu \> **API Keys** and generate a **User Key** (any role) or an **Organization Key** (platform admins). Copy the key when it is shown — it is displayed only once. + +You also need your platform **region**, visible in your Insight URL (for example `us`, `us2`, `us3`, `eu`, `ca`, `au`, or `ap`). + +#### Connector Mappings + +1. Enter your regional API endpoint in the **Location** field — for example `https://us.api.insight.rapid7.com` (replace `us` with your region). +2. Enter the Insight platform API key in the **API Key** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each InsightAppSec app becomes a Record. Only **open** vulnerabilities (Unreviewed or Verified) are imported — findings Rapid7 has marked Remediated, a False Positive, Ignored, or Duplicate are excluded, so reimport closes them in DefectDojo. Severities map directly (`SAFE` and `INFORMATIONAL` import as Info). diff --git a/docs/content/connectors/toolreference/rapid7_insightvm.de.md b/docs/content/connectors/toolreference/rapid7_insightvm.de.md new file mode 100644 index 00000000000..f648fb9c04f --- /dev/null +++ b/docs/content/connectors/toolreference/rapid7_insightvm.de.md @@ -0,0 +1,20 @@ +--- +title: "Rapid7 InsightVM" +description: "Einrichtung des Rapid7 InsightVM Upstream-Connectors für DefectDojo" +weight: 113 +audience: pro +--- +Der Rapid7-InsightVM-Connector importiert Asset-Schwachstellenbefunde aus Ihrer InsightVM-**Security Console** (API v3), angereichert mit dem globalen Schwachstellenkatalog der Console. DefectDojo erstellt für jede InsightVM-**Site** einen Eintrag. + +#### Voraussetzungen + +Netzwerkzugriff von DefectDojo auf Ihre Security Console sowie ein **Benutzerkonto** der Console — dessen Login wird für die HTTP-Basic-Authentifizierung verwendet. Die Console-API wird standardmäßig auf Port **3780** bereitgestellt. + +#### Connector-Zuordnungen + +1. Geben Sie die URL Ihrer Security Console einschließlich des Ports in das Feld **Location** ein — zum Beispiel `https://console.example.com:3780`. +2. Geben Sie den Console-Benutzernamen in das Feld **Username** ein. +3. Geben Sie das Console-Passwort in das Feld **Secret** ein. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jede InsightVM-Site wird zu einem Eintrag; der Connector durchläuft die Assets der Site und importiert deren anfällige Befunde. diff --git a/docs/content/connectors/toolreference/rapid7_insightvm.es.md b/docs/content/connectors/toolreference/rapid7_insightvm.es.md new file mode 100644 index 00000000000..cf55a5cdf2e --- /dev/null +++ b/docs/content/connectors/toolreference/rapid7_insightvm.es.md @@ -0,0 +1,20 @@ +--- +title: "Rapid7 InsightVM" +description: "Cómo configurar el Conector Upstream de Rapid7 InsightVM para DefectDojo" +weight: 113 +audience: pro +--- +El conector de Rapid7 InsightVM importa hallazgos de vulnerabilidades de activos desde su **Security Console** de InsightVM (API v3), enriquecidos con el catálogo global de vulnerabilidades de la consola. DefectDojo crea un Record para cada **site** de InsightVM. + +#### Requisitos previos + +Acceso de red desde DefectDojo hasta su Security Console, y una **cuenta de usuario** de la consola; su inicio de sesión se usa para la autenticación HTTP Basic. La API de la consola se sirve por defecto en el puerto **3780**. + +#### Asignaciones del conector + +1. Ingrese la URL de su Security Console, incluyendo el puerto, en el campo **Location**; por ejemplo, `https://console.example.com:3780`. +2. Ingrese el nombre de usuario de la consola en el campo **Username**. +3. Ingrese la contraseña de la consola en el campo **Secret**. +4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada site de InsightVM se convierte en un Record; el conector recorre los activos del site e importa sus hallazgos de vulnerabilidades. diff --git a/docs/content/connectors/toolreference/rapid7_insightvm.fr.md b/docs/content/connectors/toolreference/rapid7_insightvm.fr.md new file mode 100644 index 00000000000..42ecd254572 --- /dev/null +++ b/docs/content/connectors/toolreference/rapid7_insightvm.fr.md @@ -0,0 +1,20 @@ +--- +title: "Rapid7 InsightVM" +description: "Comment configurer le Connecteur Upstream Rapid7 InsightVM pour DefectDojo" +weight: 113 +audience: pro +--- +Le connecteur Rapid7 InsightVM importe les constatations de vulnérabilités d'actifs depuis votre **Security Console** InsightVM (API v3), enrichies avec le catalogue de vulnérabilités global de la console. DefectDojo crée un Record pour chaque **site** InsightVM. + +#### Prérequis + +Un accès réseau depuis DefectDojo vers votre Security Console, et un **compte utilisateur** de la console — son identifiant est utilisé pour l'authentification HTTP Basic. L'API de la console est servie par défaut sur le port **3780**. + +#### Correspondances du connecteur + +1. Saisissez l'URL de votre Security Console, port inclus, dans le champ **Location** — par exemple `https://console.example.com:3780`. +2. Saisissez le nom d'utilisateur de la console dans le champ **Username**. +3. Saisissez le mot de passe de la console dans le champ **Secret**. +4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque site InsightVM devient un Record ; le connecteur parcourt les actifs du site et importe leurs constatations vulnérables. diff --git a/docs/content/connectors/toolreference/rapid7_insightvm.ja.md b/docs/content/connectors/toolreference/rapid7_insightvm.ja.md new file mode 100644 index 00000000000..2a7a17f08d5 --- /dev/null +++ b/docs/content/connectors/toolreference/rapid7_insightvm.ja.md @@ -0,0 +1,20 @@ +--- +title: "Rapid7 InsightVM" +description: "DefectDojo で Rapid7 InsightVM の Upstream Connector をセットアップする方法" +weight: 113 +audience: pro +--- +Rapid7 InsightVMコネクタは、お使いのInsightVM**Security Console**(API v3)からアセットの脆弱性検出事項をインポートし、コンソールのグローバル脆弱性カタログで情報を付加します。DefectDojoは各InsightVM**サイト**についてRecordを作成します。 + +#### 前提条件 + +DefectDojoからお使いのSecurity Consoleへのネットワークアクセスと、コンソールの**ユーザーアカウント**が必要です — そのログイン情報がHTTP Basic認証に使用されます。コンソールAPIはデフォルトでポート**3780**で提供されます。 + +#### Connector Mappings + +1. **Location** フィールドに、ポートを含むSecurity ConsoleのURLを入力します — 例: `https://console.example.com:3780`。 +2. **Username** フィールドにコンソールのユーザー名を入力します。 +3. **Secret** フィールドにコンソールのパスワードを入力します。 +4. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 + +各InsightVMサイトが1件のRecordになります。コネクタはサイトのアセットを走査し、脆弱性のある検出事項をインポートします。 diff --git a/docs/content/connectors/toolreference/rapid7_insightvm.md b/docs/content/connectors/toolreference/rapid7_insightvm.md new file mode 100644 index 00000000000..faf51adbef7 --- /dev/null +++ b/docs/content/connectors/toolreference/rapid7_insightvm.md @@ -0,0 +1,20 @@ +--- +title: "Rapid7 InsightVM" +description: "How to set up the Rapid7 InsightVM Upstream Connector for DefectDojo" +weight: 113 +audience: pro +--- +The Rapid7 InsightVM connector imports asset vulnerability findings from your InsightVM **Security Console** (API v3), enriched with the console's global vulnerability catalog. DefectDojo creates a Record for each InsightVM **site**. + +#### Prerequisites + +Network access from DefectDojo to your Security Console, and a console **user account** — its login is used for HTTP Basic authentication. The console API is served on port **3780** by default. + +#### Connector Mappings + +1. Enter your Security Console URL, including the port, in the **Location** field — for example `https://console.example.com:3780`. +2. Enter the console username in the **Username** field. +3. Enter the console password in the **Secret** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each InsightVM site becomes a Record; the connector walks the site's assets and imports their vulnerable findings. diff --git a/docs/content/connectors/toolreference/red_hat_satellite.md b/docs/content/connectors/toolreference/red_hat_satellite.md new file mode 100644 index 00000000000..361f4f64586 --- /dev/null +++ b/docs/content/connectors/toolreference/red_hat_satellite.md @@ -0,0 +1,24 @@ +--- +title: "Red Hat Satellite" +description: "How to set up the Red Hat Satellite Upstream Connector for DefectDojo" +weight: 114 +audience: pro +--- +The Red Hat Satellite connector imports **errata** from your Satellite inventory as findings. DefectDojo enumerates every host and folds the fleet into Records along one Katello dimension of your choosing. + +**This is broader than "vulnerabilities."** Every applicable erratum on every host becomes a finding — that includes RHSA security advisories **and** bugfix and enhancement advisories. Use a **Minimum Severity** if you only want the security ones. + +#### Prerequisites + +A Satellite login with the **`view_hosts`** and **`view_content_views`** permissions. Satellite has no token endpoint, so the credentials are sent with every request over HTTP Basic authentication, and the password is never logged. + +#### Connector Mappings + +1. Enter your Satellite server URL in the **Location** field — for example `https://satellite.example.com`. +2. Enter the Satellite username in the **Username** field. +3. Enter the password in the **Password** field. +4. Optionally, set **Asset Grouping** to choose how hosts are folded into Records: `host-collection`, `lifecycle-environment`, `content-view`, or `host` for one Record per host. Leave it blank for `host-collection`. +5. Optionally, set **Skip TLS Verification** to `true` if your Satellite server uses the self\-signed certificate a default Satellite or Foreman install generates for itself. Leave it blank to verify certificates. +6. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Hosts that share a grouping value share a Record, and a new host joins the right Record automatically on the next Discover — so the mapping keeps up with your fleet without per\-host configuration. diff --git a/docs/content/connectors/toolreference/runzero.de.md b/docs/content/connectors/toolreference/runzero.de.md new file mode 100644 index 00000000000..98d6376a45f --- /dev/null +++ b/docs/content/connectors/toolreference/runzero.de.md @@ -0,0 +1,22 @@ +--- +title: "runZero" +description: "Einrichtung des runZero Upstream-Connectors für DefectDojo" +weight: 115 +audience: pro +--- +Der runZero-Connector verwendet die runZero-Export-API, um das Asset-Inventar Ihrer gesamten Organisation mit DefectDojo zu synchronisieren. Er ist in erster Linie ein **Asset**-Connector: DefectDojo ermittelt jedes Asset und erstellt für jedes einen Eintrag, gruppiert in einen Produkttyp nach seiner runZero-**Site**. Optional kann er auch die Schwachstellen von runZero als Befunde importieren. + +#### Voraussetzungen + +Sie benötigen einen organisationsweiten **Export Token** von runZero (Account → API), der mit `XT` beginnt. Das Token ist organisationsgebunden (die Organisation ist im Token codiert), schreibgeschützt und wird als Bearer-Token gesendet — es wird nie protokolliert. Ein Community-/Starter-Tier ist verfügbar. + +#### Connector-Zuordnungen + +1. Geben Sie Ihre runZero-Konsolen-URL in das Feld **Location** ein, zum Beispiel `https://console.runzero.com`. Die URL muss HTTPS verwenden. +2. Geben Sie das Export Token in das Feld **Secret** ein. +3. Setzen Sie optional **Import Vulnerabilities** auf `true`, um auch runZero-Schwachstellen als Befunde zu importieren; lassen Sie es leer, um nur Assets zu synchronisieren. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Schwachstellenbefunde importiert werden (gilt nur, wenn Schwachstellen importiert werden). + +DefectDojo ordnet jedes runZero-**Asset** einem Eintrag (VEP) zu: Der Anzeigename stammt aus dem Namen oder der Adresse des Assets, und dessen Site, Typ, Betriebssystem, Adressen und Tags werden als Attribute angehängt; die **Site** des Assets wird zu dessen Produkttyp. Assets werden mit einem vollständigen Export synchronisiert, den DefectDojo abgleicht (Hinzufügen/Entfernen). Ist **Import Vulnerabilities** aktiviert, wird jede runZero-Schwachstelle zu einem Befund an ihrem Asset — dabei werden Schweregrad, CVSS-Score, CVE, der betroffene Dienst-Endpunkt (`protocol://address:port`) und die Abhilfemaßnahme abgebildet. + +Weitere Informationen finden Sie in der [runZero-API-Dokumentation](https://help.runzero.com/). diff --git a/docs/content/connectors/toolreference/runzero.es.md b/docs/content/connectors/toolreference/runzero.es.md new file mode 100644 index 00000000000..ca168ba55bc --- /dev/null +++ b/docs/content/connectors/toolreference/runzero.es.md @@ -0,0 +1,22 @@ +--- +title: "runZero" +description: "Cómo configurar el Conector Upstream de runZero para DefectDojo" +weight: 115 +audience: pro +--- +El conector de runZero usa la Export API de runZero para sincronizar el inventario de activos de toda su organización en DefectDojo. Es principalmente un conector de **activos**: DefectDojo descubre cada activo y crea un Record para cada uno, agrupados en un Product Type según su **site** de runZero. Opcionalmente, también puede importar las vulnerabilidades de runZero como hallazgos. + +#### Requisitos previos + +Necesitará un **Export Token** de organización de runZero (Account → API), con el prefijo `XT`. El token tiene alcance de organización (la organización está codificada en el token), es de solo lectura, y se envía como un Bearer token; nunca se registra en los logs. Hay disponible un nivel community/starter. + +#### Asignaciones del conector + +1. Ingrese la URL de la consola de runZero en el campo **Location**, por ejemplo `https://console.runzero.com`. La URL debe ser HTTPS. +2. Ingrese el Export Token en el campo **Secret**. +3. Opcionalmente, establezca **Import Vulnerabilities** en `true` para importar también las vulnerabilidades de runZero como hallazgos; déjelo en blanco para sincronizar solo los activos. +4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos de vulnerabilidades se importan (aplica solo cuando se importan vulnerabilidades). + +DefectDojo asigna cada **activo** de runZero a un Record (VEP): el nombre visible proviene del nombre o la dirección del activo, y su site, tipo, SO, direcciones y etiquetas se adjuntan como atributos; el **site** del activo se convierte en su Product Type. Los activos se sincronizan mediante una exportación completa que DefectDojo concilia (agrega/elimina). Cuando **Import Vulnerabilities** está habilitado, cada vulnerabilidad de runZero se convierte en un hallazgo en su activo, asignando la severidad, la puntuación CVSS, el CVE, el endpoint del servicio afectado (`protocol://address:port`) y la remediación. + +Consulte la [documentación de la API de runZero](https://help.runzero.com/) para más información. diff --git a/docs/content/connectors/toolreference/runzero.fr.md b/docs/content/connectors/toolreference/runzero.fr.md new file mode 100644 index 00000000000..fbdcfaa2466 --- /dev/null +++ b/docs/content/connectors/toolreference/runzero.fr.md @@ -0,0 +1,22 @@ +--- +title: "runZero" +description: "Comment configurer le Connecteur Upstream runZero pour DefectDojo" +weight: 115 +audience: pro +--- +Le connecteur runZero utilise l'API Export de runZero pour synchroniser l'inventaire d'actifs de toute votre organisation dans DefectDojo. C'est principalement un connecteur d'**actifs** : DefectDojo découvre chaque actif et crée un Record pour chacun, regroupé en un Product Type par son **site** runZero. Il peut aussi, optionnellement, importer les vulnérabilités de runZero en tant que constatations. + +#### Prérequis + +Vous aurez besoin d'un **Export Token** d'organisation depuis runZero (Account → API), préfixé par `XT`. Le jeton est scopé à l'organisation (l'organisation est encodée dans le jeton), en lecture seule, et est envoyé comme jeton Bearer — il n'est jamais journalisé. Un niveau communautaire/starter est disponible. + +#### Correspondances du connecteur + +1. Saisissez l'URL de votre console runZero dans le champ **Location**, par exemple `https://console.runzero.com`. L'URL doit être en HTTPS. +2. Saisissez l'Export Token dans le champ **Secret**. +3. Optionnellement, réglez **Import Vulnerabilities** sur `true` pour aussi importer les vulnérabilités runZero en tant que constatations ; laissez vide pour ne synchroniser que les actifs. +4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations de vulnérabilité importées (s'applique uniquement lorsque les vulnérabilités sont importées). + +DefectDojo associe chaque **actif** runZero à un Record (VEP) : le nom d'affichage provient du nom ou de l'adresse de l'actif, et son site, type, OS, adresses et étiquettes sont attachés en tant qu'attributs ; le **site** de l'actif devient son Product Type. Les actifs sont synchronisés via un export complet que DefectDojo réconcilie (ajouts/suppressions). Lorsque **Import Vulnerabilities** est activé, chaque vulnérabilité runZero devient une constatation sur son actif — en associant la sévérité, le score CVSS, le CVE, le point de terminaison du service concerné (`protocol://address:port`) et la remédiation. + +Consultez la [documentation de l'API runZero](https://help.runzero.com/) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/runzero.ja.md b/docs/content/connectors/toolreference/runzero.ja.md new file mode 100644 index 00000000000..6118f9d0faf --- /dev/null +++ b/docs/content/connectors/toolreference/runzero.ja.md @@ -0,0 +1,22 @@ +--- +title: "runZero" +description: "DefectDojo で runZero の Upstream Connector をセットアップする方法" +weight: 115 +audience: pro +--- +runZeroコネクタはrunZero Export APIを使用して、組織全体のアセットインベントリをDefectDojoに同期します。これは主に**アセット**コネクタです: DefectDojoはすべてのアセットを検出してそれぞれについてRecordを作成し、runZeroの**サイト**ごとにProduct Typeにグループ化します。オプションで、runZeroの脆弱性を検出事項としてインポートすることもできます。 + +#### 前提条件 + +runZero(Account → API)から組織の**Export Token**が必要で、これは `XT` というプレフィックスが付きます。このトークンは組織スコープ(組織がトークン内にエンコードされています)、読み取り専用であり、Bearerトークンとして送信されます — ログに記録されることはありません。コミュニティ/スタータープランも利用できます。 + +#### Connector Mappings + +1. **Location** フィールドにrunZeroコンソールのURLを入力します。例: `https://console.runzero.com`。URLはHTTPSである必要があります。 +2. **Secret** フィールドにExport Tokenを入力します。 +3. 必要に応じて **Import Vulnerabilities** を `true` に設定すると、runZeroの脆弱性も検出事項としてインポートされます。空欄のままにすると、アセットのみが同期されます。 +4. 必要に応じて **Minimum Severity** を設定し、インポートする脆弱性の検出事項を絞り込みます(脆弱性がインポートされる場合にのみ適用されます)。 + +DefectDojoは各runZero**アセット**をRecord (VEP) にマッピングします: 表示名はアセットの名前またはアドレスから取得され、そのサイト、種別、OS、アドレス、タグが属性として付与されます。アセットの**サイト**がそのProduct Typeになります。アセットは、DefectDojoが差分を調整する(追加/削除する)完全なエクスポートによって同期されます。**Import Vulnerabilities** が有効な場合、各runZeroの脆弱性はそのアセット上の検出事項になります — 深刻度、CVSSスコア、CVE、影響を受けるサービス(`protocol://address:port`)のエンドポイント、および修復方法がマッピングされます。 + +詳細については、[runZero APIドキュメント](https://help.runzero.com/)を参照してください。 diff --git a/docs/content/connectors/toolreference/runzero.md b/docs/content/connectors/toolreference/runzero.md new file mode 100644 index 00000000000..494587f1c6f --- /dev/null +++ b/docs/content/connectors/toolreference/runzero.md @@ -0,0 +1,22 @@ +--- +title: "runZero" +description: "How to set up the runZero Upstream Connector for DefectDojo" +weight: 115 +audience: pro +--- +The runZero connector uses the runZero Export API to sync your whole organization's asset inventory into DefectDojo. It is primarily an **asset** connector: DefectDojo discovers every asset and creates a Record for each, grouped into an Organization by its runZero **site**. It can optionally also import runZero's vulnerabilities as findings. + +#### Prerequisites + +You will need an organization **Export Token** from runZero (Account → API), which is prefixed `XT`. The token is organization-scoped (the organization is encoded in the token), read-only, and is sent as a Bearer token — it is never logged. A community/starter tier is available. + +#### Connector Mappings + +1. Enter your runZero console URL in the **Location** field, for example `https://console.runzero.com`. The URL must be HTTPS. +2. Enter the Export Token in the **Secret** field. +3. Optionally set **Import Vulnerabilities** to `true` to also import runZero vulnerabilities as findings; leave it blank to sync assets only. +4. Optionally, set a **Minimum Severity** to limit which vulnerability findings are imported (applies only when vulnerabilities are imported). + +DefectDojo maps each runZero **asset** to a Record (VEP): the display name comes from the asset's name or address, and its site, type, OS, addresses and tags are attached as attributes; the asset's **site** becomes its Organization. Assets are synced with a full export that DefectDojo reconciles (adds/removes). When **Import Vulnerabilities** is enabled, each runZero vulnerability becomes a finding on its asset — mapping the severity, CVSS score, CVE, affected service (`protocol://address:port`) endpoint and the remediation. + +See the [runZero API documentation](https://help.runzero.com/) for more information. diff --git a/docs/content/connectors/toolreference/scantist.md b/docs/content/connectors/toolreference/scantist.md new file mode 100644 index 00000000000..acdcaf4289a --- /dev/null +++ b/docs/content/connectors/toolreference/scantist.md @@ -0,0 +1,19 @@ +--- +title: "Scantist" +description: "How to set up the Scantist Upstream Connector for DefectDojo" +weight: 116 +audience: pro +--- +The Scantist connector imports **SCA and SAST findings** from Scantist. DefectDojo creates a Record for each **project** on the account. + +#### Prerequisites + +A Scantist **API token**, generated in the Scantist UI under your account settings. + +#### Connector Mappings + +1. Enter `https://api.scantist.io` in the **Location** field. +2. Enter the API token in the **API Token** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each project becomes a Record, and its findings come from that project's **most recent completed scan**. diff --git a/docs/content/connectors/toolreference/security_hub.de.md b/docs/content/connectors/toolreference/security_hub.de.md new file mode 100644 index 00000000000..166e7223f74 --- /dev/null +++ b/docs/content/connectors/toolreference/security_hub.de.md @@ -0,0 +1,53 @@ +--- +title: "AWS Security Hub" +description: "Einrichtung des AWS Security Hub Upstream-Connectors für DefectDojo" +weight: 117 +audience: pro +--- +Der AWS-Security-Hub-Connector verwendet einen AWS-Zugriffsschlüssel, um mit den Security-Hub-APIs zu interagieren. + +#### Voraussetzungen + +Anstatt den AWS-Zugriffsschlüssel eines Teammitglieds zu verwenden, empfehlen wir, in Ihrem AWS-Konto speziell für DefectDojo einen IAM-Benutzer anzulegen, dessen Berechtigungen auf das für die Interaktion mit Security Hub Notwendige beschränkt sind. + +Die AWS-Richtlinie „**[AWSSecurityHubReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubReadOnlyAccess.html)**" bietet die für einen Connector erforderliche Zugriffsebene. Wenn Sie eine benutzerdefinierte Richtlinie für einen Connector schreiben möchten, müssen Sie die folgenden Berechtigungen einbeziehen: + +* [DescribeHub](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_DescribeHub.html) +* [GetFindingAggregator](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingAggregator.html) +* [GetFindings](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindings.html) +* [ListFindingAggregators](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_ListFindingAggregators.html) + +Eine funktionierende Richtliniendefinition könnte wie folgt aussehen: + +``` +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "AWSSecurityHubConnectorPerms", + "Effect": "Allow", + "Action": [ + "securityhub:DescribeHub", + "securityhub:GetFindingAggregator", + "securityhub:GetFindings", + "securityhub:ListFindingAggregators" + ], + "Resource": "*" + } + ] +} +``` + +**Bitte beachten Sie:** Wir benötigen möglicherweise in Zukunft zusätzliche API-Aktionen, um die bestmögliche Erfahrung zu bieten, was Aktualisierungen dieser Richtlinie erfordern wird. + +Sobald Sie Ihren IAM-Benutzer erstellt und ihm mit einer geeigneten Richtlinie/Rolle die notwendigen Berechtigungen zugewiesen haben, müssen Sie einen Zugriffsschlüssel generieren, den Sie dann zum Erstellen eines Connectors verwenden können. + +#### Connector-Zuordnungen + +1. Geben Sie den passenden [AWS-API-Endpunkt für Ihre Region](https://docs.aws.amazon.com/general/latest/gr/sechub.html#sechub_region) in das Feld **Location** ein**:** Um beispielsweise Ergebnisse aus der Region `us-east-1` abzurufen, würden Sie Folgendes angeben + +`https://securityhub.us-east-1.amazonaws.com` +2. Geben Sie einen gültigen **AWS Access Key** in das Feld **Access Key** ein. +3. Geben Sie den passenden **Secret Key** in das Feld **Secret Key** ein. + +DefectDojo kann mithilfe der Funktion **regionsübergreifende Aggregation** von Security Hub Befunde aus mehr als einer Region abrufen. Wenn die [regionsübergreifende Aggregation](https://docs.aws.amazon.com/securityhub/latest/userguide/finding-aggregation.html) aktiviert ist, sollten Sie den API-Endpunkt Ihrer „**Aggregation Region**" angeben. Für zusätzlich verknüpfte Regionen werden in DefectDojo anhand Ihrer AWS-Konto-ID und des Regionsnamens ProductRecords erstellt. diff --git a/docs/content/connectors/toolreference/security_hub.es.md b/docs/content/connectors/toolreference/security_hub.es.md new file mode 100644 index 00000000000..94e9f159b9f --- /dev/null +++ b/docs/content/connectors/toolreference/security_hub.es.md @@ -0,0 +1,53 @@ +--- +title: "AWS Security Hub" +description: "Cómo configurar el Conector Upstream de AWS Security Hub para DefectDojo" +weight: 117 +audience: pro +--- +El conector de AWS Security Hub usa una clave de acceso de AWS para interactuar con las API de Security Hub. + +#### Prerrequisitos + +En lugar de usar la clave de acceso de AWS de un miembro del equipo, recomendamos crear un IAM User en su cuenta de AWS específicamente para DefectDojo, con los permisos de ese usuario limitados a los necesarios para interactuar con Security Hub. + +La política "**[AWSSecurityHubReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubReadOnlyAccess.html)**" de AWS proporciona el nivel de acceso necesario para un conector. Si desea escribir una política personalizada para un Conector, deberá incluir los siguientes permisos: + +* [DescribeHub](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_DescribeHub.html) +* [GetFindingAggregator](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingAggregator.html) +* [GetFindings](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindings.html) +* [ListFindingAggregators](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_ListFindingAggregators.html) + +Una definición de política funcional podría verse de la siguiente manera: + +``` +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "AWSSecurityHubConnectorPerms", + "Effect": "Allow", + "Action": [ + "securityhub:DescribeHub", + "securityhub:GetFindingAggregator", + "securityhub:GetFindings", + "securityhub:ListFindingAggregators" + ], + "Resource": "*" + } + ] +} +``` + +**Tenga en cuenta:** es posible que en el futuro necesitemos usar acciones de API adicionales para ofrecer la mejor experiencia posible, lo que requerirá actualizaciones de esta política. + +Una vez que haya creado su usuario de IAM y le haya asignado los permisos necesarios mediante una política/rol adecuado, deberá generar una clave de acceso, que luego podrá usar para crear un Conector. + +#### Asignaciones del conector + +1. Ingrese el [AWS API Endpoint correspondiente a su región](https://docs.aws.amazon.com/general/latest/gr/sechub.html#sechub_region) en el campo **Location****:** por ejemplo, para obtener resultados de la región `us-east-1`, debería usar + +`https://securityhub.us-east-1.amazonaws.com` +2. Ingrese una **AWS Access Key** válida en el campo **Access Key**. +3. Ingrese una **Secret Key** correspondiente en el campo **Secret Key**. + +DefectDojo puede extraer Hallazgos de más de una región mediante la función de **agregación entre regiones** de Security Hub. Si la [agregación entre regiones](https://docs.aws.amazon.com/securityhub/latest/userguide/finding-aggregation.html) está habilitada, debe proporcionar el endpoint de la API de su "**Aggregation Region**". Para las regiones adicionales vinculadas se crearán ProductRecords en DefectDojo según el ID de su cuenta de AWS y el nombre de la región. diff --git a/docs/content/connectors/toolreference/security_hub.fr.md b/docs/content/connectors/toolreference/security_hub.fr.md new file mode 100644 index 00000000000..18a728bebb1 --- /dev/null +++ b/docs/content/connectors/toolreference/security_hub.fr.md @@ -0,0 +1,53 @@ +--- +title: "AWS Security Hub" +description: "Comment configurer le Connecteur Upstream AWS Security Hub pour DefectDojo" +weight: 117 +audience: pro +--- +Le connecteur AWS Security Hub utilise une clé d'accès AWS pour interagir avec les API de Security Hub. + +#### Prérequis + +Plutôt que d'utiliser la clé d'accès AWS d'un membre de l'équipe, nous recommandons de créer un utilisateur IAM dans votre compte AWS spécifiquement pour DefectDojo, avec des permissions limitées à celles nécessaires pour interagir avec Security Hub. + +La politique AWS « **[AWSSecurityHubReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubReadOnlyAccess.html)**policy » fournit le niveau d'accès requis pour un connecteur. Si vous souhaitez rédiger une politique personnalisée pour un Connecteur, vous devrez inclure les permissions suivantes : + +* [DescribeHub](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_DescribeHub.html) +* [GetFindingAggregator](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingAggregator.html) +* [GetFindings](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindings.html) +* [ListFindingAggregators](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_ListFindingAggregators.html) + +Un exemple de politique fonctionnelle pourrait ressembler à ceci : + +``` +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "AWSSecurityHubConnectorPerms", + "Effect": "Allow", + "Action": [ + "securityhub:DescribeHub", + "securityhub:GetFindingAggregator", + "securityhub:GetFindings", + "securityhub:ListFindingAggregators" + ], + "Resource": "*" + } + ] +} +``` + +**Veuillez noter :** nous pourrions avoir besoin d'utiliser des actions API supplémentaires à l'avenir afin d'offrir la meilleure expérience possible, ce qui nécessitera des mises à jour de cette politique. + +Une fois que vous avez créé votre utilisateur IAM et lui avez attribué les permissions nécessaires à l'aide d'une politique/d'un rôle approprié, vous devrez générer une clé d'accès, que vous pourrez ensuite utiliser pour créer un Connecteur. + +#### Mappages du Connecteur + +1. Saisissez le [point de terminaison de l'API AWS correspondant à votre région](https://docs.aws.amazon.com/general/latest/gr/sechub.html#sechub_region) dans le champ **Location**\ : par exemple, pour récupérer les résultats de la région `us-east-1`, vous fourniriez + +`https://securityhub.us-east-1.amazonaws.com` +2. Saisissez une **AWS Access Key** valide dans le champ **Access Key**. +3. Saisissez la **Secret Key** correspondante dans le champ **Secret Key**. + +DefectDojo peut récupérer des constatations depuis plusieurs régions grâce à la fonctionnalité d'**agrégation inter-régions** de Security Hub. Si l'[agrégation inter-régions](https://docs.aws.amazon.com/securityhub/latest/userguide/finding-aggregation.html) est activée, vous devez fournir le point de terminaison de l'API pour votre « **Aggregation Region** ». Pour les régions liées supplémentaires, des Enregistrements de Produit seront créés dans DefectDojo à partir de l'ID de votre compte AWS et du nom de la région. diff --git a/docs/content/connectors/toolreference/security_hub.ja.md b/docs/content/connectors/toolreference/security_hub.ja.md new file mode 100644 index 00000000000..eb12248766e --- /dev/null +++ b/docs/content/connectors/toolreference/security_hub.ja.md @@ -0,0 +1,53 @@ +--- +title: "AWS Security Hub" +description: "DefectDojo で AWS Security Hub の Upstream Connector をセットアップする方法" +weight: 117 +audience: pro +--- +AWS Security Hub コネクタは、Security Hub の API とやり取りするために AWS アクセスキーを使用します。 + +#### Prerequisites + +チームメンバーの AWS アクセスキーを使用するのではなく、DefectDojo 専用に AWS アカウント内で IAM ユーザーを作成し、そのユーザーの権限を Security Hub とのやり取りに必要な範囲に限定することをお勧めします。 + +AWS の「**[AWSSecurityHubReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubReadOnlyAccess.html)** ポリシー」は、コネクタに必要なレベルのアクセスを提供します。Connector 用にカスタムポリシーを作成したい場合は、以下の権限を含める必要があります。 + +* [DescribeHub](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_DescribeHub.html) +* [GetFindingAggregator](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingAggregator.html) +* [GetFindings](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindings.html) +* [ListFindingAggregators](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_ListFindingAggregators.html) + +実際に機能するポリシー定義は、以下のようになります。 + +``` +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "AWSSecurityHubConnectorPerms", + "Effect": "Allow", + "Action": [ + "securityhub:DescribeHub", + "securityhub:GetFindingAggregator", + "securityhub:GetFindings", + "securityhub:ListFindingAggregators" + ], + "Resource": "*" + } + ] +} +``` + +**ご注意ください:** 最良の利用体験を提供するため、今後追加の API アクションが必要になる場合があり、その際はこのポリシーの更新が必要になります。 + +IAM ユーザーを作成し、適切なポリシー/ロールを使って必要な権限を割り当てたら、アクセスキーを生成し、それを使って Connector を作成します。 + +#### Connector Mappings + +1. **Location** フィールドに、[お使いのリージョンに対応する AWS API エンドポイント](https://docs.aws.amazon.com/general/latest/gr/sechub.html#sechub_region)を入力します。例えば `us-east-1` リージョンから結果を取得する場合は、以下を指定します。 + +`https://securityhub.us-east-1.amazonaws.com` +2. **Access Key** フィールドに有効な **AWS Access Key** を入力します。 +3. **Secret Key** フィールドに対応する **Secret Key** を入力します。 + +DefectDojo は Security Hub の**クロスリージョン集約**機能を使って複数のリージョンから検出事項を取得できます。[クロスリージョン集約](https://docs.aws.amazon.com/securityhub/latest/userguide/finding-aggregation.html)が有効な場合は、「**Aggregation Region**」の API エンドポイントを指定してください。追加でリンクされているリージョンについては、AWS アカウント ID とリージョン名に基づいて DefectDojo 内に ProductRecords が作成されます。 diff --git a/docs/content/connectors/toolreference/security_hub.md b/docs/content/connectors/toolreference/security_hub.md new file mode 100644 index 00000000000..ee23caaec29 --- /dev/null +++ b/docs/content/connectors/toolreference/security_hub.md @@ -0,0 +1,53 @@ +--- +title: "Security Hub" +description: "How to set up the Security Hub Upstream Connector for DefectDojo" +weight: 117 +audience: pro +--- +The AWS Security Hub connector uses an AWS access key to interact with the Security Hub APIs. + +#### Prerequisites + +Rather than use the AWS access key from a team member, we recommend creating an IAM User in your AWS account specifically for DefectDojo, with that user's permissions limited to those necessary for interacting with Security Hub. + +AWS's "**[AWSSecurityHubReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubReadOnlyAccess.html)**policy" provides the required level of access for a connector. If you would like to write a custom policy for a Connector, you will need to include the following permissions: + +* [DescribeHub](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_DescribeHub.html) +* [GetFindingAggregator](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingAggregator.html) +* [GetFindings](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindings.html) +* [ListFindingAggregators](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_ListFindingAggregators.html) + +A working policy definition might look like the following: + +``` +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "AWSSecurityHubConnectorPerms", + "Effect": "Allow", + "Action": [ + "securityhub:DescribeHub", + "securityhub:GetFindingAggregator", + "securityhub:GetFindings", + "securityhub:ListFindingAggregators" + ], + "Resource": "*" + } + ] +} +``` + +**Please note:** we may need to use additional API actions in the future to provide the best possible experience, which will require updates to this policy. + +Once you have created your IAM user and assigned it the necessary permissions using an appropriate policy/role, you will need to generate an access key, which you can then use to create a Connector. + +#### Connector Mappings + +1. Enter the appropriate [AWS API Endpoint for your region](https://docs.aws.amazon.com/general/latest/gr/sechub.html#sechub_region) in the **Location** field**:** for example, to retrieve results from the `us-east-1` region, you would supply + +`https://securityhub.us-east-1.amazonaws.com` +2. Enter a valid **AWS Access Key** in the **Access Key** field. +3. Enter a matching **Secret Key** in the **Secret Key** field. + +DefectDojo can pull Findings from more than one region using Security Hub's **cross\-region aggregation** feature. If [cross\-region aggregation](https://docs.aws.amazon.com/securityhub/latest/userguide/finding-aggregation.html) is enabled, you should supply the API endpoint for your "**Aggregation Region**". Additional linked regions will have ProductRecords created for them in DefectDojo based on your AWS account ID and the region name. diff --git a/docs/content/connectors/toolreference/semgrep.de.md b/docs/content/connectors/toolreference/semgrep.de.md new file mode 100644 index 00000000000..921538e9eb9 --- /dev/null +++ b/docs/content/connectors/toolreference/semgrep.de.md @@ -0,0 +1,17 @@ +--- +title: "Semgrep" +description: "Einrichtung des Semgrep Upstream-Connectors für DefectDojo" +weight: 118 +audience: pro +--- +Dieser Connector verwendet die Semgrep-REST-API, um Daten abzurufen. + +#### Connector-Zuordnungen + +Geben Sie `https://semgrep.dev/api/v1/` in das Feld **Location** ein. + +1. Geben Sie einen gültigen API-Schlüssel in das Feld **Secret** ein. Sie finden diesen auf der Tokens-Seite: +​ +„Settings" in der linken Navigationsleiste \> Tokens \> Create new token ([https://semgrep.dev/orgs/\-/settings/tokens](https://semgrep.dev/orgs/-/settings/tokens)) + +Weitere Informationen finden Sie in der [Semgrep-Dokumentation](https://semgrep.dev/docs/semgrep-cloud-platform/semgrep-api/#tag__badge-list). diff --git a/docs/content/connectors/toolreference/semgrep.es.md b/docs/content/connectors/toolreference/semgrep.es.md new file mode 100644 index 00000000000..3ec47a90eb1 --- /dev/null +++ b/docs/content/connectors/toolreference/semgrep.es.md @@ -0,0 +1,17 @@ +--- +title: "Semgrep" +description: "Cómo configurar el Conector Upstream de Semgrep para DefectDojo" +weight: 118 +audience: pro +--- +Este conector usa la API REST de Semgrep para obtener datos. + +#### Asignaciones del conector + +Ingrese `https://semgrep.dev/api/v1/` en el campo **Location**. + +1. Ingrese una API key válida en el campo **Secret**. La puede encontrar en la página de Tokens: +​ +"Settings" en la barra de navegación izquierda > Tokens > Create new token ([https://semgrep.dev/orgs/\-/settings/tokens](https://semgrep.dev/orgs/-/settings/tokens)) + +Consulte la [documentación de Semgrep](https://semgrep.dev/docs/semgrep-cloud-platform/semgrep-api/#tag__badge-list) para más información. diff --git a/docs/content/connectors/toolreference/semgrep.fr.md b/docs/content/connectors/toolreference/semgrep.fr.md new file mode 100644 index 00000000000..cd5902b4735 --- /dev/null +++ b/docs/content/connectors/toolreference/semgrep.fr.md @@ -0,0 +1,17 @@ +--- +title: "Semgrep" +description: "Comment configurer le Connecteur Upstream Semgrep pour DefectDojo" +weight: 118 +audience: pro +--- +Ce connecteur utilise l'API REST de Semgrep pour récupérer les données. + +#### Correspondances du connecteur + +Saisissez `https://semgrep.dev/api/v1/` dans le champ **Location**. + +1. Saisissez une clé API valide dans le champ **Secret**. Vous pouvez la trouver sur la page Tokens : +​ +« Settings » dans la barre de navigation de gauche \> Tokens \> Create new token ([https://semgrep.dev/orgs/\-/settings/tokens](https://semgrep.dev/orgs/-/settings/tokens)) + +Consultez la [documentation Semgrep](https://semgrep.dev/docs/semgrep-cloud-platform/semgrep-api/#tag__badge-list) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/semgrep.ja.md b/docs/content/connectors/toolreference/semgrep.ja.md new file mode 100644 index 00000000000..bddfd70a92f --- /dev/null +++ b/docs/content/connectors/toolreference/semgrep.ja.md @@ -0,0 +1,17 @@ +--- +title: "Semgrep" +description: "DefectDojo で Semgrep の Upstream Connector をセットアップする方法" +weight: 118 +audience: pro +--- +このコネクタは、Semgrep REST APIを使用してデータを取得します。 + +#### Connector Mappings + +**Location** フィールドに `https://semgrep.dev/api/v1/` を入力します。 + +1. **Secret** フィールドに有効なAPIキーを入力します。これはTokensページで確認できます: +​ +左側のナビゲーションバーの「Settings」 \> Tokens \> Create new token ([https://semgrep.dev/orgs/\-/settings/tokens](https://semgrep.dev/orgs/-/settings/tokens)) + +詳細については[Semgrepのドキュメント](https://semgrep.dev/docs/semgrep-cloud-platform/semgrep-api/#tag__badge-list)を参照してください。 diff --git a/docs/content/connectors/toolreference/semgrep.md b/docs/content/connectors/toolreference/semgrep.md new file mode 100644 index 00000000000..b544bb9ea68 Binary files /dev/null and b/docs/content/connectors/toolreference/semgrep.md differ diff --git a/docs/content/connectors/toolreference/servicedesk_plus.de.md b/docs/content/connectors/toolreference/servicedesk_plus.de.md new file mode 100644 index 00000000000..5ae32ae8c38 --- /dev/null +++ b/docs/content/connectors/toolreference/servicedesk_plus.de.md @@ -0,0 +1,69 @@ +--- +title: "ServiceDesk Plus" +description: "Einrichtung des ServiceDesk Plus Downstream-Connectors für DefectDojo" +weight: 119 +audience: pro +--- +Die Integration mit ManageEngine ServiceDesk Plus ermöglicht es Ihnen, DefectDojo-Befunde und Befundgruppen als ServiceDesk-Plus-Requests zu übertragen, die einer Support-Gruppe Ihrer Wahl zugewiesen werden. Sowohl die **Cloud**-Edition (ServiceDesk Plus OnDemand) als auch die **On-Premises**-Edition werden von derselben Integration unterstützt - die Anmeldedaten, die Sie angeben, bestimmen, welcher Modus verwendet wird. + +### Instanz-Einrichtung + +- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf Ihre ServiceDesk-Plus-URL gesetzt werden: `https://sdpondemand.manageengine.com` für die Cloud-Edition (oder Ihr regionales Äquivalent) beziehungsweise die Adresse Ihres Servers bei On-Premises-Installationen. + +Geben Sie dann **einen** der beiden Anmeldedatensätze an: + +#### On-Premises: Technician Key + +- **Technician Key** sollte ein API-Key sein, der für einen Techniker auf Ihrem Server unter **Admin > General Settings > API** generiert wurde. Lassen Sie die Zoho-OAuth-Felder leer. + +#### Cloud: Zoho OAuth + +Die Cloud-Edition authentifiziert sich über Zoho Accounts OAuth: + +1. Öffnen Sie die [Zoho API Console](https://api-console.zoho.com/) und erstellen Sie einen **Self Client**. +2. Notieren Sie sich die **Client ID** und das **Client Secret**. +3. Geben Sie im Tab „Generate Code“ des Self Client den Scope `SDPOnDemand.requests.ALL` ein, wählen Sie eine Dauer und generieren Sie den Code. +4. Tauschen Sie den Code gegen ein Refresh-Token: + +``` +curl --request POST \ + --url 'https://accounts.zoho.com/oauth/v2/token' \ + --data 'grant_type=authorization_code' \ + --data 'client_id={{CLIENT_ID}}' \ + --data 'client_secret={{CLIENT_SECRET}}' \ + --data 'code={{GENERATED_CODE}}' +``` + +5. Geben Sie die **Client ID**, das **Client Secret** und das zurückgegebene **Refresh Token** im Instanzformular ein. Wird Ihr Konto außerhalb des US-Rechenzentrums gehostet, setzen Sie die **Token URL** auf Ihren regionalen Zoho-Accounts-Endpunkt (zum Beispiel `https://accounts.zoho.eu/oauth/v2/token`). + +### Issue-Tracker-Zuordnung + +- **Group Name** sollte der Name der ServiceDesk-Plus-Support-Gruppe sein, der Requests zugewiesen werden, genau so, wie er unter **Admin > Users > Support Groups** erscheint. + +### Details zur Schweregrad-Zuordnung + +Dies wird dem ServiceDesk-Plus-Request-Feld **Priority** anhand des Namens zugeordnet, unter Verwendung der Prioritätsnamen Ihres Kontos: + +- **Name des Schweregrad-Felds**: `Priority` +- **Info-Zuordnung**: `Low` +- **Niedrig-Zuordnung**: `Normal` +- **Mittel-Zuordnung**: `Medium` +- **Hoch-Zuordnung**: `High` +- **Kritisch-Zuordnung**: `High` + +### Details zur Status-Zuordnung + +Dies wird dem Request-Feld **Status** anhand des Namens zugeordnet. Die Standardwerte verwenden die integrierten Status: + +- **Name des Status-Felds**: `Status` +- **Aktiv-Zuordnung**: `Open` +- **Geschlossen-Zuordnung**: `Closed` +- **Falsch-positiv-Zuordnung**: `Closed` +- **Risiko-akzeptiert-Zuordnung**: `On Hold` + +Einige ServiceDesk-Plus-spezifische Verhaltensweisen, die Sie kennen sollten: + +- Aktualisierungen synchronisieren den vollständigen Request-Inhalt - anders als die meisten Tracker erlaubt ServiceDesk Plus es, Betreff und Beschreibung nach dem Erstellen zu bearbeiten. +- Requests werden geschlossen und nicht gelöscht, wenn ein Befund entfernt wird; Requests, die bereits Closed oder Resolved sind, bleiben unberührt. +- Macht Ihr Konto beim Schließen Felder zwingend erforderlich (zum Beispiel eine Lösung), kann ein von DefectDojo angestoßenes Schließen von diesen Regeln abgewiesen werden und erscheint dann in der Fehlertabelle der Integration. diff --git a/docs/content/connectors/toolreference/servicedesk_plus.es.md b/docs/content/connectors/toolreference/servicedesk_plus.es.md new file mode 100644 index 00000000000..23699c7dd20 --- /dev/null +++ b/docs/content/connectors/toolreference/servicedesk_plus.es.md @@ -0,0 +1,69 @@ +--- +title: "ServiceDesk Plus" +description: "Cómo configurar el Conector Downstream de ServiceDesk Plus para DefectDojo" +weight: 119 +audience: pro +--- +La integración con ManageEngine ServiceDesk Plus le permite enviar los Hallazgos y Grupos de Hallazgos de DefectDojo como solicitudes (requests) de ServiceDesk Plus, asignadas a un Group de soporte de su elección. La misma integración admite tanto la edición **cloud** (ServiceDesk Plus OnDemand) como la **on-premises**; las credenciales que proporcione determinan qué modo se usa. + +### Configuración de la instancia + +- **Label** debe ser la etiqueta que desee usar para identificar esta integración. +- **Location** debe configurarse con su URL de ServiceDesk Plus: `https://sdpondemand.manageengine.com` para la edición cloud (o su equivalente regional), o la dirección de su servidor para instalaciones on-premises. + +Luego proporcione **uno** de los dos conjuntos de credenciales: + +#### On-premises: Technician Key + +- **Technician Key** debe ser una clave de API generada para un técnico en su servidor, en **Admin > General Settings > API**. Deje vacíos los campos de OAuth de Zoho. + +#### Cloud: Zoho OAuth + +La edición cloud se autentica mediante Zoho Accounts OAuth: + +1. Abra la [Zoho API Console](https://api-console.zoho.com/) y cree un **Self Client**. +2. Anote el **Client ID** y el **Client Secret**. +3. En la pestaña "Generate Code" del Self Client, introduzca el alcance `SDPOnDemand.requests.ALL`, elija una duración y genere el código. +4. Intercambie el código por un refresh token: + +``` +curl --request POST \ + --url 'https://accounts.zoho.com/oauth/v2/token' \ + --data 'grant_type=authorization_code' \ + --data 'client_id={{CLIENT_ID}}' \ + --data 'client_secret={{CLIENT_SECRET}}' \ + --data 'code={{GENERATED_CODE}}' +``` + +5. Introduzca el **Client ID**, el **Client Secret** y el **Refresh Token** obtenido en el formulario de la instancia. Si su cuenta está alojada fuera del centro de datos de EE. UU., configure **Token URL** con el endpoint regional de Zoho Accounts correspondiente (por ejemplo, `https://accounts.zoho.eu/oauth/v2/token`). + +### Mapeo del sistema de tickets + +- **Group Name** debe ser el nombre del grupo de soporte de ServiceDesk Plus al que se asignarán las solicitudes, exactamente como aparece en **Admin > Users > Support Groups**. + +### Detalles del mapeo de severidad + +Esto se corresponde con el campo **Priority** de la solicitud de ServiceDesk Plus por nombre, usando los nombres de prioridad de su cuenta: + +- **Nombre del campo de severidad**: `Priority` +- **Mapeo de Informativa**: `Low` +- **Mapeo de Baja**: `Normal` +- **Mapeo de Media**: `Medium` +- **Mapeo de Alta**: `High` +- **Mapeo de Crítica**: `High` + +### Detalles del mapeo de estado + +Esto se corresponde con el campo **Status** de la solicitud por nombre. Los valores predeterminados usan los estados integrados: + +- **Nombre del campo de estado**: `Status` +- **Mapeo de Activo**: `Open` +- **Mapeo de Cerrado**: `Closed` +- **Mapeo de Falso positivo**: `Closed` +- **Mapeo de Riesgo aceptado**: `On Hold` + +Algunos comportamientos específicos de ServiceDesk Plus que debe tener en cuenta: + +- Las actualizaciones sincronizan el contenido completo de la solicitud: a diferencia de la mayoría de los sistemas de tickets, ServiceDesk Plus permite editar el asunto y la descripción después de la creación. +- Las solicitudes se cierran en lugar de eliminarse cuando se elimina un Hallazgo; las solicitudes ya Closed o Resolved se dejan sin modificar. +- Si su cuenta hace obligatorios ciertos campos al cerrar (por ejemplo, una resolución), un cierre enviado desde DefectDojo puede ser rechazado por esas reglas y aparecerá en la tabla de errores de la integración. diff --git a/docs/content/connectors/toolreference/servicedesk_plus.fr.md b/docs/content/connectors/toolreference/servicedesk_plus.fr.md new file mode 100644 index 00000000000..79a44a4e89e --- /dev/null +++ b/docs/content/connectors/toolreference/servicedesk_plus.fr.md @@ -0,0 +1,69 @@ +--- +title: "ServiceDesk Plus" +description: "Comment configurer le Connecteur Downstream ServiceDesk Plus pour DefectDojo" +weight: 119 +audience: pro +--- +L'intégration ManageEngine ServiceDesk Plus vous permet de pousser les Constatations et Groupes de constatations DefectDojo sous forme de requests ServiceDesk Plus, affectées à un Group de support de votre choix. Les éditions **cloud** (ServiceDesk Plus OnDemand) et **on-premises** sont toutes deux prises en charge par la même intégration - les identifiants que vous fournissez déterminent le mode utilisé. + +### Configuration de l'instance + +- **Label** doit être l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur votre URL ServiceDesk Plus : `https://sdpondemand.manageengine.com` pour l'édition cloud (ou son équivalent régional), ou l'adresse de votre serveur pour les installations on-premises. + +Fournissez ensuite **un seul** des deux jeux d'identifiants : + +#### On-premises : Technician Key + +- **Technician Key** doit être une clé API générée pour un technicien sur votre serveur, sous **Admin > General Settings > API**. Laissez vides les champs Zoho OAuth. + +#### Cloud : Zoho OAuth + +L'édition cloud s'authentifie via Zoho Accounts OAuth : + +1. Ouvrez la [Zoho API Console](https://api-console.zoho.com/) et créez un **Self Client**. +2. Notez le **Client ID** et le **Client Secret**. +3. Dans l'onglet « Generate Code » du Self Client, saisissez le scope `SDPOnDemand.requests.ALL`, choisissez une durée, puis générez le code. +4. Échangez le code contre un jeton d'actualisation : + +``` +curl --request POST \ + --url 'https://accounts.zoho.com/oauth/v2/token' \ + --data 'grant_type=authorization_code' \ + --data 'client_id={{CLIENT_ID}}' \ + --data 'client_secret={{CLIENT_SECRET}}' \ + --data 'code={{GENERATED_CODE}}' +``` + +5. Saisissez le **Client ID**, le **Client Secret** et le **Refresh Token** renvoyé dans le formulaire de l'instance. Si votre compte est hébergé en dehors du centre de données US, définissez **Token URL** sur le point de terminaison Zoho Accounts régional (par exemple `https://accounts.zoho.eu/oauth/v2/token`). + +### Correspondance du suivi des tickets + +- **Group Name** doit être le nom du groupe de support ServiceDesk Plus auquel les requests seront affectées, exactement comme il apparaît sous **Admin > Users > Support Groups**. + +### Détails de la correspondance des sévérités + +Ceci correspond, par nom, au champ **Priority** de la request ServiceDesk Plus, en utilisant les noms de priorité de votre compte : + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `Low` +- **Low Mapping**: `Normal` +- **Medium Mapping**: `Medium` +- **High Mapping**: `High` +- **Critical Mapping**: `High` + +### Détails de la correspondance des statuts + +Ceci correspond, par nom, au champ **Status** de la request. Les valeurs par défaut utilisent les statuts intégrés : + +- **Status Field Name**: `Status` +- **Active Mapping**: `Open` +- **Closed Mapping**: `Closed` +- **False Positive Mapping**: `Closed` +- **Risk Accepted Mapping**: `On Hold` + +Quelques comportements spécifiques à ServiceDesk Plus à connaître : + +- Les mises à jour synchronisent l'intégralité du contenu de la request - contrairement à la plupart des outils de suivi, ServiceDesk Plus permet de modifier l'objet et la description après la création. +- Les requests sont fermées plutôt que supprimées lorsqu'une Constatation est retirée ; les requests déjà Closed ou Resolved restent inchangées. +- Si votre compte rend certains champs obligatoires à la clôture (par exemple une résolution), une fermeture envoyée depuis DefectDojo peut être rejetée par ces règles et apparaîtra dans la table Integration errors. diff --git a/docs/content/connectors/toolreference/servicedesk_plus.ja.md b/docs/content/connectors/toolreference/servicedesk_plus.ja.md new file mode 100644 index 00000000000..c14c27b6a0a --- /dev/null +++ b/docs/content/connectors/toolreference/servicedesk_plus.ja.md @@ -0,0 +1,69 @@ +--- +title: "ServiceDesk Plus" +description: "DefectDojo で ServiceDesk Plus のダウンストリームコネクタをセットアップする方法" +weight: 119 +audience: pro +--- +ManageEngine ServiceDesk Plus 連携を使用すると、DefectDojo の検出事項および検出事項グループを ServiceDesk Plus のリクエストとしてプッシュし、任意の support Group に割り当てることができます。**クラウド版**(ServiceDesk Plus OnDemand)と **オンプレミス版** の両方が同じ連携でサポートされており、どちらのモードが使われるかは指定した認証情報によって決まります。 + +### インスタンスのセットアップ + +- **Label** には、この連携を識別するために使用したいラベルを設定します。 +- **Location** には、ServiceDesk Plus の URL を設定します。クラウド版の場合は `https://sdpondemand.manageengine.com`(またはお使いのリージョンに対応する URL)、オンプレミスインストールの場合はサーバーのアドレスを設定します。 + +続いて、以下の 2 種類の認証情報セットのうち **いずれか一方** を指定します。 + +#### オンプレミス: Technician Key + +- **Technician Key** には、サーバーの **Admin > General Settings > API** で技術者(Technician)向けに生成した API キーを設定します。Zoho OAuth の各フィールドは空欄のままにしてください。 + +#### クラウド: Zoho OAuth + +クラウド版は Zoho Accounts OAuth を通じて認証します。 + +1. [Zoho API Console](https://api-console.zoho.com/) を開き、**Self Client** を作成します。 +2. **Client ID** と **Client Secret** を控えておきます。 +3. Self Client の「Generate Code」タブで、スコープ `SDPOnDemand.requests.ALL` を入力し、有効期間を選択してコードを生成します。 +4. コードをリフレッシュトークンと交換します。 + +``` +curl --request POST \ + --url 'https://accounts.zoho.com/oauth/v2/token' \ + --data 'grant_type=authorization_code' \ + --data 'client_id={{CLIENT_ID}}' \ + --data 'client_secret={{CLIENT_SECRET}}' \ + --data 'code={{GENERATED_CODE}}' +``` + +5. インスタンスのフォームに **Client ID**、**Client Secret**、および取得した **Refresh Token** を入力します。アカウントが米国データセンター以外でホストされている場合は、**Token URL** をお使いのリージョンの Zoho Accounts エンドポイント(例: `https://accounts.zoho.eu/oauth/v2/token`)に設定してください。 + +### 課題管理マッピング + +- **Group Name** には、リクエストの割り当て先となる ServiceDesk Plus の support group の名前を、**Admin > Users > Support Groups** に表示されるとおりに設定します。 + +### 深刻度マッピングの詳細 + +これは、アカウントの優先度名を使用して、ServiceDesk Plus のリクエストの **Priority** フィールドに名前でマッピングされます。 + +- **深刻度フィールド名**: `Priority` +- **情報マッピング**: `Low` +- **低マッピング**: `Normal` +- **中マッピング**: `Medium` +- **高マッピング**: `High` +- **重大マッピング**: `High` + +### ステータスマッピングの詳細 + +これは、リクエストの **Status** フィールドに名前でマッピングされます。デフォルトでは組み込みのステータスを使用します。 + +- **ステータスフィールド名**: `Status` +- **アクティブマッピング**: `Open` +- **クローズマッピング**: `Closed` +- **誤検知マッピング**: `Closed` +- **リスク受容済みマッピング**: `On Hold` + +ServiceDesk Plus 固有の動作として、いくつか注意すべき点があります。 + +- 更新はリクエストの内容全体を同期します。多くのトラッカーとは異なり、ServiceDesk Plus では作成後に件名と説明を編集できます。 +- 検出事項が削除されると、リクエストは削除されるのではなくクローズされます。既に Closed または Resolved になっているリクエストはそのままにされます。 +- アカウント側でクローズ時にフィールド(たとえば resolution)を必須にしている場合、DefectDojo からプッシュされたクローズがそのルールによって拒否されることがあり、その場合は Integration errors テーブルに表示されます。 diff --git a/docs/content/connectors/toolreference/servicedesk_plus.md b/docs/content/connectors/toolreference/servicedesk_plus.md new file mode 100644 index 00000000000..479c6cfec1a --- /dev/null +++ b/docs/content/connectors/toolreference/servicedesk_plus.md @@ -0,0 +1,69 @@ +--- +title: "ServiceDesk Plus" +description: "How to set up the ServiceDesk Plus Downstream Connector for DefectDojo" +weight: 119 +audience: pro +--- +The ManageEngine ServiceDesk Plus Integration allows you to push DefectDojo Findings and Finding Groups as ServiceDesk Plus requests, assigned to a support Group of your choice. Both the **cloud** (ServiceDesk Plus OnDemand) and **on-premises** editions are supported by the same integration - the credentials you provide determine which mode is used. + +### Instance Setup + +- **Label** should be the label that you want to use to identify this integration. +- **Location** should be set to your ServiceDesk Plus URL: `https://sdpondemand.manageengine.com` for the cloud edition (or your regional equivalent), or your server's address for on-premises installs. + +Then provide **one** of the two credential sets: + +#### On-premises: Technician Key + +- **Technician Key** should be an API key generated for a technician on your server, under **Admin > General Settings > API**. Leave the Zoho OAuth fields empty. + +#### Cloud: Zoho OAuth + +The cloud edition authenticates through Zoho Accounts OAuth: + +1. Open the [Zoho API Console](https://api-console.zoho.com/) and create a **Self Client**. +2. Note the **Client ID** and **Client Secret**. +3. In the Self Client's "Generate Code" tab, enter the scope `SDPOnDemand.requests.ALL`, choose a duration, and generate the code. +4. Exchange the code for a refresh token: + +``` +curl --request POST \ + --url 'https://accounts.zoho.com/oauth/v2/token' \ + --data 'grant_type=authorization_code' \ + --data 'client_id={{CLIENT_ID}}' \ + --data 'client_secret={{CLIENT_SECRET}}' \ + --data 'code={{GENERATED_CODE}}' +``` + +5. Enter the **Client ID**, **Client Secret**, and the returned **Refresh Token** in the instance form. If your account is hosted outside the US data center, set **Token URL** to your regional Zoho Accounts endpoint (for example `https://accounts.zoho.eu/oauth/v2/token`). + +### Issue Tracker Mapping + +- **Group Name** should be the name of the ServiceDesk Plus support group requests will be assigned to, exactly as it appears under **Admin > Users > Support Groups**. + +### Severity Mapping Details + +This maps to the ServiceDesk Plus request **Priority** field by name, using your account's priority names: + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `Low` +- **Low Mapping**: `Normal` +- **Medium Mapping**: `Medium` +- **High Mapping**: `High` +- **Critical Mapping**: `High` + +### Status Mapping Details + +This maps to the request **Status** field by name. The defaults use the built-in statuses: + +- **Status Field Name**: `Status` +- **Active Mapping**: `Open` +- **Closed Mapping**: `Closed` +- **False Positive Mapping**: `Closed` +- **Risk Accepted Mapping**: `On Hold` + +A few ServiceDesk Plus-specific behaviors to be aware of: + +- Updates sync the full request content - unlike most trackers, ServiceDesk Plus allows the subject and description to be edited after creation. +- Requests are closed rather than deleted when a Finding is removed; requests already Closed or Resolved are left untouched. +- If your account makes fields mandatory on closure (for example a resolution), a close pushed from DefectDojo may be rejected by those rules and will appear in the Integration errors table. diff --git a/docs/content/connectors/toolreference/servicenow.de.md b/docs/content/connectors/toolreference/servicenow.de.md new file mode 100644 index 00000000000..c252c286f8c --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow.de.md @@ -0,0 +1,112 @@ +--- +title: "ServiceNow" +description: "Einrichtung des ServiceNow Downstream-Connectors für DefectDojo" +weight: 120 +audience: pro +--- +Die ServiceNow-Integration ermöglicht es Ihnen, DefectDojo-Befunde als ServiceNow-Incidents zu übertragen. + +### Instanz-Einrichtung + +DefectDojo authentifiziert sich bei ServiceNow über OAuth 2.0. Wie Sie die OAuth-Anmeldedaten erstellen, hängt von Ihrem ServiceNow-Release ab – neuere Releases (Zurich und später) verwenden einen Client-Credentials-Grant, frühere Releases ein Refresh-Token. + +#### ServiceNow Zurich und später (Client Credentials) + +In neueren ServiceNow-Releases wurde die klassische Option „Create an OAuth API endpoint for external clients“ zugunsten der **New Inbound Integration Experience** abgekündigt, die einen an ein Servicekonto gebundenen OAuth-**Client-Credentials**-Grant ausgibt: + +1. Suchen Sie in der linken Navigationsleiste nach „Application Registry“ und wählen Sie den Eintrag aus. +2. Klicken Sie auf **New** und wählen Sie dann **New Inbound Integration Experience**. +3. Wählen Sie **New Integration → OAuth - Client credentials grant**. +4. Setzen Sie den **OAuth Application User** auf das Servicekonto, das die Incidents erstellen wird. Die Rollen dieses Kontos bestimmen, was DefectDojo schreiben darf. +5. Speichern Sie die Registrierung. ServiceNow generiert **Client ID** und **Client Secret** automatisch (lassen Sie diese Felder beim Erstellen der Registrierung leer). + +Anschließend in DefectDojo: + +- **Instance Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf die URL Ihres ServiceNow-Servers gesetzt werden, zum Beispiel `https://your-organization.service-now.com/`. +- **Client ID** sollte die Client ID aus der OAuth-Registrierung sein. +- **Client Secret** sollte das Client Secret aus der OAuth-Registrierung sein. + +Lassen Sie die Felder Refresh Token, Username und Password leer – DefectDojo fordert für jede Synchronisierung ein frisches Client-Credentials-Token an. + +#### Frühere ServiceNow-Releases (Refresh-Token) + +Bei Releases, die noch die klassische Registrierung anbieten, benötigen Sie ein Refresh-Token, das dem Benutzer- oder Servicekonto zugeordnet ist, das Incidents an ServiceNow überträgt: + +1. Suchen Sie in der linken Navigationsleiste nach „Application Registry“ und wählen Sie den Eintrag aus. +2. Klicken Sie auf „New“. +3. Wählen Sie „Create an OAuth API endpoint for external clients“. +4. Füllen Sie die erforderlichen Felder aus: + * Name: Geben Sie Ihrer Anwendung einen sinnvollen Namen (z. B. Vulnerability Integration Client). + * (Optional) Passen Sie die Token-Lebensdauer an: + * Access Token Lifespan: Standard sind 1800 Sekunden (30 Minuten). + * Refresh Token Lifespan: Standard sind 8640000 Sekunden (etwa 100 Tage). +5. Klicken Sie auf „Submit“, um den Anwendungsdatensatz zu erstellen. +6. Wählen Sie die Anwendung nach dem Absenden aus der Liste aus und notieren Sie sich die Felder **Client ID und Client Secret**. + +Anschließend müssen Sie mit dieser Registrierung ein Refresh-Token beziehen, was nur über die ServiceNow-API möglich ist. Öffnen Sie ein Terminalfenster und fügen Sie Folgendes ein (ersetzen Sie dabei die in `{{}}` eingeschlossenen Variablen durch die tatsächlichen Angaben Ihres Benutzers) + +``` +curl --request POST \ + --url {{INSTANCE_HOST}}/oauth_token.do \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data grant_type=password \ + --data 'client_id={{CLIENT_ID}}' \ + --data 'client_secret={{CLIENT_SECRET}}' \ + --data 'username={{USERNAME}}' \ + --data 'password={{PASSWORD}}' + ``` + +Wenn Ihre ServiceNow-Anmeldedaten korrekt sind und Zugriff auf Administratorebene in ServiceNow erlauben, sollten Sie eine Antwort mit einem RefreshToken erhalten. Dieses Token benötigen Sie, um die Integration mit DefectDojo abzuschließen. + +- **Instance Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf die URL Ihres ServiceNow-Servers gesetzt werden, zum Beispiel `https://your-organization.service-now.com/`. +- **Refresh Token** ist das Feld, in das das Refresh-Token eingetragen wird. +- **Client ID** sollte die in der OAuth-App-Registrierung festgelegte Client ID sein. +- **Client Secret** sollte das in der OAuth-App-Registrierung festgelegte Client Secret sein. + +### Details zur Schweregrad-Zuordnung + +Dies wird dem ServiceNow-Feld „Impact“ zugeordnet. +- **Info-Zuordnung**: `1` +- **Niedrig-Zuordnung**: `1` +- **Mittel-Zuordnung**: `2` +- **Hoch-Zuordnung**: `3` +- **Kritisch-Zuordnung**: `3` + +### Details zur Status-Zuordnung + +- **Name des Status-Felds**: `State` +- **Aktiv-Zuordnung**: `New` +- **Geschlossen-Zuordnung**: `Closed` +- **Falsch-positiv-Zuordnung**: `Resolved` +- **Risiko-akzeptiert-Zuordnung**: `Resolved` + +Jede Zuordnung akzeptiert eine Standard-Statusbezeichnung (`New`, `In Progress`, `On Hold`, `Resolved`, `Closed`, `Cancelled`) oder einen numerischen Statuswert. Auf Instanzen mit angepassten Incident-Status – oder wenn eine andere Tabelle als `incident` das Ziel ist – verwenden Sie den numerischen **Statuswert** aus der Auswahlliste Ihrer Instanz; ein numerischer Wert außerhalb des Standardsatzes wird genau so an ServiceNow gesendet, wie er konfiguriert ist. Der integrierte Standardwert für den Resolution-Code begleitet nur die Standardstatus „resolved“/„closed“; kombinieren Sie benutzerdefinierte Statuswerte daher mit den unten beschriebenen Zuordnungen für Abschluss- und Resolution-Felder. + +### Abschluss- und Resolution-Felder + +Manche ServiceNow-Instanzen erzwingen eine Data Policy, die Felder wie den **Resolution code** (`close_code`) zwingend erforderlich macht, sobald ein Incident in einen aufgelösten oder geschlossenen Status wechselt. Schließt DefectDojo einen Incident ohne diese Felder, weist ServiceNow den Schreibvorgang mit HTTP 403 *„Data Policy Exception“* zurück, und der Grund wird in der Fehleransicht der Integration festgehalten. + +Hängen Sie die erforderlichen Felder mit **Custom Field Mappings** an den Statuswechsel an und setzen Sie **Apply On** auf die Disposition, die sie tragen soll: + +- **Transition to Closed** – wird gesendet, wenn ein Befund behoben/geschlossen wird. +- **Transition to False Positive** – wird gesendet, wenn ein Befund als Falsch-positiv markiert wird. +- **Transition to Risk Accepted** – wird gesendet, wenn für einen Befund das Risiko akzeptiert wird. + +Um zum Beispiel einen zwingend erforderlichen Resolution code zu erfüllen: + +| Source | Field Name | Value | Apply On | +|---|---|---|---| +| Static | `close_code` | `Resolved by DefectDojo` | Transition to Closed | +| Static | `close_notes` | `Reviewed by the security team` | Transition to Closed | +| Static | `close_code` | `Not a defect` | Transition to False Positive | + +Hinweise: + +- Field Name ist der ServiceNow-Spaltenname – `close_code`, `close_notes` oder ein benutzerdefiniertes `u_...`-Feld. +- Übergangszuordnungen greifen, wenn sich der Status des Datensatzes tatsächlich ändert: bei einem Befund, der beim ersten Übertragen bereits geschlossen ist, bei einer Aktualisierung, die den Datensatz schließt oder wieder öffnet, und beim erzwungenen Schließen, wenn eine Ticket-Verknüpfung gelöscht wird. Sie werden bei routinemäßigen Aktualisierungen eines unveränderten Datensatzes nicht erneut gesendet, sodass Journalfelder wie `work_notes` pro Übergang einen Eintrag erhalten. +- Referenzfelder wie `assignment_group` und `assigned_to` erwarten eine **sys_id** und keinen Anzeigenamen. +- Werte, die als JSON interpretierbar sind, werden typisiert gesendet: `true`, `42`, `[...]`, `{...}` – und `null`, wodurch das Feld geleert wird. Um solchen Text als wörtliche Zeichenkette zu senden, schließen Sie ihn in doppelte Anführungszeichen ein (z. B. `"null"`). +- `short_description`, `description`, `state`, `impact`, `urgency` und `priority` gehören zur Beschreibungsvorlage und zu den Schweregrad-/Status-Zuordnungen und können daher nicht über eine Zuordnung benutzerdefinierter Felder gesetzt werden. +- Auf anderen Tabellen als `incident` werden Statuswerte, die dem Standardsatz für Incidents entsprechen (`1`, `2`, `3`, `6`, `7`, `8`), weiterhin mit Incident-Semantik interpretiert – einschließlich des automatischen Standard-Resolution-Codes bei `6`/`7`/`8`. Bevorzugen Sie auf benutzerdefinierten Tabellen Statuswerte außerhalb dieses Bereichs, oder geben Sie die Abschlussfelder wie oben beschrieben explizit an. diff --git a/docs/content/connectors/toolreference/servicenow.es.md b/docs/content/connectors/toolreference/servicenow.es.md new file mode 100644 index 00000000000..7656b83c8fd --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow.es.md @@ -0,0 +1,112 @@ +--- +title: "ServiceNow" +description: "Cómo configurar el Conector Downstream de ServiceNow para DefectDojo" +weight: 120 +audience: pro +--- +La integración con ServiceNow le permite enviar los Hallazgos de DefectDojo como Incidentes de ServiceNow. + +### Configuración de la instancia + +DefectDojo se autentica ante ServiceNow mediante OAuth 2.0. La forma de crear las credenciales de OAuth depende de la versión de ServiceNow: las versiones más recientes (Zurich y posteriores) usan una concesión de Client Credentials, mientras que las versiones anteriores usan un token de actualización (refresh token). + +#### ServiceNow Zurich y posteriores (client credentials) + +Las versiones recientes de ServiceNow han descontinuado la opción clásica "Create an OAuth API endpoint for external clients" en favor de la **New Inbound Integration Experience**, que emite una concesión OAuth de **Client Credentials** vinculada a una cuenta de servicio: + +1. En la barra de navegación izquierda, busque "Application Registry" y selecciónela. +2. Haga clic en **New** y luego elija **New Inbound Integration Experience**. +3. Seleccione **New Integration → OAuth - Client credentials grant**. +4. Configure **OAuth Application User** con la cuenta de servicio que creará los Incidentes. Los roles de esa cuenta determinan lo que DefectDojo puede escribir. +5. Guarde el registro. ServiceNow genera automáticamente el **Client ID** y el **Client Secret** (deje esos campos en blanco al crear el registro). + +Luego, en DefectDojo: + +- **Instance Label** debe ser la etiqueta que desee usar para identificar esta integración. +- **Location** debe configurarse con la URL de su servidor ServiceNow, por ejemplo `https://your-organization.service-now.com/`. +- **Client ID** debe ser el Client ID del registro de OAuth. +- **Client Secret** debe ser el Client Secret del registro de OAuth. + +Deje vacíos los campos Refresh Token, Username y Password: DefectDojo solicita un token nuevo mediante client credentials en cada sincronización. + +#### Versiones anteriores de ServiceNow (refresh token) + +En las versiones que aún ofrecen el registro clásico, obtenga un Refresh Token asociado al Usuario o a la cuenta de servicio que enviará los Incidentes a ServiceNow: + +1. En la barra de navegación izquierda, busque "Application Registry" y selecciónela. +2. Haga clic en "New". +3. Elija "Create an OAuth API endpoint for external clients". +4. Complete los campos obligatorios: + * Name: proporcione un nombre significativo para su aplicación (por ejemplo, Vulnerability Integration Client). + * (Opcional) Ajuste la vigencia del token: + * Access Token Lifespan: el valor predeterminado es 1800 segundos (30 minutos). + * Refresh Token Lifespan: el valor predeterminado es 8640000 segundos (aproximadamente 100 días). +5. Haga clic en Submit para crear el registro de la aplicación. +6. Después de enviarlo, seleccione la aplicación en la lista y anote los campos **Client ID y Client Secret**. + +Luego deberá usar este registro para obtener un Refresh Token, que solo se puede obtener a través de la API de ServiceNow. Abra una ventana de terminal y pegue lo siguiente (sustituyendo las variables entre `{{}}` por la información real de su usuario) + +``` +curl --request POST \ + --url {{INSTANCE_HOST}}/oauth_token.do \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data grant_type=password \ + --data 'client_id={{CLIENT_ID}}' \ + --data 'client_secret={{CLIENT_SECRET}}' \ + --data 'username={{USERNAME}}' \ + --data 'password={{PASSWORD}}' + ``` + +Si sus credenciales de ServiceNow son correctas y permiten acceso de nivel administrador a ServiceNow, debería recibir una respuesta con un RefreshToken. Necesitará ese token para completar la integración con DefectDojo. + +- **Instance Label** debe ser la etiqueta que desee usar para identificar esta integración. +- **Location** debe configurarse con la URL de su servidor ServiceNow, por ejemplo `https://your-organization.service-now.com/`. +- **Refresh Token** es donde debe introducirse el Refresh Token. +- **Client ID** debe ser el Client ID configurado en el OAuth App Registration. +- **Client Secret** debe ser el Client Secret configurado en el OAuth App Registration. + +### Detalles del mapeo de severidad + +Esto se corresponde con el campo Impact de ServiceNow. +- **Mapeo de Informativa**: `1` +- **Mapeo de Baja**: `1` +- **Mapeo de Media**: `2` +- **Mapeo de Alta**: `3` +- **Mapeo de Crítica**: `3` + +### Detalles del mapeo de estado + +- **Nombre del campo de estado**: `State` +- **Mapeo de Activo**: `New` +- **Mapeo de Cerrado**: `Closed` +- **Mapeo de Falso positivo**: `Resolved` +- **Mapeo de Riesgo aceptado**: `Resolved` + +Cada mapeo acepta una etiqueta de estado estándar (`New`, `In Progress`, `On Hold`, `Resolved`, `Closed`, `Cancelled`) o un valor de estado numérico. En instancias con estados de Incidente personalizados, o cuando se apunta a una tabla distinta de `incident`, use el **valor de estado** numérico de la lista de opciones de su instancia; un valor numérico fuera del conjunto estándar se envía a ServiceNow exactamente como se configuró. El valor predeterminado integrado del código de resolución solo acompaña a los estados estándar de resuelto/cerrado, así que combine los valores de estado personalizados con los mapeos de campos de cierre y resolución que se describen a continuación. + +### Campos de cierre y resolución + +Algunas instancias de ServiceNow aplican una Data Policy que hace obligatorios campos como el **Resolution code** (`close_code`) cada vez que un Incidente pasa a un estado resuelto o cerrado. Si DefectDojo cierra un Incidente sin ellos, ServiceNow rechaza la escritura con un HTTP 403 *"Data Policy Exception"* y el motivo queda registrado en la vista de Errores de la integración. + +Asocie los campos requeridos al cambio de estado mediante **Custom Field Mappings**, configurando **Apply On** con la disposición que debe incluirlos: + +- **Transition to Closed**: se envía cuando un Hallazgo se mitiga o se cierra. +- **Transition to False Positive**: se envía cuando un Hallazgo se marca como falso positivo. +- **Transition to Risk Accepted**: se envía cuando un Hallazgo tiene el riesgo aceptado. + +Por ejemplo, para satisfacer un Resolution code obligatorio: + +| Source | Field Name | Value | Apply On | +|---|---|---|---| +| Static | `close_code` | `Resolved by DefectDojo` | Transition to Closed | +| Static | `close_notes` | `Reviewed by the security team` | Transition to Closed | +| Static | `close_code` | `Not a defect` | Transition to False Positive | + +Notas: + +- Field Name es el nombre de columna de ServiceNow: `close_code`, `close_notes`, o un campo personalizado `u_...`. +- Los mapeos de transición se disparan cuando el estado del registro realmente cambia: un Hallazgo que ya está cerrado cuando se envía por primera vez, una actualización que cierra o reabre el registro, y el cierre forzado cuando se elimina un enlace de ticket. No se vuelven a enviar en actualizaciones rutinarias de un registro sin cambios, por lo que los campos de bitácora como `work_notes` reciben una entrada por cada transición. +- Los campos de referencia como `assignment_group` y `assigned_to` esperan un **sys_id**, no un nombre para mostrar. +- Los valores que se interpretan como JSON se envían tipados: `true`, `42`, `[...]`, `{...}`, y `null`, que borra el campo. Para enviar ese texto como una cadena literal, enciérrelo entre comillas dobles (por ejemplo, `"null"`). +- `short_description`, `description`, `state`, `impact`, `urgency` y `priority` pertenecen a la plantilla de descripción y a los mapeos de severidad/estado, por lo que no se pueden configurar mediante un mapeo de campo personalizado. +- En tablas distintas de `incident`, los valores de estado que coinciden con el conjunto estándar de Incidente (`1`, `2`, `3`, `6`, `7`, `8`) se siguen interpretando con la semántica de Incidente, incluido el valor predeterminado automático de Resolution code en `6`/`7`/`8`. Prefiera valores de estado fuera de ese rango en tablas personalizadas, o proporcione explícitamente los campos de cierre como se indicó anteriormente. diff --git a/docs/content/connectors/toolreference/servicenow.fr.md b/docs/content/connectors/toolreference/servicenow.fr.md new file mode 100644 index 00000000000..eab796aa306 --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow.fr.md @@ -0,0 +1,112 @@ +--- +title: "ServiceNow" +description: "Comment configurer le Connecteur Downstream ServiceNow pour DefectDojo" +weight: 120 +audience: pro +--- +L'intégration ServiceNow vous permet de pousser les Constatations DefectDojo sous forme d'Incidents ServiceNow. + +### Configuration de l'instance + +DefectDojo s'authentifie auprès de ServiceNow via OAuth 2.0. La façon dont vous créez les identifiants OAuth dépend de votre version de ServiceNow — les versions récentes (Zurich et ultérieures) utilisent un octroi Client Credentials, tandis que les versions antérieures utilisent un jeton d'actualisation (refresh token). + +#### ServiceNow Zurich et versions ultérieures (client credentials) + +Les versions récentes de ServiceNow ont déprécié l'option classique « Create an OAuth API endpoint for external clients » au profit de la **New Inbound Integration Experience**, qui délivre un octroi OAuth **Client Credentials** lié à un compte de service : + +1. Dans la barre de navigation de gauche, recherchez « Application Registry » et sélectionnez-le. +2. Cliquez sur **New**, puis choisissez **New Inbound Integration Experience**. +3. Sélectionnez **New Integration → OAuth - Client credentials grant**. +4. Définissez **OAuth Application User** sur le compte de service qui créera les Incidents. Les rôles de ce compte déterminent ce que DefectDojo est autorisé à écrire. +5. Enregistrez l'inscription. ServiceNow génère automatiquement le **Client ID** et le **Client Secret** (laissez ces champs vides lors de la création de l'inscription). + +Ensuite, dans DefectDojo : + +- **Instance Label** doit être l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur l'URL de votre serveur ServiceNow, par exemple `https://your-organization.service-now.com/`. +- **Client ID** doit être le Client ID provenant de l'inscription OAuth. +- **Client Secret** doit être le Client Secret provenant de l'inscription OAuth. + +Laissez vides les champs Refresh Token, Username et Password — DefectDojo demande un nouveau jeton client-credentials à chaque synchronisation. + +#### Versions antérieures de ServiceNow (jeton d'actualisation) + +Sur les versions qui proposent encore l'inscription classique, obtenez un Refresh Token associé au compte Utilisateur ou de Service qui poussera les Incidents vers ServiceNow : + +1. Dans la barre de navigation de gauche, recherchez « Application Registry » et sélectionnez-le. +2. Cliquez sur « New ». +3. Choisissez « Create an OAuth API endpoint for external clients ». +4. Renseignez les champs requis : + * Name : indiquez un nom explicite pour votre application (par exemple, Vulnerability Integration Client). + * (Facultatif) Ajustez la durée de vie du jeton : + * Access Token Lifespan : la valeur par défaut est 1800 secondes (30 minutes). + * Refresh Token Lifespan : la valeur par défaut est 8640000 secondes (environ 100 jours). +5. Cliquez sur Submit pour créer l'enregistrement de l'application. +6. Après l'envoi, sélectionnez l'application dans la liste et notez les champs **Client ID and Client Secret**. + +Vous devrez ensuite utiliser cette inscription pour obtenir un Refresh Token, qui ne peut être obtenu que via l'API ServiceNow. Ouvrez une fenêtre de terminal et collez ce qui suit (en remplaçant les variables entourées de `{{}}` par les informations réelles de votre utilisateur) + +``` +curl --request POST \ + --url {{INSTANCE_HOST}}/oauth_token.do \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data grant_type=password \ + --data 'client_id={{CLIENT_ID}}' \ + --data 'client_secret={{CLIENT_SECRET}}' \ + --data 'username={{USERNAME}}' \ + --data 'password={{PASSWORD}}' + ``` + +Si vos identifiants ServiceNow sont corrects et permettent un accès de niveau administrateur à ServiceNow, vous devriez recevoir une réponse contenant un RefreshToken. Vous aurez besoin de ce jeton pour terminer l'intégration avec DefectDojo. + +- **Instance Label** doit être l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur l'URL de votre serveur ServiceNow, par exemple `https://your-organization.service-now.com/`. +- **Refresh Token** est l'endroit où le Refresh Token doit être saisi. +- **Client ID** doit être le Client ID défini dans l'OAuth App Registration. +- **Client Secret** doit être le Client Secret défini dans l'OAuth App Registration. + +### Détails de la correspondance des sévérités + +Ceci correspond au champ Impact de ServiceNow. +- **Info Mapping**: `1` +- **Low Mapping**: `1` +- **Medium Mapping**: `2` +- **High Mapping**: `3` +- **Critical Mapping**: `3` + +### Détails de la correspondance des statuts + +- **Status Field Name**: `State` +- **Active Mapping**: `New` +- **Closed Mapping**: `Closed` +- **False Positive Mapping**: `Resolved` +- **Risk Accepted Mapping**: `Resolved` + +Chaque correspondance accepte une étiquette d'état standard (`New`, `In Progress`, `On Hold`, `Resolved`, `Closed`, `Cancelled`) ou une valeur d'état numérique. Sur les instances dont les états d'Incident sont personnalisés — ou lorsque vous ciblez une table autre que `incident` — utilisez la **valeur d'état** numérique de la liste de choix de votre instance ; une valeur numérique en dehors de l'ensemble standard est envoyée à ServiceNow telle quelle. La valeur par défaut intégrée du code de résolution n'accompagne que les états résolu/fermé standard ; associez donc les valeurs d'état personnalisées aux correspondances de champs de clôture et de résolution ci-dessous. + +### Champs de clôture et de résolution + +Certaines instances ServiceNow appliquent une Data Policy qui rend obligatoires des champs tels que le **Resolution code** (`close_code`) dès qu'un Incident passe à un état résolu ou fermé. Si DefectDojo ferme un Incident sans ces champs, ServiceNow rejette l'écriture avec une erreur HTTP 403 *« Data Policy Exception »*, et la raison est enregistrée dans la vue Errors de l'intégration. + +Associez les champs requis au changement d'état avec **Custom Field Mappings**, en définissant **Apply On** sur la disposition qui doit les porter : + +- **Transition to Closed** — envoyé lorsqu'une Constatation est atténuée / fermée. +- **Transition to False Positive** — envoyé lorsqu'une Constatation est marquée comme faux positif. +- **Transition to Risk Accepted** — envoyé lorsqu'une Constatation fait l'objet d'une acceptation du risque. + +Par exemple, pour satisfaire un Resolution code obligatoire : + +| Source | Field Name | Value | Apply On | +|---|---|---|---| +| Static | `close_code` | `Resolved by DefectDojo` | Transition to Closed | +| Static | `close_notes` | `Reviewed by the security team` | Transition to Closed | +| Static | `close_code` | `Not a defect` | Transition to False Positive | + +Remarques : + +- Field Name est le nom de colonne ServiceNow — `close_code`, `close_notes`, ou un champ personnalisé `u_...`. +- Les correspondances de transition se déclenchent lorsque l'état de l'enregistrement change réellement : une Constatation déjà fermée lors de son premier envoi, une mise à jour qui ferme ou rouvre l'enregistrement, et la fermeture forcée lorsqu'un lien de ticket est supprimé. Elles ne sont pas renvoyées lors de mises à jour de routine d'un enregistrement inchangé ; les champs de journal tels que `work_notes` reçoivent donc une seule entrée par transition. +- Les champs de référence tels que `assignment_group` et `assigned_to` attendent un **sys_id**, et non un nom d'affichage. +- Les valeurs qui s'analysent comme du JSON sont envoyées typées : `true`, `42`, `[...]`, `{...}` — et `null`, qui efface le champ. Pour envoyer un tel texte comme chaîne littérale, entourez-le de guillemets doubles (par exemple `"null"`). +- `short_description`, `description`, `state`, `impact`, `urgency` et `priority` sont gérés par le modèle de description et par les correspondances de sévérité/statut ; ils ne peuvent donc pas être définis via une correspondance de champ personnalisée. +- Sur les tables autres que `incident`, les valeurs d'état qui correspondent à l'ensemble Incident standard (`1`, `2`, `3`, `6`, `7`, `8`) sont tout de même interprétées avec la sémantique Incident — y compris la valeur par défaut automatique du Resolution code sur `6`/`7`/`8`. Privilégiez des valeurs d'état en dehors de cette plage sur les tables personnalisées, ou fournissez explicitement les champs de clôture comme ci-dessus. diff --git a/docs/content/connectors/toolreference/servicenow.ja.md b/docs/content/connectors/toolreference/servicenow.ja.md new file mode 100644 index 00000000000..d76d255649a --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow.ja.md @@ -0,0 +1,112 @@ +--- +title: "ServiceNow" +description: "DefectDojo で ServiceNow のダウンストリームコネクタをセットアップする方法" +weight: 120 +audience: pro +--- +ServiceNow 連携を使用すると、DefectDojo の検出事項を ServiceNow のインシデントとしてプッシュできます。 + +### インスタンスのセットアップ + +DefectDojo は OAuth 2.0 経由で ServiceNow に認証します。OAuth 認証情報の作成方法は ServiceNow のリリースによって異なります。新しいリリース(Zurich 以降)ではクライアントクレデンシャルグラントを使用し、それより前のリリースではリフレッシュトークンを使用します。 + +#### ServiceNow Zurich 以降(クライアントクレデンシャル) + +最近の ServiceNow リリースでは、従来の「外部クライアント用の OAuth API エンドポイントの作成」オプションは非推奨となり、代わりに **新しいインバウンド統合エクスペリエンス(New Inbound Integration Experience)** が採用されています。これはサービスアカウントに紐づいた OAuth **クライアントクレデンシャル** グラントを発行します。 + +1. 左側のナビゲーションバーで「Application Registry」を検索して選択します。 +2. **New** をクリックし、**New Inbound Integration Experience** を選択します。 +3. **New Integration → OAuth - Client credentials grant** を選択します。 +4. **OAuth Application User** に、インシデントを作成するサービスアカウントを設定します。このアカウントのロールによって、DefectDojo が書き込める内容が決まります。 +5. 登録を保存します。ServiceNow が **Client ID** と **Client Secret** を自動生成します(登録作成時にはこれらのフィールドを空欄のままにしてください)。 + +その後、DefectDojo 側で以下を設定します。 + +- **Instance Label** には、この連携を識別するために使用したいラベルを設定します。 +- **Location** には、ServiceNow サーバーの URL を設定します。例: `https://your-organization.service-now.com/`。 +- **Client ID** には、OAuth 登録で取得した Client ID を設定します。 +- **Client Secret** には、OAuth 登録で取得した Client Secret を設定します。 + +Refresh Token、Username、Password の各フィールドは空欄のままにしてください。DefectDojo は同期のたびに新しいクライアントクレデンシャルトークンをリクエストします。 + +#### それ以前の ServiceNow リリース(リフレッシュトークン) + +従来の登録方式がまだ利用できるリリースでは、ServiceNow にインシデントをプッシュする User または Service アカウントに紐づいたリフレッシュトークンを取得します。 + +1. 左側のナビゲーションバーで「Application Registry」を検索して選択します。 +2. 「New」をクリックします。 +3. 「Create an OAuth API endpoint for external clients」を選択します。 +4. 必須フィールドを入力します。 + * Name: アプリケーションの分かりやすい名前を入力します(例: Vulnerability Integration Client)。 + * (任意)トークンの有効期間を調整します。 + * Access Token Lifespan: デフォルトは 1800 秒(30 分)です。 + * Refresh Token Lifespan: デフォルトは 8640000 秒(約 100 日)です。 +5. 「Submit」をクリックしてアプリケーションレコードを作成します。 +6. 送信後、リストからアプリケーションを選択し、**Client ID と Client Secret** フィールドを控えておきます。 + +次に、この登録を使用してリフレッシュトークンを取得する必要がありますが、これは ServiceNow API 経由でのみ取得できます。ターミナルウィンドウを開き、以下を貼り付けてください(`{{}}` で囲まれた変数は実際のユーザー情報に置き換えます)。 + +``` +curl --request POST \ + --url {{INSTANCE_HOST}}/oauth_token.do \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data grant_type=password \ + --data 'client_id={{CLIENT_ID}}' \ + --data 'client_secret={{CLIENT_SECRET}}' \ + --data 'username={{USERNAME}}' \ + --data 'password={{PASSWORD}}' + ``` + +ServiceNow の認証情報が正しく、ServiceNow への管理者レベルのアクセスが許可されている場合、RefreshToken を含むレスポンスが返されます。DefectDojo との連携を完了するには、そのトークンが必要です。 + +- **Instance Label** には、この連携を識別するために使用したいラベルを設定します。 +- **Location** には、ServiceNow サーバーの URL を設定します。例: `https://your-organization.service-now.com/`。 +- **Refresh Token** には、取得したリフレッシュトークンを入力します。 +- **Client ID** には、OAuth App Registration で設定した Client ID を設定します。 +- **Client Secret** には、OAuth App Registration で設定した Client Secret を設定します。 + +### 深刻度マッピングの詳細 + +これは ServiceNow の Impact フィールドにマッピングされます。 +- **情報マッピング**: `1` +- **低マッピング**: `1` +- **中マッピング**: `2` +- **高マッピング**: `3` +- **重大マッピング**: `3` + +### ステータスマッピングの詳細 + +- **ステータスフィールド名**: `State` +- **アクティブマッピング**: `New` +- **クローズマッピング**: `Closed` +- **誤検知マッピング**: `Resolved` +- **リスク受容済みマッピング**: `Resolved` + +各マッピングには、標準のステートラベル(`New`、`In Progress`、`On Hold`、`Resolved`、`Closed`、`Cancelled`)または数値のステート値を指定できます。インシデントのステートがカスタマイズされているインスタンス、または `incident` 以外のテーブルを対象とする場合は、インスタンスの選択リストにある数値の **ステート値** を使用してください。標準セット外の数値は、設定したとおりにそのまま ServiceNow へ送信されます。組み込みの Resolution コードのデフォルトは、標準の resolved/closed ステートにのみ付随するため、カスタムのステート値を使用する場合は、下記のクローズおよび解決フィールドのマッピングと組み合わせてください。 + +### クローズおよび解決フィールド + +一部の ServiceNow インスタンスでは、インシデントが resolved または closed ステートに移行する際に、**Resolution code**(`close_code`)などのフィールドを必須とする Data Policy が適用されています。これらのフィールドを指定せずに DefectDojo がインシデントをクローズしようとすると、ServiceNow は HTTP 403 の *「Data Policy Exception」* で書き込みを拒否し、その理由は連携のエラー表示に記録されます。 + +**Custom Field Mappings** を使用して、必須フィールドをステート変更に紐づけ、**Apply On** にそれらを適用すべき区分を設定します。 + +- **Transition to Closed** — 検出事項が緩和済み/クローズになったときに送信されます。 +- **Transition to False Positive** — 検出事項が誤検知としてマークされたときに送信されます。 +- **Transition to Risk Accepted** — 検出事項がリスク受容されたときに送信されます。 + +たとえば、必須の Resolution code を満たすには次のようにします。 + +| Source | Field Name | Value | Apply On | +|---|---|---|---| +| Static | `close_code` | `Resolved by DefectDojo` | Transition to Closed | +| Static | `close_notes` | `Reviewed by the security team` | Transition to Closed | +| Static | `close_code` | `Not a defect` | Transition to False Positive | + +注記: + +- Field Name は ServiceNow のカラム名です — `close_code`、`close_notes`、またはカスタムの `u_...` フィールドなど。 +- Transition マッピングは、レコードのステートが実際に変化したときに発火します。たとえば、最初にプッシュされた時点で既にクローズしている検出事項、レコードをクローズまたは再オープンする更新、チケットリンクが削除されたときの強制クローズなどです。変化のないレコードの通常の更新では再送信されないため、`work_notes` などのジャーナルフィールドには遷移ごとに 1 件のエントリが記録されます。 +- `assignment_group` や `assigned_to` などの参照フィールドには、表示名ではなく **sys_id** を指定する必要があります。 +- JSON として解釈できる値は、型付きで送信されます: `true`、`42`、`[...]`、`{...}` — および、フィールドをクリアする `null`。このようなテキストをリテラルの文字列として送信するには、二重引用符で囲みます(例: `"null"`)。 +- `short_description`、`description`、`state`、`impact`、`urgency`、`priority` は説明テンプレートおよび深刻度/ステータスのマッピングによって管理されるため、カスタムフィールドマッピングでは設定できません。 +- `incident` 以外のテーブルでも、標準のインシデントセットに一致するステート値(`1`、`2`、`3`、`6`、`7`、`8`)は、`6`/`7`/`8` での自動 Resolution コードのデフォルトを含め、引き続きインシデントの意味で解釈されます。カスタムテーブルではその範囲外のステート値を使用するか、上記のようにクローズフィールドを明示的に指定することを推奨します。 diff --git a/docs/content/connectors/toolreference/servicenow.md b/docs/content/connectors/toolreference/servicenow.md new file mode 100644 index 00000000000..732e21fe792 --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow.md @@ -0,0 +1,112 @@ +--- +title: "ServiceNow" +description: "How to set up the ServiceNow Downstream Connector for DefectDojo" +weight: 120 +audience: pro +--- +The ServiceNow Integration allows you to push DefectDojo Findings as ServiceNow Incidents. + +### Instance Setup + +DefectDojo authenticates to ServiceNow over OAuth 2.0. How you create the OAuth credentials depends on your ServiceNow release — newer releases (Zurich and later) use a Client Credentials grant, while earlier releases use a refresh token. + +#### ServiceNow Zurich and later (client credentials) + +Recent ServiceNow releases deprecated the classic "Create an OAuth API endpoint for external clients" option in favor of the **New Inbound Integration Experience**, which issues an OAuth **Client Credentials** grant bound to a service account: + +1. In the left-hand navigation bar, search for "Application Registry" and select it. +2. Click **New**, then choose **New Inbound Integration Experience**. +3. Select **New Integration → OAuth - Client credentials grant**. +4. Set the **OAuth Application User** to the service account that will create Incidents. That account's roles determine what DefectDojo is allowed to write. +5. Save the registration. ServiceNow auto-generates the **Client ID** and **Client Secret** (leave those fields blank when creating the registration). + +Then, in DefectDojo: + +- **Instance Label** should be the label that you want to use to identify this integration. +- **Location** should be set to the URL for your ServiceNow server, for example `https://your-organization.service-now.com/`. +- **Client ID** should be the Client ID from the OAuth registration. +- **Client Secret** should be the Client Secret from the OAuth registration. + +Leave the Refresh Token, Username, and Password fields empty — DefectDojo requests a fresh client-credentials token for each sync. + +#### Earlier ServiceNow releases (refresh token) + +On releases that still offer the classic registration, obtain a Refresh Token associated with the User or Service account that will push Incidents to ServiceNow: + +1. In the left-hand navigation bar, search for "Application Registry" and select it. +2. Click "New". +3. Choose "Create an OAuth API endpoint for external clients". +4. Fill in the required fields: + * Name: Provide a meaningful name for your application (e.g., Vulnerability Integration Client). + * (Optional) Adjust the Token Lifespan: + * Access Token Lifespan: Default is 1800 seconds (30 minutes). + * Refresh Token Lifespan: The default is 8640000 seconds (approximately 100 days). +5. Click Submit to create the application record. +6. After submission, select the application from the list and take note of the **Client ID and Client Secret** fields. + +You will then need to use this registration to obtain a Refresh Token, which can only be obtained through the ServiceNow API. Open a terminal window and paste the following (substituting the variables wrapped in `{{}}` with your user's actual information) + +``` +curl --request POST \ + --url {{INSTANCE_HOST}}/oauth_token.do \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data grant_type=password \ + --data 'client_id={{CLIENT_ID}}' \ + --data 'client_secret={{CLIENT_SECRET}}' \ + --data 'username={{USERNAME}}' \ + --data 'password={{PASSWORD}}' + ``` + +If your ServiceNow credentials are correct, and allow for admin level-access to ServiceNow, you should receive a response with a RefreshToken. You'll need that token to complete integration with DefectDojo. + +- **Instance Label** should be the label that you want to use to identify this integration. +- **Location** should be set to the URL for your ServiceNow server, for example `https://your-organization.service-now.com/`. +- **Refresh Token** is where the Refresh Token should be entered. +- **Client ID** should be the Client ID set in the OAuth App Registration. +- **Client Secret** should be the Client Secret set in the OAuth App Registration. + +### Severity Mapping Details + +This maps to the ServiceNow Impact field. +- **Info Mapping**: `1` +- **Low Mapping**: `1` +- **Medium Mapping**: `2` +- **High Mapping**: `3` +- **Critical Mapping**: `3` + +### Status Mapping Details + +- **Status Field Name**: `State` +- **Active Mapping**: `New` +- **Closed Mapping**: `Closed` +- **False Positive Mapping**: `Resolved` +- **Risk Accepted Mapping**: `Resolved` + +Each mapping accepts a standard state label (`New`, `In Progress`, `On Hold`, `Resolved`, `Closed`, `Cancelled`) or a numeric state value. On instances with customized Incident states — or when targeting a table other than `incident` — use the numeric **state value** from your instance's choice list; a numeric value outside the standard set is sent to ServiceNow exactly as configured. The built-in Resolution-code default only accompanies the standard resolved/closed states, so pair custom state values with the close and resolution field mappings below. + +### Close and resolution fields + +Some ServiceNow instances enforce a Data Policy that makes fields such as the **Resolution code** (`close_code`) mandatory whenever an Incident moves to a resolved or closed state. If DefectDojo closes an Incident without them, ServiceNow rejects the write with an HTTP 403 *"Data Policy Exception"* and the reason is recorded in the integration's Errors view. + +Attach the required fields to the state change with **Custom Field Mappings**, setting **Apply On** to the disposition that should carry them: + +- **Transition to Closed** — sent when a Finding is mitigated / closed. +- **Transition to False Positive** — sent when a Finding is marked a false positive. +- **Transition to Risk Accepted** — sent when a Finding is risk accepted. + +For example, to satisfy a mandatory Resolution code: + +| Source | Field Name | Value | Apply On | +|---|---|---|---| +| Static | `close_code` | `Resolved by DefectDojo` | Transition to Closed | +| Static | `close_notes` | `Reviewed by the security team` | Transition to Closed | +| Static | `close_code` | `Not a defect` | Transition to False Positive | + +Notes: + +- Field Name is the ServiceNow column name — `close_code`, `close_notes`, or a custom `u_...` field. +- Transition mappings fire when the record's state actually changes: a Finding that is already closed when first pushed, an update that closes or reopens the record, and the forced close when a ticket link is deleted. They are not re-sent on routine updates of an unchanged record, so journal fields such as `work_notes` receive one entry per transition. +- Reference fields such as `assignment_group` and `assigned_to` expect a **sys_id**, not a display name. +- Values that parse as JSON are sent typed: `true`, `42`, `[...]`, `{...}` — and `null`, which clears the field. To send such text as a literal string, wrap it in double quotes (e.g. `"null"`). +- `short_description`, `description`, `state`, `impact`, `urgency`, and `priority` are owned by the description template and the severity/status mappings, so they cannot be set through a custom field mapping. +- On tables other than `incident`, state values that match the standard Incident set (`1`, `2`, `3`, `6`, `7`, `8`) are still interpreted with Incident semantics — including the automatic Resolution code default on `6`/`7`/`8`. Prefer state values outside that range on custom tables, or supply the close fields explicitly as above. diff --git a/docs/content/connectors/toolreference/servicenow_cmdb.de.md b/docs/content/connectors/toolreference/servicenow_cmdb.de.md new file mode 100644 index 00000000000..d1c9283f766 --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow_cmdb.de.md @@ -0,0 +1,18 @@ +--- +title: "ServiceNow CMDB" +description: "Einrichtung des ServiceNow CMDB Upstream-Connectors für DefectDojo" +weight: 121 +audience: pro +--- +Der ServiceNow-CMDB-Connector ist ein **Asset-Connector**: Anstatt Befunde zu importieren, liest er Configuration Items (CIs) aus Ihrer ServiceNow Configuration Management Database und erstellt für jede CI ein DefectDojo-Asset, gruppiert in Organisationen nach CI-Klasse. Es werden keine Befunde importiert. + +#### Voraussetzungen + +Sie benötigen eine ServiceNow-Instanz und ein Konto, das die CMDB-Tabellen über die ServiceNow-Table-API lesen kann. Wir empfehlen ein dediziertes, schreibgeschütztes Service-Konto für DefectDojo. Das Konto benötigt Lesezugriff auf die zu importierenden `cmdb_ci`-Tabellen. + +#### Connector-Zuordnungen + +1. Geben Sie die URL Ihrer ServiceNow-Instanz in das Feld **Location** ein: `https://{your-instance}.service-now.com`. +2. Wählen oder erstellen Sie eine ServiceNow-**Tool Configuration**, die die Instanz-Anmeldedaten enthält (den ServiceNow-Benutzernamen und das Passwort). + +Jedes Configuration Item wird zu einem nach der CI benannten Eintrag, gruppiert nach seiner **CI-Klasse** (zum Beispiel Application, Server oder Business Service). Discovery und Sync gleichen die CI-Liste ab: Neue CIs erscheinen als `NEW`-Einträge, und eine aus der CMDB entfernte CI wird beim nächsten Sync als `MISSING` markiert, damit Ihr Team sie prüfen kann. DefectDojo löscht niemals stillschweigend ein Produkt. diff --git a/docs/content/connectors/toolreference/servicenow_cmdb.es.md b/docs/content/connectors/toolreference/servicenow_cmdb.es.md new file mode 100644 index 00000000000..463e3d6a13c --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow_cmdb.es.md @@ -0,0 +1,18 @@ +--- +title: "ServiceNow CMDB" +description: "Cómo configurar el Conector Upstream de ServiceNow CMDB para DefectDojo" +weight: 121 +audience: pro +--- +El conector de ServiceNow CMDB es un **conector de activos (Asset Connector)**: en lugar de importar hallazgos, lee Configuration Items (CI) de su ServiceNow Configuration Management Database y crea un Asset de DefectDojo para cada CI, agrupados en Organizations según su clase de CI. No se importa ningún hallazgo. + +#### Requisitos previos + +Necesitará una instancia de ServiceNow y una cuenta que pueda leer las tablas de CMDB a través de la ServiceNow Table API. Recomendamos una cuenta de servicio dedicada y de solo lectura para DefectDojo. La cuenta necesita acceso de lectura a las tablas `cmdb_ci` que desea importar. + +#### Asignaciones del conector + +1. Ingrese la URL de su instancia de ServiceNow en el campo **Location**: `https://{your-instance}.service-now.com`. +2. Seleccione o cree una **Tool Configuration** de ServiceNow que contenga las credenciales de la instancia (el nombre de usuario y la contraseña de ServiceNow). + +Cada Configuration Item se convierte en un Record con el nombre del CI, agrupado por su **clase de CI** (por ejemplo, aplicación, servidor o servicio de negocio). Discovery y Sync concilian la lista de CI: los CI nuevos aparecen como Records `NEW`, y un CI eliminado del CMDB se marca como `MISSING` en el siguiente Sync para que su equipo pueda triarlo. DefectDojo nunca elimina un Producto de forma silenciosa. diff --git a/docs/content/connectors/toolreference/servicenow_cmdb.fr.md b/docs/content/connectors/toolreference/servicenow_cmdb.fr.md new file mode 100644 index 00000000000..34cf1cb6c9d --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow_cmdb.fr.md @@ -0,0 +1,18 @@ +--- +title: "ServiceNow CMDB" +description: "Comment configurer le Connecteur Upstream ServiceNow CMDB pour DefectDojo" +weight: 121 +audience: pro +--- +Le connecteur ServiceNow CMDB est un **connecteur d'actifs** : au lieu d'importer des constatations, il lit les éléments de configuration (CI) de votre base de données de gestion de configuration ServiceNow et crée un Asset DefectDojo pour chaque CI, regroupé en Organizations par classe de CI. Aucune constatation n'est importée. + +#### Prérequis + +Vous aurez besoin d'une instance ServiceNow et d'un compte pouvant lire les tables CMDB via l'API Table de ServiceNow. Nous recommandons un compte de service dédié, en lecture seule, pour DefectDojo. Le compte a besoin d'un accès en lecture aux tables `cmdb_ci` que vous souhaitez importer. + +#### Correspondances du connecteur + +1. Saisissez l'URL de votre instance ServiceNow dans le champ **Location** : `https://{your-instance}.service-now.com`. +2. Sélectionnez ou créez une **Tool Configuration** ServiceNow contenant les identifiants de l'instance (le nom d'utilisateur et le mot de passe ServiceNow). + +Chaque élément de configuration devient un Record nommé d'après le CI, regroupé par sa **classe de CI** (par exemple, application, serveur, ou service métier). La Discovery et le Sync réconcilient la liste des CI : les nouveaux CI apparaissent comme des Records `NEW`, et un CI supprimé de la CMDB est marqué `MISSING` au Sync suivant afin que votre équipe puisse le trier. DefectDojo ne supprime jamais un Produit silencieusement. diff --git a/docs/content/connectors/toolreference/servicenow_cmdb.ja.md b/docs/content/connectors/toolreference/servicenow_cmdb.ja.md new file mode 100644 index 00000000000..f2d76a942ce --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow_cmdb.ja.md @@ -0,0 +1,18 @@ +--- +title: "ServiceNow CMDB" +description: "DefectDojo で ServiceNow CMDB の Upstream Connector をセットアップする方法" +weight: 121 +audience: pro +--- +ServiceNow CMDBコネクタは**アセットコネクタ**です: 検出事項をインポートする代わりに、お使いのServiceNow構成管理データベースからConfiguration Item (CI) を読み取り、各CIについてDefectDojoアセットを作成し、CIクラスごとにOrganizationにグループ化します。検出事項はインポートされません。 + +#### 前提条件 + +ServiceNowインスタンスと、ServiceNow Table API経由でCMDBテーブルを読み取れるアカウントが必要です。DefectDojo専用の読み取り専用サービスアカウントの利用をお勧めします。このアカウントには、インポートしたい `cmdb_ci` テーブルへの読み取りアクセス権が必要です。 + +#### Connector Mappings + +1. **Location** フィールドにServiceNowインスタンスのURLを入力します: `https://{your-instance}.service-now.com`。 +2. インスタンスの認証情報(ServiceNowのユーザー名とパスワード)を保持するServiceNowの**Tool Configuration**を選択または作成します。 + +各Configuration ItemがCIの名前を冠したRecordになり、その**CIクラス**(例: application、server、business serviceなど)でグループ化されます。DiscoveryとSyncはCIリストの差分を調整します: 新しいCIは `NEW` のRecordとして表示され、CMDBから削除されたCIは、チームがトリアージできるように次回のSyncで `MISSING` としてフラグが立てられます。DefectDojoが製品を黙って削除することはありません。 diff --git a/docs/content/connectors/toolreference/servicenow_cmdb.md b/docs/content/connectors/toolreference/servicenow_cmdb.md new file mode 100644 index 00000000000..a77e3168b2f --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow_cmdb.md @@ -0,0 +1,18 @@ +--- +title: "ServiceNow CMDB" +description: "How to set up the ServiceNow CMDB Upstream Connector for DefectDojo" +weight: 121 +audience: pro +--- +The ServiceNow CMDB connector is an **Asset Connector**: instead of importing findings, it reads Configuration Items (CIs) from your ServiceNow Configuration Management Database and creates a DefectDojo Asset for each CI, grouped into Organizations by CI class. No findings are imported. + +#### Prerequisites + +You will need a ServiceNow instance and an account that can read the CMDB tables over the ServiceNow Table API. We recommend a dedicated, read-only service account for DefectDojo. The account needs read access to the `cmdb_ci` tables you want to import. + +#### Connector Mappings + +1. Enter your ServiceNow instance URL in the **Location** field: `https://{your-instance}.service-now.com`. +2. Select or create a ServiceNow **Tool Configuration** holding the instance credentials (the ServiceNow username and password). + +Each Configuration Item becomes a Record named after the CI, grouped by its **CI class** (for example, application, server, or business service). Discovery and Sync reconcile the CI list: new CIs appear as `NEW` Records, and a CI removed from the CMDB is flagged `MISSING` on the next Sync so your team can triage it. DefectDojo never silently deletes an Asset. diff --git a/docs/content/connectors/toolreference/servicenow_secops.de.md b/docs/content/connectors/toolreference/servicenow_secops.de.md new file mode 100644 index 00000000000..bc5eccd1660 --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow_secops.de.md @@ -0,0 +1,54 @@ +--- +title: "ServiceNow SecOps" +description: "Einrichtung des ServiceNow SecOps Downstream-Connectors für DefectDojo" +weight: 122 +audience: pro +--- +Die ServiceNow-SecOps-Integration (auch bekannt als **ServiceNow SecOps / Vulnerability Response**) überträgt DefectDojo-Befunde und Befundgruppen in eine ServiceNow-Sicherheitstabelle – einen **Security Incident** (`sn_si_incident`) oder ein **Vulnerable Item** (`sn_vul_vulnerable_item`) – und hält den Datensatz synchron, während sich der Befund ändert (Erstellen, Aktualisieren und Auflösen/Schließen). Sie ist das Security-Operations-Gegenstück zur oben beschriebenen ServiceNow-Issue-Tracker-Integration; verwenden Sie ServiceNow SecOps, wenn Sie die Anwendungen Security Incident Response (SIR) oder Vulnerability Response (VR) einsetzen. + +### Instanz-Einrichtung + +- **Instance Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf die URL Ihres ServiceNow-Servers gesetzt werden, zum Beispiel `https://your-organization.service-now.com/`. + +ServiceNow SecOps unterstützt drei Authentifizierungsmethoden; geben Sie **eine** davon an: + +- **OAuth 2.0** – geben Sie eine **Client ID**, ein **Client Secret** und ein **Refresh Token** ein. Sie erhalten diese genau so, wie im Abschnitt [ServiceNow](/connectors/toolreference/servicenow/) oben beschrieben (erstellen Sie einen OAuth-API-Endpunkt in der Application Registry und tauschen Sie Ihre Anmeldedaten dann unter `/oauth_token.do` gegen ein Refresh-Token). Alternativ können Sie **Client ID** und **Client Secret** zusammen mit einem **Username** und **Password** angeben, um anstelle eines Refresh-Tokens den OAuth-Password-Grant zu verwenden. +- **API Key** – geben Sie einen **API Key** ein, der als Header `x-sn-apikey` gesendet wird. Der Key authentifiziert nichts, solange auf der Instanz kein Inbound Authentication Profile und keine REST API Access Policy daran angehängt sind. +- **HTTP Basic** – geben Sie **Username** und **Password** des Servicekontos ein. + +Das Servicekonto (oder der OAuth-Client) benötigt Schreibzugriff auf die Zieltabelle. + +### Issue-Tracker-Zuordnung + +- **Target Table** legt die ServiceNow-Tabelle fest, in die Datensätze geschrieben werden: **Security Incident** (`sn_si_incident`, der Standard) oder **Vulnerable Item** (`sn_vul_vulnerable_item`). + +### Details zur Schweregrad-Zuordnung + +Bei einem Security Incident wird dies dem Feld **Impact** zugeordnet; ServiceNow leitet die Incident-Priorität aus Impact und Urgency ab, sodass Urgency dem zugeordneten Impact folgt, sofern Sie sie nicht selbst zuordnen. Bei einem Vulnerable Item ordnen Sie den Schweregrad dem Risikofeld zu, das Ihre Instanz verwendet. Die Standardwerte unten entsprechen der Standard-SIR-Impact-Skala (`1` Hoch, `2` Mittel, `3` Niedrig) und sind bearbeitbar. + +- **Name des Schweregrad-Felds**: `impact` +- **Info-Zuordnung**: `3` +- **Niedrig-Zuordnung**: `3` +- **Mittel-Zuordnung**: `2` +- **Hoch-Zuordnung**: `1` +- **Kritisch-Zuordnung**: `1` + +### Details zur Status-Zuordnung + +Dies wird dem Feld **State** des Datensatzes zugeordnet. Statuswerte sind numerische Codes, die sich zwischen den Tabellen Security Incident und Vulnerable Item unterscheiden und pro Instanz angepasst werden können; prüfen Sie sie daher gegen Ihre eigene Konfiguration. Die Standardwerte unten verwenden die Standard-SIR-Statuscodes (`16` Analysis, `3` Closed). + +- **Name des Status-Felds**: `state` +- **Aktiv-Zuordnung**: `16` +- **Geschlossen-Zuordnung**: `3` +- **Falsch-positiv-Zuordnung**: `3` +- **Risiko-akzeptiert-Zuordnung**: `3` + +Wird ein Datensatz geschlossen, setzt DefectDojo zusätzlich den ServiceNow-**Close Code** und die **Close Notes** (`Resolved` für geschlossene Befunde, `False positive` und `Risk accepted` für die entsprechenden Status). + +### Verhalten speziell bei ServiceNow SecOps + +- **Deduplizierung** – jeder Datensatz wird in seinem Feld `correlation_id` mit dem DefectDojo-Identifikator des Befunds oder der Befundgruppe gekennzeichnet. Bevor DefectDojo einen Datensatz erstellt, sucht es per `correlation_id` nach einem vorhandenen; ein Treffer wird übernommen und aktualisiert statt dupliziert, sodass erneute Synchronisierungen idempotent sind. +- **Aktualisierungen** werden im Journal **Work notes** des Datensatzes eingetragen (intern), niemals in kundenseitig sichtbaren Comments. +- **Auflösen beim Löschen** – das Löschen eines Befunds in DefectDojo löst bzw. schließt den ServiceNow-Datensatz (State + Close Code), anstatt ihn zu löschen; Datensätze werden niemals endgültig gelöscht. +- **Referenzfelder** – die optionalen Werte `cmdb_ci`, `assignment_group` und `assigned_to` dürfen als Anzeigenamen angegeben werden; DefectDojo löst jeden in seine `sys_id` auf. Ein Name, der nicht auflösbar ist, wird mit einer Warnung verworfen, anstatt die Übertragung fehlschlagen zu lassen. diff --git a/docs/content/connectors/toolreference/servicenow_secops.es.md b/docs/content/connectors/toolreference/servicenow_secops.es.md new file mode 100644 index 00000000000..55c1ee4300b --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow_secops.es.md @@ -0,0 +1,54 @@ +--- +title: "ServiceNow SecOps" +description: "Cómo configurar el Conector Downstream de ServiceNow SecOps para DefectDojo" +weight: 122 +audience: pro +--- +La integración de ServiceNow SecOps (también conocida como **ServiceNow SecOps / Vulnerability Response**) envía los Hallazgos y Grupos de Hallazgos de DefectDojo a una tabla de seguridad de ServiceNow —un **Security Incident** (`sn_si_incident`) o un **Vulnerable Item** (`sn_vul_vulnerable_item`)— y la mantiene sincronizada a medida que el Hallazgo cambia (creación, actualización y resolución/cierre). Es la contraparte de operaciones de seguridad de la integración de ServiceNow como sistema de tickets descrita arriba; use ServiceNow SecOps cuando ejecute las aplicaciones Security Incident Response (SIR) o Vulnerability Response (VR). + +### Configuración de la instancia + +- **Instance Label** debe ser la etiqueta que desee usar para identificar esta integración. +- **Location** debe configurarse con la URL de su servidor ServiceNow, por ejemplo `https://your-organization.service-now.com/`. + +ServiceNow SecOps admite tres métodos de autenticación; proporcione **uno**: + +- **OAuth 2.0**: introduzca un **Client ID**, un **Client Secret** y un **Refresh Token**. Obténgalos exactamente como se describe en la sección [ServiceNow](/connectors/toolreference/servicenow/) anterior (cree un endpoint de API OAuth en el Application Registry y luego intercambie sus credenciales en `/oauth_token.do` por un refresh token). Alternativamente, proporcione el **Client ID** y el **Client Secret** junto con un **Username** y un **Password** para usar la concesión de contraseña de OAuth en lugar de un refresh token. +- **API Key**: introduzca una **API Key**, que se envía como el encabezado `x-sn-apikey`. La clave no autentica nada hasta que se le asocie un Inbound Authentication Profile y una REST API Access Policy en la instancia. +- **HTTP Basic**: introduzca el **Username** y el **Password** de la cuenta de servicio. + +La cuenta de servicio (o el cliente OAuth) necesita acceso de escritura a la tabla de destino. + +### Mapeo del sistema de tickets + +- **Target Table** selecciona la tabla de ServiceNow en la que se escriben los registros: **Security Incident** (`sn_si_incident`, el valor predeterminado) o **Vulnerable Item** (`sn_vul_vulnerable_item`). + +### Detalles del mapeo de severidad + +Para un Security Incident, esto se corresponde con el campo **Impact**; ServiceNow deriva la Priority del incidente a partir de Impact y Urgency, por lo que Urgency refleja el Impact mapeado a menos que lo mapee usted mismo. Para un Vulnerable Item, mapee la severidad al campo de riesgo que use su instancia. Los valores predeterminados a continuación coinciden con la escala estándar de Impact de SIR (`1` Alta, `2` Media, `3` Baja) y son editables. + +- **Nombre del campo de severidad**: `impact` +- **Mapeo de Informativa**: `3` +- **Mapeo de Baja**: `3` +- **Mapeo de Media**: `2` +- **Mapeo de Alta**: `1` +- **Mapeo de Crítica**: `1` + +### Detalles del mapeo de estado + +Esto se corresponde con el campo **State** del registro. Los valores de State son códigos numéricos que difieren entre las tablas Security Incident y Vulnerable Item y pueden personalizarse por instancia, así que revíselos contra su propia configuración. Los valores predeterminados a continuación usan los códigos de estado estándar de SIR (`16` Analysis, `3` Closed). + +- **Nombre del campo de estado**: `state` +- **Mapeo de Activo**: `16` +- **Mapeo de Cerrado**: `3` +- **Mapeo de Falso positivo**: `3` +- **Mapeo de Riesgo aceptado**: `3` + +Cuando se cierra un registro, DefectDojo también configura el **Close Code** y las **Close Notes** de ServiceNow (`Resolved` para los Hallazgos cerrados, `False positive` y `Risk accepted` para los estados correspondientes). + +### Comportamientos específicos de ServiceNow SecOps + +- **Deduplicación**: cada registro se etiqueta con el identificador de DefectDojo del Hallazgo o del Grupo de Hallazgos en su `correlation_id`. Antes de crear un registro, DefectDojo busca uno existente por `correlation_id`; si hay coincidencia, se adopta y se actualiza en lugar de duplicarse, de modo que las resincronizaciones son idempotentes. +- Las **actualizaciones** se publican en la bitácora **Work notes** del registro (interna), nunca en los Comments visibles para el cliente. +- **Resolver al eliminar**: eliminar un Hallazgo en DefectDojo resuelve/cierra el registro de ServiceNow (State + Close Code) en lugar de eliminarlo; los registros nunca se eliminan de forma permanente. +- **Campos de referencia**: los valores opcionales `cmdb_ci`, `assignment_group` y `assigned_to` pueden proporcionarse como nombres para mostrar; DefectDojo resuelve cada uno a su `sys_id`. Un nombre que no se resuelve se descarta con una advertencia en lugar de hacer fallar el envío. diff --git a/docs/content/connectors/toolreference/servicenow_secops.fr.md b/docs/content/connectors/toolreference/servicenow_secops.fr.md new file mode 100644 index 00000000000..6c051876e3b --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow_secops.fr.md @@ -0,0 +1,54 @@ +--- +title: "ServiceNow SecOps" +description: "Comment configurer le Connecteur Downstream ServiceNow SecOps pour DefectDojo" +weight: 122 +audience: pro +--- +L'intégration ServiceNow SecOps (aussi appelée **ServiceNow SecOps / Vulnerability Response**) pousse les Constatations et Groupes de constatations DefectDojo vers une table de sécurité ServiceNow — un **Security Incident** (`sn_si_incident`) ou un **Vulnerable Item** (`sn_vul_vulnerable_item`) — et la maintient synchronisée à mesure que la Constatation évolue (création, mise à jour et résolution/fermeture). C'est l'équivalent côté opérations de sécurité de l'intégration ServiceNow de suivi des tickets ci-dessus ; utilisez ServiceNow SecOps lorsque vous exploitez les applications Security Incident Response (SIR) ou Vulnerability Response (VR). + +### Configuration de l'instance + +- **Instance Label** doit être l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur l'URL de votre serveur ServiceNow, par exemple `https://your-organization.service-now.com/`. + +ServiceNow SecOps prend en charge trois méthodes d'authentification ; fournissez-en **une seule** : + +- **OAuth 2.0** — saisissez un **Client ID**, un **Client Secret** et un **Refresh Token**. Obtenez-les exactement comme décrit dans la section [ServiceNow](/connectors/toolreference/servicenow/) ci-dessus (créez un point de terminaison API OAuth dans l'Application Registry, puis échangez vos identifiants sur `/oauth_token.do` contre un jeton d'actualisation). Vous pouvez aussi fournir le **Client ID** et le **Client Secret** avec un **Username** et un **Password** pour utiliser l'octroi OAuth par mot de passe au lieu d'un jeton d'actualisation. +- **API Key** — saisissez une **API Key**, envoyée dans l'en-tête `x-sn-apikey`. La clé n'authentifie rien tant qu'un Inbound Authentication Profile et une REST API Access Policy ne lui sont pas associés sur l'instance. +- **HTTP Basic** — saisissez le **Username** et le **Password** du compte de service. + +Le compte de service (ou le client OAuth) doit disposer d'un accès en écriture à la table cible. + +### Correspondance du suivi des tickets + +- **Target Table** sélectionne la table ServiceNow dans laquelle les enregistrements sont écrits : **Security Incident** (`sn_si_incident`, valeur par défaut) ou **Vulnerable Item** (`sn_vul_vulnerable_item`). + +### Détails de la correspondance des sévérités + +Pour un Security Incident, ceci correspond au champ **Impact** ; ServiceNow dérive la Priority de l'incident à partir de l'Impact et de l'Urgency, si bien que l'Urgency reflète l'Impact mappé à moins que vous ne la mappiez vous-même. Pour un Vulnerable Item, associez la sévérité au champ de risque utilisé par votre instance. Les valeurs par défaut ci-dessous correspondent à l'échelle Impact SIR standard (`1` High, `2` Medium, `3` Low) et sont modifiables. + +- **Severity Field Name**: `impact` +- **Info Mapping**: `3` +- **Low Mapping**: `3` +- **Medium Mapping**: `2` +- **High Mapping**: `1` +- **Critical Mapping**: `1` + +### Détails de la correspondance des statuts + +Ceci correspond au champ **State** de l'enregistrement. Les valeurs d'état sont des codes numériques qui diffèrent entre les tables Security Incident et Vulnerable Item et peuvent être personnalisées par instance ; vérifiez-les donc par rapport à votre propre configuration. Les valeurs par défaut ci-dessous utilisent les codes d'état SIR standard (`16` Analysis, `3` Closed). + +- **Status Field Name**: `state` +- **Active Mapping**: `16` +- **Closed Mapping**: `3` +- **False Positive Mapping**: `3` +- **Risk Accepted Mapping**: `3` + +Lorsqu'un enregistrement est fermé, DefectDojo définit également le **Close Code** et les **Close Notes** ServiceNow (`Resolved` pour les Constatations fermées, `False positive` et `Risk accepted` pour les états correspondants). + +### Comportements spécifiques à ServiceNow SecOps + +- **Deduplication** — chaque enregistrement est marqué avec l'identifiant DefectDojo de la Constatation ou du Groupe de constatations dans son `correlation_id`. Avant de créer un enregistrement, DefectDojo en recherche un par `correlation_id` ; une correspondance est reprise et mise à jour plutôt que dupliquée, ce qui rend les resynchronisations idempotentes. +- **Updates** sont publiées dans le journal **Work notes** de l'enregistrement (interne), jamais dans les Comments visibles par le client. +- **Resolve on delete** — la suppression d'une Constatation dans DefectDojo résout/ferme l'enregistrement ServiceNow (State + Close Code) plutôt que de le supprimer ; les enregistrements ne sont jamais supprimés définitivement. +- **Reference fields** — les valeurs facultatives `cmdb_ci`, `assignment_group` et `assigned_to` peuvent être fournies sous forme de noms d'affichage ; DefectDojo résout chacune vers son `sys_id`. Un nom qui ne se résout pas est ignoré avec un avertissement plutôt que de faire échouer l'envoi. diff --git a/docs/content/connectors/toolreference/servicenow_secops.ja.md b/docs/content/connectors/toolreference/servicenow_secops.ja.md new file mode 100644 index 00000000000..fbf097f7d66 --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow_secops.ja.md @@ -0,0 +1,54 @@ +--- +title: "ServiceNow SecOps" +description: "DefectDojo で ServiceNow SecOps のダウンストリームコネクタをセットアップする方法" +weight: 122 +audience: pro +--- +ServiceNow SecOps 連携(**ServiceNow SecOps / Vulnerability Response** とも呼ばれます)は、DefectDojo の検出事項および検出事項グループを ServiceNow のセキュリティテーブル — **Security Incident**(`sn_si_incident`)または **Vulnerable Item**(`sn_vul_vulnerable_item`)— にプッシュし、検出事項の変化(作成、更新、解決/クローズ)に応じて同期を維持します。これは上記の ServiceNow 課題管理連携に対応するセキュリティ運用版であり、Security Incident Response(SIR)または Vulnerability Response(VR)アプリケーションを利用している場合は ServiceNow SecOps を使用してください。 + +### インスタンスのセットアップ + +- **Instance Label** には、この連携を識別するために使用したいラベルを設定します。 +- **Location** には、ServiceNow サーバーの URL を設定します。例: `https://your-organization.service-now.com/`。 + +ServiceNow SecOps は 3 種類の認証方式をサポートしています。**いずれか 1 つ** を指定してください。 + +- **OAuth 2.0** — **Client ID**、**Client Secret**、**Refresh Token** を入力します。取得方法は上記の[ServiceNow](/connectors/toolreference/servicenow/)セクションで説明した手順とまったく同じです(Application Registry で OAuth API エンドポイントを作成し、`/oauth_token.do` で認証情報をリフレッシュトークンと交換します)。あるいは、リフレッシュトークンの代わりに OAuth のパスワードグラントを使用する場合は、**Client ID** と **Client Secret** に加えて **Username** と **Password** を指定します。 +- **API Key** — **API Key** を入力します。これは `x-sn-apikey` ヘッダーとして送信されます。このキーは、インスタンス側で Inbound Authentication Profile と REST API Access Policy が紐づけられるまでは、何も認証しません。 +- **HTTP Basic** — サービスアカウントの **Username** と **Password** を入力します。 + +サービスアカウント(または OAuth クライアント)には、対象テーブルへの書き込みアクセス権が必要です。 + +### 課題管理マッピング + +- **Target Table** は、レコードの書き込み先となる ServiceNow テーブルを選択します: **Security Incident**(`sn_si_incident`、デフォルト)または **Vulnerable Item**(`sn_vul_vulnerable_item`)。 + +### 深刻度マッピングの詳細 + +Security Incident の場合、これは **Impact** フィールドにマッピングされます。ServiceNow はインシデントの Priority を Impact と Urgency から導出するため、自分で Urgency をマッピングしない限り、Urgency はマッピングされた Impact と同じ値になります。Vulnerable Item の場合は、インスタンスで使用しているリスクフィールドに深刻度をマッピングしてください。以下のデフォルト値は、標準の SIR Impact スケール(`1` 高、`2` 中、`3` 低)に対応しており、編集可能です。 + +- **深刻度フィールド名**: `impact` +- **情報マッピング**: `3` +- **低マッピング**: `3` +- **中マッピング**: `2` +- **高マッピング**: `1` +- **重大マッピング**: `1` + +### ステータスマッピングの詳細 + +これはレコードの **State** フィールドにマッピングされます。ステート値は数値コードであり、Security Incident テーブルと Vulnerable Item テーブルで異なり、インスタンスごとにカスタマイズできるため、自分の設定と照らし合わせて確認してください。以下のデフォルト値は、標準の SIR ステートコード(`16` Analysis、`3` Closed)を使用しています。 + +- **ステータスフィールド名**: `state` +- **アクティブマッピング**: `16` +- **クローズマッピング**: `3` +- **誤検知マッピング**: `3` +- **リスク受容済みマッピング**: `3` + +レコードがクローズされると、DefectDojo は ServiceNow の **Close Code** と **Close Notes** も設定します(クローズした検出事項には `Resolved`、対応するステートには `False positive` および `Risk accepted`)。 + +### ServiceNow SecOps 固有の動作 + +- **重複排除** — 各レコードには、検出事項または検出事項グループの DefectDojo 識別子が `correlation_id` にタグ付けされます。レコードを作成する前に、DefectDojo は `correlation_id` で既存のレコードを検索します。一致するものが見つかった場合は、重複作成せずにそれを採用して更新するため、再同期はべき等です。 +- **更新内容** は、顧客に見える Comments ではなく、レコードの **Work notes** ジャーナル(内部用)に投稿されます。 +- **削除時の解決(Resolve on delete)** — DefectDojo で検出事項を削除すると、ServiceNow のレコードは削除されるのではなく、解決/クローズされます(State + Close Code)。レコードが物理削除されることはありません。 +- **参照フィールド** — 任意項目の `cmdb_ci`、`assignment_group`、`assigned_to` の値は表示名として指定できます。DefectDojo はそれぞれを `sys_id` に解決します。解決できない名前は、プッシュを失敗させることなく、警告とともに除外されます。 diff --git a/docs/content/connectors/toolreference/servicenow_secops.md b/docs/content/connectors/toolreference/servicenow_secops.md new file mode 100644 index 00000000000..a05e19f976f --- /dev/null +++ b/docs/content/connectors/toolreference/servicenow_secops.md @@ -0,0 +1,54 @@ +--- +title: "ServiceNow SecOps" +description: "How to set up the ServiceNow SecOps Downstream Connector for DefectDojo" +weight: 122 +audience: pro +--- +The ServiceNow SecOps integration (also known as **ServiceNow SecOps / Vulnerability Response**) pushes DefectDojo Findings and Finding Groups into a ServiceNow security table — a **Security Incident** (`sn_si_incident`) or a **Vulnerable Item** (`sn_vul_vulnerable_item`) — and keeps it in sync as the Finding changes (create, update, and resolve/close). It is the security-operations counterpart to the [ServiceNow](/connectors/toolreference/servicenow/) issue-tracker integration; use ServiceNow SecOps when you run the Security Incident Response (SIR) or Vulnerability Response (VR) applications. + +### Instance Setup + +- **Instance Label** should be the label that you want to use to identify this integration. +- **Location** should be set to the URL for your ServiceNow server, for example `https://your-organization.service-now.com/`. + +ServiceNow SecOps supports three authentication methods; provide **one**: + +- **OAuth 2.0** — enter a **Client ID**, **Client Secret**, and **Refresh Token**. Obtain them exactly as described on the [ServiceNow](/connectors/toolreference/servicenow/) page (create an OAuth API endpoint in the Application Registry, then exchange your credentials at `/oauth_token.do` for a refresh token). Alternatively, provide the **Client ID** and **Client Secret** together with a **Username** and **Password** to use the OAuth password grant instead of a refresh token. +- **API Key** — enter an **API Key**, sent as the `x-sn-apikey` header. The key authenticates nothing until an Inbound Authentication Profile and a REST API Access Policy are attached to it on the instance. +- **HTTP Basic** — enter the **Username** and **Password** of the service account. + +The service account (or OAuth client) needs write access to the target table. + +### Issue Tracker Mapping + +- **Target Table** selects the ServiceNow table records are written to: **Security Incident** (`sn_si_incident`, the default) or **Vulnerable Item** (`sn_vul_vulnerable_item`). + +### Severity Mapping Details + +For a Security Incident this maps to the **Impact** field; ServiceNow derives the incident Priority from Impact and Urgency, so Urgency mirrors the mapped Impact unless you map it yourself. For a Vulnerable Item, map severity to the risk field your instance uses. The defaults below match the standard SIR Impact scale (`1` High, `2` Medium, `3` Low) and are editable. + +- **Severity Field Name**: `impact` +- **Info Mapping**: `3` +- **Low Mapping**: `3` +- **Medium Mapping**: `2` +- **High Mapping**: `1` +- **Critical Mapping**: `1` + +### Status Mapping Details + +This maps to the record's **State** field. State values are numeric codes that differ between the Security Incident and Vulnerable Item tables and can be customized per instance, so review these against your own configuration. The defaults below use the standard SIR state codes (`16` Analysis, `3` Closed). + +- **Status Field Name**: `state` +- **Active Mapping**: `16` +- **Closed Mapping**: `3` +- **False Positive Mapping**: `3` +- **Risk Accepted Mapping**: `3` + +When a record is closed, DefectDojo also sets the ServiceNow **Close Code** and **Close Notes** (`Resolved` for closed Findings, `False positive` and `Risk accepted` for the corresponding states). + +### ServiceNow SecOps-specific behaviors + +- **Deduplication** — each record is tagged with the Finding or Finding Group's DefectDojo identifier in its `correlation_id`. Before creating a record DefectDojo looks one up by `correlation_id`; a match is adopted and updated rather than duplicated, so re-syncs are idempotent. +- **Updates** are posted to the record's **Work notes** journal (internal), never to customer-visible Comments. +- **Resolve on delete** — deleting a Finding in DefectDojo resolves/closes the ServiceNow record (State + Close Code) rather than deleting it; records are never hard-deleted. +- **Reference fields** — optional `cmdb_ci`, `assignment_group`, and `assigned_to` values may be supplied as display names; DefectDojo resolves each to its `sys_id`. A name that does not resolve is dropped with a warning rather than failing the push. diff --git a/docs/content/connectors/toolreference/shodan.de.md b/docs/content/connectors/toolreference/shodan.de.md new file mode 100644 index 00000000000..aa7935385e7 --- /dev/null +++ b/docs/content/connectors/toolreference/shodan.de.md @@ -0,0 +1,20 @@ +--- +title: "Shodan" +description: "Einrichtung des Shodan Upstream-Connectors für DefectDojo" +weight: 123 +audience: pro +--- +Der Shodan-Connector verwendet die Shodan-REST-API, um die von Shodan auf Ihren im Internet exponierten Hosts beobachteten Schwachstellen (CVEs) zu importieren. Sie geben eine Shodan-Suchanfrage an, die den Import auf Ihre eigenen Assets beschränkt; DefectDojo erstellt für jeden passenden Host einen Eintrag und importiert dessen CVEs als Befunde. + +#### Voraussetzungen + +Sie benötigen einen Shodan-API-Schlüssel, den Sie auf Ihrer Shodan-**Account**-Seite finden. Die Host-Suche mit Schwachstellendaten erfordert eine Shodan-Mitgliedschaft oder einen kostenpflichtigen API-Plan — die kostenlose Stufe kann Suchergebnisse nicht seitenweise durchblättern. + +#### Connector-Zuordnungen + +1. Geben Sie `https://api.shodan.io` in das Feld **Location** ein. +2. Geben Sie Ihren Shodan-API-Schlüssel in das Feld **API Key** ein. +3. Geben Sie im Feld **Search Query** eine Shodan-Abfrage ein, die den Import auf die Assets Ihrer Organisation beschränkt — zum Beispiel `hostname:example.com`, `net:203.0.113.0/24` oder `org:"Example Inc"`. Es werden nur Hosts importiert, die dieser Abfrage entsprechen; beschränken Sie sie daher auf Infrastruktur, die Ihnen gehört. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jeder passende Host wird zu einem Eintrag, und jede von Shodan auf den exponierten Diensten dieses Hosts erkannte CVE wird als Befund importiert — der Schweregrad wird aus dem CVSS-Score abgeleitet, wobei EPSS- und CISA-KEV-Kontext einbezogen wird, sofern verfügbar. Jede Seite der Suchergebnisse verbraucht ein Shodan-Abfrage-Guthaben. diff --git a/docs/content/connectors/toolreference/shodan.es.md b/docs/content/connectors/toolreference/shodan.es.md new file mode 100644 index 00000000000..a1a3411e22d --- /dev/null +++ b/docs/content/connectors/toolreference/shodan.es.md @@ -0,0 +1,20 @@ +--- +title: "Shodan" +description: "Cómo configurar el Conector Upstream de Shodan para DefectDojo" +weight: 123 +audience: pro +--- +El conector de Shodan usa la API REST de Shodan para importar las vulnerabilidades (CVE) que Shodan ha observado en sus hosts expuestos a internet. Usted proporciona una consulta de búsqueda de Shodan que limita la importación a sus propios activos; DefectDojo crea un Record para cada host coincidente e importa sus CVE como hallazgos. + +#### Requisitos previos + +Necesitará una API key de Shodan, disponible en la página **Account** de Shodan. La búsqueda de hosts con datos de vulnerabilidades requiere una membresía de Shodan o un plan de API de pago: el nivel gratuito no puede paginar los resultados de búsqueda. + +#### Asignaciones del conector + +1. Ingrese `https://api.shodan.io` en el campo **Location**. +2. Ingrese su API key de Shodan en el campo **API Key**. +3. En el campo **Search Query**, ingrese una consulta de Shodan que limite la importación a los activos de su organización; por ejemplo, `hostname:example.com`, `net:203.0.113.0/24`, u `org:"Example Inc"`. Solo se importan los hosts que coincidan con esta consulta, así que manténgala limitada a la infraestructura que usted posee. +4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada host coincidente se convierte en un Record, y cada CVE que Shodan detectó en los servicios expuestos de ese host se importa como un hallazgo; la severidad se deriva de la puntuación CVSS, incluyendo el contexto de EPSS y CISA KEV cuando está disponible. Cada página de resultados de búsqueda consume un crédito de consulta de Shodan. diff --git a/docs/content/connectors/toolreference/shodan.fr.md b/docs/content/connectors/toolreference/shodan.fr.md new file mode 100644 index 00000000000..e28bcb9a417 --- /dev/null +++ b/docs/content/connectors/toolreference/shodan.fr.md @@ -0,0 +1,20 @@ +--- +title: "Shodan" +description: "Comment configurer le Connecteur Upstream Shodan pour DefectDojo" +weight: 123 +audience: pro +--- +Le connecteur Shodan utilise l'API REST de Shodan pour importer les vulnérabilités (CVE) que Shodan a observées sur vos hôtes exposés sur Internet. Vous fournissez une requête de recherche Shodan qui limite l'import à vos propres actifs ; DefectDojo crée un Record pour chaque hôte correspondant et importe ses CVE en tant que constatations. + +#### Prérequis + +Vous aurez besoin d'une clé API Shodan, disponible sur votre page **Account** Shodan. La recherche d'hôtes avec données de vulnérabilité nécessite un abonnement Shodan ou un plan API payant — le niveau gratuit ne permet pas de parcourir les pages de résultats de recherche. + +#### Correspondances du connecteur + +1. Saisissez `https://api.shodan.io` dans le champ **Location**. +2. Saisissez votre clé API Shodan dans le champ **API Key**. +3. Dans le champ **Search Query**, saisissez une requête Shodan qui limite l'import aux actifs de votre organisation — par exemple `hostname:example.com`, `net:203.0.113.0/24`, ou `org:"Example Inc"`. Seuls les hôtes correspondant à cette requête sont importés ; veillez donc à la limiter à l'infrastructure que vous possédez. +4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque hôte correspondant devient un Record, et chaque CVE détecté par Shodan sur les services exposés de cet hôte est importé en tant que constatation — la sévérité est dérivée du score CVSS, avec le contexte EPSS et CISA KEV inclus lorsqu'il est disponible. Chaque page de résultats de recherche consomme un crédit de requête Shodan. diff --git a/docs/content/connectors/toolreference/shodan.ja.md b/docs/content/connectors/toolreference/shodan.ja.md new file mode 100644 index 00000000000..b9383204b2c --- /dev/null +++ b/docs/content/connectors/toolreference/shodan.ja.md @@ -0,0 +1,20 @@ +--- +title: "Shodan" +description: "DefectDojo で Shodan の Upstream Connector をセットアップする方法" +weight: 123 +audience: pro +--- +Shodanコネクタは、Shodan REST APIを使用して、インターネットに露出しているホストでShodanが観測した脆弱性 (CVE) をインポートします。お使いの資産に取り込み範囲を限定するShodan検索クエリを指定し、DefectDojoは一致する各ホストについてRecordを作成し、そのCVEを検出事項としてインポートします。 + +#### 前提条件 + +Shodanの**Account**ページで確認できるShodan APIキーが必要です。脆弱性データ付きのホスト検索には、Shodanのメンバーシップまたは有料APIプランが必要です — 無料プランでは検索結果をページングできません。 + +#### Connector Mappings + +1. **Location** フィールドに `https://api.shodan.io` を入力します。 +2. **API Key** フィールドにShodan APIキーを入力します。 +3. **Search Query** フィールドに、お使いの組織の資産に取り込み範囲を限定するShodanクエリを入力します — 例: `hostname:example.com`、`net:203.0.113.0/24`、`org:"Example Inc"`。このクエリに一致するホストのみがインポートされるため、自組織が所有するインフラストラクチャに範囲を限定してください。 +4. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 + +一致する各ホストが1件のRecordになり、そのホストの露出しているサービス上でShodanが検出した各CVEが検出事項としてインポートされます — 深刻度はCVSSスコアから導出され、利用可能な場合はEPSSとCISA KEVのコンテキストが含まれます。検索結果の各ページはShodanのクエリクレジットを1つ消費します。 diff --git a/docs/content/connectors/toolreference/shodan.md b/docs/content/connectors/toolreference/shodan.md new file mode 100644 index 00000000000..28118fae4d0 --- /dev/null +++ b/docs/content/connectors/toolreference/shodan.md @@ -0,0 +1,20 @@ +--- +title: "Shodan" +description: "How to set up the Shodan Upstream Connector for DefectDojo" +weight: 123 +audience: pro +--- +The Shodan connector uses the Shodan REST API to import the vulnerabilities (CVEs) Shodan has observed on your internet-exposed hosts. You provide a Shodan search query that scopes the import to your own assets; DefectDojo creates a Record for each matching host and imports its CVEs as findings. + +#### Prerequisites + +You will need a Shodan API key, found on your Shodan **Account** page. Host search with vulnerability data requires a Shodan membership or a paid API plan — the free tier cannot page through search results. + +#### Connector Mappings + +1. Enter `https://api.shodan.io` in the **Location** field. +2. Enter your Shodan API key in the **API Key** field. +3. In the **Search Query** field, enter a Shodan query that scopes the import to your organization's assets — for example `hostname:example.com`, `net:203.0.113.0/24`, or `org:"Example Inc"`. Only hosts matching this query are imported, so keep it scoped to infrastructure you own. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each matching host becomes a Record, and each CVE Shodan detected on that host's exposed services is imported as a finding — severity is derived from the CVSS score, with EPSS and CISA KEV context included where available. Each page of search results consumes one Shodan query credit. diff --git a/docs/content/connectors/toolreference/shortcut.de.md b/docs/content/connectors/toolreference/shortcut.de.md new file mode 100644 index 00000000000..e53c2f5e9b1 --- /dev/null +++ b/docs/content/connectors/toolreference/shortcut.de.md @@ -0,0 +1,46 @@ +--- +title: "Shortcut" +description: "Einrichtung des Shortcut Downstream-Connectors für DefectDojo" +weight: 124 +audience: pro +--- +Die Shortcut-Integration ermöglicht es Ihnen, DefectDojo-Befunde als [Shortcut](https://www.shortcut.com/)-Stories zu übertragen. Stories werden mit dem Story-Typ „Bug“ erstellt und einem Team in Ihrem Shortcut-Workspace zugewiesen. + +### Instanz-Einrichtung + +- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf `https://api.app.shortcut.com` gesetzt werden. +- **API Token** sollte auf ein Shortcut-API-Token gesetzt werden. Token können in Shortcut unter „Settings“, dann „Your Account“, dann [API Tokens](https://app.shortcut.com/settings/account/api-tokens) generiert werden. + +### Issue-Tracker-Zuordnung + +- **Team (Group) ID** sollte auf die UUID des Shortcut-Teams gesetzt werden, für das Stories erstellt werden. Sie finden diese UUID, indem Sie die Team-Seite in Shortcut öffnen und den Identifikator aus der URL kopieren, oder indem Sie die Shortcut-API aufrufen: + +``` +curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/groups +``` + +### Details zur Schweregrad-Zuordnung + +Jeder Schweregradwert wird der Story als Label zugewiesen. Labels werden in Shortcut automatisch erstellt, falls sie noch nicht existieren; die Standardwerte unten können also unverändert übernommen oder durch Labelnamen Ihrer Wahl ersetzt werden. Ändert sich der Schweregrad eines Befunds, wird das alte Schweregrad-Label von der Story entfernt und das neue hinzugefügt. + +- **Name des Schweregrad-Felds**: `Label` +- **Info-Zuordnung**: `sev-info` +- **Niedrig-Zuordnung**: `sev-low` +- **Mittel-Zuordnung**: `sev-medium` +- **Hoch-Zuordnung**: `sev-high` +- **Kritisch-Zuordnung**: `sev-critical` + +### Details zur Status-Zuordnung + +Jeder Statuswert muss auf die numerische ID eines Workflow-States in Ihrem Shortcut-Workspace gesetzt werden. Workflow-State-IDs sind je Workspace eindeutig, daher gibt es keine Standardwerte. Sie können die Workflow-States und ihre IDs auflisten, indem Sie die Shortcut-API aufrufen: + +``` +curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/workflows +``` + +- **Name des Status-Felds**: `Workflow State ID` +- **Aktiv-Zuordnung**: die ID des States für offene Arbeit, zum Beispiel ein Backlog- oder To-Do-State. +- **Geschlossen-Zuordnung**: die ID eines States vom Typ „Done“. Wenn ein Befund in DefectDojo gelöscht wird, wird seine Story in diesen State verschoben. +- **Falsch-positiv-Zuordnung**: die ID des States, der für Falsch-positiv-Befunde verwendet wird. +- **Risiko-akzeptiert-Zuordnung**: die ID des States, der für Befunde mit akzeptiertem Risiko verwendet wird. diff --git a/docs/content/connectors/toolreference/shortcut.es.md b/docs/content/connectors/toolreference/shortcut.es.md new file mode 100644 index 00000000000..678499b0e45 --- /dev/null +++ b/docs/content/connectors/toolreference/shortcut.es.md @@ -0,0 +1,46 @@ +--- +title: "Shortcut" +description: "Cómo configurar el Conector Downstream de Shortcut para DefectDojo" +weight: 124 +audience: pro +--- +La integración con Shortcut le permite enviar los Hallazgos de DefectDojo como Stories de [Shortcut](https://www.shortcut.com/). Las Stories se crean con el tipo de story Bug y se asignan a un Team de su espacio de trabajo de Shortcut. + +### Configuración de la instancia + +- **Label** debe ser la etiqueta que desee usar para identificar esta integración. +- **Location** debe configurarse como `https://api.app.shortcut.com`. +- **API Token** debe configurarse con un token de API de Shortcut. Los tokens pueden generarse en Shortcut en Settings, luego Your Account, luego [API Tokens](https://app.shortcut.com/settings/account/api-tokens). + +### Mapeo del sistema de tickets + +- **Team (Group) ID** debe configurarse con el UUID del Team de Shortcut para el que se crearán las Stories. Puede encontrar este UUID abriendo la página del Team en Shortcut y copiando el identificador de la URL, o llamando a la API de Shortcut: + +``` +curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/groups +``` + +### Detalles del mapeo de severidad + +Cada valor de severidad se aplica a la Story como una etiqueta. Las etiquetas se crean automáticamente en Shortcut si aún no existen, por lo que los valores predeterminados a continuación pueden usarse tal cual, o sustituirse por nombres de etiqueta de su elección. Cuando cambia la severidad de un Hallazgo, la etiqueta de severidad anterior se elimina de la Story y se añade la nueva. + +- **Nombre del campo de severidad**: `Label` +- **Mapeo de Informativa**: `sev-info` +- **Mapeo de Baja**: `sev-low` +- **Mapeo de Media**: `sev-medium` +- **Mapeo de Alta**: `sev-high` +- **Mapeo de Crítica**: `sev-critical` + +### Detalles del mapeo de estado + +Cada valor de estado debe configurarse con el ID numérico de un Workflow State en su espacio de trabajo de Shortcut. Los ID de Workflow State son únicos para cada espacio de trabajo, por lo que no hay valores predeterminados. Puede listar los Workflow States y sus ID llamando a la API de Shortcut: + +``` +curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/workflows +``` + +- **Nombre del campo de estado**: `Workflow State ID` +- **Mapeo de Activo**: el ID del estado para trabajo abierto, por ejemplo un estado de Backlog o To Do. +- **Mapeo de Cerrado**: el ID de un estado de tipo Done. Cuando se elimina un Hallazgo en DefectDojo, su Story se mueve a este estado. +- **Mapeo de Falso positivo**: el ID del estado que se usará para los Hallazgos marcados como Falso positivo. +- **Mapeo de Riesgo aceptado**: el ID del estado que se usará para los Hallazgos con Riesgo aceptado. diff --git a/docs/content/connectors/toolreference/shortcut.fr.md b/docs/content/connectors/toolreference/shortcut.fr.md new file mode 100644 index 00000000000..5bb4beee7a6 --- /dev/null +++ b/docs/content/connectors/toolreference/shortcut.fr.md @@ -0,0 +1,46 @@ +--- +title: "Shortcut" +description: "Comment configurer le Connecteur Downstream Shortcut pour DefectDojo" +weight: 124 +audience: pro +--- +L'intégration Shortcut vous permet de pousser les Constatations DefectDojo sous forme de Stories [Shortcut](https://www.shortcut.com/). Les Stories sont créées avec le type Bug et affectées à une Team de votre espace de travail Shortcut. + +### Configuration de l'instance + +- **Label** doit être l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur `https://api.app.shortcut.com`. +- **API Token** doit être un jeton API Shortcut. Les jetons peuvent être générés dans Shortcut sous Settings, puis Your Account, puis [API Tokens](https://app.shortcut.com/settings/account/api-tokens). + +### Correspondance du suivi des tickets + +- **Team (Group) ID** doit être défini sur l'UUID de la Team Shortcut pour laquelle les Stories seront créées. Vous pouvez trouver cet UUID en ouvrant la page Team dans Shortcut et en copiant l'identifiant depuis l'URL, ou en appelant l'API Shortcut : + +``` +curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/groups +``` + +### Détails de la correspondance des sévérités + +Chaque valeur de sévérité est appliquée à la Story sous forme de label. Les labels sont créés automatiquement dans Shortcut s'ils n'existent pas déjà ; les valeurs par défaut ci-dessous peuvent donc être utilisées telles quelles, ou remplacées par des noms de label de votre choix. Lorsque la sévérité d'une Constatation change, l'ancien label de sévérité est retiré de la Story et le nouveau est ajouté. + +- **Severity Field Name**: `Label` +- **Info Mapping**: `sev-info` +- **Low Mapping**: `sev-low` +- **Medium Mapping**: `sev-medium` +- **High Mapping**: `sev-high` +- **Critical Mapping**: `sev-critical` + +### Détails de la correspondance des statuts + +Chaque valeur de statut doit être définie sur l'ID numérique d'un Workflow State dans votre espace de travail Shortcut. Les ID de Workflow State sont propres à chaque espace de travail ; il n'y a donc pas de valeurs par défaut. Vous pouvez lister les Workflow States et leurs ID en appelant l'API Shortcut : + +``` +curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/workflows +``` + +- **Status Field Name**: `Workflow State ID` +- **Active Mapping** : l'ID de l'état pour le travail ouvert, par exemple un état Backlog ou To Do. +- **Closed Mapping** : l'ID d'un état de type Done. Lorsqu'une Constatation est supprimée dans DefectDojo, sa Story est déplacée vers cet état. +- **False Positive Mapping** : l'ID de l'état à utiliser pour les Constatations Faux positif. +- **Risk Accepted Mapping** : l'ID de l'état à utiliser pour les Constatations Risque accepté. diff --git a/docs/content/connectors/toolreference/shortcut.ja.md b/docs/content/connectors/toolreference/shortcut.ja.md new file mode 100644 index 00000000000..882ac8acbf9 --- /dev/null +++ b/docs/content/connectors/toolreference/shortcut.ja.md @@ -0,0 +1,46 @@ +--- +title: "Shortcut" +description: "DefectDojo で Shortcut のダウンストリームコネクタをセットアップする方法" +weight: 124 +audience: pro +--- +Shortcut 連携を使用すると、DefectDojo の検出事項を [Shortcut](https://www.shortcut.com/) の Story としてプッシュできます。Story は Story タイプ Bug で作成され、Shortcut ワークスペース内の Team に割り当てられます。 + +### インスタンスのセットアップ + +- **Label** には、この連携を識別するために使用したいラベルを設定します。 +- **Location** には `https://api.app.shortcut.com` を設定します。 +- **API Token** には、Shortcut の API トークンを設定します。トークンは Shortcut の Settings > Your Account > [API Tokens](https://app.shortcut.com/settings/account/api-tokens) で生成できます。 + +### 課題管理マッピング + +- **Team (Group) ID** には、Story の作成先となる Shortcut Team の UUID を設定します。この UUID は、Shortcut で Team ページを開いて URL から識別子をコピーするか、Shortcut API を呼び出すことで確認できます。 + +``` +curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/groups +``` + +### 深刻度マッピングの詳細 + +各深刻度の値は、ラベルとして Story に適用されます。ラベルが Shortcut にまだ存在しない場合は自動的に作成されるため、以下のデフォルト値をそのまま使用することも、任意のラベル名に置き換えることもできます。検出事項の深刻度が変更されると、古い深刻度ラベルが Story から削除され、新しいラベルが追加されます。 + +- **深刻度フィールド名**: `Label` +- **情報マッピング**: `sev-info` +- **低マッピング**: `sev-low` +- **中マッピング**: `sev-medium` +- **高マッピング**: `sev-high` +- **重大マッピング**: `sev-critical` + +### ステータスマッピングの詳細 + +各ステータスの値には、Shortcut ワークスペース内の Workflow State の数値 ID を設定する必要があります。Workflow State ID はワークスペースごとに固有であるため、デフォルト値はありません。Workflow State とその ID の一覧は、Shortcut API を呼び出すことで取得できます。 + +``` +curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/workflows +``` + +- **ステータスフィールド名**: `Workflow State ID` +- **アクティブマッピング**: 未着手の作業を表すステート(たとえば Backlog や To Do のステート)の ID。 +- **クローズマッピング**: Done タイプのステートの ID。DefectDojo で検出事項が削除されると、その Story はこのステートに移動します。 +- **誤検知マッピング**: 誤検知の検出事項に使用するステートの ID。 +- **リスク受容済みマッピング**: リスク受容済みの検出事項に使用するステートの ID。 diff --git a/docs/content/connectors/toolreference/shortcut.md b/docs/content/connectors/toolreference/shortcut.md new file mode 100644 index 00000000000..1fed6b1ebda --- /dev/null +++ b/docs/content/connectors/toolreference/shortcut.md @@ -0,0 +1,46 @@ +--- +title: "Shortcut" +description: "How to set up the Shortcut Downstream Connector for DefectDojo" +weight: 124 +audience: pro +--- +The Shortcut integration allows you to push DefectDojo Findings as [Shortcut](https://www.shortcut.com/) Stories. Stories are created with the story type of Bug and assigned to a Team in your Shortcut workspace. + +### Instance Setup + +- **Label** should be the label that you want to use to identify this integration. +- **Location** should be set to `https://api.app.shortcut.com`. +- **API Token** should be set to a Shortcut API token. Tokens can be generated in Shortcut under Settings, then Your Account, then [API Tokens](https://app.shortcut.com/settings/account/api-tokens). + +### Issue Tracker Mapping + +- **Team (Group) ID** should be set to the UUID of the Shortcut Team that Stories will be created for. You can find this UUID by opening the Team page in Shortcut and copying the identifier from the URL, or by calling the Shortcut API: + +``` +curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/groups +``` + +### Severity Mapping Details + +Each severity value is applied to the Story as a label. Labels are created automatically in Shortcut if they do not already exist, so the default values below can be used as they are, or replaced with label names of your choosing. When a Finding's severity changes, the old severity label is removed from the Story and the new one is added. + +- **Severity Field Name**: `Label` +- **Info Mapping**: `sev-info` +- **Low Mapping**: `sev-low` +- **Medium Mapping**: `sev-medium` +- **High Mapping**: `sev-high` +- **Critical Mapping**: `sev-critical` + +### Status Mapping Details + +Each status value must be set to the numeric ID of a Workflow State in your Shortcut workspace. Workflow State IDs are unique to each workspace, so there are no default values. You can list the Workflow States and their IDs by calling the Shortcut API: + +``` +curl -H "Shortcut-Token: {{API_TOKEN}}" https://api.app.shortcut.com/api/v3/workflows +``` + +- **Status Field Name**: `Workflow State ID` +- **Active Mapping**: the ID of the state for open work, for example a Backlog or To Do state. +- **Closed Mapping**: the ID of a Done type state. When a Finding is deleted in DefectDojo, its Story is moved to this state. +- **False Positive Mapping**: the ID of the state to use for False Positive Findings. +- **Risk Accepted Mapping**: the ID of the state to use for Risk Accepted Findings. diff --git a/docs/content/connectors/toolreference/snyk.de.md b/docs/content/connectors/toolreference/snyk.de.md new file mode 100644 index 00000000000..9c6fab29c6b --- /dev/null +++ b/docs/content/connectors/toolreference/snyk.de.md @@ -0,0 +1,14 @@ +--- +title: "Snyk" +description: "Einrichtung des Snyk Upstream-Connectors für DefectDojo" +weight: 125 +audience: pro +--- +Der Snyk-Connector verwendet die Snyk-REST-API, um Daten abzurufen. + +#### Connector-Zuordnungen + +1. Geben Sie **[https://api.snyk.io/rest](https://api.snyk.io/v1)** oder **[https://api.eu.snyk.io/rest](https://api.eu.snyk.io/v1)** (für eine regionale EU-Bereitstellung) in das Feld **Location** ein. +2. Geben Sie einen gültigen API-Schlüssel in das Feld **Secret** ein. API-Tokens finden Sie auf der **[Account-Settings](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token)**-[Seite](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token) eines Benutzers in Snyk. + +Weitere Informationen finden Sie in der [Snyk-API-Dokumentation](https://docs.snyk.io/snyk-api). diff --git a/docs/content/connectors/toolreference/snyk.es.md b/docs/content/connectors/toolreference/snyk.es.md new file mode 100644 index 00000000000..f9c2e1f58ca --- /dev/null +++ b/docs/content/connectors/toolreference/snyk.es.md @@ -0,0 +1,14 @@ +--- +title: "Snyk" +description: "Cómo configurar el Conector Upstream de Snyk para DefectDojo" +weight: 125 +audience: pro +--- +El conector de Snyk usa la API REST de Snyk para obtener datos. + +#### Asignaciones del conector + +1. Ingrese **[https://api.snyk.io/rest](https://api.snyk.io/v1)** o **[https://api.eu.snyk.io/rest](https://api.eu.snyk.io/v1)** (para una implementación regional en la UE) en el campo **Location**. +2. Ingrese una API key válida en el campo **Secret**. Los API Tokens se encuentran en la **[Account Settings](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token)** [página](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token) de un usuario en Snyk. + +Consulte la [documentación de la API de Snyk](https://docs.snyk.io/snyk-api) para más información. diff --git a/docs/content/connectors/toolreference/snyk.fr.md b/docs/content/connectors/toolreference/snyk.fr.md new file mode 100644 index 00000000000..993fdd40902 --- /dev/null +++ b/docs/content/connectors/toolreference/snyk.fr.md @@ -0,0 +1,14 @@ +--- +title: "Snyk" +description: "Comment configurer le Connecteur Upstream Snyk pour DefectDojo" +weight: 125 +audience: pro +--- +Le connecteur Snyk utilise l'API REST de Snyk pour récupérer les données. + +#### Correspondances du connecteur + +1. Saisissez **[https://api.snyk.io/rest](https://api.snyk.io/v1)** ou **[https://api.eu.snyk.io/rest](https://api.eu.snyk.io/v1)** (pour un déploiement régional EU) dans le champ **Location**. +2. Saisissez une clé API valide dans le champ **Secret**. Les jetons API se trouvent dans les **[paramètres du compte](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token)** [utilisateur](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token) dans Snyk. + +Consultez la [documentation de l'API Snyk](https://docs.snyk.io/snyk-api) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/snyk.ja.md b/docs/content/connectors/toolreference/snyk.ja.md new file mode 100644 index 00000000000..6d5b2056680 --- /dev/null +++ b/docs/content/connectors/toolreference/snyk.ja.md @@ -0,0 +1,14 @@ +--- +title: "Snyk" +description: "DefectDojo で Snyk の Upstream Connector をセットアップする方法" +weight: 125 +audience: pro +--- +Snykコネクタは、Snyk REST APIを使用してデータを取得します。 + +#### Connector Mappings + +1. **Location** フィールドに **[https://api.snyk.io/rest](https://api.snyk.io/v1)** または(リージョナルなEUデプロイメントの場合)**[https://api.eu.snyk.io/rest](https://api.eu.snyk.io/v1)** を入力します。 +2. **Secret** フィールドに有効なAPIキーを入力します。APIトークンは、Snykのユーザーの**[アカウント設定](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token)**[ページ](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token)にあります。 + +詳細については[Snyk APIドキュメント](https://docs.snyk.io/snyk-api)を参照してください。 diff --git a/docs/content/connectors/toolreference/snyk.md b/docs/content/connectors/toolreference/snyk.md new file mode 100644 index 00000000000..a9d255b037f Binary files /dev/null and b/docs/content/connectors/toolreference/snyk.md differ diff --git a/docs/content/connectors/toolreference/socket.de.md b/docs/content/connectors/toolreference/socket.de.md new file mode 100644 index 00000000000..343306953b2 --- /dev/null +++ b/docs/content/connectors/toolreference/socket.de.md @@ -0,0 +1,21 @@ +--- +title: "Socket" +description: "Einrichtung des Socket Upstream-Connectors für DefectDojo" +weight: 126 +audience: pro +--- +Der Socket-Connector verwendet die API von [Socket.dev](https://socket.dev), um **Software-Supply-Chain-Befunde** zu importieren — Sockets Warnungen zu Ihren Abhängigkeiten (Malware, Typosquats, Install-Skripte, bekannte Schwachstellen und über 70 weitere Kategorien). DefectDojo ermittelt jedes Repository in den Organisationen, auf die Ihr Token zugreifen kann, und erstellt für jedes einen Eintrag; anschließend werden die Warnungen aus dem letzten vollständigen Scan dieses Repositorys importiert. + +#### Voraussetzungen + +Sie benötigen ein Socket-**API-Token** — ein Organisations-Token, das im Socket-Dashboard unter **Settings → API Tokens** erstellt wird (mit den Scopes `repo:list` und Full-Scan-Lesezugriff). Das Token wird als Bearer-Token gesendet und nie protokolliert. + +#### Connector-Zuordnungen + +1. Lassen Sie das Feld **Location** leer, um `https://api.socket.dev/v0` zu verwenden, oder geben Sie es explizit an. +2. Geben Sie das Socket-API-Token in das Feld **Secret** ein. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +DefectDojo ordnet jedes **Repository** einem Eintrag zu und importiert die Warnungen aus dessen letztem vollständigen Scan. Jede Warnung wird zu einem Befund: Der Schweregrad stammt aus Sockets eigener Bewertung (low, medium, high, critical), das betroffene Paket wird zur Komponente und zu einer PURL, die Warnungskategorie (Supply-Chain-Risiko, Qualität, Wartung, Schwachstelle, Lizenz) wird als Tags erfasst, und die Warnungsdetails werden in die Beschreibung übernommen. Befunde werden als statische Befunde erfasst und anhand des Socket-Warnungsschlüssels dedupliziert. + +Weitere Informationen finden Sie in der [Socket-API-Dokumentation](https://docs.socket.dev/reference). diff --git a/docs/content/connectors/toolreference/socket.es.md b/docs/content/connectors/toolreference/socket.es.md new file mode 100644 index 00000000000..22bbaf79a77 --- /dev/null +++ b/docs/content/connectors/toolreference/socket.es.md @@ -0,0 +1,21 @@ +--- +title: "Socket" +description: "Cómo configurar el Conector Upstream de Socket para DefectDojo" +weight: 126 +audience: pro +--- +El conector de Socket usa la API de [Socket.dev](https://socket.dev) para importar **hallazgos de la cadena de suministro de software** — las alertas de Socket sobre sus dependencias (malware, typosquatting, scripts de instalación, vulnerabilidades conocidas y más de 70 categorías adicionales). DefectDojo descubre todos los repositorios de las organizaciones a las que su token tiene acceso y crea un Record para cada uno, luego importa las alertas del análisis completo más reciente de ese repositorio. + +#### Prerrequisitos + +Necesitará un **token de API** de Socket — un token de organización creado en el panel de Socket en **Settings → API Tokens** (con los alcances `repo:list` y de lectura de full-scan). El token se envía como bearer token y nunca se registra en los logs. + +#### Asignaciones del conector + +1. Deje el campo **Location** en blanco para usar `https://api.socket.dev/v0`, o introdúzcalo explícitamente. +2. Introduzca el token de API de Socket en el campo **Secret**. +3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +DefectDojo asigna cada **repositorio** a un Record e importa las alertas de su análisis completo más reciente. Cada alerta se convierte en un hallazgo: la severidad proviene de la propia calificación de Socket (low, medium, high, critical), el paquete afectado se convierte en el componente y en un PURL, la categoría de la alerta (riesgo de cadena de suministro, calidad, mantenimiento, vulnerabilidad, licencia) se registra como etiquetas, y los detalles de la alerta se incorporan a la descripción. Los hallazgos se registran como hallazgos estáticos y se deduplican según la clave de alerta de Socket. + +Consulte la [documentación de la API de Socket](https://docs.socket.dev/reference) para más información. diff --git a/docs/content/connectors/toolreference/socket.fr.md b/docs/content/connectors/toolreference/socket.fr.md new file mode 100644 index 00000000000..3ca99ebdf5d --- /dev/null +++ b/docs/content/connectors/toolreference/socket.fr.md @@ -0,0 +1,21 @@ +--- +title: "Socket" +description: "Comment configurer le Connecteur Upstream Socket pour DefectDojo" +weight: 126 +audience: pro +--- +Le connecteur Socket utilise l'API [Socket.dev](https://socket.dev) pour importer des **constatations de sécurité de la chaîne d'approvisionnement logicielle** — les alertes de Socket sur vos dépendances (logiciels malveillants, typosquats, scripts d'installation, vulnérabilités connues et plus de 70 autres catégories). DefectDojo découvre chaque dépôt dans les organisations auxquelles votre jeton a accès et crée un Enregistrement pour chacun, puis importe les alertes du dernier scan complet de ce dépôt. + +#### Prérequis + +Vous aurez besoin d'un **jeton API** Socket — un jeton d'organisation créé dans le tableau de bord Socket sous **Settings → API Tokens** (avec les portées `repo:list` et de lecture des scans complets). Le jeton est envoyé en tant que jeton porteur (bearer) et n'est jamais journalisé. + +#### Mappages du connecteur + +1. Laissez le champ **Location** vide pour utiliser `https://api.socket.dev/v0`, ou saisissez-le explicitement. +2. Saisissez le jeton API Socket dans le champ **Secret**. +3. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +DefectDojo associe chaque **dépôt** à un Enregistrement et importe les alertes de son scan complet le plus récent. Chaque alerte devient une constatation : la sévérité provient de la propre notation de Socket (low, medium, high, critical), le paquet concerné devient le composant et un PURL, la catégorie de l'alerte (risque de chaîne d'approvisionnement, qualité, maintenance, vulnérabilité, licence) est enregistrée sous forme d'étiquettes, et les détails de l'alerte sont repris dans la description. Les constatations sont enregistrées comme des constatations statiques et dédupliquées sur la clé d'alerte de Socket. + +Consultez la [documentation de l'API Socket](https://docs.socket.dev/reference) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/socket.ja.md b/docs/content/connectors/toolreference/socket.ja.md new file mode 100644 index 00000000000..186ffded54d --- /dev/null +++ b/docs/content/connectors/toolreference/socket.ja.md @@ -0,0 +1,21 @@ +--- +title: "Socket" +description: "DefectDojo で Socket の Upstream Connector をセットアップする方法" +weight: 126 +audience: pro +--- +Socket コネクタは [Socket.dev](https://socket.dev) API を使用して、**ソフトウェアサプライチェーンの検出事項**（依存関係に対する Socket のアラート — マルウェア、タイポスクワッティング、インストールスクリプト、既知の脆弱性、その他 70 以上のカテゴリ）をインポートします。DefectDojo はトークンがアクセスできる組織内のすべてのリポジトリを検出し、それぞれに対して Record を作成した上で、そのリポジトリの最新のフルスキャンからアラートをインポートします。 + +#### Prerequisites + +Socket の **API トークン**（Socket ダッシュボードの **Settings → API Tokens** で作成する組織トークンで、`repo:list` とフルスキャンの読み取りスコープを持つもの）が必要です。トークンはベアラートークンとして送信され、ログに記録されることはありません。 + +#### Connector Mappings + +1. **Location** フィールドを空欄のままにすると `https://api.socket.dev/v0` が使用されます。明示的に入力することもできます。 +2. **Secret** フィールドに Socket API トークンを入力します。 +3. 必要に応じて、**Minimum Severity** を設定してインポートする検出事項を絞り込みます。 + +DefectDojo は各**リポジトリ**を Record にマッピングし、その最新のフルスキャンからアラートをインポートします。各アラートは検出事項になります。深刻度は Socket 自身の評価(low、medium、high、critical)に基づき、影響を受けるパッケージはコンポーネントおよび PURL になり、アラートのカテゴリ(サプライチェーンリスク、品質、メンテナンス、脆弱性、ライセンス)はタグとして記録され、アラートの詳細は説明に反映されます。検出事項は静的検出事項として記録され、Socket のアラートキーで重複排除されます。 + +詳細については、[Socket API ドキュメント](https://docs.socket.dev/reference)を参照してください。 diff --git a/docs/content/connectors/toolreference/socket.md b/docs/content/connectors/toolreference/socket.md new file mode 100644 index 00000000000..2900471226d --- /dev/null +++ b/docs/content/connectors/toolreference/socket.md @@ -0,0 +1,21 @@ +--- +title: "Socket" +description: "How to set up the Socket Upstream Connector for DefectDojo" +weight: 126 +audience: pro +--- +The Socket connector uses the [Socket.dev](https://socket.dev) API to import **software supply-chain findings** — Socket's alerts on your dependencies (malware, typosquats, install scripts, known vulnerabilities and 70+ other categories). DefectDojo discovers every repository across the organizations your token can access and creates a Record for each, then imports the alerts from that repository's latest full scan. + +#### Prerequisites + +You will need a Socket **API token** — an organization token created in the Socket dashboard under **Settings → API Tokens** (with the `repo:list` and full-scan read scopes). The token is sent as a bearer token and is never logged. + +#### Connector Mappings + +1. Leave the **Location** field blank to use `https://api.socket.dev/v0`, or enter it explicitly. +2. Enter the Socket API token in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +DefectDojo maps each **repository** to a Record and imports the alerts from its most recent full scan. Each alert becomes a finding: the severity comes from Socket's own rating (low, medium, high, critical), the affected package becomes the component and a PURL, the alert category (supply-chain risk, quality, maintenance, vulnerability, license) is recorded as tags, and the alert details are carried into the description. Findings are recorded as static findings and de-duplicated on Socket's alert key. + +See the [Socket API documentation](https://docs.socket.dev/reference) for more information. diff --git a/docs/content/connectors/toolreference/sonarqube.de.md b/docs/content/connectors/toolreference/sonarqube.de.md new file mode 100644 index 00000000000..9a03c95fb08 --- /dev/null +++ b/docs/content/connectors/toolreference/sonarqube.de.md @@ -0,0 +1,21 @@ +--- +title: "SonarQube" +description: "Einrichtung des SonarQube Upstream-Connectors für DefectDojo" +weight: 127 +audience: pro +--- +Der SonarQube-Connector kann Daten entweder von einem SonarCloud-Konto oder von einer lokalen SonarQube-Instanz abrufen. + +**Für SonarCloud-Benutzer:** + +1. Geben Sie https://sonarcloud.io/ in das Feld Location ein. +2. Geben Sie einen gültigen **API-Schlüssel** in das Feld Secret ein. + +**Für SonarQube-Benutzer (On-Premise):** + +1. Geben Sie die Basis-URL Ihrer SonarQube-Instanz in das Feld Location ein: zum Beispiel `https://my.sonarqube.com/` +2. Geben Sie einen gültigen **API-Schlüssel** in das Feld Secret ein. Dies muss ein **[User](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/)**-[API-Token-Typ](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/) sein. + +Das Token benötigt Zugriff auf Projects, Vulnerabilities und Hotspots innerhalb von Sonar. + +API-Tokens finden und generieren Sie über **My Account \-\> Security \-\> Generate Token** in der SonarQube-App. Weitere Informationen finden Sie in der [SonarQube-Dokumentation](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/). diff --git a/docs/content/connectors/toolreference/sonarqube.es.md b/docs/content/connectors/toolreference/sonarqube.es.md new file mode 100644 index 00000000000..5744ac20910 --- /dev/null +++ b/docs/content/connectors/toolreference/sonarqube.es.md @@ -0,0 +1,21 @@ +--- +title: "SonarQube" +description: "Cómo configurar el Conector Upstream de SonarQube para DefectDojo" +weight: 127 +audience: pro +--- +El conector de SonarQube puede obtener datos tanto de una cuenta de SonarCloud como de una instancia local de SonarQube. + +**Para usuarios de SonarCloud:** + +1. Ingrese https://sonarcloud.io/ en el campo Location. +2. Ingrese una **API key** válida en el campo Secret. + +**Para usuarios de SonarQube (on-premise):** + +1. Ingrese la URL base de su instancia de SonarQube en el campo Location: por ejemplo, `https://my.sonarqube.com/` +2. Ingrese una **API key** válida en el campo Secret. Deberá ser un **[User](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/)** [API Token Type](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/). + +El token deberá tener acceso a Projects, Vulnerabilities y Hotspots dentro de Sonar. + +Los tokens de API se pueden encontrar y generar a través de **My Account -> Security -> Generate Token** en la aplicación de SonarQube. Para más información, [consulte la documentación de SonarQube](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/). diff --git a/docs/content/connectors/toolreference/sonarqube.fr.md b/docs/content/connectors/toolreference/sonarqube.fr.md new file mode 100644 index 00000000000..18eddfaee5f --- /dev/null +++ b/docs/content/connectors/toolreference/sonarqube.fr.md @@ -0,0 +1,21 @@ +--- +title: "SonarQube" +description: "Comment configurer le Connecteur Upstream SonarQube pour DefectDojo" +weight: 127 +audience: pro +--- +Le connecteur SonarQube peut récupérer des données soit depuis un compte SonarCloud, soit depuis une instance SonarQube locale. + +**Pour les utilisateurs de SonarCloud :** + +1. Saisissez https://sonarcloud.io/ dans le champ Location. +2. Saisissez une **clé API** valide dans le champ Secret. + +**Pour les utilisateurs de SonarQube (sur site) :** + +1. Saisissez l'URL de base de votre instance SonarQube dans le champ Location : par exemple `https://my.sonarqube.com/` +2. Saisissez une **clé API** valide dans le champ Secret. Il devra s'agir d'un **[User](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/)** [type de jeton API](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/). + +Le jeton devra avoir accès aux Projects, Vulnerabilities et Hotspots dans Sonar. + +Les clés API peuvent être trouvées et générées via **My Account \-\> Security \-\> Generate Token** dans l'application SonarQube. Pour plus d'informations, [consultez la documentation SonarQube](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/). diff --git a/docs/content/connectors/toolreference/sonarqube.ja.md b/docs/content/connectors/toolreference/sonarqube.ja.md new file mode 100644 index 00000000000..d1322d1c710 --- /dev/null +++ b/docs/content/connectors/toolreference/sonarqube.ja.md @@ -0,0 +1,21 @@ +--- +title: "SonarQube" +description: "DefectDojo で SonarQube の Upstream Connector をセットアップする方法" +weight: 127 +audience: pro +--- +SonarQubeコネクタは、SonarCloudアカウントまたはローカルのSonarQubeインスタンスのいずれからでもデータを取得できます。 + +**SonarCloudユーザーの場合:** + +1. Locationフィールドに https://sonarcloud.io/ を入力します。 +2. Secretフィールドに有効な**APIキー**を入力します。 + +**SonarQube(オンプレミス)ユーザーの場合:** + +1. Locationフィールドにお使いのSonarQubeインスタンスのベースURLを入力します: 例 `https://my.sonarqube.com/` +2. Secretフィールドに有効な**APIキー**を入力します。これは**[User](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/)** [APIトークンタイプ](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/)である必要があります。 + +このトークンには、Sonar内のProjects、Vulnerabilities、Hotspotsへのアクセス権が必要です。 + +APIトークンは、SonarQubeアプリの **My Account -> Security -> Generate Token** から確認・生成できます。詳細については、[SonarQubeドキュメントを参照してください](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/)。 diff --git a/docs/content/connectors/toolreference/sonarqube.md b/docs/content/connectors/toolreference/sonarqube.md new file mode 100644 index 00000000000..eec2e1b4b0c --- /dev/null +++ b/docs/content/connectors/toolreference/sonarqube.md @@ -0,0 +1,21 @@ +--- +title: "SonarQube" +description: "How to set up the SonarQube Upstream Connector for DefectDojo" +weight: 127 +audience: pro +--- +The SonarQube Connector can fetch data from either a SonarCloud account or from a local SonarQube instance. + +**For SonarCloud users:** + +1. Enter https://sonarcloud.io/ in the Location field. +2. Enter a valid **API key** in the Secret field. + +**For SonarQube (on\-premise) users:** + +1. Enter the base url of your SonarQube instance in the Location field: for example `https://my.sonarqube.com/` +2. Enter a valid **API key** in the Secret field. This will need to be a **[User](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/)** [API Token Type](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/). + +The token will need to have access to Projects, Vulnerabilities and Hotspots within Sonar. + +API tokens can be found and generated via **My Account \-\> Security \-\> Generate Token** in the SonarQube app. For more information, [see SonarQube documentation](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/). diff --git a/docs/content/connectors/toolreference/sonatype_iq.de.md b/docs/content/connectors/toolreference/sonatype_iq.de.md new file mode 100644 index 00000000000..ae490f5fa6e --- /dev/null +++ b/docs/content/connectors/toolreference/sonatype_iq.de.md @@ -0,0 +1,21 @@ +--- +title: "Sonatype IQ" +description: "Einrichtung des Sonatype IQ Upstream-Connectors für DefectDojo" +weight: 128 +audience: pro +--- +Der Sonatype-IQ-Connector verwendet die REST-API des Sonatype-IQ-Servers (Nexus Lifecycle), um Open-Source-Komponentenschwachstellen zu importieren. Er zählt jede Anwendung in Ihrer IQ-Organisation auf und importiert für jede die Komponentenschwachstellen aus dem letzten Bericht dieser Anwendung auf der von Ihnen konfigurierten Lifecycle-Stufe. DefectDojo erstellt automatisch für jede Anwendung einen Eintrag — es gibt keine Pro-Anwendungs-Konfiguration. + +#### Voraussetzungen + +Sie benötigen ein Sonatype-IQ-Benutzerkonto mit der Berechtigung **View IQ Elements** für die zu importierenden Anwendungen. Sonatype empfiehlt die Authentifizierung mit einem **User Token** (generiert unter **My Profile > User Token** im IQ Server) statt eines Passworts; die beiden Teile des Tokens werden unten den Feldern Username und User Token zugeordnet. Der Connector funktioniert sowohl mit selbstgehostetem IQ Server als auch mit von Sonatype gehosteten (SaaS-)Instanzen. + +#### Connector-Zuordnungen + +1. Geben Sie im Feld **Location** die Basis-URL Ihres IQ-Servers ein — für einen selbstgehosteten Server `https://iq.example.com`; für eine von Sonatype gehostete Instanz `https://.sonatype.app/platform`. +2. Geben Sie den IQ-Benutzer (oder den User-Code-Teil Ihres User Tokens) in das Feld **Username** ein. +3. Geben Sie das IQ-User-Token (oder das Passwort) in das Feld **User Token** ein. +4. Legen Sie optional eine **Stage** fest, um zu wählen, dessen Bericht pro Anwendung importiert wird (`build`, `stage-release`, `release` usw.). Leer lassen, um `build` zu verwenden. +5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jede Anwendung wird zu einem Eintrag, und jedes Sicherheitsproblem im letzten Bericht dieser Anwendung für die gewählte Stufe wird als Befund importiert. Der Schweregrad wird aus dem numerischen Score des Issues abgeleitet, und CVE-Referenzen, die CWE, der CVSS-Vektor sowie die Package-URL (PURL) der betroffenen Komponente werden einbezogen, sofern verfügbar. diff --git a/docs/content/connectors/toolreference/sonatype_iq.es.md b/docs/content/connectors/toolreference/sonatype_iq.es.md new file mode 100644 index 00000000000..21d656b76ed --- /dev/null +++ b/docs/content/connectors/toolreference/sonatype_iq.es.md @@ -0,0 +1,21 @@ +--- +title: "Sonatype IQ" +description: "Cómo configurar el Conector Upstream de Sonatype IQ para DefectDojo" +weight: 128 +audience: pro +--- +El conector de Sonatype IQ usa la API REST del servidor Sonatype IQ (Nexus Lifecycle) para importar vulnerabilidades de componentes de código abierto. Enumera todas las aplicaciones de su organización de IQ y, para cada una, importa las vulnerabilidades de componentes del informe más reciente de esa aplicación en la etapa del ciclo de vida que configure. DefectDojo crea un Record para cada aplicación automáticamente — no hay configuración por aplicación. + +#### Prerrequisitos + +Necesitará una cuenta de usuario de Sonatype IQ con el permiso **View IQ Elements** en las aplicaciones que desea importar. Sonatype recomienda autenticarse con un **user token** (generado en **My Profile > User Token** en IQ Server) en lugar de una contraseña; las dos partes del token se corresponden con los campos Username y User Token que aparecen a continuación. El conector funciona tanto con instancias de IQ Server autoalojadas como con instancias alojadas por Sonatype (SaaS). + +#### Asignaciones del conector + +1. En el campo **Location**, introduzca la URL base de su IQ Server — para un servidor autoalojado, `https://iq.example.com`; para una instancia alojada por Sonatype, `https://.sonatype.app/platform`. +2. Introduzca el usuario de IQ (o la parte de código de usuario de su user token) en el campo **Username**. +3. Introduzca el user token de IQ (o la contraseña) en el campo **User Token**. +4. Opcionalmente, establezca un **Stage** para elegir de qué etapa del ciclo de vida se importa el informe por aplicación (`build`, `stage-release`, `release`, etc.). Déjelo en blanco para usar `build`. +5. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada aplicación se convierte en un Record, y cada problema de seguridad en el informe más reciente de esa aplicación para la etapa seleccionada se importa como un hallazgo. La severidad se deriva de la puntuación numérica del problema, y se incluyen las referencias CVE, el CWE, el vector CVSS y la URL del paquete (PURL) del componente afectado cuando están disponibles. diff --git a/docs/content/connectors/toolreference/sonatype_iq.fr.md b/docs/content/connectors/toolreference/sonatype_iq.fr.md new file mode 100644 index 00000000000..a34fad4fee8 --- /dev/null +++ b/docs/content/connectors/toolreference/sonatype_iq.fr.md @@ -0,0 +1,21 @@ +--- +title: "Sonatype IQ" +description: "Comment configurer le Connecteur Upstream Sonatype IQ pour DefectDojo" +weight: 128 +audience: pro +--- +Le connecteur Sonatype IQ utilise l'API REST du serveur Sonatype IQ (Nexus Lifecycle) pour importer les vulnérabilités des composants open source. Il recense chaque application de votre organisation IQ et, pour chacune, importe les vulnérabilités de composants du dernier rapport de cette application à l'étape du cycle de vie que vous configurez. DefectDojo crée automatiquement un Enregistrement pour chaque application — il n'y a pas de configuration par application. + +#### Prérequis + +Vous aurez besoin d'un compte utilisateur Sonatype IQ disposant de la permission **View IQ Elements** sur les applications que vous souhaitez importer. Sonatype recommande de s'authentifier avec un **jeton utilisateur** (généré sous **My Profile > User Token** dans IQ Server) plutôt qu'avec un mot de passe ; les deux parties du jeton correspondent aux champs Username et User Token ci-dessous. Le connecteur fonctionne aussi bien avec un serveur IQ auto-hébergé qu'avec une instance hébergée par Sonatype (SaaS). + +#### Mappages du connecteur + +1. Dans le champ **Location**, saisissez l'URL de base de votre serveur IQ — pour un serveur auto-hébergé, `https://iq.example.com` ; pour une instance hébergée par Sonatype, `https://.sonatype.app/platform`. +2. Saisissez l'utilisateur IQ (ou la partie code utilisateur de votre jeton utilisateur) dans le champ **Username**. +3. Saisissez le jeton utilisateur IQ (ou le mot de passe) dans le champ **User Token**. +4. Optionnellement, définissez un **Stage** pour choisir l'étape du cycle de vie dont le rapport est importé pour chaque application (`build`, `stage-release`, `release`, etc.). Laissez vide pour utiliser `build`. +5. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque application devient un Enregistrement, et chaque problème de sécurité du dernier rapport de cette application pour l'étape sélectionnée est importé comme constatation. La sévérité est dérivée du score numérique du problème, et les références CVE, le CWE, le vecteur CVSS et l'URL de paquet (PURL) du composant concerné sont inclus lorsqu'ils sont disponibles. diff --git a/docs/content/connectors/toolreference/sonatype_iq.ja.md b/docs/content/connectors/toolreference/sonatype_iq.ja.md new file mode 100644 index 00000000000..81729205539 --- /dev/null +++ b/docs/content/connectors/toolreference/sonatype_iq.ja.md @@ -0,0 +1,21 @@ +--- +title: "Sonatype IQ" +description: "DefectDojo で Sonatype IQ の Upstream Connector をセットアップする方法" +weight: 128 +audience: pro +--- +Sonatype IQ コネクタは Sonatype IQ Server(Nexus Lifecycle)の REST API を使用して、オープンソースコンポーネントの脆弱性をインポートします。IQ 組織内のすべてのアプリケーションを列挙し、それぞれについて、設定したライフサイクルステージにおけるそのアプリケーションの最新レポートからコンポーネントの脆弱性をインポートします。DefectDojo は各アプリケーションに対して自動的に Record を作成します — アプリケーションごとの設定は不要です。 + +#### Prerequisites + +インポートしたいアプリケーションに対して **View IQ Elements** 権限を持つ Sonatype IQ ユーザーアカウントが必要です。Sonatype はパスワードではなく、(IQ Server の **My Profile > User Token** で生成する)**ユーザートークン**を使用した認証を推奨しています。トークンの 2 つの部分は、以下の Username フィールドと User Token フィールドにそれぞれ対応します。このコネクタはセルフホスト型の IQ Server と、Sonatype がホストする(SaaS)インスタンスの両方に対応しています。 + +#### Connector Mappings + +1. **Location** フィールドに IQ Server のベース URL を入力します — セルフホスト型サーバーの場合は `https://iq.example.com`、Sonatype がホストするインスタンスの場合は `https://.sonatype.app/platform` です。 +2. **Username** フィールドに IQ ユーザー(またはユーザートークンのユーザーコード部分)を入力します。 +3. **User Token** フィールドに IQ ユーザートークン(またはパスワード)を入力します。 +4. 必要に応じて、**Stage** を設定して、アプリケーションごとにどのライフサイクルステージのレポートをインポートするかを選択します(`build`、`stage-release`、`release` など)。空欄のままにすると `build` が使用されます。 +5. 必要に応じて、**Minimum Severity** を設定してインポートする検出事項を絞り込みます。 + +各アプリケーションは Record になり、選択したステージにおけるそのアプリケーションの最新レポート内の各セキュリティ問題が検出事項としてインポートされます。深刻度は問題の数値スコアから導出され、CVE 参照、CWE、CVSS ベクター、影響を受けるコンポーネントのパッケージ URL(PURL)が利用可能な場合は含まれます。 diff --git a/docs/content/connectors/toolreference/sonatype_iq.md b/docs/content/connectors/toolreference/sonatype_iq.md new file mode 100644 index 00000000000..8495482537c --- /dev/null +++ b/docs/content/connectors/toolreference/sonatype_iq.md @@ -0,0 +1,21 @@ +--- +title: "Sonatype IQ" +description: "How to set up the Sonatype IQ Upstream Connector for DefectDojo" +weight: 128 +audience: pro +--- +The Sonatype IQ connector uses the Sonatype IQ Server (Nexus Lifecycle) REST API to import open\-source component vulnerabilities. It enumerates every application in your IQ organization and, for each one, imports the component vulnerabilities from that application's latest report at the lifecycle stage you configure. DefectDojo creates a Record for each application automatically — there is no per\-application configuration. + +#### Prerequisites + +You will need a Sonatype IQ user account with the **View IQ Elements** permission on the applications you want to import. Sonatype recommends authenticating with a **user token** (generated under **My Profile > User Token** in IQ Server) rather than a password; the token's two parts map to the Username and User Token fields below. The connector works with both self\-hosted IQ Server and Sonatype\-hosted (SaaS) instances. + +#### Connector Mappings + +1. In the **Location** field, enter your IQ Server base URL — for a self\-hosted server, `https://iq.example.com`; for a Sonatype\-hosted instance, `https://.sonatype.app/platform`. +2. Enter the IQ user (or the user\-code part of your user token) in the **Username** field. +3. Enter the IQ user token (or password) in the **User Token** field. +4. Optionally, set a **Stage** to choose which lifecycle stage's report is imported per application (`build`, `stage-release`, `release`, and so on). Leave it blank to use `build`. +5. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each application becomes a Record, and each security issue in that application's latest report for the selected stage is imported as a finding. Severity is derived from the issue's numeric score, and CVE references, CWE, the CVSS vector, and the affected component's package URL (PURL) are included where available. diff --git a/docs/content/connectors/toolreference/soos.md b/docs/content/connectors/toolreference/soos.md new file mode 100644 index 00000000000..e0d2774a2cf --- /dev/null +++ b/docs/content/connectors/toolreference/soos.md @@ -0,0 +1,25 @@ +--- +title: "SOOS" +description: "How to set up the SOOS Upstream Connector for DefectDojo" +weight: 129 +audience: pro +--- +The SOOS connector imports **SCA findings** from SOOS. DefectDojo creates a Record for each **project** on the account. + +#### Prerequisites + +**Two credentials — neither works on its own:** + +* Your **Client ID**, which forms part of every request path. +* Your **API Key**, sent as a request header. + +Both are found under **SOOS \> Integrations**. + +#### Connector Mappings + +1. Enter `https://api.soos.io/api/` in the **Location** field. +2. Enter your SOOS **Client ID**. +3. Enter your SOOS **API Key**. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each project becomes a Record, carrying its scanned dependencies' vulnerabilities. diff --git a/docs/content/connectors/toolreference/sysdig_secure.de.md b/docs/content/connectors/toolreference/sysdig_secure.de.md new file mode 100644 index 00000000000..e51ec06ac3b --- /dev/null +++ b/docs/content/connectors/toolreference/sysdig_secure.de.md @@ -0,0 +1,21 @@ +--- +title: "Sysdig Secure" +description: "Einrichtung des Sysdig Secure Upstream-Connectors für DefectDojo" +weight: 130 +audience: pro +--- +Der Sysdig-Secure-Connector importiert **Container-/CNAPP-Schwachstellenbefunde** über die Vulnerability-Management-API von Sysdig Secure. Er synchronisiert das gesamte Konto über die konfigurierten Geltungsbereich(e) und erstellt für jede gescannte Asset-Gruppierung ein DefectDojo-Produkt. + +#### Voraussetzungen + +Ein Sysdig-Secure-**API-Token**: Gehen Sie in Sysdig Secure zu **Settings \> Sysdig Secure API Token** und kopieren Sie das Token. Sie benötigen außerdem Ihre Sysdig-**Region-URL** (zum Beispiel `https://us2.app.sysdig.com`, `https://eu1.app.sysdig.com`, oder Ihren On-Premises-Host). + +#### Connector-Zuordnungen + +1. Geben Sie Ihre Sysdig-Region-/Basis-URL in das Feld **Location** ein. +2. Geben Sie das API-Token in das Feld **Secret** ein. +3. Legen Sie optional **Scopes** fest — eine kommagetrennte Liste aus `runtime`, `registry` und/oder `pipeline` (leer lassen für `runtime`, den Geltungsbereich bereitgestellter Workloads). +4. Legen Sie optional **Runtime Product Grouping** fest — wie Runtime-Ergebnisse auf Produkte abgebildet werden: `cluster`, `namespace`, `workload` oder `image` (leer lassen für `namespace`). Registry- und Pipeline-Ergebnisse werden immer nach Image-Repository gruppiert. +5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jede Asset-Gruppierung wird zu einem Eintrag. Für jedes Scan-Ergebnis importiert der Connector jedes anfällige Paket als Befund. **Runtime**-Befunde (bereitgestellte Workloads) werden als dynamische Befunde erfasst und mit ihrem Kubernetes-Kontext (Cluster/Namespace/Workload/Container) getaggt; **Registry**- und **Pipeline**-Befunde werden als statische Image-Scan-Befunde erfasst. Sysdigs Schweregrad `NEGLIGIBLE` wird auf Info abgebildet. diff --git a/docs/content/connectors/toolreference/sysdig_secure.es.md b/docs/content/connectors/toolreference/sysdig_secure.es.md new file mode 100644 index 00000000000..fb370159c7a --- /dev/null +++ b/docs/content/connectors/toolreference/sysdig_secure.es.md @@ -0,0 +1,21 @@ +--- +title: "Sysdig Secure" +description: "Cómo configurar el Conector Upstream de Sysdig Secure para DefectDojo" +weight: 130 +audience: pro +--- +El conector de Sysdig Secure importa **hallazgos de vulnerabilidades de contenedores / CNAPP** desde la API de gestión de vulnerabilidades de Sysdig Secure. Sincroniza toda la cuenta en el/los alcance(s) configurado(s) y crea un producto de DefectDojo para cada agrupación de activos escaneados. + +#### Prerrequisitos + +Un **token de API** de Sysdig Secure: en Sysdig Secure, vaya a **Settings > Sysdig Secure API Token** y copie el token. También necesita la **URL de región** de Sysdig (por ejemplo, `https://us2.app.sysdig.com`, `https://eu1.app.sysdig.com`, o su host on-premises). + +#### Asignaciones del conector + +1. Introduzca la URL de región/base de Sysdig en el campo **Location**. +2. Introduzca el token de API en el campo **Secret**. +3. Opcionalmente, establezca **Scopes** — una lista separada por comas de `runtime`, `registry`, y/o `pipeline` (déjelo en blanco para `runtime`, el alcance de cargas de trabajo desplegadas). +4. Opcionalmente, establezca **Runtime Product Grouping** — cómo se asignan los resultados de runtime a los productos: `cluster`, `namespace`, `workload`, o `image` (déjelo en blanco para `namespace`). Los resultados de registry y pipeline siempre se agrupan por repositorio de imágenes. +5. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada agrupación de activos se convierte en un Record. Para cada resultado de análisis, el conector importa cada paquete vulnerable como un hallazgo. Los hallazgos de **runtime** (cargas de trabajo desplegadas) se registran como hallazgos dinámicos y se etiquetan con su contexto de clúster/namespace/workload/contenedor de Kubernetes; los hallazgos de **registry** y **pipeline** se registran como hallazgos estáticos de análisis de imágenes. La severidad `NEGLIGIBLE` de Sysdig se asigna a Informativa. diff --git a/docs/content/connectors/toolreference/sysdig_secure.fr.md b/docs/content/connectors/toolreference/sysdig_secure.fr.md new file mode 100644 index 00000000000..8c415e87593 --- /dev/null +++ b/docs/content/connectors/toolreference/sysdig_secure.fr.md @@ -0,0 +1,21 @@ +--- +title: "Sysdig Secure" +description: "Comment configurer le Connecteur Upstream Sysdig Secure pour DefectDojo" +weight: 130 +audience: pro +--- +Le connecteur Sysdig Secure importe des **constatations de vulnérabilité de conteneurs / CNAPP** depuis l'API de gestion des vulnérabilités de Sysdig Secure. Il synchronise l'intégralité du compte sur le ou les périmètres configurés et crée un produit DefectDojo pour chaque regroupement d'actifs analysé. + +#### Prérequis + +Un **jeton API** Sysdig Secure : dans Sysdig Secure, allez dans **Settings > Sysdig Secure API Token** et copiez le jeton. Vous avez également besoin de l'**URL de région** Sysdig (par exemple `https://us2.app.sysdig.com`, `https://eu1.app.sysdig.com`, ou votre hôte sur site). + +#### Mappages du connecteur + +1. Saisissez votre région/URL de base Sysdig dans le champ **Location**. +2. Saisissez le jeton API dans le champ **Secret**. +3. Optionnellement, définissez **Scopes** — une liste séparée par des virgules de `runtime`, `registry` et/ou `pipeline` (laissez vide pour `runtime`, le périmètre des charges de travail déployées). +4. Optionnellement, définissez **Runtime Product Grouping** — la façon dont les résultats runtime sont associés aux produits : `cluster`, `namespace`, `workload` ou `image` (laissez vide pour `namespace`). Les résultats registry et pipeline sont toujours regroupés par dépôt d'images. +5. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque regroupement d'actifs devient un Enregistrement. Pour chaque résultat de scan, le connecteur importe chaque paquet vulnérable comme constatation. Les constatations **Runtime** (charges de travail déployées) sont enregistrées comme des constatations dynamiques et étiquetées avec leur contexte Kubernetes cluster / namespace / workload / conteneur ; les constatations **registry** et **pipeline** sont enregistrées comme des constatations statiques d'analyse d'image. La sévérité `NEGLIGIBLE` de Sysdig est associée à Info. diff --git a/docs/content/connectors/toolreference/sysdig_secure.ja.md b/docs/content/connectors/toolreference/sysdig_secure.ja.md new file mode 100644 index 00000000000..08cdb3ce39a --- /dev/null +++ b/docs/content/connectors/toolreference/sysdig_secure.ja.md @@ -0,0 +1,21 @@ +--- +title: "Sysdig Secure" +description: "DefectDojo で Sysdig Secure の Upstream Connector をセットアップする方法" +weight: 130 +audience: pro +--- +Sysdig Secure コネクタは、Sysdig Secure の脆弱性管理 API から**コンテナ / CNAPP 脆弱性検出事項**をインポートします。設定されたスコープ全体でアカウント全体を同期し、スキャン対象のアセットグループごとに DefectDojo 製品を作成します。 + +#### Prerequisites + +Sysdig Secure の **API トークン**: Sysdig Secure で **Settings > Sysdig Secure API Token** に移動し、トークンをコピーします。また、Sysdig の**リージョン URL**(例: `https://us2.app.sysdig.com`、`https://eu1.app.sysdig.com`、またはオンプレミスホスト)も必要です。 + +#### Connector Mappings + +1. **Location** フィールドに Sysdig のリージョン / ベース URL を入力します。 +2. **Secret** フィールドに API トークンを入力します。 +3. 必要に応じて **Scopes** を設定します — `runtime`、`registry`、`pipeline` のカンマ区切りリストです(空欄の場合はデプロイ済みワークロードのスコープである `runtime` になります)。 +4. 必要に応じて **Runtime Product Grouping** を設定します — ランタイムの結果を製品にどうマッピングするか(`cluster`、`namespace`、`workload`、`image`)を指定します(空欄の場合は `namespace` になります)。レジストリおよびパイプラインの結果は常にイメージリポジトリ単位でグループ化されます。 +5. 必要に応じて、**Minimum Severity** を設定してインポートする検出事項を絞り込みます。 + +各アセットグループは Record になります。各スキャン結果について、コネクタは脆弱性のあるすべてのパッケージを検出事項としてインポートします。**Runtime** の検出事項(デプロイ済みワークロード)は動的検出事項として記録され、Kubernetes のクラスター / 名前空間 / ワークロード / コンテナのコンテキストがタグ付けされます。**registry** および **pipeline** の検出事項は静的なイメージスキャン検出事項として記録されます。Sysdig の `NEGLIGIBLE` 深刻度は Info にマッピングされます。 diff --git a/docs/content/connectors/toolreference/sysdig_secure.md b/docs/content/connectors/toolreference/sysdig_secure.md new file mode 100644 index 00000000000..30e0385b213 --- /dev/null +++ b/docs/content/connectors/toolreference/sysdig_secure.md @@ -0,0 +1,21 @@ +--- +title: "Sysdig Secure" +description: "How to set up the Sysdig Secure Upstream Connector for DefectDojo" +weight: 130 +audience: pro +--- +The Sysdig Secure connector imports **container / CNAPP vulnerability findings** from Sysdig Secure's vulnerability management API. It syncs the whole account across the configured scope(s) and creates a DefectDojo product for each scanned asset grouping. + +#### Prerequisites + +A Sysdig Secure **API token**: in Sysdig Secure, go to **Settings \> Sysdig Secure API Token** and copy the token. You also need your Sysdig **region URL** (for example `https://us2.app.sysdig.com`, `https://eu1.app.sysdig.com`, or your on\-premises host). + +#### Connector Mappings + +1. Enter your Sysdig region/base URL in the **Location** field. +2. Enter the API token in the **Secret** field. +3. Optionally set **Scopes** — a comma\-separated list of `runtime`, `registry`, and/or `pipeline` (leave blank for `runtime`, the deployed\-workload scope). +4. Optionally set **Runtime Asset Grouping** — how runtime results map to Assets: `cluster`, `namespace`, `workload`, or `image` (leave blank for `namespace`). Registry and pipeline results always group by image repository. +5. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each asset grouping becomes a Record. For each scan result the connector imports every vulnerable package as a finding. **Runtime** findings (deployed workloads) are recorded as dynamic findings and tagged with their Kubernetes cluster / namespace / workload / container context; **registry** and **pipeline** findings are recorded as static image\-scan findings. Sysdig's `NEGLIGIBLE` severity maps to Info. diff --git a/docs/content/connectors/toolreference/tenable_io.de.md b/docs/content/connectors/toolreference/tenable_io.de.md new file mode 100644 index 00000000000..49adfe97913 --- /dev/null +++ b/docs/content/connectors/toolreference/tenable_io.de.md @@ -0,0 +1,16 @@ +--- +title: "Tenable" +description: "Einrichtung des Tenable Upstream-Connectors für DefectDojo" +weight: 131 +audience: pro +--- +Der Tenable-Connector verwendet die **Tenable.io**-REST-API, um Daten abzurufen. Scans werden vom Tenable-VM-Endpunkt `/scans` abgerufen. + +On-Premise-Tenable-Connectors sind derzeit nicht verfügbar. + +#### **Connector-Zuordnungen** + +1. Geben Sie in das Feld Location ein. +2. Geben Sie einen gültigen **API-Schlüssel** in das Feld Secret ein. + +Weitere Informationen finden Sie in der [Tenable-API-Dokumentation](https://docs.tenable.com/vulnerability-management/Content/Settings/my-account/GenerateAPIKey.htm). diff --git a/docs/content/connectors/toolreference/tenable_io.es.md b/docs/content/connectors/toolreference/tenable_io.es.md new file mode 100644 index 00000000000..ebbf4b46801 --- /dev/null +++ b/docs/content/connectors/toolreference/tenable_io.es.md @@ -0,0 +1,16 @@ +--- +title: "Tenable" +description: "Cómo configurar el Conector Upstream de Tenable para DefectDojo" +weight: 131 +audience: pro +--- +El conector de Tenable usa la API REST de **Tenable.io** para obtener datos. Los análisis se obtienen del endpoint `/scans` de Tenable VM. + +Los conectores de Tenable on-premise no están disponibles por el momento. + +#### **Asignaciones del conector** + +1. Introduzca en el campo Location. +2. Introduzca una **API key** válida en el campo Secret. + +Consulte la [documentación de la API de Tenable](https://docs.tenable.com/vulnerability-management/Content/Settings/my-account/GenerateAPIKey.htm) para más información. diff --git a/docs/content/connectors/toolreference/tenable_io.fr.md b/docs/content/connectors/toolreference/tenable_io.fr.md new file mode 100644 index 00000000000..027647afdd1 --- /dev/null +++ b/docs/content/connectors/toolreference/tenable_io.fr.md @@ -0,0 +1,16 @@ +--- +title: "Tenable" +description: "Comment configurer le Connecteur Upstream Tenable pour DefectDojo" +weight: 131 +audience: pro +--- +Le connecteur Tenable utilise l'API REST **Tenable.io** pour récupérer les données. Les scans sont extraits du point de terminaison `/scans` de Tenable VM. + +Les connecteurs Tenable sur site ne sont pas disponibles pour le moment. + +#### **Mappages du connecteur** + +1. Saisissez dans le champ Location. +2. Saisissez une **clé API** valide dans le champ Secret. + +Consultez la [documentation de l'API Tenable](https://docs.tenable.com/vulnerability-management/Content/Settings/my-account/GenerateAPIKey.htm) pour plus d'informations. diff --git a/docs/content/connectors/toolreference/tenable_io.ja.md b/docs/content/connectors/toolreference/tenable_io.ja.md new file mode 100644 index 00000000000..ff8832b7460 --- /dev/null +++ b/docs/content/connectors/toolreference/tenable_io.ja.md @@ -0,0 +1,16 @@ +--- +title: "Tenable" +description: "DefectDojo で Tenable の Upstream Connector をセットアップする方法" +weight: 131 +audience: pro +--- +Tenable コネクタは **Tenable.io** REST API を使用してデータを取得します。 スキャンは Tenable VM の `/scans` エンドポイントから取得されます。 + +オンプレミス版の Tenable コネクタは現時点では利用できません。 + +#### **Connector Mappings** + +1. Location フィールドに を入力します。 +2. Secret フィールドに有効な **API キー**を入力します。 + +詳細については、[Tenable の API ドキュメント](https://docs.tenable.com/vulnerability-management/Content/Settings/my-account/GenerateAPIKey.htm)を参照してください。 diff --git a/docs/content/connectors/toolreference/tenable_io.md b/docs/content/connectors/toolreference/tenable_io.md new file mode 100644 index 00000000000..cb98c3d2982 --- /dev/null +++ b/docs/content/connectors/toolreference/tenable_io.md @@ -0,0 +1,16 @@ +--- +title: "Tenable.io" +description: "How to set up the Tenable.io Upstream Connector for DefectDojo" +weight: 131 +audience: pro +--- +The Tenable connector uses the **Tenable.io** REST API to fetch data. Scans are pulled from the Tenable VM `/scans` endpoint. + +On\-premise Tenable Connectors are not available at this time. + +#### **Connector Mappings** + +1. Enter in the Location field. +2. Enter a valid **API key** in the Secret field. + +See [Tenable's API Documentation](https://docs.tenable.com/vulnerability-management/Content/Settings/my-account/GenerateAPIKey.htm) for more info. diff --git a/docs/content/connectors/toolreference/tenable_web_app_scanning.de.md b/docs/content/connectors/toolreference/tenable_web_app_scanning.de.md new file mode 100644 index 00000000000..e9bdbc19ad0 --- /dev/null +++ b/docs/content/connectors/toolreference/tenable_web_app_scanning.de.md @@ -0,0 +1,25 @@ +--- +title: "Tenable Web App Scanning" +description: "Einrichtung des Tenable Web App Scanning Upstream-Connectors für DefectDojo" +weight: 132 +audience: pro +--- +Der Tenable-Web-App-Scanning-Connector importiert **Web-Anwendungs(DAST)-Befunde** von Tenable Web App Scanning. Es handelt sich um einen separaten Connector zu Tenable (Vulnerability Management): Die beiden Produkte decken unterschiedliche Assets ab und werden unabhängig voneinander konfiguriert, sodass Sie entweder eines oder beide verwenden können. + +DefectDojo erstellt für jede **gescannte Web-Anwendung** einen Eintrag. Anwendungen werden aus Ihren Web-App-Scanning-Scan-Konfigurationen ermittelt; eine Konfiguration, die nie ausgeführt wurde, erzeugt erst nach ihrem ersten abgeschlossenen Scan einen Eintrag. Scannen mehrere Konfigurationen dieselbe Anwendung, teilen sie sich einen einzigen Eintrag. + +#### Voraussetzungen + +Tenable-**API-Schlüssel** (ein Access Key und ein Secret Key) für einen Benutzer mit Web-App-Scanning-Berechtigungen. Generieren Sie diese in Tenable unter **My Account \> API Keys**, und stellen Sie sicher, dass der Benutzer die zu importierenden Scans sehen kann — auf Vulnerability Management beschränkte Schlüssel können keine Web-App-Scanning-Daten lesen. + +On-Premise-Tenable-Connectors sind derzeit nicht verfügbar. + +#### Connector-Zuordnungen + +1. Geben Sie in das Feld **Location** ein. +2. Geben Sie Ihren **Access Key** und **Secret Key** ein. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Befunde werden mit dem Schweregrad importiert, den Tenable für Ihr Konto meldet, einschließlich jeder von Ihrem Team neu eingestuften Bewertung. Jeder Befund enthält die betroffene URL als Endpunkt, den Request-Parameter und die Payload, die ihn ausgelöst haben, sowie Tenables Nachweis und Ausgabe als Schritte zur Reproduktion, zusammen mit CWE-, CVE-, CVSS- und EPSS-Werten, sofern das erkennende Plugin diese liefert. + +Es werden nur derzeit offene oder wiedereröffnete Befunde importiert. Ein von Tenable als behoben markierter Befund wird beim nächsten Sync in DefectDojo geschlossen. diff --git a/docs/content/connectors/toolreference/tenable_web_app_scanning.es.md b/docs/content/connectors/toolreference/tenable_web_app_scanning.es.md new file mode 100644 index 00000000000..a301126b645 --- /dev/null +++ b/docs/content/connectors/toolreference/tenable_web_app_scanning.es.md @@ -0,0 +1,25 @@ +--- +title: "Tenable Web App Scanning" +description: "Cómo configurar el Conector Upstream de Tenable Web App Scanning para DefectDojo" +weight: 132 +audience: pro +--- +El conector de Tenable Web App Scanning importa **hallazgos de aplicaciones web (DAST)** desde Tenable Web App Scanning. Es un conector independiente de Tenable (Vulnerability Management): los dos productos cubren activos diferentes y se configuran de forma independiente, por lo que puede usar uno u otro, o ambos. + +DefectDojo crea un Record para cada **aplicación web escaneada**. Las aplicaciones se descubren a partir de sus configuraciones de análisis de Web App Scanning; una configuración que nunca se ha ejecutado no genera un Record hasta que se complete su primer análisis. Cuando más de una configuración analiza la misma aplicación, comparten un único Record. + +#### Prerrequisitos + +**API keys** de Tenable (una access key y una secret key) para un usuario con permisos de Web App Scanning. En Tenable, vaya a **My Account > API Keys** para generarlas, y confirme que el usuario puede ver los análisis que desea importar — las keys limitadas a Vulnerability Management no pueden leer datos de Web App Scanning. + +Los conectores de Tenable on-premise no están disponibles por el momento. + +#### Asignaciones del conector + +1. Introduzca en el campo **Location**. +2. Introduzca su **Access Key** y **Secret Key**. +3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +Los hallazgos se importan con la severidad que Tenable reporta para su cuenta, incluida cualquier severidad que su equipo haya reclasificado. Cada hallazgo incluye la URL afectada como endpoint, el parámetro de solicitud y el payload que lo desencadenó, y la prueba y el resultado de Tenable como pasos para reproducirlo, junto con los valores de CWE, CVE, CVSS y EPSS cuando el plugin de detección los proporciona. + +Solo se importan los hallazgos que están actualmente abiertos o reabiertos. Un hallazgo que Tenable ha marcado como corregido se cierra en DefectDojo en la siguiente sincronización. diff --git a/docs/content/connectors/toolreference/tenable_web_app_scanning.fr.md b/docs/content/connectors/toolreference/tenable_web_app_scanning.fr.md new file mode 100644 index 00000000000..b8a631b4c91 --- /dev/null +++ b/docs/content/connectors/toolreference/tenable_web_app_scanning.fr.md @@ -0,0 +1,25 @@ +--- +title: "Tenable Web App Scanning" +description: "Comment configurer le Connecteur Upstream Tenable Web App Scanning pour DefectDojo" +weight: 132 +audience: pro +--- +Le connecteur Tenable Web App Scanning importe des **constatations d'application web (DAST)** depuis Tenable Web App Scanning. Il s'agit d'un connecteur distinct de Tenable (Vulnerability Management) : les deux produits couvrent des actifs différents et se configurent indépendamment, vous pouvez donc utiliser l'un, l'autre, ou les deux. + +DefectDojo crée un Enregistrement pour chaque **application web analysée**. Les applications sont découvertes à partir de vos configurations de scan Web App Scanning ; une configuration qui n'a jamais été exécutée ne produit pas d'Enregistrement tant que son premier scan n'est pas terminé. Lorsque plusieurs configurations analysent la même application, elles partagent un seul Enregistrement. + +#### Prérequis + +Des **clés API** Tenable (une clé d'accès et une clé secrète) pour un utilisateur disposant des permissions Web App Scanning. Dans Tenable, allez dans **My Account > API Keys** pour les générer, et vérifiez que l'utilisateur peut voir les scans que vous souhaitez importer — les clés limitées à Vulnerability Management ne peuvent pas lire les données de Web App Scanning. + +Les connecteurs Tenable sur site ne sont pas disponibles pour le moment. + +#### Mappages du connecteur + +1. Saisissez dans le champ **Location**. +2. Saisissez votre **Access Key** et votre **Secret Key**. +3. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Les constatations sont importées avec la sévérité que Tenable indique pour votre compte, y compris toute sévérité que votre équipe a reclassée. Chaque constatation porte l'URL concernée comme point de terminaison, le paramètre de requête et la charge utile qui l'ont déclenchée, ainsi que la preuve et la sortie de Tenable comme étapes de reproduction, avec les valeurs CWE, CVE, CVSS et EPSS lorsque le plugin de détection les fournit. + +Seules les constatations actuellement ouvertes ou rouvertes sont importées. Une constatation que Tenable a marquée comme corrigée est fermée dans DefectDojo lors de la prochaine synchronisation. diff --git a/docs/content/connectors/toolreference/tenable_web_app_scanning.ja.md b/docs/content/connectors/toolreference/tenable_web_app_scanning.ja.md new file mode 100644 index 00000000000..2b024efcb4c --- /dev/null +++ b/docs/content/connectors/toolreference/tenable_web_app_scanning.ja.md @@ -0,0 +1,25 @@ +--- +title: "Tenable Web App Scanning" +description: "DefectDojo で Tenable Web App Scanning の Upstream Connector をセットアップする方法" +weight: 132 +audience: pro +--- +Tenable Web App Scanning コネクタは、Tenable Web App Scanning から**Web アプリケーション(DAST)検出事項**をインポートします。これは Tenable(Vulnerability Management)とは別のコネクタです。両製品は対象とするアセットが異なり、それぞれ独立して設定されるため、どちらか一方、または両方を使用できます。 + +DefectDojo は**スキャン対象の Web アプリケーション**ごとに Record を作成します。アプリケーションは Web App Scanning のスキャン設定から検出されます。一度も実行されていない設定は、最初のスキャンが完了するまで Record を生成しません。複数の設定が同じアプリケーションをスキャンする場合、それらは 1 つの Record を共有します。 + +#### Prerequisites + +Web App Scanning の権限を持つユーザー用の Tenable **API キー**(アクセスキーとシークレットキー)。Tenable で **My Account > API Keys** に移動して生成し、そのユーザーがインポートしたいスキャンを閲覧できることを確認してください — Vulnerability Management に限定されたキーでは Web App Scanning のデータを読み取れません。 + +オンプレミス版の Tenable コネクタは現時点では利用できません。 + +#### Connector Mappings + +1. **Location** フィールドに を入力します。 +2. **Access Key** と **Secret Key** を入力します。 +3. 必要に応じて、**Minimum Severity** を設定してインポートする検出事項を絞り込みます。 + +検出事項は、チームが変更した深刻度も含め、Tenable がアカウントに対して報告する深刻度でインポートされます。各検出事項には、影響を受ける URL がエンドポイントとして、検出のきっかけとなったリクエストパラメータとペイロード、および Tenable の証拠と出力が再現手順として含まれ、検出プラグインが提供する場合は CWE、CVE、CVSS、EPSS の値も含まれます。 + +現在オープンまたは再オープンされている検出事項のみがインポートされます。Tenable が修正済みとマークした検出事項は、次回の同期時に DefectDojo でクローズされます。 diff --git a/docs/content/connectors/toolreference/tenable_web_app_scanning.md b/docs/content/connectors/toolreference/tenable_web_app_scanning.md new file mode 100644 index 00000000000..97584a3357a --- /dev/null +++ b/docs/content/connectors/toolreference/tenable_web_app_scanning.md @@ -0,0 +1,25 @@ +--- +title: "Tenable Web App Scanning" +description: "How to set up the Tenable Web App Scanning Upstream Connector for DefectDojo" +weight: 132 +audience: pro +--- +The Tenable Web App Scanning connector imports **web application (DAST) findings** from Tenable Web App Scanning. It is a separate connector from Tenable (Vulnerability Management): the two Assets cover different assets and are configured independently, so you can use either or both. + +DefectDojo creates a Record for each **scanned web application**. Applications are discovered from your Web App Scanning scan configurations; a configuration that has never run does not produce a Record until its first scan completes. When more than one configuration scans the same application, they share a single Record. + +#### Prerequisites + +Tenable **API keys** (an access key and a secret key) for a user with Web App Scanning permissions. In Tenable, go to **My Account \> API Keys** to generate them, and confirm the user can view the scans you want to import — keys limited to Vulnerability Management cannot read Web App Scanning data. + +On\-premise Tenable connectors are not available at this time. + +#### Connector Mappings + +1. Enter in the **Location** field. +2. Enter your **Access Key** and **Secret Key**. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Findings are imported with the severity Tenable reports for your account, including any severity your team has recast. Each finding carries the affected URL as an endpoint, the request parameter and payload that triggered it, and Tenable's proof and output as steps to reproduce, along with CWE, CVE, CVSS and EPSS values where the detecting plugin supplies them. + +Only findings that are currently open or reopened are imported. A finding Tenable has marked fixed is closed in DefectDojo on the next sync. diff --git a/docs/content/connectors/toolreference/trufflehog.md b/docs/content/connectors/toolreference/trufflehog.md new file mode 100644 index 00000000000..b0f3f13db25 --- /dev/null +++ b/docs/content/connectors/toolreference/trufflehog.md @@ -0,0 +1,23 @@ +--- +title: "TruffleHog" +description: "How to set up the TruffleHog Upstream Connector for DefectDojo" +weight: 133 +audience: pro +--- +The TruffleHog connector imports **secret detections** from TruffleHog Enterprise. DefectDojo creates a Record for each configured **scan source** — a repository, bucket or registry — and that source's detections become its findings. No per\-source configuration is required. + +**Secret handling.** Findings carry only the **redacted** secret as TruffleHog reports it. Raw secret material is read solely to compute the deduplication digest, and never reaches a finding field, a log line, or an error message. Response bodies are never logged, even with debug logging enabled, so a debug session cannot leak secret material. + +**Not to be confused with `trufflehog3`.** The separate `trufflehog3` parser in the supported tools list is a different tool with a different report format — it is not this connector's file equivalent. + +#### Prerequisites + +A TruffleHog **Enterprise** API token, sent as a bearer token. + +#### Connector Mappings + +1. Enter your TruffleHog Enterprise API host in the **Location** field. +2. Enter the Enterprise API token in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each configured scan source becomes a Record. diff --git a/docs/content/connectors/toolreference/trustwave_fusion.md b/docs/content/connectors/toolreference/trustwave_fusion.md new file mode 100644 index 00000000000..58e05fbe22a --- /dev/null +++ b/docs/content/connectors/toolreference/trustwave_fusion.md @@ -0,0 +1,19 @@ +--- +title: "Trustwave Fusion" +description: "How to set up the Trustwave Fusion Upstream Connector for DefectDojo" +weight: 134 +audience: pro +--- +The Trustwave Fusion connector imports findings from the Trustwave Fusion platform. DefectDojo creates a Record for each **asset**, derived from the findings themselves. + +#### Prerequisites + +A Trustwave Fusion **API token** for the tenant whose findings you want to import. + +#### Connector Mappings + +1. Enter your Trustwave Fusion API URL in the **Location** field. +2. Enter the API token in the **API Token** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each asset referenced by your findings becomes a Record, grouped by the asset the finding was reported against. diff --git a/docs/content/connectors/toolreference/upstream.de.md b/docs/content/connectors/toolreference/upstream.de.md new file mode 100644 index 00000000000..6c2f4f43b02 --- /dev/null +++ b/docs/content/connectors/toolreference/upstream.de.md @@ -0,0 +1,109 @@ +--- +title: Referenz zu Upstream-Connector-Tools +description: Unsere Liste der unterstützten Connector-Tools und wie Sie sie mit DefectDojo + einrichten +weight: 1 +audience: pro +aliases: +- /de/connectors/upstream/toolreference/ +- /de/import_data/pro/connectors/connectors_tool_reference/ +- /de/en/connecting_your_tools/connectors/connectors_tool_reference +--- + +Hinweis: Upstream-Connectors sind eine reine DefectDojo-Pro-Funktion. + +Beim Einrichten eines Connectors für ein unterstütztes Tool müssen Sie DefectDojo bestimmte Informationen zur API des Tools mitteilen. Grundsätzlich benötigen Sie: + +* **Location** \-ein Feld, das im Allgemeinen auf die URL Ihres Tools in Ihrem Netzwerk verweist, +* **Secret** \- in der Regel ein API-Schlüssel. + +Manche Tools benötigen über **Location** und **Secret** hinaus weitere API-bezogene Felder. Möglicherweise müssen Sie auch auf der Seite des Tools Änderungen vornehmen, um einen eingehenden Connector von DefectDojo zu ermöglichen. + +![image](images/connectors_tool_reference.png) + +Jedes Tool hat eine andere API-Konfiguration, und dieser Leitfaden soll Ihnen helfen, die API des Tools so einzurichten, dass DefectDojo eine Verbindung herstellen kann. + +Wann immer möglich, empfehlen wir, in Ihrem Sicherheitstool ein neues Konto „DefectDojo Bot" anzulegen, das ausschließlich vom Connector verwendet wird. So können Sie besser zwischen manuell von Ihrem Team ausgeführten Aktionen und automatisierten Aktionen des Connectors unterscheiden. + +# **Asset-Connectors** + +Die meisten Connectors importieren **Befunde** aus einem Sicherheitstool. **Asset-Connectors** funktionieren anders: Sie importieren stattdessen Ihr **Asset-Inventar**. Ein Asset-Connector zählt die Assets auf, die in einer externen Plattform vorhanden sind (zum Beispiel die Repositories in einer GitLab-Gruppe), und erstellt und pflegt automatisch die entsprechenden **Produkte** (Assets) und **Produkttypen** (Organisationen) in DefectDojo. Ein Asset-Connector importiert keine Befunde. + +* **Discover** und **Sync** gleichen beide die Asset-Liste ab. Neue Assets erscheinen als `NEW`-Einträge; sobald sie zugeordnet sind (automatisch, wenn Auto-Mapping aktiviert ist), erstellt DefectDojo das Produkt und ordnet es einem vom Tool abgeleiteten Produkttyp zu — zum Beispiel dem GitLab-Namespace oder dem Azure-DevOps-Projekt. +* Wird ein Asset später upstream entfernt (zum Beispiel ein gelöschtes Repository), wird sein zugeordneter Eintrag beim nächsten Sync als `MISSING` markiert, damit Ihr Team ihn prüfen kann. DefectDojo löscht niemals stillschweigend ein Produkt. + +Azure DevOps, Backstage, Bitbucket, GitHub, GitLab, Jira Service Management Assets und ServiceNow CMDB sind Asset-Connectors. runZero ist in erster Linie ein Asset-Connector, kann aber optional auch Schwachstellen als Befunde importieren. Alle anderen unten aufgeführten Connectors importieren Befunde. + +# **Unterstützte Connectors** + +- [Acunetix 360](/connectors/toolreference/acunetix_360/) +- [Akamai API Security](/connectors/toolreference/akamai/) +- [Anchore](/connectors/toolreference/anchore_enterprise/) +- [AWS Security Hub](/connectors/toolreference/security_hub/) +- [Azure DevOps](/connectors/toolreference/azure_devops/) +- [Backstage](/connectors/toolreference/backstage/) +- [Black Duck](/connectors/toolreference/black_duck/) +- [Bitbucket](/connectors/toolreference/bitbucket/#upstream-connector) +- [Bugcrowd](/connectors/toolreference/bugcrowd/) +- [Bright Security](/connectors/toolreference/bright_security/) +- [BurpSuite](/connectors/toolreference/burp_suite_enterprise/) +- [Censys](/connectors/toolreference/censys/) +- [Checkmarx ONE](/connectors/toolreference/checkmarx_one/) +- [Cloudflare](/connectors/toolreference/cloudflare/) +- [Cobalt.io](/connectors/toolreference/cobalt_io/) +- [Contrast](/connectors/toolreference/contrast/) +- [Coverity](/connectors/toolreference/coverity/) +- [CrowdStrike Falcon](/connectors/toolreference/crowdstrike_falcon/) +- [Deepfence ThreatMapper](/connectors/toolreference/deepfence_threatmapper/) +- [Dependency-Track](/connectors/toolreference/dependency_track/) +- [Docker Scout](/connectors/toolreference/docker_scout/) +- [Endor Labs](/connectors/toolreference/endor_labs/) +- [Edgescan](/connectors/toolreference/edgescan/) +- [Escape](/connectors/toolreference/escape/) +- [Fairwinds Insights](/connectors/toolreference/fairwinds_insights/) +- [Fortify](/connectors/toolreference/fortify/) +- [GitGuardian](/connectors/toolreference/gitguardian/) +- [GitHub](/connectors/toolreference/github/#upstream-connector) +- [GitHub Advanced Security](/connectors/toolreference/github_advanced_security/) +- [GitLab](/connectors/toolreference/gitlab/#upstream-connector) +- [Google Cloud Security Command Center](/connectors/toolreference/google_cloud_scc/) +- [Group-IB ASM](/connectors/toolreference/group_ib_asm/) +- [HackerOne](/connectors/toolreference/hackerone/) +- [Harbor](/connectors/toolreference/harbor/) +- [Have I Been Pwned](/connectors/toolreference/have_i_been_pwned/) +- [HCL AppScan](/connectors/toolreference/hcl_appscan/) +- [Intigriti](/connectors/toolreference/intigriti/) +- [Intruder](/connectors/toolreference/intruder/) +- [IriusRisk](/connectors/toolreference/iriusrisk/) +- [JFrog Xray](/connectors/toolreference/jfrog_xray/) +- [Jira Service Management Assets](/connectors/toolreference/jsm_assets/) +- [Kubescape](/connectors/toolreference/kubescape/) +- [Mend](/connectors/toolreference/mend/) +- [Lacework / FortiCNAPP](/connectors/toolreference/lacework_forticnapp/) +- [Microsoft Defender](/connectors/toolreference/microsoft_defender/) +- [Microsoft Defender for Cloud](/connectors/toolreference/microsoft_defender_for_cloud/) +- [MobSF](/connectors/toolreference/mobsf/) +- [NeuVector](/connectors/toolreference/neuvector/) +- [Nuclei (ProjectDiscovery Cloud)](/connectors/toolreference/nuclei_projectdiscovery_cloud/) +- [OpenVAS / Greenbone](/connectors/toolreference/openvas_greenbone/) +- [Probely](/connectors/toolreference/probely/) +- [Prowler](/connectors/toolreference/prowler/) +- [Qualys](/connectors/toolreference/qualys/) +- [Quay](/connectors/toolreference/quay/) +- [Rapid7 InsightAppSec](/connectors/toolreference/rapid7_insightappsec/) +- [Rapid7 InsightVM](/connectors/toolreference/rapid7_insightvm/) +- [runZero](/connectors/toolreference/runzero/) +- [Semgrep](/connectors/toolreference/semgrep/) +- [ServiceNow CMDB](/connectors/toolreference/servicenow_cmdb/) +- [Shodan](/connectors/toolreference/shodan/) +- [SonarQube](/connectors/toolreference/sonarqube/) +- [Snyk](/connectors/toolreference/snyk/) +- [Socket](/connectors/toolreference/socket/) +- [Sonatype IQ](/connectors/toolreference/sonatype_iq/) +- [Sysdig Secure](/connectors/toolreference/sysdig_secure/) +- [Tenable](/connectors/toolreference/tenable_io/) +- [Tenable Web App Scanning](/connectors/toolreference/tenable_web_app_scanning/) +- [Veracode](/connectors/toolreference/veracode/) +- [Wazuh](/connectors/toolreference/wazuh/) +- [Wiz](/connectors/toolreference/wiz/) +- [YesWeHack](/connectors/toolreference/yeswehack/) diff --git a/docs/content/connectors/toolreference/upstream.es.md b/docs/content/connectors/toolreference/upstream.es.md new file mode 100644 index 00000000000..7cfd848e0c3 --- /dev/null +++ b/docs/content/connectors/toolreference/upstream.es.md @@ -0,0 +1,109 @@ +--- +title: Referencia de herramientas de Conectores Upstream +description: Nuestra lista de herramientas de Conector compatibles y cómo configurarlas + con DefectDojo +weight: 1 +audience: pro +aliases: +- /es/connectors/upstream/toolreference/ +- /es/import_data/pro/connectors/connectors_tool_reference/ +- /es/en/connecting_your_tools/connectors/connectors_tool_reference +--- + +Nota: los Conectores Upstream son una función exclusiva de DefectDojo Pro. + +Al configurar un Conector para una herramienta compatible, deberá proporcionar a DefectDojo información específica relacionada con la API de la herramienta. Como mínimo, necesitará: + +* **Location** \-un campo que generalmente hace referencia a la URL de su herramienta dentro de su red, +* **Secret** \- generalmente, una clave de API. + +Algunas herramientas requerirán campos adicionales relacionados con la API además de **Location** y **Secret**. También pueden requerir que realice cambios de su lado para admitir un Conector entrante desde DefectDojo. + +![imagen](images/connectors_tool_reference.png) + +Cada herramienta tiene una configuración de API diferente, y esta guía está diseñada para ayudarlo a configurar la API de la herramienta para que DefectDojo pueda conectarse. + +Siempre que sea posible, recomendamos crear una nueva cuenta 'DefectDojo Bot' dentro de su herramienta de seguridad, que solo será utilizada por el Conector. Esto le ayudará a diferenciar mejor entre las acciones realizadas manualmente por su equipo y las acciones automatizadas realizadas por el Conector. + +# **Conectores de activos** + +La mayoría de los Conectores importan **hallazgos** desde una herramienta de seguridad. Los **Conectores de activos** funcionan de forma diferente: en su lugar, importan su **inventario de activos**. Un Conector de activos enumera los activos que existen en una plataforma externa (por ejemplo, los repositorios de un grupo de GitLab) y crea y mantiene automáticamente los **Productos** (Activos) y **Tipos de producto** (Organizaciones) correspondientes en DefectDojo. Un Conector de activos no importa hallazgos. + +* Tanto **Discover** como **Sync** concilian la lista de activos. Los activos nuevos aparecen como Registros `NEW`; una vez asignados (automáticamente, si la asignación automática está habilitada), DefectDojo crea el Producto y lo agrupa bajo un Tipo de producto derivado de la herramienta — por ejemplo, el namespace de GitLab o el proyecto de Azure DevOps. +* Si más adelante se elimina un activo en el origen (por ejemplo, se elimina un repositorio), su Registro asignado se marca como `MISSING` en la siguiente Sync para que su equipo pueda triarlo. DefectDojo nunca elimina un Producto de forma silenciosa. + +Azure DevOps, Backstage, Bitbucket, GitHub, GitLab, Jira Service Management Assets y ServiceNow CMDB son Conectores de activos. runZero es principalmente un Conector de activos, pero opcionalmente puede importar vulnerabilidades como hallazgos. Todos los demás Conectores listados a continuación importan hallazgos. + +# **Conectores compatibles** + +- [Acunetix 360](/connectors/toolreference/acunetix_360/) +- [Akamai API Security](/connectors/toolreference/akamai/) +- [Anchore](/connectors/toolreference/anchore_enterprise/) +- [AWS Security Hub](/connectors/toolreference/security_hub/) +- [Azure DevOps](/connectors/toolreference/azure_devops/) +- [Backstage](/connectors/toolreference/backstage/) +- [Black Duck](/connectors/toolreference/black_duck/) +- [Bitbucket](/connectors/toolreference/bitbucket/#upstream-connector) +- [Bugcrowd](/connectors/toolreference/bugcrowd/) +- [Bright Security](/connectors/toolreference/bright_security/) +- [BurpSuite](/connectors/toolreference/burp_suite_enterprise/) +- [Censys](/connectors/toolreference/censys/) +- [Checkmarx ONE](/connectors/toolreference/checkmarx_one/) +- [Cloudflare](/connectors/toolreference/cloudflare/) +- [Cobalt.io](/connectors/toolreference/cobalt_io/) +- [Contrast](/connectors/toolreference/contrast/) +- [Coverity](/connectors/toolreference/coverity/) +- [CrowdStrike Falcon](/connectors/toolreference/crowdstrike_falcon/) +- [Deepfence ThreatMapper](/connectors/toolreference/deepfence_threatmapper/) +- [Dependency-Track](/connectors/toolreference/dependency_track/) +- [Docker Scout](/connectors/toolreference/docker_scout/) +- [Endor Labs](/connectors/toolreference/endor_labs/) +- [Edgescan](/connectors/toolreference/edgescan/) +- [Escape](/connectors/toolreference/escape/) +- [Fairwinds Insights](/connectors/toolreference/fairwinds_insights/) +- [Fortify](/connectors/toolreference/fortify/) +- [GitGuardian](/connectors/toolreference/gitguardian/) +- [GitHub](/connectors/toolreference/github/#upstream-connector) +- [GitHub Advanced Security](/connectors/toolreference/github_advanced_security/) +- [GitLab](/connectors/toolreference/gitlab/#upstream-connector) +- [Google Cloud Security Command Center](/connectors/toolreference/google_cloud_scc/) +- [Group-IB ASM](/connectors/toolreference/group_ib_asm/) +- [HackerOne](/connectors/toolreference/hackerone/) +- [Harbor](/connectors/toolreference/harbor/) +- [Have I Been Pwned](/connectors/toolreference/have_i_been_pwned/) +- [HCL AppScan](/connectors/toolreference/hcl_appscan/) +- [Intigriti](/connectors/toolreference/intigriti/) +- [Intruder](/connectors/toolreference/intruder/) +- [IriusRisk](/connectors/toolreference/iriusrisk/) +- [JFrog Xray](/connectors/toolreference/jfrog_xray/) +- [Jira Service Management Assets](/connectors/toolreference/jsm_assets/) +- [Kubescape](/connectors/toolreference/kubescape/) +- [Mend](/connectors/toolreference/mend/) +- [Lacework / FortiCNAPP](/connectors/toolreference/lacework_forticnapp/) +- [Microsoft Defender](/connectors/toolreference/microsoft_defender/) +- [Microsoft Defender for Cloud](/connectors/toolreference/microsoft_defender_for_cloud/) +- [MobSF](/connectors/toolreference/mobsf/) +- [NeuVector](/connectors/toolreference/neuvector/) +- [Nuclei (ProjectDiscovery Cloud)](/connectors/toolreference/nuclei_projectdiscovery_cloud/) +- [OpenVAS / Greenbone](/connectors/toolreference/openvas_greenbone/) +- [Probely](/connectors/toolreference/probely/) +- [Prowler](/connectors/toolreference/prowler/) +- [Qualys](/connectors/toolreference/qualys/) +- [Quay](/connectors/toolreference/quay/) +- [Rapid7 InsightAppSec](/connectors/toolreference/rapid7_insightappsec/) +- [Rapid7 InsightVM](/connectors/toolreference/rapid7_insightvm/) +- [runZero](/connectors/toolreference/runzero/) +- [Semgrep](/connectors/toolreference/semgrep/) +- [ServiceNow CMDB](/connectors/toolreference/servicenow_cmdb/) +- [Shodan](/connectors/toolreference/shodan/) +- [SonarQube](/connectors/toolreference/sonarqube/) +- [Snyk](/connectors/toolreference/snyk/) +- [Socket](/connectors/toolreference/socket/) +- [Sonatype IQ](/connectors/toolreference/sonatype_iq/) +- [Sysdig Secure](/connectors/toolreference/sysdig_secure/) +- [Tenable](/connectors/toolreference/tenable_io/) +- [Tenable Web App Scanning](/connectors/toolreference/tenable_web_app_scanning/) +- [Veracode](/connectors/toolreference/veracode/) +- [Wazuh](/connectors/toolreference/wazuh/) +- [Wiz](/connectors/toolreference/wiz/) +- [YesWeHack](/connectors/toolreference/yeswehack/) diff --git a/docs/content/connectors/toolreference/upstream.fr.md b/docs/content/connectors/toolreference/upstream.fr.md new file mode 100644 index 00000000000..9014e8629f1 --- /dev/null +++ b/docs/content/connectors/toolreference/upstream.fr.md @@ -0,0 +1,109 @@ +--- +title: Référence des outils pour les Connecteurs Upstream +description: Notre liste des outils de Connecteur pris en charge, et comment les configurer + avec DefectDojo +weight: 1 +audience: pro +aliases: +- /fr/connectors/upstream/toolreference/ +- /fr/import_data/pro/connectors/connectors_tool_reference/ +- /fr/en/connecting_your_tools/connectors/connectors_tool_reference +--- + +Remarque : les Connecteurs Upstream sont une fonctionnalité réservée à DefectDojo Pro. + +Lors de la configuration d'un Connecteur pour un outil pris en charge, vous devez fournir à DefectDojo des informations spécifiques liées à l'API de l'outil. Au minimum, vous aurez besoin des éléments suivants : + +* **Location** \- un champ qui fait généralement référence à l'URL de votre outil sur votre réseau, +* **Secret** \- généralement une clé API. + +Certains outils nécessiteront des champs supplémentaires liés à l'API, en plus de **Location** et **Secret**. Ils peuvent également nécessiter que vous effectuiez des modifications de leur côté pour prendre en charge un Connecteur entrant depuis DefectDojo. + +![image](images/connectors_tool_reference.png) + +Chaque outil possède une configuration d'API différente, et ce guide a pour but de vous aider à configurer l'API de l'outil afin que DefectDojo puisse s'y connecter. + +Dans la mesure du possible, nous vous recommandons de créer un nouveau compte « DefectDojo Bot » au sein de votre outil de sécurité, qui sera utilisé exclusivement par le Connecteur. Cela vous aidera à mieux distinguer les actions effectuées manuellement par votre équipe des actions automatisées effectuées par le Connecteur. + +# **Connecteurs d'actifs** + +La plupart des Connecteurs importent des **constatations** depuis un outil de sécurité. Les **Connecteurs d'actifs** fonctionnent différemment : ils importent plutôt votre **inventaire d'actifs**. Un Connecteur d'actifs énumère les actifs qui existent sur une plateforme externe (par exemple, les dépôts d'un groupe GitLab) et crée et maintient automatiquement les **Produits** (Actifs) et **Types de produit** (Organisations) correspondants dans DefectDojo. Aucune constatation n'est importée par un Connecteur d'actifs. + +* **Discover** et **Sync** réconcilient tous deux la liste des actifs. Les nouveaux actifs apparaissent comme des Enregistrements `NEW` ; une fois mappés (automatiquement, si le mappage automatique est activé), DefectDojo crée le Produit et le regroupe sous un Type de produit dérivé de l'outil — par exemple, l'espace de noms GitLab ou le projet Azure DevOps. +* Si un actif est ensuite supprimé en amont (par exemple, un dépôt est supprimé), son Enregistrement mappé est marqué `MISSING` lors de la prochaine synchronisation via **Sync**, afin que votre équipe puisse le trier. DefectDojo ne supprime jamais silencieusement un Produit. + +Azure DevOps, Backstage, Bitbucket, GitHub, GitLab, Jira Service Management Assets et ServiceNow CMDB sont des Connecteurs d'actifs. runZero est principalement un Connecteur d'actifs, mais peut également importer des vulnérabilités sous forme de constatations. Tous les autres Connecteurs listés ci-dessous importent des constatations. + +# **Connecteurs pris en charge** + +- [Acunetix 360](/connectors/toolreference/acunetix_360/) +- [Akamai API Security](/connectors/toolreference/akamai/) +- [Anchore](/connectors/toolreference/anchore_enterprise/) +- [AWS Security Hub](/connectors/toolreference/security_hub/) +- [Azure DevOps](/connectors/toolreference/azure_devops/) +- [Backstage](/connectors/toolreference/backstage/) +- [Black Duck](/connectors/toolreference/black_duck/) +- [Bitbucket](/connectors/toolreference/bitbucket/#upstream-connector) +- [Bugcrowd](/connectors/toolreference/bugcrowd/) +- [Bright Security](/connectors/toolreference/bright_security/) +- [BurpSuite](/connectors/toolreference/burp_suite_enterprise/) +- [Censys](/connectors/toolreference/censys/) +- [Checkmarx ONE](/connectors/toolreference/checkmarx_one/) +- [Cloudflare](/connectors/toolreference/cloudflare/) +- [Cobalt.io](/connectors/toolreference/cobalt_io/) +- [Contrast](/connectors/toolreference/contrast/) +- [Coverity](/connectors/toolreference/coverity/) +- [CrowdStrike Falcon](/connectors/toolreference/crowdstrike_falcon/) +- [Deepfence ThreatMapper](/connectors/toolreference/deepfence_threatmapper/) +- [Dependency-Track](/connectors/toolreference/dependency_track/) +- [Docker Scout](/connectors/toolreference/docker_scout/) +- [Endor Labs](/connectors/toolreference/endor_labs/) +- [Edgescan](/connectors/toolreference/edgescan/) +- [Escape](/connectors/toolreference/escape/) +- [Fairwinds Insights](/connectors/toolreference/fairwinds_insights/) +- [Fortify](/connectors/toolreference/fortify/) +- [GitGuardian](/connectors/toolreference/gitguardian/) +- [GitHub](/connectors/toolreference/github/#upstream-connector) +- [GitHub Advanced Security](/connectors/toolreference/github_advanced_security/) +- [GitLab](/connectors/toolreference/gitlab/#upstream-connector) +- [Google Cloud Security Command Center](/connectors/toolreference/google_cloud_scc/) +- [Group-IB ASM](/connectors/toolreference/group_ib_asm/) +- [HackerOne](/connectors/toolreference/hackerone/) +- [Harbor](/connectors/toolreference/harbor/) +- [Have I Been Pwned](/connectors/toolreference/have_i_been_pwned/) +- [HCL AppScan](/connectors/toolreference/hcl_appscan/) +- [Intigriti](/connectors/toolreference/intigriti/) +- [Intruder](/connectors/toolreference/intruder/) +- [IriusRisk](/connectors/toolreference/iriusrisk/) +- [JFrog Xray](/connectors/toolreference/jfrog_xray/) +- [Jira Service Management Assets](/connectors/toolreference/jsm_assets/) +- [Kubescape](/connectors/toolreference/kubescape/) +- [Mend](/connectors/toolreference/mend/) +- [Lacework / FortiCNAPP](/connectors/toolreference/lacework_forticnapp/) +- [Microsoft Defender](/connectors/toolreference/microsoft_defender/) +- [Microsoft Defender for Cloud](/connectors/toolreference/microsoft_defender_for_cloud/) +- [MobSF](/connectors/toolreference/mobsf/) +- [NeuVector](/connectors/toolreference/neuvector/) +- [Nuclei (ProjectDiscovery Cloud)](/connectors/toolreference/nuclei_projectdiscovery_cloud/) +- [OpenVAS / Greenbone](/connectors/toolreference/openvas_greenbone/) +- [Probely](/connectors/toolreference/probely/) +- [Prowler](/connectors/toolreference/prowler/) +- [Qualys](/connectors/toolreference/qualys/) +- [Quay](/connectors/toolreference/quay/) +- [Rapid7 InsightAppSec](/connectors/toolreference/rapid7_insightappsec/) +- [Rapid7 InsightVM](/connectors/toolreference/rapid7_insightvm/) +- [runZero](/connectors/toolreference/runzero/) +- [Semgrep](/connectors/toolreference/semgrep/) +- [ServiceNow CMDB](/connectors/toolreference/servicenow_cmdb/) +- [Shodan](/connectors/toolreference/shodan/) +- [SonarQube](/connectors/toolreference/sonarqube/) +- [Snyk](/connectors/toolreference/snyk/) +- [Socket](/connectors/toolreference/socket/) +- [Sonatype IQ](/connectors/toolreference/sonatype_iq/) +- [Sysdig Secure](/connectors/toolreference/sysdig_secure/) +- [Tenable](/connectors/toolreference/tenable_io/) +- [Tenable Web App Scanning](/connectors/toolreference/tenable_web_app_scanning/) +- [Veracode](/connectors/toolreference/veracode/) +- [Wazuh](/connectors/toolreference/wazuh/) +- [Wiz](/connectors/toolreference/wiz/) +- [YesWeHack](/connectors/toolreference/yeswehack/) diff --git a/docs/content/connectors/toolreference/upstream.ja.md b/docs/content/connectors/toolreference/upstream.ja.md new file mode 100644 index 00000000000..f62a7246d5d --- /dev/null +++ b/docs/content/connectors/toolreference/upstream.ja.md @@ -0,0 +1,108 @@ +--- +title: Upstream Connectors ツールリファレンス +description: 対応している Connector ツールの一覧と、DefectDojo でのセットアップ方法 +weight: 1 +audience: pro +aliases: +- /ja/connectors/upstream/toolreference/ +- /ja/import_data/pro/connectors/connectors_tool_reference/ +- /ja/en/connecting_your_tools/connectors/connectors_tool_reference +--- + +注: Upstream Connectors は DefectDojo Pro 限定の機能です。 + +対応ツール向けに Connector をセットアップする際は、そのツールの API に関する特定の情報を DefectDojo に提供する必要があります。基本的には、以下が必要です。 + +* **Location** \- 通常、ネットワーク内のツールの URL を指すフィールド +* **Secret** \- 通常は API キー + +ツールによっては、**Location** と **Secret** 以外にも追加の API 関連フィールドが必要になる場合があります。また、DefectDojo からの Connector 接続を受け入れるために、ツール側での設定変更が必要になることもあります。 + +![image](images/connectors_tool_reference.png) + +ツールごとに API の設定は異なるため、このガイドでは DefectDojo が接続できるように各ツールの API をセットアップする方法を説明します。 + +可能な限り、Connector 専用に利用する新しい「DefectDojo Bot」アカウントをセキュリティツール内に作成することをお勧めします。これにより、チームが手動で行った操作と Connector による自動操作を区別しやすくなります。 + +# **Asset Connectors** + +ほとんどの Connector はセキュリティツールから**検出事項**をインポートします。**Asset Connectors** はこれとは異なる動作をします。検出事項ではなく**アセットインベントリ**をインポートします。Asset Connector は外部プラットフォームに存在するアセット(例えば GitLab グループ内のリポジトリ)を列挙し、DefectDojo 内に対応する**製品**(アセット)と**製品タイプ**(組織)を自動的に作成・維持します。Asset Connector によって検出事項がインポートされることはありません。 + +* **Discover** と **Sync** はどちらもアセット一覧を突き合わせます。新しいアセットは `NEW` レコードとして表示され、(自動マッピングが有効な場合は自動的に)マッピングされると、DefectDojo はそのツールから導出された製品タイプ(例えば GitLab の namespace や Azure DevOps のプロジェクト)の下に製品を作成し、グループ化します。 +* アセットが後で上流側で削除された場合(例えばリポジトリが削除された場合)、次の Sync 時にマッピング済みのレコードが `MISSING` としてフラグされ、チームがトリアージできるようになります。DefectDojo が製品を無言で削除することはありません。 + +Azure DevOps、Backstage、Bitbucket、GitHub、GitLab、Jira Service Management Assets、ServiceNow CMDB は Asset Connectors です。runZero は主に Asset Connector ですが、脆弱性を検出事項としてインポートするオプションも備えています。以下に挙げるその他すべての Connector は検出事項をインポートします。 + +# **Supported Connectors** + +- [Acunetix 360](/connectors/toolreference/acunetix_360/) +- [Akamai API Security](/connectors/toolreference/akamai/) +- [Anchore](/connectors/toolreference/anchore_enterprise/) +- [AWS Security Hub](/connectors/toolreference/security_hub/) +- [Azure DevOps](/connectors/toolreference/azure_devops/) +- [Backstage](/connectors/toolreference/backstage/) +- [Black Duck](/connectors/toolreference/black_duck/) +- [Bitbucket](/connectors/toolreference/bitbucket/#upstream-connector) +- [Bugcrowd](/connectors/toolreference/bugcrowd/) +- [Bright Security](/connectors/toolreference/bright_security/) +- [BurpSuite](/connectors/toolreference/burp_suite_enterprise/) +- [Censys](/connectors/toolreference/censys/) +- [Checkmarx ONE](/connectors/toolreference/checkmarx_one/) +- [Cloudflare](/connectors/toolreference/cloudflare/) +- [Cobalt.io](/connectors/toolreference/cobalt_io/) +- [Contrast](/connectors/toolreference/contrast/) +- [Coverity](/connectors/toolreference/coverity/) +- [CrowdStrike Falcon](/connectors/toolreference/crowdstrike_falcon/) +- [Deepfence ThreatMapper](/connectors/toolreference/deepfence_threatmapper/) +- [Dependency-Track](/connectors/toolreference/dependency_track/) +- [Docker Scout](/connectors/toolreference/docker_scout/) +- [Endor Labs](/connectors/toolreference/endor_labs/) +- [Edgescan](/connectors/toolreference/edgescan/) +- [Escape](/connectors/toolreference/escape/) +- [Fairwinds Insights](/connectors/toolreference/fairwinds_insights/) +- [Fortify](/connectors/toolreference/fortify/) +- [GitGuardian](/connectors/toolreference/gitguardian/) +- [GitHub](/connectors/toolreference/github/#upstream-connector) +- [GitHub Advanced Security](/connectors/toolreference/github_advanced_security/) +- [GitLab](/connectors/toolreference/gitlab/#upstream-connector) +- [Google Cloud Security Command Center](/connectors/toolreference/google_cloud_scc/) +- [Group-IB ASM](/connectors/toolreference/group_ib_asm/) +- [HackerOne](/connectors/toolreference/hackerone/) +- [Harbor](/connectors/toolreference/harbor/) +- [Have I Been Pwned](/connectors/toolreference/have_i_been_pwned/) +- [HCL AppScan](/connectors/toolreference/hcl_appscan/) +- [Intigriti](/connectors/toolreference/intigriti/) +- [Intruder](/connectors/toolreference/intruder/) +- [IriusRisk](/connectors/toolreference/iriusrisk/) +- [JFrog Xray](/connectors/toolreference/jfrog_xray/) +- [Jira Service Management Assets](/connectors/toolreference/jsm_assets/) +- [Kubescape](/connectors/toolreference/kubescape/) +- [Mend](/connectors/toolreference/mend/) +- [Lacework / FortiCNAPP](/connectors/toolreference/lacework_forticnapp/) +- [Microsoft Defender](/connectors/toolreference/microsoft_defender/) +- [Microsoft Defender for Cloud](/connectors/toolreference/microsoft_defender_for_cloud/) +- [MobSF](/connectors/toolreference/mobsf/) +- [NeuVector](/connectors/toolreference/neuvector/) +- [Nuclei (ProjectDiscovery Cloud)](/connectors/toolreference/nuclei_projectdiscovery_cloud/) +- [OpenVAS / Greenbone](/connectors/toolreference/openvas_greenbone/) +- [Probely](/connectors/toolreference/probely/) +- [Prowler](/connectors/toolreference/prowler/) +- [Qualys](/connectors/toolreference/qualys/) +- [Quay](/connectors/toolreference/quay/) +- [Rapid7 InsightAppSec](/connectors/toolreference/rapid7_insightappsec/) +- [Rapid7 InsightVM](/connectors/toolreference/rapid7_insightvm/) +- [runZero](/connectors/toolreference/runzero/) +- [Semgrep](/connectors/toolreference/semgrep/) +- [ServiceNow CMDB](/connectors/toolreference/servicenow_cmdb/) +- [Shodan](/connectors/toolreference/shodan/) +- [SonarQube](/connectors/toolreference/sonarqube/) +- [Snyk](/connectors/toolreference/snyk/) +- [Socket](/connectors/toolreference/socket/) +- [Sonatype IQ](/connectors/toolreference/sonatype_iq/) +- [Sysdig Secure](/connectors/toolreference/sysdig_secure/) +- [Tenable](/connectors/toolreference/tenable_io/) +- [Tenable Web App Scanning](/connectors/toolreference/tenable_web_app_scanning/) +- [Veracode](/connectors/toolreference/veracode/) +- [Wazuh](/connectors/toolreference/wazuh/) +- [Wiz](/connectors/toolreference/wiz/) +- [YesWeHack](/connectors/toolreference/yeswehack/) diff --git a/docs/content/connectors/toolreference/upstream.md b/docs/content/connectors/toolreference/upstream.md new file mode 100644 index 00000000000..53763b075cd --- /dev/null +++ b/docs/content/connectors/toolreference/upstream.md @@ -0,0 +1,162 @@ +--- +title: "Upstream Connectors Tool Reference" +description: "Our list of supported Connector tools, and how to set them up with DefectDojo" +weight: 1 +audience: pro +aliases: + - /connectors/upstream/toolreference/ + - /import_data/pro/connectors/connectors_tool_reference/ + - /en/connecting_your_tools/connectors/connectors_tool_reference +--- +Note: Upstream Connectors are a DefectDojo Pro-only feature. + +When setting up a Connector for a supported tool, you'll need to give DefectDojo specific information related to the tool's API. At a base level, you'll need: + +* **Location** \-a field whichgenerallyrefers to your tool's URL in your network, +* **Secret** \- generally an API key. + +Some tools will require additional API\-related fields beyond **Location** and **Secret**. They may also require you to make changes on their side to accommodate an incoming Connector from DefectDojo. + +![image](images/connectors_tool_reference.png) + +Each tool has a different API configuration, and this guide is intended to help you set up the tool's API so that DefectDojo can connect. + +Whenever possible, we recommend creating a new 'DefectDojo Bot' account within your Security Tool which will only be used by the Connector. This will help you better differentiate between actions manually taken by your team, and automated actions taken by the Connector. + +# **Asset Connectors** + +Most Connectors import **findings** from a security tool. **Asset Connectors** work differently: they import your **asset inventory** instead. An Asset Connector enumerates the assets that exist in an external platform (for example, the repositories in a GitLab group) and automatically creates and maintains the matching **Assets** and **Organizations** in DefectDojo. No findings are imported by an Asset Connector. + +* **Discover** and **Sync** both reconcile the asset list. New assets appear as `NEW` Records; once mapped (automatically, if auto-mapping is enabled), DefectDojo creates the Asset and groups it under an Organization derived from the tool — for example, the GitLab namespace or the Azure DevOps project. +* If an asset is later removed upstream (for example, a repository is deleted), its mapped Record is flagged `MISSING` on the next Sync so your team can triage it. DefectDojo never silently deletes an Asset. + +Azure DevOps, Backstage, Bitbucket, GitHub, GitLab, JSM Assets, and ServiceNow CMDB are Asset Connectors. runZero is primarily an Asset Connector but can optionally import vulnerabilities as findings. All other Connectors listed below import findings. + +# **Supported Connectors** + +- [AccuKnox](/connectors/toolreference/accuknox/) +- [Action1](/connectors/toolreference/action1/) +- [Acunetix 360](/connectors/toolreference/acunetix_360/) +- [Akamai](/connectors/toolreference/akamai/) +- [Akto](/connectors/toolreference/akto/) +- [Alert Logic](/connectors/toolreference/alert_logic/) +- [Anchore Enterprise](/connectors/toolreference/anchore_enterprise/) +- [AppCheck](/connectors/toolreference/appcheck/) +- [Aqua Security](/connectors/toolreference/aqua_security/) +- [Automox](/connectors/toolreference/automox/) +- [Azure DevOps](/connectors/toolreference/azure_devops/) +- [Backstage](/connectors/toolreference/backstage/) +- [Beagle Security](/connectors/toolreference/beagle_security/) +- [BigID](/connectors/toolreference/bigid/) +- [Black Duck](/connectors/toolreference/black_duck/) +- [Bitbucket](/connectors/toolreference/bitbucket/#upstream-connector) +- [Black Duck Continuous Dynamic](/connectors/toolreference/black_duck_continuous_dynamic/) +- [Bugcrowd](/connectors/toolreference/bugcrowd/) +- [Bright Security](/connectors/toolreference/bright_security/) +- [Burp Suite Enterprise](/connectors/toolreference/burp_suite_enterprise/) +- [Calico Cloud](/connectors/toolreference/calico_cloud/) +- [Censys](/connectors/toolreference/censys/) +- [Checkmarx One](/connectors/toolreference/checkmarx_one/) +- [Chef Automate](/connectors/toolreference/chef_automate/) +- [CI Fuzz](/connectors/toolreference/ci_fuzz/) +- [Cloudflare](/connectors/toolreference/cloudflare/) +- [Cobalt.io](/connectors/toolreference/cobalt_io/) +- [Codacy](/connectors/toolreference/codacy/) +- [Contrast](/connectors/toolreference/contrast/) +- [Coverity](/connectors/toolreference/coverity/) +- [CrowdStrike Falcon](/connectors/toolreference/crowdstrike_falcon/) +- [CyberArk Certificate Manager](/connectors/toolreference/cyberark_certificate_manager/) +- [Cyberwatch](/connectors/toolreference/cyberwatch/) +- [CyCognito](/connectors/toolreference/cycognito/) +- [Datadog](/connectors/toolreference/datadog/) +- [Deepfence ThreatMapper](/connectors/toolreference/deepfence_threatmapper/) +- [DeepSource](/connectors/toolreference/deepsource/) +- [Dependency-Track](/connectors/toolreference/dependency_track/) +- [Detectify](/connectors/toolreference/detectify/) +- [Docker Scout](/connectors/toolreference/docker_scout/) +- [Dragos](/connectors/toolreference/dragos/) +- [Elastic Security](/connectors/toolreference/elastic_security/) +- [Endor Labs](/connectors/toolreference/endor_labs/) +- [Edgescan](/connectors/toolreference/edgescan/) +- [Escape](/connectors/toolreference/escape/) +- [Fairwinds Insights](/connectors/toolreference/fairwinds_insights/) +- [Finite State](/connectors/toolreference/finite_state/) +- [Fleet](/connectors/toolreference/fleet/) +- [Fortify](/connectors/toolreference/fortify/) +- [FOSSA](/connectors/toolreference/fossa/) +- [GitGuardian](/connectors/toolreference/gitguardian/) +- [GitHub](/connectors/toolreference/github/#upstream-connector) +- [GitHub Advanced Security](/connectors/toolreference/github_advanced_security/) +- [GitLab](/connectors/toolreference/gitlab/#upstream-connector) +- [Google Artifact Analysis](/connectors/toolreference/google_artifact_analysis/) +- [Google Cloud SCC](/connectors/toolreference/google_cloud_scc/) +- [Group-IB ASM](/connectors/toolreference/group_ib_asm/) +- [HackerOne](/connectors/toolreference/hackerone/) +- [Halo Security](/connectors/toolreference/halo_security/) +- [Harbor](/connectors/toolreference/harbor/) +- [Have I Been Pwned](/connectors/toolreference/have_i_been_pwned/) +- [HCL AppScan](/connectors/toolreference/hcl_appscan/) +- [HiddenLayer](/connectors/toolreference/hiddenlayer/) +- [Holm Security](/connectors/toolreference/holm_security/) +- [ImmuniWeb](/connectors/toolreference/immuniweb/) +- [InsightCloudSec](/connectors/toolreference/insightcloudsec/) +- [Intigriti](/connectors/toolreference/intigriti/) +- [Intruder](/connectors/toolreference/intruder/) +- [IriusRisk](/connectors/toolreference/iriusrisk/) +- [JFrog XRay](/connectors/toolreference/jfrog_xray/) +- [JSM Assets](/connectors/toolreference/jsm_assets/) +- [Klocwork](/connectors/toolreference/klocwork/) +- [Kubescape](/connectors/toolreference/kubescape/) +- [Mend](/connectors/toolreference/mend/) +- [Lacework / FortiCNAPP](/connectors/toolreference/lacework_forticnapp/) +- [Microsoft Defender](/connectors/toolreference/microsoft_defender/) +- [Microsoft Defender for Cloud](/connectors/toolreference/microsoft_defender_for_cloud/) +- [MobSF](/connectors/toolreference/mobsf/) +- [NetRise](/connectors/toolreference/netrise/) +- [NeuVector](/connectors/toolreference/neuvector/) +- [Nightfall AI](/connectors/toolreference/nightfall_ai/) +- [NowSecure](/connectors/toolreference/nowsecure/) +- [Nozomi Networks](/connectors/toolreference/nozomi_networks/) +- [Nuclei (ProjectDiscovery Cloud)](/connectors/toolreference/nuclei_projectdiscovery_cloud/) +- [OpenVAS / Greenbone](/connectors/toolreference/openvas_greenbone/) +- [Orca Security](/connectors/toolreference/orca_security/) +- [Ostorlab](/connectors/toolreference/ostorlab/) +- [Parasoft DTP](/connectors/toolreference/parasoft_dtp/) +- [Picus Security](/connectors/toolreference/picus_security/) +- [PingCastle](/connectors/toolreference/pingcastle/) +- [Probely](/connectors/toolreference/probely/) +- [Promptfoo](/connectors/toolreference/promptfoo/) +- [Prowler](/connectors/toolreference/prowler/) +- [Qualys](/connectors/toolreference/qualys/) +- [Quay](/connectors/toolreference/quay/) +- [Qwiet AI](/connectors/toolreference/qwiet_ai/) +- [Rapid7 InsightAppSec](/connectors/toolreference/rapid7_insightappsec/) +- [Rapid7 InsightVM](/connectors/toolreference/rapid7_insightvm/) +- [Red Hat Satellite](/connectors/toolreference/red_hat_satellite/) +- [runZero](/connectors/toolreference/runzero/) +- [Scantist](/connectors/toolreference/scantist/) +- [Security Hub](/connectors/toolreference/security_hub/) +- [Semgrep](/connectors/toolreference/semgrep/) +- [ServiceNow CMDB](/connectors/toolreference/servicenow_cmdb/) +- [Shodan](/connectors/toolreference/shodan/) +- [SonarQube](/connectors/toolreference/sonarqube/) +- [Snyk](/connectors/toolreference/snyk/) +- [Socket](/connectors/toolreference/socket/) +- [Sonatype IQ](/connectors/toolreference/sonatype_iq/) +- [SOOS](/connectors/toolreference/soos/) +- [Sysdig Secure](/connectors/toolreference/sysdig_secure/) +- [Tenable.io](/connectors/toolreference/tenable_io/) +- [Tenable Web App Scanning](/connectors/toolreference/tenable_web_app_scanning/) +- [TruffleHog](/connectors/toolreference/trufflehog/) +- [Trustwave Fusion](/connectors/toolreference/trustwave_fusion/) +- [Uptycs](/connectors/toolreference/uptycs/) +- [Vanta](/connectors/toolreference/vanta/) +- [Veracode](/connectors/toolreference/veracode/) +- [Vulnerability Manager Plus](/connectors/toolreference/vulnerability_manager_plus/) +- [Wallarm](/connectors/toolreference/wallarm/) +- [Wazuh](/connectors/toolreference/wazuh/) +- [WebInspect Enterprise](/connectors/toolreference/webinspect_enterprise/) +- [Wiz](/connectors/toolreference/wiz/) +- [YesWeHack](/connectors/toolreference/yeswehack/) +- [Zimperium](/connectors/toolreference/zimperium/) +- [Zora](/connectors/toolreference/zora/) diff --git a/docs/content/connectors/toolreference/uptycs.md b/docs/content/connectors/toolreference/uptycs.md new file mode 100644 index 00000000000..2ec646857f7 --- /dev/null +++ b/docs/content/connectors/toolreference/uptycs.md @@ -0,0 +1,25 @@ +--- +title: "Uptycs" +description: "How to set up the Uptycs Upstream Connector for DefectDojo" +weight: 135 +audience: pro +--- +The Uptycs connector imports **vulnerability findings** from your Uptycs tenant. DefectDojo creates a Record for each **asset group**. + +#### Prerequisites + +Three values from Uptycs: + +* Your **customer ID**, shown in the API key file. +* An **API key ID**, from **Configuration \> User \> API Keys**. +* The matching **API secret**, which DefectDojo uses to sign a per\-request token. It is never logged. + +#### Connector Mappings + +1. Enter your Uptycs stack URL in the **Location** field — for example `https://your-stack.uptycs.io`. +2. Enter the customer ID in the **Customer ID** field. +3. Enter the API key ID in the **Key** field. +4. Enter the API secret in the **Secret** field. +5. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each asset group becomes a Record. Uptycs vulnerabilities are read through its osquery-style query engine, so the imported finding set is whatever that query returns for your tenant. diff --git a/docs/content/connectors/toolreference/vanta.md b/docs/content/connectors/toolreference/vanta.md new file mode 100644 index 00000000000..7841bd51d30 --- /dev/null +++ b/docs/content/connectors/toolreference/vanta.md @@ -0,0 +1,20 @@ +--- +title: "Vanta" +description: "How to set up the Vanta Upstream Connector for DefectDojo" +weight: 136 +audience: pro +--- +The Vanta connector imports **failing compliance tests** from Vanta. DefectDojo creates a Record for each Vanta **integration**, plus an organization\-wide catch\-all for tests that belong to none. + +#### Prerequisites + +An OAuth **client ID and secret** from Vanta. Create them under **Settings \> Developer Console** as a **"Manage Vanta"** app — other app types will not have the access this connector needs. + +#### Connector Mappings + +1. Enter your Vanta API URL in the **Location** field. +2. Enter the OAuth client ID in the **Client ID** field. +3. Enter the client secret in the **Client Secret** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each **failing resource of a failing test** becomes a finding, grouped under the integration the test belongs to — so a single failing control across many resources produces a finding per resource. diff --git a/docs/content/connectors/toolreference/veracode.de.md b/docs/content/connectors/toolreference/veracode.de.md new file mode 100644 index 00000000000..2264d430ff8 --- /dev/null +++ b/docs/content/connectors/toolreference/veracode.de.md @@ -0,0 +1,20 @@ +--- +title: "Veracode" +description: "Einrichtung des Veracode Upstream-Connectors für DefectDojo" +weight: 137 +audience: pro +--- +Der Veracode-Connector importiert Anwendungsbefunde von der Veracode-Plattform, aufgeteilt nach Scan-Typ in die Befundtypen **SAST**, **DAST**, **SCA** und **Manual**. DefectDojo erstellt für jede Veracode-**Anwendung** einen Eintrag. + +#### Voraussetzungen + +Generieren Sie eine Veracode-**API-Anmeldeinformation** für ein Konto, das die zu importierenden Anwendungen sehen kann: Öffnen Sie in der Veracode-Plattform Ihr Kontomenü \> **API Credentials** und wählen Sie **Generate API Credentials** (siehe [Managing Veracode API credentials](https://docs.veracode.com/r/c_api_credentials3)). Kopieren Sie sowohl die **API ID** als auch den **API Secret Key** — das Secret wird nur einmal angezeigt. + +#### Connector-Zuordnungen + +1. Geben Sie die Basis-URL der Veracode-API in das Feld **Location** ein: `https://api.veracode.com` (kommerzielle Region), `https://api.veracode.eu` (europäische Region) oder `https://api.veracode.us` (US-Bundesregion). +2. Geben Sie die API ID in das Feld **API ID** ein. +3. Geben Sie den API Secret Key in das Feld **Secret** ein. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. + +Jede Veracode-Anwendung wird zu einem Eintrag. Es werden nur **offene** Befunde importiert, sodass ein erneuter Import von Veracode als behoben gemeldete Befunde schließt. diff --git a/docs/content/connectors/toolreference/veracode.es.md b/docs/content/connectors/toolreference/veracode.es.md new file mode 100644 index 00000000000..eb35bcb395f --- /dev/null +++ b/docs/content/connectors/toolreference/veracode.es.md @@ -0,0 +1,20 @@ +--- +title: "Veracode" +description: "Cómo configurar el Conector Upstream de Veracode para DefectDojo" +weight: 137 +audience: pro +--- +El conector de Veracode importa hallazgos de aplicaciones desde la plataforma Veracode, divididos por tipo de análisis en los tipos de hallazgo **SAST**, **DAST**, **SCA** y **Manual**. DefectDojo crea un Record para cada **aplicación** de Veracode. + +#### Prerrequisitos + +Genere una **credencial de API** de Veracode para una cuenta que pueda ver las aplicaciones que desea importar: en la Veracode Platform, abra el menú de su cuenta > **API Credentials** y seleccione **Generate API Credentials** (consulte [Managing Veracode API credentials](https://docs.veracode.com/r/c_api_credentials3)). Copie tanto el **API ID** como la **API Secret Key** — la clave secreta solo se muestra una vez. + +#### Asignaciones del conector + +1. Introduzca la URL base de la API de Veracode en el campo **Location**: `https://api.veracode.com` (región comercial), `https://api.veracode.eu` (región europea), o `https://api.veracode.us` (región federal de EE. UU.). +2. Introduzca el API ID en el campo **API ID**. +3. Introduzca la clave secreta de API en el campo **Secret**. +4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. + +Cada aplicación de Veracode se convierte en un Record. Solo se importan los hallazgos **abiertos**, por lo que una nueva importación cierra los hallazgos que Veracode reporta como resueltos. diff --git a/docs/content/connectors/toolreference/veracode.fr.md b/docs/content/connectors/toolreference/veracode.fr.md new file mode 100644 index 00000000000..f60182749d0 --- /dev/null +++ b/docs/content/connectors/toolreference/veracode.fr.md @@ -0,0 +1,20 @@ +--- +title: "Veracode" +description: "Comment configurer le Connecteur Upstream Veracode pour DefectDojo" +weight: 137 +audience: pro +--- +Le connecteur Veracode importe les constatations d'application depuis la plateforme Veracode, réparties par type de scan en types de constatation **SAST**, **DAST**, **SCA** et **Manual**. DefectDojo crée un Enregistrement pour chaque **application** Veracode. + +#### Prérequis + +Générez un **identifiant API** Veracode pour un compte pouvant voir les applications que vous souhaitez importer : dans la plateforme Veracode, ouvrez le menu de votre compte > **API Credentials** et sélectionnez **Generate API Credentials** (voir [Gestion des identifiants API Veracode](https://docs.veracode.com/r/c_api_credentials3)). Copiez à la fois l'**API ID** et l'**API Secret Key** — la clé secrète n'est affichée qu'une seule fois. + +#### Mappages du connecteur + +1. Saisissez l'URL de base de l'API Veracode dans le champ **Location** : `https://api.veracode.com` (région commerciale), `https://api.veracode.eu` (région européenne), ou `https://api.veracode.us` (région fédérale américaine). +2. Saisissez l'API ID dans le champ **API ID**. +3. Saisissez la clé secrète API dans le champ **Secret**. +4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. + +Chaque application Veracode devient un Enregistrement. Seules les constatations **open** sont importées, donc une réimportation ferme les constatations que Veracode signale comme résolues. diff --git a/docs/content/connectors/toolreference/veracode.ja.md b/docs/content/connectors/toolreference/veracode.ja.md new file mode 100644 index 00000000000..6b5c6901346 --- /dev/null +++ b/docs/content/connectors/toolreference/veracode.ja.md @@ -0,0 +1,20 @@ +--- +title: "Veracode" +description: "DefectDojo で Veracode の Upstream Connector をセットアップする方法" +weight: 137 +audience: pro +--- +Veracode コネクタは、Veracode プラットフォームからアプリケーションの検出事項をインポートし、スキャンタイプごとに **SAST**、**DAST**、**SCA**、**Manual** の検出事項タイプに分けます。DefectDojo は Veracode の**アプリケーション**ごとに Record を作成します。 + +#### Prerequisites + +インポートしたいアプリケーションを閲覧できるアカウントに対して、Veracode の **API 認証情報**を生成します: Veracode プラットフォームでアカウントメニューを開き、**API Credentials** から **Generate API Credentials** を選択します([Veracode API 認証情報の管理](https://docs.veracode.com/r/c_api_credentials3)を参照)。**API ID** と **API Secret Key** の両方をコピーしてください — シークレットは一度しか表示されません。 + +#### Connector Mappings + +1. **Location** フィールドに Veracode API のベース URL を入力します: `https://api.veracode.com`(商用リージョン)、`https://api.veracode.eu`(欧州リージョン)、または `https://api.veracode.us`(米国連邦リージョン)です。 +2. **API ID** フィールドに API ID を入力します。 +3. **Secret** フィールドに API シークレットキーを入力します。 +4. 必要に応じて、**Minimum Severity** を設定してインポートする検出事項を絞り込みます。 + +各 Veracode アプリケーションは Record になります。**open**(未解決)の検出事項のみがインポートされるため、再インポートを行うと、Veracode が解決済みと報告した検出事項はクローズされます。 diff --git a/docs/content/connectors/toolreference/veracode.md b/docs/content/connectors/toolreference/veracode.md new file mode 100644 index 00000000000..36798823f21 --- /dev/null +++ b/docs/content/connectors/toolreference/veracode.md @@ -0,0 +1,20 @@ +--- +title: "Veracode" +description: "How to set up the Veracode Upstream Connector for DefectDojo" +weight: 137 +audience: pro +--- +The Veracode connector imports application findings from the Veracode platform, split by scan type into **SAST**, **DAST**, **SCA**, and **Manual** finding types. DefectDojo creates a Record for each Veracode **application**. + +#### Prerequisites + +Generate a Veracode **API credential** for an account that can see the applications you want to import: in the Veracode Platform, open your account menu \> **API Credentials** and select **Generate API Credentials** (see [Managing Veracode API credentials](https://docs.veracode.com/r/c_api_credentials3)). Copy both the **API ID** and the **API Secret Key** — the secret is shown only once. + +#### Connector Mappings + +1. Enter the Veracode API base URL in the **Location** field: `https://api.veracode.com` (commercial region), `https://api.veracode.eu` (European region), or `https://api.veracode.us` (US federal region). +2. Enter the API ID in the **API ID** field. +3. Enter the API secret key in the **Secret** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each Veracode application becomes a Record. Only **open** findings are imported, so reimport closes findings Veracode reports as resolved. diff --git a/docs/content/connectors/toolreference/vulnerability_manager_plus.md b/docs/content/connectors/toolreference/vulnerability_manager_plus.md new file mode 100644 index 00000000000..88cb5c4fa97 --- /dev/null +++ b/docs/content/connectors/toolreference/vulnerability_manager_plus.md @@ -0,0 +1,19 @@ +--- +title: "Vulnerability Manager Plus" +description: "How to set up the Vulnerability Manager Plus Upstream Connector for DefectDojo" +weight: 138 +audience: pro +--- +The Vulnerability Manager Plus connector imports **endpoint vulnerability findings** from ManageEngine Vulnerability Manager Plus. DefectDojo creates a Record for each **host**. + +#### Prerequisites + +A Vulnerability Manager Plus **API token**, from **Admin \> API key generation**. It is never logged. + +#### Connector Mappings + +1. Enter your Vulnerability Manager Plus server URL in the **Location** field. +2. Enter the API token in the **Auth Token** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each host becomes a Record, carrying the vulnerabilities detected on it. diff --git a/docs/content/connectors/toolreference/wallarm.md b/docs/content/connectors/toolreference/wallarm.md new file mode 100644 index 00000000000..7a0b423c472 --- /dev/null +++ b/docs/content/connectors/toolreference/wallarm.md @@ -0,0 +1,19 @@ +--- +title: "Wallarm" +description: "How to set up the Wallarm Upstream Connector for DefectDojo" +weight: 139 +audience: pro +--- +The Wallarm connector imports **API security findings** from Wallarm. DefectDojo creates a Record for each **affected domain**. + +#### Prerequisites + +A Wallarm **API token**, from **Console \> Settings \> API tokens**. A **Read Only** role is sufficient, and the token is never logged. + +#### Connector Mappings + +1. Enter your Wallarm cloud URL in the **Location** field — `https://api.wallarm.com` for the EU cloud or `https://us1.api.wallarm.com` for the US cloud. +2. Enter the API token in the **API Token** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each affected domain becomes a Record, carrying the account's API security vulnerabilities that affect it. diff --git a/docs/content/connectors/toolreference/wazuh.de.md b/docs/content/connectors/toolreference/wazuh.de.md new file mode 100644 index 00000000000..f84aec3f428 --- /dev/null +++ b/docs/content/connectors/toolreference/wazuh.de.md @@ -0,0 +1,25 @@ +--- +title: "Wazuh" +description: "Einrichtung des Wazuh Upstream-Connectors für DefectDojo" +weight: 140 +audience: pro +--- +Der Wazuh-Connector verwendet den Wazuh Indexer (OpenSearch), um Schwachstellenbefunde abzurufen. Wazuh 4.8 und später speichern erkannte CVEs im Indexer statt in der Wazuh-Server-API, daher liest dieser Connector sie direkt aus dem Index `wazuh-states-vulnerabilities-*`. + +DefectDojo erstellt für jeden Wazuh-Agenten (Endpunkt) einen Eintrag und importiert die von diesem Agenten erkannten CVEs geplant als Befunde. + +#### Voraussetzungen + +Sie benötigen: + +* Die Basis-URL Ihres Wazuh Indexer einschließlich des Ports (der Indexer lauscht standardmäßig auf Port 9200). DefectDojo verbindet sich direkt mit dem Indexer, dieser Endpunkt muss daher von DefectDojo aus erreichbar sein. Bei selbstverwalteten Bereitstellungen ist dies der Host, auf dem der Wazuh Indexer läuft. Verwenden Sie bei Wazuh Cloud den in Ihrer Wazuh-Cloud-Konsole angezeigten Indexer-Endpunkt, der sich von der Wazuh-Dashboard-URL unterscheidet. +* Einen Indexer-Benutzer und ein Passwort mit Lesezugriff auf den Index `wazuh-states-vulnerabilities-*`. Wir empfehlen, für DefectDojo einen dedizierten Benutzer anzulegen. + +Die Schwachstellenerkennung muss in Wazuh aktiviert sein, damit der Vulnerability-State-Index befüllt wird. Weitere Informationen finden Sie in der [Wazuh-Dokumentation zur Schwachstellenerkennung](https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html). + +#### Connector-Zuordnungen + +1. Geben Sie die Basis-URL Ihres Wazuh Indexer einschließlich Schema und Port in das Feld **Location** ein, zum Beispiel `https://your-indexer.example.com:9200`. Geben Sie keinen abschließenden Pfad an. DefectDojo erstellt die Suchpfade automatisch. +2. Geben Sie den Indexer-Benutzernamen in das Feld **Username** ein. +3. Geben Sie das Indexer-Passwort in das Feld **Password** ein. +4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. diff --git a/docs/content/connectors/toolreference/wazuh.es.md b/docs/content/connectors/toolreference/wazuh.es.md new file mode 100644 index 00000000000..630d32b05cf --- /dev/null +++ b/docs/content/connectors/toolreference/wazuh.es.md @@ -0,0 +1,25 @@ +--- +title: "Wazuh" +description: "Cómo configurar el Conector Upstream de Wazuh para DefectDojo" +weight: 140 +audience: pro +--- +El conector de Wazuh usa el Wazuh Indexer (OpenSearch) para obtener hallazgos de vulnerabilidades. Wazuh 4.8 y versiones posteriores almacenan los CVE detectados en el Indexer en lugar de en la API del servidor Wazuh, por lo que este conector los lee directamente del índice `wazuh-states-vulnerabilities-*`. + +DefectDojo crea un Record para cada agente (endpoint) de Wazuh e importa los CVE detectados de ese agente como hallazgos de forma programada. + +#### Prerrequisitos + +Necesitará: + +* La URL base de su Wazuh Indexer, incluido el puerto (el Indexer escucha por defecto en el puerto 9200). DefectDojo se conecta directamente al Indexer, por lo que este endpoint debe ser accesible desde DefectDojo. Para implementaciones autoadministradas, es el host que ejecuta el Wazuh Indexer. Para Wazuh Cloud, use el endpoint del Indexer que se muestra en su consola de Wazuh Cloud, que es distinto de la URL del panel de Wazuh. +* Un usuario y contraseña del Indexer con acceso de lectura al índice `wazuh-states-vulnerabilities-*`. Recomendamos crear un usuario dedicado para DefectDojo. + +La detección de vulnerabilidades debe estar habilitada en Wazuh para que se rellene el índice de estado de vulnerabilidades. Consulte la [documentación de detección de vulnerabilidades de Wazuh](https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html) para más información. + +#### Asignaciones del conector + +1. Introduzca la URL base de su Wazuh Indexer en el campo **Location**, incluyendo el esquema y el puerto, por ejemplo `https://your-indexer.example.com:9200`. No incluya una ruta final. DefectDojo construye las rutas de búsqueda automáticamente. +2. Introduzca el nombre de usuario del Indexer en el campo **Username**. +3. Introduzca la contraseña del Indexer en el campo **Password**. +4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importarán. diff --git a/docs/content/connectors/toolreference/wazuh.fr.md b/docs/content/connectors/toolreference/wazuh.fr.md new file mode 100644 index 00000000000..def73658137 --- /dev/null +++ b/docs/content/connectors/toolreference/wazuh.fr.md @@ -0,0 +1,25 @@ +--- +title: "Wazuh" +description: "Comment configurer le Connecteur Upstream Wazuh pour DefectDojo" +weight: 140 +audience: pro +--- +Le connecteur Wazuh utilise le Wazuh Indexer (OpenSearch) pour récupérer les constatations de vulnérabilité. Wazuh 4.8 et versions ultérieures stockent les CVE détectées dans l'Indexer plutôt que dans l'API du serveur Wazuh ; ce connecteur les lit donc directement dans l'index `wazuh-states-vulnerabilities-*`. + +DefectDojo crée un Enregistrement pour chaque agent Wazuh (point de terminaison) et importe les CVE détectées par cet agent comme constatations selon une planification. + +#### Prérequis + +Vous aurez besoin de : + +* L'URL de base de votre Wazuh Indexer, port inclus (l'Indexer écoute par défaut sur le port 9200). DefectDojo se connecte directement à l'Indexer, ce point de terminaison doit donc être accessible depuis DefectDojo. Pour les déploiements auto-gérés, il s'agit de l'hôte exécutant le Wazuh Indexer. Pour Wazuh Cloud, utilisez le point de terminaison de l'Indexer indiqué dans votre console Wazuh Cloud, distinct de l'URL du tableau de bord Wazuh. +* Un utilisateur et un mot de passe Indexer disposant d'un accès en lecture à l'index `wazuh-states-vulnerabilities-*`. Nous recommandons de créer un utilisateur dédié pour DefectDojo. + +La détection de vulnérabilités doit être activée dans Wazuh pour que l'index d'état des vulnérabilités soit alimenté. Consultez la [documentation de détection de vulnérabilités de Wazuh](https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html) pour plus d'informations. + +#### Mappages du connecteur + +1. Saisissez l'URL de base de votre Wazuh Indexer dans le champ **Location**, avec le schéma et le port, par exemple `https://your-indexer.example.com:9200`. N'incluez pas de chemin final. DefectDojo construit automatiquement les chemins de recherche. +2. Saisissez le nom d'utilisateur de l'Indexer dans le champ **Username**. +3. Saisissez le mot de passe de l'Indexer dans le champ **Password**. +4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. Les constatations en dessous de la sévérité sélectionnée ne seront pas importées. diff --git a/docs/content/connectors/toolreference/wazuh.ja.md b/docs/content/connectors/toolreference/wazuh.ja.md new file mode 100644 index 00000000000..4e6289575e0 --- /dev/null +++ b/docs/content/connectors/toolreference/wazuh.ja.md @@ -0,0 +1,25 @@ +--- +title: "Wazuh" +description: "DefectDojo で Wazuh の Upstream Connector をセットアップする方法" +weight: 140 +audience: pro +--- +Wazuh コネクタは、Wazuh Indexer(OpenSearch)を使用して脆弱性の検出事項を取得します。Wazuh 4.8 以降では、検出された CVE は Wazuh サーバー API ではなく Indexer に保存されるため、このコネクタは `wazuh-states-vulnerabilities-*` インデックスから直接それらを読み取ります。 + +DefectDojo は Wazuh エージェント(エンドポイント)ごとに Record を作成し、そのエージェントで検出された CVE をスケジュールに基づいて検出事項としてインポートします。 + +#### Prerequisites + +以下が必要です。 + +* ポートを含む Wazuh Indexer のベース URL(Indexer はデフォルトでポート 9200 で待ち受けます)。DefectDojo は Indexer に直接接続するため、このエンドポイントは DefectDojo から到達可能である必要があります。セルフマネージド環境では、これは Wazuh Indexer を実行しているホストです。Wazuh Cloud の場合は、Wazuh Cloud コンソールに表示される Indexer エンドポイントを使用してください。これは Wazuh ダッシュボードの URL とは別のものです。 +* `wazuh-states-vulnerabilities-*` インデックスへの読み取りアクセス権を持つ Indexer のユーザーとパスワード。DefectDojo 専用のユーザーを作成することをお勧めします。 + +脆弱性状態インデックスにデータが投入されるよう、Wazuh で脆弱性検出を有効にしておく必要があります。詳細については、[Wazuh 脆弱性検出ドキュメント](https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html)を参照してください。 + +#### Connector Mappings + +1. **Location** フィールドに、スキームとポートを含む Wazuh Indexer のベース URL を入力します。例: `https://your-indexer.example.com:9200`。末尾にパスを含めないでください。DefectDojo が検索パスを自動的に構築します。 +2. **Username** フィールドに Indexer のユーザー名を入力します。 +3. **Password** フィールドに Indexer のパスワードを入力します。 +4. 必要に応じて、**Minimum Severity** を設定してインポートする検出事項を絞り込みます。選択した深刻度を下回る検出事項はインポートされません。 diff --git a/docs/content/connectors/toolreference/wazuh.md b/docs/content/connectors/toolreference/wazuh.md new file mode 100644 index 00000000000..6cdf6ca0462 --- /dev/null +++ b/docs/content/connectors/toolreference/wazuh.md @@ -0,0 +1,25 @@ +--- +title: "Wazuh" +description: "How to set up the Wazuh Upstream Connector for DefectDojo" +weight: 140 +audience: pro +--- +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. diff --git a/docs/content/connectors/toolreference/webinspect_enterprise.md b/docs/content/connectors/toolreference/webinspect_enterprise.md new file mode 100644 index 00000000000..1b9d37c4c14 --- /dev/null +++ b/docs/content/connectors/toolreference/webinspect_enterprise.md @@ -0,0 +1,19 @@ +--- +title: "WebInspect Enterprise" +description: "How to set up the WebInspect Enterprise Upstream Connector for DefectDojo" +weight: 141 +audience: pro +--- +The WebInspect Enterprise connector imports **DAST findings** from a WebInspect Enterprise (WIE) server. DefectDojo creates a Record for each **application** the token can see. + +#### Prerequisites + +A WebInspect Enterprise **API token**. WIE accepts a Fortify\-style API token, and it is never logged. + +#### Connector Mappings + +1. Enter your WebInspect Enterprise server URL in the **Location** field. +2. Enter the API token in the **Secret** field. +3. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each application becomes a Record, and its findings come from that application's **most recent completed scan**. diff --git a/docs/content/connectors/toolreference/wiz.de.md b/docs/content/connectors/toolreference/wiz.de.md new file mode 100644 index 00000000000..bfe28c0815d --- /dev/null +++ b/docs/content/connectors/toolreference/wiz.de.md @@ -0,0 +1,18 @@ +--- +title: "Wiz" +description: "Einrichtung des Wiz Upstream-Connectors für DefectDojo" +weight: 142 +audience: pro +--- +Um den Wiz-Connector zu verwenden, müssen Sie ein Service-Konto erstellen: siehe die [Wiz-Dokumentation](https://docs.wiz.io/wiz-docs/docs/service-accounts-settings#add-a-service-account) für weitere Informationen. Sie benötigen ein Wiz-Konto, um auf die Dokumentation zuzugreifen. + +Das Service-Konto muss alle folgenden Anforderungen erfüllen. Ein Service-Konto, dem eine davon fehlt, kann sich zwar erfolgreich authentifizieren, importiert aber nichts: + +* **Type**: Custom Integration (GraphQL API). +* **API-Scopes**: mindestens `read:projects`, `read:issues` und `read:vulnerabilities`. +* **Projekt-Sichtbarkeit**: Das Service-Konto muss auf jedes zu importierende Wiz-Projekt beschränkt sein (oder auf alle Projekte). Der Connector ermittelt zunächst Ihre Wiz-Projekte und ruft dann die Befunde jedes Projekts ab — ein Konto, das Issues lesen kann, aber keine Projekt-Sichtbarkeit hat, ermittelt null Projekte, sodass nichts zu importieren ist und von keiner Seite ein Fehler gemeldet wird. + +#### **Connector-Zuordnungen** + +1. Geben Sie Ihre Wiz Client ID in das Feld Client ID ein. +2. Geben Sie das Wiz Client Secret in das Feld Secret ein. diff --git a/docs/content/connectors/toolreference/wiz.es.md b/docs/content/connectors/toolreference/wiz.es.md new file mode 100644 index 00000000000..5d1b3110f74 --- /dev/null +++ b/docs/content/connectors/toolreference/wiz.es.md @@ -0,0 +1,18 @@ +--- +title: "Wiz" +description: "Cómo configurar el Conector Upstream de Wiz para DefectDojo" +weight: 142 +audience: pro +--- +Para usar el conector de Wiz es necesario crear una cuenta de servicio: consulte la [documentación de Wiz](https://docs.wiz.io/wiz-docs/docs/service-accounts-settings#add-a-service-account) para más información. Necesitará una cuenta de Wiz para acceder a la documentación. + +La cuenta de servicio debe cumplir todos los siguientes requisitos. Una cuenta de servicio a la que le falte alguno de ellos aún puede autenticarse correctamente, pero no importará nada: + +* **Type**: Custom Integration (GraphQL API). +* **API scopes**: como mínimo `read:projects`, `read:issues`, y `read:vulnerabilities`. +* **Project visibility**: la cuenta de servicio debe tener alcance sobre cada Wiz Project que desee importar (o sobre todos los Projects). El conector descubre primero sus Wiz Projects y luego obtiene los hallazgos de cada Project — una cuenta que puede leer issues pero no tiene visibilidad de Projects descubre cero Projects, por lo que no hay nada que importar y ninguno de los dos lados reporta un error. + +#### **Asignaciones del conector** + +1. Introduzca su Wiz Client ID en el campo Client ID. +2. Introduzca el Wiz Client Secret en el campo Secret. diff --git a/docs/content/connectors/toolreference/wiz.fr.md b/docs/content/connectors/toolreference/wiz.fr.md new file mode 100644 index 00000000000..ccd0bc4397a --- /dev/null +++ b/docs/content/connectors/toolreference/wiz.fr.md @@ -0,0 +1,18 @@ +--- +title: "Wiz" +description: "Comment configurer le Connecteur Upstream Wiz pour DefectDojo" +weight: 142 +audience: pro +--- +L'utilisation du connecteur Wiz nécessite la création d'un compte de service : consultez la [documentation Wiz](https://docs.wiz.io/wiz-docs/docs/service-accounts-settings#add-a-service-account) pour plus d'informations. Vous aurez besoin d'un compte Wiz pour accéder à la documentation. + +Le compte de service doit répondre à toutes les exigences suivantes. Un compte de service qui n'en respecte pas une peut tout de même s'authentifier avec succès mais n'importera rien : + +* **Type**: Custom Integration (GraphQL API). +* **API scopes**: au minimum `read:projects`, `read:issues`, et `read:vulnerabilities`. +* **Project visibility**: le compte de service doit être limité à chaque Wiz Project que vous souhaitez importer (ou à tous les Projects). Le connecteur découvre d'abord vos Wiz Projects, puis récupère les constatations de chaque Project — un compte qui peut lire les issues mais n'a de visibilité sur aucun Project ne découvre aucun Project, il n'y a donc rien à importer et aucune erreur n'est signalée par l'un ou l'autre des systèmes. + +#### **Mappages du connecteur** + +1. Saisissez votre Wiz Client ID dans le champ Client ID. +2. Saisissez le Wiz Client Secret dans le champ Secret. diff --git a/docs/content/connectors/toolreference/wiz.ja.md b/docs/content/connectors/toolreference/wiz.ja.md new file mode 100644 index 00000000000..094aa6c6444 --- /dev/null +++ b/docs/content/connectors/toolreference/wiz.ja.md @@ -0,0 +1,18 @@ +--- +title: "Wiz" +description: "DefectDojo で Wiz の Upstream Connector をセットアップする方法" +weight: 142 +audience: pro +--- +Wiz コネクタを使用するには、サービスアカウントを作成する必要があります。詳細については [Wiz のドキュメント](https://docs.wiz.io/wiz-docs/docs/service-accounts-settings#add-a-service-account)を参照してください。ドキュメントにアクセスするには Wiz アカウントが必要です。 + +サービスアカウントは、以下の要件をすべて満たしている必要があります。いずれかを満たしていないサービスアカウントでも認証自体は成功しますが、何もインポートされません。 + +* **Type**: Custom Integration(GraphQL API)。 +* **API scopes**: 最低限 `read:projects`、`read:issues`、`read:vulnerabilities` が必要です。 +* **Project visibility**: サービスアカウントは、インポートしたいすべての Wiz Project(またはすべての Project)に対してスコープが設定されている必要があります。コネクタはまず Wiz Project を検出し、その後各 Project の検出事項を取得します — issue を読み取れても Project の可視性がないアカウントは Project を 1 つも検出できないため、インポートするものがなく、双方からエラーも報告されません。 + +#### **Connector Mappings** + +1. Client ID フィールドに Wiz の Client ID を入力します。 +2. Secret フィールドに Wiz の Client Secret を入力します。 diff --git a/docs/content/connectors/toolreference/wiz.md b/docs/content/connectors/toolreference/wiz.md new file mode 100644 index 00000000000..27cfdd4aae3 --- /dev/null +++ b/docs/content/connectors/toolreference/wiz.md @@ -0,0 +1,18 @@ +--- +title: "Wiz" +description: "How to set up the Wiz Upstream Connector for DefectDojo" +weight: 142 +audience: pro +--- +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. + +The service account must meet all of the following requirements. A service account that misses one of them can still authenticate successfully but will import nothing: + +* **Type**: Custom Integration (GraphQL API). +* **API scopes**: at minimum `read:projects`, `read:issues`, and `read:vulnerabilities`. +* **Project visibility**: the service account must be scoped to every Wiz Project you want imported (or to all Projects). The connector discovers your Wiz Projects first and then pulls each Project's findings — an account that can read issues but has no Project visibility discovers zero Projects, so there is nothing to import and no error is reported by either side. + +#### **Connector Mappings** + +1. Enter your Wiz Client ID in the Client ID field. +2. Enter the Wiz Client Secret in the Secret field. diff --git a/docs/content/connectors/toolreference/yeswehack.de.md b/docs/content/connectors/toolreference/yeswehack.de.md new file mode 100644 index 00000000000..5792be5e5c5 --- /dev/null +++ b/docs/content/connectors/toolreference/yeswehack.de.md @@ -0,0 +1,22 @@ +--- +title: "YesWeHack" +description: "Einrichtung des YesWeHack Upstream-Connectors für DefectDojo" +weight: 143 +audience: pro +--- +Der YesWeHack-Connector verwendet die YesWeHack-REST-API, um Reports aus Ihren Bug-Bounty- und Vulnerability-Disclosure-Programmen zu importieren. DefectDojo erstellt für jedes Programm, auf das Ihr Token zugreifen kann, einen Eintrag und importiert dessen Reports als Befunde. + +#### Voraussetzungen + +Sie benötigen ein YesWeHack-**Personal Access Token (PAT)**. Lesezugriff auf Ihre Programme ist ausreichend. Manche Konten erfordern beim Erstellen eines Tokens TOTP/MFA; einmal erstellt, verwendet der Connector nur den Token-Wert selbst. + +1. Öffnen Sie in YesWeHack Ihre Kontoeinstellungen und gehen Sie zu **API / Personal Access Tokens**. +2. Erstellen Sie ein Token und kopieren Sie dessen Wert. Er wird nur einmal angezeigt. + +#### Connector-Zuordnungen + +1. Geben Sie `https://api.yeswehack.com/` in das Feld **Location** ein. +2. Geben Sie Ihr Personal Access Token in das Feld **Secret** ein. +3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. + +DefectDojo erstellt für jedes Programm, auf das Ihr Token zugreifen kann, einen separaten Eintrag und importiert jeden Report als Befund. Der Schweregrad des Befunds wird der CVSS-Bewertung des Reports entnommen (mit Rückgriff auf die Triage-Priorität), und sein Status spiegelt den Workflow-Status des Reports wider — zum Beispiel werden gelöste Reports als behoben importiert, und als ungültig oder außerhalb des Geltungsbereichs markierte Reports werden als inaktiv importiert. diff --git a/docs/content/connectors/toolreference/yeswehack.es.md b/docs/content/connectors/toolreference/yeswehack.es.md new file mode 100644 index 00000000000..a75aca6f61d --- /dev/null +++ b/docs/content/connectors/toolreference/yeswehack.es.md @@ -0,0 +1,22 @@ +--- +title: "YesWeHack" +description: "Cómo configurar el Conector Upstream de YesWeHack para DefectDojo" +weight: 143 +audience: pro +--- +El conector de YesWeHack usa la API REST de YesWeHack para importar informes de sus programas de bug bounty y divulgación de vulnerabilidades. DefectDojo crea un Record para cada programa al que su token pueda acceder e importa sus informes como hallazgos. + +#### Prerrequisitos + +Necesitará un **Personal Access Token (PAT)** de YesWeHack. Es suficiente con acceso de lectura a sus programas. Algunas cuentas requieren TOTP/MFA al crear un token; una vez creado, el conector usa el valor del token en sí. + +1. En YesWeHack, abra la configuración de su cuenta y vaya a **API / Personal Access Tokens**. +2. Cree un token y copie su valor. Solo se muestra una vez. + +#### Asignaciones del conector + +1. Introduzca `https://api.yeswehack.com/` en el campo **Location**. +2. Introduzca su Personal Access Token en el campo **Secret**. +3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importarán. + +DefectDojo crea un Record independiente para cada programa al que su token pueda acceder, e importa cada informe como un hallazgo. La severidad del hallazgo se toma de la calificación CVSS del informe (recurriendo a la prioridad de triaje si no está disponible), y su estado refleja el estado del flujo de trabajo del informe — por ejemplo, los informes resueltos se importan como Mitigado, y los informes marcados como inválidos o fuera de alcance se importan como inactivos. diff --git a/docs/content/connectors/toolreference/yeswehack.fr.md b/docs/content/connectors/toolreference/yeswehack.fr.md new file mode 100644 index 00000000000..d8d05773412 --- /dev/null +++ b/docs/content/connectors/toolreference/yeswehack.fr.md @@ -0,0 +1,22 @@ +--- +title: "YesWeHack" +description: "Comment configurer le Connecteur Upstream YesWeHack pour DefectDojo" +weight: 143 +audience: pro +--- +Le connecteur YesWeHack utilise l'API REST de YesWeHack pour importer les rapports de vos programmes de bug bounty et de divulgation de vulnérabilités. DefectDojo crée un Enregistrement pour chaque programme auquel votre jeton a accès et importe ses rapports comme constatations. + +#### Prérequis + +Vous aurez besoin d'un **jeton d'accès personnel (PAT)** YesWeHack. Un accès en lecture à vos programmes suffit. Certains comptes exigent TOTP/MFA lors de la création d'un jeton ; une fois créé, c'est la valeur du jeton elle-même que le connecteur utilise. + +1. Dans YesWeHack, ouvrez les paramètres de votre compte et allez dans **API / Personal Access Tokens**. +2. Créez un jeton et copiez sa valeur. Elle n'est affichée qu'une seule fois. + +#### Mappages du connecteur + +1. Saisissez `https://api.yeswehack.com/` dans le champ **Location**. +2. Saisissez votre jeton d'accès personnel dans le champ **Secret**. +3. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. Les constatations en dessous de la sévérité sélectionnée ne seront pas importées. + +DefectDojo crée un Enregistrement distinct pour chaque programme auquel votre jeton a accès, et importe chaque rapport comme constatation. La sévérité de la constatation est déterminée par la notation CVSS du rapport (avec repli sur la priorité de triage), et son statut reflète l'état de workflow du rapport — par exemple, les rapports résolus sont importés comme atténués, et les rapports marqués comme invalides ou hors périmètre sont importés comme inactifs. diff --git a/docs/content/connectors/toolreference/yeswehack.ja.md b/docs/content/connectors/toolreference/yeswehack.ja.md new file mode 100644 index 00000000000..5a174a875fb --- /dev/null +++ b/docs/content/connectors/toolreference/yeswehack.ja.md @@ -0,0 +1,22 @@ +--- +title: "YesWeHack" +description: "DefectDojo で YesWeHack の Upstream Connector をセットアップする方法" +weight: 143 +audience: pro +--- +YesWeHack コネクタは、YesWeHack REST API を使用して、バグバウンティおよび脆弱性開示プログラムからレポートをインポートします。DefectDojo は、トークンがアクセスできるプログラムごとに Record を作成し、そのレポートを検出事項としてインポートします。 + +#### Prerequisites + +YesWeHack の **Personal Access Token(PAT)**が必要です。プログラムへの読み取りアクセス権があれば十分です。一部のアカウントではトークン作成時に TOTP/MFA が必要ですが、作成後はトークンの値自体をコネクタが使用します。 + +1. YesWeHack でアカウント設定を開き、**API / Personal Access Tokens** に移動します。 +2. トークンを作成し、その値をコピーします。値は一度しか表示されません。 + +#### Connector Mappings + +1. **Location** フィールドに `https://api.yeswehack.com/` を入力します。 +2. **Secret** フィールドに Personal Access Token を入力します。 +3. 必要に応じて、**Minimum Severity** を設定してインポートする検出事項を絞り込みます。選択した深刻度を下回る検出事項はインポートされません。 + +DefectDojo は、トークンがアクセスできるプログラムごとに個別の Record を作成し、各レポートを検出事項としてインポートします。検出事項の深刻度はレポートの CVSS 評価から取得され(利用できない場合はトリアージの優先度にフォールバックします)、そのステータスはレポートのワークフロー状態を反映します — 例えば、解決済みのレポートは緩和済みとしてインポートされ、無効または対象外とマークされたレポートは非アクティブとしてインポートされます。 diff --git a/docs/content/connectors/toolreference/yeswehack.md b/docs/content/connectors/toolreference/yeswehack.md new file mode 100644 index 00000000000..6146dd41191 --- /dev/null +++ b/docs/content/connectors/toolreference/yeswehack.md @@ -0,0 +1,22 @@ +--- +title: "YesWeHack" +description: "How to set up the YesWeHack Upstream Connector for DefectDojo" +weight: 143 +audience: pro +--- +The YesWeHack connector uses the YesWeHack REST API to import reports from your bug bounty and vulnerability disclosure programs. DefectDojo creates a Record for each program your token can access and imports its reports as findings. + +#### Prerequisites + +You will need a YesWeHack **Personal Access Token (PAT)**. Read access to your programs is sufficient. Some accounts require TOTP/MFA when creating a token; once created, the token value itself is what the connector uses. + +1. In YesWeHack, open your account settings and go to **API / Personal Access Tokens**. +2. Create a token and copy its value. It is only shown once. + +#### Connector Mappings + +1. Enter `https://api.yeswehack.com/` in the **Location** field. +2. Enter your Personal Access Token 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 program your token can access, and imports each report as a finding. The finding's severity is taken from the report's CVSS rating (falling back to the triage priority), and its status reflects the report's workflow state — for example, resolved reports are imported as mitigated, and reports marked invalid or out of scope are imported as inactive. diff --git a/docs/content/connectors/toolreference/zendesk.de.md b/docs/content/connectors/toolreference/zendesk.de.md new file mode 100644 index 00000000000..63fb01240cf --- /dev/null +++ b/docs/content/connectors/toolreference/zendesk.de.md @@ -0,0 +1,45 @@ +--- +title: "Zendesk" +description: "Einrichtung des Zendesk Downstream-Connectors für DefectDojo" +weight: 144 +audience: pro +--- +Die Zendesk-Integration ermöglicht es Ihnen, DefectDojo-Befunde und Befundgruppen als Zendesk-Tickets zu übertragen, die einer Zendesk-Gruppe Ihrer Wahl zugewiesen werden. + +### Instanz-Einrichtung + +- **Label** sollte die Bezeichnung sein, mit der Sie diese Integration identifizieren möchten. +- **Location** sollte auf die URL Ihres Zendesk-Kontos gesetzt werden, zum Beispiel `https://your-subdomain.zendesk.com`. +- **Email** sollte die E-Mail-Adresse des Zendesk-Agenten sein, zu dem das API-Token gehört. +- **API Token** sollte auf ein Zendesk-API-Token gesetzt werden. Ein Administrator kann eines im Zendesk Admin Center unter **Apps and integrations > APIs > Zendesk API** erstellen (der Token-Zugriff muss aktiviert sein). + +### Issue-Tracker-Zuordnung + +- **Group ID** sollte die numerische ID der Zendesk-Gruppe sein, der Tickets zugewiesen werden. Sie finden sie im Admin Center unter **People > Team > Groups** oder in der URL, während Sie die Gruppe ansehen. + +### Details zur Schweregrad-Zuordnung + +Dies wird dem Zendesk-Ticketfeld **Priority** zugeordnet, das `low`, `normal`, `high` und `urgent` akzeptiert: + +- **Name des Schweregrad-Felds**: `Priority` +- **Info-Zuordnung**: `low` +- **Niedrig-Zuordnung**: `low` +- **Mittel-Zuordnung**: `normal` +- **Hoch-Zuordnung**: `high` +- **Kritisch-Zuordnung**: `urgent` + +### Details zur Status-Zuordnung + +Zendesk-Tickets unterstützen die Status `new`, `open`, `pending`, `hold`, `solved` und `closed`. Beachten Sie, dass `hold` in Ihrem Konto aktiviert sein muss, bevor es verwendet werden kann. + +- **Name des Status-Felds**: `Status` +- **Aktiv-Zuordnung**: `new` +- **Geschlossen-Zuordnung**: `solved` +- **Falsch-positiv-Zuordnung**: `solved` +- **Risiko-akzeptiert-Zuordnung**: `pending` + +Einige Zendesk-spezifische Verhaltensweisen, die Sie kennen sollten: + +- Die Ticketbeschreibung ist in Zendesk der erste Kommentar und kann nach dem Erstellen nicht bearbeitet werden; beim Übertragen eines aktualisierten Befunds werden daher Betreff, Priorität und Status des Tickets synchronisiert, Änderungen der Beschreibung jedoch nicht. +- Tickets werden als `solved` markiert und nicht gelöscht, wenn ein Befund entfernt wird; Zendesk schließt gelöste Tickets nach einer bestimmten Zeit automatisch. +- `closed` ist ein endgültiger Status - geschlossene Tickets können überhaupt nicht mehr aktualisiert werden, und das Übertragen eines Befunds, dessen Ticket geschlossen ist, meldet einen Fehler. diff --git a/docs/content/connectors/toolreference/zendesk.es.md b/docs/content/connectors/toolreference/zendesk.es.md new file mode 100644 index 00000000000..d552d644b18 --- /dev/null +++ b/docs/content/connectors/toolreference/zendesk.es.md @@ -0,0 +1,45 @@ +--- +title: "Zendesk" +description: "Cómo configurar el Conector Downstream de Zendesk para DefectDojo" +weight: 144 +audience: pro +--- +La integración con Zendesk le permite enviar los Hallazgos y Grupos de Hallazgos de DefectDojo como tickets de Zendesk, asignados a un Group de Zendesk de su elección. + +### Configuración de la instancia + +- **Label** debe ser la etiqueta que desee usar para identificar esta integración. +- **Location** debe configurarse con la URL de su cuenta de Zendesk, por ejemplo `https://your-subdomain.zendesk.com`. +- **Email** debe ser la dirección de correo del agente de Zendesk al que pertenece el token de API. +- **API Token** debe configurarse con un token de API de Zendesk. Un administrador puede crear uno en el Zendesk Admin Center, en **Apps and integrations > APIs > Zendesk API** (debe habilitarse el acceso por token). + +### Mapeo del sistema de tickets + +- **Group ID** debe ser el ID numérico del Group de Zendesk al que se asignarán los tickets. Puede encontrarlo en el Admin Center, en **People > Team > Groups**, o en la URL al ver el grupo. + +### Detalles del mapeo de severidad + +Esto se corresponde con el campo **Priority** del ticket de Zendesk, que acepta `low`, `normal`, `high` y `urgent`: + +- **Nombre del campo de severidad**: `Priority` +- **Mapeo de Informativa**: `low` +- **Mapeo de Baja**: `low` +- **Mapeo de Media**: `normal` +- **Mapeo de Alta**: `high` +- **Mapeo de Crítica**: `urgent` + +### Detalles del mapeo de estado + +Los tickets de Zendesk admiten los estados `new`, `open`, `pending`, `hold` y `closed`, así como `solved`. Tenga en cuenta que `hold` debe estar habilitado en su cuenta antes de poder usarse. + +- **Nombre del campo de estado**: `Status` +- **Mapeo de Activo**: `new` +- **Mapeo de Cerrado**: `solved` +- **Mapeo de Falso positivo**: `solved` +- **Mapeo de Riesgo aceptado**: `pending` + +Algunos comportamientos específicos de Zendesk que debe tener en cuenta: + +- La descripción del ticket es el primer comentario en Zendesk y no se puede editar después de la creación, por lo que enviar un Hallazgo actualizado sincronizará el asunto, la prioridad y el estado del ticket, pero no los cambios de descripción. +- Los tickets se marcan como `solved` en lugar de eliminarse cuando se elimina un Hallazgo; Zendesk cierra automáticamente los tickets resueltos después de un período de tiempo. +- `closed` es un estado final: los tickets cerrados no se pueden actualizar en absoluto, y enviar un Hallazgo cuyo ticket esté cerrado generará un error. diff --git a/docs/content/connectors/toolreference/zendesk.fr.md b/docs/content/connectors/toolreference/zendesk.fr.md new file mode 100644 index 00000000000..73b1a348dd3 --- /dev/null +++ b/docs/content/connectors/toolreference/zendesk.fr.md @@ -0,0 +1,45 @@ +--- +title: "Zendesk" +description: "Comment configurer le Connecteur Downstream Zendesk pour DefectDojo" +weight: 144 +audience: pro +--- +L'intégration Zendesk vous permet de pousser les Constatations et Groupes de constatations DefectDojo sous forme de tickets Zendesk, affectés à un Group Zendesk de votre choix. + +### Configuration de l'instance + +- **Label** doit être l'étiquette que vous souhaitez utiliser pour identifier cette intégration. +- **Location** doit être définie sur l'URL de votre compte Zendesk, par exemple `https://your-subdomain.zendesk.com`. +- **Email** doit être l'adresse e-mail de l'agent Zendesk auquel appartient le jeton API. +- **API Token** doit être un jeton API Zendesk. Un administrateur peut en créer un dans le Zendesk Admin Center sous **Apps and integrations > APIs > Zendesk API** (l'accès par jeton doit être activé). + +### Correspondance du suivi des tickets + +- **Group ID** doit être l'ID numérique du Group Zendesk auquel les tickets seront affectés. Vous pouvez le trouver dans l'Admin Center sous **People > Team > Groups**, ou dans l'URL en consultant le groupe. + +### Détails de la correspondance des sévérités + +Ceci correspond au champ **Priority** du ticket Zendesk, qui accepte `low`, `normal`, `high` et `urgent` : + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `low` +- **Low Mapping**: `low` +- **Medium Mapping**: `normal` +- **High Mapping**: `high` +- **Critical Mapping**: `urgent` + +### Détails de la correspondance des statuts + +Les tickets Zendesk prennent en charge les statuts `new`, `open`, `pending`, `hold`, `solved` et `closed`. Notez que `hold` doit être activé sur votre compte avant de pouvoir être utilisé. + +- **Status Field Name**: `Status` +- **Active Mapping**: `new` +- **Closed Mapping**: `solved` +- **False Positive Mapping**: `solved` +- **Risk Accepted Mapping**: `pending` + +Quelques comportements spécifiques à Zendesk à connaître : + +- La description du ticket est le premier commentaire dans Zendesk et ne peut pas être modifiée après la création ; l'envoi d'une Constatation mise à jour synchronisera donc l'objet, la priorité et le statut du ticket, mais pas les modifications de la description. +- Les tickets sont marqués `solved` plutôt que supprimés lorsqu'une Constatation est retirée ; Zendesk ferme automatiquement les tickets solved au bout d'un certain temps. +- `closed` est un statut final - les tickets closed ne peuvent plus du tout être mis à jour, et l'envoi d'une Constatation dont le ticket est fermé génèrera une erreur. diff --git a/docs/content/connectors/toolreference/zendesk.ja.md b/docs/content/connectors/toolreference/zendesk.ja.md new file mode 100644 index 00000000000..e41402e3a4f --- /dev/null +++ b/docs/content/connectors/toolreference/zendesk.ja.md @@ -0,0 +1,45 @@ +--- +title: "Zendesk" +description: "DefectDojo で Zendesk のダウンストリームコネクタをセットアップする方法" +weight: 144 +audience: pro +--- +Zendesk 連携を使用すると、DefectDojo の検出事項および検出事項グループを Zendesk のチケットとしてプッシュし、任意の Zendesk Group に割り当てることができます。 + +### インスタンスのセットアップ + +- **Label** には、この連携を識別するために使用したいラベルを設定します。 +- **Location** には、Zendesk アカウントの URL を設定します。例: `https://your-subdomain.zendesk.com`。 +- **Email** には、API トークンの持ち主である Zendesk エージェントのメールアドレスを設定します。 +- **API Token** には、Zendesk の API トークンを設定します。管理者は Zendesk Admin Center の **Apps and integrations > APIs > Zendesk API** でトークンを作成できます(トークンアクセスを有効化しておく必要があります)。 + +### 課題管理マッピング + +- **Group ID** には、チケットの割り当て先となる Zendesk Group の数値 ID を設定します。Admin Center の **People > Team > Groups** で確認するか、グループを表示しているときの URL から確認できます。 + +### 深刻度マッピングの詳細 + +これは Zendesk チケットの **Priority** フィールドにマッピングされます。このフィールドには `low`、`normal`、`high`、`urgent` を指定できます。 + +- **深刻度フィールド名**: `Priority` +- **情報マッピング**: `low` +- **低マッピング**: `low` +- **中マッピング**: `normal` +- **高マッピング**: `high` +- **重大マッピング**: `urgent` + +### ステータスマッピングの詳細 + +Zendesk チケットは、`new`、`open`、`pending`、`hold`、`solved`、`closed` のステータスをサポートしています。`hold` を使用するには、事前にアカウントで有効化しておく必要がある点に注意してください。 + +- **ステータスフィールド名**: `Status` +- **アクティブマッピング**: `new` +- **クローズマッピング**: `solved` +- **誤検知マッピング**: `solved` +- **リスク受容済みマッピング**: `pending` + +Zendesk 固有の動作として、いくつか注意すべき点があります。 + +- Zendesk ではチケットの説明が最初のコメントとして扱われ、作成後は編集できません。そのため、更新された検出事項をプッシュすると、チケットの件名・優先度・ステータスは同期されますが、説明の変更は同期されません。 +- 検出事項が削除されると、チケットは削除されるのではなく `solved` にマークされます。Zendesk は solved になったチケットを一定期間後に自動的にクローズします。 +- `closed` は最終ステータスです。クローズされたチケットはまったく更新できず、チケットがクローズ済みの検出事項をプッシュするとエラーが報告されます。 diff --git a/docs/content/connectors/toolreference/zendesk.md b/docs/content/connectors/toolreference/zendesk.md new file mode 100644 index 00000000000..bb70ad585c3 --- /dev/null +++ b/docs/content/connectors/toolreference/zendesk.md @@ -0,0 +1,45 @@ +--- +title: "Zendesk" +description: "How to set up the Zendesk Downstream Connector for DefectDojo" +weight: 144 +audience: pro +--- +The Zendesk Integration allows you to push DefectDojo Findings and Finding Groups as Zendesk tickets, assigned to a Zendesk Group of your choice. + +### Instance Setup + +- **Label** should be the label that you want to use to identify this integration. +- **Location** should be set to your Zendesk account URL, for example `https://your-subdomain.zendesk.com`. +- **Email** should be the email address of the Zendesk agent the API token belongs to. +- **API Token** should be set to a Zendesk API token. An administrator can create one in the Zendesk Admin Center under **Apps and integrations > APIs > Zendesk API** (token access must be enabled). + +### Issue Tracker Mapping + +- **Group ID** should be the numeric ID of the Zendesk Group that tickets will be assigned to. You can find it in the Admin Center under **People > Team > Groups**, or in the URL while viewing the group. + +### Severity Mapping Details + +This maps to the Zendesk ticket **Priority** field, which accepts `low`, `normal`, `high`, and `urgent`: + +- **Severity Field Name**: `Priority` +- **Info Mapping**: `low` +- **Low Mapping**: `low` +- **Medium Mapping**: `normal` +- **High Mapping**: `high` +- **Critical Mapping**: `urgent` + +### Status Mapping Details + +Zendesk tickets support the statuses `new`, `open`, `pending`, `hold`, `solved`, and `closed`. Note that `hold` must be enabled on your account before it can be used. + +- **Status Field Name**: `Status` +- **Active Mapping**: `new` +- **Closed Mapping**: `solved` +- **False Positive Mapping**: `solved` +- **Risk Accepted Mapping**: `pending` + +A few Zendesk-specific behaviors to be aware of: + +- The ticket description is the first comment in Zendesk and cannot be edited after creation, so pushing an updated Finding will sync the ticket's subject, priority, and status, but not description changes. +- Tickets are marked `solved` rather than deleted when a Finding is removed; Zendesk closes solved tickets automatically after a period of time. +- `closed` is a final status - closed tickets cannot be updated at all, and pushing a Finding whose ticket has closed will report an error. diff --git a/docs/content/connectors/toolreference/zimperium.md b/docs/content/connectors/toolreference/zimperium.md new file mode 100644 index 00000000000..b8a37c231f3 --- /dev/null +++ b/docs/content/connectors/toolreference/zimperium.md @@ -0,0 +1,20 @@ +--- +title: "Zimperium" +description: "How to set up the Zimperium Upstream Connector for DefectDojo" +weight: 145 +audience: pro +--- +The Zimperium connector imports **mobile application security findings** from Zimperium zScan. DefectDojo creates a Record for each zScan **mobile app**. + +#### Prerequisites + +A zScan **client ID and secret**, issued from **zConsole \> Account Management \> Authorizations** (the `ZSCAN_CLIENT_ID` and `ZSCAN_CLIENT_SECRET` values). DefectDojo exchanges them for a bearer token on each Sync; the secret is never logged. + +#### Connector Mappings + +1. Enter your **zConsole** host in the **Location** field. +2. Enter the client ID in the **Client ID** field. +3. Enter the client secret in the **Client Secret** field. +4. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each zScan mobile app becomes a Record, carrying the findings of that app's **latest completed assessment**. diff --git a/docs/content/connectors/toolreference/zora.md b/docs/content/connectors/toolreference/zora.md new file mode 100644 index 00000000000..ea6cc5f2f65 --- /dev/null +++ b/docs/content/connectors/toolreference/zora.md @@ -0,0 +1,22 @@ +--- +title: "Zora" +description: "How to set up the Zora Upstream Connector for DefectDojo" +weight: 146 +audience: pro +--- +The Zora connector imports **Kubernetes cluster findings** from Zora. DefectDojo creates a Record for each **scanned cluster**. + +Zora is a multi\-cluster manager, so DefectDojo reads the Zora resources in your **management cluster** and maps each cluster Zora scans to its own Record. + +#### Prerequisites + +A **kubeconfig** granting read access to the **management cluster** where the Zora Operator writes its results. + +Unlike most connectors, this one does not use an API token — Zora exposes no REST API, and its results live only as Kubernetes resources, so DefectDojo reads them directly from the cluster. + +#### Connector Mappings + +1. Provide the kubeconfig for the management cluster. +2. Optionally, set a **Minimum Severity** to limit which findings are imported. + +Each scanned cluster becomes a Record, carrying the issues and vulnerability reports Zora recorded for it. diff --git a/docs/content/connectors/upstream/about.de.md b/docs/content/connectors/upstream/about.de.md index 20f1c248ff3..5c720c93f50 100644 --- a/docs/content/connectors/upstream/about.de.md +++ b/docs/content/connectors/upstream/about.de.md @@ -100,7 +100,7 @@ Wir unterstützen derzeit Upstream-Connectors für die folgenden Tools, weitere * **Wiz** * **YesWeHack** -Schritt-für-Schritt-Anleitungen zur Einrichtung für jedes Tool finden Sie in der Referenz [Tool-spezifische Connector-Einrichtung](../toolreference/). +Schritt-für-Schritt-Anleitungen zur Einrichtung für jedes Tool finden Sie in der Referenz [Tool-spezifische Connector-Einrichtung](../../toolreference/upstream/). Die meisten Connectors importieren **Befunde**. Einige wenige sind **Asset Connectors**, die stattdessen Ihr **Asset-Inventar** importieren — sie bauen und pflegen Ihre Produkt- (Asset-) und Produkttyp- (Organisations-) Hierarchie, statt Befunde zu importieren: **Azure DevOps**, **Backstage**, **Bitbucket**, **GitHub**, **GitLab**, **Jira Service Management Assets** und **ServiceNow CMDB**. (**runZero** ist in erster Linie ein Asset Connector, kann aber optional auch Schwachstellen als Befunde importieren.) diff --git a/docs/content/connectors/upstream/about.es.md b/docs/content/connectors/upstream/about.es.md index 8e03c9b8576..eaa304660f8 100644 --- a/docs/content/connectors/upstream/about.es.md +++ b/docs/content/connectors/upstream/about.es.md @@ -100,7 +100,7 @@ Actualmente admitimos Conectores ascendentes para las siguientes herramientas, c * **Wiz** * **YesWeHack** -Para obtener instrucciones de configuración paso a paso de cada herramienta, consulte la referencia de [Configuración de conectores específicos por herramienta](../toolreference/). +Para obtener instrucciones de configuración paso a paso de cada herramienta, consulte la referencia de [Configuración de conectores específicos por herramienta](../../toolreference/upstream/). La mayoría de los Conectores importan **hallazgos**. Unos pocos son **Conectores de activos** que en su lugar importan su **inventario de activos** — creando y manteniendo su jerarquía de Producto (Activo) y Tipo de Producto (Organización) en lugar de importar hallazgos: **Azure DevOps**, **Backstage**, **Bitbucket**, **GitHub**, **GitLab**, **Jira Service Management Assets** y **ServiceNow CMDB**. (**runZero** es principalmente un Conector de activos, pero opcionalmente también puede importar vulnerabilidades como hallazgos.) diff --git a/docs/content/connectors/upstream/about.fr.md b/docs/content/connectors/upstream/about.fr.md index 416bcce6775..8ce785d1696 100644 --- a/docs/content/connectors/upstream/about.fr.md +++ b/docs/content/connectors/upstream/about.fr.md @@ -100,7 +100,7 @@ Nous prenons actuellement en charge les Connecteurs en amont pour les outils sui * **Wiz** * **YesWeHack** -Pour des instructions de configuration étape par étape pour chaque outil, consultez la référence [Configuration des connecteurs par outil](../toolreference/). +Pour des instructions de configuration étape par étape pour chaque outil, consultez la référence [Configuration des connecteurs par outil](../../toolreference/upstream/). La plupart des connecteurs importent des **constatations**. Certains sont des **Connecteurs d'actifs** qui importent plutôt votre **inventaire d'actifs** — en construisant et en maintenant votre hiérarchie Produit (Actif) et Type de produit (Organisation) au lieu d'importer des constatations : **Azure DevOps**, **Backstage**, **Bitbucket**, **GitHub**, **GitLab**, **Jira Service Management Assets**, et **ServiceNow CMDB**. (**runZero** est principalement un Connecteur d'actifs, mais peut aussi, en option, importer des vulnérabilités sous forme de constatations.) diff --git a/docs/content/connectors/upstream/about.ja.md b/docs/content/connectors/upstream/about.ja.md index c72b9274c7c..3949b7a60a1 100644 --- a/docs/content/connectors/upstream/about.ja.md +++ b/docs/content/connectors/upstream/about.ja.md @@ -100,7 +100,7 @@ DefectDojo を使用すると、洗練された API 連携を構築でき、脆 * **Wiz** * **YesWeHack** -各ツールのステップバイステップのセットアップ手順については、[ツール別コネクタセットアップ](../toolreference/) のリファレンスを参照してください。 +各ツールのステップバイステップのセットアップ手順については、[ツール別コネクタセットアップ](../../toolreference/upstream/) のリファレンスを参照してください。 ほとんどのコネクタは **検出事項** をインポートします。一部は **Asset Connector** であり、検出事項をインポートする代わりに **アセットインベントリ** をインポートします — 検出事項をインポートするのではなく、製品 (アセット) と製品タイプ (組織) の階層を構築・維持します: **Azure DevOps**、**Backstage**、**Bitbucket**、**GitHub**、**GitLab**、**Jira Service Management Assets**、**ServiceNow CMDB**。(**runZero** は主に Asset Connector ですが、オプションで脆弱性を検出事項としてインポートすることもできます。) diff --git a/docs/content/connectors/upstream/about.md b/docs/content/connectors/upstream/about.md index ed785a51ac8..2e765e91c8d 100644 --- a/docs/content/connectors/upstream/about.md +++ b/docs/content/connectors/upstream/about.md @@ -154,7 +154,7 @@ We currently support Upstream Connectors for the following tools, with more on t * **Zimperium** * **Zora** -For step\-by\-step setup instructions for each tool, see the [Tool\-Specific Connector Setup](../toolreference/) reference. +For step\-by\-step setup instructions for each tool, see the [Tool\-Specific Connector Setup](../../toolreference/upstream/) reference. Most Connectors import **findings**. A few are **Asset Connectors** that import your **asset inventory** instead — building and maintaining your Asset and Organization hierarchy rather than importing findings: **Azure DevOps**, **Backstage**, **Bitbucket**, **GitHub**, **GitLab**, **JSM Assets**, and **ServiceNow CMDB**. (**runZero** is primarily an Asset Connector, but can optionally import vulnerabilities as findings too.) diff --git a/docs/content/connectors/upstream/add_edit.de.md b/docs/content/connectors/upstream/add_edit.de.md index c95109558ae..31cc8dd78d4 100644 --- a/docs/content/connectors/upstream/add_edit.de.md +++ b/docs/content/connectors/upstream/add_edit.de.md @@ -10,7 +10,7 @@ aliases: Das Vorgehen zum Hinzufügen und Konfigurieren eines Upstream-Connectors ist unabhängig vom Tool, das Sie verbinden möchten, ähnlich. Bei bestimmten Tools müssen Sie jedoch möglicherweise API-Schlüssel erstellen oder zusätzliche Schritte durchführen. -Bevor Sie beginnen, empfehlen wir Ihnen, unsere [tool-spezifische Referenz](../toolreference/) zu Rate zu ziehen, um die API-Ressourcen für das Tool zu finden, das Sie verbinden möchten. +Bevor Sie beginnen, empfehlen wir Ihnen, unsere [tool-spezifische Referenz](../../toolreference/upstream/) zu Rate zu ziehen, um die API-Ressourcen für das Tool zu finden, das Sie verbinden möchten. 1. Falls noch nicht geschehen, wechseln Sie zunächst in DefectDojo **zur Pro UI**. 2. Öffnen Sie im Menü auf der linken Seite die Gruppe **Connectors** unter der Überschrift **Import** und klicken Sie auf **Upstream Connectors**. @@ -23,7 +23,7 @@ Sie können auch einen bestehenden Connector unter der Überschrift **Configured ​ ![image](images/add_edit_connectors_2.png) -4. Sie benötigen eine erreichbare **Location URL** für das Tool sowie einen API-**Secret**-Schlüssel. Wo sich der API-Schlüssel befindet, hängt vom jeweiligen Tool ab, das Sie konfigurieren möchten. Weitere Details finden Sie in unserer [tool-spezifischen Referenz](../toolreference/). +4. Sie benötigen eine erreichbare **Location URL** für das Tool sowie einen API-**Secret**-Schlüssel. Wo sich der API-Schlüssel befindet, hängt vom jeweiligen Tool ab, das Sie konfigurieren möchten. Weitere Details finden Sie in unserer [tool-spezifischen Referenz](../../toolreference/upstream/). ​ 5. Vergeben Sie ein **Label** für diese Verbindung, damit Sie sie in DefectDojo leichter identifizieren können. ​ diff --git a/docs/content/connectors/upstream/add_edit.es.md b/docs/content/connectors/upstream/add_edit.es.md index 513fb1c3bcc..d3443af0eec 100644 --- a/docs/content/connectors/upstream/add_edit.es.md +++ b/docs/content/connectors/upstream/add_edit.es.md @@ -10,7 +10,7 @@ aliases: El proceso para agregar y configurar un Conector ascendente es similar, sin importar la herramienta que intente conectar. Sin embargo, algunas herramientas pueden requerir que cree claves de API o complete pasos adicionales. -Antes de comenzar este proceso, le recomendamos consultar nuestra [Referencia específica por herramienta](../toolreference/) para encontrar los recursos de API de la herramienta que intenta conectar. +Antes de comenzar este proceso, le recomendamos consultar nuestra [Referencia específica por herramienta](../../toolreference/upstream/) para encontrar los recursos de API de la herramienta que intenta conectar. 1. Si aún no lo ha hecho, comience **cambiando a la interfaz Pro** en DefectDojo. 2. En el menú del lado izquierdo, abra el grupo **Conectores** anidado bajo el encabezado **Importar**, y haga clic en **Conectores ascendentes**. @@ -23,7 +23,7 @@ También puede editar un Conector existente en el encabezado **Conectores config ​ ![image](images/add_edit_connectors_2.png) -4. Necesitará una **URL de ubicación** accesible para la herramienta, junto con una clave **Secret** de API. La ubicación de la clave de API dependerá de la herramienta que esté intentando configurar. Consulte nuestra [Referencia específica por herramienta](../toolreference/) para más detalles. +4. Necesitará una **URL de ubicación** accesible para la herramienta, junto con una clave **Secret** de API. La ubicación de la clave de API dependerá de la herramienta que esté intentando configurar. Consulte nuestra [Referencia específica por herramienta](../../toolreference/upstream/) para más detalles. ​ 5. Establezca una **Etiqueta** para esta conexión que le ayude a identificarla en DefectDojo. ​ diff --git a/docs/content/connectors/upstream/add_edit.fr.md b/docs/content/connectors/upstream/add_edit.fr.md index 9a0e5a34158..28012b68173 100644 --- a/docs/content/connectors/upstream/add_edit.fr.md +++ b/docs/content/connectors/upstream/add_edit.fr.md @@ -10,7 +10,7 @@ aliases: Le processus d'ajout et de configuration d'un Connecteur en amont est similaire, quel que soit l'outil que vous essayez de connecter. Cependant, certains outils peuvent nécessiter la création de clés API ou des étapes supplémentaires. -Avant de commencer ce processus, nous vous recommandons de consulter notre [Référence spécifique à chaque outil](../toolreference/) pour trouver les ressources API de l'outil que vous essayez de connecter. +Avant de commencer ce processus, nous vous recommandons de consulter notre [Référence spécifique à chaque outil](../../toolreference/upstream/) pour trouver les ressources API de l'outil que vous essayez de connecter. 1. Si ce n'est pas déjà fait, commencez par **passer à la Pro UI** dans DefectDojo. 2. Dans le menu de gauche, ouvrez le groupe **Connecteurs** imbriqué sous l'en-tête **Import**, puis cliquez sur **Connecteurs en amont**. @@ -23,7 +23,7 @@ Vous pouvez également modifier un connecteur existant sous l'en-tête **Connect ​ ![image](images/add_edit_connectors_2.png) -4. Vous aurez besoin d'une **Location URL** accessible pour l'outil, ainsi que d'une clé API **Secret**. L'emplacement de la clé API dépendra de l'outil que vous essayez de configurer. Consultez notre [Référence spécifique à chaque outil](../toolreference/) pour plus de détails. +4. Vous aurez besoin d'une **Location URL** accessible pour l'outil, ainsi que d'une clé API **Secret**. L'emplacement de la clé API dépendra de l'outil que vous essayez de configurer. Consultez notre [Référence spécifique à chaque outil](../../toolreference/upstream/) pour plus de détails. ​ 5. Définissez un **Label** pour cette connexion afin de pouvoir l'identifier facilement dans DefectDojo. diff --git a/docs/content/connectors/upstream/add_edit.ja.md b/docs/content/connectors/upstream/add_edit.ja.md index a8744a0a76b..278ad4f1d00 100644 --- a/docs/content/connectors/upstream/add_edit.ja.md +++ b/docs/content/connectors/upstream/add_edit.ja.md @@ -10,7 +10,7 @@ aliases: アップストリームコネクタの追加と設定のプロセスは、接続しようとしているツールに関わらずほぼ同じです。ただし、ツールによっては API キーの作成や追加の手順が必要になる場合があります。 -この作業を始める前に、接続しようとしているツールの API リソースを確認するため、[ツール別リファレンス](../toolreference/) を確認することをお勧めします。 +この作業を始める前に、接続しようとしているツールの API リソースを確認するため、[ツール別リファレンス](../../toolreference/upstream/) を確認することをお勧めします。 1. まだの場合は、まず DefectDojo で **Pro UI に切り替え** てください。 2. 左側のメニューから、**Import** ヘッダーの下にネストされた **Connectors** グループを開き、**Upstream Connectors** をクリックします。 @@ -23,7 +23,7 @@ aliases: ​ ![image](images/add_edit_connectors_2.png) -4. ツールにアクセス可能な **Location URL** と、API **Secret** キーが必要です。API キーの場所は、設定しようとしているツールによって異なります。詳細は [ツール別リファレンス](../toolreference/) を参照してください。 +4. ツールにアクセス可能な **Location URL** と、API **Secret** キーが必要です。API キーの場所は、設定しようとしているツールによって異なります。詳細は [ツール別リファレンス](../../toolreference/upstream/) を参照してください。 ​ 5. DefectDojo でこの接続を識別しやすいように、**Label** を設定します。 ​ diff --git a/docs/content/connectors/upstream/add_edit.md b/docs/content/connectors/upstream/add_edit.md index 862b5eb41d1..4d7fe040299 100644 --- a/docs/content/connectors/upstream/add_edit.md +++ b/docs/content/connectors/upstream/add_edit.md @@ -9,7 +9,7 @@ aliases: The process for adding and configuring an Upstream Connector is similar, regardless of the tool you’re trying to connect. However, certain tools may require you to create API keys or complete additional steps. -Before you begin this process, we recommend checking our [Tool-Specific Reference](../toolreference/) to find the API resources for the tool you're trying to connect. +Before you begin this process, we recommend checking our [Tool-Specific Reference](../../toolreference/upstream/) to find the API resources for the tool you're trying to connect. 1. If you haven't already, start by **switching to the Pro UI** in DefectDojo. 2. From the left\-side menu, open the **Connectors** group nested under the **Import** header, and click **Upstream Connectors**. @@ -22,7 +22,7 @@ You can also edit an existing Connector under the **Configured Connectors** head ​ ![image](images/add_edit_connectors_2.png) -4. You will need an accessible **Location URL** for the tool, along with an API **Secret** key. The location of the API key will depend on the tool you are trying to configure. See our [Tool\-Specific Reference](../toolreference/) for more details. +4. You will need an accessible **Location URL** for the tool, along with an API **Secret** key. The location of the API key will depend on the tool you are trying to configure. See our [Tool\-Specific Reference](../../toolreference/upstream/) for more details. ​ 5. Set a **Label** for this connection to help you identify it in DefectDojo. ​ diff --git a/docs/content/connectors/upstream/toolreference.de.md b/docs/content/connectors/upstream/toolreference.de.md deleted file mode 100644 index e51f5bdf7f9..00000000000 --- a/docs/content/connectors/upstream/toolreference.de.md +++ /dev/null @@ -1,1501 +0,0 @@ ---- -title: Referenz zu Upstream-Connector-Tools -description: Unsere Liste der unterstützten Connector-Tools und wie Sie sie mit DefectDojo - einrichten -aliases: -- /de/import_data/pro/connectors/connectors_tool_reference/ -- /de/en/connecting_your_tools/connectors/connectors_tool_reference ---- - -Hinweis: Upstream-Connectors sind eine reine DefectDojo-Pro-Funktion. - -Beim Einrichten eines Connectors für ein unterstütztes Tool müssen Sie DefectDojo bestimmte Informationen zur API des Tools mitteilen. Grundsätzlich benötigen Sie: - -* **Location** \-ein Feld, das im Allgemeinen auf die URL Ihres Tools in Ihrem Netzwerk verweist, -* **Secret** \- in der Regel ein API-Schlüssel. - -Manche Tools benötigen über **Location** und **Secret** hinaus weitere API-bezogene Felder. Möglicherweise müssen Sie auch auf der Seite des Tools Änderungen vornehmen, um einen eingehenden Connector von DefectDojo zu ermöglichen. - -![image](images/connectors_tool_reference.png) - -Jedes Tool hat eine andere API-Konfiguration, und dieser Leitfaden soll Ihnen helfen, die API des Tools so einzurichten, dass DefectDojo eine Verbindung herstellen kann. - -Wann immer möglich, empfehlen wir, in Ihrem Sicherheitstool ein neues Konto „DefectDojo Bot" anzulegen, das ausschließlich vom Connector verwendet wird. So können Sie besser zwischen manuell von Ihrem Team ausgeführten Aktionen und automatisierten Aktionen des Connectors unterscheiden. - -# **Asset-Connectors** - -Die meisten Connectors importieren **Befunde** aus einem Sicherheitstool. **Asset-Connectors** funktionieren anders: Sie importieren stattdessen Ihr **Asset-Inventar**. Ein Asset-Connector zählt die Assets auf, die in einer externen Plattform vorhanden sind (zum Beispiel die Repositories in einer GitLab-Gruppe), und erstellt und pflegt automatisch die entsprechenden **Produkte** (Assets) und **Produkttypen** (Organisationen) in DefectDojo. Ein Asset-Connector importiert keine Befunde. - -* **Discover** und **Sync** gleichen beide die Asset-Liste ab. Neue Assets erscheinen als `NEW`-Einträge; sobald sie zugeordnet sind (automatisch, wenn Auto-Mapping aktiviert ist), erstellt DefectDojo das Produkt und ordnet es einem vom Tool abgeleiteten Produkttyp zu — zum Beispiel dem GitLab-Namespace oder dem Azure-DevOps-Projekt. -* Wird ein Asset später upstream entfernt (zum Beispiel ein gelöschtes Repository), wird sein zugeordneter Eintrag beim nächsten Sync als `MISSING` markiert, damit Ihr Team ihn prüfen kann. DefectDojo löscht niemals stillschweigend ein Produkt. - -Azure DevOps, Backstage, Bitbucket, GitHub, GitLab, Jira Service Management Assets und ServiceNow CMDB sind Asset-Connectors. runZero ist in erster Linie ein Asset-Connector, kann aber optional auch Schwachstellen als Befunde importieren. Alle anderen unten aufgeführten Connectors importieren Befunde. - -# **Unterstützte Connectors** - -## **Acunetix 360** - -Der Acunetix-360-Connector importiert **DAST-Schwachstellenbefunde** von der Acunetix-360-Cloud-Plattform (der Invicti-Plattform). DefectDojo ermittelt die gescannten Websites Ihres Kontos und erstellt für jede **Website** einen Eintrag; die Befunde einer Website stammen aus deren letztem abgeschlossenen Scan. - -**Bitte beachten Sie:** Dieser Connector ist für **Acunetix 360** (das Cloud-Produkt unter `online.acunetix360.com`). Er ist nicht für den On-Premises-Scanner Acunetix Standard/Premium gedacht, der über eine andere API verfügt. - -#### Voraussetzungen - -Ein Acunetix-360-Konto und eine **API-Anmeldeinformation**: Öffnen Sie in Acunetix 360 Ihr Kontomenü \> **API Settings**, und notieren Sie sich die **API User ID** und generieren Sie ein **API Token**. Der Connector authentifiziert sich damit als HTTP-Basic-Anmeldedaten, daher wird ein dediziertes Service-Konto empfohlen, um automatisierte Aktivitäten von manuellen Team-Aktionen zu unterscheiden. - -#### Connector-Zuordnungen - -1. Geben Sie Ihre Acunetix-360-URL in das Feld **Location** ein: `https://online.acunetix360.com`. -2. Geben Sie die API User ID in das Feld **API User ID** ein. -3. Geben Sie das API Token in das Feld **API Token** ein. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jede gescannte Website wird zu einem Eintrag. Die Befunde stammen aus dem letzten abgeschlossenen Scan der Website; Schwachstellen, die Acunetix 360 als **Accepted Risk** oder **False Positive** markiert hat, werden weiterhin importiert, aber als inaktiv gekennzeichnet (risikoakzeptiert oder falsch-positiv), damit das DefectDojo-Produkt die Triage des Herstellers widerspiegelt. - -## **Akamai API Security** - -Der Akamai-API-Security-Connector verwendet einen API-Schlüssel, um Sicherheitsbefunde von der Akamai-API abzurufen. DefectDojo ermittelt Ihre Akamai-Umgebung und erstellt separate Einträge für jede in Ihrem Konto konfigurierte **Application** und jeden **Host**. - -#### Voraussetzungen - -Sie benötigen einen API-Schlüssel mit Zugriff auf die Akamai-API. Wir empfehlen, für DefectDojo ein dediziertes Service-Konto anzulegen, um automatisierte Aktivitäten klar von manuellen Team-Aktionen zu unterscheiden. - -#### Connector-Zuordnungen - -1. Geben Sie die Basis-URL Ihrer Akamai-API in das Feld **Location** ein. Diese URL ist spezifisch für Ihre Akamai-Instanz, zum Beispiel -2. Geben Sie einen gültigen **API Key** in das Feld **Secret** ein. - -DefectDojo ordnet **Applications** und **Hosts** als separate Einträge zu. Jede Application erscheint als `{name} (application)` und jeder Host als `{name} (host)` in Ihrer Eintragsliste. - -## **Anchore** - -Der Anchore-Connector verwendet das API-Token eines Benutzers, um Daten von Anchore Enterprise abzurufen. Produkte werden anhand von „Applications" zugeordnet und ermittelt, die sich in Anchore aus mehreren Images zusammensetzen - siehe [Anchore Enterprise Documentation](https://docs.anchore.com/current/docs/sbom_management/application_groups/application_management_anchorectl/) für weitere Informationen. - -#### Connector-Zuordnungen - -1. Die Anchore-URL in das Feld **Location**: Dies ist die URL, unter der Sie auf Anchore zugreifen. -2. Geben Sie einen gültigen API-Schlüssel in das Feld Secret ein. Dies ist der API-Schlüssel, der mit Ihrem Burp-Service-Konto verknüpft ist. - -Weitere Informationen zum Erstellen eines Tokens für Anchore finden Sie in der offiziellen [Anchore-Dokumentation](https://docs.anchore.com/current/docs/). - -## **AWS Security Hub** - -Der AWS-Security-Hub-Connector verwendet einen AWS-Zugriffsschlüssel, um mit den Security-Hub-APIs zu interagieren. - -#### Voraussetzungen - -Anstatt den AWS-Zugriffsschlüssel eines Teammitglieds zu verwenden, empfehlen wir, in Ihrem AWS-Konto speziell für DefectDojo einen IAM-Benutzer anzulegen, dessen Berechtigungen auf das für die Interaktion mit Security Hub Notwendige beschränkt sind. - -Die AWS-Richtlinie „**[AWSSecurityHubReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubReadOnlyAccess.html)**" bietet die für einen Connector erforderliche Zugriffsebene. Wenn Sie eine benutzerdefinierte Richtlinie für einen Connector schreiben möchten, müssen Sie die folgenden Berechtigungen einbeziehen: - -* [DescribeHub](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_DescribeHub.html) -* [GetFindingAggregator](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingAggregator.html) -* [GetFindings](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindings.html) -* [ListFindingAggregators](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_ListFindingAggregators.html) - -Eine funktionierende Richtliniendefinition könnte wie folgt aussehen: - -``` -{ - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "AWSSecurityHubConnectorPerms", - "Effect": "Allow", - "Action": [ - "securityhub:DescribeHub", - "securityhub:GetFindingAggregator", - "securityhub:GetFindings", - "securityhub:ListFindingAggregators" - ], - "Resource": "*" - } - ] -} -``` - -**Bitte beachten Sie:** Wir benötigen möglicherweise in Zukunft zusätzliche API-Aktionen, um die bestmögliche Erfahrung zu bieten, was Aktualisierungen dieser Richtlinie erfordern wird. - -Sobald Sie Ihren IAM-Benutzer erstellt und ihm mit einer geeigneten Richtlinie/Rolle die notwendigen Berechtigungen zugewiesen haben, müssen Sie einen Zugriffsschlüssel generieren, den Sie dann zum Erstellen eines Connectors verwenden können. - -#### Connector-Zuordnungen - -1. Geben Sie den passenden [AWS-API-Endpunkt für Ihre Region](https://docs.aws.amazon.com/general/latest/gr/sechub.html#sechub_region) in das Feld **Location** ein**:** Um beispielsweise Ergebnisse aus der Region `us-east-1` abzurufen, würden Sie Folgendes angeben - -`https://securityhub.us-east-1.amazonaws.com` -2. Geben Sie einen gültigen **AWS Access Key** in das Feld **Access Key** ein. -3. Geben Sie den passenden **Secret Key** in das Feld **Secret Key** ein. - -DefectDojo kann mithilfe der Funktion **regionsübergreifende Aggregation** von Security Hub Befunde aus mehr als einer Region abrufen. Wenn die [regionsübergreifende Aggregation](https://docs.aws.amazon.com/securityhub/latest/userguide/finding-aggregation.html) aktiviert ist, sollten Sie den API-Endpunkt Ihrer „**Aggregation Region**" angeben. Für zusätzlich verknüpfte Regionen werden in DefectDojo anhand Ihrer AWS-Konto-ID und des Regionsnamens ProductRecords erstellt. - -## **Azure DevOps** - -Der Azure-DevOps-Connector ist ein **Asset-Connector**: Er zählt die Git-Repositories in jedem Projekt Ihrer Azure-DevOps-Organisation auf und erstellt für jedes Repository ein DefectDojo-Asset, gruppiert in Organisationen nach Azure-DevOps-Projekt. Es werden keine Befunde importiert. - -#### Voraussetzungen - -Sie benötigen ein Personal Access Token (PAT) für die Organisation. Wir empfehlen, das Token von einem dedizierten Service-Konto aus zu erstellen. Es werden nur Lese-Scopes benötigt: - -1. Öffnen Sie in Azure DevOps **User settings \> Personal access tokens \> New Token**. -2. Klicken Sie auf **Show all scopes** und wählen Sie dann **Code: Read** und **Project and Team: Read**. - -Nur Azure DevOps Services (dev.azure.com) wird unterstützt; der On-Premise Azure DevOps Server wird derzeit nicht unterstützt. - -#### Connector-Zuordnungen - -1. Geben Sie Ihre Organisations-URL in das Feld **Location** ein: `https://dev.azure.com/{your-organization}`. Auch die alten `https://{your-organization}.visualstudio.com`-URLs werden akzeptiert, und zusätzliche Pfadsegmente (zum Beispiel ein Link zu einem bestimmten Projekt) werden ignoriert. -2. Geben Sie das PAT in das Feld **Secret** ein. - -Jedes Repository wird zu einem nach dem Repository benannten Eintrag, gruppiert nach seinem Azure-DevOps-**Projekt**. Deaktivierte Repositories werden übersprungen; das Deaktivieren oder Löschen eines Repositorys markiert seinen Eintrag beim nächsten Sync daher als `MISSING`. - -## **Backstage** - -Der Backstage-Connector ist ein **Asset-Connector**: Anstatt Befunde zu importieren, überträgt er Ihren [Backstage](https://backstage.io)-Software-Katalog in DefectDojo und hält Ihre Produkthierarchie und Team-Zuständigkeit damit synchron. Er ist für Organisationen konzipiert, die ihr Service-Inventar und ihre Organisationsstruktur in Backstage pflegen und möchten, dass DefectDojo diese Struktur widerspiegelt, statt sie manuell zu pflegen. - -#### Was zugeordnet wird - -| Backstage | DefectDojo | -|---|---| -| **System** | Produkttyp (Components ohne System werden unter einem konfigurierbaren Produkttyp „Backstage / Uncategorized" gruppiert) | -| **Component** | Produkt — benannt nach dem `title` der Entität (Rückgriff auf `name`), mit der Katalogbeschreibung | -| **Owning Group** (`ownedBy`-Beziehung) | Eine mit dem Produkt verknüpfte DefectDojo-Gruppe (Standardrolle: Maintainer, konfigurierbar) | -| **Owner email** (E-Mail des Gruppenprofils oder E-Mail eines User-Owners) | Ein Produktmitglied, sofern bereits ein DefectDojo-Benutzer mit dieser E-Mail-Adresse existiert (es werden nie Benutzer angelegt) | -| `metadata.tags`, `spec.type`, `spec.lifecycle`, Namespace, Domain | Produkt-Tags mit dem Präfix `backstage:` | -| `metadata.annotations` | Wird am Eintrag gespeichert (begrenzt); ausgewählte Annotationen können über **Annotation Mappings** zu vollwertigen Attributen oder Tags hochgestuft werden | - -Einträge werden über die vom Server vergebene `metadata.uid` der Entität identifiziert, sodass Umbenennungen in Backstage das zugeordnete Produkt beim nächsten Sync **an Ort und Stelle** aktualisieren — keine Duplikate. Der Produktname folgt stets dem Katalog: Um ein von diesem Connector verwaltetes Produkt umzubenennen, benennen Sie die Component in Backstage um (eine Umbenennung auf DefectDojo-Seite oder ein bei der manuellen Zuordnung vergebener eigener Name wird beim nächsten Sync auf den Katalognamen zurückgesetzt, sofern dies nicht mit einem anderen Produkt kollidieren würde). Eigentümerwechsel verschieben die Gruppenzuordnung des Produkts. Components, die aus dem Katalog verschwinden (oder mit der Annotation `backstage.io/orphan` gekennzeichnet sind), werden als **MISSING** markiert — DefectDojo löscht nie von sich aus ein Produkt. Domain- und Group-Hierarchie (übergeordnete Teams) werden nur als Tags/Metadaten erfasst; sie erzeugen keine zusätzlichen Hierarchieebenen. - -#### Voraussetzungen - -Der Connector authentifiziert sich mit einem **statischen externen Zugriffstoken** gegenüber dem Backstage-Backend. Definieren Sie in Ihrer Backstage-App-Konfiguration ein Token und beschränken Sie es (empfohlen) auf das Catalog-Plugin: - -```yaml -backend: - auth: - externalAccess: - - type: static - options: - token: ${DEFECTDOJO_BACKSTAGE_TOKEN} - subject: defectdojo-connector - accessRestrictions: - - plugin: catalog -``` - -Generieren Sie ein starkes Zufallstoken (zum Beispiel mit `openssl rand -hex 32`) und speichern Sie es in der Umgebung Ihrer Backstage-Bereitstellung. Einzelheiten finden Sie in der [Backstage-Dokumentation zur Service-to-Service-Authentifizierung](https://backstage.io/docs/auth/service-to-service-auth). - -#### Connector-Zuordnungen - -1. Geben Sie Ihre **Backstage-Backend-Root-URL** in das Feld **Location** ein: zum Beispiel `https://backstage.example.com` (der Connector hängt `/api/catalog` an). Dies muss die **Backend**-URL sein, nicht die Frontend-Web-UI. -2. Geben Sie das statische externe Zugriffstoken in das Feld **Secret** ein. - -Optionale Felder (für die Standardwerte leer lassen): - -* **Namespaces** — kommagetrennte Katalog-Namespaces, die importiert werden sollen; bei leerem Feld werden alle Namespaces importiert. -* **Component Types** — kommagetrennte `spec.type`-Werte (z. B. `service,website`); bei leerem Feld werden alle Typen importiert. -* **Page Size** — Seitengröße der Katalogabfrage (1\-500, Standard 250). -* **TLS Verification** — nur auf `false` setzen, wenn Backstage ein Zertifikat verwendet, das DefectDojo nicht verifizieren kann (interne CA); nicht empfohlen. -* **Uncategorized Product Type** — der Produkttyp für Components ohne System (Standard `Backstage / Uncategorized`). -* **Owner Group Role** — die Rolle, die dem verantwortlichen Team bei zugeordneten Produkten gewährt wird (Standard `Maintainer`). -* **Annotation Mappings** — ein JSON-Objekt, das Annotationsschlüssel auf Namen von Eintragsattributen abbildet, oder auf `"tag"`, um eine Annotation als Produkt-Tag zu importieren, z. B. `{"github.com/project-slug": "GITHUB_PROJECT", "example.com/tier": "tag"}`. - -Bei aktiviertem **Auto\-Map** baut ein einziger Discover \+ Sync die vollständige Struktur aus Produkttyp/Produkt/Eigentümerschaft ohne manuelle Schritte auf. Bei deaktiviertem Auto\-Map erscheinen ermittelte Components als Einträge, die auf Ihre Zuordnungsentscheidung warten. - -#### Einschränkungen (v1) - -* Die **Group-Mitgliedschaft von Backstage wird nicht synchronisiert**: Der Connector erstellt/verknüpft das verantwortliche Team als DefectDojo-Gruppe, aber das Befüllen dieser Gruppe mit Benutzern bleibt Ihrem Identity-Provider oder Ihren Administratoren überlassen. -* Nur Components werden zu Produkten; APIs, Resources und Domains werden nicht als Assets importiert (Domains erscheinen als Tags). -* Tags und Annotationen werden normalisiert und begrenzt, um in die DefectDojo-Feldgrenzen zu passen (überlange Werte werden gekürzt). - -**Ein Hinweis zur umgekehrten Richtung:** Die Anzeige von DefectDojo-Befunden und -Bewertungen *innerhalb* von Backstage (auf Entitätsseiten) wäre ein naheliegender nächster Schritt, der als Backstage-Frontend-Plugin umgesetzt würde, das die DefectDojo-REST-API konsumiert — dies liegt bewusst außerhalb des Umfangs dieses Connectors, der ausschließlich Katalogdaten in DefectDojo überträgt. - -## **Black Duck** - -Der Black-Duck-Connector importiert **Software-Composition-Analysis(SCA)**-Befunde von einer Black-Duck(Synopsys/Black-Duck)-Hub-Instanz. DefectDojo ermittelt jedes Projekt in der Instanz und erstellt für jedes **Projekt** einen Eintrag; die Befunde eines Projekts stammen aus den anfälligen BOM-Komponenten der ausgewählten Version. - -#### Voraussetzungen - -Ein Black-Duck-**API-Token** für einen Benutzer, der die zu importierenden Projekte sehen kann. Öffnen Sie in Black Duck Ihr Benutzermenü \> **My Access Tokens** \> **Create New Token**, gewähren Sie (mindestens) Lesezugriff, und kopieren Sie das Token, wenn es angezeigt wird — es wird nur einmal angezeigt. Der Connector tauscht dieses Token bei jedem Sync gegen ein kurzlebiges Bearer-Token ein; es wird über das Secret-Feld des Connectors hinaus nie im Klartext gespeichert. - -#### Connector-Zuordnungen - -1. Geben Sie Ihre Black-Duck-Hub-URL in das Feld **Location** ein — zum Beispiel `https://your-company.app.blackduck.com`. -2. Geben Sie das API-Token in das Feld **Secret** ein. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jedes Black-Duck-Projekt wird zu einem Eintrag. Standardmäßig importiert der Connector die **released**-Version des Projekts (mit Rückgriff auf dessen erste Version); jede anfällige BOM-Komponente dieser Version wird zu einem Befund mit dem Titel `{vulnerability} in {component}:{version}`. - -Dieser Connector unterscheidet sich von den dateibasierten Black-Duck-Parsern — seine Befunde verwenden den dedizierten Scan-Typ **Black Duck - Connectors Import**. - -## **Bitbucket** - -Der Bitbucket-Connector ist ein **Asset-Connector**: Er zählt die Repositories in den von Ihnen benannten Bitbucket-Cloud-Workspaces auf und erstellt für jedes Repository ein DefectDojo-Asset, gruppiert in Organisationen nach Bitbucket-Projekt. Es werden keine Befunde importiert. - -#### Voraussetzungen - -Bitbucket Cloud erfordert ein **scoped** Atlassian-API-Token — klassische (nicht-scoped) Atlassian-API-Tokens werden von Bitbucket mit dem Fehler „API Token provided has no Bitbucket scopes" abgelehnt. - -1. Gehen Sie zu [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens) und wählen Sie **Create API token with scopes**. -2. Wählen Sie die **Bitbucket**-App und gewähren Sie dann die Lese-Scopes: `read:account:bitbucket`, `read:workspace:bitbucket`, `read:repository:bitbucket` und `read:project:bitbucket`. - -Nur Bitbucket Cloud (bitbucket.org) wird unterstützt. Bitbucket Server hat 2024 das Ende seiner Lebensdauer erreicht, und Bitbucket Data Center wird nicht unterstützt. - -#### Connector-Zuordnungen - -1. Geben Sie `https://bitbucket.org` in das Feld **Location** ein. -2. Geben Sie die Atlassian-Konto-E-Mail-Adresse, zu der das Token gehört, in das Feld **Email** ein. -3. Geben Sie das scoped API-Token in das Feld **Secret** ein. -4. Geben Sie einen oder mehrere Workspace-Slugs (kommagetrennt) in das Feld **Workspace Slugs** ein. Dieses Feld ist erforderlich: Die scoped API-Tokens von Bitbucket können Workspaces nicht automatisch auflisten, daher muss DefectDojo mitgeteilt werden, welche Workspaces gelesen werden sollen. - -Jedes Repository wird zu einem nach dem Repository benannten Eintrag, gruppiert nach seinem Bitbucket-**Projekt**. - -## **Bugcrowd** - -Der Bugcrowd-Connector verwendet die Bugcrowd-REST-API, um Einreichungen aus Ihren Bug-Bounty- und Vulnerability-Disclosure-Programmen zu importieren. DefectDojo ermittelt die Programme, auf die Ihr API-Token zugreifen kann, und erstellt für jedes einen Eintrag, wobei die Einreichungen des Programms als Befunde importiert werden. - -#### Voraussetzungen - -Sie benötigen ein Bugcrowd-**API-Token** mit Zugriff auf die zu importierenden Programme. Wir empfehlen, für DefectDojo ein dediziertes Service-Konto anzulegen, damit automatisierte Aktivitäten leicht von manuellen Team-Aktionen zu unterscheiden sind. Generieren Sie das Token in Bugcrowd unter **Organization settings \> API credentials**; Lesezugriff auf Submissions, Programme und Targets ist ausreichend. - -#### Connector-Zuordnungen - -1. Geben Sie `https://api.bugcrowd.com` in das Feld **Location** ein. -2. Geben Sie Ihr Bugcrowd-API-Token in das Feld **Secret** ein. Es wird als `Authorization: Token`-Header gesendet. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jedes Bugcrowd-**Programm** wird zu einem Eintrag, und seine Einreichungen werden mit dem beibehaltenen Bugcrowd-Schweregrad als Befunde importiert. Doppelte Einreichungen werden ausgeschlossen, sodass ein erneuter Import keine wiederholten Befunde für dasselbe Problem erzeugt. - -## **Bright Security** - -Der Bright-Security-Connector verwendet die [Bright](https://brightsec.com)-API (ehemals NeuraLegion), um **DAST-Befunde** zu importieren. DefectDojo ermittelt jeden Scan, auf den das Token zugreifen kann, und erstellt für jeden abgeschlossenen Scan einen Eintrag; anschließend werden die Issues dieses Scans als Befunde importiert. - -#### Voraussetzungen - -Sie benötigen einen Bright-**API-Schlüssel**, der in der Bright-App unter **User settings → API keys** erstellt wird (ein `Org`- oder persönlicher Schlüssel). Der Schlüssel wird im Header `Authorization: Api-Key` gesendet und nie protokolliert. - -#### Connector-Zuordnungen - -1. Lassen Sie das Feld **Location** leer, um `https://app.brightsec.com` zu verwenden, oder geben Sie Ihren Bright-Host explizit an. -2. Geben Sie den Bright-API-Schlüssel in das Feld **Secret** ein. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo ordnet jeden abgeschlossenen **Scan** einem Eintrag zu und jedes **Issue** einem Befund: Der Schweregrad stammt aus Brights eigener Bewertung (Critical/High/Medium/Low), der CVSS-Score, die CWE und die Abhilfemaßnahme werden übernommen, der betroffene Entry Point wird zum Endpunkt, und der Request/Response-Nachweis wird in die Beschreibung aufgenommen. Befunde werden als dynamische Befunde erfasst und anhand der Bright-Issue-ID dedupliziert. - -Weitere Informationen finden Sie in der [Bright-API-Dokumentation](https://docs.brightsec.com/). - -## **BurpSuite** - -Der Burp-Connector von DefectDojo ruft die GraphQL-API von Burp auf, um Daten abzurufen. - -#### Voraussetzungen - -Bevor Sie diesen Connector einrichten können, benötigen Sie einen API-Schlüssel eines Burp-Service-Kontos. Burp-Benutzerkonten verfügen standardmäßig nicht über API-Schlüssel, daher müssen Sie möglicherweise eigens dafür einen neuen Benutzer anlegen. - -Eine Anleitung zum Einrichten eines Service-Account-Benutzers mit einem API-Schlüssel finden Sie in der [Burp-Dokumentation](https://portswigger.net/burp/documentation/enterprise/user-guide/api-documentation/create-api-user). - -#### Connector-Zuordnungen - -1. Geben Sie die Root-URL von Burp in das Feld **Location** ein: Dies ist die URL, unter der Sie auf das Burp-Tool zugreifen. -2. Geben Sie einen gültigen API-Schlüssel in das Feld Secret ein. Dies ist der API-Schlüssel, der mit Ihrem Burp-Service-Konto verknüpft ist. - -Weitere Informationen zur Burp-API finden Sie in der offiziellen [Burp-Dokumentation](https://portswigger.net/burp/extensibility/enterprise/graphql-api/index.html). - -## **Censys** - -Der Censys-Connector liest Host-Assets aus der Censys Platform und importiert die exponierten Dienste jedes Hosts als Befunde. Er verwendet die globale Such-API der Censys Platform, um die Hosts zu ermitteln, auf die Sie ihn beschränken. - -#### Voraussetzungen - -Sie benötigen ein Censys-**Platform**-Konto mit API-Zugriff: - -* Ein **Personal Access Token**, erstellt in der Censys Platform Console unter Personal Access Tokens. -* Ihre **Organization ID**, die auf derselben Einstellungsseite unter „Current Organization" angezeigt wird. Der API-Zugriff auf den Such-Endpunkt erfordert eine Organisation, daher ist mindestens ein Starter-Tier erforderlich. Free-Tier-Tokens haben keine Organization ID und können die Such-API nicht nutzen. - -Pro-Host-CVE- und Risikodaten sind nur in den Censys-Core(Enterprise)-Tiers verfügbar, sodass Befunde in niedrigeren Tiers exponierte Dienste statt Schwachstellen darstellen. - -Weitere Informationen finden Sie in der [Censys-Platform-API-Dokumentation](https://docs.censys.com/reference/get-started). - -#### Connector-Zuordnungen - -1. Geben Sie `https://api.platform.censys.io` in das Feld **Location** ein. -2. Geben Sie Ihr Personal Access Token in das Feld **API Key** ein. -3. Geben Sie Ihre **Organization ID** ein. -4. Geben Sie eine **Search Query** ein, die den Import auf Ihre eigenen Assets beschränkt, zum Beispiel `host.autonomous_system.asn: ` oder `host.ip: 203.0.113.0/24`. -5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo erstellt für jeden Host einen Eintrag und importiert dessen exponierte Dienste als Befunde. - -## **Checkmarx ONE** - -Der Checkmarx-ONE-Connector von DefectDojo ruft die Checkmarx-API auf, um Daten abzurufen. - -#### **Connector-Zuordnungen** - -1. Geben Sie Ihren **Tenant Name** in das Feld **Checkmarx Tenant** ein. Dieser Name sollte auf der Checkmarx-ONE-Anmeldeseite oben rechts sichtbar sein: -" Tenant: \<**Ihr Tenant-Name**\> " -​ -![image](images/connectors_tool_reference_2.png) - -2. Geben Sie einen gültigen API-Schlüssel ein. Möglicherweise müssen Sie einen neuen generieren: siehe [Checkmarx-API-Dokumentation](https://docs.checkmarx.com/en/34965-68618-generating-an-api-key.html#UUID-f3b6481c-47f4-6cd8-9f0d-990896e36cd6_UUID-39ccc262-c7cb-5884-52ed-e1692a635e08) für Einzelheiten. -3. Geben Sie Ihren Tenant-Standort in das Feld **Location** ein. Diese URL ist wie folgt aufgebaut: -​`https://.ast.checkmarx.net/` . Ihre Region finden Sie am Anfang Ihrer Checkmarx-URL, wenn Sie die Checkmarx-App verwenden. **** ist der primäre US-Server (ohne Regionspräfix). - -#### **Branch-Handhabung** - -Standardmäßig importiert jeder Sync die Befunde des **einzigen zuletzt abgeschlossenen Scans** eines Projekts, unabhängig vom Branch. Wenn Ihre CI viele Branches scannt, „gewinnt" bei diesem Sync der Branch, der zuletzt gescannt wurde: Befunde, die nur auf anderen Branches existieren, werden nicht importiert, und der Close-Old-Abgleich des Syncs kann Befunde hin- und herwechselnd öffnen und schließen, je nachdem, welcher Branch gerade der aktuellste Scan ist. - -Zwei optionale Felder steuern dieses Verhalten: - -- **Branch**: fixiert jedes Projekt auf einen Branch-Namen — es werden nur Scans dieses Branches importiert. Dies ist ein einziger globaler Wert für den gesamten Connector und eignet sich daher für Umgebungen, in denen jedes Projekt denselben langlebigen Branch verwendet (z. B. `main`). - - Ein **Platzhalter `*`** wird unterstützt. Ein Branch-Wert, der `*` enthält, wählt über *jeden* passenden Branch statt nur einen aus — zum Beispiel importiert `release/*` jeden Release-Branch, und `*` erfasst jeden Branch. In Kombination mit **Track Scanned Branches** lässt sich damit eine Gruppe von Branches verfolgen, ohne alle einzeln zu verfolgen. - - Wenn ein Platzhalter innerhalb des Scan-Fensters **keinen** Branch trifft, wird dieser Sync **übersprungen**, statt als „der Branch hat keine Befunde" behandelt zu werden — sodass ein Muster, das vorübergehend auf nichts passt, nicht alle Befunde des Assets schließen kann. -- **Track Scanned Branches**: Wenn aktiviert, findet jeder Sync jeden Branch mit einem abgeschlossenen Scan in der jüngsten Scan-Historie des Projekts und importiert **den letzten abgeschlossenen Scan jedes Branches**, einen erneuten Import pro Branch. Die Befunde jedes Branches liegen in einem eigenen Engagement auf dem zugeordneten Asset mit dem Namen „\ \- \", sodass das Schließen veralteter Befunde pro Branch erfolgt: Ein in einen Branch gemergter Fix kann niemals die Befunde eines anderen Branches schließen. Der primäre Branch des Projekts (laut Checkmarx) wird zuerst importiert, sodass erneute Auftritte desselben Befunds auf anderen Branches mit dem Original des primären Branches dedupliziert werden. - -Hinweise zu **Track Scanned Branches**: - -- **Prüfen Sie, welcher Standard für Sie gilt.** Branch-Tracking ist bei **Neuinstallationen standardmäßig aktiviert**. Installationen von vor dieser Änderung behalten ihr bisheriges Verhalten bei, sodass der Schalter dort deaktiviert bleibt, bis ihn jemand einschaltet. -- Wenn beide Felder gesetzt sind, wird nur der fixierte **Branch** verfolgt — auch wenn dieser Branch-Wert ein Platzhaltermuster ist; in diesem Fall wird jeder passende Branch verfolgt. -- Ein Branch, der nicht mehr gescannt wird (gemergt oder gelöscht), erhält keine Updates mehr: Sein Engagement bleibt mit den zuletzt bekannten Befunden sichtbar, die Sie prüfen und gesammelt schließen können. -- Den Schalter später wieder auszuschalten ist unbedenklich: Die Branch-spezifischen Engagements erhalten dann einfach keine Importe mehr, und beim nächsten Sync wird wieder das Standard-Engagement verwendet. -- Connectors gleichen den Zustand nach dem Sync-Zeitplan ab. Branch-Tracking macht jeden Sync über alle Branches hinweg vollständig; es macht die Daten zwischen den Syncs jedoch nicht in Echtzeit verfügbar. - -## **Cloudflare** - -Der Cloudflare-Connector importiert **Security-Center-Insights** — Probleme mit der Sicherheitslage, die Cloudflare zu Ihrem Konto und Ihren Zonen aufzeigt, etwa einen fehlenden DMARC-Eintrag, nicht aktiviertes DNSSEC oder ein Zertifikatsproblem. DefectDojo erstellt für jede Zone (Domain) mit offenen Insights einen Eintrag, plus einen Eintrag auf Kontoebene für Insights, die keiner bestimmten Zone zugeordnet sind. - -#### Voraussetzungen - -Sie benötigen ein Cloudflare-**API-Token** (nicht den veralteten Global API Key). Erstellen Sie eines im Cloudflare-Dashboard unter **My Profile > API Tokens > Create Token**. Die schnellste Option ist die Vorlage **„Read all resources"**; für ein Token mit minimalen Rechten gewähren Sie **Zone > Zone > Read** (alle Zonen) sowie kontoweiten Lesezugriff für Security Center. - -#### Connector-Zuordnungen - -1. Geben Sie `https://api.cloudflare.com/client/v4` in das Feld **Location** ein. -2. Geben Sie das API-Token in das Feld **Secret** ein. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo ermittelt automatisch die Konten und Zonen, auf die das Token zugreifen kann — es ist keine Konto-ID erforderlich. Es werden nur offene (aktive, nicht verworfene) Insights importiert, sodass Insights, die Sie in Cloudflare beheben oder verwerfen, beim nächsten Sync automatisch in DefectDojo als behoben markiert werden. - -## **Cobalt.io** - -Der Cobalt.io-Connector verwendet die Cobalt.io-API (v2), um Pentest-Befunde aus Ihrer Cobalt.io-Organisation abzurufen. DefectDojo ermittelt jede Organisation, auf die Ihr API-Token zugreifen kann, und erstellt für jedes **Asset** (die Einheit, die Cobalt pentestet) einen separaten Eintrag. - -#### Voraussetzungen - -Sie benötigen ein persönliches Cobalt.io-**API-Token**. Wir empfehlen, für DefectDojo ein dediziertes Service-Konto anzulegen, um automatisierte Aktivitäten klar von manuellen Team-Aktionen zu unterscheiden. Generieren Sie ein Token unter **Settings \> API Tokens** in der Cobalt.io-Oberfläche. Organisations-Tokens werden automatisch ermittelt \- Sie müssen sie nicht angeben. - -#### Connector-Zuordnungen - -1. Geben Sie die Basis-URL der Cobalt.io-API in das Feld **Location** ein: `https://api.cobalt.io` (oder Ihren regionalen Host, zum Beispiel `https://api.us.cobalt.io`). -2. Geben Sie Ihr **persönliches API-Token** in das Feld **Secret** ein. -3. Geben Sie optional ein **Organization Token** ein, um den Sync auf eine einzelne Organisation zu beschränken. Bleibt das Feld leer, synchronisiert DefectDojo jede Organisation, auf die das persönliche API-Token zugreifen kann. - -DefectDojo ordnet jedes Cobalt.io-**Asset** als separaten Eintrag zu. Für jedes zugeordnete Asset werden Befunde importiert, wobei deren Cobalt.io-Status (zum Beispiel `valid_fix`, `wont_fix`, `invalid`) den Befundstatus in DefectDojo bestimmt. - -## **Contrast** - -Der Contrast-Connector verwendet die Contrast-Assess-REST-API, um Anwendungsschwachstellen zu importieren. DefectDojo ermittelt die Anwendungen in Ihrer Contrast-Organisation und erstellt für jede einen Eintrag. - -#### Voraussetzungen - -Sie benötigen vier Werte von Contrast. Wir empfehlen, ein dediziertes Service-Konto anzulegen, damit automatisierte Aktivitäten leicht von den manuellen Aktionen Ihres Teams zu unterscheiden sind. In der Contrast-Oberfläche finden Sie unter **User Settings > Profile > Your Keys**: - -* Ihren organisationsweiten **API Key**. -* Ihren persönlichen **Service Key**. -* Den **Benutzernamen**, zu dem die Anmeldedaten gehören (die Login-E-Mail-Adresse des Kontos). -* Ihre **Organization ID** — die UUID der Organisation, aus der importiert werden soll, ebenfalls unter **Organization Settings** angezeigt. - -#### Connector-Zuordnungen - -1. Geben Sie die URL, über die Sie auf Contrast zugreifen, in das Feld **Location** ein — beim gehosteten Produkt ist dies typischerweise `https://app.contrastsecurity.com` (oder Ihre regionale/selbstgehostete Team-Server-URL). -2. Geben Sie die Login-E-Mail-Adresse des Kontos in das Feld **Username** ein. -3. Geben Sie den organisationsweiten **API Key** in das Feld **API Key** ein. -4. Geben Sie den persönlichen **Service Key** in das Feld **Service Key** ein. -5. Geben Sie die **Organization ID** (UUID) in das Feld **Organization ID** ein. -6. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jede Contrast-Anwendung wird zu einem Eintrag, und ihre Schwachstellen werden als Befunde importiert. - -## **Coverity** - -Der Coverity-Connector importiert Befunde von einem **Coverity-Connect**-Server. DefectDojo erstellt für jedes Coverity-**Projekt** einen Eintrag. - -#### Connector-Zuordnungen - -1. Geben Sie die URL Ihres Coverity-Connect-Servers in das Feld **Location** ein. -2. Geben Sie den Coverity-Connect-**Benutzernamen** in das Feld **Username** ein. -3. Geben Sie das Passwort oder den Authentifizierungsschlüssel des Benutzers in das Feld **Secret** ein. -4. Legen Sie optional einen **View Name** fest, um auszuwählen, welche gespeicherte Issue-Ansicht der Connector liest. Leer lassen, um den Standard **Outstanding Issues** zu verwenden. -5. Setzen Sie optional **Import All Issue Kinds** auf `true`, um den Import über den Standardfilter für Security- und Quality-Issues (`RESOURCE_LEAK`) hinaus zu erweitern. - -## **CrowdStrike Falcon** - -Der CrowdStrike-Falcon-Connector importiert **Spotlight-Schwachstellen** und **EDR-Detections** von der Falcon-Plattform als zwei separate Befundtypen (`CrowdStrike:Spotlight` und `CrowdStrike:Detections`). DefectDojo erstellt für jeden Falcon-**Host** einen Eintrag. - -#### Voraussetzungen - -Ein Falcon-**API-Client** (Client ID und Secret), erstellt in der Falcon-Konsole unter **Support \> API Clients and Keys**. Gewähren Sie ihm die Scopes für die zu importierenden Daten: **Hosts: Read** (erforderlich, für die Host-Ermittlung), **Vulnerabilities (Spotlight): Read** (für Spotlight-Befunde) und **Alerts: Read** (für EDR-Detections). Die beiden Befundtypen sind unabhängig voneinander — fehlt dem Client ein Scope, wird dieser Befundtyp übersprungen, statt den Sync scheitern zu lassen; ein Client ohne **Alerts: Read** importiert also weiterhin Spotlight-Schwachstellen. - -#### Connector-Zuordnungen - -1. Geben Sie die Basis-URL der API Ihrer Falcon-Cloud in das Feld **Location** ein, passend zu Ihrer Konsolen-Region — zum Beispiel `https://api.crowdstrike.com` (US\-1), `https://api.us-2.crowdstrike.com` (US\-2), `https://api.eu-1.crowdstrike.com` (EU\-1) oder `https://api.laggar.gcw.crowdstrike.com` (US\-GOV\-1). -2. Geben Sie die Client ID des API-Clients in das Feld **Client ID** ein. -3. Geben Sie das Secret des API-Clients in das Feld **Client Secret** ein. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jeder Falcon-Host wird zu einem Eintrag, benannt nach Hostname, Betriebssystem und Typ. Es werden nur Spotlight-Schwachstellen mit dem Status **open** und **reopened** importiert, sodass ein erneuter Import behobene Befunde schließt. - -## **Deepfence ThreatMapper** - -Der Deepfence-ThreatMapper-Connector verwendet die REST-API der [ThreatMapper](https://github.com/deepfence/ThreatMapper)-Management-Konsole, um **Schwachstellen-Scan**-Ergebnisse zu importieren. DefectDojo ermittelt jeden Node, den ThreatMapper gescannt hat — ein Container-Image, einen Host oder einen Container — und erstellt für jeden einen Eintrag; anschließend wird der letzte abgeschlossene Scan dieses Nodes als Befunde importiert. - -#### Voraussetzungen - -Sie benötigen ein ThreatMapper-**API-Token**, das Sie in der Konsole unter **Settings → User Management** finden (der API-Schlüssel Ihres Benutzers). Der Connector tauscht dieses bei jedem Sync gegen ein kurzlebiges Zugriffstoken ein; das API-Token wird nie protokolliert. - -#### Connector-Zuordnungen - -1. Geben Sie die URL Ihrer ThreatMapper-Konsole in das Feld **Location** ein (zum Beispiel `https://threatmapper.example.com`). -2. Geben Sie im Feld **Secret** das ThreatMapper-API-Token ein. -3. Wenn Ihre Konsole ein selbstsigniertes Zertifikat verwendet, setzen Sie **Skip TLS Verification** auf `true`. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo ordnet jeden gescannten **Node** einem Eintrag zu und jede **CVE** im letzten abgeschlossenen Schwachstellen-Scan einem Befund. Der Schweregrad stammt aus ThreatMappers eigener Bewertung, und das betroffene Paket, der CVSS-Score, die Fix-Version (als Abhilfemaßnahme), Referenzlinks und ein Detailblock werden übernommen. Befunde werden als dynamische Befunde erfasst und anhand von Node, CVE, Paket und Paketpfad dedupliziert. - -Weitere Informationen finden Sie in der [ThreatMapper-Dokumentation](https://community.deepfence.io/threatmapper/docs/v2.5/). - -## Dependency\-Track - -Dieser Connector ruft Daten von einer On-Premise-Dependency\-Track-Instanz über die REST-API ab. - -​**Connector-Zuordnungen** - -1. Geben Sie die URL Ihres lokalen Dependency\-Track-Servers in das Feld **Location** ein. -2. Geben Sie einen gültigen API-Schlüssel in das Feld **Secret** ein. - -So generieren Sie einen Dependency\-Track-API-Schlüssel: - -1. **Access Management**: Navigieren Sie in der Dependency\-Track-Oberfläche zu Administration \> Access Management \> Teams. -2. **Teams Setup**: Sie können entweder ein neues Team erstellen oder ein bestehendes auswählen. Mit Teams können Sie den API-Zugriff anhand der Gruppenmitgliedschaft verwalten. -3. **Generate API Key**: Suchen Sie auf der Detailseite des ausgewählten Teams den Abschnitt „API Keys". Klicken Sie auf die Schaltfläche \+, um einen neuen API-Schlüssel zu generieren. -4. **Assign Permissions**: Klicken Sie im Abschnitt „Permissions" der Team-Seite auf die Schaltfläche \+, um die Berechtigungsauswahl zu öffnen. Wählen Sie die Berechtigungen **VIEW\_PORTFOLIO** und **VIEW\_VULNERABILITY**, um API-Zugriff auf Projekt-Portfolios und Schwachstellendetails zu ermöglichen. -5. Klicken Sie auf „**Select**", um diese Berechtigungen zu bestätigen und zu speichern. - -Weitere Informationen finden Sie in der **[Dependency\-Track-Dokumentation](https://docs.dependencytrack.org/integrations/rest-api/)**. - -## **Docker Scout** - -Der Docker-Scout-Connector verwendet die Docker-Scout-Metrics-Exporter-API, um den Schwachstellenstatus der Images Ihrer Organisation zu melden. DefectDojo ermittelt jeden Docker-Scout-Stream (Ihre Laufzeitumgebungen) und importiert für jeden eine Zusammenfassung der Schwachstellen und der Richtlinien-Compliance. - -#### Voraussetzungen - -Sie benötigen ein persönliches Docker-Zugriffstoken, das von einem **Owner** einer Docker-Organisation erstellt wurde, die **bei Docker Scout registriert** ist. Der Metrics Exporter ist eine Funktion auf Organisationsebene, daher liefert ein persönliches Konto oder eine nicht bei Docker Scout registrierte Organisation keine Daten. - -Erstellen Sie das Token in Ihren Docker-Kontoeinstellungen unter **Personal access tokens**, und notieren Sie sich Ihren Docker-**Organisations-Namespace**, den Sie ebenfalls benötigen. - -#### Connector-Zuordnungen - -1. Geben Sie `https://api.scout.docker.com` in das Feld **Location** ein. -2. Geben Sie Ihr persönliches Docker-Zugriffstoken in das Feld **Secret** ein. -3. Geben Sie Ihren Docker-**Organization**-Namespace ein. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. - -DefectDojo erstellt für jeden Docker-Scout-Stream einen separaten Eintrag und importiert einen Befund pro Schweregrad für die Schwachstellen, die Docker Scout in diesem Stream zählt, sowie einen Befund für jedes Image, das Ihre Docker-Scout-Richtlinie nicht erfüllt. Die Metrics-API von Docker Scout meldet aggregierte Zählwerte statt einzelner CVEs, daher fassen diese Befunde den Status eines Streams zusammen. Öffnen Sie den Stream in Docker Scout für Details pro Image und pro CVE. - -Weitere Informationen finden Sie in der [Docker-Scout-Dokumentation](https://docs.docker.com/scout/). - -## **Endor Labs** - -Der Endor-Labs-Connector verwendet die Endor-Labs-REST-API, um einen gesamten Endor-Labs-**Namespace** zu synchronisieren. DefectDojo ermittelt jedes Endor-**Projekt** als Eintrag und importiert die Befunde dieses Projekts, wobei Endors **Reachability**-Bewertung übernommen wird, damit Sie Schwachstellen priorisieren können, deren betroffener Code tatsächlich erreichbar ist. - -#### Voraussetzungen - -Sie benötigen einen Endor-Labs-**API-Schlüssel** (eine Schlüsselkennung plus deren Secret) und den **Namespace**, den Sie synchronisieren möchten. Erstellen Sie den Schlüssel in der Endor-Labs-Plattform unter **Settings \> Access \> API Keys**; der Schlüssel benötigt Lesezugriff auf die Projekte und Befunde in diesem Namespace. - -Der Connector authentifiziert sich, indem er den API-Schlüssel und das Secret gegen ein kurzlebiges Bearer-Token eintauscht — das Secret wird nur für diesen Austausch verwendet und nie im Klartext gespeichert. - -#### Connector-Zuordnungen - -1. Geben Sie `https://api.endorlabs.com` in das Feld **Location** ein. Wenn Ihr Tenant in einer anderen Region gehostet wird, verwenden Sie stattdessen die API-Basis-URL dieser Region. -2. Geben Sie den zu synchronisierenden Endor-Labs-**Namespace** ein (zum Beispiel `your-org` oder `your-org.team`). -3. Geben Sie die **API-Key**-Kennung ein. -4. Geben Sie das zum Schlüssel gehörende **API Secret** ein. -5. Setzen Sie optional **Traverse Child Namespaces** auf `true`, um auch Befunde aus untergeordneten Namespaces des konfigurierten Namespace zu importieren. -6. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. - -DefectDojo erstellt für jedes Endor-Labs-Projekt im Namespace einen Eintrag und importiert dessen Befunde, wobei Endor-Schweregrade auf DefectDojo-Schweregrade, die CVE/GHSA-Kennungen und den CVSS-Score jeder Schwachstelle sowie Endors Reachability-Tags abgebildet werden. Die Reachability-Bewertung (zum Beispiel *Reachable — vulnerable function is called* oder *Unreachable*) wird als Impact des Befunds sowie als Tag angezeigt. - -Weitere Informationen finden Sie in der **[Endor-Labs-REST-API-Dokumentation](https://docs.endorlabs.com/rest-api/)**. - -## **Edgescan** - -Der Edgescan-Connector verwendet die Edgescan-REST-API, um offene Schwachstellen aus Ihrem gesamten Edgescan-Konto zu importieren. DefectDojo zählt jedes Edgescan-**Asset** auf und erstellt für jedes einen Eintrag; anschließend werden die offenen Schwachstellen dieses Assets als Befunde importiert — es gibt keine Pro-Asset-Konfiguration. - -#### Voraussetzungen - -Sie benötigen ein Edgescan-API-Token. Erstellen Sie eines in Ihrem Edgescan-Konto unter **Account settings \> API tokens**: Geben Sie eine Bezeichnung ein, klicken Sie auf **Create**, und kopieren Sie das generierte Token (es wird nur einmal angezeigt). Wir empfehlen ein dediziertes Konto für den Connector, damit automatisierte Aktivitäten leicht zu unterscheiden sind. - -#### Connector-Zuordnungen - -1. Geben Sie Ihre Edgescan-URL in das Feld **Location** ein — `https://live.edgescan.com` für die Standard-Hosted-Plattform, oder den Host Ihres Tenants, falls abweichend. -2. Geben Sie Ihr Edgescan-API-Token in das Feld **Secret** ein. Es wird als `X-API-TOKEN`-Header gesendet. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jedes Edgescan-Asset wird zu einem Eintrag, und jede offene Schwachstelle dieses Assets wird als Befund importiert. Der Schweregrad wird von Edgescans numerischer Skala (1–5) auf DefectDojos Info–Kritisch abgebildet, und CVE-Referenzen, die CWE sowie ein CVSS-v3-Vektor werden einbezogen, sofern Edgescan sie bereitstellt. - -## **Escape** - -Der Escape-Connector verwendet die [Escape](https://escape.tech)-API, um **API-Sicherheits(DAST)-Befunde** zu importieren. DefectDojo zählt jede Organisation, auf die das Token zugreifen kann, sowie jede Anwendung darin auf, erstellt für jede Anwendung mit einem Scan einen Eintrag und importiert die Issues des letzten Scans dieser Anwendung als Befunde — es gibt keine Pro-Anwendungs-Konfiguration. - -#### Voraussetzungen - -Sie benötigen einen Escape-**API-Schlüssel**, der in der Escape-App unter **Settings → API keys** erstellt wird. Der Schlüssel wird im Header `Authorization: Key` gesendet und nie protokolliert. - -#### Connector-Zuordnungen - -1. Lassen Sie das Feld **Location** leer, um `https://public.escape.tech/v2` zu verwenden, oder geben Sie Ihren Escape-API-Host explizit an. -2. Geben Sie den Escape-API-Schlüssel in das Feld **Secret** ein. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo ordnet jede **Anwendung** einem Eintrag zu und jedes Scan-**Issue** einem Befund: Der Schweregrad stammt aus Escapes Bewertung (Critical/High/Medium/Low), die CWE wird übernommen, die OWASP-Kategorie und die HTTP-Methode werden zu Tags, die betroffene URL wird zum Endpunkt, und die Abhilfehinweise werden einbezogen. Befunde werden als dynamische Befunde erfasst und anhand der Escape-Issue-ID dedupliziert. - -Weitere Informationen finden Sie in der [Escape-API-Dokumentation](https://docs.escape.tech/). - -## **Fairwinds Insights** - -Der Fairwinds-Insights-Connector verwendet die REST-API von [Fairwinds Insights](https://insights.fairwinds.com), um **Kubernetes-Sicherheitsbefunde** aus Ihrer gesamten Organisation zu importieren. DefectDojo zählt jeden aktiven **Cluster** auf und erstellt für jeden einen Eintrag; anschließend werden die Security-**Action Items** dieses Clusters \(von Polaris, Trivy, Kube\-bench, OPA und den anderen Insights-Berichten\) als Befunde importiert — es gibt keine Pro-Cluster-Konfiguration. - -#### Voraussetzungen - -Sie benötigen einen Fairwinds-Insights-**Organisationsnamen** und ein **API-Token**. Erstellen Sie das Token in der Insights-App unter **Organization Settings \> Tokens**; ein `read_only`-Token ist ausreichend. Das Token ist organisationsweit gültig und wird als Bearer-Token gesendet; es wird nie protokolliert. - -#### Connector-Zuordnungen - -1. Lassen Sie das Feld **Location** leer, um `https://insights.fairwinds.com` zu verwenden, oder geben Sie Ihren Insights-Host explizit an. -2. Geben Sie Ihren Insights-**Organization**-Namen ein (den Slug, der in Ihrer Dashboard-URL angezeigt wird). -3. Geben Sie das Insights-API-Token in das Feld **Secret** ein. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo ordnet jeden aktiven **Cluster** einem Eintrag zu und jedes Security-**Action Item** einem Befund: Der Schweregrad stammt aus Fairwinds' numerischer Bewertung \(abgebildet auf DefectDojos Info–Kritisch\), der Fairwinds-Bericht, der das Item erzeugt hat \(`polaris`, `trivy`, `kube-bench`, ...\), wird zu einem Tool-Tag, die betroffene Kubernetes-Ressource und das Container-Image werden einbezogen, und etwaige CVE-Kennungen werden extrahiert. Befunde werden als statische Befunde erfasst und anhand der Fairwinds-Action-Item-ID dedupliziert. - -Weitere Informationen finden Sie in der [Fairwinds-Insights-API-Dokumentation](https://insights.docs.fairwinds.com/technical-details/api/). - -## **Fortify** - -Der Fortify-Connector importiert SAST-/DAST-Ergebnisse von Fortify (OpenText/Micro Focus) und deckt beide Editionen ab, die sich die Plattform teilen: **SSC** (Software Security Center, selbstgehostet) und **Fortify on Demand (FoD)** (SaaS). Er synchronisiert das gesamte Konto: DefectDojo ermittelt jede Anwendung (SSC-Projektversion/FoD-Release) und erstellt für jede einen Eintrag; anschließend werden die Issues dieser Anwendung als Befunde importiert. - -#### Voraussetzungen - -- **SSC**: ein **FortifyToken** — erstellen Sie eines in der SSC-Oberfläche unter **Administration → Token Management** (ein CIToken/UnifiedLoginToken). -- **FoD**: ein **OAuth2-API-Schlüssel** — eine Client ID und ein Client Secret aus **Settings → API** (mit dem Scope `api-tenant`). - -Das Token und das OAuth-Secret werden nie protokolliert. - -#### Connector-Zuordnungen - -1. Geben Sie die Fortify-Basis-URL in das Feld **Location** ein: für SSC Ihren Server-Host (der Connector ergänzt `/ssc/api/v1`); für FoD den API-Host Ihrer Region, z. B. `https://api.ams.fortify.com`. -2. Setzen Sie **Edition** auf `SSC` oder `FoD`. -3. Geben Sie für **FoD** die OAuth-**Client ID** ein; für SSC leer lassen. -4. Geben Sie in **Token / Client Secret** das SSC-FortifyToken oder das FoD-OAuth-Client-Secret ein. -5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo ordnet jede Fortify-**Anwendung** einem Eintrag zu und jedes **Issue** einem Befund: Der Schweregrad stammt aus Fortifys eigener **Friority**-Bewertung (Critical/High/Medium/Low), der Titel kombiniert die Issue-Kategorie mit Datei und Zeile, und Dateipfad, Zeile, Kingdom, Analyzer und Engine-Typ werden übernommen. Issues von statischen Analyse-Engines (SCA) werden als statische Befunde erfasst und WebInspect(DAST)-Issues als dynamische Befunde; unterdrückte, entfernte und verborgene Issues werden übersprungen, als „Not an Issue" geprüfte Issues werden als falsch-positiv markiert, und „Exploitable"/geprüfte Issues werden als verifiziert markiert. - -Weitere Informationen finden Sie in der Dokumentation zu [Fortify SSC](https://www.microfocus.com/documentation/fortify-software-security-center/) und [Fortify on Demand](https://api.ams.fortify.com/swagger/ui). - -## **GitGuardian** - -Der GitGuardian-Connector verwendet die GitGuardian-REST-API, um **Secret-Incidents** zu importieren — von GitGuardian erkannte offengelegte Anmeldedaten in Ihren überwachten Quellen. DefectDojo erstellt für jede überwachte Quelle (Repository oder Perimeter) mit derzeit offenen Incidents einen Eintrag und importiert jeden offenen Incident als Befund. - -Zu Ihrer Sicherheit importiert der Connector nur Incident-**Metadaten** — den Detektor, den Schweregrad, die Gültigkeit, den Status und einen Link zurück zu GitGuardian. Der offengelegte Secret-Wert selbst wird von DefectDojo nie abgerufen oder gespeichert; folgen Sie dem Link in jedem Befund, um die betroffenen Stellen in GitGuardian zu prüfen. - -#### Voraussetzungen - -Sie benötigen einen GitGuardian-API-Schlüssel. Wir empfehlen ein **Service-Account-Token** (statt eines persönlichen Zugriffstokens), damit automatisierte Aktivitäten leicht zu unterscheiden sind. Erstellen Sie es unter **API** im GitGuardian-Dashboard und gewähren Sie diese Lese-Scopes: - -* `incidents:read` -* `sources:read` - -#### Connector-Zuordnungen - -1. Geben Sie Ihre GitGuardian-API-URL in das Feld **Location** ein: `https://api.gitguardian.com` für die SaaS-Plattform, oder die API-URL Ihrer selbstgehosteten Instanz. -2. Geben Sie den API-Schlüssel in das Feld **Secret** ein. - -Es werden nur **offene** Incidents (Status `TRIGGERED` oder `ASSIGNED`) importiert; Incidents, die Sie in GitGuardian beheben oder ignorieren, werden beim nächsten Sync automatisch in DefectDojo als behoben markiert. Ein bestätigt aktives Secret (Gültigkeit *valid*) wird als verifizierter Befund importiert. - -## **GitHub** - -Der GitHub-Connector ist ein **Asset-Connector**: Er zählt die Repositories auf, auf die Ihr Token zugreifen kann, und erstellt für jedes ein DefectDojo-Asset, gruppiert in Organisationen nach GitHub-Owner (Organisation oder Benutzer). Es werden keine Befunde importiert. - -**Bitte beachten Sie:** Dieser Connector importiert nur Ihr Repository-**Inventar**. Um GitHub-Sicherheitswarnungen — Code Scanning, Dependabot und Secret Scanning — als Befunde zu importieren, verwenden Sie den separaten **GitHub-Advanced-Security**-Connector weiter unten. Beide sind unabhängig voneinander und können gemeinsam betrieben werden. - -#### Voraussetzungen - -Der Connector authentifiziert sich mit einem GitHub-**Personal Access Token** und liest nur Repository-**Metadaten** (Name, Beschreibung, URL und Owner) — er greift nicht auf Ihren Code, Ihre Issues oder Sicherheitswarnungen zu. Er importiert jedes Repository, das dem Konto des Tokens gehört, an dem es mitarbeitet oder dessen Organisation es angehört; stellen Sie daher sicher, dass das Konto des Tokens die zu spiegelnden Repositories sehen kann. Wir empfehlen ein dediziertes Service-Konto. - -Das Token benötigt nur lesenden Zugriff auf Repository-Metadaten: - -- Ein *fein-granulares* Token benötigt **Repository permissions → Metadata: Read-only**, gewährt für die zu importierenden Repositories (oder die gesamte Organisation). -- Ein *klassisches* Token benötigt den Scope **`repo`**, um private Repositories einzuschließen (verwenden Sie **`public_repo`**, wenn Sie nur öffentliche benötigen), sowie **`read:org`**, damit organisationseigene Repositories aufgelöst werden. - -Nur GitHub.com (einschließlich GitHub Enterprise Cloud) wird unterstützt. GitHub Enterprise **Server** wird von diesem Connector derzeit nicht unterstützt. - -#### Connector-Zuordnungen - -1. Geben Sie `https://api.github.com` in das Feld **Location** ein. -2. Geben Sie das Personal Access Token in das Feld **Secret** ein. - -Es muss keine Organisations- oder Repository-Liste eingegeben werden — DefectDojo importiert jedes Repository, das das Token sehen kann. Jedes Repository wird zu einem nach dem Repository benannten Eintrag, gruppiert nach seinem GitHub-**Owner** (Organisation oder Benutzer). Wird ein Repository später gelöscht oder verliert das Token den Zugriff darauf, wird sein zugeordneter Eintrag beim nächsten Sync als `MISSING` markiert statt entfernt — DefectDojo löscht niemals stillschweigend ein Produkt. - -## **GitHub Advanced Security** - -Der GitHub-Advanced-Security-Connector importiert **Code-Scanning-**, **Dependabot-** und **Secret-Scanning**-Warnungen von GitHub als drei separate Befundtypen (`GitHub:CodeScanning`, `GitHub:Dependabot` und `GitHub:SecretScanning`). DefectDojo ermittelt jedes nicht archivierte Repository in der konfigurierten Organisation und erstellt für jedes einen Eintrag. - -#### Voraussetzungen - -GitHub-Advanced-Security-Funktionen müssen für die zu importierenden Repositories aktiviert sein. Der Connector authentifiziert sich mit einem GitHub-**Personal Access Token**: - -1. Öffnen Sie in GitHub **Settings \> Developer settings \> Personal access tokens** und erstellen Sie ein Token, das der Zielorganisation gehört (oder Zugriff darauf hat). -2. Gewähren Sie ihm Lesezugriff auf die Sicherheitswarnungen: Ein *fein-granulares* Token benötigt **Read-only**-Zugriff auf **Code scanning alerts**, **Dependabot alerts** und **Secret scanning alerts** der Repositories der Organisation; ein *klassisches* Token benötigt die Scopes **`repo`** und **`security_events`**. -3. Stellen Sie sicher, dass der Owner des Tokens die zu importierenden Repositories sehen kann — der Connector sieht nur Repositories, auf die das Token zugreifen kann. - -#### Connector-Zuordnungen - -1. Geben Sie `https://api.github.com` in das Feld **Location** ein. Verwenden Sie für GitHub Enterprise Server `https:///api/v3`. -2. Geben Sie den Organisations-Login in das Feld **Organization** ein. -3. Geben Sie das Personal Access Token in das Feld **Secret** ein. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jedes nicht archivierte Repository wird zu einem Eintrag, der über die drei Warnungsfamilien nach offenen Warnungen abgefragt wird. Eine Warnungsfamilie, die für ein Repository nicht aktiviert ist, wird übersprungen statt als behoben gemeldet, sodass deaktivierte Funktionen keine falschen Schließungen verursachen. - -## **GitLab** - -Der GitLab-Connector ist ein **Asset-Connector**: Er zählt jedes Projekt (Repository) auf, auf das Ihr Token zugreifen kann, und erstellt für jedes ein DefectDojo-Asset, gruppiert in Organisationen nach GitLab-Namespace (Gruppe oder Benutzer). Es werden keine Befunde importiert. - -#### Voraussetzungen - -Sie benötigen ein Personal Access Token mit dem Scope **read_api**. Wir empfehlen, das Token von einem dedizierten Service-Konto aus zu erstellen; der Connector listet die Projekte auf, in denen dieses Konto Mitglied ist. - -#### Connector-Zuordnungen - -1. Geben Sie Ihre GitLab-URL in das Feld **Location** ein: `https://gitlab.com`, oder die Basis-URL Ihrer selbstgehosteten Instanz. -2. Geben Sie das Personal Access Token in das Feld **Secret** ein. - -Jedes Projekt wird zu einem nach dem Projekt benannten Eintrag, gruppiert nach seinem **Namespace**. Projekte, die in GitLab zur Löschung vorgesehen sind (von einem Benutzer gelöscht, aber noch nicht durch den Hintergrundjob von GitLab endgültig entfernt), werden automatisch ausgeschlossen; das Löschen eines Projekts markiert seinen Eintrag daher beim nächsten Sync als `MISSING`, statt ein umbenanntes Geister-Asset zu hinterlassen. - -## **Google Cloud Security Command Center** - -Der Google-Cloud-SCC-Connector verwendet die Security-Command-Center-v2-REST-API, um aktive Sicherheitsbefunde aus Ihrer Google-Cloud-Organisation, -Ordner oder -Projekt zu importieren. DefectDojo erstellt für jedes Google-Cloud-**Projekt** mit offenen Befunden einen Eintrag. - -#### Voraussetzungen - -Security Command Center muss für Ihre Organisation **aktiviert** sein (das Standard-Tier ist kostenlos). Anschließend benötigen Sie ein Service-Konto, das Befunde auflisten kann, sowie einen JSON-Schlüssel dafür: - -1. Erstellen Sie in Google Cloud ein Service-Konto — ein dediziertes für DefectDojo wird empfohlen. -2. Gewähren Sie ihm die Rolle **Security Center Findings Viewer** (`roles/securitycenter.findingsViewer`) auf der Ebene, aus der Sie importieren möchten (Organisation, Ordner oder Projekt). -3. Erstellen Sie einen **JSON-Schlüssel** für das Service-Konto und laden Sie ihn herunter. - -#### Connector-Zuordnungen - -1. Lassen Sie das Feld **Location** auf dem Standardwert `https://securitycenter.googleapis.com`, sofern Sie keinen nicht standardmäßigen Endpunkt verwenden. -2. Geben Sie im Feld **Parent Resource** den Geltungsbereich für den Import ein: `organizations/{id}`, `folders/{id}` oder `projects/{id}`. -3. Fügen Sie den vollständigen Inhalt der **JSON-Schlüssel**-Datei des Service-Kontos in das Feld **Service Account Key** ein. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Es werden nur `ACTIVE`, nicht stummgeschaltete Befunde importiert, sodass Befunde, die Sie in SCC deaktivieren oder stummschalten, beim nächsten Sync automatisch in DefectDojo als behoben markiert werden. Das betroffene GCP-Projekt jedes Befunds wird zu dessen Eintrag. - -## **Group-IB ASM** - -Der Group-IB-ASM(Attack Surface Management)-Connector verwendet die Group-IB-ASM-REST-API, um externe Angriffsflächen-**Issues** (Befunde) in DefectDojo zu übertragen. DefectDojo ermittelt jedes Group-IB-**Unternehmen/Tenant** als separaten Eintrag und importiert die Issues dieses Unternehmens geplant und inkrementell. Das Asset, auf das sich jedes Issue bezieht (eine Domain, IP oder URL), wird dem resultierenden Befund als **Endpunkt** angehängt. - -#### Voraussetzungen - -Sie benötigen Ihren Group-IB-ASM-Login und einen API-Schlüssel. Wir empfehlen, für DefectDojo ein dediziertes Service-Konto anzulegen, damit automatisierte Aktivitäten von manuellen Team-Aktionen unterschieden werden können. - -So generieren Sie einen API-Schlüssel: - -1. Öffnen Sie Group-IB Attack Surface Management, klicken Sie unten links auf **Help** und wählen Sie **API**. -2. Klicken Sie auf **Generate API Key** (oben rechts, unter Ihrem Benutzernamen). -3. Geben Sie Ihr SSO-Passwort ein und klicken Sie auf **Next**, dann auf **Copy token**. -4. Speichern Sie den Schlüssel in einem Secret Manager und planen Sie eine regelmäßige Rotation ein. - -#### Connector-Zuordnungen - -Group-IB ASM authentifiziert sich mit HTTP Basic Auth, wobei der Benutzername Ihr ASM-Login und das Passwort Ihr API-Schlüssel ist. **Beide Werte sind erforderlich** — der API-Schlüssel allein reicht nicht aus. - -1. Geben Sie `https://asm.group-ib.com` in das Feld **Location** ein. Dies ist für alle Group-IB-ASM-Tenants gleich. -2. Geben Sie Ihren ASM-Login (in der Regel eine E-Mail-Adresse) in das Feld **Username** ein. -3. Geben Sie Ihren API-Schlüssel in das Feld **API Key** (Secret) ein. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. - -DefectDojo ordnet jedes Group-IB-**Unternehmen** als separaten Eintrag zu, wobei die Unternehmens-ID als Kennung verwendet wird. Beim ersten Sync trägt DefectDojo die jüngste Issue-Historie nach; nachfolgende Syncs erfolgen inkrementell und rufen nur seit dem letzten Sync geänderte Issues ab (anhand des jeweils neuesten `lastSeen`-Zeitstempels jedes Issues). - -#### Beschränkung auf ein einzelnes Unternehmen (optional) - -Standardmäßig ermittelt der Connector automatisch die für Ihre API-Anmeldedaten verfügbaren Unternehmen (über den ASM-Endpunkt `clients`) und erstellt einen Eintrag pro Unternehmen. Dies ist die empfohlene Einrichtung und erfordert keine zusätzliche Konfiguration. - -Ist der Endpunkt `clients` für Ihren Tenant nicht verfügbar — zum Beispiel, weil er auf Partner-/MSP-Konten beschränkt ist —, kann der Connector auf ein Unternehmen beschränkt werden, indem dessen **Unternehmens-ID** als toolspezifisches Feld `company_id` in der Connector-Konfiguration angegeben wird. Ist `company_id` gesetzt, verwendet DefectDojo dieses Unternehmen direkt, statt Unternehmen aufzuzählen. Lassen Sie es nicht gesetzt, um die automatische Ermittlung zu verwenden. - -Weitere Informationen finden Sie im Group-IB-ASM-REST-API-Handbuch (im Produkt verfügbar über **Help → API**). - -## **HackerOne** - -Der HackerOne-Connector verwendet die HackerOne-REST-API, um Reports aus Ihrem Bug-Bounty- oder Vulnerability-Disclosure-Programm zu importieren. DefectDojo erstellt für jedes Programm, auf das das Token zugreifen kann, einen Eintrag und importiert dessen Reports als Befunde. - -#### Voraussetzungen - -Der Connector verwendet die **Customer**-API von HackerOne, die ein **Organization-API-Token** erfordert — ein persönliches Token aus Ihren Benutzereinstellungen funktioniert nur gegen die Hacker-API und authentifiziert sich hier nicht. - -1. Gehen Sie in HackerOne zu **Organization Settings > API Tokens**. -2. Erstellen Sie ein Token und notieren Sie sowohl die **Identifier** als auch den **Token**-Wert. Lesezugriff auf das Programm ist ausreichend. - -#### Connector-Zuordnungen - -1. Geben Sie `https://api.hackerone.com` in das Feld **Location** ein. -2. Geben Sie die Token-**Identifier** in das Feld **API Token Identifier** ein. -3. Geben Sie den Token-Wert in das Feld **API Token** ein. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jedes Programm wird zu einem Eintrag, und seine Reports werden mit der beibehaltenen HackerOne-Schweregrad-Bewertung als Befunde importiert. - -## **Harbor** - -Der Harbor-Connector verwendet die Harbor-v2.0-REST-API, um Container-Image-Schwachstellen aus Ihrer gesamten Registry zu importieren. DefectDojo zählt jedes Harbor-**Projekt** auf und erstellt für jedes einen Eintrag; anschließend durchläuft er die Repositories und Artefakte des Projekts und importiert die Schwachstellen aus jedem **gescannten** Artefakt — wobei das Image (Repository + Tag/Digest) als Befundkontext übernommen wird. Es gibt keine Pro-Image-Konfiguration. - -#### Voraussetzungen - -Sie benötigen ein Harbor-Konto (oder ein **Robot-Konto**) mit Pull-/Lesezugriff auf die zu importierenden Projekte. Wir empfehlen ein dediziertes Robot-Konto: Öffnen Sie in Harbor ein Projekt (oder **Administration \> Robot Accounts** für ein System-Robot), erstellen Sie einen Robot mit der Berechtigung **pull** auf Repositories und Artefakte, und kopieren Sie dessen vollständigen Namen und Secret. Robot-Namen beginnen standardmäßig mit `robot$`, das Präfix ist jedoch pro Harbor-Instanz konfigurierbar (manche verwenden `robot_`) — kopieren Sie den Namen exakt so, wie Harbor ihn anzeigt. Ein normaler Benutzername/Passwort funktioniert ebenfalls. - -#### Connector-Zuordnungen - -1. Geben Sie Ihre Harbor-URL in das Feld **Location** ein — zum Beispiel `https://harbor.example.com`. DefectDojo hängt den API-Pfad `/api/v2.0` automatisch an. -2. Geben Sie den Harbor-Benutzernamen oder einen Robot-Kontonamen exakt so, wie Harbor ihn anzeigt (standardmäßig `robot$`), in das Feld **Username** ein. -3. Geben Sie das Passwort oder das Robot-Konto-Secret in das Feld **Secret** ein. Es wird per HTTP-Basic-Authentifizierung gesendet. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jedes Harbor-Projekt wird zu einem Eintrag. Für jedes Artefakt mit einem abgeschlossenen Scan werden dessen Schwachstellen als Befunde importiert; das betroffene Paket/die Version, ein von CVSS abgeleiteter Schweregrad, die CVE, die CWE und eine Abhilfemaßnahme (Fix-Version) werden einbezogen, sofern Harbor sie bereitstellt. Es werden nur gescannte Artefakte importiert — lösen Sie in Harbor einen Scan für noch nicht gescannte Images aus. - -## **Have I Been Pwned** - -Der Have-I-Been-Pwned(HIBP)-Connector verwendet die HIBP-REST-API, um zu melden, welche Konten auf den eigenen Domains Ihrer Organisation in bekannten Datenpannen aufgetaucht sind. DefectDojo ermittelt jede von Ihnen bei HIBP verifizierte Domain und importiert einen Befund pro Datenpanne, die diese Domain betrifft. - -#### Voraussetzungen - -Sie benötigen einen Have-I-Been-Pwned-API-Schlüssel mit Domain-Suche, wofür mindestens ein **Core**-Abonnement erforderlich ist. Sie können einen Schlüssel über Ihr [Have-I-Been-Pwned-Konto](https://haveibeenpwned.com/API/Key) erhalten. - -Sie müssen außerdem **mindestens eine Domain verifizieren**, bevor Datenpannen-Daten verfügbar sind. HIBP ermöglicht die Verifizierung einer Domain per DNS-TXT-Eintrag, Meta-Tag, Datei-Upload oder E-Mail, unter **Domain search** in Ihrem Konto. Solange keine Domain verifiziert ist, ermittelt der Connector keine Domains und importiert keine Befunde. - -#### Connector-Zuordnungen - -1. Geben Sie `https://haveibeenpwned.com` in das Feld **Location** ein. -2. Geben Sie Ihren API-Schlüssel in das Feld **Secret** ein. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. - -DefectDojo erstellt für jede von Ihnen bei HIBP verifizierte Domain einen separaten Eintrag und importiert einen Befund pro Datenpanne, die Konten auf dieser Domain betrifft. Der Schweregrad jedes Befunds spiegelt die Art der durch die Datenpanne offengelegten Daten wider, und seine Beschreibung listet die betroffenen Konten auf Ihrer Domain auf, damit Ihr Team handeln kann. - -Weitere Informationen finden Sie in der [Have-I-Been-Pwned-API-Dokumentation](https://haveibeenpwned.com/API/v3). - -## **HCL AppScan** - -Der HCL-AppScan-Connector verwendet die AppScan-v4-REST-API, um Issues aus **AppScan on Cloud (ASoC)** oder einem selbstgehosteten **AppScan 360°** zu importieren (beide teilen sich die API). Er synchronisiert das gesamte Konto: DefectDojo ermittelt jede Anwendung und erstellt für jede einen Eintrag; anschließend werden die Issues dieser Anwendung (DAST, SAST und IAST) als Befunde importiert. - -#### Voraussetzungen - -Sie benötigen einen AppScan-**API-Schlüssel** — eine Key ID und ein Key Secret, generiert unter Ihren AppScan-Kontoeinstellungen (API Key). Der Connector tauscht diese bei jedem Lauf gegen ein kurzlebiges Session-Token ein; Key ID, Key Secret und Token werden nie protokolliert. - -#### Connector-Zuordnungen - -1. Geben Sie die AppScan-Konsolen-URL in das Feld **Location** ein: Verwenden Sie für ASoC `https://cloud.appscan.com` (oder `https://eu.cloud.appscan.com` für die EU-Region); verwenden Sie für AppScan 360° den Host Ihrer Instanz. -2. Setzen Sie **Provider** auf `ASOC` für AppScan on Cloud oder auf `A360` für ein selbstgehostetes AppScan 360°. -3. Geben Sie die **API Key ID** und das **API Key Secret** ein. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo ordnet jede AppScan-**Anwendung** einem Eintrag (VEP) zu und jedes **Issue** einem Befund: Der Titel ist der Issue-Typ mit angehängter Domain/Entität/Cause-ID/URL/Pfad; der Schweregrad bildet Informational auf Info ab (Low/Medium/High/Critical werden unverändert übernommen); die CWE, eine beschriftete Beschreibung, die Abhilfemaßnahme und der Hinweis sowie der Host/Port-Endpunkt werden übernommen. Issues aus statischer Analyse werden als statische Befunde erfasst und dynamische/interaktive Issues als dynamische Befunde; offene Issues sind aktiv, und behobene/bestandene Issues sind behoben. - -Weitere Informationen finden Sie in der [AppScan-REST-API-Dokumentation](https://help.hcl-software.com/appscan/ASoC/appseccloud_rest_apis.html). - -## **Intigriti** - -Der Intigriti-Connector verwendet die externe Unternehmens-API von Intigriti, um Bug-Bounty-/Pentest-**Submissions** in DefectDojo zu übertragen. Er synchronisiert das gesamte Unternehmenskonto: DefectDojo ermittelt jedes Programm, auf das das Token zugreifen kann, und erstellt für jedes einen Eintrag; anschließend werden die Submissions dieses Programms als Befunde importiert. - -#### Voraussetzungen - -Sie benötigen ein Intigriti-**Company-API-Token**. Generieren Sie im Intigriti-Unternehmensportal unter **Company Settings > API** (Scope `company_external_api`) ein Zugriffstoken mit Lesezugriff auf Ihre Programme und Submissions. Ein dediziertes Token für DefectDojo wird empfohlen. Das Token wird als Bearer-Token gesendet und nie protokolliert. - -#### Connector-Zuordnungen - -1. Geben Sie die Basis-URL der externen Intigriti-Unternehmens-API in das Feld **Location** ein: `https://api.intigriti.com/external/company`. Die URL muss HTTPS verwenden. -2. Geben Sie das Unternehmens-API-Token in das Feld **Secret** ein. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo ordnet jedes Intigriti-**Programm** einem Eintrag zu und jede **Submission** einem Befund, mit dem Submission-Code als Schlüssel. Der Schweregrad des Befunds folgt der Bewertung von Intigriti (Exceptional/Critical → Critical, dann High/Medium/Low, ansonsten Informational), und der Lifecycle-Status der Submission wird auf den Befundstatus abgebildet: offene/in Triage befindliche Submissions sind aktiv, akzeptierte Submissions sind verifiziert, und geschlossene Submissions werden je nach Schließungsgrund zu behoben, einem Duplikat, außerhalb des Geltungsbereichs, falsch-positiv oder risikoakzeptiert. Die Befundbeschreibung übernimmt den Schwachstellentyp des Reports, das betroffene Asset, den Proof of Concept und die Antworten des Forschers. - -Weitere Informationen finden Sie in der [Intigriti-API-Dokumentation](https://kb.intigriti.com/en/articles/6117846-intigriti-api). - -## **Intruder** - -Der Intruder-Connector verwendet die [Intruder-REST-API](https://developers.intruder.io/), um den Status Ihres gesamten Kontos in DefectDojo zu übertragen. Jedes Intruder-**Target** wird als Eintrag (Produkt) ermittelt; jedes **Vorkommen** eines Issues auf einem Target wird zu einem Befund. - -#### Connector-Zuordnungen - -1. Lassen Sie das Feld **Location** auf `https://api.intruder.io/` (dem Standard-Intruder-API-Server). -2. Geben Sie ein Intruder-**API-Zugriffstoken** in das Feld **Secret** ein. - -Generieren Sie ein Zugriffstoken in Intruder unter **My account > API Access Tokens** (Sie benötigen Ihr Kontopasswort, um es zu erstellen, und das Token wird nur einmal angezeigt). Einzelheiten finden Sie in der [Intruder-API-Dokumentation](https://developers.intruder.io/docs/creating-an-access-token). - -Befunde werden pro Vorkommen abgeleitet: Der Schweregrad stammt aus dem Issue-Schweregrad, CVEs und CVSS aus dem Vorkommen, der Standort aus Target/Port, und ein zurückgestelltes (snoozed) Vorkommen wird als inaktiver Befund (falsch-positiv oder risikoakzeptiert) importiert. - -## **IriusRisk** - -Der IriusRisk-Connector verwendet ein API-Token, um Threat-Modeling-Daten aus Ihrer IriusRisk-Instanz abzurufen. - -#### Voraussetzungen - -Sie benötigen ein API-Token aus Ihrem IriusRisk-Konto. Wir empfehlen, für DefectDojo ein dediziertes Service-Konto anzulegen, um automatisierte Aktivitäten klar von manuellen Team-Aktionen zu unterscheiden. - -So generieren Sie ein API-Token in IriusRisk: - -1. Melden Sie sich bei Ihrer IriusRisk-Instanz an. -2. Navigieren Sie zu Ihrem **User Profile** im Menü oben rechts. -3. Wählen Sie **API Token** und generieren Sie ein neues Token. - -Weitere Informationen finden Sie in der [IriusRisk-API-Dokumentation](https://support.iriusrisk.com/hc/en-us/categories/360001148511). - -#### Connector-Zuordnungen - -1. Geben Sie die URL Ihrer IriusRisk-Instanz in das Feld **Location URL** ein. Bei Cloud-gehosteten Instanzen ist dies typischerweise `https://{your-subdomain}.iriusrisk.com`. Verwenden Sie bei On-Premise-Installationen die Basis-URL Ihrer Instanz. -2. Geben Sie Ihr **API Token** in das Feld **Secret** ein. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. - -## **JFrog Xray** - -Der JFrog-Xray-Connector verwendet die JFrog-Xray-REST-API, um Schwachstellendaten aus Ihren Artifactory-Repositories abzurufen. DefectDojo ermittelt alle Repositories in Ihrer JFrog-Instanz und erzeugt über Xray Schwachstellenberichte, wobei Befunde geplant importiert werden. - -#### Voraussetzungen - -Sie benötigen ein API-Token mit Zugriff auf sowohl die Artifactory- als auch die Xray-API. Wir empfehlen, für DefectDojo ein dediziertes Service-Konto anzulegen. Das Konto benötigt: - -* Lesezugriff auf Artifactory-Repositories -* Berechtigung, Xray-Schwachstellenberichte zu erzeugen und anzuzeigen (Berechtigung `Apply on Watches` in Xray oder gleichwertig) - -#### Connector-Zuordnungen - -1. Geben Sie die Basis-URL Ihrer JFrog-Instanz in das Feld **Location** ein. Dies sollte die Root-URL Ihrer JFrog-Instanz sein, zum Beispiel `https://your-instance.jfrog.io`. Geben Sie keinen abschließenden Pfad an — DefectDojo erstellt die passenden API-Pfade automatisch. -2. Geben Sie ein gültiges **Reference Token** in das Feld **Secret** ein. Tokens können unter **User Management \> Access Tokens** in der JFrog-Platform-Oberfläche generiert werden. -Sie müssen ein **Reference Token** generieren und diesen Wert verwenden. - -Erforderliche Token-Scopes für JFrog Xray: - -- **All Services**, da DefectDojo Zugriff sowohl auf den XRay- als auch auf den Artifactory-Dienst benötigt -- Mindestens **Manage Reports + Manage Resources**. - -Standardmäßig ordnet DefectDojo jedes Artifactory-**Repository** als separaten Eintrag zu. Jeder Sync erzeugt über Xray einen vollständigen Schwachstellenbericht pro Repository, sodass die Befundstatus in DefectDojo stets den aktuellen Zustand des Repositorys widerspiegeln. - -#### Repository-Filter (optional) - -Standardmäßig ermittelt der Connector **jedes** Repository in Ihrer JFrog-Instanz. Bei Instanzen mit einer großen Anzahl von Repositories — von denen viele für die Sicherheitsprüfung möglicherweise nicht relevant sind — kann die Ermittlung mit dem optionalen Feld **Repository Filter** unter **Import Filters** im Connector-Formular eingegrenzt werden. - -Der Filter wird während der Ermittlung angewendet, **bevor irgendeine Arbeit pro Repository erfolgt**. Ein Repository außerhalb des Filters verursacht keine Kosten: Für dieses wird kein Xray-Bericht erzeugt, und im Artefakt-Modus werden keine seiner Artefakte der ersten Ebene aufgelistet. Dies macht ihn zur effektivsten Methode, um sowohl die Sync-Zeit als auch die Last zu reduzieren, die DefectDojo auf Ihre JFrog-Instanz legt — mehr als jede später im Sync angewendete Einstellung. Er wird insbesondere in Kombination mit **Artifact-Level Records** bei großen Instanzen empfohlen. - -**Syntax:** eine kommagetrennte Liste von Repository-Schlüsseln. Jeder Eintrag kann `*`-Platzhalter verwenden: - -* Ein Eintrag, der `*` enthält, wird als Muster abgeglichen — `releases-*` erfasst jeden Repository-Schlüssel, der mit `releases-` beginnt, und `*docker-pr-local*` erfasst jeden Schlüssel, der `docker-pr-local` enthält. Ein `*` erfasst eine beliebige Zeichenfolge, auch `/`. -* Ein Eintrag ohne `*` muss einem Repository-Schlüssel **exakt** entsprechen. -* Ein Repository wird ermittelt, wenn es auf **einen beliebigen** Eintrag der Liste passt. Leerzeichen um Kommas werden ignoriert. - -``` -releases-*, snapshots -``` - -Das obige Beispiel ermittelt jedes Repository, dessen Schlüssel mit `releases-` beginnt, sowie das einzelne Repository mit dem exakten Namen `snapshots`. - -Hinweise: - -* Der Filter ist eine **Allow-Liste** — eine Übereinstimmung wählt ein Repository aus. Es gibt keine Ausschluss- oder Negationssyntax, sodass sich „alles außer X" nicht direkt ausdrücken lässt. -* Der Abgleich erfolgt **groß-/kleinschreibungssensitiv**, sowohl bei exakten Einträgen als auch bei Platzhaltern. `*` ist das einzige Platzhalterzeichen; `?` und Zeichenbereiche werden nicht unterstützt. -* **Leer lassen, um jedes Repository zu ermitteln.** Ein Wert, der nur aus Leerzeichen oder Kommas besteht, wird als leer behandelt. -* Ein Filter, der auf nichts passt, ermittelt einfach nichts — es gibt keine Fehlermeldung. Findet ein Sync unerwartet keine Repositories, prüfen Sie im Connector-Log den Eintrag `repository filter scoped discovery`, der meldet, wie viele der insgesamt vorhandenen Repositories getroffen wurden. -* Das Feld kann nach dem Erstellen der Verbindung geändert werden. - -**Den Filter später ändern:** Repositories, die ein neu eingeengter Filter jetzt ausschließt, werden nicht mehr ermittelt, und ihre bestehenden Einträge durchlaufen den normalen Lebenszyklus für Produkte, die das Tool nicht mehr meldet — **zugeordnete** Einträge werden beim nächsten Sync als `MISSING` markiert, und nicht zugeordnete `NEW`-Einträge werden entfernt. Bereits in DefectDojo importierte Befunde werden nicht gelöscht; der Filter steuert nur die Ermittlung. - -#### Artifact-Level Records - -Der Schalter **Artifact-Level Records** ändert die Ermittlung auf eine Ebene unterhalb des Repositorys: Jeder Eintrag der ersten Ebene unter einer Repository-Root (bei Docker-Repositories jedes Image; bei generischen Repositories jede Datei oder jeder Ordner der obersten Ebene) wird zu einem eigenen Eintrag. Jeder Sync erzeugt weiterhin einen einzigen Xray-Bericht pro Repository — DefectDojo ordnet jede Schwachstelle den Artefakten zu, die sie betrifft, sodass sich die Last auf Ihre JFrog-Instanz nicht erhöht. - -> **Prüfen Sie vor Ihrem ersten Sync, in welchem Modus Sie sich befinden.** Artifact-Level Records ist bei **Neuinstallationen standardmäßig aktiviert**. Installationen von vor Einführung dieser Funktion behalten ihr bestehendes Repository-Level-Layout bei, sodass der Schalter dort deaktiviert bleibt, bis ihn jemand einschaltet. In beiden Fällen kann der Schalter jederzeit geändert werden — siehe *Eine bestehende Verbindung umstellen* unten. - -Bei aktiviertem Artifact-Level Records: - -* Repositories bleiben als Einträge bestehen und werden zu **übergeordneten Assets**: Sie tragen selbst keine Befunde, aber wenn die Asset-Hierarchie-Funktion aktiviert ist, verknüpft DefectDojo jedes Artefakt-Asset automatisch mit einer `parent`-Beziehung mit seinem Repository-Asset. Assets können dann nach Parent/Child gefiltert werden, und Befunde werden in der Hierarchie nach oben aggregiert. -* Eine Schwachstelle, die mehrere Artefakte betrifft, wird in das Asset jedes betroffenen Artefakts importiert, sodass jedes Asset die vollständige Menge der es betreffenden Befunde zeigt. -* Befunde beziehen sich auf den **neuesten Build** jedes Artefakts, sodass die Befunde eines Artefakts dessen aktuellen Build beschreiben, statt Ergebnisse aus jedem von Xray je gescannten Build anzusammeln. -* Von diesem Connector erzeugte Hierarchiebeziehungen überschreiben nie von Ihnen manuell erstellte Beziehungen. Hat ein Asset bereits einen von Ihnen zugewiesenen Parent, lässt der Connector ihn unangetastet. -* Das Token benötigt zusätzlich Lesezugriff auf die Artifactory-Storage-API (in den obigen Scopes enthalten). - -**Eine bestehende Verbindung auf Artifact-Level Records umstellen:** Der Schalter kann jederzeit geändert werden. Beim ersten Sync danach erscheinen neue Artefakt-Einträge zur Zuordnung — aktivieren Sie **Auto Map** für die Verbindung beim Umschalten, damit Befunde ohne Lücke übertragen werden. Die Repository-Level-Assets erhalten keine Befunde mehr, und ihre zuvor importierten Befunde werden beim nächsten Sync geschlossen (dieselben Befunde werden mit neuem Status unter den neuen Artefakt-Assets erneut importiert); Notizen und Historie zu den alten Repository-Level-Befunden bleiben am Repository-Asset erhalten. Ein Zurückschalten kehrt dies um: Repository-Einträge tragen wieder Befunde (zuvor geschlossene Befunde werden bei erneuter Übereinstimmung wieder geöffnet), und Artefakt-Einträge werden als MISSING markiert — ihre Assets und Befunde bleiben erhalten, erhalten aber keine Updates mehr, sodass Sie sie nach Belieben archivieren können. - -Weitere Informationen finden Sie in der [JFrog-Xray-REST-API-Dokumentation](https://jfrog.com/help/r/jfrog-rest-apis/xray-rest-apis). - -## **Jira Service Management Assets** - -Der JSM-Assets-Connector ist ein **Asset-Connector**: Er zählt die Objekte in Ihrem Jira-Service-Management-Assets-Workspace (ehemals Insight) auf und erstellt für jedes Objekt ein DefectDojo-Asset, gruppiert in Organisationen nach Objektschema. Es werden keine Befunde importiert. - -#### Voraussetzungen - -* Assets erfordert einen **Jira-Service-Management-Premium- oder -Enterprise-Plan**. Bei Free- oder Standard-Plänen antwortet die Assets-API mit `403 "Access to Assets API was denied"`, obwohl der Rest der Site funktioniert. -* Das verwendete Atlassian-Konto muss auf der Site über **Jira-Service-Management-Produktzugriff** verfügen (einen Agent-Sitzplatz) — reiner Site-Zugriff genügt nicht. -* Erstellen Sie ein klassisches Atlassian-API-Token unter [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens). Wir empfehlen ein dediziertes Service-Konto. - -#### Connector-Zuordnungen - -1. Geben Sie Ihre Atlassian-Site-URL in das Feld **Location** ein: `https://{your-site}.atlassian.net`. -2. Geben Sie die Atlassian-Konto-E-Mail-Adresse, zu der das Token gehört, in das Feld **Email** ein. -3. Geben Sie das API-Token in das Feld **Secret** ein. - -Jedes Assets-Objekt wird zu einem nach dem Label des Objekts benannten Eintrag, gruppiert nach seinem **Objektschema**. - -## **Kubescape** - -Der Kubescape-Connector liest Kubernetes-Posture(Fehlkonfigurations)-Ergebnisse, die vom [Kubescape-Operator](https://kubescape.io/docs/install-operator/) erzeugt werden, direkt aus der Kubernetes-API des Clusters — ein ARMO-SaaS-Konto ist nicht erforderlich. Er liest die `WorkloadConfigurationScan`-Objekte, die von der im Cluster laufenden Storage-Aggregated-API des Operators bereitgestellt werden (`spdx.softwarecomposition.kubescape.io/v1beta1`). Jeder Kubernetes-**Namespace** mit Posture-Ergebnissen wird einem Eintrag (Produkt) zugeordnet; jede fehlgeschlagene Kontrolle auf einer Workload wird zu einem Befund. - -#### Voraussetzungen - -- Der Kubescape-Operator muss im Zielcluster mit aktiviertem Konfigurations-Scanning installiert sein (siehe [Installing in your cluster](https://kubescape.io/docs/install-operator/)). Bestätigen Sie mit `kubectl get workloadconfigurationscans -A`, dass Ergebnisse vorhanden sind. -- Eine **kubeconfig**, die Lesezugriff auf die API-Gruppe `spdx.softwarecomposition.kubescape.io` gewährt (list/get auf `workloadconfigurationscans`) für den Zielcluster. - -#### Connector-Zuordnungen - -1. Geben Sie die API-Server-URL des Clusters (oder eine sprechende Cluster-Kennung) in das Feld **Location** ein. -2. Fügen Sie die **kubeconfig** für den Zielcluster in das Feld `kubeconfig` ein. Setzen Sie optional `kube_context`, um einen Kontext darin auszuwählen, und `cluster_name`, um die ermittelten Produkte zu beschriften. -3. Jeder Namespace mit Posture-Ergebnissen wird als Eintrag ermittelt; ordnen Sie die gewünschten den DefectDojo-Produkten zu. - -Befunde werden pro fehlgeschlagener Kontrolle abgeleitet: Der Kontrollname und die Workload identifizieren den Befund, der Schweregrad stammt aus dem Score-Faktor der Kontrolle, die Kontroll-ID wird zur Schwachstellen-ID, und jeder Befund verlinkt auf seine Kontrollreferenz unter `https://hub.armosec.io/docs/`. - -## **Mend** - -Der Mend-Connector (ehemals **WhiteSource**) verwendet die Mend-API, um Sicherheitsbefunde aus Ihrer Mend-Organisation zu importieren. DefectDojo erstellt für jedes Mend-**Projekt** einen Eintrag. - -#### Voraussetzungen - -Sie benötigen einen Mend-(Service-)Benutzer mit einem **User Key** (einem persönlichen Zugriffstoken) und Ihre Mend-**Organization UUID**. Wir empfehlen ein dediziertes Service-Konto, damit automatisierte Aktivitäten leicht von manuellen Team-Aktionen zu unterscheiden sind. Die Organization UUID finden Sie in der Mend-App unter **Administration > Organization UUID**. - -#### Connector-Zuordnungen - -1. Geben Sie Ihre Mend-API-URL in das Feld **Location** ein. Diese URL ist **regionsspezifisch** — verwenden Sie die API-Basis-URL der Region, in der Ihre Mend-Organisation gehostet wird. -2. Geben Sie die Login-E-Mail-Adresse des Mend-Benutzers in das Feld **Email** ein. -3. Geben Sie Ihre Mend-**Organization UUID** in das Feld **Organization UUID** ein. -4. Geben Sie den Mend-**User Key** in das Feld **User Key** ein. -5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -## **Lacework / FortiCNAPP** - -Der Lacework-/FortiCNAPP-Connector verwendet die Lacework-v2-API, um **Host- und Container-Schwachstellen** für Ihr gesamtes Lacework-Konto zu importieren. - -#### Voraussetzungen - -Sie benötigen einen Lacework-**API-Schlüssel** — eine API-Key-ID und ein Secret, erstellt in der Lacework-Konsole unter **Settings → API keys**. Der Connector tauscht diese bei jedem Sync gegen ein kurzlebiges Zugriffstoken ein; Key-ID, Secret und Token werden nie protokolliert. - -#### Connector-Zuordnungen - -1. Geben Sie Ihre Lacework-Konto-URL in das Feld **Location** ein — zum Beispiel `https://YOUR-ACCOUNT.lacework.net` (ein bloßer Kontoname wird ebenfalls akzeptiert). -2. Geben Sie die **API Key ID** und das **API Secret** ein. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo ordnet das Lacework-**Konto** einem Eintrag zu (der gesamte Konto-Geltungsbereich). Jede **Container**- und **Host**-Schwachstelle wird zu einem Befund: Der Schweregrad stammt aus Laceworks eigener Bewertung, das betroffene Paket und die Version werden zur Komponente, die Fix-Version wird zur Abhilfemaßnahme, und das betroffene Image/der betroffene Host wird als Tags erfasst. Container-Schwachstellen werden als statische Befunde erfasst (Image-Scans) und Host-Schwachstellen als dynamische Befunde (Scans laufender Hosts). - -Weitere Informationen finden Sie in der [Lacework-API-Dokumentation](https://docs.lacework.net/api/v2/docs). - -## **Microsoft Defender** - -Der Microsoft-Defender-Connector importiert Geräte-Schwachstellenbefunde aus **Microsoft Defender Vulnerability Management (MDVM)** — einen Befund pro Kombination aus Gerät/Softwareversion/CVE, einschließlich Schweregrad, CVSS-Score, Ausnutzbarkeitsgrad und empfohlener Sicherheitsupdates. DefectDojo ermittelt Ihre Defender-**Gerätegruppen** und erstellt für jede einen Eintrag; Geräte, die keiner Gerätegruppe zugewiesen sind, werden unter einer synthetischen Gruppe **Unassigned** zusammengefasst. - -**Bitte beachten Sie:** Dieser Connector unterscheidet sich vom dateibasierten Scan-Typ **„MSDefender Parser"**, der manuell exportierte Defender-Dateien importiert. Wählen Sie pro Produkt einen Importpfad, um doppelte Befunde zu vermeiden. - -#### Voraussetzungen - -Ihr Microsoft-Tenant benötigt eine aktive Lizenz, die die Defender-Vulnerability-Export-APIs einschließt: **Defender for Endpoint Plan 2**, **Microsoft Defender Vulnerability Management Standalone**, oder MDE P1/P2 mit dem MDVM-Add-on. (Das MDVM-*Add-on*-SKU allein reicht nicht aus — es setzt Defender for Endpoint Plan 2 voraus.) - -Der Connector authentifiziert sich als Microsoft-Entra-ID-**App-Registrierung** mittels Client-Credentials-Flow. So erstellen Sie eine: - -1. Öffnen Sie im [Azure-Portal](https://portal.azure.com) **App registrations \> New registration**. Benennen Sie sie (zum Beispiel `defectdojo-connector`), belassen Sie die Standardwerte, und wählen Sie **Register**. -2. Notieren Sie sich auf der **Overview**-Seite der App die **Application (client) ID** und die **Directory (tenant) ID**. -3. Öffnen Sie **API permissions \> Add a permission \> APIs my organization uses** und suchen Sie nach **WindowsDefenderATP**. Erscheint es nicht, wurde das Defender-Backend Ihres Tenants noch nicht bereitgestellt: Stellen Sie sicher, dass die Lizenz aktiv ist, öffnen Sie einmal [security.microsoft.com](https://security.microsoft.com), und versuchen Sie es nach einigen Minuten erneut. -4. Wählen Sie **Application permissions** (*nicht* Delegated — Delegated-Berechtigungen erscheinen nie im Service-Token des Connectors), erweitern Sie **Vulnerability**, markieren Sie **Vulnerability.Read.All**, und wählen Sie **Add permissions**. -5. Wählen Sie **Grant admin consent** und bestätigen Sie. Die Status-Spalte muss ein grünes Häkchen zeigen — ohne diesen Schritt liefert jeder API-Aufruf einen 403-Fehler. -6. Öffnen Sie **Certificates & secrets \> New client secret**, legen Sie ein Ablaufdatum fest, und kopieren Sie den **Value** des Secrets sofort (er wird nur einmal angezeigt). Der Connector funktioniert nicht mehr, wenn das Secret abläuft; notieren Sie sich daher das Datum. - -#### Connector-Zuordnungen - -1. Geben Sie `https://api.security.microsoft.com` in das Feld **Location** ein. -2. Geben Sie die **Directory (tenant) ID** in das Feld **Tenant ID** ein. -3. Geben Sie die **Application (client) ID** in das Feld **Client ID** ein. -4. Geben Sie den Wert des Client-Secrets in das Feld **Client Secret** ein. -5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jede Defender-Gerätegruppe wird zu einem Eintrag. Microsoft erneuert den vom Connector gelesenen Schwachstellen-Snapshot etwa alle 6 Stunden, und neu angebundene Geräte können bis zu ca. 24 Stunden benötigen, um ihre ersten Schwachstellendaten zu liefern — ein brandneuer Tenant wird legitim null Befunde synchronisieren, bis Geräte angebunden und bewertet wurden. Auch die Lizenzaktivierung selbst kann ca. 20 Minuten oder länger benötigen, bis sie die API erreicht (Fehler „No active license found" während dieses Zeitfensters lösen sich von selbst). - -## **Microsoft Defender for Cloud** - -Der Microsoft-Defender-for-Cloud-Connector importiert Schwachstellenbefunde aus **Microsoft Defender Vulnerability Management (MDVM)**, wie sie von Defender for Cloud bereitgestellt werden — sowohl **Server**-Befunde (CVEs des Betriebssystems und der installierten Software von Azure-VMs) als auch **Container-Registry**-Befunde (CVEs von Container-Images), einschließlich Schweregrad, CVSS-Score, dem betroffenen Paket oder Image und Abhilfemaßnahmen. DefectDojo ermittelt die Azure-**Subscriptions**, die Ihr Service Principal lesen kann, und erstellt für jede aktivierte Subscription einen Eintrag. - -**Bitte beachten Sie:** Dieser Connector unterscheidet sich vom **Microsoft-Defender**-Connector, der Gerätebefunde aus der Defender-for-Endpoint-API importiert. Defender for Cloud ist ein Azure-Produkt mit einer anderen API-Oberfläche (Azure Resource Manager/Resource Graph) und einem anderen Berechtigungsmodell (Azure RBAC). Verwenden Sie denjenigen, der zu Ihren Befundquellen passt — oder beide, wenn Sie beide Produkte nutzen. - -#### Voraussetzungen - -Sie benötigen eine oder mehrere **Azure-Subscriptions mit aktiviertem Microsoft Defender for Cloud**, wobei die relevanten Defender-Pläne für die zu scannenden Ressourcen aktiviert sind (unter **Microsoft Defender for Cloud \> Environment settings**, dann Ihre Subscription auswählen): - -* **Defender for Servers (Plan 2)** — CVE-Befunde zum Betriebssystem und zur Software von Azure-VMs (agentloses Vulnerability Scanning). -* **Defender for Containers** — CVE-Befunde von Container-Registry-Images. - -SQL-Vulnerability-Assessment- und Konfigurations-/Posture-Befunde werden bewusst **nicht** importiert — dieser Connector importiert ausschließlich CVE-Schwachstellen. - -Der Connector authentifiziert sich als Microsoft-Entra-ID-**App-Registrierung** mittels Client-Credentials-Flow: - -1. Öffnen Sie im [Azure-Portal](https://portal.azure.com) **App registrations \> New registration**. Benennen Sie sie (zum Beispiel `defectdojo-connector`), belassen Sie die Standardwerte, und wählen Sie **Register**. -2. Notieren Sie sich auf der **Overview**-Seite der App die **Application (client) ID** und die **Directory (tenant) ID**. -3. Öffnen Sie **Certificates & secrets \> New client secret**, legen Sie ein Ablaufdatum fest, und kopieren Sie den **Value** des Secrets sofort (er wird nur einmal angezeigt). Der Connector funktioniert nicht mehr, wenn das Secret abläuft; notieren Sie sich daher das Datum. -4. Gewähren Sie der App Lesezugriff auf jede zu importierende Subscription: Öffnen Sie **Subscriptions**, wählen Sie Ihre Subscription, dann **Access control (IAM) \> Add \> Add role assignment**. Wählen Sie die Rolle **Security Reader** (oder **Reader**), und weisen Sie sie im Tab **Members** der von Ihnen erstellten App zu — suchen Sie sie über den **Namen** oder die **Object ID** der App, da der Picker nicht mit der Client ID abgleicht. Wiederholen Sie dies für jede Subscription. - -Anders als beim gerätebasierten Microsoft-Defender-Connector sind keine API-Berechtigungen oder Admin-Consent erforderlich: Der Zugriff auf Defender for Cloud wird ausschließlich über die oben genannte Azure-RBAC-Rollenzuweisung geregelt. - -#### Connector-Zuordnungen - -1. Geben Sie `https://management.azure.com` in das Feld **Location** ein. (Verwenden Sie bei souveränen Clouds den passenden ARM-Endpunkt, zum Beispiel `https://management.usgovcloudapi.net`.) -2. Geben Sie die **Directory (tenant) ID** in das Feld **Tenant ID** ein. -3. Geben Sie die **Application (client) ID** in das Feld **Client ID** ein. -4. Geben Sie den Wert des Client-Secrets in das Feld **Client Secret** ein. -5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jede aktivierte Azure-Subscription wird zu einem Eintrag. Befunde werden über Azure Resource Graph gelesen, sodass sie zügig sichtbar werden, sobald Defender for Cloud Ihre Ressourcen gescannt hat — die Scans selbst laufen jedoch nach dem Zeitplan von Microsoft: Container-Registry-Images werden meist innerhalb einer Stunde nach dem Push gescannt, während der erste agentlose Schwachstellen-Scan einer VM mehrere Stunden dauern kann. Eine neu aktivierte Subscription wird legitim null Befunde synchronisieren, bis ihre Ressourcen gescannt wurden. - -## **MobSF** - -Der MobSF-Connector verwendet die REST-API des [Mobile Security Framework (MobSF)](https://github.com/MobSF/Mobile-Security-Framework-MobSF), um statische Analyseergebnisse mobiler Anwendungen (APK/IPA) zu importieren. DefectDojo ermittelt jede App, die auf Ihrer MobSF-Instanz gescannt wurde, und erstellt für jede einen Eintrag; anschließend werden die statischen Analysebefunde dieser App importiert. - -#### Voraussetzungen - -Sie benötigen Ihren MobSF-**REST-API-Schlüssel**. Sie finden ihn auf der MobSF-Startseite unter **API** (in der MobSF-Dokumentation auch als `Authorization`-Wert angezeigt). Der Schlüssel wird bei jeder Anfrage gesendet und nie protokolliert. - -#### Connector-Zuordnungen - -1. Geben Sie Ihre MobSF-Basis-URL in das Feld **Location** ein (zum Beispiel `https://mobsf.example.com`). -2. Geben Sie im Feld **Secret** den MobSF-REST-API-Schlüssel ein. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo ordnet jede gescannte **App** einem Eintrag zu und importiert deren Befunde aus dem MobSF-JSON-Bericht über mehrere Abschnitte hinweg — Anwendungsberechtigungen, Code-Analyse, das Signaturzertifikat, das Android-Manifest, Android-API-Nutzung und Binäranalyse. Jeder Befund wird mit **CWE 919** (mobil) getaggt, und sein Schweregrad stammt aus MobSFs eigener Bewertung (high, warning, info, secure/good) — eine *gefährliche* Berechtigung wird als High behandelt. Befunde werden als statische Befunde erfasst und anhand von Scan, Abschnitt, Titel, Schweregrad und Dateipfad dedupliziert. - -Weitere Informationen finden Sie in der [MobSF-REST-API-Dokumentation](https://mobsf.github.io/docs/#/rest_api). - -## **NeuVector** - -Der NeuVector-Connector verwendet die Controller-REST-API von [NeuVector](https://github.com/neuvector/neuvector), um Container-**Image-Schwachstellen-Scans** zu importieren. DefectDojo ermittelt jedes von NeuVector gescannte Image und erstellt für jedes einen Eintrag; anschließend wird der Scan-Bericht dieses Images als Befunde importiert. - -#### Voraussetzungen - -Sie benötigen einen NeuVector-**Benutzernamen und ein Passwort** für ein Controller-Konto mit Berechtigung, Scan-Ergebnisse zu lesen. Der Connector meldet sich mit diesen Anmeldedaten an, um ein Session-Token zu erhalten; das Passwort und das Token werden nie protokolliert. - -#### Connector-Zuordnungen - -1. Geben Sie Ihre NeuVector-Controller-URL einschließlich des REST-API-Ports in das Feld **Location** ein — zum Beispiel `https://neuvector.example.com:10443`. -2. Geben Sie den Controller-**Username** und das **Password** ein. -3. Wenn Ihr Controller ein selbstsigniertes Zertifikat verwendet, setzen Sie **Skip TLS Verification** auf `true`. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo ordnet jedes gescannte **Image** einem Eintrag zu und jede **CVE** in dessen Scan-Bericht einem Befund. Der Schweregrad stammt aus NeuVectors eigener Bewertung, und das betroffene Paket und die Version, der CVSSv3-Score und -Vektor, die Fix-Version (als Abhilfemaßnahme) sowie ein Referenzlink werden übernommen. Befunde werden anhand von Image, CVE, Paket, Version und Schweregrad dedupliziert. - -Weitere Informationen finden Sie in der [NeuVector-API-Dokumentation](https://open-docs.neuvector.com/automation/automation). - -## **Nuclei (ProjectDiscovery Cloud)** - -Der Nuclei-Connector verwendet die REST-API der ProjectDiscovery Cloud Platform (PDCP), um [nuclei](https://github.com/projectdiscovery/nuclei)-Scan-Ergebnisse aus Ihrem PDCP-Konto abzurufen. DefectDojo ermittelt jeden Scan im Konto und erstellt für jeden **Scan** einen separaten Eintrag. - -#### Voraussetzungen - -Sie benötigen einen ProjectDiscovery-Cloud-**API-Schlüssel**. Wir empfehlen, für DefectDojo ein dediziertes Service-Konto anzulegen, um automatisierte Aktivitäten klar von manuellen Team-Aktionen zu unterscheiden. Generieren Sie einen Schlüssel unter **Settings \> API Key** in der ProjectDiscovery-Cloud-Oberfläche ([cloud.projectdiscovery.io](https://cloud.projectdiscovery.io)). Ergebnisse gelangen entweder über gehostete Scans oder über die mit `-dashboard` ausgeführte nuclei-CLI zu PDCP. - -#### Connector-Zuordnungen - -1. Geben Sie die Basis-URL der PDCP-API in das Feld **Location** ein: `https://api.projectdiscovery.io`. -2. Geben Sie Ihren **API-Schlüssel** in das Feld **Secret** ein. -3. Geben Sie optional eine **Team ID** ein, um den Sync auf einen Team-Workspace zu beschränken (zu finden unter **Settings \> Team**). Bleibt das Feld leer, synchronisiert DefectDojo Ihren persönlichen Workspace. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo ordnet jeden PDCP-**Scan** als separaten Eintrag zu und importiert dessen Befunde über alle Schweregrade hinweg, einschließlich informativer. - -## **OpenVAS / Greenbone** - -Der OpenVAS-/Greenbone-Connector importiert **Netzwerk-Schwachstellenbefunde** aus einer Greenbone-Instanz (Greenbone Community Edition oder Greenbone Enterprise). Er kommuniziert mit `gvmd` über **GMP (Greenbone Management Protocol)** — ein XML-Protokoll über ein TLS-Socket, nicht HTTP — und synchronisiert die gesamte Instanz: Er zählt Scan-**Tasks** auf und erstellt für jeden ein DefectDojo-Produkt, wobei die Ergebnisse des jeweils letzten Berichts jedes Tasks importiert werden. - -#### Voraussetzungen - -Ein Greenbone-**GMP-Benutzer** (Benutzername + Passwort) und Netzwerkzugriff auf den GMP-TLS-Port von gvmd (standardmäßig **9390**). Der Compose-Stack der Greenbone Community Edition stellt gvmd über einen Unix-Socket bereit; um ihn von einem vernetzten Connector aus zu erreichen, betreiben Sie den Connector entweder dort, wo er den Socket erreichen kann, oder exponieren Sie den GMP-TLS-Port (zum Beispiel eine `socat`-TLS-Bridge zu `gvmd.sock`). - -#### Connector-Zuordnungen - -1. Geben Sie den gvmd-Host in das Feld **Location** ein (Host oder `host:port`). -2. Geben Sie den GMP-**Username** und das **Password** ein. -3. Legen Sie optional den **GMP Port** fest (Standard 9390). -4. Für das standardmäßige selbstsignierte Zertifikat von gvmd geben Sie entweder ein **CA Certificate (PEM)** zur Verifizierung an, oder setzen Sie **Skip TLS Verification** auf `true`. -5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jeder Greenbone-Task wird zu einem Eintrag. Befunde stammen aus dem letzten abgeschlossenen Bericht des Tasks — einer pro ``. Der Schweregrad wird der Threat-Level-Angabe des Ergebnisses entnommen (Greenbones informative Stufen `Log`/`Debug` werden auf Info abgebildet), wobei der numerische CVSS-Score erfasst wird; CVE-Referenzen werden zu Schwachstellen-IDs, die NVT-Lösung wird zur Abhilfemaßnahme, und Host/Port jedes Ergebnisses werden zu einem Endpunkt. - -## Probely - -Dieser Connector verwendet die Probely-REST-API, um Daten abzurufen. - -​**Connector-Zuordnungen** - -1. Geben Sie die passende API-Server-Adresse in das Feld **Location** ein. (entweder oder ) -2. Geben Sie einen gültigen API-Schlüssel in das Feld **Secret** ein. - -Einen API-Schlüssel finden Sie in Probely unter dem Menü User \> API Keys. -Weitere Informationen finden Sie in der [Probely-Dokumentation](https://help.probely.com/en/articles/8592281-how-to-generate-an-api-key). - -## Prowler - -Der Prowler-Connector verwendet die **Prowler-App**-REST-API, um Cloud-Security-Posture(CSPM)-Befunde von einer selbstgehosteten Prowler-App-Instanz zu importieren. DefectDojo ermittelt jeden Prowler-**Provider** (Cloud-Konto) als Eintrag und importiert die **FAIL**-Befunde des letzten abgeschlossenen Scans dieses Providers. - -#### Voraussetzungen - -Sie benötigen eine laufende, selbstgehostete **Prowler-App**-Instanz sowie entweder eine Benutzer-E-Mail-Adresse + ein Passwort (für JWT-Authentifizierung) oder einen Prowler-App-**API-Schlüssel**. Befunde erscheinen erst, sobald Sie ein Cloud-Konto (AWS, GCP, Azure, Kubernetes, ...) in der Prowler-App verbunden und einen Scan ausgeführt haben. - -#### Connector-Zuordnungen - -1. Geben Sie Ihre Prowler-App-URL in das Feld **Location** ein (zum Beispiel `https://prowler.your-company.com`). -2. Geben Sie für die JWT-Authentifizierung die **Email** und das **Password** des Prowler-App-Benutzers ein. Alternativ lassen Sie diese leer und geben einen Prowler-App-**API-Schlüssel** ein. Sind beide angegeben, wird E-Mail/Passwort (JWT) verwendet. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. - -DefectDojo erstellt für jeden Prowler-Provider einen Eintrag und importiert die FAIL-Befunde von dessen letztem abgeschlossenem Scan, wobei Prowler-Schweregrade auf DefectDojo-Schweregrade abgebildet werden, die betroffene Cloud-Ressource (ARN/Ressourcen-ID) zur Komponente wird und die Abhilfemaßnahme sowie das Risiko der Prüfung in den Befund übernommen werden. Stummgeschaltete Befunde werden übersprungen. Cloud-Konto, Region und Dienst werden als Tags angehängt. - -Weitere Informationen finden Sie in der **[Prowler-App-API-Dokumentation](https://api.prowler.com/api/v1/docs)**. - -## Qualys - -Der Qualys-Connector importiert **VMDR-Host-Schwachstellendetektionen** — jeweils verknüpft mit den Metadaten der Qualys-KnowledgeBase (QID) — von der Qualys Cloud Platform. DefectDojo erstellt für jeden Qualys-**Host** in Ihrer Subscription einen Eintrag. - -#### Voraussetzungen - -Ein Qualys-Benutzerkonto mit **VMDR-API-Zugriff** sowie die **API-Server(Platform)-URL** Ihrer Subscription — diese unterscheidet sich je nach Subscription. Sie finden sie in der Qualys-Oberfläche unter **Help \> About** oder auf der Qualys-Seite [Platform Identification](https://www.qualys.com/platform-identification/) (zum Beispiel `https://qualysapi.qualys.com` für US Platform 1, oder `https://qualysapi.qg2.apps.qualys.com` für US Platform 2). - -#### Connector-Zuordnungen - -1. Geben Sie Ihre Qualys-API-Server-URL in das Feld **Location** ein (zum Beispiel `https://qualysapi.qualys.com`). -2. Geben Sie den Qualys-API-Benutzernamen in das Feld **Username** ein. -3. Geben Sie das Qualys-API-Passwort in das Feld **Secret** ein. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jeder Qualys-Host wird zu einem Eintrag. Detektionen, die Qualys als **Fixed** markiert hat, werden ausgeschlossen, sodass ein erneuter Import behobene Befunde schließt. - -## **Quay** - -Der Quay-Connector verwendet die Project-Quay-REST-API, um Container-Repositories zu ermitteln und die von Quays integriertem **Clair**-Scanner erzeugten Schwachstellenberichte zu importieren. DefectDojo erstellt für jedes Quay-**Repository** einen Eintrag und liest bei jedem Sync den Clair-Sicherheitsbericht des Image-Manifests jedes aktiven Tags. - -#### Voraussetzungen - -Security Scanning (Clair) muss auf Ihrer Quay-Instanz aktiviert sein, und Sie benötigen ein Quay-**OAuth-2-Zugriffstoken**: - -* Erstellen (oder öffnen) Sie in Quay eine Organisation, gehen Sie zu **Applications**, erstellen Sie eine OAuth-Anwendung, und dann **Generate Token** mit mindestens dem Scope **Read repositories**. Eine dedizierte Anwendung für DefectDojo wird empfohlen. -* Das Token wird bei jeder Anfrage als Bearer-Token gesendet und nie protokolliert. - -#### Connector-Zuordnungen - -1. Geben Sie Ihre Quay-Basis-URL in das Feld **Location** ein, zum Beispiel `https://quay.io` oder Ihr selbstgehostetes `https://quay.example.com`. Die URL muss HTTPS verwenden; geben Sie keinen abschließenden API-Pfad an — DefectDojo erstellt die API-Pfade automatisch. -2. Geben Sie das OAuth-Zugriffstoken in das Feld **Secret** ein. -3. Legen Sie optional einen **Namespace** fest, um die Ermittlung auf eine einzelne Quay-Organisation oder einen Benutzer zu beschränken. Leer lassen, um jedes Repository zu ermitteln, das das Token lesen kann. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo ordnet jedes Quay-**Repository** einem Eintrag zu. Für jedes Repository listet es die aktiven Tags auf, dedupliziert sie zu ihren eindeutigen Image-Manifesten (ein von mehreren Tags gemeinsam genutztes Manifest wird einmal gescannt) und liest den Clair-Bericht jedes Manifests. Manifeste, deren Scan Clair noch nicht abgeschlossen hat (zum Beispiel eine Multi-Architektur-Manifestliste oder ein noch in der Warteschlange befindliches Image), werden bis zu einem späteren Sync übersprungen. Jede Clair-Schwachstelle wird zu einem Befund — das betroffene Paket ist die Komponente, die Fix-Version wird zur Abhilfemaßnahme, und Clairs Schweregrade **Negligible**/**Unknown** werden als **Informational** erfasst. - -Weitere Informationen finden Sie in der [Project-Quay-API-Dokumentation](https://docs.projectquay.io/api_quay.html) und der [Clair-Dokumentation](https://quay.github.io/clair/). - -## **Rapid7 InsightAppSec** - -Der Rapid7-InsightAppSec-Connector importiert **DAST-Schwachstellenbefunde** von der InsightAppSec-Cloud-Plattform, angereichert mit Attack-Module-Metadaten (zum Beispiel *SQL Injection*), CVSS-Scores und den vom Scan gesammelten Nachweisen. DefectDojo erstellt für jede InsightAppSec-**App** einen Eintrag. - -**Bitte beachten Sie:** Dieser Connector unterscheidet sich vom **Rapid7-InsightVM**-Connector weiter unten — InsightAppSec ist Rapid7s Cloud-DAST-Produkt auf der Insight-Plattform, während InsightVM-Befunde aus Ihrer eigenen Security Console stammen. - -#### Voraussetzungen - -Ein Insight-Platform-Konto mit InsightAppSec sowie ein Platform-**API-Schlüssel**: Öffnen Sie in der [Rapid7-Insight-Plattform](https://insight.rapid7.com) das Einstellungsmenü (Zahnrad) \> **API Keys** und generieren Sie einen **User Key** (beliebige Rolle) oder einen **Organization Key** (Platform-Admins). Kopieren Sie den Schlüssel, wenn er angezeigt wird — er wird nur einmal angezeigt. - -Sie benötigen außerdem Ihre Platform-**Region**, sichtbar in Ihrer Insight-URL (zum Beispiel `us`, `us2`, `us3`, `eu`, `ca`, `au` oder `ap`). - -#### Connector-Zuordnungen - -1. Geben Sie Ihren regionalen API-Endpunkt in das Feld **Location** ein — zum Beispiel `https://us.api.insight.rapid7.com` (ersetzen Sie `us` durch Ihre Region). -2. Geben Sie den API-Schlüssel der Insight-Plattform in das Feld **API Key** ein. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jede InsightAppSec-App wird zu einem Eintrag. Es werden nur **offene** Schwachstellen (Unreviewed oder Verified) importiert — Befunde, die Rapid7 als Remediated, False Positive, Ignored oder Duplicate markiert hat, werden ausgeschlossen, sodass ein erneuter Import sie in DefectDojo schließt. Schweregrade werden direkt abgebildet (`SAFE` und `INFORMATIONAL` werden als Info importiert). - -## **Rapid7 InsightVM** - -Der Rapid7-InsightVM-Connector importiert Asset-Schwachstellenbefunde aus Ihrer InsightVM-**Security Console** (API v3), angereichert mit dem globalen Schwachstellenkatalog der Console. DefectDojo erstellt für jede InsightVM-**Site** einen Eintrag. - -#### Voraussetzungen - -Netzwerkzugriff von DefectDojo auf Ihre Security Console sowie ein **Benutzerkonto** der Console — dessen Login wird für die HTTP-Basic-Authentifizierung verwendet. Die Console-API wird standardmäßig auf Port **3780** bereitgestellt. - -#### Connector-Zuordnungen - -1. Geben Sie die URL Ihrer Security Console einschließlich des Ports in das Feld **Location** ein — zum Beispiel `https://console.example.com:3780`. -2. Geben Sie den Console-Benutzernamen in das Feld **Username** ein. -3. Geben Sie das Console-Passwort in das Feld **Secret** ein. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jede InsightVM-Site wird zu einem Eintrag; der Connector durchläuft die Assets der Site und importiert deren anfällige Befunde. - -## **runZero** - -Der runZero-Connector verwendet die runZero-Export-API, um das Asset-Inventar Ihrer gesamten Organisation mit DefectDojo zu synchronisieren. Er ist in erster Linie ein **Asset**-Connector: DefectDojo ermittelt jedes Asset und erstellt für jedes einen Eintrag, gruppiert in einen Produkttyp nach seiner runZero-**Site**. Optional kann er auch die Schwachstellen von runZero als Befunde importieren. - -#### Voraussetzungen - -Sie benötigen einen organisationsweiten **Export Token** von runZero (Account → API), der mit `XT` beginnt. Das Token ist organisationsgebunden (die Organisation ist im Token codiert), schreibgeschützt und wird als Bearer-Token gesendet — es wird nie protokolliert. Ein Community-/Starter-Tier ist verfügbar. - -#### Connector-Zuordnungen - -1. Geben Sie Ihre runZero-Konsolen-URL in das Feld **Location** ein, zum Beispiel `https://console.runzero.com`. Die URL muss HTTPS verwenden. -2. Geben Sie das Export Token in das Feld **Secret** ein. -3. Setzen Sie optional **Import Vulnerabilities** auf `true`, um auch runZero-Schwachstellen als Befunde zu importieren; lassen Sie es leer, um nur Assets zu synchronisieren. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Schwachstellenbefunde importiert werden (gilt nur, wenn Schwachstellen importiert werden). - -DefectDojo ordnet jedes runZero-**Asset** einem Eintrag (VEP) zu: Der Anzeigename stammt aus dem Namen oder der Adresse des Assets, und dessen Site, Typ, Betriebssystem, Adressen und Tags werden als Attribute angehängt; die **Site** des Assets wird zu dessen Produkttyp. Assets werden mit einem vollständigen Export synchronisiert, den DefectDojo abgleicht (Hinzufügen/Entfernen). Ist **Import Vulnerabilities** aktiviert, wird jede runZero-Schwachstelle zu einem Befund an ihrem Asset — dabei werden Schweregrad, CVSS-Score, CVE, der betroffene Dienst-Endpunkt (`protocol://address:port`) und die Abhilfemaßnahme abgebildet. - -Weitere Informationen finden Sie in der [runZero-API-Dokumentation](https://help.runzero.com/). - -## **Semgrep** - -Dieser Connector verwendet die Semgrep-REST-API, um Daten abzurufen. - -#### Connector-Zuordnungen - -Geben Sie `https://semgrep.dev/api/v1/` in das Feld **Location** ein. - -1. Geben Sie einen gültigen API-Schlüssel in das Feld **Secret** ein. Sie finden diesen auf der Tokens-Seite: -​ -„Settings" in der linken Navigationsleiste \> Tokens \> Create new token ([https://semgrep.dev/orgs/\-/settings/tokens](https://semgrep.dev/orgs/-/settings/tokens)) - -Weitere Informationen finden Sie in der [Semgrep-Dokumentation](https://semgrep.dev/docs/semgrep-cloud-platform/semgrep-api/#tag__badge-list). - -## **ServiceNow CMDB** - -Der ServiceNow-CMDB-Connector ist ein **Asset-Connector**: Anstatt Befunde zu importieren, liest er Configuration Items (CIs) aus Ihrer ServiceNow Configuration Management Database und erstellt für jede CI ein DefectDojo-Asset, gruppiert in Organisationen nach CI-Klasse. Es werden keine Befunde importiert. - -#### Voraussetzungen - -Sie benötigen eine ServiceNow-Instanz und ein Konto, das die CMDB-Tabellen über die ServiceNow-Table-API lesen kann. Wir empfehlen ein dediziertes, schreibgeschütztes Service-Konto für DefectDojo. Das Konto benötigt Lesezugriff auf die zu importierenden `cmdb_ci`-Tabellen. - -#### Connector-Zuordnungen - -1. Geben Sie die URL Ihrer ServiceNow-Instanz in das Feld **Location** ein: `https://{your-instance}.service-now.com`. -2. Wählen oder erstellen Sie eine ServiceNow-**Tool Configuration**, die die Instanz-Anmeldedaten enthält (den ServiceNow-Benutzernamen und das Passwort). - -Jedes Configuration Item wird zu einem nach der CI benannten Eintrag, gruppiert nach seiner **CI-Klasse** (zum Beispiel Application, Server oder Business Service). Discovery und Sync gleichen die CI-Liste ab: Neue CIs erscheinen als `NEW`-Einträge, und eine aus der CMDB entfernte CI wird beim nächsten Sync als `MISSING` markiert, damit Ihr Team sie prüfen kann. DefectDojo löscht niemals stillschweigend ein Produkt. - -## **Shodan** - -Der Shodan-Connector verwendet die Shodan-REST-API, um die von Shodan auf Ihren im Internet exponierten Hosts beobachteten Schwachstellen (CVEs) zu importieren. Sie geben eine Shodan-Suchanfrage an, die den Import auf Ihre eigenen Assets beschränkt; DefectDojo erstellt für jeden passenden Host einen Eintrag und importiert dessen CVEs als Befunde. - -#### Voraussetzungen - -Sie benötigen einen Shodan-API-Schlüssel, den Sie auf Ihrer Shodan-**Account**-Seite finden. Die Host-Suche mit Schwachstellendaten erfordert eine Shodan-Mitgliedschaft oder einen kostenpflichtigen API-Plan — die kostenlose Stufe kann Suchergebnisse nicht seitenweise durchblättern. - -#### Connector-Zuordnungen - -1. Geben Sie `https://api.shodan.io` in das Feld **Location** ein. -2. Geben Sie Ihren Shodan-API-Schlüssel in das Feld **API Key** ein. -3. Geben Sie im Feld **Search Query** eine Shodan-Abfrage ein, die den Import auf die Assets Ihrer Organisation beschränkt — zum Beispiel `hostname:example.com`, `net:203.0.113.0/24` oder `org:"Example Inc"`. Es werden nur Hosts importiert, die dieser Abfrage entsprechen; beschränken Sie sie daher auf Infrastruktur, die Ihnen gehört. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jeder passende Host wird zu einem Eintrag, und jede von Shodan auf den exponierten Diensten dieses Hosts erkannte CVE wird als Befund importiert — der Schweregrad wird aus dem CVSS-Score abgeleitet, wobei EPSS- und CISA-KEV-Kontext einbezogen wird, sofern verfügbar. Jede Seite der Suchergebnisse verbraucht ein Shodan-Abfrage-Guthaben. - -## SonarQube - -Der SonarQube-Connector kann Daten entweder von einem SonarCloud-Konto oder von einer lokalen SonarQube-Instanz abrufen. - -**Für SonarCloud-Benutzer:** - -1. Geben Sie https://sonarcloud.io/ in das Feld Location ein. -2. Geben Sie einen gültigen **API-Schlüssel** in das Feld Secret ein. - -**Für SonarQube-Benutzer (On-Premise):** - -1. Geben Sie die Basis-URL Ihrer SonarQube-Instanz in das Feld Location ein: zum Beispiel `https://my.sonarqube.com/` -2. Geben Sie einen gültigen **API-Schlüssel** in das Feld Secret ein. Dies muss ein **[User](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/)**-[API-Token-Typ](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/) sein. - -Das Token benötigt Zugriff auf Projects, Vulnerabilities und Hotspots innerhalb von Sonar. - -API-Tokens finden und generieren Sie über **My Account \-\> Security \-\> Generate Token** in der SonarQube-App. Weitere Informationen finden Sie in der [SonarQube-Dokumentation](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/). - -## **Snyk** - -Der Snyk-Connector verwendet die Snyk-REST-API, um Daten abzurufen. - -#### Connector-Zuordnungen - -1. Geben Sie **[https://api.snyk.io/rest](https://api.snyk.io/v1)** oder **[https://api.eu.snyk.io/rest](https://api.eu.snyk.io/v1)** (für eine regionale EU-Bereitstellung) in das Feld **Location** ein. -2. Geben Sie einen gültigen API-Schlüssel in das Feld **Secret** ein. API-Tokens finden Sie auf der **[Account-Settings](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token)**-[Seite](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token) eines Benutzers in Snyk. - -Weitere Informationen finden Sie in der [Snyk-API-Dokumentation](https://docs.snyk.io/snyk-api). - -## **Socket** - -Der Socket-Connector verwendet die API von [Socket.dev](https://socket.dev), um **Software-Supply-Chain-Befunde** zu importieren — Sockets Warnungen zu Ihren Abhängigkeiten (Malware, Typosquats, Install-Skripte, bekannte Schwachstellen und über 70 weitere Kategorien). DefectDojo ermittelt jedes Repository in den Organisationen, auf die Ihr Token zugreifen kann, und erstellt für jedes einen Eintrag; anschließend werden die Warnungen aus dem letzten vollständigen Scan dieses Repositorys importiert. - -#### Voraussetzungen - -Sie benötigen ein Socket-**API-Token** — ein Organisations-Token, das im Socket-Dashboard unter **Settings → API Tokens** erstellt wird (mit den Scopes `repo:list` und Full-Scan-Lesezugriff). Das Token wird als Bearer-Token gesendet und nie protokolliert. - -#### Connector-Zuordnungen - -1. Lassen Sie das Feld **Location** leer, um `https://api.socket.dev/v0` zu verwenden, oder geben Sie es explizit an. -2. Geben Sie das Socket-API-Token in das Feld **Secret** ein. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -DefectDojo ordnet jedes **Repository** einem Eintrag zu und importiert die Warnungen aus dessen letztem vollständigen Scan. Jede Warnung wird zu einem Befund: Der Schweregrad stammt aus Sockets eigener Bewertung (low, medium, high, critical), das betroffene Paket wird zur Komponente und zu einer PURL, die Warnungskategorie (Supply-Chain-Risiko, Qualität, Wartung, Schwachstelle, Lizenz) wird als Tags erfasst, und die Warnungsdetails werden in die Beschreibung übernommen. Befunde werden als statische Befunde erfasst und anhand des Socket-Warnungsschlüssels dedupliziert. - -Weitere Informationen finden Sie in der [Socket-API-Dokumentation](https://docs.socket.dev/reference). - -## **Sonatype IQ** - -Der Sonatype-IQ-Connector verwendet die REST-API des Sonatype-IQ-Servers (Nexus Lifecycle), um Open-Source-Komponentenschwachstellen zu importieren. Er zählt jede Anwendung in Ihrer IQ-Organisation auf und importiert für jede die Komponentenschwachstellen aus dem letzten Bericht dieser Anwendung auf der von Ihnen konfigurierten Lifecycle-Stufe. DefectDojo erstellt automatisch für jede Anwendung einen Eintrag — es gibt keine Pro-Anwendungs-Konfiguration. - -#### Voraussetzungen - -Sie benötigen ein Sonatype-IQ-Benutzerkonto mit der Berechtigung **View IQ Elements** für die zu importierenden Anwendungen. Sonatype empfiehlt die Authentifizierung mit einem **User Token** (generiert unter **My Profile > User Token** im IQ Server) statt eines Passworts; die beiden Teile des Tokens werden unten den Feldern Username und User Token zugeordnet. Der Connector funktioniert sowohl mit selbstgehostetem IQ Server als auch mit von Sonatype gehosteten (SaaS-)Instanzen. - -#### Connector-Zuordnungen - -1. Geben Sie im Feld **Location** die Basis-URL Ihres IQ-Servers ein — für einen selbstgehosteten Server `https://iq.example.com`; für eine von Sonatype gehostete Instanz `https://.sonatype.app/platform`. -2. Geben Sie den IQ-Benutzer (oder den User-Code-Teil Ihres User Tokens) in das Feld **Username** ein. -3. Geben Sie das IQ-User-Token (oder das Passwort) in das Feld **User Token** ein. -4. Legen Sie optional eine **Stage** fest, um zu wählen, dessen Bericht pro Anwendung importiert wird (`build`, `stage-release`, `release` usw.). Leer lassen, um `build` zu verwenden. -5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jede Anwendung wird zu einem Eintrag, und jedes Sicherheitsproblem im letzten Bericht dieser Anwendung für die gewählte Stufe wird als Befund importiert. Der Schweregrad wird aus dem numerischen Score des Issues abgeleitet, und CVE-Referenzen, die CWE, der CVSS-Vektor sowie die Package-URL (PURL) der betroffenen Komponente werden einbezogen, sofern verfügbar. -## **Sysdig Secure** - -Der Sysdig-Secure-Connector importiert **Container-/CNAPP-Schwachstellenbefunde** über die Vulnerability-Management-API von Sysdig Secure. Er synchronisiert das gesamte Konto über die konfigurierten Geltungsbereich(e) und erstellt für jede gescannte Asset-Gruppierung ein DefectDojo-Produkt. - -#### Voraussetzungen - -Ein Sysdig-Secure-**API-Token**: Gehen Sie in Sysdig Secure zu **Settings \> Sysdig Secure API Token** und kopieren Sie das Token. Sie benötigen außerdem Ihre Sysdig-**Region-URL** (zum Beispiel `https://us2.app.sysdig.com`, `https://eu1.app.sysdig.com`, oder Ihren On-Premises-Host). - -#### Connector-Zuordnungen - -1. Geben Sie Ihre Sysdig-Region-/Basis-URL in das Feld **Location** ein. -2. Geben Sie das API-Token in das Feld **Secret** ein. -3. Legen Sie optional **Scopes** fest — eine kommagetrennte Liste aus `runtime`, `registry` und/oder `pipeline` (leer lassen für `runtime`, den Geltungsbereich bereitgestellter Workloads). -4. Legen Sie optional **Runtime Product Grouping** fest — wie Runtime-Ergebnisse auf Produkte abgebildet werden: `cluster`, `namespace`, `workload` oder `image` (leer lassen für `namespace`). Registry- und Pipeline-Ergebnisse werden immer nach Image-Repository gruppiert. -5. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jede Asset-Gruppierung wird zu einem Eintrag. Für jedes Scan-Ergebnis importiert der Connector jedes anfällige Paket als Befund. **Runtime**-Befunde (bereitgestellte Workloads) werden als dynamische Befunde erfasst und mit ihrem Kubernetes-Kontext (Cluster/Namespace/Workload/Container) getaggt; **Registry**- und **Pipeline**-Befunde werden als statische Image-Scan-Befunde erfasst. Sysdigs Schweregrad `NEGLIGIBLE` wird auf Info abgebildet. - -## Tenable - -Der Tenable-Connector verwendet die **Tenable.io**-REST-API, um Daten abzurufen. Scans werden vom Tenable-VM-Endpunkt `/scans` abgerufen. - -On-Premise-Tenable-Connectors sind derzeit nicht verfügbar. - -#### **Connector-Zuordnungen** - -1. Geben Sie in das Feld Location ein. -2. Geben Sie einen gültigen **API-Schlüssel** in das Feld Secret ein. - -Weitere Informationen finden Sie in der [Tenable-API-Dokumentation](https://docs.tenable.com/vulnerability-management/Content/Settings/my-account/GenerateAPIKey.htm). - -## **Tenable Web App Scanning** - -Der Tenable-Web-App-Scanning-Connector importiert **Web-Anwendungs(DAST)-Befunde** von Tenable Web App Scanning. Es handelt sich um einen separaten Connector zu Tenable (Vulnerability Management): Die beiden Produkte decken unterschiedliche Assets ab und werden unabhängig voneinander konfiguriert, sodass Sie entweder eines oder beide verwenden können. - -DefectDojo erstellt für jede **gescannte Web-Anwendung** einen Eintrag. Anwendungen werden aus Ihren Web-App-Scanning-Scan-Konfigurationen ermittelt; eine Konfiguration, die nie ausgeführt wurde, erzeugt erst nach ihrem ersten abgeschlossenen Scan einen Eintrag. Scannen mehrere Konfigurationen dieselbe Anwendung, teilen sie sich einen einzigen Eintrag. - -#### Voraussetzungen - -Tenable-**API-Schlüssel** (ein Access Key und ein Secret Key) für einen Benutzer mit Web-App-Scanning-Berechtigungen. Generieren Sie diese in Tenable unter **My Account \> API Keys**, und stellen Sie sicher, dass der Benutzer die zu importierenden Scans sehen kann — auf Vulnerability Management beschränkte Schlüssel können keine Web-App-Scanning-Daten lesen. - -On-Premise-Tenable-Connectors sind derzeit nicht verfügbar. - -#### Connector-Zuordnungen - -1. Geben Sie in das Feld **Location** ein. -2. Geben Sie Ihren **Access Key** und **Secret Key** ein. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Befunde werden mit dem Schweregrad importiert, den Tenable für Ihr Konto meldet, einschließlich jeder von Ihrem Team neu eingestuften Bewertung. Jeder Befund enthält die betroffene URL als Endpunkt, den Request-Parameter und die Payload, die ihn ausgelöst haben, sowie Tenables Nachweis und Ausgabe als Schritte zur Reproduktion, zusammen mit CWE-, CVE-, CVSS- und EPSS-Werten, sofern das erkennende Plugin diese liefert. - -Es werden nur derzeit offene oder wiedereröffnete Befunde importiert. Ein von Tenable als behoben markierter Befund wird beim nächsten Sync in DefectDojo geschlossen. - -## **Veracode** - -Der Veracode-Connector importiert Anwendungsbefunde von der Veracode-Plattform, aufgeteilt nach Scan-Typ in die Befundtypen **SAST**, **DAST**, **SCA** und **Manual**. DefectDojo erstellt für jede Veracode-**Anwendung** einen Eintrag. - -#### Voraussetzungen - -Generieren Sie eine Veracode-**API-Anmeldeinformation** für ein Konto, das die zu importierenden Anwendungen sehen kann: Öffnen Sie in der Veracode-Plattform Ihr Kontomenü \> **API Credentials** und wählen Sie **Generate API Credentials** (siehe [Managing Veracode API credentials](https://docs.veracode.com/r/c_api_credentials3)). Kopieren Sie sowohl die **API ID** als auch den **API Secret Key** — das Secret wird nur einmal angezeigt. - -#### Connector-Zuordnungen - -1. Geben Sie die Basis-URL der Veracode-API in das Feld **Location** ein: `https://api.veracode.com` (kommerzielle Region), `https://api.veracode.eu` (europäische Region) oder `https://api.veracode.us` (US-Bundesregion). -2. Geben Sie die API ID in das Feld **API ID** ein. -3. Geben Sie den API Secret Key in das Feld **Secret** ein. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. - -Jede Veracode-Anwendung wird zu einem Eintrag. Es werden nur **offene** Befunde importiert, sodass ein erneuter Import von Veracode als behoben gemeldete Befunde schließt. - -## **Wazuh** - -Der Wazuh-Connector verwendet den Wazuh Indexer (OpenSearch), um Schwachstellenbefunde abzurufen. Wazuh 4.8 und später speichern erkannte CVEs im Indexer statt in der Wazuh-Server-API, daher liest dieser Connector sie direkt aus dem Index `wazuh-states-vulnerabilities-*`. - -DefectDojo erstellt für jeden Wazuh-Agenten (Endpunkt) einen Eintrag und importiert die von diesem Agenten erkannten CVEs geplant als Befunde. - -#### Voraussetzungen - -Sie benötigen: - -* Die Basis-URL Ihres Wazuh Indexer einschließlich des Ports (der Indexer lauscht standardmäßig auf Port 9200). DefectDojo verbindet sich direkt mit dem Indexer, dieser Endpunkt muss daher von DefectDojo aus erreichbar sein. Bei selbstverwalteten Bereitstellungen ist dies der Host, auf dem der Wazuh Indexer läuft. Verwenden Sie bei Wazuh Cloud den in Ihrer Wazuh-Cloud-Konsole angezeigten Indexer-Endpunkt, der sich von der Wazuh-Dashboard-URL unterscheidet. -* Einen Indexer-Benutzer und ein Passwort mit Lesezugriff auf den Index `wazuh-states-vulnerabilities-*`. Wir empfehlen, für DefectDojo einen dedizierten Benutzer anzulegen. - -Die Schwachstellenerkennung muss in Wazuh aktiviert sein, damit der Vulnerability-State-Index befüllt wird. Weitere Informationen finden Sie in der [Wazuh-Dokumentation zur Schwachstellenerkennung](https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html). - -#### Connector-Zuordnungen - -1. Geben Sie die Basis-URL Ihres Wazuh Indexer einschließlich Schema und Port in das Feld **Location** ein, zum Beispiel `https://your-indexer.example.com:9200`. Geben Sie keinen abschließenden Pfad an. DefectDojo erstellt die Suchpfade automatisch. -2. Geben Sie den Indexer-Benutzernamen in das Feld **Username** ein. -3. Geben Sie das Indexer-Passwort in das Feld **Password** ein. -4. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. - -## Wiz - -Um den Wiz-Connector zu verwenden, müssen Sie ein Service-Konto erstellen: siehe die [Wiz-Dokumentation](https://docs.wiz.io/wiz-docs/docs/service-accounts-settings#add-a-service-account) für weitere Informationen. Sie benötigen ein Wiz-Konto, um auf die Dokumentation zuzugreifen. - -Das Service-Konto muss alle folgenden Anforderungen erfüllen. Ein Service-Konto, dem eine davon fehlt, kann sich zwar erfolgreich authentifizieren, importiert aber nichts: - -* **Type**: Custom Integration (GraphQL API). -* **API-Scopes**: mindestens `read:projects`, `read:issues` und `read:vulnerabilities`. -* **Projekt-Sichtbarkeit**: Das Service-Konto muss auf jedes zu importierende Wiz-Projekt beschränkt sein (oder auf alle Projekte). Der Connector ermittelt zunächst Ihre Wiz-Projekte und ruft dann die Befunde jedes Projekts ab — ein Konto, das Issues lesen kann, aber keine Projekt-Sichtbarkeit hat, ermittelt null Projekte, sodass nichts zu importieren ist und von keiner Seite ein Fehler gemeldet wird. - -#### **Connector-Zuordnungen** - -1. Geben Sie Ihre Wiz Client ID in das Feld Client ID ein. -2. Geben Sie das Wiz Client Secret in das Feld Secret ein. - -## **YesWeHack** - -Der YesWeHack-Connector verwendet die YesWeHack-REST-API, um Reports aus Ihren Bug-Bounty- und Vulnerability-Disclosure-Programmen zu importieren. DefectDojo erstellt für jedes Programm, auf das Ihr Token zugreifen kann, einen Eintrag und importiert dessen Reports als Befunde. - -#### Voraussetzungen - -Sie benötigen ein YesWeHack-**Personal Access Token (PAT)**. Lesezugriff auf Ihre Programme ist ausreichend. Manche Konten erfordern beim Erstellen eines Tokens TOTP/MFA; einmal erstellt, verwendet der Connector nur den Token-Wert selbst. - -1. Öffnen Sie in YesWeHack Ihre Kontoeinstellungen und gehen Sie zu **API / Personal Access Tokens**. -2. Erstellen Sie ein Token und kopieren Sie dessen Wert. Er wird nur einmal angezeigt. - -#### Connector-Zuordnungen - -1. Geben Sie `https://api.yeswehack.com/` in das Feld **Location** ein. -2. Geben Sie Ihr Personal Access Token in das Feld **Secret** ein. -3. Legen Sie optional einen **Minimum Severity**-Wert fest, um einzuschränken, welche Befunde importiert werden. Befunde unterhalb des gewählten Schweregrads werden nicht importiert. - -DefectDojo erstellt für jedes Programm, auf das Ihr Token zugreifen kann, einen separaten Eintrag und importiert jeden Report als Befund. Der Schweregrad des Befunds wird der CVSS-Bewertung des Reports entnommen (mit Rückgriff auf die Triage-Priorität), und sein Status spiegelt den Workflow-Status des Reports wider — zum Beispiel werden gelöste Reports als behoben importiert, und als ungültig oder außerhalb des Geltungsbereichs markierte Reports werden als inaktiv importiert. diff --git a/docs/content/connectors/upstream/toolreference.es.md b/docs/content/connectors/upstream/toolreference.es.md deleted file mode 100644 index 15e9348dfec..00000000000 --- a/docs/content/connectors/upstream/toolreference.es.md +++ /dev/null @@ -1,1501 +0,0 @@ ---- -title: Referencia de herramientas de Conectores Upstream -description: Nuestra lista de herramientas de Conector compatibles y cómo configurarlas - con DefectDojo -aliases: -- /es/import_data/pro/connectors/connectors_tool_reference/ -- /es/en/connecting_your_tools/connectors/connectors_tool_reference ---- - -Nota: los Conectores Upstream son una función exclusiva de DefectDojo Pro. - -Al configurar un Conector para una herramienta compatible, deberá proporcionar a DefectDojo información específica relacionada con la API de la herramienta. Como mínimo, necesitará: - -* **Location** \-un campo que generalmente hace referencia a la URL de su herramienta dentro de su red, -* **Secret** \- generalmente, una clave de API. - -Algunas herramientas requerirán campos adicionales relacionados con la API además de **Location** y **Secret**. También pueden requerir que realice cambios de su lado para admitir un Conector entrante desde DefectDojo. - -![imagen](images/connectors_tool_reference.png) - -Cada herramienta tiene una configuración de API diferente, y esta guía está diseñada para ayudarlo a configurar la API de la herramienta para que DefectDojo pueda conectarse. - -Siempre que sea posible, recomendamos crear una nueva cuenta 'DefectDojo Bot' dentro de su herramienta de seguridad, que solo será utilizada por el Conector. Esto le ayudará a diferenciar mejor entre las acciones realizadas manualmente por su equipo y las acciones automatizadas realizadas por el Conector. - -# **Conectores de activos** - -La mayoría de los Conectores importan **hallazgos** desde una herramienta de seguridad. Los **Conectores de activos** funcionan de forma diferente: en su lugar, importan su **inventario de activos**. Un Conector de activos enumera los activos que existen en una plataforma externa (por ejemplo, los repositorios de un grupo de GitLab) y crea y mantiene automáticamente los **Productos** (Activos) y **Tipos de producto** (Organizaciones) correspondientes en DefectDojo. Un Conector de activos no importa hallazgos. - -* Tanto **Discover** como **Sync** concilian la lista de activos. Los activos nuevos aparecen como Registros `NEW`; una vez asignados (automáticamente, si la asignación automática está habilitada), DefectDojo crea el Producto y lo agrupa bajo un Tipo de producto derivado de la herramienta — por ejemplo, el namespace de GitLab o el proyecto de Azure DevOps. -* Si más adelante se elimina un activo en el origen (por ejemplo, se elimina un repositorio), su Registro asignado se marca como `MISSING` en la siguiente Sync para que su equipo pueda triarlo. DefectDojo nunca elimina un Producto de forma silenciosa. - -Azure DevOps, Backstage, Bitbucket, GitHub, GitLab, Jira Service Management Assets y ServiceNow CMDB son Conectores de activos. runZero es principalmente un Conector de activos, pero opcionalmente puede importar vulnerabilidades como hallazgos. Todos los demás Conectores listados a continuación importan hallazgos. - -# **Conectores compatibles** - -## **Acunetix 360** - -El conector de Acunetix 360 importa **hallazgos de vulnerabilidades DAST** desde la plataforma en la nube de Acunetix 360 (la plataforma Invicti). DefectDojo descubre los sitios web escaneados de su cuenta y crea un Registro para cada **sitio web**; los hallazgos de un sitio web provienen de su último análisis completado. - -**Tenga en cuenta:** este conector es para **Acunetix 360** (el producto en la nube en `online.acunetix360.com`). No es para el escáner local Acunetix Standard/Premium, que tiene una API diferente. - -#### Requisitos previos - -Una cuenta de Acunetix 360 y una **credencial de API**: en Acunetix 360, abra el menú de su cuenta \> **API Settings**, anote el **API User ID** y genere un **API Token**. El conector se autentica con estos valores como credenciales HTTP Basic, por lo que se recomienda una cuenta de servicio dedicada para distinguir la actividad automatizada de las acciones manuales del equipo. - -#### Asignaciones del conector - -1. Ingrese la URL de su Acunetix 360 en el campo **Location**: `https://online.acunetix360.com`. -2. Ingrese el API User ID en el campo **API User ID**. -3. Ingrese el API Token en el campo **API Token**. -4. Opcionalmente, configure una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada sitio web escaneado se convierte en un Registro. Los hallazgos provienen del último análisis completado del sitio web; las vulnerabilidades que Acunetix 360 ha marcado como **Riesgo aceptado** o **Falso positivo** igualmente se importan, pero se marcan como inactivas (riesgo aceptado o falso positivo) para que el producto de DefectDojo refleje la clasificación del proveedor. - -## **Akamai API Security** - -El conector de Akamai API Security usa una clave de API para extraer hallazgos de seguridad desde la API de Akamai. DefectDojo descubrirá su entorno de Akamai y creará Registros independientes para cada **Application** y **Host** configurados en su cuenta. - -#### Prerrequisitos - -Necesitará una clave de API con acceso a la API de Akamai. Recomendamos crear una cuenta de servicio dedicada para DefectDojo, de modo que se distinga claramente la actividad automatizada de las acciones manuales del equipo. - -#### Asignaciones del conector - -1. Ingrese la URL base de la API de Akamai en el campo **Location**. Esta URL es específica de su instancia de Akamai: por ejemplo -2. Ingrese una **API Key** válida en el campo **Secret**. - -DefectDojo asignará las **Applications** y los **Hosts** como Registros independientes. Cada Application aparecerá como `{name} (application)` y cada Host como `{name} (host)` en su lista de Registros. - -## **Anchore** - -El conector de Anchore usa el token de API de un usuario para extraer datos de Anchore Enterprise. Los Productos se asignarán y descubrirán en función de las "Applications", que se componen de varias Images en Anchore - consulte la [documentación de Anchore Enterprise](https://docs.anchore.com/current/docs/sbom_management/application_groups/application_management_anchorectl/) para obtener más información. - -#### Asignaciones del conector - -1. La URL de Anchore en el campo **Location**: esta es la URL donde accede a Anchore. -2. Ingrese una API Key válida en el campo Secret. Esta es la clave de API asociada con su cuenta de servicio de Burp. - -Consulte la [documentación oficial de Anchore](https://docs.anchore.com/current/docs/) para obtener más información sobre cómo crear un token para Anchore. - -## **AWS Security Hub** - -El conector de AWS Security Hub usa una clave de acceso de AWS para interactuar con las API de Security Hub. - -#### Prerrequisitos - -En lugar de usar la clave de acceso de AWS de un miembro del equipo, recomendamos crear un IAM User en su cuenta de AWS específicamente para DefectDojo, con los permisos de ese usuario limitados a los necesarios para interactuar con Security Hub. - -La política "**[AWSSecurityHubReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubReadOnlyAccess.html)**" de AWS proporciona el nivel de acceso necesario para un conector. Si desea escribir una política personalizada para un Conector, deberá incluir los siguientes permisos: - -* [DescribeHub](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_DescribeHub.html) -* [GetFindingAggregator](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingAggregator.html) -* [GetFindings](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindings.html) -* [ListFindingAggregators](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_ListFindingAggregators.html) - -Una definición de política funcional podría verse de la siguiente manera: - -``` -{ - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "AWSSecurityHubConnectorPerms", - "Effect": "Allow", - "Action": [ - "securityhub:DescribeHub", - "securityhub:GetFindingAggregator", - "securityhub:GetFindings", - "securityhub:ListFindingAggregators" - ], - "Resource": "*" - } - ] -} -``` - -**Tenga en cuenta:** es posible que en el futuro necesitemos usar acciones de API adicionales para ofrecer la mejor experiencia posible, lo que requerirá actualizaciones de esta política. - -Una vez que haya creado su usuario de IAM y le haya asignado los permisos necesarios mediante una política/rol adecuado, deberá generar una clave de acceso, que luego podrá usar para crear un Conector. - -#### Asignaciones del conector - -1. Ingrese el [AWS API Endpoint correspondiente a su región](https://docs.aws.amazon.com/general/latest/gr/sechub.html#sechub_region) en el campo **Location****:** por ejemplo, para obtener resultados de la región `us-east-1`, debería usar - -`https://securityhub.us-east-1.amazonaws.com` -2. Ingrese una **AWS Access Key** válida en el campo **Access Key**. -3. Ingrese una **Secret Key** correspondiente en el campo **Secret Key**. - -DefectDojo puede extraer Hallazgos de más de una región mediante la función de **agregación entre regiones** de Security Hub. Si la [agregación entre regiones](https://docs.aws.amazon.com/securityhub/latest/userguide/finding-aggregation.html) está habilitada, debe proporcionar el endpoint de la API de su "**Aggregation Region**". Para las regiones adicionales vinculadas se crearán ProductRecords en DefectDojo según el ID de su cuenta de AWS y el nombre de la región. - -## **Azure DevOps** - -El conector de Azure DevOps es un **Conector de activos**: enumera los repositorios git de cada proyecto de su organización de Azure DevOps y crea un Activo de DefectDojo para cada repositorio, agrupados en Organizaciones según el proyecto de Azure DevOps. No se importa ningún hallazgo. - -#### Prerrequisitos - -Necesitará un Personal Access Token (PAT) para la organización. Recomendamos generar el token desde una cuenta de servicio dedicada. Solo se requieren ámbitos de lectura: - -1. En Azure DevOps, abra **User settings \> Personal access tokens \> New Token**. -2. Haga clic en **Show all scopes** y, a continuación, seleccione **Code: Read** y **Project and Team: Read**. - -Solo se admite Azure DevOps Services (dev.azure.com); actualmente no se admite Azure DevOps Server on-premise. - -#### Asignaciones del conector - -1. Ingrese la URL de su organización en el campo **Location**: `https://dev.azure.com/{your-organization}`. También se aceptan las URL heredadas `https://{your-organization}.visualstudio.com`, y cualquier segmento de ruta adicional (por ejemplo, un enlace a un proyecto específico) se ignora. -2. Ingrese el PAT en el campo **Secret**. - -Cada repositorio se convierte en un Registro con el nombre del repositorio, agrupado por su **proyecto** de Azure DevOps. Los repositorios deshabilitados se omiten, por lo que deshabilitar o eliminar un repositorio marca su Registro como `MISSING` en la siguiente Sync. - -## **Backstage** - -El conector de Backstage es un **conector de activos**: en lugar de importar Hallazgos, extrae su Software Catalog de [Backstage](https://backstage.io) hacia DefectDojo y mantiene sincronizada su jerarquía de Productos y la propiedad de los equipos con ella. Está diseñado para organizaciones que mantienen su inventario de servicios y su estructura organizativa en Backstage y desean que DefectDojo refleje esa estructura en lugar de mantenerla manualmente. - -#### Qué se asigna - -| Backstage | DefectDojo | -|---|---| -| **System** | Tipo de producto (los Components sin System se agrupan bajo un Tipo de producto configurable "Backstage / Uncategorized") | -| **Component** | Producto — con el nombre tomado de la entidad `title` (o de `name` si no existe), junto con la descripción del catálogo | -| **Owning Group** (relación `ownedBy`) | Un Grupo de DefectDojo vinculado al Producto (rol predeterminado: Maintainer, configurable) | -| **Owner email** (correo del perfil del Group, o correo del propietario User) | Un miembro del Producto, cuando ya existe un usuario de DefectDojo con ese correo (nunca se crean usuarios) | -| `metadata.tags`, `spec.type`, `spec.lifecycle`, namespace, domain | Etiquetas de Producto con el prefijo `backstage:` | -| `metadata.annotations` | Se almacena en el Registro (con límite); ciertas anotaciones seleccionadas pueden promoverse a atributos de primera clase o a etiquetas mediante **Annotation Mappings** | - -Los Registros se identifican mediante el `metadata.uid` asignado por el servidor de la entidad, por lo que los cambios de nombre en Backstage actualizan el Producto asignado **en el mismo lugar** en la siguiente sincronización — sin duplicados. El nombre del Producto siempre sigue al catálogo: para cambiar el nombre de un Producto gestionado por este conector, cambie el nombre del Component en Backstage (un cambio de nombre realizado del lado de DefectDojo, o un nombre personalizado asignado durante la asignación manual, se concilia con el nombre del catálogo en la siguiente sincronización a menos que colisione con otro Producto). Los cambios de propiedad mueven la asignación de grupo del Producto. Los Components que desaparecen del catálogo (o que están marcados con la anotación `backstage.io/orphan`) se marcan como **MISSING** — DefectDojo nunca elimina un Producto por sí mismo. La jerarquía de Domain y Group (equipos superiores) se registra únicamente como etiquetas/metadatos; no crea niveles de jerarquía adicionales. - -#### Prerrequisitos - -El conector se autentica con un **token de acceso externo estático** frente al backend de Backstage. En la configuración de su aplicación Backstage, defina un token y (recomendado) restríjalo al plugin de catálogo: - -```yaml -backend: - auth: - externalAccess: - - type: static - options: - token: ${DEFECTDOJO_BACKSTAGE_TOKEN} - subject: defectdojo-connector - accessRestrictions: - - plugin: catalog -``` - -Genere un token aleatorio robusto (por ejemplo `openssl rand -hex 32`) y guárdelo en el entorno de su implementación de Backstage. Consulte la [documentación de autenticación servicio a servicio de Backstage](https://backstage.io/docs/auth/service-to-service-auth) para obtener más detalles. - -#### Asignaciones del conector - -1. Ingrese la **URL raíz del backend de Backstage** en el campo **Location**: por ejemplo `https://backstage.example.com` (el conector añade `/api/catalog`). Debe ser la URL del **backend**, no la de la interfaz web frontend. -2. Ingrese el token de acceso externo estático en el campo **Secret**. - -Campos opcionales (déjelos en blanco para usar los valores predeterminados): - -* **Namespaces** — namespaces del catálogo a importar, separados por comas; en blanco se importan todos los namespaces. -* **Component Types** — valores de `spec.type` separados por comas (p. ej. `service,website`); en blanco se importan todos los tipos. -* **Page Size** — tamaño de página para las consultas al catálogo (1\-500, valor predeterminado 250). -* **TLS Verification** — establézcalo en `false` solo si Backstage sirve un certificado que DefectDojo no puede verificar (CA interna); no se recomienda. -* **Uncategorized Product Type** — el Tipo de producto usado para los Components sin System (valor predeterminado `Backstage / Uncategorized`). -* **Owner Group Role** — el rol otorgado al equipo propietario en los Productos asignados (valor predeterminado `Maintainer`). -* **Annotation Mappings** — un objeto JSON que asigna claves de anotación a nombres de atributos del Registro, o a `"tag"` para importar una anotación como etiqueta de Producto, p. ej. `{"github.com/project-slug": "GITHUB_PROJECT", "example.com/tier": "tag"}`. - -Con **Auto\-Map** habilitado, un único Discover \+ Sync genera toda la estructura de Tipo de producto / Producto / propiedad sin pasos manuales. Con Auto\-Map deshabilitado, los Components descubiertos aparecen como Registros a la espera de su decisión de asignación. - -#### Limitaciones (v1) - -* La **pertenencia a Group de Backstage no se sincroniza**: el conector crea/vincula el equipo propietario como un Grupo de DefectDojo, pero completar los usuarios de ese grupo queda a cargo de su proveedor de identidad o de los administradores. -* Solo los Components se convierten en Productos; las APIs, Resources y Domains no se importan como activos (los domains aparecen como etiquetas). -* Las etiquetas y anotaciones se normalizan y se limitan para ajustarse a los límites de campo de DefectDojo (los valores demasiado grandes se truncan). - -**Una nota sobre la dirección inversa:** mostrar los hallazgos y las calificaciones de DefectDojo *dentro* de Backstage (en las páginas de entidad) es una extensión natural que se implementaría como un plugin de frontend de Backstage que consume la REST API de DefectDojo — queda deliberadamente fuera del alcance de este conector, que solo extrae datos del catálogo hacia DefectDojo. - -## **Black Duck** - -El conector de Black Duck importa hallazgos de **análisis de composición de software (SCA)** desde una instancia de Black Duck Hub (Synopsys / Black Duck). DefectDojo descubre todos los proyectos de la instancia y crea un Registro para cada **proyecto**; los hallazgos de un proyecto provienen de los componentes de la BOM vulnerables de su versión seleccionada. - -#### Prerrequisitos - -Un **token de API** de Black Duck para un usuario que pueda ver los proyectos que desea importar. En Black Duck, abra el menú de usuario \> **My Access Tokens** \> **Create New Token**, otórguele (como mínimo) acceso de lectura y copie el token cuando se muestre — solo se exhibe una vez. El conector intercambia este token por un bearer de corta duración en cada sincronización; nunca se almacena en texto claro más allá del campo secreto del conector. - -#### Asignaciones del conector - -1. Ingrese la URL de su hub de Black Duck en el campo **Location** — por ejemplo `https://your-company.app.blackduck.com`. -2. Ingrese el token de API en el campo **Secret**. -3. Opcionalmente, configure una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada proyecto de Black Duck se convierte en un Registro. Por defecto el conector importa la versión **released** del proyecto (recurriendo a su primera versión si no existe); cada componente de la BOM vulnerable de esa versión se convierte en un hallazgo, titulado `{vulnerability} in {component}:{version}`. - -Este conector es distinto de los parsers de Black Duck basados en archivos — sus hallazgos usan el tipo de análisis dedicado **Black Duck - Connectors Import**. - -## **Bitbucket** - -El conector de Bitbucket es un **Conector de activos**: enumera los repositorios de los workspaces de Bitbucket Cloud que usted indique y crea un Activo de DefectDojo para cada repositorio, agrupados en Organizaciones según el proyecto de Bitbucket. No se importa ningún hallazgo. - -#### Prerrequisitos - -Bitbucket Cloud requiere un token de API de Atlassian **con ámbitos (scoped)** — los tokens de API de Atlassian clásicos (sin ámbitos) son rechazados por Bitbucket con un error "API Token provided has no Bitbucket scopes". - -1. Vaya a [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens) y elija **Create API token with scopes**. -2. Seleccione la aplicación **Bitbucket** y, a continuación, otorgue los ámbitos de lectura: `read:account:bitbucket`, `read:workspace:bitbucket`, `read:repository:bitbucket` y `read:project:bitbucket`. - -Solo se admite Bitbucket Cloud (bitbucket.org). Bitbucket Server llegó a su fin de vida en 2024, y Bitbucket Data Center no es compatible. - -#### Asignaciones del conector - -1. Ingrese `https://bitbucket.org` en el campo **Location**. -2. Ingrese el correo de la cuenta de Atlassian a la que pertenece el token en el campo **Email**. -3. Ingrese el token de API con ámbitos en el campo **Secret**. -4. Ingrese uno o más slugs de workspace (separados por comas) en el campo **Workspace Slugs**. Este campo es obligatorio: los tokens de API con ámbitos de Bitbucket no pueden listar workspaces automáticamente, por lo que hay que indicarle a DefectDojo qué workspaces leer. - -Cada repositorio se convierte en un Registro con el nombre del repositorio, agrupado por su **proyecto** de Bitbucket. - -## **Bugcrowd** - -El conector de Bugcrowd usa la REST API de Bugcrowd para importar submissions de sus programas de bug bounty y de divulgación de vulnerabilidades. DefectDojo descubre los programas a los que su token de API tiene acceso y crea un Registro para cada uno, importando las submissions de ese programa como hallazgos. - -#### Prerrequisitos - -Necesitará un **token de API** de Bugcrowd con acceso a los programas que desea importar. Recomendamos crear una cuenta de servicio dedicada para DefectDojo, de modo que la actividad automatizada se distinga fácilmente de las acciones manuales del equipo. Genere el token en Bugcrowd en **Organization settings \> API credentials**; basta con acceso de lectura a submissions, programs y targets. - -#### Asignaciones del conector - -1. Ingrese `https://api.bugcrowd.com` en el campo **Location**. -2. Ingrese su token de API de Bugcrowd en el campo **Secret**. Se envía como encabezado `Authorization: Token`. -3. Opcionalmente, configure una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada **program** de Bugcrowd se convierte en un Registro, y sus submissions se importan como hallazgos conservando la severidad de Bugcrowd. Las submissions duplicadas se excluyen, por lo que volver a importar no crea hallazgos repetidos para el mismo problema. - -## **Bright Security** - -El conector de Bright Security usa la API de [Bright](https://brightsec.com) (anteriormente NeuraLegion) para importar **hallazgos DAST**. DefectDojo descubre todos los scans a los que el token tiene acceso y crea un Registro para cada scan completado, e importa luego los issues de ese scan como hallazgos. - -#### Prerrequisitos - -Necesitará una **API key** de Bright, creada en la aplicación Bright en **User settings → API keys** (una clave `Org` o personal). La clave se envía en el encabezado `Authorization: Api-Key` y nunca se registra en logs. - -#### Asignaciones del conector - -1. Deje el campo **Location** en blanco para usar `https://app.brightsec.com`, o ingrese explícitamente su host de Bright. -2. Ingrese la API key de Bright en el campo **Secret**. -3. Opcionalmente, configure una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo asigna cada **scan** completado a un Registro y cada **issue** a un hallazgo: la severidad proviene de la propia calificación de Bright (Crítica/Alta/Media/Baja), se trasladan el puntaje CVSS, el CWE y la remediación, el punto de entrada afectado se convierte en el endpoint, y la evidencia de la solicitud/respuesta se incluye en la descripción. Los hallazgos se registran como hallazgos dinámicos y se deduplican según el id de issue de Bright. - -Consulte la [documentación de la API de Bright](https://docs.brightsec.com/) para obtener más información. - -## **BurpSuite** - -El conector de Burp de DefectDojo llama a la GraphQL API de Burp para obtener datos. - -#### Prerrequisitos - -Antes de configurar este conector, necesitará una clave de API de una Burp Service Account. Las cuentas de usuario de Burp no tienen claves de API de forma predeterminada, por lo que quizás deba crear un nuevo usuario específicamente para este fin. - -Consulte la [documentación de Burp](https://portswigger.net/burp/documentation/enterprise/user-guide/api-documentation/create-api-user) para obtener una guía sobre cómo configurar un usuario Service Account con una clave de API. - -#### Asignaciones del conector - -1. Ingrese la URL raíz de Burp en el campo **Location**: esta es la URL donde accede a la herramienta Burp. -2. Ingrese una API Key válida en el campo Secret. Esta es la clave de API asociada con su cuenta de Burp Service. - -Consulte la [documentación oficial de Burp](https://portswigger.net/burp/extensibility/enterprise/graphql-api/index.html) para obtener más información sobre la API de Burp. - -## **Censys** - -El conector de Censys lee activos de tipo host desde Censys Platform e importa los servicios expuestos de cada host como hallazgos. Usa la API de búsqueda global de Censys Platform para enumerar los hosts a los que lo delimite. - -#### Prerrequisitos - -Necesitará una cuenta de Censys **Platform** con acceso a la API: - -* Un **Personal Access Token**, creado en Censys Platform Console, en Personal Access Tokens. -* Su **Organization ID**, que se muestra en la misma página de configuración bajo "Current Organization". El acceso de la API al endpoint de búsqueda requiere una organización, por lo que se necesita un plan Starter o superior. Los tokens del plan gratuito no tienen Organization ID y no pueden usar la API de búsqueda. - -Los datos de CVE y riesgo por host solo están disponibles en los planes Censys Core (enterprise), por lo que en planes inferiores los hallazgos representan servicios expuestos en lugar de vulnerabilidades. - -Consulte la [documentación de la API de Censys Platform](https://docs.censys.com/reference/get-started) para obtener más información. - -#### Asignaciones del conector - -1. Ingrese `https://api.platform.censys.io` en el campo **Location**. -2. Ingrese su Personal Access Token en el campo **API Key**. -3. Ingrese su **Organization ID**. -4. Ingrese una **Search Query** que delimite la importación a sus propios activos, por ejemplo `host.autonomous_system.asn: ` o `host.ip: 203.0.113.0/24`. -5. Opcionalmente, configure una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo crea un Registro para cada host e importa sus servicios expuestos como hallazgos. - -## **Checkmarx ONE** - -El conector de Checkmarx ONE de DefectDojo llama a la API de Checkmarx para obtener datos. - -#### **Asignaciones del conector** - -1. Ingrese su **Tenant Name** en el campo **Checkmarx Tenant**. Este nombre debería ser visible en la página de inicio de sesión de Checkmarx ONE, en la esquina superior derecha: -" Tenant: \<**su nombre de tenant**\> " -​ -![imagen](images/connectors_tool_reference_2.png) - -2. Ingrese una clave de API válida. Es posible que deba generar una nueva: consulte la [documentación de la API de Checkmarx](https://docs.checkmarx.com/en/34965-68618-generating-an-api-key.html#UUID-f3b6481c-47f4-6cd8-9f0d-990896e36cd6_UUID-39ccc262-c7cb-5884-52ed-e1692a635e08) para obtener más detalles. -3. Ingrese la ubicación de su tenant en el campo **Location**. Esta URL tiene el siguiente formato: -​`https://.ast.checkmarx.net/` . Su Región se encuentra al comienzo de la URL de Checkmarx cuando usa la aplicación Checkmarx. **** es el servidor principal de EE. UU. (que no tiene prefijo de región). - -#### **Manejo de branches** - -Por defecto, cada sincronización importa los hallazgos del **único scan completado más reciente de un proyecto, sin importar el branch**. Si su CI escanea muchos branches, el branch que resulte haber escaneado en último lugar "gana" esa sincronización: los hallazgos que solo existen en otros branches no se importan, y la conciliación de cierre de antiguos de la sincronización puede hacer que los hallazgos se abran y cierren alternadamente a medida que distintos branches se turnan como el scan más reciente. - -Dos campos opcionales controlan este comportamiento: - -- **Branch**: fija cada proyecto a un único nombre de branch — solo se importan los scans de ese branch. Es un valor global único para todo el conector, por lo que se adapta a flotas donde cada proyecto usa el mismo branch de larga duración (p. ej. `main`). - - Se admite un **comodín `*`**. Un valor de Branch que contenga `*` selecciona *todos* los branches coincidentes en lugar de uno solo — por ejemplo `release/*` importa cada branch de release, y `*` coincide con todos los branches. Combinado con **Track Scanned Branches**, esta es la forma de rastrear una familia de branches sin rastrearlos todos. - - Si un comodín no coincide con **ningún** branch dentro de la ventana de escaneo, esa sincronización se **omite** en lugar de tratarse como "el branch no tiene hallazgos" — de este modo, un patrón que temporalmente no coincide con nada no puede cerrar todos los hallazgos del activo. -- **Track Scanned Branches**: cuando está habilitado, cada sincronización encuentra todos los branches con un scan completado en el historial reciente de scans del proyecto e importa **el scan completado más reciente de cada branch**, con una reimportación por branch. Los hallazgos de cada branch residen en su propio Compromiso en el activo asignado, llamado "\ \- \", por lo que el cierre de hallazgos obsoletos está delimitado por branch: una corrección fusionada en un branch nunca puede cerrar los hallazgos de otro branch. El branch principal del proyecto (según lo informado por Checkmarx) se importa primero, de modo que las reapariciones del mismo hallazgo en otros branches se deduplican contra el original del branch principal. - -Notas sobre **Track Scanned Branches**: - -- **Verifique qué valor predeterminado se aplica en su caso.** El seguimiento de branches está **habilitado por defecto para las instalaciones nuevas**. Las instalaciones anteriores al cambio conservan su comportamiento previo, por lo que la opción permanece deshabilitada para ellas hasta que alguien la active. -- Cuando ambos campos están configurados, solo se rastrea el **Branch** fijado — incluso cuando ese valor de Branch es un patrón comodín, en cuyo caso se rastrea cada branch que coincida con el patrón. -- Un branch que deja de escanearse (fusionado o eliminado) deja de recibir actualizaciones: su Compromiso permanece visible con sus últimos hallazgos conocidos, que puede revisar y cerrar en bloque. -- Deshabilitar la opción más adelante es seguro: los Compromisos por branch simplemente dejan de recibir importaciones y el Compromiso predeterminado se reanuda en la siguiente sincronización. -- Los Conectores concilian el estado según el programa de sincronización. El seguimiento de branches hace que cada sincronización sea completa entre branches; no hace que los datos sean en tiempo real entre sincronizaciones. - -## **Cloudflare** - -El conector de Cloudflare importa **Security Center insights** — problemas de postura de seguridad que Cloudflare identifica sobre su cuenta y sus zonas, como un registro DMARC faltante, DNSSEC no habilitado o un problema de certificado. DefectDojo crea un Registro para cada zona (dominio) que tenga insights abiertos, además de un Registro a nivel de cuenta para los insights que no están asociados a una zona específica. - -#### Prerrequisitos - -Necesitará un **API token** de Cloudflare (no la Global API Key heredada). Cree uno en **My Profile > API Tokens > Create Token** dentro del panel de Cloudflare. La opción más rápida es la plantilla **"Read all resources"**; para un token con privilegios mínimos, otorgue **Zone > Zone > Read** (todas las zonas) más acceso de lectura a nivel de cuenta para Security Center. - -#### Asignaciones del conector - -1. Ingrese `https://api.cloudflare.com/client/v4` en el campo **Location**. -2. Ingrese el API token en el campo **Secret**. -3. Opcionalmente, configure una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo autodescubre las cuentas y zonas a las que el token tiene acceso — no se requiere un ID de cuenta. Solo se importan los insights abiertos (activos, no descartados), por lo que los insights que resuelva o descarte en Cloudflare se marcan automáticamente como Mitigado en DefectDojo en la siguiente sincronización. - -## **Cobalt.io** - -El conector de Cobalt.io utiliza la API de Cobalt.io (v2) para extraer los hallazgos de pentest de su organización de Cobalt.io. DefectDojo detecta todas las organizaciones a las que su token de API tiene acceso y crea un Registro independiente para cada **activo** (la unidad que Cobalt somete a pentest). - -#### Requisitos previos - -Necesitará un **token de API personal** de Cobalt.io. Recomendamos crear una cuenta de servicio dedicada para DefectDojo, de modo que la actividad automatizada se distinga claramente de las acciones manuales del equipo. Genere un token desde **Settings \> API Tokens** en la interfaz de Cobalt.io. Los tokens de organización se detectan automáticamente \- no es necesario proporcionarlos. - -#### Asignaciones del conector - -1. Introduzca la URL base de la API de Cobalt.io en el campo **Location**: `https://api.cobalt.io` (o el host de su región, por ejemplo `https://api.us.cobalt.io`). -2. Introduzca su **token de API personal** en el campo **Secret**. -3. De forma opcional, introduzca un **Organization Token** para fijar la sincronización a una sola organización. Si se deja en blanco, DefectDojo sincroniza todas las organizaciones a las que el token de API personal tiene acceso. - -DefectDojo asigna cada **activo** de Cobalt.io como un Registro independiente. Los hallazgos se importan para cada activo asignado, y su estado en Cobalt.io (por ejemplo, `valid_fix`, `wont_fix`, `invalid`) determina el estado del hallazgo en DefectDojo. - -## **Contrast** - -El conector de Contrast utiliza la API REST de Contrast Assess para importar vulnerabilidades de aplicaciones. DefectDojo detecta las aplicaciones de su organización de Contrast y crea un Registro para cada una. - -#### Requisitos previos - -Necesitará cuatro valores de Contrast. Recomendamos crear una cuenta de servicio dedicada para que la actividad automatizada se distinga fácilmente de las acciones manuales de su equipo. En la interfaz de Contrast, en **User Settings > Profile > Your Keys**, encontrará: - -* La **API Key** de su organización. -* Su **Service Key** personal. -* El **username** al que pertenecen las credenciales (el correo electrónico de inicio de sesión de la cuenta). -* Su **Organization ID**: el UUID de la organización desde la que importar, que también se muestra en **Organization Settings**. - -#### Asignaciones del conector - -1. Introduzca la URL base que utiliza para acceder a Contrast en el campo **Location**; para el producto alojado, suele ser `https://app.contrastsecurity.com` (o la URL de su Team Server regional o autoalojado). -2. Introduzca el correo electrónico de inicio de sesión de la cuenta en el campo **Username**. -3. Introduzca la **API Key** de la organización en el campo **API Key**. -4. Introduzca la **Service Key** personal en el campo **Service Key**. -5. Introduzca el **Organization ID** (UUID) en el campo **Organization ID**. -6. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada aplicación de Contrast se convierte en un Registro, y sus vulnerabilidades se importan como hallazgos. - -## **Coverity** - -El conector de Coverity importa hallazgos desde un servidor **Coverity Connect**. DefectDojo crea un Registro para cada **proyecto** de Coverity. - -#### Asignaciones del conector - -1. Introduzca la URL de su servidor Coverity Connect en el campo **Location**. -2. Introduzca el **username** de Coverity Connect en el campo **Username**. -3. Introduzca la contraseña o la clave de autenticación del usuario en el campo **Secret**. -4. De forma opcional, defina un **View Name** para seleccionar qué vista de incidencias guardada lee el conector. Déjelo en blanco para usar la opción predeterminada, **Outstanding Issues**. -5. De forma opcional, defina **Import All Issue Kinds** en `true` para ampliar la importación más allá del filtro predeterminado de incidencias de Security y Quality (`RESOURCE_LEAK`). - -## **CrowdStrike Falcon** - -El conector de CrowdStrike Falcon importa **vulnerabilidades de Spotlight** y **detecciones de EDR** de la plataforma Falcon, como dos tipos de hallazgo independientes (`CrowdStrike:Spotlight` y `CrowdStrike:Detections`). DefectDojo crea un Registro para cada **host** de Falcon. - -#### Requisitos previos - -Un **API client** de Falcon (Client ID y secret), creado en la consola de Falcon en **Support \> API Clients and Keys**. Otórguele los scopes correspondientes a los datos que desea importar: **Hosts: Read** (obligatorio, para la detección de hosts), **Vulnerabilities (Spotlight): Read** (para los hallazgos de Spotlight) y **Alerts: Read** (para las detecciones de EDR). Los dos tipos de hallazgo son independientes: si al cliente le falta un scope, ese tipo de hallazgo se omite en lugar de hacer fallar la sincronización, por lo que un cliente sin **Alerts: Read** sigue importando las vulnerabilidades de Spotlight. - -#### Asignaciones del conector - -1. Introduzca la URL base de la API de su nube de Falcon en el campo **Location**, según la región de su consola; por ejemplo, `https://api.crowdstrike.com` (US\-1), `https://api.us-2.crowdstrike.com` (US\-2), `https://api.eu-1.crowdstrike.com` (EU\-1) o `https://api.laggar.gcw.crowdstrike.com` (US\-GOV\-1). -2. Introduzca el Client ID del API client en el campo **Client ID**. -3. Introduzca el secret del API client en el campo **Client Secret**. -4. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada host de Falcon se convierte en un Registro, nombrado según su hostname, sistema operativo y tipo. Solo se importan las vulnerabilidades de Spotlight **open** y **reopened**, por lo que una nueva importación cierra los hallazgos ya remediados. - -## **Deepfence ThreatMapper** - -El conector de Deepfence ThreatMapper utiliza la API REST de la consola de administración de [ThreatMapper](https://github.com/deepfence/ThreatMapper) para importar resultados de **escaneos de vulnerabilidades**. DefectDojo detecta todos los nodos que ThreatMapper ha escaneado (una imagen de contenedor, un host o un contenedor) y crea un Registro para cada uno; a continuación, importa como hallazgos el escaneo completado más reciente de ese nodo. - -#### Requisitos previos - -Necesitará un **API token** de ThreatMapper, disponible en la consola en **Settings → User Management** (la clave de API de su usuario). El conector lo intercambia por un token de acceso de corta duración en cada sincronización; el API token nunca se registra en los logs. - -#### Asignaciones del conector - -1. Introduzca la URL de la consola de ThreatMapper en el campo **Location** (por ejemplo, `https://threatmapper.example.com`). -2. En el campo **Secret**, introduzca el API token de ThreatMapper. -3. Si su consola utiliza un certificado autofirmado, defina **Skip TLS Verification** en `true`. -4. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo asigna cada **nodo** escaneado a un Registro y cada **CVE** de su escaneo de vulnerabilidades completado más reciente a un hallazgo. La severidad proviene de la propia calificación de ThreatMapper, y se trasladan el paquete afectado, la puntuación CVSS, la versión de corrección (como mitigación), los enlaces de referencia y un bloque de detalles. Los hallazgos se registran como hallazgos dinámicos y se deduplican según el nodo, el CVE, el paquete y la ruta del paquete. - -Consulte la [documentación de ThreatMapper](https://community.deepfence.io/threatmapper/docs/v2.5/) para obtener más información. - -## Dependency\-Track - -Este conector obtiene datos de una instancia on\-premise de Dependency\-Track mediante la API REST. - -​**Asignaciones del conector** - -1. Introduzca la URL de su servidor local de Dependency\-Track en el campo **Location**. -2. Introduzca una clave de API válida en el campo **Secret**. - -Para generar una clave de API de Dependency\-Track: - -1. **Access Management**: navegue hasta Administration \> Access Management \> Teams en la interfaz de Dependency\-Track. -2. **Teams Setup**: puede crear un nuevo equipo o seleccionar uno existente. Los equipos permiten gestionar el acceso a la API según la pertenencia al grupo. -3. **Generate API Key**: en la página de detalles del equipo seleccionado, busque la sección "API Keys". Haga clic en el botón \+ para generar una nueva clave de API. -4. **Assign Permissions**: en la sección "Permissions" de la página del equipo, haga clic en el botón \+ para abrir el selector de permisos. Elija los permisos **VIEW\_PORTFOLIO** y **VIEW\_VULNERABILITY** para habilitar el acceso mediante API a los portafolios de proyectos y a los detalles de vulnerabilidades. -5. Haga clic en "**Select**" para confirmar y guardar estos permisos. - -Para obtener más información, consulte la **[documentación de Dependency\-Track](https://docs.dependencytrack.org/integrations/rest-api/)**. - -## **Docker Scout** - -El conector de Docker Scout utiliza la API del exportador de métricas de Docker Scout para informar sobre la postura de vulnerabilidades de las imágenes de su organización. DefectDojo detecta cada stream de Docker Scout (sus entornos de ejecución) e importa un resumen de las vulnerabilidades y el cumplimiento de políticas de cada uno. - -#### Requisitos previos - -Necesitará un personal access token de Docker creado por un **owner** de una organización de Docker que esté **inscrita en Docker Scout**. El exportador de métricas es una función a nivel de organización, por lo que una cuenta personal, o una organización no inscrita en Docker Scout, no devolverá datos. - -Cree el token desde la configuración de su cuenta de Docker, en **Personal access tokens**, y anote el **organization namespace** de Docker, que también necesitará. - -#### Asignaciones del conector - -1. Introduzca `https://api.scout.docker.com` en el campo **Location**. -2. Introduzca su personal access token de Docker en el campo **Secret**. -3. Introduzca su namespace de **Organization** de Docker. -4. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importarán. - -DefectDojo crea un Registro independiente para cada stream de Docker Scout, e importa un hallazgo por severidad para las vulnerabilidades que Docker Scout contabiliza en ese stream, además de un hallazgo por cada imagen que incumple su política de Docker Scout. La API de métricas de Docker Scout informa recuentos agregados en lugar de CVE individuales, por lo que estos hallazgos resumen la postura de un stream. Abra el stream en Docker Scout para ver el detalle por imagen y por CVE. - -Consulte la [documentación de Docker Scout](https://docs.docker.com/scout/) para obtener más información. - -## **Endor Labs** - -El conector de Endor Labs utiliza la API REST de Endor Labs para sincronizar un **namespace** completo de Endor Labs. DefectDojo detecta cada **proyecto** de Endor como un Registro e importa los hallazgos de ese proyecto, trasladando el veredicto de **accesibilidad** de Endor para que pueda priorizar las vulnerabilidades cuyo código afectado sea realmente accesible. - -#### Requisitos previos - -Necesitará una **API key** de Endor Labs (un identificador de clave más su secret) y el **namespace** que desea sincronizar. Cree la clave en la plataforma de Endor Labs en **Settings \> Access \> API Keys**; la clave necesita acceso de lectura a los proyectos y hallazgos de ese namespace. - -El conector se autentica intercambiando la API key y el secret por un bearer token de corta duración; el secret se utiliza únicamente para ese intercambio y nunca se almacena en texto plano. - -#### Asignaciones del conector - -1. Introduzca `https://api.endorlabs.com` en el campo **Location**. Si su tenant está alojado en una región distinta, utilice en su lugar la URL base de la API de esa región. -2. Introduzca el **Namespace** de Endor Labs que desea sincronizar (por ejemplo `your-org` o `your-org.team`). -3. Introduzca el identificador de **API Key**. -4. Introduzca el **API Secret** asociado a la clave. -5. De forma opcional, defina **Traverse Child Namespaces** en `true` para importar también los hallazgos de los namespaces hijos del namespace configurado. -6. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importan. - -DefectDojo crea un Registro para cada proyecto de Endor Labs del namespace e importa sus hallazgos, asignando los niveles de severidad de Endor a las severidades de DefectDojo, los identificadores CVE/GHSA y la puntuación CVSS de cada vulnerabilidad, y las etiquetas de accesibilidad de Endor. El veredicto de accesibilidad (por ejemplo, *Reachable — vulnerable function is called* o *Unreachable*) se muestra como el Impact del hallazgo y como una etiqueta. - -Para obtener más información, consulte la **[documentación de la API REST de Endor Labs](https://docs.endorlabs.com/rest-api/)**. - -## **Edgescan** - -El conector de Edgescan utiliza la API REST de Edgescan para importar las vulnerabilidades abiertas de toda su cuenta de Edgescan. DefectDojo enumera todos los **activos** de Edgescan y crea un Registro para cada uno; a continuación, importa las vulnerabilidades abiertas de ese activo como hallazgos. No existe configuración por activo. - -#### Requisitos previos - -Necesitará un token de API de Edgescan. Créelo desde su cuenta de Edgescan en **Account settings \> API tokens**: introduzca una etiqueta, haga clic en **Create** y copie el token generado (solo se muestra una vez). Recomendamos una cuenta dedicada para el conector, de modo que la actividad automatizada se distinga fácilmente. - -#### Asignaciones del conector - -1. Introduzca su URL de Edgescan en el campo **Location**: `https://live.edgescan.com` para la plataforma alojada estándar, o el host de su tenant si es distinto. -2. Introduzca su token de API de Edgescan en el campo **Secret**. Se envía en el encabezado `X-API-TOKEN`. -3. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada activo de Edgescan se convierte en un Registro, y cada vulnerabilidad abierta de ese activo se importa como un hallazgo. La severidad se asigna desde la escala numérica de Edgescan (1–5) a la escala Informativa–Crítica de DefectDojo, e incluye las referencias CVE, el CWE y un vector CVSS v3 cuando Edgescan los proporciona. - -## **Escape** - -El conector de Escape utiliza la API de [Escape](https://escape.tech) para importar **hallazgos de seguridad de API (DAST)**. DefectDojo enumera todas las organizaciones a las que el token tiene acceso y todas las aplicaciones de cada una, crea un Registro para cada aplicación que tenga un escaneo, e importa como hallazgos las incidencias del escaneo más reciente de esa aplicación. No existe configuración por aplicación. - -#### Requisitos previos - -Necesitará una **API key** de Escape, creada en la aplicación de Escape en **Settings → API keys**. La clave se envía en el encabezado `Authorization: Key` y nunca se registra en los logs. - -#### Asignaciones del conector - -1. Deje el campo **Location** en blanco para usar `https://public.escape.tech/v2`, o introduzca explícitamente el host de la API de Escape. -2. Introduzca la clave de API de Escape en el campo **Secret**. -3. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo asigna cada **aplicación** a un Registro y cada **issue** del escaneo a un hallazgo: la severidad proviene de la calificación de Escape (Crítica/Alta/Media/Baja), se traslada el CWE, la categoría OWASP y el método HTTP se convierten en etiquetas, la URL afectada se convierte en el endpoint, y se incluye la guía de remediación. Los hallazgos se registran como hallazgos dinámicos y se deduplican según el id de la issue de Escape. - -Consulte la [documentación de la API de Escape](https://docs.escape.tech/) para obtener más información. - -## **Fairwinds Insights** - -El conector de Fairwinds Insights utiliza la API REST de [Fairwinds Insights](https://insights.fairwinds.com) para importar **hallazgos de seguridad de Kubernetes** de toda su organización. DefectDojo enumera todos los **clusters** activos y crea un Registro para cada uno; a continuación, importa como hallazgos los **action items** de seguridad de ese cluster \(de Polaris, Trivy, Kube\-bench, OPA y los demás informes de Insights\). No existe configuración por cluster. - -#### Requisitos previos - -Necesitará un nombre de **organización** de Fairwinds Insights y un **API token**. Cree el token en la aplicación de Insights en **Organization Settings \> Tokens**; basta con un token `read_only`. El token tiene alcance de organización y se envía como bearer token; nunca se registra en los logs. - -#### Asignaciones del conector - -1. Deje el campo **Location** en blanco para usar `https://insights.fairwinds.com`, o introduzca explícitamente el host de Insights. -2. Introduzca el nombre de **Organization** de Insights (el slug que aparece en la URL de su panel). -3. Introduzca el token de API de Insights en el campo **Secret**. -4. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo asigna cada **cluster** activo a un Registro y cada **action item** de Security a un hallazgo: la severidad proviene de la puntuación numérica de Fairwinds \(asignada a la escala Informativa–Crítica de DefectDojo\), el informe de Fairwinds que generó el elemento \(`polaris`, `trivy`, `kube-bench`, ...\) se convierte en una etiqueta de herramienta, se incluyen el recurso de Kubernetes afectado y la imagen del contenedor, y se extraen los identificadores CVE si los hay. Los hallazgos se registran como hallazgos estáticos y se deduplican según el id del action item de Fairwinds. - -Consulte la [documentación de la API de Fairwinds Insights](https://insights.docs.fairwinds.com/technical-details/api/) para obtener más información. - -## **Fortify** - -El conector de Fortify importa resultados SAST/DAST de Fortify (OpenText/Micro Focus), abarcando las dos ediciones que comparten la plataforma: **SSC** (Software Security Center, autoalojado) y **Fortify on Demand (FoD)** (SaaS). Sincroniza toda la cuenta: DefectDojo detecta todas las aplicaciones (project version de SSC / release de FoD) y crea un Registro para cada una; a continuación, importa las incidencias de esa aplicación como hallazgos. - -#### Requisitos previos - -- **SSC**: un **FortifyToken**; créelo en la interfaz de SSC en **Administration → Token Management** (un CIToken/UnifiedLoginToken). -- **FoD**: una **OAuth2 API key**; un Client ID y un Client Secret desde **Settings → API** (con el scope `api-tenant`). - -El token y el secret de OAuth nunca se registran en los logs. - -#### Asignaciones del conector - -1. Introduzca la URL base de Fortify en el campo **Location**: para SSC, el host de su servidor (el conector añade `/ssc/api/v1`); para FoD, el host de la API de su región, por ejemplo, `https://api.ams.fortify.com`. -2. Defina **Edition** en `SSC` o `FoD`. -3. Para **FoD**, introduzca el **Client ID** de OAuth; déjelo en blanco para SSC. -4. En **Token / Client Secret**, introduzca el FortifyToken de SSC o el client secret de OAuth de FoD. -5. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo asigna cada **aplicación** de Fortify a un Registro y cada **issue** a un hallazgo: la severidad proviene de la propia calificación de **friority** de Fortify (Crítica/Alta/Media/Baja), el título combina la categoría de la incidencia con su archivo y línea, y se trasladan la ruta del archivo, la línea, el kingdom, el analizador y el tipo de motor. Las incidencias de los motores de análisis estático (SCA) se registran como hallazgos estáticos y las incidencias de WebInspect (DAST) como hallazgos dinámicos; las incidencias suprimidas, eliminadas u ocultas se omiten, las incidencias auditadas como "Not an Issue" se marcan como falso positivo, y las incidencias "Exploitable" o revisadas se marcan como verificadas. - -Consulte la documentación de la API de [Fortify SSC](https://www.microfocus.com/documentation/fortify-software-security-center/) y de [Fortify on Demand](https://api.ams.fortify.com/swagger/ui) para obtener más información. - -## **GitGuardian** - -El conector de GitGuardian utiliza la API REST de GitGuardian para importar **incidentes de secretos**: credenciales expuestas que GitGuardian ha detectado en sus fuentes monitorizadas. DefectDojo crea un Registro para cada fuente monitorizada (repositorio o perímetro) que actualmente tenga incidentes abiertos, e importa cada incidente abierto como un hallazgo. - -Por su seguridad, el conector importa únicamente los **metadatos** del incidente: el detector, la severidad, la validez, el estado y un enlace de vuelta a GitGuardian. El propio valor del secreto expuesto nunca se recupera ni se almacena en DefectDojo; siga el enlace de cada hallazgo para revisar las ubicaciones afectadas en GitGuardian. - -#### Requisitos previos - -Necesitará una clave de API de GitGuardian. Recomendamos un **Service Account token** (en lugar de un personal access token) para que la actividad automatizada se distinga fácilmente. Créelo en **API** en el panel de GitGuardian y otorgue estos scopes de lectura: - -* `incidents:read` -* `sources:read` - -#### Asignaciones del conector - -1. Introduzca la URL de la API de GitGuardian en el campo **Location**: `https://api.gitguardian.com` para la plataforma SaaS, o la URL de la API de su instancia autoalojada. -2. Introduzca la clave de API en el campo **Secret**. - -Solo se importan los incidentes **open** (con estado `TRIGGERED` o `ASSIGNED`); los incidentes que resuelva o ignore en GitGuardian se mitigan automáticamente en DefectDojo en la siguiente sincronización. Un secreto confirmado como activo (validez *valid*) se importa como un hallazgo verificado. - -## **GitHub** - -El conector de GitHub es un **Asset Connector**: enumera los repositorios a los que su token tiene acceso y crea un Activo de DefectDojo para cada uno, agrupados en Organizaciones según el propietario de GitHub (organización o usuario). No se importa ningún hallazgo. - -**Tenga en cuenta:** este conector importa únicamente el **inventario** de sus repositorios. Para importar las alertas de seguridad de GitHub (code scanning, Dependabot y secret scanning) como hallazgos, utilice el conector independiente **GitHub Advanced Security** que se describe más adelante. Ambos son independientes y pueden ejecutarse juntos. - -#### Requisitos previos - -El conector se autentica con un **personal access token** de GitHub y solo lee los **metadatos** del repositorio (nombre, descripción, URL y propietario); no accede a su código, incidencias ni alertas de seguridad. Importa todos los repositorios que la cuenta del token posee, en los que colabora, o de cuya organización es miembro, así que confirme que la cuenta del token puede ver los repositorios que desea reflejar. Recomendamos una cuenta de servicio dedicada. - -El token solo necesita acceso de solo lectura a los metadatos del repositorio: - -- Un token *fine-grained* necesita **Repository permissions → Metadata: Read-only**, otorgado a los repositorios (o a toda la organización) que desea importar. -- Un token *classic* necesita el scope **`repo`** para incluir repositorios privados (use **`public_repo`** si solo necesita los públicos), además de **`read:org`** para que se resuelvan los repositorios propiedad de la organización. - -Solo se admite GitHub.com (incluido GitHub Enterprise Cloud). GitHub Enterprise **Server** no está soportado actualmente por este conector. - -#### Asignaciones del conector - -1. Introduzca `https://api.github.com` en el campo **Location**. -2. Introduzca el personal access token en el campo **Secret**. - -No es necesario introducir ninguna lista de organizaciones ni de repositorios: DefectDojo importa todos los repositorios que el token puede ver. Cada repositorio se convierte en un Registro con el nombre del repositorio, agrupado por su **owner** de GitHub (organización o usuario). Si un repositorio se elimina más adelante, o el token pierde el acceso a él, su Registro asignado se marca como `MISSING` en la siguiente sincronización en lugar de eliminarse: DefectDojo nunca elimina un Producto de forma silenciosa. - -## **GitHub Advanced Security** - -El conector de GitHub Advanced Security importa alertas de **code scanning**, **Dependabot** y **secret scanning** de GitHub, como tres tipos de hallazgo independientes (`GitHub:CodeScanning`, `GitHub:Dependabot` y `GitHub:SecretScanning`). DefectDojo detecta todos los repositorios no archivados de la organización configurada y crea un Registro para cada uno. - -#### Requisitos previos - -Las funciones de GitHub Advanced Security deben estar habilitadas en los repositorios que desea importar. El conector se autentica con un **personal access token** de GitHub: - -1. En GitHub, abra **Settings \> Developer settings \> Personal access tokens** y cree un token propiedad de (o con acceso a) la organización de destino. -2. Otórguele acceso de lectura a las alertas de seguridad: un token *fine\-grained* necesita acceso **Read\-only** a **Code scanning alerts**, **Dependabot alerts** y **Secret scanning alerts** en los repositorios de la organización; un token *classic* necesita los scopes **`repo`** y **`security_events`**. -3. Confirme que el propietario del token puede ver los repositorios que pretende importar: el conector solo ve los repositorios a los que el token tiene acceso. - -#### Asignaciones del conector - -1. Introduzca `https://api.github.com` en el campo **Location**. Para GitHub Enterprise Server, utilice `https:///api/v3`. -2. Introduzca el login de la organización en el campo **Organization**. -3. Introduzca el personal access token en el campo **Secret**. -4. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada repositorio no archivado se convierte en un Registro, consultado en las tres familias de alertas en busca de alertas abiertas. Una familia de alertas que no esté habilitada para un repositorio se omite en lugar de reportarse como resuelta, de modo que las funciones deshabilitadas no provocan cierres falsos. - -## **GitLab** - -El conector de GitLab es un **Asset Connector**: enumera todos los proyectos (repositorios) a los que su token tiene acceso y crea un Activo de DefectDojo para cada uno, agrupados en Organizaciones según el namespace de GitLab (grupo o usuario). No se importa ningún hallazgo. - -#### Requisitos previos - -Necesitará un Personal Access Token con el scope **read_api**. Recomendamos crear el token desde una cuenta de servicio dedicada; el conector enumera los proyectos de los que esa cuenta es miembro. - -#### Asignaciones del conector - -1. Introduzca su URL de GitLab en el campo **Location**: `https://gitlab.com`, o la URL base de su instancia autoalojada. -2. Introduzca el Personal Access Token en el campo **Secret**. - -Cada proyecto se convierte en un Registro con el nombre del proyecto, agrupado por su **namespace**. Los proyectos pendientes de eliminación en GitLab (eliminados por un usuario, pero aún no purgados por el trabajo en segundo plano de GitLab) se excluyen automáticamente, de modo que eliminar un proyecto marca su Registro como `MISSING` en la siguiente sincronización en lugar de dejar un activo fantasma renombrado. - -## **Google Cloud Security Command Center** - -El conector de Google Cloud SCC utiliza la API REST v2 de Security Command Center para importar los hallazgos de seguridad activos de su organización, carpeta o proyecto de Google Cloud. DefectDojo crea un Registro para cada **proyecto** de Google Cloud que tenga hallazgos abiertos. - -#### Requisitos previos - -Security Command Center debe estar **activado** en su organización (el nivel Standard es gratuito). A continuación, necesitará una cuenta de servicio que pueda listar hallazgos, y una clave JSON para ella: - -1. En Google Cloud, cree una cuenta de servicio; se recomienda una dedicada para DefectDojo. -2. Otórguele el rol **Security Center Findings Viewer** (`roles/securitycenter.findingsViewer`) en el alcance que desea importar (organización, carpeta o proyecto). -3. Cree una **clave JSON** para la cuenta de servicio y descárguela. - -#### Asignaciones del conector - -1. Deje el campo **Location** con el valor predeterminado `https://securitycenter.googleapis.com`, salvo que utilice un endpoint no estándar. -2. En el campo **Parent Resource**, introduzca el alcance desde el que importar: `organizations/{id}`, `folders/{id}` o `projects/{id}`. -3. Pegue el contenido completo del archivo de **clave JSON** de la cuenta de servicio en el campo **Service Account Key**. -4. De forma opcional, defina una **Minimum Severity** para limitar qué hallazgos se importan. - -Solo se importan los hallazgos `ACTIVE` y no silenciados, por lo que los hallazgos que desactive o silencie en SCC se mitigan automáticamente en DefectDojo en la siguiente sincronización. El proyecto de GCP afectado de cada hallazgo se convierte en su Registro. - -## **Group-IB ASM** - -El conector Group-IB ASM (Attack Surface Management) usa la API REST de Group-IB ASM para importar a DefectDojo **incidencias** (hallazgos) de superficie de ataque externa. DefectDojo detecta cada **empresa/tenant** de Group-IB como un Registro independiente e importa las incidencias de esa empresa de forma programada e incremental. El activo al que se refiere cada incidencia (un dominio, una IP o una URL) se adjunta al hallazgo resultante como un **Endpoint**. - -#### Requisitos previos - -Necesitará su inicio de sesión de Group-IB ASM y una clave de API. Recomendamos crear una cuenta de servicio dedicada para DefectDojo, de modo que la actividad automatizada pueda distinguirse de las acciones manuales del equipo. - -Para generar una clave de API: - -1. Abra Group-IB Attack Surface Management, haga clic en **Help** en la esquina inferior izquierda y seleccione **API**. -2. Haga clic en **Generate API Key** (arriba a la derecha, debajo de su nombre de usuario). -3. Introduzca su contraseña de SSO y haga clic en **Next**, luego haga clic en **Copy token**. -4. Guarde la clave en un gestor de secretos y planifique su rotación periódica. - -#### Asignaciones del conector - -Group-IB ASM se autentica mediante HTTP Basic Auth, donde el nombre de usuario es su inicio de sesión de ASM y la contraseña es su clave de API. **Se requieren ambos valores**: la clave de API por sí sola no es suficiente. - -1. Introduzca `https://asm.group-ib.com` en el campo **Location**. Es el mismo para todos los tenants de Group-IB ASM. -2. Introduzca su inicio de sesión de ASM (normalmente una dirección de correo electrónico) en el campo **Username**. -3. Introduzca su clave de API en el campo **API Key** (Secret). -4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importan. - -DefectDojo asigna cada **empresa** de Group-IB como un Registro independiente, usando el ID de la empresa como identificador. En la primera Sincronización, DefectDojo recupera el historial reciente de incidencias; las Sincronizaciones posteriores son incrementales y solo obtienen las incidencias modificadas desde la última Sincronización (según la marca de tiempo `lastSeen` más reciente de cada incidencia). - -#### Limitar a una sola empresa (opcional) - -De forma predeterminada, el conector detecta automáticamente las empresas disponibles para sus credenciales de API (mediante el endpoint `clients` de ASM) y crea un Registro por empresa. Esta es la configuración recomendada y no requiere configuración adicional. - -Si el endpoint `clients` no está disponible para su tenant — por ejemplo, cuando está restringido a cuentas de socios/MSP —, el conector puede limitarse a una sola empresa proporcionando su **ID de empresa** como campo específico de la herramienta `company_id` en la configuración del conector. Cuando se establece `company_id`, DefectDojo usa esa empresa directamente en lugar de enumerar las empresas. Déjelo sin establecer para usar la detección automática. - -Consulte el manual de la API REST de Group-IB ASM (disponible en el propio producto en **Help → API**) para obtener más información. - -## **HackerOne** - -El conector HackerOne usa la API REST de HackerOne para importar reportes de su programa de recompensas por errores (bug bounty) o de divulgación de vulnerabilidades. DefectDojo crea un Registro para cada programa al que el token pueda acceder e importa sus reportes como hallazgos. - -#### Requisitos previos - -El conector usa la API **customer** de HackerOne, que requiere un **token de API de la organización**; un token personal de la configuración de su usuario solo funciona con la API de hacker y no se autenticará aquí. - -1. En HackerOne, vaya a **Organization Settings > API Tokens**. -2. Cree un token y anote tanto el **identifier** como el valor del **token**. El acceso de lectura al programa es suficiente. - -#### Asignaciones del conector - -1. Introduzca `https://api.hackerone.com` en el campo **Location**. -2. Introduzca el **identifier** del token en el campo **API Token Identifier**. -3. Introduzca el valor del token en el campo **API Token**. -4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada programa se convierte en un Registro, y sus reportes se importan como hallazgos conservando la calificación de severidad de HackerOne. - -## **Harbor** - -El conector Harbor usa la API REST v2.0 de Harbor para importar vulnerabilidades de imágenes de contenedor de todo su registro. DefectDojo enumera cada **proyecto** de Harbor y crea un Registro para cada uno, luego recorre los repositorios y artefactos del proyecto e importa las vulnerabilidades de cada artefacto **escaneado** — incorporando la imagen (repositorio + etiqueta/digest) como contexto del hallazgo. No existe configuración por imagen. - -#### Requisitos previos - -Necesitará una cuenta de Harbor (o una **cuenta robot**) con acceso de extracción/lectura a los proyectos que desea importar. Recomendamos una cuenta robot dedicada: en Harbor, abra un proyecto (o **Administration > Robot Accounts** para un robot de sistema), cree un robot con el permiso **pull** sobre repositorios y artefactos, y copie su nombre completo y su secreto. Los nombres de robot comienzan con `robot$` de forma predeterminada, pero el prefijo es configurable por instancia de Harbor (algunas usan `robot_`) — copie el nombre exactamente como lo muestra Harbor. Un nombre de usuario y contraseña normales también funcionan. - -#### Asignaciones del conector - -1. Introduzca su URL de Harbor en el campo **Location** — por ejemplo `https://harbor.example.com`. DefectDojo añade automáticamente la ruta de la API `/api/v2.0`. -2. Introduzca el nombre de usuario de Harbor, o el nombre de una cuenta robot exactamente como lo muestra Harbor (`robot$` de forma predeterminada), en el campo **Username**. -3. Introduzca la contraseña o el secreto de la cuenta robot en el campo **Secret**. Se envía mediante autenticación HTTP Basic. -4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada proyecto de Harbor se convierte en un Registro. Para cada artefacto que tenga un escaneo completado, sus vulnerabilidades se importan como hallazgos; se incluyen el paquete/versión afectados, una severidad derivada de CVSS, el CVE, el CWE y una corrección (versión reparada) cuando Harbor los proporciona. Solo se importan los artefactos escaneados — active un escaneo en Harbor para las imágenes que aún no se hayan escaneado. - -## **Have I Been Pwned** - -El conector Have I Been Pwned (HIBP) usa la API REST de HIBP para informar de qué cuentas de los dominios propios de su organización han aparecido en filtraciones de datos conocidas. DefectDojo detecta cada dominio que haya verificado con HIBP e importa un hallazgo por cada filtración que afecte a ese dominio. - -#### Requisitos previos - -Necesitará una clave de API de Have I Been Pwned con búsqueda de dominio, lo que requiere un nivel de suscripción **Core** o superior. Puede obtener una clave desde su [cuenta de Have I Been Pwned](https://haveibeenpwned.com/API/Key). - -También debe **verificar al menos un dominio** en su cuenta de HIBP antes de que haya datos de filtraciones disponibles. HIBP permite verificar un dominio mediante registro TXT de DNS, metaetiqueta, carga de archivo o correo electrónico, en **Domain search** dentro de su cuenta. Hasta que un dominio esté verificado, el conector no detecta ningún dominio y no importa ningún hallazgo. - -#### Asignaciones del conector - -1. Introduzca `https://haveibeenpwned.com` en el campo **Location**. -2. Introduzca su clave de API en el campo **Secret**. -3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importarán. - -DefectDojo crea un Registro independiente para cada dominio que haya verificado con HIBP, e importa un hallazgo por cada filtración que afecte a las cuentas de ese dominio. La severidad de cada hallazgo refleja el tipo de datos que expuso la filtración, y su descripción enumera las cuentas afectadas de su dominio para que su equipo pueda actuar sobre ellas. - -Consulte la [documentación de la API de Have I Been Pwned](https://haveibeenpwned.com/API/v3) para obtener más información. - -## **HCL AppScan** - -El conector HCL AppScan usa la API REST v4 de AppScan para importar incidencias de **AppScan on Cloud (ASoC)** o de una instancia autoalojada de **AppScan 360°** (ambas comparten la API). Sincroniza toda la cuenta: DefectDojo detecta todas las aplicaciones y crea un Registro para cada una, y luego importa las incidencias de esa aplicación (DAST, SAST e IAST) como hallazgos. - -#### Requisitos previos - -Necesitará una **API key** de AppScan — un Key ID y un Key Secret generados en la configuración de su cuenta de AppScan (API Key). El conector los intercambia por un token de sesión de corta duración en cada ejecución; el Key ID, el Key Secret y el token nunca se registran en los logs. - -#### Asignaciones del conector - -1. Introduzca la URL de la consola de AppScan en el campo **Location**: para ASoC use `https://cloud.appscan.com` (o `https://eu.cloud.appscan.com` para la región de la UE); para AppScan 360° use el host de su instancia. -2. Establezca **Provider** en `ASOC` para AppScan on Cloud, o en `A360` para una instancia autoalojada de AppScan 360°. -3. Introduzca el **API Key ID** y el **API Key Secret**. -4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo asigna cada **aplicación** de AppScan a un Registro (VEP) y cada **incidencia** a un hallazgo: el título es el tipo de incidencia con su dominio/entidad/cause-id/URL/ruta añadidos; la severidad asigna Informational a Info (Low/Medium/High/Critical se transfieren sin cambios); se incluyen el CWE, una descripción etiquetada, la corrección y el aviso, y el endpoint de host/puerto. Las incidencias de análisis estático se registran como hallazgos estáticos y las incidencias dinámicas/interactivas como hallazgos dinámicos; las incidencias abiertas quedan activas y las corregidas/aprobadas quedan mitigadas. - -Consulte la [documentación de la API REST de AppScan](https://help.hcl-software.com/appscan/ASoC/appseccloud_rest_apis.html) para obtener más información. - -## **Intigriti** - -El conector Intigriti usa la API externa de empresa de Intigriti para importar **envíos** de bug bounty / pentest a DefectDojo. Sincroniza toda la cuenta de la empresa: DefectDojo detecta todos los programas a los que el token puede acceder y crea un Registro para cada uno, luego importa los envíos de ese programa como hallazgos. - -#### Requisitos previos - -Necesitará un **token de API de empresa** de Intigriti. En el portal de empresa de Intigriti, en **Company Settings > API** (el ámbito `company_external_api`), genere un token de acceso con acceso de lectura a sus programas y envíos. Se recomienda un token dedicado para DefectDojo. El token se envía como Bearer token y nunca se registra en los logs. - -#### Asignaciones del conector - -1. Introduzca la URL base de la API externa de empresa de Intigriti en el campo **Location**: `https://api.intigriti.com/external/company`. La URL debe ser HTTPS. -2. Introduzca el token de API de empresa en el campo **Secret**. -3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo asigna cada **programa** de Intigriti a un Registro y cada **envío** a un hallazgo, identificado por el código del envío. La severidad del hallazgo sigue la calificación de Intigriti (Exceptional/Critical → Crítica, luego Alta/Media/Baja, o en caso contrario Informational), y el estado del ciclo de vida del envío se asigna al estado del hallazgo: los envíos open/triage están activos, los envíos accepted están verificados, y los envíos closed pasan a ser duplicado, fuera de alcance, falso positivo o riesgo aceptado según su motivo de cierre. La descripción del hallazgo incluye el tipo de vulnerabilidad del reporte, el activo afectado, la prueba de concepto y las respuestas del investigador. - -Consulte la [documentación de la API de Intigriti](https://kb.intigriti.com/en/articles/6117846-intigriti-api) para obtener más información. - -## **Intruder** - -El conector Intruder usa la [API REST de Intruder](https://developers.intruder.io/) para importar la postura de toda su cuenta a DefectDojo. Cada **destino** de Intruder se detecta como un Registro (Producto); cada **aparición** de una incidencia en un destino se convierte en un Hallazgo. - -#### Asignaciones del conector - -1. Deje el campo **Location** como `https://api.intruder.io/` (el servidor de API predeterminado de Intruder). -2. Introduzca un **token de acceso de API** de Intruder en el campo **Secret**. - -Genere un token de acceso en Intruder en **My account > API Access Tokens** (necesitará la contraseña de su cuenta para crearlo, y el token solo se muestra una vez). Consulte la [documentación de la API de Intruder](https://developers.intruder.io/docs/creating-an-access-token) para más detalles. - -Los hallazgos se derivan por aparición: la severidad proviene de la severidad de la incidencia, los CVE y CVSS de la aparición, la ubicación del destino/puerto, y una aparición en estado "snoozed" se importa como un hallazgo inactivo (falso positivo o riesgo aceptado). - -## **IriusRisk** - -El conector IriusRisk usa un token de API para importar datos de modelado de amenazas desde su instancia de IriusRisk. - -#### Requisitos previos - -Necesitará un token de API de su cuenta de IriusRisk. Recomendamos crear una cuenta de servicio dedicada para DefectDojo, de modo que se distinga claramente la actividad automatizada de las acciones manuales del equipo. - -Para generar un token de API en IriusRisk: - -1. Inicie sesión en su instancia de IriusRisk. -2. Vaya a su **User Profile** en el menú superior derecho. -3. Seleccione **API Token** y genere un nuevo token. - -Consulte la [documentación de la API de IriusRisk](https://support.iriusrisk.com/hc/en-us/categories/360001148511) para obtener más información. - -#### Asignaciones del conector - -1. Introduzca la URL de su instancia de IriusRisk en el campo **Location URL**. Para instancias alojadas en la nube, suele ser `https://{your-subdomain}.iriusrisk.com`. Para instalaciones locales, use la URL base de su instancia. -2. Introduzca su **API Token** en el campo **Secret**. -3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importarán. - -## **JFrog Xray** - -El conector JFrog Xray usa la API REST de JFrog Xray para obtener datos de vulnerabilidades de sus repositorios de Artifactory. DefectDojo detectará todos los repositorios de su instancia de JFrog y generará informes de vulnerabilidades mediante Xray, importando hallazgos de forma programada. - -#### Requisitos previos - -Necesitará un token de API con acceso tanto a la API de Artifactory como a la de Xray. Recomendamos crear una cuenta de servicio dedicada para DefectDojo. La cuenta requiere: - -* Acceso de lectura a los repositorios de Artifactory -* Permiso para generar y ver informes de vulnerabilidades de Xray (permiso `Apply on Watches` en Xray, o equivalente) - -#### Asignaciones del conector - -1. Introduzca la URL base de su instancia de JFrog en el campo **Location**. Debe ser la URL raíz de su instancia de JFrog, por ejemplo `https://your-instance.jfrog.io`. No incluya una ruta final — DefectDojo construirá automáticamente las rutas de API correspondientes. -2. Introduzca un **Reference Token** válido en el campo **Secret**. Los tokens se pueden generar en **User Management > Access Tokens** en la interfaz de JFrog Platform. -Deberá generar un **Reference Token** y usar ese valor. - -Ámbitos de token necesarios para JFrog Xray: - -- **All Services**, ya que DefectDojo necesita acceso tanto a los servicios de XRay como de Artifactory -- **Manage Reports + Manage Resources** como mínimo. - -De forma predeterminada, DefectDojo asigna cada **repositorio** de Artifactory como un Registro independiente. Cada Sincronización genera un informe de vulnerabilidades completo por repositorio mediante Xray, de modo que los estados de los hallazgos en DefectDojo siempre reflejan el estado actual del repositorio. - -#### Filtro de repositorio (opcional) - -De forma predeterminada, el conector detecta **todos** los repositorios de su instancia de JFrog. En instancias con un gran número de repositorios — muchos de los cuales pueden no ser relevantes para la revisión de seguridad —, la detección se puede limitar con el campo opcional **Repository Filter**, en **Import Filters** en el formulario del conector. - -El filtro se aplica durante la detección, **antes de realizar cualquier trabajo por repositorio**. Un repositorio fuera del filtro no tiene ningún coste: no se genera ningún informe de Xray para él y, en el modo de artefactos, no se enumera ninguno de sus artefactos de primer nivel. Esto lo convierte en la forma más eficaz de reducir tanto el tiempo de Sincronización como la carga que DefectDojo impone a su instancia de JFrog — más que cualquier ajuste aplicado más adelante en la Sincronización. Se recomienda especialmente junto con **Artifact-Level Records** en instancias grandes. - -**Sintaxis:** una lista de claves de repositorio separadas por comas. Cada entrada puede usar comodines `*`: - -* Una entrada que contenga `*` se compara como un patrón — `releases-*` coincide con toda clave de repositorio que comience por `releases-`, y `*docker-pr-local*` coincide con cualquier clave que contenga `docker-pr-local`. Un `*` coincide con cualquier secuencia de caracteres, incluido `/`. -* Una entrada sin `*` debe coincidir **exactamente** con una clave de repositorio. -* Un repositorio se detecta si coincide con **cualquier** entrada de la lista. Los espacios alrededor de las comas se ignoran. - -``` -releases-*, snapshots -``` - -El ejemplo anterior detecta todos los repositorios cuya clave comience por `releases-`, más el único repositorio llamado exactamente `snapshots`. - -Notas: - -* El filtro es una **lista de permitidos** (allow-list) — una coincidencia selecciona un repositorio. No existe sintaxis de exclusión o negación, por lo que no se puede expresar directamente "todo excepto X". -* La comparación es **sensible a mayúsculas y minúsculas**, tanto para entradas exactas como para comodines. `*` es el único carácter comodín; `?` y los rangos de caracteres no son compatibles. -* **Déjelo en blanco para detectar todos los repositorios.** Un valor que solo contiene espacios o comas se trata como en blanco. -* Un filtro que no coincide con nada simplemente no detecta nada — no se produce ningún error. Si una Sincronización no encuentra repositorios inesperadamente, revise el log del conector en busca de la entrada `repository filter scoped discovery`, que indica cuántos de los repositorios totales coincidieron. -* El campo se puede modificar después de crear la conexión. - -**Cambiar el filtro más adelante:** los repositorios que un filtro recién restringido ya no incluye dejan de detectarse, y sus Registros existentes siguen el ciclo de vida normal de los productos que la herramienta ya no reporta — los Registros **mapeados** se marcan como `MISSING` en la siguiente Sincronización, y los Registros `NEW` sin mapear se eliminan. Los hallazgos ya importados en DefectDojo no se eliminan; el filtro solo rige la detección. - -#### Registros a nivel de artefacto - -El interruptor **Artifact-Level Records** cambia la detección a un nivel por debajo del repositorio: cada entrada de primer nivel bajo la raíz de un repositorio (para repositorios Docker, cada imagen; para repositorios genéricos, cada archivo o carpeta de nivel superior) se convierte en su propio Registro. Cada Sincronización sigue generando un único informe de Xray por repositorio — DefectDojo atribuye cada vulnerabilidad a los artefactos a los que afecta, de modo que la carga sobre su instancia de JFrog no aumenta. - -> **Compruebe en qué modo se encuentra antes de su primera Sincronización.** Artifact-Level Records está **activado de forma predeterminada para las instalaciones nuevas**. Las instalaciones anteriores a esta función conservan su diseño existente a nivel de repositorio, por lo que el interruptor permanece desactivado hasta que alguien lo active. En ambos casos, el interruptor se puede cambiar en cualquier momento — consulte *Cambiar una conexión existente* más abajo. - -Con Artifact-Level Records habilitado: - -* Los repositorios permanecen como Registros y se convierten en **activos principales**: no contienen hallazgos propios, pero cuando la función Asset Hierarchy está habilitada, DefectDojo relaciona automáticamente cada activo de artefacto con su activo de repositorio mediante una relación `parent`. Los activos se pueden filtrar entonces por elemento principal/secundario, y los hallazgos se propagan hacia arriba en la jerarquía. -* Una vulnerabilidad que afecta a varios artefactos se importa en el activo de cada artefacto afectado, de modo que cada activo muestra el conjunto completo de hallazgos que le afectan. -* Los hallazgos se limitan a la **última build** de cada artefacto, de modo que los hallazgos de un artefacto describen su build actual en lugar de acumular resultados de todas las builds que Xray haya escaneado alguna vez. -* Las relaciones jerárquicas creadas por el conector nunca sobrescriben las relaciones que usted haya creado manualmente. Si un activo ya tiene un elemento principal asignado, el conector lo deja tal cual. -* El token necesita además acceso de lectura a la API de almacenamiento de Artifactory (incluido en los ámbitos anteriores). - -**Cambiar una conexión existente a Artifact-Level Records:** el interruptor se puede cambiar en cualquier momento. En la primera Sincronización posterior, aparecen nuevos Registros de artefactos para mapear — habilite **Auto Map** en la conexión al cambiar el interruptor para que los hallazgos se muevan sin interrupción. Los activos a nivel de repositorio dejan de recibir hallazgos y sus hallazgos importados previamente se cierran en su siguiente Sincronización (los mismos hallazgos se vuelven a importar bajo los nuevos activos de artefacto, con un estado nuevo); las notas y el historial de los hallazgos antiguos a nivel de repositorio permanecen en el activo de repositorio. Volver al modo anterior invierte esto: los Registros de repositorio vuelven a recibir hallazgos (los hallazgos previamente cerrados se reabren al volver a coincidir), y los Registros de artefacto se marcan como MISSING — sus activos y hallazgos se conservan pero dejan de actualizarse, por lo que puede archivarlos cuando le convenga. - -Consulte la [documentación de la API REST de JFrog Xray](https://jfrog.com/help/r/jfrog-rest-apis/xray-rest-apis) para obtener más información. - -## **Jira Service Management Assets** - -El conector JSM Assets es un **conector de activos**: enumera los objetos de su espacio de trabajo de Jira Service Management Assets (anteriormente Insight) y crea un Activo de DefectDojo para cada objeto, agrupados en Organizaciones según el esquema del objeto. No se importa ningún hallazgo. - -#### Requisitos previos - -* Assets requiere un plan **Jira Service Management Premium o Enterprise**. En los planes Free o Standard, la API de Assets responde con `403 "Access to Assets API was denied"`, aunque el resto del sitio funcione con normalidad. -* La cuenta de Atlassian utilizada debe tener **acceso de producto a Jira Service Management** (una plaza de agente) en el sitio — el acceso al sitio por sí solo no es suficiente. -* Cree un token de API clásico de Atlassian en [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens). Recomendamos una cuenta de servicio dedicada. - -#### Asignaciones del conector - -1. Introduzca la URL de su sitio de Atlassian en el campo **Location**: `https://{your-site}.atlassian.net`. -2. Introduzca el correo electrónico de la cuenta de Atlassian al que pertenece el token en el campo **Email**. -3. Introduzca el token de API en el campo **Secret**. - -Cada objeto de Assets se convierte en un Registro con el nombre de la etiqueta del objeto, agrupado por su **esquema de objeto**. - -## **Kubescape** - -El conector Kubescape lee los resultados de postura (configuraciones incorrectas) de Kubernetes generados por el [operador de Kubescape](https://kubescape.io/docs/install-operator/) directamente desde la API de Kubernetes del clúster — no se requiere ninguna cuenta SaaS de ARMO. Lee los objetos `WorkloadConfigurationScan` que expone la API agregada de almacenamiento dentro del clúster del operador (`spdx.softwarecomposition.kubescape.io/v1beta1`). Cada **namespace** de Kubernetes que tiene resultados de postura se asigna a un Registro (Producto); cada control fallido de una carga de trabajo se convierte en un Hallazgo. - -#### Requisitos previos - -- El operador de Kubescape debe estar instalado en el clúster de destino con el escaneo de configuración habilitado (consulte [Instalación en su clúster](https://kubescape.io/docs/install-operator/)). Confirme que existen resultados con `kubectl get workloadconfigurationscans -A`. -- Un **kubeconfig** que otorgue acceso de lectura al grupo de API `spdx.softwarecomposition.kubescape.io` (list/get sobre `workloadconfigurationscans`) para el clúster de destino. - -#### Asignaciones del conector - -1. Introduzca la URL del servidor de API del clúster (o un identificador descriptivo del clúster) en el campo **Location**. -2. Pegue el **kubeconfig** del clúster de destino en el campo `kubeconfig`. Opcionalmente, establezca `kube_context` para seleccionar un contexto dentro de él, y `cluster_name` para etiquetar los Productos detectados. -3. Cada namespace con resultados de postura se detecta como un Registro; mapee los que desee importar a Productos de DefectDojo. - -Los hallazgos se derivan por control fallido: el nombre del control y la carga de trabajo identifican el Hallazgo, la severidad proviene del factor de puntuación del control, el ID del control se convierte en el ID de vulnerabilidad, y cada Hallazgo enlaza con su referencia de control en `https://hub.armosec.io/docs/`. - -## **Mend** - -El conector Mend (anteriormente **WhiteSource**) usa la API de Mend para importar hallazgos de seguridad de su organización de Mend. DefectDojo crea un Registro para cada **proyecto** de Mend. - -#### Requisitos previos - -Necesitará un usuario (de servicio) de Mend con una **User Key** (un token de acceso personal) y su **Organization UUID** de Mend. Recomendamos una cuenta de servicio dedicada para que la actividad automatizada sea fácil de distinguir de las acciones manuales del equipo. Encuentre el Organization UUID en la aplicación Mend en **Administration > Organization UUID**. - -#### Asignaciones del conector - -1. Introduzca la URL de la API de Mend en el campo **Location**. Esta URL es **específica de la región** — use la URL base de la API de la región donde está alojada su organización de Mend. -2. Introduzca el correo electrónico de inicio de sesión del usuario de Mend en el campo **Email**. -3. Introduzca su **Organization UUID** de Mend en el campo **Organization UUID**. -4. Introduzca la **User Key** de Mend en el campo **User Key**. -5. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -## **Lacework / FortiCNAPP** - -El conector Lacework / FortiCNAPP usa la API v2 de Lacework para importar **vulnerabilidades de hosts y contenedores** de toda su cuenta de Lacework. - -#### Requisitos previos - -Necesitará una **API key** de Lacework — un ID de clave de API y un secreto, creados en la consola de Lacework en **Settings → API keys**. El conector los intercambia por un token de acceso de corta duración en cada sincronización; el ID de clave, el secreto y el token nunca se registran en los logs. - -#### Asignaciones del conector - -1. Introduzca la URL de su cuenta de Lacework en el campo **Location** — por ejemplo `https://YOUR-ACCOUNT.lacework.net` (también se acepta un nombre de cuenta simple). -2. Introduzca el **API Key ID** y el **API Secret**. -3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo asigna la **cuenta** de Lacework a un Registro (el ámbito de toda la cuenta). Cada vulnerabilidad de **contenedor** y de **host** se convierte en un hallazgo: la severidad proviene de la propia calificación de Lacework, el paquete y la versión afectados se convierten en el componente, la versión de corrección se convierte en la mitigación, y la imagen/host afectado se registra como etiquetas. Las vulnerabilidades de contenedor se registran como hallazgos estáticos (escaneos de imagen) y las vulnerabilidades de host como hallazgos dinámicos (escaneos de host en ejecución). - -Consulte la [documentación de la API de Lacework](https://docs.lacework.net/api/v2/docs) para obtener más información. - -## **Microsoft Defender** - -El conector de Microsoft Defender importa hallazgos de vulnerabilidades de dispositivos desde **Microsoft Defender Vulnerability Management (MDVM)** — un hallazgo por cada combinación de dispositivo / versión de software / CVE, incluyendo severidad, puntuación CVSS, nivel de explotabilidad y las actualizaciones de seguridad recomendadas. DefectDojo descubrirá los **grupos de dispositivos** de Defender y creará un Record para cada uno; los dispositivos que no estén asignados a ningún grupo de dispositivos se agrupan bajo un grupo sintético llamado **Unassigned**. - -**Tenga en cuenta:** este conector es distinto del tipo de escaneo basado en archivos **"MSDefender Parser"**, que importa archivos de Defender exportados manualmente. Elija una única vía de importación por Producto para evitar hallazgos duplicados. - -#### Requisitos previos - -Su tenant de Microsoft necesita una licencia activa que incluya las API de exportación de vulnerabilidades de Defender: **Defender for Endpoint Plan 2**, **Microsoft Defender Vulnerability Management Standalone**, o MDE P1/P2 con el add-on de MDVM. (El SKU *Add-on* de MDVM por sí solo no es suficiente: requiere tener Defender for Endpoint Plan 2 como base.) - -El conector se autentica como un **registro de aplicación (app registration)** de Microsoft Entra ID mediante el flujo de credenciales de cliente. Para crear uno: - -1. En el [portal de Azure](https://portal.azure.com), abra **App registrations > New registration**. Asígnele un nombre (por ejemplo, `defectdojo-connector`), deje los valores predeterminados y seleccione **Register**. -2. En la página **Overview** de la aplicación, anote el **Application (client) ID** y el **Directory (tenant) ID**. -3. Abra **API permissions > Add a permission > APIs my organization uses** y busque **WindowsDefenderATP**. Si no aparece, el backend de Defender de su tenant aún no se ha aprovisionado: asegúrese de que la licencia esté activa, abra [security.microsoft.com](https://security.microsoft.com) una vez y vuelva a intentarlo pasados unos minutos. -4. Elija **Application permissions** (*no* Delegated: los permisos delegados nunca aparecen en el token de servicio del conector), expanda **Vulnerability**, marque **Vulnerability.Read.All** y seleccione **Add permissions**. -5. Seleccione **Grant admin consent** y confirme. La columna Status debe mostrar una marca verde: sin este paso, cada llamada a la API devuelve un error 403. -6. Abra **Certificates & secrets > New client secret**, establezca una fecha de caducidad y copie el **Value** del secreto de inmediato (solo se muestra una vez). El conector deja de funcionar cuando el secreto caduca, así que anote la fecha. - -#### Asignaciones del conector - -1. Ingrese `https://api.security.microsoft.com` en el campo **Location**. -2. Ingrese el **Directory (tenant) ID** en el campo **Tenant ID**. -3. Ingrese el **Application (client) ID** en el campo **Client ID**. -4. Ingrese el valor del secreto de cliente en el campo **Client Secret**. -5. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada grupo de dispositivos de Defender se convierte en un Record. Microsoft regenera la instantánea de vulnerabilidades que lee el conector aproximadamente cada 6 horas, y los dispositivos recién incorporados pueden tardar hasta ~24 horas en producir sus primeros datos de vulnerabilidad: es normal que un tenant recién creado sincronice (Sync) cero hallazgos hasta que los dispositivos se incorporen y evalúen. La propia activación de la licencia también puede tardar ~20 minutos o más en propagarse a la API (los errores "No active license found" durante ese período se resuelven por sí solos). - -## **Microsoft Defender for Cloud** - -El conector de Microsoft Defender for Cloud importa hallazgos de vulnerabilidades de **Microsoft Defender Vulnerability Management (MDVM)** tal como los expone Defender for Cloud, tanto hallazgos de **servidor** (CVEs del sistema operativo y del software instalado en VM de Azure) como hallazgos de **registro de contenedores** (CVEs de imágenes de contenedor), incluyendo severidad, puntuación CVSS, el paquete o la imagen afectados y la remediación. DefectDojo descubre las **suscripciones** de Azure que su entidad de servicio (service principal) puede leer y crea un Record por cada suscripción habilitada. - -**Tenga en cuenta:** este conector es distinto del conector **Microsoft Defender**, que importa hallazgos de dispositivos desde la API de Defender for Endpoint. Defender for Cloud es un producto de Azure con una superficie de API diferente (Azure Resource Manager / Resource Graph) y un modelo de permisos diferente (Azure RBAC). Ejecute el que corresponda según dónde residan sus hallazgos, o ambos si usa los dos productos. - -#### Requisitos previos - -Necesita una o más **suscripciones de Azure con Microsoft Defender for Cloud habilitado**, con los planes de Defender pertinentes activados para los recursos que desea escanear (en **Microsoft Defender for Cloud > Environment settings**, y luego seleccione su suscripción): - -* **Defender for Servers (Plan 2)**: hallazgos de CVE del sistema operativo y del software de VM de Azure (escaneo de vulnerabilidades sin agente). -* **Defender for Containers**: hallazgos de CVE de imágenes del registro de contenedores. - -Los hallazgos de evaluación de vulnerabilidades de SQL y de configuración/postura **no** se importan intencionalmente: este conector solo importa vulnerabilidades CVE. - -El conector se autentica como un **registro de aplicación (app registration)** de Microsoft Entra ID mediante el flujo de credenciales de cliente: - -1. En el [portal de Azure](https://portal.azure.com), abra **App registrations > New registration**. Asígnele un nombre (por ejemplo, `defectdojo-connector`), deje los valores predeterminados y seleccione **Register**. -2. En la página **Overview** de la aplicación, anote el **Application (client) ID** y el **Directory (tenant) ID**. -3. Abra **Certificates & secrets > New client secret**, establezca una fecha de caducidad y copie el **Value** del secreto de inmediato (solo se muestra una vez). El conector deja de funcionar cuando el secreto caduca, así que anote la fecha. -4. Otorgue a la aplicación acceso de lectura a cada suscripción que desee importar: abra **Subscriptions**, seleccione su suscripción y luego **Access control (IAM) > Add > Add role assignment**. Seleccione el rol **Security Reader** (o **Reader**) y, en la pestaña **Members**, asígnelo a la aplicación que creó; búsquela por el **nombre** o el **object ID** de la aplicación, ya que el selector no coincide con el client ID. Repita esto para cada suscripción. - -A diferencia del conector Microsoft Defender basado en dispositivos, no se requieren permisos de API ni consentimiento de administrador: el acceso a Defender for Cloud se rige completamente por la asignación de rol de Azure RBAC descrita arriba. - -#### Asignaciones del conector - -1. Ingrese `https://management.azure.com` en el campo **Location**. (Para nubes soberanas, use el endpoint de ARM correspondiente, por ejemplo `https://management.usgovcloudapi.net`.) -2. Ingrese el **Directory (tenant) ID** en el campo **Tenant ID**. -3. Ingrese el **Application (client) ID** en el campo **Client ID**. -4. Ingrese el valor del secreto de cliente en el campo **Client Secret**. -5. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada suscripción de Azure habilitada se convierte en un Record. Los hallazgos se leen a través de Azure Resource Graph, por lo que aparecen con rapidez una vez que Defender for Cloud ha escaneado sus recursos, pero los escaneos en sí se ejecutan según la programación de Microsoft: las imágenes del registro de contenedores suelen escanearse dentro de la hora siguiente a su carga (push), mientras que el primer escaneo de vulnerabilidades sin agente de una VM puede tardar varias horas. Es normal que una suscripción recién habilitada sincronice (Sync) cero hallazgos hasta que se hayan escaneado sus recursos. - -## **MobSF** - -El conector de MobSF usa la API REST de [Mobile Security Framework (MobSF)](https://github.com/MobSF/Mobile-Security-Framework-MobSF) para importar resultados de análisis estático de aplicaciones móviles (APK/IPA). DefectDojo descubre cada app que se ha escaneado en su instancia de MobSF y crea un Record para cada una, y luego importa los hallazgos de análisis estático de esa app. - -#### Requisitos previos - -Necesitará su **REST API key** de MobSF. Encuéntrela en la página de inicio de MobSF, en **API** (también se muestra en la documentación de MobSF como el valor `Authorization`). La clave se envía en cada solicitud y nunca se registra en los logs. - -#### Asignaciones del conector - -1. Ingrese la URL base de MobSF en el campo **Location** (por ejemplo, `https://mobsf.example.com`). -2. En el campo **Secret**, ingrese la REST API key de MobSF. -3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo asigna cada **app** escaneada a un Record e importa sus hallazgos del informe JSON de MobSF en varias secciones: permisos de la aplicación, análisis de código, el certificado de firma, el manifiesto de Android, el uso de la API de Android y el análisis binario. Cada hallazgo se etiqueta con **CWE 919** (móvil), y su severidad proviene de la propia calificación de MobSF (high, warning, info, secure/good); un permiso *dangerous* se trata como Alta. Los hallazgos se registran como hallazgos estáticos y se deduplican por el scan, la sección, el título, la severidad y la ruta del archivo. - -Consulte la [documentación de la API REST de MobSF](https://mobsf.github.io/docs/#/rest_api) para más información. - -## **NeuVector** - -El conector de NeuVector usa la API REST del controlador de [NeuVector](https://github.com/neuvector/neuvector) para importar **escaneos de vulnerabilidades de imágenes** de contenedor. DefectDojo descubre cada imagen que NeuVector ha escaneado y crea un Record para cada una, y luego importa el informe de escaneo de esa imagen como hallazgos. - -#### Requisitos previos - -Necesitará un **nombre de usuario y contraseña** de NeuVector para una cuenta del controlador con permiso para leer los resultados de los escaneos. El conector inicia sesión con estas credenciales para obtener un token de sesión; la contraseña y el token nunca se registran en los logs. - -#### Asignaciones del conector - -1. Ingrese la URL del controlador de NeuVector en el campo **Location**, incluyendo el puerto de la API REST; por ejemplo, `https://neuvector.example.com:10443`. -2. Ingrese el **Username** y **Password** del controlador. -3. Si su controlador usa un certificado autofirmado, establezca **Skip TLS Verification** en `true`. -4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo asigna cada **imagen** escaneada a un Record y cada **CVE** de su informe de escaneo a un hallazgo. La severidad proviene de la propia calificación de NeuVector, y se trasladan el paquete y la versión afectados, la puntuación y el vector CVSSv3, la versión de corrección (como mitigación) y el enlace de referencia. Los hallazgos se deduplican por la imagen, el CVE, el paquete, la versión y la severidad. - -Consulte la [documentación de la API de NeuVector](https://open-docs.neuvector.com/automation/automation) para más información. - -## **Nuclei (ProjectDiscovery Cloud)** - -El conector de Nuclei usa la API REST de ProjectDiscovery Cloud Platform (PDCP) para obtener resultados de escaneo de [nuclei](https://github.com/projectdiscovery/nuclei) desde su cuenta de PDCP. DefectDojo descubre cada escaneo de la cuenta y crea un Record independiente para cada **escaneo**. - -#### Requisitos previos - -Necesitará una **API key** de ProjectDiscovery Cloud. Recomendamos crear una cuenta de servicio dedicada para DefectDojo, de modo que la actividad automatizada se distinga claramente de las acciones manuales del equipo. Genere una clave desde **Settings > API Key** en la interfaz de ProjectDiscovery Cloud ([cloud.projectdiscovery.io](https://cloud.projectdiscovery.io)). Los resultados llegan a PDCP ya sea desde escaneos alojados (hosted) o desde la CLI de nuclei ejecutada con `-dashboard`. - -#### Asignaciones del conector - -1. Ingrese la URL base de la API de PDCP en el campo **Location**: `https://api.projectdiscovery.io`. -2. Ingrese su **API key** en el campo **Secret**. -3. Opcionalmente, ingrese un **Team ID** para limitar la sincronización a un espacio de trabajo de equipo (se encuentra en **Settings > Team**). Si se deja en blanco, DefectDojo sincroniza su espacio de trabajo personal. -4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo asigna cada **escaneo** de PDCP como un Record independiente e importa los hallazgos de ese escaneo en todas las severidades, incluida la informativa. - -## **OpenVAS / Greenbone** - -El conector de OpenVAS / Greenbone importa **hallazgos de vulnerabilidades de red** desde una instancia de Greenbone (Greenbone Community Edition o Greenbone Enterprise). Se comunica con `gvmd` mediante **GMP (Greenbone Management Protocol)** —un protocolo XML sobre un socket TLS, no HTTP— y sincroniza toda la instancia: enumera las **tareas (tasks)** de escaneo y crea un producto de DefectDojo para cada una, importando los resultados del informe más reciente de cada tarea. - -#### Requisitos previos - -Un **usuario GMP** de Greenbone (nombre de usuario + contraseña) y acceso de red al puerto TLS de GMP de gvmd (por defecto **9390**). El stack de compose de Greenbone Community Edition expone gvmd a través de un socket unix, así que para alcanzarlo desde un conector conectado en red debe ejecutar el conector donde pueda acceder al socket, o exponer el puerto TLS de GMP (por ejemplo, un puente TLS con `socat` hacia `gvmd.sock`). - -#### Asignaciones del conector - -1. Ingrese el host de gvmd en el campo **Location** (host o `host:port`). -2. Ingrese el **Username** y **Password** de GMP. -3. Opcionalmente, establezca el **GMP Port** (por defecto 9390). -4. Para el certificado autofirmado predeterminado de gvmd, proporcione un **CA Certificate (PEM)** contra el cual verificar, o bien establezca **Skip TLS Verification** en `true`. -5. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada tarea de Greenbone se convierte en un Record. Los hallazgos provienen del informe finalizado más reciente de la tarea, uno por cada ``. La severidad se toma del nivel de amenaza (threat level) del resultado (los niveles informativos `Log`/`Debug` de Greenbone se asignan a Informativa), y se registra la puntuación CVSS numérica; las referencias CVE se convierten en identificadores de vulnerabilidad, la solución del NVT se convierte en la mitigación, y el host/puerto de cada resultado se convierte en un endpoint. - -## Probely - -Este conector usa la API REST de Probely para obtener datos. - -​**Asignaciones del conector** - -1. Ingrese la dirección del servidor de API correspondiente en el campo **Location**. (ya sea o ) -2. Ingrese una API key válida en el campo **Secret**. - -Puede encontrar una API key en el menú User > API Keys de Probely. -Consulte la [documentación de Probely](https://help.probely.com/en/articles/8592281-how-to-generate-an-api-key) para más información. - -## Prowler - -El conector de Prowler usa la API REST de **Prowler App** para importar hallazgos de postura de seguridad en la nube (CSPM) desde una instancia de Prowler App autoalojada. DefectDojo descubre cada **provider** (cuenta en la nube) de Prowler como un Record e importa los hallazgos **FAIL** del escaneo completado más reciente de ese provider. - -#### Requisitos previos - -Necesitará una instancia de **Prowler App** autoalojada en ejecución, y ya sea un correo electrónico y contraseña de usuario (para autenticación JWT) o una **API key** de Prowler App. Los hallazgos solo aparecen una vez que haya conectado una cuenta en la nube (AWS, GCP, Azure, Kubernetes, ...) en Prowler App y ejecutado un escaneo. - -#### Asignaciones del conector - -1. Ingrese la URL de Prowler App en el campo **Location** (por ejemplo, `https://prowler.your-company.com`). -2. Para autenticación JWT, ingrese el **Email** y **Password** del usuario de Prowler App. Alternativamente, deje esos campos en blanco e ingrese una **API Key** de Prowler App. Si se proporcionan ambos, se usa el email/password (JWT). -3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importan. - -DefectDojo crea un Record para cada provider de Prowler e importa los hallazgos FAIL de su escaneo completado más reciente, asignando las severidades de Prowler a las severidades de DefectDojo, el recurso en la nube afectado (ARN/resource id) como componente, y la remediación y el riesgo del check al hallazgo. Los hallazgos silenciados (muted) se omiten. La cuenta en la nube, la región y el servicio se adjuntan como etiquetas (tags). - -Para más información, consulte la **[documentación de la API de Prowler App](https://api.prowler.com/api/v1/docs)**. - -## Qualys - -El conector de Qualys importa **detecciones de vulnerabilidades de hosts de VMDR** —cada una combinada con sus metadatos de Qualys KnowledgeBase (QID)— desde Qualys Cloud Platform. DefectDojo crea un Record para cada **host** de Qualys en su suscripción. - -#### Requisitos previos - -Una cuenta de usuario de Qualys con **acceso a la API de VMDR**, y la **URL del servidor de API (platform)** de su suscripción, que difiere según la suscripción. Encuéntrela en la interfaz de Qualys, en **Help > About**, o en la página de [Platform Identification](https://www.qualys.com/platform-identification/) de Qualys (por ejemplo, `https://qualysapi.qualys.com` para US Platform 1, o `https://qualysapi.qg2.apps.qualys.com` para US Platform 2). - -#### Asignaciones del conector - -1. Ingrese la URL del servidor de API de Qualys en el campo **Location** (por ejemplo, `https://qualysapi.qualys.com`). -2. Ingrese el nombre de usuario de la API de Qualys en el campo **Username**. -3. Ingrese la contraseña de la API de Qualys en el campo **Secret**. -4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada host de Qualys se convierte en un Record. Las detecciones que Qualys ha marcado como **Fixed** se excluyen, por lo que reimportar cierra los hallazgos remediados. - -## **Quay** - -El conector de Quay usa la API REST de Project Quay para descubrir repositorios de contenedores e importar los informes de vulnerabilidades generados por el escáner **Clair** integrado de Quay. DefectDojo crea un Record para cada **repositorio** de Quay y, en cada Sync, lee el informe de seguridad de Clair del manifiesto de imagen de cada tag activo. - -#### Requisitos previos - -El escaneo de seguridad (Clair) debe estar habilitado en su instancia de Quay, y necesitará un **token de acceso OAuth 2** de Quay: - -* En Quay, cree (o abra) una Organization, vaya a **Applications**, cree una aplicación OAuth y luego **Generate Token** con al menos el alcance (scope) **Read repositories**. Se recomienda una aplicación dedicada para DefectDojo. -* El token se envía como un Bearer token en cada solicitud y nunca se registra en los logs. - -#### Asignaciones del conector - -1. Ingrese la URL base de Quay en el campo **Location**, por ejemplo `https://quay.io` o su instancia autoalojada `https://quay.example.com`. La URL debe ser HTTPS; no incluya una ruta de API al final: DefectDojo construye las rutas de la API automáticamente. -2. Ingrese el token de acceso OAuth en el campo **Secret**. -3. Opcionalmente, establezca un **Namespace** para restringir el descubrimiento a una única organización o usuario de Quay. Déjelo en blanco para descubrir todos los repositorios que el token pueda leer. -4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo asigna cada **repositorio** de Quay a un Record. Para cada repositorio, enumera los tags activos, los deduplica a sus manifiestos de imagen únicos (un manifiesto compartido por varios tags se escanea una sola vez) y lee el informe de Clair de cada manifiesto. Los manifiestos que Clair aún no ha terminado de escanear (por ejemplo, una lista de manifiestos multi-arquitectura, o una imagen aún en cola) se omiten hasta un Sync posterior. Cada vulnerabilidad de Clair se convierte en un hallazgo: el paquete afectado es el componente, la versión corregida se convierte en la mitigación, y las severidades **Negligible**/**Unknown** de Clair se registran como **Informativa**. - -Consulte la [documentación de la API de Project Quay](https://docs.projectquay.io/api_quay.html) y la [documentación de Clair](https://quay.github.io/clair/) para más información. - -## **Rapid7 InsightAppSec** - -El conector de Rapid7 InsightAppSec importa **hallazgos de vulnerabilidades DAST** desde la plataforma en la nube InsightAppSec, enriquecidos con metadatos del módulo de ataque (por ejemplo, *SQL Injection*), puntuaciones CVSS y la evidencia recopilada por el escaneo. DefectDojo crea un Record para cada **app** de InsightAppSec. - -**Tenga en cuenta:** este conector es distinto del conector **Rapid7 InsightVM** que se describe más abajo: InsightAppSec es el producto DAST en la nube de Rapid7 dentro de la plataforma Insight, mientras que los hallazgos de InsightVM provienen de su propia Security Console. - -#### Requisitos previos - -Una cuenta de la plataforma Insight con InsightAppSec, y una **API key** de la plataforma: en [Rapid7 Insight platform](https://insight.rapid7.com), abra el menú de configuración (el ícono de engranaje) > **API Keys** y genere una **User Key** (cualquier rol) o una **Organization Key** (administradores de la plataforma). Copie la clave cuando se muestre: solo se muestra una vez. - -También necesitará la **región** de su plataforma, visible en su URL de Insight (por ejemplo, `us`, `us2`, `us3`, `eu`, `ca`, `au` o `ap`). - -#### Asignaciones del conector - -1. Ingrese el endpoint de API de su región en el campo **Location**, por ejemplo `https://us.api.insight.rapid7.com` (reemplace `us` por su región). -2. Ingrese la API key de la plataforma Insight en el campo **API Key**. -3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada app de InsightAppSec se convierte en un Record. Solo se importan las vulnerabilidades **abiertas** (Unreviewed o Verified): los hallazgos que Rapid7 ha marcado como Remediated, Falso positivo, Ignored o Duplicado se excluyen, por lo que reimportar los cierra en DefectDojo. Las severidades se asignan directamente (`SAFE` e `INFORMATIONAL` se importan como Informativa). - -## **Rapid7 InsightVM** - -El conector de Rapid7 InsightVM importa hallazgos de vulnerabilidades de activos desde su **Security Console** de InsightVM (API v3), enriquecidos con el catálogo global de vulnerabilidades de la consola. DefectDojo crea un Record para cada **site** de InsightVM. - -#### Requisitos previos - -Acceso de red desde DefectDojo hasta su Security Console, y una **cuenta de usuario** de la consola; su inicio de sesión se usa para la autenticación HTTP Basic. La API de la consola se sirve por defecto en el puerto **3780**. - -#### Asignaciones del conector - -1. Ingrese la URL de su Security Console, incluyendo el puerto, en el campo **Location**; por ejemplo, `https://console.example.com:3780`. -2. Ingrese el nombre de usuario de la consola en el campo **Username**. -3. Ingrese la contraseña de la consola en el campo **Secret**. -4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada site de InsightVM se convierte en un Record; el conector recorre los activos del site e importa sus hallazgos de vulnerabilidades. - -## **runZero** - -El conector de runZero usa la Export API de runZero para sincronizar el inventario de activos de toda su organización en DefectDojo. Es principalmente un conector de **activos**: DefectDojo descubre cada activo y crea un Record para cada uno, agrupados en un Product Type según su **site** de runZero. Opcionalmente, también puede importar las vulnerabilidades de runZero como hallazgos. - -#### Requisitos previos - -Necesitará un **Export Token** de organización de runZero (Account → API), con el prefijo `XT`. El token tiene alcance de organización (la organización está codificada en el token), es de solo lectura, y se envía como un Bearer token; nunca se registra en los logs. Hay disponible un nivel community/starter. - -#### Asignaciones del conector - -1. Ingrese la URL de la consola de runZero en el campo **Location**, por ejemplo `https://console.runzero.com`. La URL debe ser HTTPS. -2. Ingrese el Export Token en el campo **Secret**. -3. Opcionalmente, establezca **Import Vulnerabilities** en `true` para importar también las vulnerabilidades de runZero como hallazgos; déjelo en blanco para sincronizar solo los activos. -4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos de vulnerabilidades se importan (aplica solo cuando se importan vulnerabilidades). - -DefectDojo asigna cada **activo** de runZero a un Record (VEP): el nombre visible proviene del nombre o la dirección del activo, y su site, tipo, SO, direcciones y etiquetas se adjuntan como atributos; el **site** del activo se convierte en su Product Type. Los activos se sincronizan mediante una exportación completa que DefectDojo concilia (agrega/elimina). Cuando **Import Vulnerabilities** está habilitado, cada vulnerabilidad de runZero se convierte en un hallazgo en su activo, asignando la severidad, la puntuación CVSS, el CVE, el endpoint del servicio afectado (`protocol://address:port`) y la remediación. - -Consulte la [documentación de la API de runZero](https://help.runzero.com/) para más información. - -## **Semgrep** - -Este conector usa la API REST de Semgrep para obtener datos. - -#### Asignaciones del conector - -Ingrese `https://semgrep.dev/api/v1/` en el campo **Location**. - -1. Ingrese una API key válida en el campo **Secret**. La puede encontrar en la página de Tokens: -​ -"Settings" en la barra de navegación izquierda > Tokens > Create new token ([https://semgrep.dev/orgs/\-/settings/tokens](https://semgrep.dev/orgs/-/settings/tokens)) - -Consulte la [documentación de Semgrep](https://semgrep.dev/docs/semgrep-cloud-platform/semgrep-api/#tag__badge-list) para más información. - -## **ServiceNow CMDB** - -El conector de ServiceNow CMDB es un **conector de activos (Asset Connector)**: en lugar de importar hallazgos, lee Configuration Items (CI) de su ServiceNow Configuration Management Database y crea un Asset de DefectDojo para cada CI, agrupados en Organizations según su clase de CI. No se importa ningún hallazgo. - -#### Requisitos previos - -Necesitará una instancia de ServiceNow y una cuenta que pueda leer las tablas de CMDB a través de la ServiceNow Table API. Recomendamos una cuenta de servicio dedicada y de solo lectura para DefectDojo. La cuenta necesita acceso de lectura a las tablas `cmdb_ci` que desea importar. - -#### Asignaciones del conector - -1. Ingrese la URL de su instancia de ServiceNow en el campo **Location**: `https://{your-instance}.service-now.com`. -2. Seleccione o cree una **Tool Configuration** de ServiceNow que contenga las credenciales de la instancia (el nombre de usuario y la contraseña de ServiceNow). - -Cada Configuration Item se convierte en un Record con el nombre del CI, agrupado por su **clase de CI** (por ejemplo, aplicación, servidor o servicio de negocio). Discovery y Sync concilian la lista de CI: los CI nuevos aparecen como Records `NEW`, y un CI eliminado del CMDB se marca como `MISSING` en el siguiente Sync para que su equipo pueda triarlo. DefectDojo nunca elimina un Producto de forma silenciosa. - -## **Shodan** - -El conector de Shodan usa la API REST de Shodan para importar las vulnerabilidades (CVE) que Shodan ha observado en sus hosts expuestos a internet. Usted proporciona una consulta de búsqueda de Shodan que limita la importación a sus propios activos; DefectDojo crea un Record para cada host coincidente e importa sus CVE como hallazgos. - -#### Requisitos previos - -Necesitará una API key de Shodan, disponible en la página **Account** de Shodan. La búsqueda de hosts con datos de vulnerabilidades requiere una membresía de Shodan o un plan de API de pago: el nivel gratuito no puede paginar los resultados de búsqueda. - -#### Asignaciones del conector - -1. Ingrese `https://api.shodan.io` en el campo **Location**. -2. Ingrese su API key de Shodan en el campo **API Key**. -3. En el campo **Search Query**, ingrese una consulta de Shodan que limite la importación a los activos de su organización; por ejemplo, `hostname:example.com`, `net:203.0.113.0/24`, u `org:"Example Inc"`. Solo se importan los hosts que coincidan con esta consulta, así que manténgala limitada a la infraestructura que usted posee. -4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada host coincidente se convierte en un Record, y cada CVE que Shodan detectó en los servicios expuestos de ese host se importa como un hallazgo; la severidad se deriva de la puntuación CVSS, incluyendo el contexto de EPSS y CISA KEV cuando está disponible. Cada página de resultados de búsqueda consume un crédito de consulta de Shodan. - -## SonarQube - -El conector de SonarQube puede obtener datos tanto de una cuenta de SonarCloud como de una instancia local de SonarQube. - -**Para usuarios de SonarCloud:** - -1. Ingrese https://sonarcloud.io/ en el campo Location. -2. Ingrese una **API key** válida en el campo Secret. - -**Para usuarios de SonarQube (on-premise):** - -1. Ingrese la URL base de su instancia de SonarQube en el campo Location: por ejemplo, `https://my.sonarqube.com/` -2. Ingrese una **API key** válida en el campo Secret. Deberá ser un **[User](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/)** [API Token Type](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/). - -El token deberá tener acceso a Projects, Vulnerabilities y Hotspots dentro de Sonar. - -Los tokens de API se pueden encontrar y generar a través de **My Account -> Security -> Generate Token** en la aplicación de SonarQube. Para más información, [consulte la documentación de SonarQube](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/). - -## **Snyk** - -El conector de Snyk usa la API REST de Snyk para obtener datos. - -#### Asignaciones del conector - -1. Ingrese **[https://api.snyk.io/rest](https://api.snyk.io/v1)** o **[https://api.eu.snyk.io/rest](https://api.eu.snyk.io/v1)** (para una implementación regional en la UE) en el campo **Location**. -2. Ingrese una API key válida en el campo **Secret**. Los API Tokens se encuentran en la **[Account Settings](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token)** [página](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token) de un usuario en Snyk. - -Consulte la [documentación de la API de Snyk](https://docs.snyk.io/snyk-api) para más información. - -## **Socket** - -El conector de Socket usa la API de [Socket.dev](https://socket.dev) para importar **hallazgos de la cadena de suministro de software** — las alertas de Socket sobre sus dependencias (malware, typosquatting, scripts de instalación, vulnerabilidades conocidas y más de 70 categorías adicionales). DefectDojo descubre todos los repositorios de las organizaciones a las que su token tiene acceso y crea un Record para cada uno, luego importa las alertas del análisis completo más reciente de ese repositorio. - -#### Prerrequisitos - -Necesitará un **token de API** de Socket — un token de organización creado en el panel de Socket en **Settings → API Tokens** (con los alcances `repo:list` y de lectura de full-scan). El token se envía como bearer token y nunca se registra en los logs. - -#### Asignaciones del conector - -1. Deje el campo **Location** en blanco para usar `https://api.socket.dev/v0`, o introdúzcalo explícitamente. -2. Introduzca el token de API de Socket en el campo **Secret**. -3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -DefectDojo asigna cada **repositorio** a un Record e importa las alertas de su análisis completo más reciente. Cada alerta se convierte en un hallazgo: la severidad proviene de la propia calificación de Socket (low, medium, high, critical), el paquete afectado se convierte en el componente y en un PURL, la categoría de la alerta (riesgo de cadena de suministro, calidad, mantenimiento, vulnerabilidad, licencia) se registra como etiquetas, y los detalles de la alerta se incorporan a la descripción. Los hallazgos se registran como hallazgos estáticos y se deduplican según la clave de alerta de Socket. - -Consulte la [documentación de la API de Socket](https://docs.socket.dev/reference) para más información. - -## **Sonatype IQ** - -El conector de Sonatype IQ usa la API REST del servidor Sonatype IQ (Nexus Lifecycle) para importar vulnerabilidades de componentes de código abierto. Enumera todas las aplicaciones de su organización de IQ y, para cada una, importa las vulnerabilidades de componentes del informe más reciente de esa aplicación en la etapa del ciclo de vida que configure. DefectDojo crea un Record para cada aplicación automáticamente — no hay configuración por aplicación. - -#### Prerrequisitos - -Necesitará una cuenta de usuario de Sonatype IQ con el permiso **View IQ Elements** en las aplicaciones que desea importar. Sonatype recomienda autenticarse con un **user token** (generado en **My Profile > User Token** en IQ Server) en lugar de una contraseña; las dos partes del token se corresponden con los campos Username y User Token que aparecen a continuación. El conector funciona tanto con instancias de IQ Server autoalojadas como con instancias alojadas por Sonatype (SaaS). - -#### Asignaciones del conector - -1. En el campo **Location**, introduzca la URL base de su IQ Server — para un servidor autoalojado, `https://iq.example.com`; para una instancia alojada por Sonatype, `https://.sonatype.app/platform`. -2. Introduzca el usuario de IQ (o la parte de código de usuario de su user token) en el campo **Username**. -3. Introduzca el user token de IQ (o la contraseña) en el campo **User Token**. -4. Opcionalmente, establezca un **Stage** para elegir de qué etapa del ciclo de vida se importa el informe por aplicación (`build`, `stage-release`, `release`, etc.). Déjelo en blanco para usar `build`. -5. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada aplicación se convierte en un Record, y cada problema de seguridad en el informe más reciente de esa aplicación para la etapa seleccionada se importa como un hallazgo. La severidad se deriva de la puntuación numérica del problema, y se incluyen las referencias CVE, el CWE, el vector CVSS y la URL del paquete (PURL) del componente afectado cuando están disponibles. -## **Sysdig Secure** - -El conector de Sysdig Secure importa **hallazgos de vulnerabilidades de contenedores / CNAPP** desde la API de gestión de vulnerabilidades de Sysdig Secure. Sincroniza toda la cuenta en el/los alcance(s) configurado(s) y crea un producto de DefectDojo para cada agrupación de activos escaneados. - -#### Prerrequisitos - -Un **token de API** de Sysdig Secure: en Sysdig Secure, vaya a **Settings > Sysdig Secure API Token** y copie el token. También necesita la **URL de región** de Sysdig (por ejemplo, `https://us2.app.sysdig.com`, `https://eu1.app.sysdig.com`, o su host on-premises). - -#### Asignaciones del conector - -1. Introduzca la URL de región/base de Sysdig en el campo **Location**. -2. Introduzca el token de API en el campo **Secret**. -3. Opcionalmente, establezca **Scopes** — una lista separada por comas de `runtime`, `registry`, y/o `pipeline` (déjelo en blanco para `runtime`, el alcance de cargas de trabajo desplegadas). -4. Opcionalmente, establezca **Runtime Product Grouping** — cómo se asignan los resultados de runtime a los productos: `cluster`, `namespace`, `workload`, o `image` (déjelo en blanco para `namespace`). Los resultados de registry y pipeline siempre se agrupan por repositorio de imágenes. -5. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada agrupación de activos se convierte en un Record. Para cada resultado de análisis, el conector importa cada paquete vulnerable como un hallazgo. Los hallazgos de **runtime** (cargas de trabajo desplegadas) se registran como hallazgos dinámicos y se etiquetan con su contexto de clúster/namespace/workload/contenedor de Kubernetes; los hallazgos de **registry** y **pipeline** se registran como hallazgos estáticos de análisis de imágenes. La severidad `NEGLIGIBLE` de Sysdig se asigna a Informativa. - -## Tenable - -El conector de Tenable usa la API REST de **Tenable.io** para obtener datos. Los análisis se obtienen del endpoint `/scans` de Tenable VM. - -Los conectores de Tenable on-premise no están disponibles por el momento. - -#### **Asignaciones del conector** - -1. Introduzca en el campo Location. -2. Introduzca una **API key** válida en el campo Secret. - -Consulte la [documentación de la API de Tenable](https://docs.tenable.com/vulnerability-management/Content/Settings/my-account/GenerateAPIKey.htm) para más información. - -## **Tenable Web App Scanning** - -El conector de Tenable Web App Scanning importa **hallazgos de aplicaciones web (DAST)** desde Tenable Web App Scanning. Es un conector independiente de Tenable (Vulnerability Management): los dos productos cubren activos diferentes y se configuran de forma independiente, por lo que puede usar uno u otro, o ambos. - -DefectDojo crea un Record para cada **aplicación web escaneada**. Las aplicaciones se descubren a partir de sus configuraciones de análisis de Web App Scanning; una configuración que nunca se ha ejecutado no genera un Record hasta que se complete su primer análisis. Cuando más de una configuración analiza la misma aplicación, comparten un único Record. - -#### Prerrequisitos - -**API keys** de Tenable (una access key y una secret key) para un usuario con permisos de Web App Scanning. En Tenable, vaya a **My Account > API Keys** para generarlas, y confirme que el usuario puede ver los análisis que desea importar — las keys limitadas a Vulnerability Management no pueden leer datos de Web App Scanning. - -Los conectores de Tenable on-premise no están disponibles por el momento. - -#### Asignaciones del conector - -1. Introduzca en el campo **Location**. -2. Introduzca su **Access Key** y **Secret Key**. -3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -Los hallazgos se importan con la severidad que Tenable reporta para su cuenta, incluida cualquier severidad que su equipo haya reclasificado. Cada hallazgo incluye la URL afectada como endpoint, el parámetro de solicitud y el payload que lo desencadenó, y la prueba y el resultado de Tenable como pasos para reproducirlo, junto con los valores de CWE, CVE, CVSS y EPSS cuando el plugin de detección los proporciona. - -Solo se importan los hallazgos que están actualmente abiertos o reabiertos. Un hallazgo que Tenable ha marcado como corregido se cierra en DefectDojo en la siguiente sincronización. - -## **Veracode** - -El conector de Veracode importa hallazgos de aplicaciones desde la plataforma Veracode, divididos por tipo de análisis en los tipos de hallazgo **SAST**, **DAST**, **SCA** y **Manual**. DefectDojo crea un Record para cada **aplicación** de Veracode. - -#### Prerrequisitos - -Genere una **credencial de API** de Veracode para una cuenta que pueda ver las aplicaciones que desea importar: en la Veracode Platform, abra el menú de su cuenta > **API Credentials** y seleccione **Generate API Credentials** (consulte [Managing Veracode API credentials](https://docs.veracode.com/r/c_api_credentials3)). Copie tanto el **API ID** como la **API Secret Key** — la clave secreta solo se muestra una vez. - -#### Asignaciones del conector - -1. Introduzca la URL base de la API de Veracode en el campo **Location**: `https://api.veracode.com` (región comercial), `https://api.veracode.eu` (región europea), o `https://api.veracode.us` (región federal de EE. UU.). -2. Introduzca el API ID en el campo **API ID**. -3. Introduzca la clave secreta de API en el campo **Secret**. -4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. - -Cada aplicación de Veracode se convierte en un Record. Solo se importan los hallazgos **abiertos**, por lo que una nueva importación cierra los hallazgos que Veracode reporta como resueltos. - -## **Wazuh** - -El conector de Wazuh usa el Wazuh Indexer (OpenSearch) para obtener hallazgos de vulnerabilidades. Wazuh 4.8 y versiones posteriores almacenan los CVE detectados en el Indexer en lugar de en la API del servidor Wazuh, por lo que este conector los lee directamente del índice `wazuh-states-vulnerabilities-*`. - -DefectDojo crea un Record para cada agente (endpoint) de Wazuh e importa los CVE detectados de ese agente como hallazgos de forma programada. - -#### Prerrequisitos - -Necesitará: - -* La URL base de su Wazuh Indexer, incluido el puerto (el Indexer escucha por defecto en el puerto 9200). DefectDojo se conecta directamente al Indexer, por lo que este endpoint debe ser accesible desde DefectDojo. Para implementaciones autoadministradas, es el host que ejecuta el Wazuh Indexer. Para Wazuh Cloud, use el endpoint del Indexer que se muestra en su consola de Wazuh Cloud, que es distinto de la URL del panel de Wazuh. -* Un usuario y contraseña del Indexer con acceso de lectura al índice `wazuh-states-vulnerabilities-*`. Recomendamos crear un usuario dedicado para DefectDojo. - -La detección de vulnerabilidades debe estar habilitada en Wazuh para que se rellene el índice de estado de vulnerabilidades. Consulte la [documentación de detección de vulnerabilidades de Wazuh](https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html) para más información. - -#### Asignaciones del conector - -1. Introduzca la URL base de su Wazuh Indexer en el campo **Location**, incluyendo el esquema y el puerto, por ejemplo `https://your-indexer.example.com:9200`. No incluya una ruta final. DefectDojo construye las rutas de búsqueda automáticamente. -2. Introduzca el nombre de usuario del Indexer en el campo **Username**. -3. Introduzca la contraseña del Indexer en el campo **Password**. -4. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importarán. - -## Wiz - -Para usar el conector de Wiz es necesario crear una cuenta de servicio: consulte la [documentación de Wiz](https://docs.wiz.io/wiz-docs/docs/service-accounts-settings#add-a-service-account) para más información. Necesitará una cuenta de Wiz para acceder a la documentación. - -La cuenta de servicio debe cumplir todos los siguientes requisitos. Una cuenta de servicio a la que le falte alguno de ellos aún puede autenticarse correctamente, pero no importará nada: - -* **Type**: Custom Integration (GraphQL API). -* **API scopes**: como mínimo `read:projects`, `read:issues`, y `read:vulnerabilities`. -* **Project visibility**: la cuenta de servicio debe tener alcance sobre cada Wiz Project que desee importar (o sobre todos los Projects). El conector descubre primero sus Wiz Projects y luego obtiene los hallazgos de cada Project — una cuenta que puede leer issues pero no tiene visibilidad de Projects descubre cero Projects, por lo que no hay nada que importar y ninguno de los dos lados reporta un error. - -#### **Asignaciones del conector** - -1. Introduzca su Wiz Client ID en el campo Client ID. -2. Introduzca el Wiz Client Secret en el campo Secret. - -## **YesWeHack** - -El conector de YesWeHack usa la API REST de YesWeHack para importar informes de sus programas de bug bounty y divulgación de vulnerabilidades. DefectDojo crea un Record para cada programa al que su token pueda acceder e importa sus informes como hallazgos. - -#### Prerrequisitos - -Necesitará un **Personal Access Token (PAT)** de YesWeHack. Es suficiente con acceso de lectura a sus programas. Algunas cuentas requieren TOTP/MFA al crear un token; una vez creado, el conector usa el valor del token en sí. - -1. En YesWeHack, abra la configuración de su cuenta y vaya a **API / Personal Access Tokens**. -2. Cree un token y copie su valor. Solo se muestra una vez. - -#### Asignaciones del conector - -1. Introduzca `https://api.yeswehack.com/` en el campo **Location**. -2. Introduzca su Personal Access Token en el campo **Secret**. -3. Opcionalmente, establezca una **Minimum Severity** para limitar qué hallazgos se importan. Los hallazgos por debajo de la severidad seleccionada no se importarán. - -DefectDojo crea un Record independiente para cada programa al que su token pueda acceder, e importa cada informe como un hallazgo. La severidad del hallazgo se toma de la calificación CVSS del informe (recurriendo a la prioridad de triaje si no está disponible), y su estado refleja el estado del flujo de trabajo del informe — por ejemplo, los informes resueltos se importan como Mitigado, y los informes marcados como inválidos o fuera de alcance se importan como inactivos. diff --git a/docs/content/connectors/upstream/toolreference.fr.md b/docs/content/connectors/upstream/toolreference.fr.md deleted file mode 100644 index 1895135363f..00000000000 --- a/docs/content/connectors/upstream/toolreference.fr.md +++ /dev/null @@ -1,1501 +0,0 @@ ---- -title: Référence des outils pour les Connecteurs Upstream -description: Notre liste des outils de Connecteur pris en charge, et comment les configurer - avec DefectDojo -aliases: -- /fr/import_data/pro/connectors/connectors_tool_reference/ -- /fr/en/connecting_your_tools/connectors/connectors_tool_reference ---- - -Remarque : les Connecteurs Upstream sont une fonctionnalité réservée à DefectDojo Pro. - -Lors de la configuration d'un Connecteur pour un outil pris en charge, vous devez fournir à DefectDojo des informations spécifiques liées à l'API de l'outil. Au minimum, vous aurez besoin des éléments suivants : - -* **Location** \- un champ qui fait généralement référence à l'URL de votre outil sur votre réseau, -* **Secret** \- généralement une clé API. - -Certains outils nécessiteront des champs supplémentaires liés à l'API, en plus de **Location** et **Secret**. Ils peuvent également nécessiter que vous effectuiez des modifications de leur côté pour prendre en charge un Connecteur entrant depuis DefectDojo. - -![image](images/connectors_tool_reference.png) - -Chaque outil possède une configuration d'API différente, et ce guide a pour but de vous aider à configurer l'API de l'outil afin que DefectDojo puisse s'y connecter. - -Dans la mesure du possible, nous vous recommandons de créer un nouveau compte « DefectDojo Bot » au sein de votre outil de sécurité, qui sera utilisé exclusivement par le Connecteur. Cela vous aidera à mieux distinguer les actions effectuées manuellement par votre équipe des actions automatisées effectuées par le Connecteur. - -# **Connecteurs d'actifs** - -La plupart des Connecteurs importent des **constatations** depuis un outil de sécurité. Les **Connecteurs d'actifs** fonctionnent différemment : ils importent plutôt votre **inventaire d'actifs**. Un Connecteur d'actifs énumère les actifs qui existent sur une plateforme externe (par exemple, les dépôts d'un groupe GitLab) et crée et maintient automatiquement les **Produits** (Actifs) et **Types de produit** (Organisations) correspondants dans DefectDojo. Aucune constatation n'est importée par un Connecteur d'actifs. - -* **Discover** et **Sync** réconcilient tous deux la liste des actifs. Les nouveaux actifs apparaissent comme des Enregistrements `NEW` ; une fois mappés (automatiquement, si le mappage automatique est activé), DefectDojo crée le Produit et le regroupe sous un Type de produit dérivé de l'outil — par exemple, l'espace de noms GitLab ou le projet Azure DevOps. -* Si un actif est ensuite supprimé en amont (par exemple, un dépôt est supprimé), son Enregistrement mappé est marqué `MISSING` lors de la prochaine synchronisation via **Sync**, afin que votre équipe puisse le trier. DefectDojo ne supprime jamais silencieusement un Produit. - -Azure DevOps, Backstage, Bitbucket, GitHub, GitLab, Jira Service Management Assets et ServiceNow CMDB sont des Connecteurs d'actifs. runZero est principalement un Connecteur d'actifs, mais peut également importer des vulnérabilités sous forme de constatations. Tous les autres Connecteurs listés ci-dessous importent des constatations. - -# **Connecteurs pris en charge** - -## **Acunetix 360** - -Le connecteur Acunetix 360 importe des **constatations de vulnérabilités DAST** depuis la plateforme cloud Acunetix 360 (la plateforme Invicti). DefectDojo découvre les sites web analysés de votre compte et crée un Enregistrement pour chaque **site web** ; les constatations d'un site web proviennent de son dernier scan terminé. - -**Veuillez noter :** ce connecteur est destiné à **Acunetix 360** (le produit cloud à l'adresse `online.acunetix360.com`). Il ne concerne pas le scanner Acunetix Standard/Premium sur site, qui dispose d'une API différente. - -#### Prérequis - -Un compte Acunetix 360 et des **identifiants API** : dans Acunetix 360, ouvrez le menu de votre compte \> **API Settings**, notez l'**API User ID** et générez un **API Token**. Le connecteur s'authentifie avec ces identifiants au format HTTP Basic ; un compte de service dédié est donc recommandé pour distinguer l'activité automatisée des actions manuelles de l'équipe. - -#### Mappages du Connecteur - -1. Saisissez l'URL de votre Acunetix 360 dans le champ **Location** : `https://online.acunetix360.com`. -2. Saisissez l'API User ID dans le champ **API User ID**. -3. Saisissez l'API Token dans le champ **API Token**. -4. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque site web analysé devient un Enregistrement. Les constatations proviennent du dernier scan terminé du site web ; les vulnérabilités qu'Acunetix 360 a marquées **Accepted Risk** ou **False Positive** sont tout de même importées, mais signalées comme inactives (risque accepté ou faux positif) afin que le produit DefectDojo reflète le triage effectué par l'éditeur. - -## **Akamai API Security** - -Le connecteur Akamai API Security utilise une clé API pour récupérer les constatations de sécurité depuis l'API Akamai. DefectDojo découvre votre environnement Akamai et crée des Enregistrements distincts pour chaque **Application** et **Host** configurés dans votre compte. - -#### Prérequis - -Vous aurez besoin d'une clé API ayant accès à l'API Akamai. Nous recommandons de créer un compte de service dédié pour DefectDojo afin de bien distinguer l'activité automatisée des actions manuelles de l'équipe. - -#### Mappages du Connecteur - -1. Saisissez l'URL de base de votre API Akamai dans le champ **Location**. Cette URL est spécifique à votre instance Akamai : par exemple -2. Saisissez une **API Key** valide dans le champ **Secret**. - -DefectDojo mappe les **Applications** et les **Hosts** sous forme d'Enregistrements distincts. Chaque Application apparaîtra sous la forme `{name} (application)` et chaque Host sous la forme `{name} (host)` dans votre liste d'Enregistrements. - -## **Anchore** - -Le connecteur Anchore utilise le jeton API d'un utilisateur pour récupérer des données depuis Anchore Enterprise. Les Produits sont mappés et découverts à partir des « Applications », qui sont composées de plusieurs Images dans Anchore - voir la [documentation Anchore Enterprise](https://docs.anchore.com/current/docs/sbom_management/application_groups/application_management_anchorectl/) pour plus d'informations. - -#### Mappages du Connecteur - -1. L'URL d'Anchore dans le champ **Location** : il s'agit de l'URL à laquelle vous accédez à Anchore. -2. Saisissez une clé API valide dans le champ Secret. Il s'agit de la clé API associée à votre compte de service Burp. - -Consultez la [documentation officielle d'Anchore](https://docs.anchore.com/current/docs/) pour plus d'informations sur la création d'un jeton pour Anchore. - -## **AWS Security Hub** - -Le connecteur AWS Security Hub utilise une clé d'accès AWS pour interagir avec les API de Security Hub. - -#### Prérequis - -Plutôt que d'utiliser la clé d'accès AWS d'un membre de l'équipe, nous recommandons de créer un utilisateur IAM dans votre compte AWS spécifiquement pour DefectDojo, avec des permissions limitées à celles nécessaires pour interagir avec Security Hub. - -La politique AWS « **[AWSSecurityHubReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubReadOnlyAccess.html)**policy » fournit le niveau d'accès requis pour un connecteur. Si vous souhaitez rédiger une politique personnalisée pour un Connecteur, vous devrez inclure les permissions suivantes : - -* [DescribeHub](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_DescribeHub.html) -* [GetFindingAggregator](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingAggregator.html) -* [GetFindings](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindings.html) -* [ListFindingAggregators](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_ListFindingAggregators.html) - -Un exemple de politique fonctionnelle pourrait ressembler à ceci : - -``` -{ - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "AWSSecurityHubConnectorPerms", - "Effect": "Allow", - "Action": [ - "securityhub:DescribeHub", - "securityhub:GetFindingAggregator", - "securityhub:GetFindings", - "securityhub:ListFindingAggregators" - ], - "Resource": "*" - } - ] -} -``` - -**Veuillez noter :** nous pourrions avoir besoin d'utiliser des actions API supplémentaires à l'avenir afin d'offrir la meilleure expérience possible, ce qui nécessitera des mises à jour de cette politique. - -Une fois que vous avez créé votre utilisateur IAM et lui avez attribué les permissions nécessaires à l'aide d'une politique/d'un rôle approprié, vous devrez générer une clé d'accès, que vous pourrez ensuite utiliser pour créer un Connecteur. - -#### Mappages du Connecteur - -1. Saisissez le [point de terminaison de l'API AWS correspondant à votre région](https://docs.aws.amazon.com/general/latest/gr/sechub.html#sechub_region) dans le champ **Location**\ : par exemple, pour récupérer les résultats de la région `us-east-1`, vous fourniriez - -`https://securityhub.us-east-1.amazonaws.com` -2. Saisissez une **AWS Access Key** valide dans le champ **Access Key**. -3. Saisissez la **Secret Key** correspondante dans le champ **Secret Key**. - -DefectDojo peut récupérer des constatations depuis plusieurs régions grâce à la fonctionnalité d'**agrégation inter-régions** de Security Hub. Si l'[agrégation inter-régions](https://docs.aws.amazon.com/securityhub/latest/userguide/finding-aggregation.html) est activée, vous devez fournir le point de terminaison de l'API pour votre « **Aggregation Region** ». Pour les régions liées supplémentaires, des Enregistrements de Produit seront créés dans DefectDojo à partir de l'ID de votre compte AWS et du nom de la région. - -## **Azure DevOps** - -Le connecteur Azure DevOps est un **Connecteur d'actifs** : il énumère les dépôts git de chaque projet de votre organisation Azure DevOps et crée un Actif DefectDojo pour chaque dépôt, regroupé en Organisations par projet Azure DevOps. Aucune constatation n'est importée. - -#### Prérequis - -Vous aurez besoin d'un jeton d'accès personnel (PAT) pour l'organisation. Nous recommandons de générer ce jeton depuis un compte de service dédié. Seuls des scopes en lecture sont nécessaires : - -1. Dans Azure DevOps, ouvrez **User settings \> Personal access tokens \> New Token**. -2. Cliquez sur **Show all scopes**, puis sélectionnez **Code: Read** et **Project and Team: Read**. - -Seul Azure DevOps Services (dev.azure.com) est pris en charge ; Azure DevOps Server sur site n'est pas pris en charge pour le moment. - -#### Mappages du Connecteur - -1. Saisissez l'URL de votre organisation dans le champ **Location** : `https://dev.azure.com/{your-organization}`. Les URL héritées `https://{your-organization}.visualstudio.com` sont également acceptées, et tout segment de chemin supplémentaire (par exemple, un lien vers un projet spécifique) est ignoré. -2. Saisissez le PAT dans le champ **Secret**. - -Chaque dépôt devient un Enregistrement portant le nom du dépôt, regroupé par **projet** Azure DevOps. Les dépôts désactivés sont ignorés, si bien que désactiver ou supprimer un dépôt marque son Enregistrement comme `MISSING` lors de la prochaine synchronisation. - -## **Backstage** - -Le connecteur Backstage est un **connecteur d'actifs** : au lieu d'importer des constatations, il récupère votre Software Catalog [Backstage](https://backstage.io) dans DefectDojo et maintient votre hiérarchie de Produits et la propriété des équipes synchronisées avec celui-ci. Il est conçu pour les organisations qui maintiennent leur inventaire de services et leur structure organisationnelle dans Backstage et souhaitent que DefectDojo reflète cette structure au lieu de la maintenir manuellement. - -#### Ce qui est mappé - -| Backstage | DefectDojo | -|---|---| -| **System** | Type de produit (les Components sans System sont regroupés sous un Type de produit configurable « Backstage / Uncategorized ») | -| **Component** | Produit — nommé à partir du `title` de l'entité (avec repli sur `name`), avec la description du catalogue | -| **Owning Group** (relation `ownedBy`) | Un Groupe DefectDojo lié au Produit (rôle par défaut : Maintainer, configurable) | -| **Owner email** (e-mail du profil du Groupe, ou e-mail d'un propriétaire Utilisateur) | Un Membre de produit, lorsqu'un utilisateur DefectDojo possédant cet e-mail existe déjà (aucun utilisateur n'est jamais créé) | -| `metadata.tags`, `spec.type`, `spec.lifecycle`, namespace, domain | Étiquettes de produit sous un préfixe `backstage:` | -| `metadata.annotations` | Stocké sur l'Enregistrement (avec une limite) ; certaines annotations peuvent être promues en attributs de premier niveau ou en étiquettes via **Annotation Mappings** | - -Les Enregistrements sont indexés par le `metadata.uid` attribué par le serveur de l'entité ; ainsi, les renommages effectués dans Backstage mettent à jour le Produit mappé **sur place** lors de la prochaine synchronisation — sans doublons. Le nom du Produit suit toujours le catalogue : pour renommer un Produit géré par ce connecteur, renommez le Component dans Backstage (un renommage effectué côté DefectDojo, ou un nom personnalisé attribué lors du mappage manuel, est réconcilié avec le nom du catalogue lors de la prochaine synchronisation, sauf s'il entre en collision avec un autre Produit). Les changements de propriété déplacent l'affectation de groupe du Produit. Les Components qui disparaissent du catalogue (ou qui sont signalés par l'annotation `backstage.io/orphan`) sont marqués **MISSING** — DefectDojo ne supprime jamais un Produit de lui-même. La hiérarchie de Domain et de Group (équipes parentes) est uniquement enregistrée sous forme d'étiquettes/métadonnées ; elle ne crée pas de niveaux de hiérarchie supplémentaires. - -#### Prérequis - -Le connecteur s'authentifie à l'aide d'un **jeton d'accès externe statique** auprès du backend Backstage. Dans la configuration de votre application Backstage, définissez un jeton et (recommandé) restreignez-le au plugin catalog : - -```yaml -backend: - auth: - externalAccess: - - type: static - options: - token: ${DEFECTDOJO_BACKSTAGE_TOKEN} - subject: defectdojo-connector - accessRestrictions: - - plugin: catalog -``` - -Générez un jeton aléatoire fort (par exemple `openssl rand -hex 32`) et stockez-le dans l'environnement de votre déploiement Backstage. Consultez la [documentation Backstage sur l'authentification de service à service](https://backstage.io/docs/auth/service-to-service-auth) pour plus de détails. - -#### Mappages du Connecteur - -1. Saisissez l'**URL racine du backend Backstage** dans le champ **Location** : par exemple `https://backstage.example.com` (le connecteur ajoute `/api/catalog`). Il doit s'agir de l'URL du **backend**, et non de l'interface web frontend. -2. Saisissez le jeton d'accès externe statique dans le champ **Secret**. - -Champs facultatifs (laissez vide pour les valeurs par défaut) : - -* **Namespaces** — espaces de noms du catalogue à importer, séparés par des virgules ; vide importe tous les espaces de noms. -* **Component Types** — valeurs `spec.type` séparées par des virgules (par ex. `service,website`) ; vide importe tous les types. -* **Page Size** — taille de page pour les requêtes du catalogue (1\-500, valeur par défaut 250). -* **TLS Verification** — à définir sur `false` uniquement si Backstage sert un certificat que DefectDojo ne peut pas vérifier (AC interne) ; non recommandé. -* **Uncategorized Product Type** — le Type de produit utilisé pour les Components sans System (par défaut `Backstage / Uncategorized`). -* **Owner Group Role** — le rôle accordé à l'équipe propriétaire sur les Produits mappés (par défaut `Maintainer`). -* **Annotation Mappings** — un objet JSON associant des clés d'annotation à des noms d'attributs d'Enregistrement, ou à `"tag"` pour importer une annotation en tant qu'étiquette de Produit, par ex. `{"github.com/project-slug": "GITHUB_PROJECT", "example.com/tier": "tag"}`. - -Lorsque **Auto\-Map** est activé, un seul cycle Discover \+ Sync construit l'intégralité de la structure Type de produit / Produit / propriété sans étape manuelle. Lorsque Auto\-Map est désactivé, les Components découverts apparaissent comme des Enregistrements en attente de votre décision de mappage. - -#### Limitations (v1) - -* **L'appartenance aux Groups Backstage n'est pas synchronisée** : le connecteur crée/associe l'équipe propriétaire en tant que Groupe DefectDojo, mais le peuplement des utilisateurs de ce groupe est laissé à votre fournisseur d'identité ou à vos administrateurs. -* Seuls les Components deviennent des Produits ; les API, Resources et Domains ne sont pas importés comme actifs (les domains apparaissent sous forme d'étiquettes). -* Les étiquettes et annotations sont normalisées et limitées pour respecter les contraintes de longueur des champs DefectDojo (les valeurs trop longues sont tronquées). - -**Remarque sur le sens inverse :** afficher les constatations et les notes DefectDojo *à l'intérieur* de Backstage (sur les pages d'entité) constituerait un prolongement naturel, qui serait développé sous la forme d'un plugin frontend Backstage consommant l'API REST de DefectDojo — cela sort délibérément du périmètre de ce connecteur, qui se contente d'importer les données du catalogue dans DefectDojo. - -## **Black Duck** - -Le connecteur Black Duck importe des constatations d'**analyse de composition logicielle (SCA)** depuis une instance Black Duck Hub (Synopsys / Black Duck). DefectDojo découvre tous les projets de l'instance et crée un Enregistrement pour chaque **projet** ; les constatations d'un projet proviennent des composants du BOM vulnérables de sa version sélectionnée. - -#### Prérequis - -Un **jeton API** Black Duck pour un utilisateur pouvant voir les projets que vous souhaitez importer. Dans Black Duck, ouvrez votre menu utilisateur \> **My Access Tokens** \> **Create New Token**, accordez-lui (au moins) un accès en lecture, et copiez le jeton lorsqu'il s'affiche — il n'est affiché qu'une seule fois. Le connecteur échange ce jeton contre un jeton porteur (bearer) de courte durée à chaque synchronisation ; il n'est jamais stocké en clair en dehors du champ secret du connecteur. - -#### Mappages du Connecteur - -1. Saisissez l'URL de votre hub Black Duck dans le champ **Location** — par exemple `https://your-company.app.blackduck.com`. -2. Saisissez le jeton API dans le champ **Secret**. -3. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque projet Black Duck devient un Enregistrement. Par défaut, le connecteur importe la version **released** du projet (avec repli sur sa première version) ; chaque composant du BOM vulnérable de cette version devient une constatation, intitulée `{vulnerability} in {component}:{version}`. - -Ce connecteur est distinct des parseurs Black Duck basés sur fichiers — ses constatations utilisent le type de scan dédié **Black Duck - Connectors Import**. - -## **Bitbucket** - -Le connecteur Bitbucket est un **Connecteur d'actifs** : il énumère les dépôts des espaces de travail (workspaces) Bitbucket Cloud que vous indiquez et crée un Actif DefectDojo pour chaque dépôt, regroupé en Organisations par projet Bitbucket. Aucune constatation n'est importée. - -#### Prérequis - -Bitbucket Cloud nécessite un jeton API Atlassian **à portée définie (scoped)** — les jetons API Atlassian classiques (sans portée) sont rejetés par Bitbucket avec une erreur « API Token provided has no Bitbucket scopes ». - -1. Rendez-vous sur [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens) et choisissez **Create API token with scopes**. -2. Sélectionnez l'application **Bitbucket**, puis accordez les portées en lecture : `read:account:bitbucket`, `read:workspace:bitbucket`, `read:repository:bitbucket` et `read:project:bitbucket`. - -Seul Bitbucket Cloud (bitbucket.org) est pris en charge. Bitbucket Server a atteint sa fin de vie en 2024, et Bitbucket Data Center n'est pas pris en charge. - -#### Mappages du Connecteur - -1. Saisissez `https://bitbucket.org` dans le champ **Location**. -2. Saisissez l'e-mail du compte Atlassian auquel appartient le jeton dans le champ **Email**. -3. Saisissez le jeton API à portée définie dans le champ **Secret**. -4. Saisissez un ou plusieurs slugs d'espace de travail (séparés par des virgules) dans le champ **Workspace Slugs**. Ce champ est obligatoire : les jetons API à portée définie de Bitbucket ne peuvent pas lister automatiquement les espaces de travail, DefectDojo doit donc être informé des espaces de travail à lire. - -Chaque dépôt devient un Enregistrement portant le nom du dépôt, regroupé par **projet** Bitbucket. - -## **Bugcrowd** - -Le connecteur Bugcrowd utilise l'API REST de Bugcrowd pour importer les soumissions de vos programmes de bug bounty et de divulgation de vulnérabilités. DefectDojo découvre les programmes auxquels votre jeton API a accès et crée un Enregistrement pour chacun d'eux, en important les soumissions de ce programme sous forme de constatations. - -#### Prérequis - -Vous aurez besoin d'un **jeton API** Bugcrowd ayant accès aux programmes que vous souhaitez importer. Nous recommandons de créer un compte de service dédié pour DefectDojo afin que l'activité automatisée soit facile à distinguer des actions manuelles de l'équipe. Générez le jeton dans Bugcrowd sous **Organization settings \> API credentials** ; un accès en lecture aux submissions, programs et targets est suffisant. - -#### Mappages du Connecteur - -1. Saisissez `https://api.bugcrowd.com` dans le champ **Location**. -2. Saisissez votre jeton API Bugcrowd dans le champ **Secret**. Il est envoyé sous forme d'en-tête `Authorization: Token`. -3. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque **programme** Bugcrowd devient un Enregistrement, et ses soumissions sont importées comme constatations en conservant la sévérité Bugcrowd. Les soumissions en doublon sont exclues, si bien qu'une réimportation ne crée pas de constatations répétées pour le même problème. - -## **Bright Security** - -Le connecteur Bright Security utilise l'API [Bright](https://brightsec.com) (anciennement NeuraLegion) pour importer des **constatations DAST**. DefectDojo découvre tous les scans auxquels le jeton a accès et crée un Enregistrement pour chaque scan terminé, puis importe les issues de ce scan sous forme de constatations. - -#### Prérequis - -Vous aurez besoin d'une **clé API** Bright, créée dans l'application Bright sous **User settings → API keys** (une clé `Org` ou personnelle). La clé est envoyée dans l'en-tête `Authorization: Api-Key` et n'est jamais journalisée. - -#### Mappages du Connecteur - -1. Laissez le champ **Location** vide pour utiliser `https://app.brightsec.com`, ou saisissez explicitement votre hôte Bright. -2. Saisissez la clé API Bright dans le champ **Secret**. -3. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -DefectDojo mappe chaque **scan** terminé sur un Enregistrement et chaque **issue** sur une constatation : la sévérité provient de la notation propre à Bright (Critical/High/Medium/Low), le score CVSS, le CWE et la remédiation sont repris, le point d'entrée affecté devient le point de terminaison, et les preuves de requête/réponse sont incluses dans la description. Les constatations sont enregistrées comme des constatations dynamiques et dédupliquées sur l'ID d'issue de Bright. - -Consultez la [documentation de l'API Bright](https://docs.brightsec.com/) pour plus d'informations. - -## **BurpSuite** - -Le connecteur Burp de DefectDojo appelle l'API GraphQL de Burp pour récupérer les données. - -#### Prérequis - -Avant de pouvoir configurer ce connecteur, vous aurez besoin d'une clé API provenant d'un Burp Service Account. Les comptes utilisateur Burp n'ont pas de clé API par défaut ; vous devrez donc peut-être créer un nouvel utilisateur spécifiquement à cette fin. - -Consultez la [documentation Burp](https://portswigger.net/burp/documentation/enterprise/user-guide/api-documentation/create-api-user) pour un guide sur la configuration d'un utilisateur Service Account avec une clé API. - -#### Mappages du Connecteur - -1. Saisissez l'URL racine de Burp dans le champ **Location** : il s'agit de l'URL à laquelle vous accédez à l'outil Burp. -2. Saisissez une clé API valide dans le champ Secret. Il s'agit de la clé API associée à votre compte Burp Service. - -Consultez la [documentation officielle de Burp](https://portswigger.net/burp/extensibility/enterprise/graphql-api/index.html) pour plus d'informations sur l'API Burp. - -## **Censys** - -Le connecteur Censys lit les actifs de type host depuis la Censys Platform et importe les services exposés de chaque host sous forme de constatations. Il utilise l'API de recherche globale de la Censys Platform pour énumérer les hosts sur lesquels vous le limitez. - -#### Prérequis - -Vous aurez besoin d'un compte Censys **Platform** avec accès API : - -* Un **Personal Access Token**, créé dans la Censys Platform Console sous Personal Access Tokens. -* Votre **Organization ID**, affiché sur la même page de paramètres sous « Current Organization ». L'accès API au point de terminaison de recherche nécessite une organisation ; un abonnement Starter ou supérieur est donc requis. Les jetons de niveau gratuit n'ont pas d'Organization ID et ne peuvent pas utiliser l'API de recherche. - -Les données de CVE et de risque par host ne sont disponibles que sur les abonnements Censys Core (entreprise) ; sur les niveaux inférieurs, les constatations représentent donc des services exposés plutôt que des vulnérabilités. - -Consultez la [documentation de l'API Censys Platform](https://docs.censys.com/reference/get-started) pour plus d'informations. - -#### Mappages du Connecteur - -1. Saisissez `https://api.platform.censys.io` dans le champ **Location**. -2. Saisissez votre Personal Access Token dans le champ **API Key**. -3. Saisissez votre **Organization ID**. -4. Saisissez une **Search Query** qui limite l'import à vos propres actifs, par exemple `host.autonomous_system.asn: ` ou `host.ip: 203.0.113.0/24`. -5. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -DefectDojo crée un Enregistrement pour chaque host et importe ses services exposés sous forme de constatations. - -## **Checkmarx ONE** - -Le connecteur Checkmarx ONE de DefectDojo appelle l'API Checkmarx pour récupérer les données. - -#### **Mappages du Connecteur** - -1. Saisissez votre **Tenant Name** dans le champ **Checkmarx Tenant**. Ce nom doit être visible sur la page de connexion de Checkmarx ONE, dans le coin supérieur droit : -" Tenant : \<**votre nom de tenant**\> " -​ -![image](images/connectors_tool_reference_2.png) - -2. Saisissez une clé API valide. Vous devrez peut-être en générer une nouvelle : consultez la [documentation de l'API Checkmarx](https://docs.checkmarx.com/en/34965-68618-generating-an-api-key.html#UUID-f3b6481c-47f4-6cd8-9f0d-990896e36cd6_UUID-39ccc262-c7cb-5884-52ed-e1692a635e08) pour plus de détails. -3. Saisissez l'emplacement de votre tenant dans le champ **Location**. Cette URL est formatée comme suit : -​`https://.ast.checkmarx.net/` . Votre région se trouve au début de votre URL Checkmarx lorsque vous utilisez l'application Checkmarx. **** est le serveur US principal (qui n'a pas de préfixe de région). - -#### **Gestion des branches** - -Par défaut, chaque synchronisation importe les constatations du **seul scan terminé le plus récent d'un projet, quelle que soit la branche**. Si votre CI analyse de nombreuses branches, la branche qui a été analysée en dernier « remporte » cette synchronisation : les constatations qui n'existent que sur d'autres branches ne sont pas importées, et la réconciliation de fermeture des anciennes constatations lors de la synchronisation peut faire osciller des constatations entre ouvert et fermé à mesure que différentes branches deviennent tour à tour le scan le plus récent. - -Deux champs facultatifs contrôlent ce comportement : - -- **Branch** : épingle chaque projet à un nom de branche unique — seuls les scans de cette branche sont importés. Il s'agit d'une valeur globale unique pour l'ensemble du connecteur, ce qui convient aux parcs où chaque projet utilise la même branche pérenne (par ex. `main`). - - Un **caractère générique `*`** est pris en charge. Une valeur Branch contenant `*` sélectionne *toutes* les branches correspondantes plutôt qu'une seule — par exemple `release/*` importe chaque branche de release, et `*` correspond à toutes les branches. Combiné avec **Track Scanned Branches**, c'est le moyen de suivre une famille de branches sans toutes les suivre. - - Si un caractère générique ne correspond à **aucune** branche dans la fenêtre de scan, cette synchronisation est **ignorée** plutôt que traitée comme « la branche n'a aucune constatation » — ainsi, un motif qui ne correspond temporairement à rien ne peut pas fermer toutes les constatations de l'actif. -- **Track Scanned Branches** : lorsque cette option est activée, chaque synchronisation recherche toutes les branches ayant un scan terminé dans l'historique récent des scans du projet et importe **le dernier scan terminé de chaque branche**, avec une réimportation par branche. Les constatations de chaque branche vivent dans leur propre engagement sur l'actif mappé, nommé « \ \- \ », si bien que la fermeture des constatations obsolètes est limitée à chaque branche : un correctif fusionné sur une branche ne peut jamais fermer les constatations d'une autre branche. La branche principale du projet (telle que rapportée par Checkmarx) est importée en premier, de sorte que les réapparitions d'une même constatation sur d'autres branches se dédupliquent par rapport à l'originale de la branche principale. - -Remarques sur **Track Scanned Branches** : - -- **Vérifiez quel comportement par défaut s'applique à vous.** Le suivi des branches est **activé par défaut pour les nouvelles installations**. Les installations antérieures à ce changement conservent leur comportement précédent ; l'option reste donc désactivée pour elles tant que quelqu'un ne l'active pas. -- Lorsque les deux champs sont renseignés, seule la **Branch** épinglée est suivie — y compris lorsque cette valeur Branch est un motif générique, auquel cas toutes les branches correspondant au motif sont suivies. -- Une branche qui cesse d'être analysée (fusionnée ou supprimée) cesse de recevoir des mises à jour : son engagement reste visible avec ses dernières constatations connues, que vous pouvez examiner et fermer en masse. -- Désactiver l'option ultérieurement est sans risque : les engagements par branche cessent simplement de recevoir des imports, et l'engagement par défaut reprend lors de la prochaine synchronisation. -- Les Connecteurs réconcilient l'état selon le calendrier de synchronisation. Le suivi des branches rend chaque synchronisation complète à travers les branches ; il ne rend pas les données en temps réel entre deux synchronisations. - -## **Cloudflare** - -Le connecteur Cloudflare importe les **insights Security Center** — des problèmes de posture de sécurité que Cloudflare signale sur votre compte et vos zones, comme un enregistrement DMARC manquant, le DNSSEC non activé, ou un problème de certificat. DefectDojo crée un Enregistrement pour chaque zone (domaine) ayant des insights ouverts, ainsi qu'un Enregistrement au niveau du compte pour les insights qui ne sont liés à aucune zone spécifique. - -#### Prérequis - -Vous aurez besoin d'un **jeton API** Cloudflare (et non de l'ancienne Global API Key). Créez-en un sous **My Profile > API Tokens > Create Token** dans le tableau de bord Cloudflare. L'option la plus rapide est le modèle **« Read all resources »** ; pour un jeton à privilège minimal, accordez **Zone > Zone > Read** (toutes les zones) ainsi qu'un accès en lecture au niveau du compte pour Security Center. - -#### Mappages du Connecteur - -1. Saisissez `https://api.cloudflare.com/client/v4` dans le champ **Location**. -2. Saisissez le jeton API dans le champ **Secret**. -3. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -DefectDojo découvre automatiquement les comptes et zones auxquels le jeton a accès — aucun ID de compte n'est requis. Seuls les insights ouverts (actifs, non ignorés) sont importés ; les insights que vous résolvez ou ignorez dans Cloudflare sont donc automatiquement atténués dans DefectDojo lors de la prochaine synchronisation. - -## **Cobalt.io** - -Le connecteur Cobalt.io utilise l'API Cobalt.io (v2) pour récupérer les résultats de pentest de votre organisation Cobalt.io. DefectDojo découvre chaque organisation à laquelle votre jeton d'API a accès et crée un enregistrement distinct pour chaque **actif** (l'unité que Cobalt teste). - -#### Prérequis - -Vous aurez besoin d'un **jeton d'API personnel** Cobalt.io. Nous recommandons de créer un compte de service dédié pour DefectDojo afin de distinguer clairement l'activité automatisée des actions manuelles de l'équipe. Générez un jeton depuis **Settings \> API Tokens** dans l'interface Cobalt.io. Les jetons d'organisation sont découverts automatiquement \- vous n'avez pas besoin de les fournir. - -#### Mappages du connecteur - -1. Saisissez l'URL de base de l'API Cobalt.io dans le champ **Location** : `https://api.cobalt.io` (ou votre hôte régional, par exemple `https://api.us.cobalt.io`). -2. Saisissez votre **jeton d'API personnel** dans le champ **Secret**. -3. Facultativement, saisissez un **Organization Token** pour limiter la synchronisation à une seule organisation. Si ce champ est laissé vide, DefectDojo synchronise toutes les organisations auxquelles le jeton d'API personnel a accès. - -DefectDojo associe chaque **actif** Cobalt.io à un enregistrement distinct. Les constatations sont importées pour chaque actif associé, leur état Cobalt.io (par exemple `valid_fix`, `wont_fix`, `invalid`) déterminant le statut de la constatation dans DefectDojo. - -## **Contrast** - -Le connecteur Contrast utilise l'API REST Contrast Assess pour importer les vulnérabilités des applications. DefectDojo découvre les applications de votre organisation Contrast et crée un enregistrement pour chacune d'elles. - -#### Prérequis - -Vous aurez besoin de quatre valeurs provenant de Contrast. Nous recommandons de créer un compte de service dédié afin que l'activité automatisée soit facile à distinguer des actions manuelles de votre équipe. Dans l'interface Contrast, sous **User Settings > Profile > Your Keys**, vous trouverez : - -* Votre **API Key** d'organisation. -* Votre **Service Key** personnelle. -* Le **username** auquel appartiennent ces identifiants (l'e-mail de connexion du compte). -* Votre **Organization ID** — l'UUID de l'organisation depuis laquelle importer, également affiché sous **Organization Settings**. - -#### Mappages du connecteur - -1. Saisissez l'URL de base que vous utilisez pour accéder à Contrast dans le champ **Location** — pour le produit hébergé, il s'agit généralement de `https://app.contrastsecurity.com` (ou de l'URL de votre Team Server régional / auto-hébergé). -2. Saisissez l'e-mail de connexion du compte dans le champ **Username**. -3. Saisissez l'**API Key** de l'organisation dans le champ **API Key**. -4. Saisissez la **Service Key** personnelle dans le champ **Service Key**. -5. Saisissez l'**Organization ID** (UUID) dans le champ **Organization ID**. -6. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque application Contrast devient un enregistrement, et ses vulnérabilités sont importées comme constatations. - -## **Coverity** - -Le connecteur Coverity importe des constatations depuis un serveur **Coverity Connect**. DefectDojo crée un enregistrement pour chaque **projet** Coverity. - -#### Mappages du connecteur - -1. Saisissez l'URL de votre serveur Coverity Connect dans le champ **Location**. -2. Saisissez le **username** Coverity Connect dans le champ **Username**. -3. Saisissez le mot de passe ou la clé d'authentification de l'utilisateur dans le champ **Secret**. -4. Facultativement, définissez un **View Name** pour sélectionner la vue d'issues enregistrée que le connecteur doit lire. Laissez vide pour utiliser la vue par défaut, **Outstanding Issues**. -5. Facultativement, définissez **Import All Issue Kinds** sur `true` pour élargir l'import au-delà du filtre d'issues Security and Quality (`RESOURCE_LEAK`) par défaut. - -## **CrowdStrike Falcon** - -Le connecteur CrowdStrike Falcon importe les **vulnérabilités Spotlight** et les **détections EDR** depuis la plateforme Falcon, sous forme de deux types de constatations distincts (`CrowdStrike:Spotlight` et `CrowdStrike:Detections`). DefectDojo crée un enregistrement pour chaque **hôte** Falcon. - -#### Prérequis - -Un **client API** Falcon (Client ID et secret), créé dans la console Falcon sous **Support \> API Clients and Keys**. Accordez-lui les scopes correspondant aux données que vous souhaitez importer : **Hosts: Read** (requis, pour la découverte des hôtes), **Vulnerabilities (Spotlight): Read** (pour les constatations Spotlight) et **Alerts: Read** (pour les détections EDR). Les deux types de constatations sont indépendants — si le client ne dispose pas d'un scope, ce type de constatation est ignoré plutôt que de faire échouer la synchronisation ; ainsi, un client sans **Alerts: Read** importe tout de même les vulnérabilités Spotlight. - -#### Mappages du connecteur - -1. Saisissez l'URL de base de l'API de votre cloud Falcon dans le champ **Location**, en fonction de la région de votre console — par exemple `https://api.crowdstrike.com` (US\-1), `https://api.us-2.crowdstrike.com` (US\-2), `https://api.eu-1.crowdstrike.com` (EU\-1), ou `https://api.laggar.gcw.crowdstrike.com` (US\-GOV\-1). -2. Saisissez le Client ID du client API dans le champ **Client ID**. -3. Saisissez le secret du client API dans le champ **Client Secret**. -4. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque hôte Falcon devient un enregistrement, nommé d'après son nom d'hôte, son OS et son type. Seules les vulnérabilités Spotlight à l'état **open** et **reopened** sont importées ; une réimportation clôt donc les constatations corrigées. - -## **Deepfence ThreatMapper** - -Le connecteur Deepfence ThreatMapper utilise l'API REST de la console de gestion [ThreatMapper](https://github.com/deepfence/ThreatMapper) pour importer les résultats des **scans de vulnérabilités**. DefectDojo découvre chaque nœud scanné par ThreatMapper — une image de conteneur, un hôte ou un conteneur — et crée un enregistrement pour chacun, puis importe le scan complété le plus récent de ce nœud sous forme de constatations. - -#### Prérequis - -Vous aurez besoin d'un **jeton d'API** ThreatMapper, disponible dans la console sous **Settings → User Management** (la clé d'API de votre utilisateur). Le connecteur l'échange contre un jeton d'accès de courte durée à chaque synchronisation ; le jeton d'API n'est jamais journalisé. - -#### Mappages du connecteur - -1. Saisissez l'URL de votre console ThreatMapper dans le champ **Location** (par exemple `https://threatmapper.example.com`). -2. Dans le champ **Secret**, saisissez le jeton d'API ThreatMapper. -3. Si votre console utilise un certificat auto-signé, définissez **Skip TLS Verification** sur `true`. -4. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -DefectDojo associe chaque **nœud** scanné à un enregistrement et chaque **CVE** de son dernier scan de vulnérabilités complété à une constatation. La sévérité provient de la notation propre à ThreatMapper, et le paquet affecté, le score CVSS, la version corrigée (utilisée comme atténuation), les liens de référence et un bloc de détails sont repris. Les constatations sont enregistrées comme constatations dynamiques et dédupliquées sur le nœud, le CVE, le paquet et le chemin du paquet. - -Pour plus d'informations, consultez la [documentation ThreatMapper](https://community.deepfence.io/threatmapper/docs/v2.5/). - -## Dependency\-Track - -Ce connecteur récupère les données d'une instance Dependency\-Track sur site, via l'API REST. - -​**Mappages du connecteur** - -1. Saisissez l'URL de votre serveur Dependency\-Track local dans le champ **Location**. -2. Saisissez une clé d'API valide dans le champ **Secret**. - -Pour générer une clé d'API Dependency\-Track : - -1. **Access Management** : accédez à Administration \> Access Management \> Teams dans l'interface Dependency\-Track. -2. **Teams Setup** : vous pouvez créer une nouvelle équipe ou en sélectionner une existante. Les équipes permettent de gérer l'accès à l'API en fonction de l'appartenance à un groupe. -3. **Generate API Key** : sur la page de détails de l'équipe sélectionnée, trouvez la section « API Keys ». Cliquez sur le bouton \+ pour générer une nouvelle clé d'API. -4. **Assign Permissions** : dans la section « Permissions » de la page de l'équipe, cliquez sur le bouton \+ pour ouvrir le sélecteur de permissions. Choisissez les permissions **VIEW\_PORTFOLIO** et **VIEW\_VULNERABILITY** pour activer l'accès API aux portefeuilles de projets et aux détails des vulnérabilités. -5. Cliquez sur « **Select** » pour confirmer et enregistrer ces permissions. - -Pour plus d'informations, consultez la **[documentation Dependency\-Track](https://docs.dependencytrack.org/integrations/rest-api/)**. - -## **Docker Scout** - -Le connecteur Docker Scout utilise l'API de l'exportateur de métriques Docker Scout pour rendre compte de la posture de vulnérabilité des images de votre organisation. DefectDojo découvre chaque flux (stream) Docker Scout (vos environnements d'exécution) et importe un résumé des vulnérabilités et de la conformité aux politiques pour chacun. - -#### Prérequis - -Vous aurez besoin d'un jeton d'accès personnel Docker créé par un **owner** d'une organisation Docker **inscrite à Docker Scout**. L'exportateur de métriques est une fonctionnalité au niveau de l'organisation ; un compte personnel, ou une organisation non inscrite à Docker Scout, ne renverra donc aucune donnée. - -Créez le jeton depuis les paramètres de votre compte Docker, sous **Personal access tokens**, et notez votre **espace de noms d'organisation** Docker, qui vous sera également nécessaire. - -#### Mappages du connecteur - -1. Saisissez `https://api.scout.docker.com` dans le champ **Location**. -2. Saisissez votre jeton d'accès personnel Docker dans le champ **Secret**. -3. Saisissez votre espace de noms **Organization** Docker. -4. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. Les constatations d'une sévérité inférieure à celle sélectionnée ne seront pas importées. - -DefectDojo crée un enregistrement distinct pour chaque flux Docker Scout, et importe une constatation par sévérité pour les vulnérabilités que Docker Scout comptabilise dans ce flux, ainsi qu'une constatation pour chaque image qui échoue à votre politique Docker Scout. L'API de métriques de Docker Scout renvoie des comptages agrégés plutôt que des CVE individuels ; ces constatations résument donc la posture d'un flux. Ouvrez le flux dans Docker Scout pour obtenir le détail par image et par CVE. - -Pour plus d'informations, consultez la [documentation Docker Scout](https://docs.docker.com/scout/). - -## **Endor Labs** - -Le connecteur Endor Labs utilise l'API REST Endor Labs pour synchroniser un **espace de noms (namespace)** Endor Labs entier. DefectDojo découvre chaque **projet** Endor sous forme d'enregistrement et importe les constatations de ce projet, en reprenant le verdict d'**accessibilité (reachability)** d'Endor afin de vous permettre de prioriser les vulnérabilités dont le code affecté est réellement atteignable. - -#### Prérequis - -Vous aurez besoin d'une **API key** Endor Labs (un identifiant de clé accompagné de son secret) et de l'**espace de noms (namespace)** à synchroniser. Créez la clé dans la plateforme Endor Labs sous **Settings \> Access \> API Keys** ; la clé doit disposer d'un accès en lecture aux projets et constatations de cet espace de noms. - -Le connecteur s'authentifie en échangeant la clé d'API et le secret contre un jeton porteur (bearer token) de courte durée — le secret n'est utilisé que pour cet échange et n'est jamais stocké en clair. - -#### Mappages du connecteur - -1. Saisissez `https://api.endorlabs.com` dans le champ **Location**. Si votre tenant est hébergé dans une autre région, utilisez plutôt l'URL de base de l'API de cette région. -2. Saisissez le **Namespace** Endor Labs à synchroniser (par exemple `your-org` ou `your-org.team`). -3. Saisissez l'identifiant de l'**API Key**. -4. Saisissez l'**API Secret** associé à la clé. -5. Facultativement, définissez **Traverse Child Namespaces** sur `true` pour importer également les constatations des espaces de noms enfants de l'espace de noms configuré. -6. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. Les constatations d'une sévérité inférieure à celle sélectionnée ne sont pas importées. - -DefectDojo crée un enregistrement pour chaque projet Endor Labs de l'espace de noms et importe ses constatations, en associant les niveaux de sévérité Endor aux sévérités DefectDojo, les identifiants CVE/GHSA et le score CVSS de chaque vulnérabilité, ainsi que les étiquettes d'accessibilité d'Endor. Le verdict d'accessibilité (par exemple *Reachable — vulnerable function is called* ou *Unreachable*) est présenté comme l'Impact de la constatation et comme une étiquette. - -Pour plus d'informations, consultez la **[documentation de l'API REST Endor Labs](https://docs.endorlabs.com/rest-api/)**. - -## **Edgescan** - -Le connecteur Edgescan utilise l'API REST Edgescan pour importer les vulnérabilités ouvertes de l'ensemble de votre compte Edgescan. DefectDojo énumère chaque **actif** Edgescan et crée un enregistrement pour chacun, puis importe les vulnérabilités ouvertes de cet actif sous forme de constatations — il n'y a pas de configuration par actif. - -#### Prérequis - -Vous aurez besoin d'un jeton d'API Edgescan. Créez-en un depuis votre compte Edgescan sous **Account settings \> API tokens** : saisissez un libellé, cliquez sur **Create**, puis copiez le jeton généré (il n'est affiché qu'une seule fois). Nous recommandons un compte dédié pour le connecteur afin que l'activité automatisée soit facile à distinguer. - -#### Mappages du connecteur - -1. Saisissez votre URL Edgescan dans le champ **Location** — `https://live.edgescan.com` pour la plateforme hébergée standard, ou l'hôte de votre tenant si différent. -2. Saisissez votre jeton d'API Edgescan dans le champ **Secret**. Il est envoyé dans l'en-tête `X-API-TOKEN`. -3. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque actif Edgescan devient un enregistrement, et chaque vulnérabilité ouverte sur cet actif est importée comme constatation. La sévérité est convertie de l'échelle numérique d'Edgescan (1–5) vers l'échelle Info–Critique de DefectDojo, et les références CVE, la CWE, ainsi qu'un vecteur CVSS v3 sont inclus lorsqu'Edgescan les fournit. - -## **Escape** - -Le connecteur Escape utilise l'API [Escape](https://escape.tech) pour importer des **constatations de sécurité API (DAST)**. DefectDojo énumère chaque organisation à laquelle le jeton a accès ainsi que chaque application qu'elle contient, crée un enregistrement pour chaque application ayant fait l'objet d'un scan, et importe les issues du dernier scan de cette application sous forme de constatations — il n'y a pas de configuration par application. - -#### Prérequis - -Vous aurez besoin d'une **API key** Escape, créée dans l'application Escape sous **Settings → API keys**. La clé est envoyée dans l'en-tête `Authorization: Key` et n'est jamais journalisée. - -#### Mappages du connecteur - -1. Laissez le champ **Location** vide pour utiliser `https://public.escape.tech/v2`, ou saisissez explicitement l'hôte de votre API Escape. -2. Saisissez la clé d'API Escape dans le champ **Secret**. -3. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -DefectDojo associe chaque **application** à un enregistrement et chaque **issue** de scan à une constatation : la sévérité provient de la notation d'Escape (Critical/High/Medium/Low), la CWE est reprise, la catégorie OWASP et la méthode HTTP deviennent des étiquettes, l'URL affectée devient le point de terminaison, et les recommandations de remédiation sont incluses. Les constatations sont enregistrées comme constatations dynamiques et dédupliquées sur l'identifiant d'issue Escape. - -Pour plus d'informations, consultez la [documentation de l'API Escape](https://docs.escape.tech/). - -## **Fairwinds Insights** - -Le connecteur Fairwinds Insights utilise l'API REST [Fairwinds Insights](https://insights.fairwinds.com) pour importer des **constatations de sécurité Kubernetes** sur l'ensemble de votre organisation. DefectDojo énumère chaque **cluster** actif et crée un enregistrement pour chacun, puis importe les **action items** de sécurité de ce cluster \(provenant de Polaris, Trivy, Kube\-bench, OPA et des autres rapports Insights\) sous forme de constatations — il n'y a pas de configuration par cluster. - -#### Prérequis - -Vous aurez besoin d'un nom d'**organisation** Fairwinds Insights et d'un **jeton d'API**. Créez le jeton dans l'application Insights sous **Organization Settings \> Tokens** ; un jeton `read_only` suffit. Le jeton est limité à l'organisation (org-scoped) et est envoyé comme jeton porteur (bearer token) ; il n'est jamais journalisé. - -#### Mappages du connecteur - -1. Laissez le champ **Location** vide pour utiliser `https://insights.fairwinds.com`, ou saisissez explicitement l'hôte de votre instance Insights. -2. Saisissez votre nom d'**Organization** Insights (le slug affiché dans l'URL de votre tableau de bord). -3. Saisissez le jeton d'API Insights dans le champ **Secret**. -4. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -DefectDojo associe chaque **cluster** actif à un enregistrement et chaque **action item** de sécurité à une constatation : la sévérité provient du score numérique de Fairwinds \(converti vers l'échelle Info–Critique de DefectDojo\), le rapport Fairwinds à l'origine de l'élément \(`polaris`, `trivy`, `kube-bench`, ...\) devient une étiquette d'outil, la ressource Kubernetes affectée et l'image de conteneur sont incluses, et les identifiants CVE éventuels sont extraits. Les constatations sont enregistrées comme constatations statiques et dédupliquées sur l'identifiant d'action item Fairwinds. - -Pour plus d'informations, consultez la [documentation de l'API Fairwinds Insights](https://insights.docs.fairwinds.com/technical-details/api/). - -## **Fortify** - -Le connecteur Fortify importe les résultats SAST/DAST de Fortify (OpenText/Micro Focus), couvrant les deux éditions qui partagent la plateforme : **SSC** (Software Security Center, auto-hébergé) et **Fortify on Demand (FoD)** (SaaS). Il synchronise l'ensemble du compte : DefectDojo découvre chaque application (version de projet SSC / release FoD) et crée un enregistrement pour chacune, puis importe les issues de cette application sous forme de constatations. - -#### Prérequis - -- **SSC** : un **FortifyToken** — créez-en un dans l'interface SSC sous **Administration → Token Management** (un CIToken/UnifiedLoginToken). -- **FoD** : une **clé d'API OAuth2** — un Client ID et un Client Secret depuis **Settings → API** (avec le scope `api-tenant`). - -Le jeton et le secret OAuth ne sont jamais journalisés. - -#### Mappages du connecteur - -1. Saisissez l'URL de base de Fortify dans le champ **Location** : pour SSC, l'hôte de votre serveur (le connecteur ajoute `/ssc/api/v1`) ; pour FoD, l'hôte de l'API de votre région, par exemple `https://api.ams.fortify.com`. -2. Définissez **Edition** sur `SSC` ou `FoD`. -3. Pour **FoD**, saisissez le **Client ID** OAuth ; laissez-le vide pour SSC. -4. Dans **Token / Client Secret**, saisissez le FortifyToken SSC ou le client secret OAuth FoD. -5. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -DefectDojo associe chaque **application** Fortify à un enregistrement et chaque **issue** à une constatation : la sévérité provient de la notation **friority** propre à Fortify (Critical/High/Medium/Low), le titre combine la catégorie de l'issue avec son fichier et sa ligne, et le chemin du fichier, la ligne, le kingdom, l'analyzer et le type de moteur sont repris. Les issues provenant des moteurs d'analyse statique (SCA) sont enregistrées comme constatations statiques et les issues WebInspect (DAST) comme constatations dynamiques ; les issues supprimées, retirées ou masquées sont ignorées, les issues auditées « Not an Issue » sont marquées Faux positif, et les issues « Exploitable » / revues sont marquées Vérifié. - -Pour plus d'informations, consultez la documentation de l'API [Fortify SSC](https://www.microfocus.com/documentation/fortify-software-security-center/) et [Fortify on Demand](https://api.ams.fortify.com/swagger/ui). - -## **GitGuardian** - -Le connecteur GitGuardian utilise l'API REST GitGuardian pour importer des **incidents de secrets** — des identifiants exposés que GitGuardian a détectés sur l'ensemble de vos sources surveillées. DefectDojo crée un enregistrement pour chaque source surveillée (dépôt ou périmètre) ayant actuellement des incidents ouverts, et importe chaque incident ouvert sous forme de constatation. - -Pour votre sécurité, le connecteur n'importe que les **métadonnées** de l'incident — le détecteur, la sévérité, la validité, le statut, et un lien de retour vers GitGuardian. La valeur du secret exposé elle-même n'est jamais récupérée ni stockée par DefectDojo ; suivez le lien dans chaque constatation pour examiner les emplacements concernés dans GitGuardian. - -#### Prérequis - -Vous aurez besoin d'une clé d'API GitGuardian. Nous recommandons un **jeton de compte de service (Service Account token)** (plutôt qu'un jeton d'accès personnel) afin que l'activité automatisée soit facile à distinguer. Créez-le sous **API** dans le tableau de bord GitGuardian et accordez ces scopes en lecture : - -* `incidents:read` -* `sources:read` - -#### Mappages du connecteur - -1. Saisissez l'URL de l'API GitGuardian dans le champ **Location** : `https://api.gitguardian.com` pour la plateforme SaaS, ou l'URL de l'API de votre instance auto-hébergée. -2. Saisissez la clé d'API dans le champ **Secret**. - -Seuls les incidents à l'état **open** (statut `TRIGGERED` ou `ASSIGNED`) sont importés ; les incidents que vous résolvez ou ignorez dans GitGuardian sont automatiquement atténués dans DefectDojo lors de la prochaine synchronisation. Un secret confirmé actif (validité *valid*) est importé comme une constatation vérifiée. - -## **GitHub** - -Le connecteur GitHub est un **connecteur d'actifs (Asset Connector)** : il énumère les dépôts auxquels votre jeton a accès et crée un actif DefectDojo pour chacun, regroupés en organisations par propriétaire GitHub (organisation ou utilisateur). Aucune constatation n'est importée. - -**Remarque :** ce connecteur importe uniquement l'**inventaire** de vos dépôts. Pour importer les alertes de sécurité GitHub — code scanning, Dependabot et secret scanning — sous forme de constatations, utilisez le connecteur **GitHub Advanced Security** distinct décrit plus bas. Les deux sont indépendants et peuvent être exécutés ensemble. - -#### Prérequis - -Le connecteur s'authentifie avec un **jeton d'accès personnel** GitHub et ne lit que les **métadonnées** du dépôt (nom, description, URL et propriétaire) — il n'accède ni à votre code, ni à vos issues, ni à vos alertes de sécurité. Il importe chaque dépôt dont le compte du jeton est propriétaire, collaborateur, ou membre de l'organisation propriétaire ; vérifiez donc que le compte du jeton peut voir les dépôts que vous souhaitez refléter. Nous recommandons un compte de service dédié. - -Le jeton n'a besoin que d'un accès en lecture seule aux métadonnées du dépôt : - -- Un jeton *fine-grained* nécessite **Repository permissions → Metadata: Read-only**, accordé aux dépôts (ou à l'ensemble de l'organisation) que vous souhaitez importer. -- Un jeton *classic* nécessite le scope **`repo`** pour inclure les dépôts privés (utilisez **`public_repo`** si vous n'avez besoin que des dépôts publics), ainsi que **`read:org`** pour que les dépôts appartenant à une organisation soient résolus. - -Seul GitHub.com (y compris GitHub Enterprise Cloud) est pris en charge. GitHub Enterprise **Server** n'est pas pris en charge par ce connecteur pour le moment. - -#### Mappages du connecteur - -1. Saisissez `https://api.github.com` dans le champ **Location**. -2. Saisissez le jeton d'accès personnel dans le champ **Secret**. - -Aucune liste d'organisations ou de dépôts n'est à saisir — DefectDojo importe tous les dépôts que le jeton peut voir. Chaque dépôt devient un enregistrement nommé d'après le dépôt, regroupé par **owner** GitHub (organisation ou utilisateur). Si un dépôt est supprimé par la suite, ou si le jeton perd l'accès à celui-ci, son enregistrement associé est marqué `MISSING` lors de la prochaine synchronisation plutôt que supprimé — DefectDojo ne supprime jamais silencieusement un Produit. - -## **GitHub Advanced Security** - -Le connecteur GitHub Advanced Security importe les alertes **code scanning**, **Dependabot** et **secret scanning** de GitHub, sous forme de trois types de constatations distincts (`GitHub:CodeScanning`, `GitHub:Dependabot` et `GitHub:SecretScanning`). DefectDojo découvre chaque dépôt non archivé de l'organisation configurée et crée un enregistrement pour chacun. - -#### Prérequis - -Les fonctionnalités GitHub Advanced Security doivent être activées pour les dépôts que vous souhaitez importer. Le connecteur s'authentifie avec un **jeton d'accès personnel** GitHub : - -1. Dans GitHub, ouvrez **Settings \> Developer settings \> Personal access tokens** et créez un jeton appartenant à (ou ayant accès à) l'organisation cible. -2. Accordez-lui un accès en lecture aux alertes de sécurité : un jeton *fine\-grained* nécessite un accès **Read\-only** à **Code scanning alerts**, **Dependabot alerts** et **Secret scanning alerts** sur les dépôts de l'organisation ; un jeton *classic* nécessite les scopes **`repo`** et **`security_events`**. -3. Vérifiez que le propriétaire du jeton peut voir les dépôts que vous prévoyez d'importer — le connecteur ne voit que les dépôts auxquels le jeton a accès. - -#### Mappages du connecteur - -1. Saisissez `https://api.github.com` dans le champ **Location**. Pour GitHub Enterprise Server, utilisez `https:///api/v3`. -2. Saisissez le login de l'organisation dans le champ **Organization**. -3. Saisissez le jeton d'accès personnel dans le champ **Secret**. -4. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque dépôt non archivé devient un enregistrement, interrogé sur les trois familles d'alertes pour les alertes ouvertes. Une famille d'alertes non activée pour un dépôt est ignorée plutôt que signalée comme résolue, de sorte que les fonctionnalités désactivées ne provoquent pas de fermetures erronées. - -## **GitLab** - -Le connecteur GitLab est un **connecteur d'actifs (Asset Connector)** : il énumère chaque projet (dépôt) auquel votre jeton a accès et crée un actif DefectDojo pour chacun, regroupés en organisations par espace de noms (namespace) GitLab (groupe ou utilisateur). Aucune constatation n'est importée. - -#### Prérequis - -Vous aurez besoin d'un jeton d'accès personnel (Personal Access Token) avec le scope **read_api**. Nous recommandons de créer le jeton depuis un compte de service dédié ; le connecteur liste les projets dont ce compte est membre. - -#### Mappages du connecteur - -1. Saisissez votre URL GitLab dans le champ **Location** : `https://gitlab.com`, ou l'URL de base de votre instance auto-hébergée. -2. Saisissez le Personal Access Token dans le champ **Secret**. - -Chaque projet devient un enregistrement nommé d'après le projet, regroupé par son **namespace**. Les projets en attente de suppression dans GitLab (supprimés par un utilisateur, mais pas encore purgés par la tâche de fond de GitLab) sont exclus automatiquement ; la suppression d'un projet marque donc son enregistrement comme `MISSING` lors de la prochaine synchronisation, au lieu de laisser un actif fantôme renommé. - -## **Google Cloud Security Command Center** - -Le connecteur Google Cloud SCC utilise l'API REST Security Command Center v2 pour importer les constatations de sécurité actives de votre organisation, dossier ou projet Google Cloud. DefectDojo crée un enregistrement pour chaque **projet** Google Cloud ayant des constatations ouvertes. - -#### Prérequis - -Security Command Center doit être **activé** sur votre organisation (le niveau Standard est gratuit). Vous aurez ensuite besoin d'un compte de service capable de lister les constatations, ainsi que d'une clé JSON pour celui-ci : - -1. Dans Google Cloud, créez un compte de service — un compte dédié pour DefectDojo est recommandé. -2. Accordez-lui le rôle **Security Center Findings Viewer** (`roles/securitycenter.findingsViewer`) au niveau (organisation, dossier ou projet) que vous souhaitez importer. -3. Créez une **clé JSON** pour le compte de service et téléchargez-la. - -#### Mappages du connecteur - -1. Laissez le champ **Location** à sa valeur par défaut `https://securitycenter.googleapis.com`, sauf si vous utilisez un point de terminaison non standard. -2. Dans le champ **Parent Resource**, saisissez le périmètre depuis lequel importer : `organizations/{id}`, `folders/{id}`, ou `projects/{id}`. -3. Collez le contenu complet du fichier de **clé JSON** du compte de service dans le champ **Service Account Key**. -4. Facultativement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Seules les constatations à l'état `ACTIVE` et non mises en sourdine sont importées ; les constatations que vous désactivez ou mettez en sourdine dans SCC sont donc automatiquement atténuées dans DefectDojo lors de la prochaine synchronisation. Le projet GCP affecté par chaque constatation devient son enregistrement. - -## **Group-IB ASM** - -Le connecteur Group-IB ASM (Attack Surface Management) utilise l'API REST Group-IB ASM pour importer dans DefectDojo les **issues** (constatations) de surface d'attaque externe. DefectDojo découvre chaque **entreprise/locataire** Group-IB comme un Enregistrement distinct et importe les issues de cette entreprise de façon planifiée et incrémentale. L'actif auquel se rapporte chaque issue (un domaine, une IP ou une URL) est rattaché à la constatation résultante en tant que **Point de terminaison**. - -#### Prérequis - -Vous aurez besoin de votre identifiant de connexion Group-IB ASM et d'une clé API. Nous recommandons de créer un compte de service dédié pour DefectDojo afin de pouvoir distinguer l'activité automatisée des actions manuelles de l'équipe. - -Pour générer une clé API : - -1. Ouvrez Group-IB Attack Surface Management, cliquez sur **Help** dans le coin inférieur gauche, puis sélectionnez **API**. -2. Cliquez sur **Generate API Key** (en haut à droite, sous votre nom d'utilisateur). -3. Saisissez votre mot de passe SSO, cliquez sur **Next**, puis cliquez sur **Copy token**. -4. Stockez la clé dans un gestionnaire de secrets et prévoyez une rotation régulière. - -#### Mappages du connecteur - -Group-IB ASM s'authentifie via HTTP Basic Auth, où le nom d'utilisateur est votre identifiant de connexion ASM et le mot de passe est votre clé API. **Les deux valeurs sont requises** — la clé API seule ne suffit pas. - -1. Saisissez `https://asm.group-ib.com` dans le champ **Location**. Cette valeur est identique pour tous les locataires Group-IB ASM. -2. Saisissez votre identifiant de connexion ASM (généralement une adresse e-mail) dans le champ **Username**. -3. Saisissez votre clé API dans le champ **API Key** (Secret). -4. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. Les constatations en dessous de la sévérité sélectionnée ne sont pas importées. - -DefectDojo mappe chaque **entreprise** Group-IB comme un Enregistrement distinct, en utilisant l'identifiant de l'entreprise comme identifiant. Lors de la première synchronisation, DefectDojo réimporte l'historique récent des issues ; les synchronisations suivantes sont incrémentales et ne récupèrent que les issues modifiées depuis la dernière synchronisation (suivies via l'horodatage `lastSeen` le plus récent de chaque issue). - -#### Limiter à une seule entreprise (optionnel) - -Par défaut, le connecteur découvre automatiquement les entreprises accessibles avec vos identifiants API (via le point de terminaison ASM `clients`) et crée un Enregistrement par entreprise. C'est la configuration recommandée et elle ne nécessite aucune configuration supplémentaire. - -Si le point de terminaison `clients` n'est pas disponible pour votre locataire — par exemple lorsqu'il est réservé aux comptes partenaires/MSP —, le connecteur peut être limité à une seule entreprise en fournissant son **identifiant d'entreprise** en tant que champ spécifique à l'outil `company_id` dans la configuration du connecteur. Lorsque `company_id` est défini, DefectDojo utilise directement cette entreprise au lieu d'énumérer les entreprises. Laissez ce champ vide pour utiliser la découverte automatique. - -Consultez le manuel de l'API REST Group-IB ASM (disponible dans le produit via **Help → API**) pour plus d'informations. - -## **HackerOne** - -Le connecteur HackerOne utilise l'API REST HackerOne pour importer les rapports de votre programme de bug bounty ou de divulgation de vulnérabilités. DefectDojo crée un Enregistrement pour chaque programme auquel le jeton peut accéder et importe ses rapports en tant que constatations. - -#### Prérequis - -Le connecteur utilise l'API **customer** de HackerOne, qui nécessite un **jeton API d'organisation** — un jeton personnel provenant de vos paramètres utilisateur ne fonctionne qu'avec l'API hacker et ne permettra pas de s'authentifier ici. - -1. Dans HackerOne, accédez à **Organization Settings > API Tokens**. -2. Créez un jeton et notez à la fois l'**identifiant** et la valeur du **jeton**. Un accès en lecture au programme suffit. - -#### Mappages du connecteur - -1. Saisissez `https://api.hackerone.com` dans le champ **Location**. -2. Saisissez l'**identifiant** du jeton dans le champ **API Token Identifier**. -3. Saisissez la valeur du jeton dans le champ **API Token**. -4. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. - -Chaque programme devient un Enregistrement, et ses rapports sont importés en tant que constatations en conservant la note de sévérité HackerOne. - -## **Harbor** - -Le connecteur Harbor utilise l'API REST Harbor v2.0 pour importer les vulnérabilités des images de conteneurs sur l'ensemble de votre registre. DefectDojo énumère chaque **projet** Harbor et crée un Enregistrement pour chacun, puis parcourt les dépôts et artefacts du projet et importe les vulnérabilités de chaque artefact **scanné** — en conservant l'image (dépôt + tag/digest) comme contexte de la constatation. Il n'y a pas de configuration par image. - -#### Prérequis - -Vous aurez besoin d'un compte Harbor (ou d'un **compte robot**) disposant d'un accès pull/lecture aux projets que vous souhaitez importer. Nous recommandons un compte robot dédié : dans Harbor, ouvrez un projet (ou **Administration > Robot Accounts** pour un robot système), créez un robot avec la permission **pull** sur les dépôts et artefacts, et copiez son nom complet et son secret. Les noms de robot commencent par `robot$` par défaut, mais le préfixe est configurable selon l'instance Harbor (certaines utilisent `robot_`) — copiez le nom exactement tel qu'affiché par Harbor. Un nom d'utilisateur/mot de passe classique fonctionne aussi. - -#### Mappages du connecteur - -1. Saisissez votre URL Harbor dans le champ **Location** — par exemple `https://harbor.example.com`. DefectDojo ajoute automatiquement le chemin d'API `/api/v2.0`. -2. Saisissez le nom d'utilisateur Harbor, ou un nom de compte robot exactement tel qu'affiché par Harbor (`robot$` par défaut), dans le champ **Username**. -3. Saisissez le mot de passe ou le secret du compte robot dans le champ **Secret**. Il est envoyé via authentification HTTP Basic. -4. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. - -Chaque projet Harbor devient un Enregistrement. Pour chaque artefact ayant un scan terminé, ses vulnérabilités sont importées en tant que constatations ; le paquet/version affecté, une sévérité dérivée du CVSS, le CVE, le CWE et une remédiation (version corrigée) sont inclus lorsque Harbor les fournit. Seuls les artefacts scannés sont importés — déclenchez un scan dans Harbor pour les images qui n'ont pas encore été scannées. - -## **Have I Been Pwned** - -Le connecteur Have I Been Pwned (HIBP) utilise l'API REST HIBP pour signaler quels comptes des domaines de votre propre organisation sont apparus dans des fuites de données connues. DefectDojo découvre chaque domaine que vous avez vérifié auprès de HIBP et importe une constatation par fuite affectant ce domaine. - -#### Prérequis - -Vous aurez besoin d'une clé API Have I Been Pwned avec recherche par domaine, ce qui nécessite un abonnement de niveau **Core** ou supérieur. Vous pouvez obtenir une clé depuis votre [compte Have I Been Pwned](https://haveibeenpwned.com/API/Key). - -Vous devez également **vérifier au moins un domaine** sur votre compte HIBP avant que des données de fuite soient disponibles. HIBP permet de vérifier un domaine par enregistrement DNS TXT, balise meta, téléversement de fichier ou e-mail, sous **Domain search** dans votre compte. Tant qu'aucun domaine n'est vérifié, le connecteur ne découvre aucun domaine et n'importe aucune constatation. - -#### Mappages du connecteur - -1. Saisissez `https://haveibeenpwned.com` dans le champ **Location**. -2. Saisissez votre clé API dans le champ **Secret**. -3. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. Les constatations en dessous de la sévérité sélectionnée ne seront pas importées. - -DefectDojo crée un Enregistrement distinct pour chaque domaine que vous avez vérifié auprès de HIBP, et importe une constatation par fuite affectant les comptes de ce domaine. La sévérité de chaque constatation reflète le type de données exposées par la fuite, et sa description répertorie les comptes affectés sur votre domaine afin que votre équipe puisse agir. - -Consultez la [documentation de l'API Have I Been Pwned](https://haveibeenpwned.com/API/v3) pour plus d'informations. - -## **HCL AppScan** - -Le connecteur HCL AppScan utilise l'API REST AppScan v4 pour importer les issues depuis **AppScan on Cloud (ASoC)** ou une instance auto-hébergée **AppScan 360°** (les deux partagent la même API). Il synchronise l'ensemble du compte : DefectDojo découvre chaque application et crée un Enregistrement pour chacune, puis importe les issues de cette application (DAST, SAST et IAST) en tant que constatations. - -#### Prérequis - -Vous aurez besoin d'une **clé API** AppScan — un Key ID et un Key Secret générés dans les paramètres de votre compte AppScan (API Key). Le connecteur les échange contre un jeton de session de courte durée à chaque exécution ; le Key ID, le Key Secret et le jeton ne sont jamais journalisés. - -#### Mappages du connecteur - -1. Saisissez l'URL de la console AppScan dans le champ **Location** : pour ASoC, utilisez `https://cloud.appscan.com` (ou `https://eu.cloud.appscan.com` pour la région UE) ; pour AppScan 360°, utilisez l'hôte de votre instance. -2. Définissez **Provider** sur `ASOC` pour AppScan on Cloud, ou `A360` pour une instance AppScan 360° auto-hébergée. -3. Saisissez l'**API Key ID** et l'**API Key Secret**. -4. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. - -DefectDojo mappe chaque **application** AppScan à un Enregistrement (VEP) et chaque **issue** à une constatation : le titre est le type d'issue avec son domaine / entité / cause-id / URL / chemin ajouté ; la sévérité mappe Informational → Info (Low/Medium/High/Critical sont conservées telles quelles) ; le CWE, une description étiquetée, la remédiation et l'avis, ainsi que le point de terminaison hôte/port sont repris. Les issues issues de l'analyse statique sont enregistrées comme constatations statiques et les issues dynamiques/interactives comme constatations dynamiques ; les issues ouvertes sont actives et les issues corrigées/passées sont atténuées. - -Consultez la [documentation de l'API REST AppScan](https://help.hcl-software.com/appscan/ASoC/appseccloud_rest_apis.html) pour plus d'informations. - -## **Intigriti** - -Le connecteur Intigriti utilise l'API externe Intigriti pour les entreprises afin d'importer dans DefectDojo les **soumissions** de bug bounty / pentest. Il synchronise l'ensemble du compte de l'entreprise : DefectDojo découvre chaque programme auquel le jeton peut accéder et crée un Enregistrement pour chacun, puis importe les soumissions de ce programme en tant que constatations. - -#### Prérequis - -Vous aurez besoin d'un **jeton API d'entreprise** Intigriti. Dans le portail entreprise Intigriti, sous **Company Settings > API** (le périmètre `company_external_api`), générez un jeton d'accès avec un accès en lecture à vos programmes et soumissions. Un jeton dédié pour DefectDojo est recommandé. Le jeton est envoyé en tant que jeton Bearer et n'est jamais journalisé. - -#### Mappages du connecteur - -1. Saisissez l'URL de base de l'API externe Intigriti pour les entreprises dans le champ **Location** : `https://api.intigriti.com/external/company`. L'URL doit être en HTTPS. -2. Saisissez le jeton API d'entreprise dans le champ **Secret**. -3. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. - -DefectDojo mappe chaque **programme** Intigriti à un Enregistrement et chaque **soumission** à une constatation, indexée par le code de la soumission. La sévérité de la constatation suit la notation Intigriti (Exceptional/Critical → Critique, puis High/Medium/Low, sinon Informational), et l'état du cycle de vie de la soumission se mappe au statut de la constatation : les soumissions ouvertes/en triage sont actives, les soumissions acceptées sont vérifiées, et les soumissions fermées deviennent atténuées, doublon, hors périmètre, faux positif ou risque accepté selon leur motif de fermeture. La description de la constatation reprend le type de vulnérabilité du rapport, l'actif affecté, la preuve de concept et les réponses du chercheur. - -Consultez la [documentation de l'API Intigriti](https://kb.intigriti.com/en/articles/6117846-intigriti-api) pour plus d'informations. - -## **Intruder** - -Le connecteur Intruder utilise l'[API REST Intruder](https://developers.intruder.io/) pour importer dans DefectDojo la posture de l'ensemble de votre compte. Chaque **cible** Intruder est découverte comme un Enregistrement (Produit) ; chaque **occurrence** d'une issue sur une cible devient une Constatation. - -#### Mappages du connecteur - -1. Laissez le champ **Location** à `https://api.intruder.io/` (le serveur API Intruder par défaut). -2. Saisissez un **jeton d'accès API** Intruder dans le champ **Secret**. - -Générez un jeton d'accès dans Intruder sous **My account > API Access Tokens** (vous aurez besoin du mot de passe de votre compte pour le créer, et le jeton n'est affiché qu'une seule fois). Consultez la [documentation de l'API Intruder](https://developers.intruder.io/docs/creating-an-access-token) pour plus de détails. - -Les constatations sont dérivées par occurrence : la sévérité provient de la sévérité de l'issue, les CVE et le CVSS proviennent de l'occurrence, l'emplacement provient de la cible/du port, et une occurrence mise en sommeil (snoozed) est importée comme une constatation inactive (faux positif ou risque accepté). - -## **IriusRisk** - -Le connecteur IriusRisk utilise un jeton API pour importer les données de modélisation de menaces de votre instance IriusRisk. - -#### Prérequis - -Vous aurez besoin d'un jeton API provenant de votre compte IriusRisk. Nous recommandons de créer un compte de service dédié pour DefectDojo afin de bien distinguer l'activité automatisée des actions manuelles de l'équipe. - -Pour générer un jeton API dans IriusRisk : - -1. Connectez-vous à votre instance IriusRisk. -2. Accédez à votre **User Profile** dans le menu en haut à droite. -3. Sélectionnez **API Token** et générez un nouveau jeton. - -Consultez la [documentation de l'API IriusRisk](https://support.iriusrisk.com/hc/en-us/categories/360001148511) pour plus d'informations. - -#### Mappages du connecteur - -1. Saisissez l'URL de votre instance IriusRisk dans le champ **Location URL**. Pour les instances hébergées dans le cloud, il s'agit généralement de `https://{your-subdomain}.iriusrisk.com`. Pour les installations sur site, utilisez l'URL de base de votre instance. -2. Saisissez votre **jeton API** dans le champ **Secret**. -3. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. Les constatations en dessous de la sévérité sélectionnée ne seront pas importées. - -## **JFrog Xray** - -Le connecteur JFrog Xray utilise l'API REST JFrog Xray pour récupérer les données de vulnérabilité de vos dépôts Artifactory. DefectDojo découvrira tous les dépôts de votre instance JFrog et générera des rapports de vulnérabilité via Xray, en important les constatations de façon planifiée. - -#### Prérequis - -Vous aurez besoin d'un jeton API ayant accès aux API Artifactory et Xray. Nous recommandons de créer un compte de service dédié pour DefectDojo. Le compte nécessite : - -* Un accès en lecture aux dépôts Artifactory -* La permission de générer et consulter les rapports de vulnérabilité Xray (permission `Apply on Watches` dans Xray, ou équivalent) - -#### Mappages du connecteur - -1. Saisissez l'URL de base de votre instance JFrog dans le champ **Location**. Il doit s'agir de l'URL racine de votre instance JFrog, par exemple `https://your-instance.jfrog.io`. N'incluez pas de chemin final — DefectDojo construira automatiquement les chemins d'API appropriés. -2. Saisissez un **Reference Token** valide dans le champ **Secret**. Les jetons peuvent être générés sous **User Management > Access Tokens** dans l'interface JFrog Platform. -Vous devrez générer un **Reference Token** et utiliser cette valeur. - -Portées de jeton requises pour JFrog Xray : - -- **All Services**, car DefectDojo a besoin d'accéder à la fois aux services XRay et Artifactory -- **Manage Reports + Manage Resources** au minimum. - -Par défaut, DefectDojo mappe chaque **dépôt** Artifactory comme un Enregistrement distinct. Chaque synchronisation génère un rapport de vulnérabilité complet par dépôt via Xray, de sorte que les statuts des constatations dans DefectDojo reflètent toujours l'état actuel du dépôt. - -#### Filtre de dépôt (optionnel) - -Par défaut, le connecteur découvre **tous** les dépôts de votre instance JFrog. Sur les instances comptant un grand nombre de dépôts — dont beaucoup peuvent ne pas être pertinents pour la revue de sécurité —, la découverte peut être limitée avec le champ optionnel **Repository Filter**, sous **Import Filters** sur le formulaire du connecteur. - -Le filtre est appliqué pendant la découverte, **avant que tout travail par dépôt ne soit effectué**. Un dépôt en dehors du filtre ne coûte rien : aucun rapport Xray n'est généré pour lui et, en mode artefact, aucun de ses artefacts de premier niveau n'est énuméré. C'est donc le moyen le plus efficace de réduire à la fois le temps de synchronisation et la charge que DefectDojo impose à votre instance JFrog — plus que tout paramètre appliqué plus tard dans la synchronisation. Il est particulièrement recommandé en complément des **Artifact-Level Records** sur les grandes instances. - -**Syntaxe :** une liste de clés de dépôt séparées par des virgules. Chaque entrée peut utiliser des jokers `*` : - -* Une entrée contenant `*` est traitée comme un motif — `releases-*` correspond à toute clé de dépôt commençant par `releases-`, et `*docker-pr-local*` correspond à toute clé contenant `docker-pr-local`. Un `*` correspond à toute suite de caractères, y compris `/`. -* Une entrée sans `*` doit correspondre **exactement** à une clé de dépôt. -* Un dépôt est découvert s'il correspond à **n'importe quelle** entrée de la liste. Les espaces autour des virgules sont ignorés. - -``` -releases-*, snapshots -``` - -L'exemple ci-dessus découvre tous les dépôts dont la clé commence par `releases-`, plus le seul dépôt nommé exactement `snapshots`. - -Remarques : - -* Le filtre est une **liste d'autorisation** — une correspondance sélectionne un dépôt. Il n'existe pas de syntaxe d'exclusion ou de négation, vous ne pouvez donc pas exprimer directement « tout sauf X ». -* La correspondance est **sensible à la casse**, aussi bien pour les entrées exactes que pour les jokers. `*` est le seul caractère joker ; `?` et les plages de caractères ne sont pas pris en charge. -* **Laissez-le vide pour découvrir tous les dépôts.** Une valeur composée uniquement d'espaces ou de virgules est traitée comme vide. -* Un filtre qui ne correspond à rien ne découvre simplement rien — il n'y a pas d'erreur. Si une synchronisation ne trouve inopinément aucun dépôt, vérifiez l'entrée `repository filter scoped discovery` dans le journal du connecteur, qui indique combien de dépôts sur le total ont correspondu. -* Le champ peut être modifié après la création de la connexion. - -**Modifier le filtre ultérieurement :** les dépôts qu'un filtre nouvellement restreint exclut désormais ne sont plus découverts, et leurs Enregistrements existants suivent le cycle de vie normal des produits que l'outil ne signale plus — les Enregistrements **mappés** sont marqués `MISSING` lors de la synchronisation suivante, et les Enregistrements `NEW` non mappés sont supprimés. Les constatations déjà importées dans DefectDojo ne sont pas supprimées ; le filtre régit uniquement la découverte. - -#### Enregistrements au niveau des artefacts - -Le bouton **Artifact-Level Records** modifie la découverte pour descendre d'un niveau sous le dépôt : chaque entrée de premier niveau sous la racine d'un dépôt (pour les dépôts Docker, chaque image ; pour les dépôts génériques, chaque fichier ou dossier de premier niveau) devient son propre Enregistrement. Chaque synchronisation génère toujours un seul rapport Xray par dépôt — DefectDojo attribue chaque vulnérabilité aux artefacts qu'elle impacte, de sorte que la charge sur votre instance JFrog n'augmente pas. - -> **Vérifiez dans quel mode vous vous trouvez avant votre première synchronisation.** Artifact-Level Records est **activé par défaut pour les nouvelles installations**. Les installations antérieures à cette fonctionnalité conservent leur disposition existante au niveau du dépôt, le bouton est donc désactivé pour elles jusqu'à ce que quelqu'un l'active. Dans les deux cas, le bouton peut être modifié à tout moment — voir *Basculer une connexion existante* ci-dessous. - -Avec Artifact-Level Records activé : - -* Les dépôts restent des Enregistrements et deviennent des **actifs parents** : ils ne portent aucune constatation eux-mêmes, mais lorsque la fonctionnalité Asset Hierarchy est activée, DefectDojo relie automatiquement chaque actif artefact à son actif dépôt avec une relation `parent`. Les actifs peuvent alors être filtrés par parent/enfant, et les constatations remontent la hiérarchie. -* Une vulnérabilité qui impacte plusieurs artefacts est importée dans l'actif de chaque artefact affecté, de sorte que chaque actif affiche l'ensemble complet des constatations qui le concernent. -* Les constatations sont limitées à la **dernière build** de chaque artefact, de sorte que les constatations d'un artefact décrivent sa build actuelle plutôt que d'accumuler les résultats de toutes les builds que Xray a jamais analysées. -* Les relations hiérarchiques créées par le connecteur n'écrasent jamais les relations que vous avez créées manuellement. Si un actif a déjà un parent que vous avez attribué, le connecteur le laisse tel quel. -* Le jeton nécessite en plus un accès en lecture à l'API de stockage Artifactory (inclus dans les portées ci-dessus). - -**Basculer une connexion existante vers Artifact-Level Records :** le bouton peut être modifié à tout moment. Lors de la synchronisation suivante, de nouveaux Enregistrements d'artefacts apparaissent pour le mappage — activez **Auto Map** sur la connexion lors du basculement pour que les constatations soient transférées sans interruption. Les actifs au niveau du dépôt cessent de recevoir des constatations et leurs constatations précédemment importées sont fermées lors de leur prochaine synchronisation (les mêmes constatations sont réimportées sous les nouveaux actifs artefacts, avec un statut actualisé) ; les notes et l'historique des anciennes constatations au niveau du dépôt restent sur l'actif dépôt. Revenir en arrière inverse ce processus : les Enregistrements de dépôt recommencent à porter des constatations (les constatations précédemment fermées se rouvrent lorsqu'elles correspondent à nouveau), et les Enregistrements d'artefacts sont marqués MISSING — leurs actifs et constatations sont conservés mais cessent d'être mis à jour, afin que vous puissiez les archiver à votre convenance. - -Consultez la [documentation de l'API REST JFrog Xray](https://jfrog.com/help/r/jfrog-rest-apis/xray-rest-apis) pour plus d'informations. - -## **Jira Service Management Assets** - -Le connecteur JSM Assets est un **Connecteur d'actifs** : il énumère les objets de votre espace de travail Jira Service Management Assets (anciennement Insight) et crée un Actif DefectDojo pour chaque objet, regroupés en Organisations par schéma d'objet. Aucune constatation n'est importée. - -#### Prérequis - -* Assets nécessite un plan **Jira Service Management Premium ou Enterprise**. Sur les plans Free ou Standard, l'API Assets répond avec `403 "Access to Assets API was denied"`, même si le reste du site fonctionne. -* Le compte Atlassian utilisé doit disposer d'un **accès produit Jira Service Management** (un siège agent) sur le site — l'accès au site seul ne suffit pas. -* Créez un jeton API Atlassian classique sur [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens). Nous recommandons un compte de service dédié. - -#### Mappages du connecteur - -1. Saisissez l'URL de votre site Atlassian dans le champ **Location** : `https://{your-site}.atlassian.net`. -2. Saisissez l'e-mail du compte Atlassian auquel appartient le jeton dans le champ **Email**. -3. Saisissez le jeton API dans le champ **Secret**. - -Chaque objet Assets devient un Enregistrement nommé d'après le libellé de l'objet, regroupé par son **schéma d'objet**. - -## **Kubescape** - -Le connecteur Kubescape lit les résultats de posture Kubernetes (mauvaises configurations) produits par l'[opérateur Kubescape](https://kubescape.io/docs/install-operator/) directement depuis l'API Kubernetes du cluster — aucun compte SaaS ARMO n'est requis. Il lit les objets `WorkloadConfigurationScan` servis par l'API agrégée de stockage in-cluster de l'opérateur (`spdx.softwarecomposition.kubescape.io/v1beta1`). Chaque **espace de noms** Kubernetes disposant de résultats de posture est mappé à un Enregistrement (Produit) ; chaque contrôle échoué sur une charge de travail devient une Constatation. - -#### Prérequis - -- L'opérateur Kubescape doit être installé dans le cluster cible avec l'analyse de configuration activée (voir [Installing in your cluster](https://kubescape.io/docs/install-operator/)). Confirmez l'existence de résultats avec `kubectl get workloadconfigurationscans -A`. -- Un **kubeconfig** accordant un accès en lecture au groupe d'API `spdx.softwarecomposition.kubescape.io` (list/get sur `workloadconfigurationscans`) pour le cluster cible. - -#### Mappages du connecteur - -1. Saisissez l'URL du serveur API du cluster (ou un identifiant convivial du cluster) dans le champ **Location**. -2. Collez le **kubeconfig** du cluster cible dans le champ `kubeconfig`. Vous pouvez éventuellement définir `kube_context` pour sélectionner un contexte à l'intérieur de celui-ci, et `cluster_name` pour étiqueter les Produits découverts. -3. Chaque espace de noms disposant de résultats de posture est découvert comme un Enregistrement ; mappez ceux que vous souhaitez importer vers des Produits DefectDojo. - -Les constatations sont dérivées par contrôle échoué : le nom du contrôle et la charge de travail identifient la Constatation, la sévérité provient du facteur de score du contrôle, l'identifiant du contrôle devient l'identifiant de vulnérabilité, et chaque Constatation renvoie vers sa référence de contrôle à l'adresse `https://hub.armosec.io/docs/`. - -## **Mend** - -Le connecteur Mend (anciennement **WhiteSource**) utilise l'API Mend pour importer les constatations de sécurité de votre organisation Mend. DefectDojo crée un Enregistrement pour chaque **projet** Mend. - -#### Prérequis - -Vous aurez besoin d'un utilisateur (de service) Mend avec une **User Key** (un jeton d'accès personnel) et de l'**Organization UUID** de votre organisation Mend. Nous recommandons un compte de service dédié afin que l'activité automatisée soit facile à distinguer des actions manuelles de l'équipe. Trouvez l'Organization UUID dans l'application Mend sous **Administration > Organization UUID**. - -#### Mappages du connecteur - -1. Saisissez l'URL de l'API Mend dans le champ **Location**. Cette URL est **spécifique à la région** — utilisez l'URL de base de l'API pour la région où votre organisation Mend est hébergée. -2. Saisissez l'e-mail de connexion de l'utilisateur Mend dans le champ **Email**. -3. Saisissez votre **Organization UUID** Mend dans le champ **Organization UUID**. -4. Saisissez la **User Key** Mend dans le champ **User Key**. -5. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. - -## **Lacework / FortiCNAPP** - -Le connecteur Lacework / FortiCNAPP utilise l'API Lacework v2 pour importer les **vulnérabilités des hôtes et des conteneurs** de l'ensemble de votre compte Lacework. - -#### Prérequis - -Vous aurez besoin d'une **clé API** Lacework — un identifiant de clé API et un secret, créés dans la console Lacework sous **Settings → API keys**. Le connecteur les échange contre un jeton d'accès de courte durée à chaque synchronisation ; l'identifiant de clé, le secret et le jeton ne sont jamais journalisés. - -#### Mappages du connecteur - -1. Saisissez l'URL de votre compte Lacework dans le champ **Location** — par exemple `https://YOUR-ACCOUNT.lacework.net` (un simple nom de compte est également accepté). -2. Saisissez l'**API Key ID** et l'**API Secret**. -3. Vous pouvez éventuellement définir une **Sévérité minimale** pour limiter les constatations importées. - -DefectDojo mappe le **compte** Lacework à un Enregistrement (le périmètre de l'ensemble du compte). Chaque vulnérabilité de **conteneur** et d'**hôte** devient une constatation : la sévérité provient de la notation propre à Lacework, le paquet et la version affectés deviennent le composant, la version corrigée devient l'atténuation, et l'image/hôte affecté est enregistré sous forme d'étiquettes. Les vulnérabilités de conteneurs sont enregistrées comme constatations statiques (scans d'image) et les vulnérabilités d'hôtes comme constatations dynamiques (scans d'hôte en cours d'exécution). - -Consultez la [documentation de l'API Lacework](https://docs.lacework.net/api/v2/docs) pour plus d'informations. - -## **Microsoft Defender** - -Le connecteur Microsoft Defender importe les constatations de vulnérabilités des appareils depuis **Microsoft Defender Vulnerability Management (MDVM)** — une constatation par combinaison appareil / version logicielle / CVE, incluant la sévérité, le score CVSS, le niveau d'exploitabilité et les mises à jour de sécurité recommandées. DefectDojo découvre vos **groupes d'appareils** Defender et crée un Record pour chacun ; les appareils qui ne sont assignés à aucun groupe d'appareils sont regroupés sous un groupe synthétique **Unassigned**. - -**Remarque :** ce Connecteur est distinct du type de scan basé sur fichier **« MSDefender Parser »**, qui importe des fichiers Defender exportés manuellement. Choisissez un seul chemin d'import par Produit afin d'éviter les constatations en double. - -#### Prérequis - -Votre tenant Microsoft doit disposer d'une licence active incluant les API d'export de vulnérabilités Defender : **Defender for Endpoint Plan 2**, **Microsoft Defender Vulnerability Management Standalone**, ou MDE P1/P2 avec l'add\-on MDVM. (Le SKU *Add\-on* MDVM seul ne suffit pas — il nécessite Defender for Endpoint Plan 2 en dessous.) - -Le connecteur s'authentifie en tant qu'**app registration** Microsoft Entra ID via le flux client credentials. Pour en créer une : - -1. Dans le [portail Azure](https://portal.azure.com), ouvrez **App registrations \> New registration**. Nommez\-la (par exemple `defectdojo-connector`), laissez les valeurs par défaut, puis sélectionnez **Register**. -2. Sur la page **Overview** de l'application, notez l'**Application (client) ID** et le **Directory (tenant) ID**. -3. Ouvrez **API permissions \> Add a permission \> APIs my organization uses** et recherchez **WindowsDefenderATP**. Si elle n'apparaît pas, le backend Defender de votre tenant n'a pas encore été provisionné : vérifiez que la licence est active, ouvrez une fois [security.microsoft.com](https://security.microsoft.com), puis réessayez après quelques minutes. -4. Choisissez **Application permissions** (*et non* Delegated — les permissions Delegated n'apparaissent jamais dans le jeton de service du connecteur), développez **Vulnerability**, cochez **Vulnerability.Read.All**, puis sélectionnez **Add permissions**. -5. Sélectionnez **Grant admin consent** et confirmez. La colonne Status doit afficher une coche verte — sans cette étape, chaque appel API renvoie une erreur 403. -6. Ouvrez **Certificates & secrets \> New client secret**, définissez une expiration, et copiez immédiatement la **Value** du secret (elle n'est affichée qu'une seule fois). Le Connecteur cesse de fonctionner à l'expiration du secret, notez donc la date. - -#### Correspondances du connecteur - -1. Saisissez `https://api.security.microsoft.com` dans le champ **Location**. -2. Saisissez le **Directory (tenant) ID** dans le champ **Tenant ID**. -3. Saisissez l'**Application (client) ID** dans le champ **Client ID**. -4. Saisissez la valeur du secret client dans le champ **Client Secret**. -5. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque groupe d'appareils Defender devient un Record. Microsoft régénère l'instantané de vulnérabilités que lit le connecteur environ toutes les 6 heures, et les appareils nouvellement intégrés peuvent mettre jusqu'à ~24 heures à produire leurs premières données de vulnérabilité — un tenant tout juste créé effectuera légitimement un Sync avec zéro constatation tant que les appareils n'auront pas été intégrés et évalués. L'activation de la licence elle\-même peut aussi prendre ~20 minutes ou plus avant d'atteindre l'API (les erreurs « No active license found » pendant cette fenêtre se résolvent d'elles\-mêmes). - -## **Microsoft Defender for Cloud** - -Le connecteur Microsoft Defender for Cloud importe les constatations de vulnérabilités de **Microsoft Defender Vulnerability Management (MDVM)** telles qu'exposées par Defender for Cloud — à la fois les constatations **serveur** (CVE du système d'exploitation et des logiciels installés sur les VM Azure) et les constatations **registre de conteneurs** (CVE des images de conteneurs), incluant la sévérité, le score CVSS, le paquet ou l'image concerné, et la remédiation. DefectDojo découvre les **abonnements** Azure que votre service principal peut lire et crée un Record pour chaque abonnement activé. - -**Remarque :** ce Connecteur est distinct du connecteur **Microsoft Defender**, qui importe les constatations d'appareils depuis l'API Defender for Endpoint. Defender for Cloud est un produit Azure avec une surface d'API différente (Azure Resource Manager / Resource Graph) et un modèle de permissions différent (Azure RBAC). Exécutez celui qui correspond à l'emplacement de vos constatations — ou les deux, si vous utilisez les deux produits. - -#### Prérequis - -Vous avez besoin d'un ou plusieurs **abonnements Azure avec Microsoft Defender for Cloud activé**, avec les plans Defender pertinents activés pour les ressources que vous souhaitez scanner (sous **Microsoft Defender for Cloud \> Environment settings**, puis sélectionnez votre abonnement) : - -* **Defender for Servers (Plan 2)** — constatations CVE du système d'exploitation et des logiciels des VM Azure (scan de vulnérabilités sans agent). -* **Defender for Containers** — constatations CVE des images du registre de conteneurs. - -Les constatations d'évaluation de vulnérabilités SQL et de configuration/posture ne sont intentionnellement **pas** importées — ce connecteur importe uniquement les vulnérabilités CVE. - -Le connecteur s'authentifie en tant qu'**app registration** Microsoft Entra ID via le flux client credentials : - -1. Dans le [portail Azure](https://portal.azure.com), ouvrez **App registrations \> New registration**. Nommez\-la (par exemple `defectdojo-connector`), laissez les valeurs par défaut, puis sélectionnez **Register**. -2. Sur la page **Overview** de l'application, notez l'**Application (client) ID** et le **Directory (tenant) ID**. -3. Ouvrez **Certificates & secrets \> New client secret**, définissez une expiration, et copiez immédiatement la **Value** du secret (elle n'est affichée qu'une seule fois). Le Connecteur cesse de fonctionner à l'expiration du secret, notez donc la date. -4. Accordez à l'application un accès en lecture à chaque abonnement que vous souhaitez importer : ouvrez **Subscriptions**, sélectionnez votre abonnement, puis **Access control (IAM) \> Add \> Add role assignment**. Sélectionnez le rôle **Security Reader** (ou **Reader**), et dans l'onglet **Members**, assignez\-le à l'application que vous avez créée — recherchez\-la par le **nom** ou l'**object ID** de l'application, car le sélecteur ne fait pas correspondre le client ID. Répétez l'opération pour chaque abonnement. - -Contrairement au connecteur Microsoft Defender basé sur les appareils, aucune permission API ni consentement admin n'est requis : l'accès à Defender for Cloud est entièrement régi par l'attribution de rôle Azure RBAC ci\-dessus. - -#### Correspondances du connecteur - -1. Saisissez `https://management.azure.com` dans le champ **Location**. (Pour les clouds souverains, utilisez le endpoint ARM correspondant, par exemple `https://management.usgovcloudapi.net`.) -2. Saisissez le **Directory (tenant) ID** dans le champ **Tenant ID**. -3. Saisissez l'**Application (client) ID** dans le champ **Client ID**. -4. Saisissez la valeur du secret client dans le champ **Client Secret**. -5. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque abonnement Azure activé devient un Record. Les constatations sont lues via Azure Resource Graph, elles apparaissent donc rapidement une fois que Defender for Cloud a scanné vos ressources — mais les scans eux\-mêmes s'exécutent selon le calendrier de Microsoft : les images du registre de conteneurs sont généralement scannées dans l'heure suivant leur push, tandis que le premier scan de vulnérabilités sans agent d'une VM peut prendre plusieurs heures. Un abonnement nouvellement activé effectuera légitimement un Sync avec zéro constatation tant que ses ressources n'auront pas été scannées. - -## **MobSF** - -Le connecteur MobSF utilise l'API REST de [Mobile Security Framework (MobSF)](https://github.com/MobSF/Mobile-Security-Framework-MobSF) pour importer les résultats d'analyse statique d'applications mobiles (APK/IPA). DefectDojo découvre chaque application scannée sur votre instance MobSF et crée un Record pour chacune, puis importe les constatations d'analyse statique de cette application. - -#### Prérequis - -Vous aurez besoin de votre **clé API REST** MobSF. Trouvez\-la sur la page d'accueil MobSF sous **API** (également indiquée dans la documentation MobSF comme la valeur `Authorization`). La clé est envoyée à chaque requête et n'est jamais journalisée. - -#### Correspondances du connecteur - -1. Saisissez l'URL de base de votre MobSF dans le champ **Location** (par exemple `https://mobsf.example.com`). -2. Dans le champ **Secret**, saisissez la clé API REST MobSF. -3. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -DefectDojo associe chaque **application** scannée à un Record et importe ses constatations depuis le rapport JSON de MobSF, réparties sur plusieurs sections — permissions de l'application, analyse de code, certificat de signature, manifeste Android, utilisation de l'API Android et analyse binaire. Chaque constatation est étiquetée **CWE 919** (mobile), et sa sévérité provient de la notation propre à MobSF (high, warning, info, secure/good) — une permission *dangerous* est traitée comme High. Les constatations sont enregistrées comme des constatations statiques et dédupliquées sur le scan, la section, le titre, la sévérité et le chemin du fichier. - -Consultez la [documentation de l'API REST MobSF](https://mobsf.github.io/docs/#/rest_api) pour plus d'informations. - -## **NeuVector** - -Le connecteur NeuVector utilise l'API REST du contrôleur [NeuVector](https://github.com/neuvector/neuvector) pour importer les **scans de vulnérabilités d'images** de conteneurs. DefectDojo découvre chaque image scannée par NeuVector et crée un Record pour chacune, puis importe le rapport de scan de cette image sous forme de constatations. - -#### Prérequis - -Vous aurez besoin d'un **nom d'utilisateur et d'un mot de passe** NeuVector pour un compte du contrôleur disposant de la permission de lire les résultats de scan. Le connecteur se connecte avec ces identifiants pour obtenir un jeton de session ; le mot de passe et le jeton ne sont jamais journalisés. - -#### Correspondances du connecteur - -1. Saisissez l'URL de votre contrôleur NeuVector dans le champ **Location**, en incluant le port de l'API REST — par exemple `https://neuvector.example.com:10443`. -2. Saisissez le **Username** et le **Password** du contrôleur. -3. Si votre contrôleur utilise un certificat auto\-signé, réglez **Skip TLS Verification** sur `true`. -4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -DefectDojo associe chaque **image** scannée à un Record et chaque **CVE** de son rapport de scan à une constatation. La sévérité provient de la notation propre à NeuVector, et le paquet et la version concernés, le score et le vecteur CVSSv3, la version corrigée (en tant que mitigation) et le lien de référence sont repris. Les constatations sont dédupliquées sur l'image, le CVE, le paquet, la version et la sévérité. - -Consultez la [documentation de l'API NeuVector](https://open-docs.neuvector.com/automation/automation) pour plus d'informations. - -## **Nuclei (ProjectDiscovery Cloud)** - -Le connecteur Nuclei utilise l'API REST de la ProjectDiscovery Cloud Platform (PDCP) pour récupérer les résultats de scan [nuclei](https://github.com/projectdiscovery/nuclei) depuis votre compte PDCP. DefectDojo découvre chaque scan du compte et crée un Record distinct pour chaque **scan**. - -#### Prérequis - -Vous aurez besoin d'une **clé API** ProjectDiscovery Cloud. Nous recommandons de créer un compte de service dédié pour DefectDojo afin de bien distinguer l'activité automatisée des actions manuelles de l'équipe. Générez une clé depuis **Settings \> API Key** dans l'interface ProjectDiscovery Cloud ([cloud.projectdiscovery.io](https://cloud.projectdiscovery.io)). Les résultats parviennent à PDCP soit depuis des scans hébergés, soit depuis le CLI nuclei exécuté avec `-dashboard`. - -#### Correspondances du connecteur - -1. Saisissez l'URL de base de l'API PDCP dans le champ **Location** : `https://api.projectdiscovery.io`. -2. Saisissez votre **clé API** dans le champ **Secret**. -3. Optionnellement, saisissez un **Team ID** pour restreindre la synchronisation à un espace de travail d'équipe (trouvable sous **Settings \> Team**). Si laissé vide, DefectDojo synchronise votre espace de travail personnel. -4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -DefectDojo associe chaque **scan** PDCP à un Record distinct et importe les constatations de ce scan pour toutes les sévérités, y compris informationnelle. - -## **OpenVAS / Greenbone** - -Le connecteur OpenVAS / Greenbone importe les **constatations de vulnérabilités réseau** d'une instance Greenbone (Greenbone Community Edition ou Greenbone Enterprise). Il communique avec `gvmd` via **GMP (Greenbone Management Protocol)** — un protocole XML sur un socket TLS, et non HTTP — et synchronise l'instance entière : il énumère les **tâches** de scan et crée un produit DefectDojo pour chacune, en important les résultats du dernier rapport de chaque tâche. - -#### Prérequis - -Un **utilisateur GMP** Greenbone (nom d'utilisateur + mot de passe) et un accès réseau au port TLS GMP de gvmd (par défaut **9390**). La pile compose de Greenbone Community Edition expose gvmd via un socket unix ; pour l'atteindre depuis un connecteur en réseau, exécutez donc le connecteur là où il peut accéder au socket, ou exposez le port TLS GMP (par exemple un pont TLS `socat` vers `gvmd.sock`). - -#### Correspondances du connecteur - -1. Saisissez l'hôte gvmd dans le champ **Location** (hôte ou `host:port`). -2. Saisissez le **Username** et le **Password** GMP. -3. Optionnellement, définissez le **GMP Port** (par défaut 9390). -4. Pour le certificat auto\-signé par défaut de gvmd, fournissez soit un **CA Certificate (PEM)** pour la vérification, soit réglez **Skip TLS Verification** sur `true`. -5. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque tâche Greenbone devient un Record. Les constatations proviennent du dernier rapport terminé de la tâche — une par ``. La sévérité est tirée du niveau de menace du résultat (les niveaux informationnels `Log`/`Debug` de Greenbone sont associés à Info), avec le score CVSS numérique enregistré ; les références CVE deviennent des identifiants de vulnérabilité, la solution du NVT devient la mitigation, et l'hôte/port de chaque résultat devient un point de terminaison. - -## Probely - -Ce connecteur utilise l'API REST de Probely pour récupérer les données. - -​**Correspondances du connecteur** - -1. Saisissez l'adresse du serveur API appropriée dans le champ **Location**. (soit soit ) -2. Saisissez une clé API valide dans le champ **Secret**. - -Vous pouvez trouver une clé API sous le menu User \> API Keys dans Probely. -Consultez la [documentation Probely](https://help.probely.com/en/articles/8592281-how-to-generate-an-api-key) pour plus d'informations. - -## Prowler - -Le connecteur Prowler utilise l'API REST **Prowler App** pour importer les constatations de posture de sécurité cloud (CSPM) depuis une instance Prowler App auto\-hébergée. DefectDojo découvre chaque **provider** (compte cloud) Prowler comme un Record et importe les constatations **FAIL** du dernier scan terminé de ce provider. - -#### Prérequis - -Vous aurez besoin d'une instance **Prowler App** auto\-hébergée en cours d'exécution, et soit d'un e\-mail + mot de passe utilisateur (pour l'authentification JWT), soit d'une **clé API** Prowler App. Les constatations n'apparaissent qu'une fois qu'un compte cloud (AWS, GCP, Azure, Kubernetes, ...) a été connecté dans Prowler App et qu'un scan a été exécuté. - -#### Correspondances du connecteur - -1. Saisissez l'URL de votre Prowler App dans le champ **Location** (par exemple `https://prowler.your-company.com`). -2. Pour l'authentification JWT, saisissez l'**Email** et le **Password** de l'utilisateur Prowler App. Vous pouvez également laisser ces champs vides et saisir une **API Key** Prowler App. Si les deux sont fournis, l'e\-mail/mot de passe (JWT) est utilisé. -3. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. Les constatations en dessous de la sévérité sélectionnée ne sont pas importées. - -DefectDojo crée un Record pour chaque provider Prowler et importe les constatations FAIL de son dernier scan terminé, en associant les sévérités Prowler aux sévérités DefectDojo, la ressource cloud concernée (ARN/resource id) comme composant, et la remédiation et le risque du contrôle dans la constatation. Les constatations mises en sourdine (muted) sont ignorées. Le compte cloud, la région et le service sont attachés en tant qu'étiquettes. - -Pour plus d'informations, consultez la **[documentation de l'API Prowler App](https://api.prowler.com/api/v1/docs)**. - -## Qualys - -Le connecteur Qualys importe les **détections de vulnérabilités hôtes VMDR** — chacune jointe aux métadonnées de la base de connaissances Qualys (QID) — depuis la Qualys Cloud Platform. DefectDojo crée un Record pour chaque **hôte** Qualys de votre abonnement. - -#### Prérequis - -Un compte utilisateur Qualys avec **accès API VMDR**, et l'**URL du serveur API (platform)** de votre abonnement — celle\-ci diffère selon l'abonnement. Trouvez\-la dans l'interface Qualys sous **Help \> About**, ou sur la page [Platform Identification](https://www.qualys.com/platform-identification/) de Qualys (par exemple `https://qualysapi.qualys.com` pour US Platform 1, ou `https://qualysapi.qg2.apps.qualys.com` pour US Platform 2). - -#### Correspondances du connecteur - -1. Saisissez l'URL de votre serveur API Qualys dans le champ **Location** (par exemple `https://qualysapi.qualys.com`). -2. Saisissez le nom d'utilisateur API Qualys dans le champ **Username**. -3. Saisissez le mot de passe API Qualys dans le champ **Secret**. -4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque hôte Qualys devient un Record. Les détections que Qualys a marquées **Fixed** sont exclues, de sorte qu'une réimportation clôt les constatations corrigées. - -## **Quay** - -Le connecteur Quay utilise l'API REST de Project Quay pour découvrir les dépôts de conteneurs et importer les rapports de vulnérabilités produits par le scanner **Clair** intégré à Quay. DefectDojo crée un Record pour chaque **dépôt** Quay et, à chaque Sync, lit le rapport de sécurité Clair du manifeste d'image de chaque tag actif. - -#### Prérequis - -Le scan de sécurité (Clair) doit être activé sur votre instance Quay, et vous aurez besoin d'un **jeton d'accès OAuth 2** Quay : - -* Dans Quay, créez (ou ouvrez) une organisation, allez dans **Applications**, créez une application OAuth, puis **Generate Token** avec au minimum le scope **Read repositories**. Une application dédiée pour DefectDojo est recommandée. -* Le jeton est envoyé comme jeton Bearer à chaque requête et n'est jamais journalisé. - -#### Correspondances du connecteur - -1. Saisissez l'URL de base de votre Quay dans le champ **Location**, par exemple `https://quay.io` ou votre instance auto\-hébergée `https://quay.example.com`. L'URL doit être en HTTPS ; n'incluez pas de chemin d'API final — DefectDojo construit automatiquement les chemins d'API. -2. Saisissez le jeton d'accès OAuth dans le champ **Secret**. -3. Optionnellement, définissez un **Namespace** pour restreindre la découverte à une seule organisation ou un seul utilisateur Quay. Laissez vide pour découvrir tous les dépôts que le jeton peut lire. -4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -DefectDojo associe chaque **dépôt** Quay à un Record. Pour chaque dépôt, il liste les tags actifs, les déduplique vers leurs manifestes d'image uniques (un manifeste partagé par plusieurs tags est scanné une seule fois), et lit le rapport Clair de chaque manifeste. Les manifestes que Clair n'a pas terminé de scanner (par exemple une liste de manifestes multi\-architecture, ou une image encore en file d'attente) sont ignorés jusqu'à un Sync ultérieur. Chaque vulnérabilité Clair devient une constatation — le paquet concerné est le composant, la version corrigée devient la mitigation, et les sévérités **Negligible**/**Unknown** de Clair sont enregistrées comme **Informational**. - -Consultez la [documentation de l'API Project Quay](https://docs.projectquay.io/api_quay.html) et la [documentation Clair](https://quay.github.io/clair/) pour plus d'informations. - -## **Rapid7 InsightAppSec** - -Le connecteur Rapid7 InsightAppSec importe les **constatations de vulnérabilités DAST** depuis la plateforme cloud InsightAppSec, enrichies avec les métadonnées de module d'attaque (par exemple *SQL Injection*), les scores CVSS, et les preuves collectées par le scan. DefectDojo crée un Record pour chaque **app** InsightAppSec. - -**Remarque :** ce Connecteur est distinct du connecteur **Rapid7 InsightVM** ci\-dessous — InsightAppSec est le produit DAST cloud de Rapid7 sur la plateforme Insight, tandis que les constatations InsightVM proviennent de votre propre Security Console. - -#### Prérequis - -Un compte de la plateforme Insight avec InsightAppSec, et une **clé API** de plateforme : dans la [plateforme Rapid7 Insight](https://insight.rapid7.com), ouvrez le menu des paramètres (icône d'engrenage) \> **API Keys** et générez une **User Key** (n'importe quel rôle) ou une **Organization Key** (administrateurs de la plateforme). Copiez la clé lorsqu'elle s'affiche — elle n'est affichée qu'une seule fois. - -Vous avez également besoin de votre **région** de plateforme, visible dans votre URL Insight (par exemple `us`, `us2`, `us3`, `eu`, `ca`, `au`, ou `ap`). - -#### Correspondances du connecteur - -1. Saisissez votre endpoint API régional dans le champ **Location** — par exemple `https://us.api.insight.rapid7.com` (remplacez `us` par votre région). -2. Saisissez la clé API de la plateforme Insight dans le champ **API Key**. -3. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque app InsightAppSec devient un Record. Seules les vulnérabilités **ouvertes** (Unreviewed ou Vérifié) sont importées — les constatations que Rapid7 a marquées Remediated, Faux positif, Ignored, ou Doublon sont exclues, de sorte qu'une réimportation les clôt dans DefectDojo. Les sévérités sont associées directement (`SAFE` et `INFORMATIONAL` sont importés comme Info). - -## **Rapid7 InsightVM** - -Le connecteur Rapid7 InsightVM importe les constatations de vulnérabilités d'actifs depuis votre **Security Console** InsightVM (API v3), enrichies avec le catalogue de vulnérabilités global de la console. DefectDojo crée un Record pour chaque **site** InsightVM. - -#### Prérequis - -Un accès réseau depuis DefectDojo vers votre Security Console, et un **compte utilisateur** de la console — son identifiant est utilisé pour l'authentification HTTP Basic. L'API de la console est servie par défaut sur le port **3780**. - -#### Correspondances du connecteur - -1. Saisissez l'URL de votre Security Console, port inclus, dans le champ **Location** — par exemple `https://console.example.com:3780`. -2. Saisissez le nom d'utilisateur de la console dans le champ **Username**. -3. Saisissez le mot de passe de la console dans le champ **Secret**. -4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque site InsightVM devient un Record ; le connecteur parcourt les actifs du site et importe leurs constatations vulnérables. - -## **runZero** - -Le connecteur runZero utilise l'API Export de runZero pour synchroniser l'inventaire d'actifs de toute votre organisation dans DefectDojo. C'est principalement un connecteur d'**actifs** : DefectDojo découvre chaque actif et crée un Record pour chacun, regroupé en un Product Type par son **site** runZero. Il peut aussi, optionnellement, importer les vulnérabilités de runZero en tant que constatations. - -#### Prérequis - -Vous aurez besoin d'un **Export Token** d'organisation depuis runZero (Account → API), préfixé par `XT`. Le jeton est scopé à l'organisation (l'organisation est encodée dans le jeton), en lecture seule, et est envoyé comme jeton Bearer — il n'est jamais journalisé. Un niveau communautaire/starter est disponible. - -#### Correspondances du connecteur - -1. Saisissez l'URL de votre console runZero dans le champ **Location**, par exemple `https://console.runzero.com`. L'URL doit être en HTTPS. -2. Saisissez l'Export Token dans le champ **Secret**. -3. Optionnellement, réglez **Import Vulnerabilities** sur `true` pour aussi importer les vulnérabilités runZero en tant que constatations ; laissez vide pour ne synchroniser que les actifs. -4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations de vulnérabilité importées (s'applique uniquement lorsque les vulnérabilités sont importées). - -DefectDojo associe chaque **actif** runZero à un Record (VEP) : le nom d'affichage provient du nom ou de l'adresse de l'actif, et son site, type, OS, adresses et étiquettes sont attachés en tant qu'attributs ; le **site** de l'actif devient son Product Type. Les actifs sont synchronisés via un export complet que DefectDojo réconcilie (ajouts/suppressions). Lorsque **Import Vulnerabilities** est activé, chaque vulnérabilité runZero devient une constatation sur son actif — en associant la sévérité, le score CVSS, le CVE, le point de terminaison du service concerné (`protocol://address:port`) et la remédiation. - -Consultez la [documentation de l'API runZero](https://help.runzero.com/) pour plus d'informations. - -## **Semgrep** - -Ce connecteur utilise l'API REST de Semgrep pour récupérer les données. - -#### Correspondances du connecteur - -Saisissez `https://semgrep.dev/api/v1/` dans le champ **Location**. - -1. Saisissez une clé API valide dans le champ **Secret**. Vous pouvez la trouver sur la page Tokens : -​ -« Settings » dans la barre de navigation de gauche \> Tokens \> Create new token ([https://semgrep.dev/orgs/\-/settings/tokens](https://semgrep.dev/orgs/-/settings/tokens)) - -Consultez la [documentation Semgrep](https://semgrep.dev/docs/semgrep-cloud-platform/semgrep-api/#tag__badge-list) pour plus d'informations. - -## **ServiceNow CMDB** - -Le connecteur ServiceNow CMDB est un **connecteur d'actifs** : au lieu d'importer des constatations, il lit les éléments de configuration (CI) de votre base de données de gestion de configuration ServiceNow et crée un Asset DefectDojo pour chaque CI, regroupé en Organizations par classe de CI. Aucune constatation n'est importée. - -#### Prérequis - -Vous aurez besoin d'une instance ServiceNow et d'un compte pouvant lire les tables CMDB via l'API Table de ServiceNow. Nous recommandons un compte de service dédié, en lecture seule, pour DefectDojo. Le compte a besoin d'un accès en lecture aux tables `cmdb_ci` que vous souhaitez importer. - -#### Correspondances du connecteur - -1. Saisissez l'URL de votre instance ServiceNow dans le champ **Location** : `https://{your-instance}.service-now.com`. -2. Sélectionnez ou créez une **Tool Configuration** ServiceNow contenant les identifiants de l'instance (le nom d'utilisateur et le mot de passe ServiceNow). - -Chaque élément de configuration devient un Record nommé d'après le CI, regroupé par sa **classe de CI** (par exemple, application, serveur, ou service métier). La Discovery et le Sync réconcilient la liste des CI : les nouveaux CI apparaissent comme des Records `NEW`, et un CI supprimé de la CMDB est marqué `MISSING` au Sync suivant afin que votre équipe puisse le trier. DefectDojo ne supprime jamais un Produit silencieusement. - -## **Shodan** - -Le connecteur Shodan utilise l'API REST de Shodan pour importer les vulnérabilités (CVE) que Shodan a observées sur vos hôtes exposés sur Internet. Vous fournissez une requête de recherche Shodan qui limite l'import à vos propres actifs ; DefectDojo crée un Record pour chaque hôte correspondant et importe ses CVE en tant que constatations. - -#### Prérequis - -Vous aurez besoin d'une clé API Shodan, disponible sur votre page **Account** Shodan. La recherche d'hôtes avec données de vulnérabilité nécessite un abonnement Shodan ou un plan API payant — le niveau gratuit ne permet pas de parcourir les pages de résultats de recherche. - -#### Correspondances du connecteur - -1. Saisissez `https://api.shodan.io` dans le champ **Location**. -2. Saisissez votre clé API Shodan dans le champ **API Key**. -3. Dans le champ **Search Query**, saisissez une requête Shodan qui limite l'import aux actifs de votre organisation — par exemple `hostname:example.com`, `net:203.0.113.0/24`, ou `org:"Example Inc"`. Seuls les hôtes correspondant à cette requête sont importés ; veillez donc à la limiter à l'infrastructure que vous possédez. -4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque hôte correspondant devient un Record, et chaque CVE détecté par Shodan sur les services exposés de cet hôte est importé en tant que constatation — la sévérité est dérivée du score CVSS, avec le contexte EPSS et CISA KEV inclus lorsqu'il est disponible. Chaque page de résultats de recherche consomme un crédit de requête Shodan. - -## SonarQube - -Le connecteur SonarQube peut récupérer des données soit depuis un compte SonarCloud, soit depuis une instance SonarQube locale. - -**Pour les utilisateurs de SonarCloud :** - -1. Saisissez https://sonarcloud.io/ dans le champ Location. -2. Saisissez une **clé API** valide dans le champ Secret. - -**Pour les utilisateurs de SonarQube (sur site) :** - -1. Saisissez l'URL de base de votre instance SonarQube dans le champ Location : par exemple `https://my.sonarqube.com/` -2. Saisissez une **clé API** valide dans le champ Secret. Il devra s'agir d'un **[User](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/)** [type de jeton API](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/). - -Le jeton devra avoir accès aux Projects, Vulnerabilities et Hotspots dans Sonar. - -Les clés API peuvent être trouvées et générées via **My Account \-\> Security \-\> Generate Token** dans l'application SonarQube. Pour plus d'informations, [consultez la documentation SonarQube](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/). - -## **Snyk** - -Le connecteur Snyk utilise l'API REST de Snyk pour récupérer les données. - -#### Correspondances du connecteur - -1. Saisissez **[https://api.snyk.io/rest](https://api.snyk.io/v1)** ou **[https://api.eu.snyk.io/rest](https://api.eu.snyk.io/v1)** (pour un déploiement régional EU) dans le champ **Location**. -2. Saisissez une clé API valide dans le champ **Secret**. Les jetons API se trouvent dans les **[paramètres du compte](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token)** [utilisateur](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token) dans Snyk. - -Consultez la [documentation de l'API Snyk](https://docs.snyk.io/snyk-api) pour plus d'informations. - -## **Socket** - -Le connecteur Socket utilise l'API [Socket.dev](https://socket.dev) pour importer des **constatations de sécurité de la chaîne d'approvisionnement logicielle** — les alertes de Socket sur vos dépendances (logiciels malveillants, typosquats, scripts d'installation, vulnérabilités connues et plus de 70 autres catégories). DefectDojo découvre chaque dépôt dans les organisations auxquelles votre jeton a accès et crée un Enregistrement pour chacun, puis importe les alertes du dernier scan complet de ce dépôt. - -#### Prérequis - -Vous aurez besoin d'un **jeton API** Socket — un jeton d'organisation créé dans le tableau de bord Socket sous **Settings → API Tokens** (avec les portées `repo:list` et de lecture des scans complets). Le jeton est envoyé en tant que jeton porteur (bearer) et n'est jamais journalisé. - -#### Mappages du connecteur - -1. Laissez le champ **Location** vide pour utiliser `https://api.socket.dev/v0`, ou saisissez-le explicitement. -2. Saisissez le jeton API Socket dans le champ **Secret**. -3. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -DefectDojo associe chaque **dépôt** à un Enregistrement et importe les alertes de son scan complet le plus récent. Chaque alerte devient une constatation : la sévérité provient de la propre notation de Socket (low, medium, high, critical), le paquet concerné devient le composant et un PURL, la catégorie de l'alerte (risque de chaîne d'approvisionnement, qualité, maintenance, vulnérabilité, licence) est enregistrée sous forme d'étiquettes, et les détails de l'alerte sont repris dans la description. Les constatations sont enregistrées comme des constatations statiques et dédupliquées sur la clé d'alerte de Socket. - -Consultez la [documentation de l'API Socket](https://docs.socket.dev/reference) pour plus d'informations. - -## **Sonatype IQ** - -Le connecteur Sonatype IQ utilise l'API REST du serveur Sonatype IQ (Nexus Lifecycle) pour importer les vulnérabilités des composants open source. Il recense chaque application de votre organisation IQ et, pour chacune, importe les vulnérabilités de composants du dernier rapport de cette application à l'étape du cycle de vie que vous configurez. DefectDojo crée automatiquement un Enregistrement pour chaque application — il n'y a pas de configuration par application. - -#### Prérequis - -Vous aurez besoin d'un compte utilisateur Sonatype IQ disposant de la permission **View IQ Elements** sur les applications que vous souhaitez importer. Sonatype recommande de s'authentifier avec un **jeton utilisateur** (généré sous **My Profile > User Token** dans IQ Server) plutôt qu'avec un mot de passe ; les deux parties du jeton correspondent aux champs Username et User Token ci-dessous. Le connecteur fonctionne aussi bien avec un serveur IQ auto-hébergé qu'avec une instance hébergée par Sonatype (SaaS). - -#### Mappages du connecteur - -1. Dans le champ **Location**, saisissez l'URL de base de votre serveur IQ — pour un serveur auto-hébergé, `https://iq.example.com` ; pour une instance hébergée par Sonatype, `https://.sonatype.app/platform`. -2. Saisissez l'utilisateur IQ (ou la partie code utilisateur de votre jeton utilisateur) dans le champ **Username**. -3. Saisissez le jeton utilisateur IQ (ou le mot de passe) dans le champ **User Token**. -4. Optionnellement, définissez un **Stage** pour choisir l'étape du cycle de vie dont le rapport est importé pour chaque application (`build`, `stage-release`, `release`, etc.). Laissez vide pour utiliser `build`. -5. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque application devient un Enregistrement, et chaque problème de sécurité du dernier rapport de cette application pour l'étape sélectionnée est importé comme constatation. La sévérité est dérivée du score numérique du problème, et les références CVE, le CWE, le vecteur CVSS et l'URL de paquet (PURL) du composant concerné sont inclus lorsqu'ils sont disponibles. -## **Sysdig Secure** - -Le connecteur Sysdig Secure importe des **constatations de vulnérabilité de conteneurs / CNAPP** depuis l'API de gestion des vulnérabilités de Sysdig Secure. Il synchronise l'intégralité du compte sur le ou les périmètres configurés et crée un produit DefectDojo pour chaque regroupement d'actifs analysé. - -#### Prérequis - -Un **jeton API** Sysdig Secure : dans Sysdig Secure, allez dans **Settings > Sysdig Secure API Token** et copiez le jeton. Vous avez également besoin de l'**URL de région** Sysdig (par exemple `https://us2.app.sysdig.com`, `https://eu1.app.sysdig.com`, ou votre hôte sur site). - -#### Mappages du connecteur - -1. Saisissez votre région/URL de base Sysdig dans le champ **Location**. -2. Saisissez le jeton API dans le champ **Secret**. -3. Optionnellement, définissez **Scopes** — une liste séparée par des virgules de `runtime`, `registry` et/ou `pipeline` (laissez vide pour `runtime`, le périmètre des charges de travail déployées). -4. Optionnellement, définissez **Runtime Product Grouping** — la façon dont les résultats runtime sont associés aux produits : `cluster`, `namespace`, `workload` ou `image` (laissez vide pour `namespace`). Les résultats registry et pipeline sont toujours regroupés par dépôt d'images. -5. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque regroupement d'actifs devient un Enregistrement. Pour chaque résultat de scan, le connecteur importe chaque paquet vulnérable comme constatation. Les constatations **Runtime** (charges de travail déployées) sont enregistrées comme des constatations dynamiques et étiquetées avec leur contexte Kubernetes cluster / namespace / workload / conteneur ; les constatations **registry** et **pipeline** sont enregistrées comme des constatations statiques d'analyse d'image. La sévérité `NEGLIGIBLE` de Sysdig est associée à Info. - -## Tenable - -Le connecteur Tenable utilise l'API REST **Tenable.io** pour récupérer les données. Les scans sont extraits du point de terminaison `/scans` de Tenable VM. - -Les connecteurs Tenable sur site ne sont pas disponibles pour le moment. - -#### **Mappages du connecteur** - -1. Saisissez dans le champ Location. -2. Saisissez une **clé API** valide dans le champ Secret. - -Consultez la [documentation de l'API Tenable](https://docs.tenable.com/vulnerability-management/Content/Settings/my-account/GenerateAPIKey.htm) pour plus d'informations. - -## **Tenable Web App Scanning** - -Le connecteur Tenable Web App Scanning importe des **constatations d'application web (DAST)** depuis Tenable Web App Scanning. Il s'agit d'un connecteur distinct de Tenable (Vulnerability Management) : les deux produits couvrent des actifs différents et se configurent indépendamment, vous pouvez donc utiliser l'un, l'autre, ou les deux. - -DefectDojo crée un Enregistrement pour chaque **application web analysée**. Les applications sont découvertes à partir de vos configurations de scan Web App Scanning ; une configuration qui n'a jamais été exécutée ne produit pas d'Enregistrement tant que son premier scan n'est pas terminé. Lorsque plusieurs configurations analysent la même application, elles partagent un seul Enregistrement. - -#### Prérequis - -Des **clés API** Tenable (une clé d'accès et une clé secrète) pour un utilisateur disposant des permissions Web App Scanning. Dans Tenable, allez dans **My Account > API Keys** pour les générer, et vérifiez que l'utilisateur peut voir les scans que vous souhaitez importer — les clés limitées à Vulnerability Management ne peuvent pas lire les données de Web App Scanning. - -Les connecteurs Tenable sur site ne sont pas disponibles pour le moment. - -#### Mappages du connecteur - -1. Saisissez dans le champ **Location**. -2. Saisissez votre **Access Key** et votre **Secret Key**. -3. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Les constatations sont importées avec la sévérité que Tenable indique pour votre compte, y compris toute sévérité que votre équipe a reclassée. Chaque constatation porte l'URL concernée comme point de terminaison, le paramètre de requête et la charge utile qui l'ont déclenchée, ainsi que la preuve et la sortie de Tenable comme étapes de reproduction, avec les valeurs CWE, CVE, CVSS et EPSS lorsque le plugin de détection les fournit. - -Seules les constatations actuellement ouvertes ou rouvertes sont importées. Une constatation que Tenable a marquée comme corrigée est fermée dans DefectDojo lors de la prochaine synchronisation. - -## **Veracode** - -Le connecteur Veracode importe les constatations d'application depuis la plateforme Veracode, réparties par type de scan en types de constatation **SAST**, **DAST**, **SCA** et **Manual**. DefectDojo crée un Enregistrement pour chaque **application** Veracode. - -#### Prérequis - -Générez un **identifiant API** Veracode pour un compte pouvant voir les applications que vous souhaitez importer : dans la plateforme Veracode, ouvrez le menu de votre compte > **API Credentials** et sélectionnez **Generate API Credentials** (voir [Gestion des identifiants API Veracode](https://docs.veracode.com/r/c_api_credentials3)). Copiez à la fois l'**API ID** et l'**API Secret Key** — la clé secrète n'est affichée qu'une seule fois. - -#### Mappages du connecteur - -1. Saisissez l'URL de base de l'API Veracode dans le champ **Location** : `https://api.veracode.com` (région commerciale), `https://api.veracode.eu` (région européenne), ou `https://api.veracode.us` (région fédérale américaine). -2. Saisissez l'API ID dans le champ **API ID**. -3. Saisissez la clé secrète API dans le champ **Secret**. -4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. - -Chaque application Veracode devient un Enregistrement. Seules les constatations **open** sont importées, donc une réimportation ferme les constatations que Veracode signale comme résolues. - -## **Wazuh** - -Le connecteur Wazuh utilise le Wazuh Indexer (OpenSearch) pour récupérer les constatations de vulnérabilité. Wazuh 4.8 et versions ultérieures stockent les CVE détectées dans l'Indexer plutôt que dans l'API du serveur Wazuh ; ce connecteur les lit donc directement dans l'index `wazuh-states-vulnerabilities-*`. - -DefectDojo crée un Enregistrement pour chaque agent Wazuh (point de terminaison) et importe les CVE détectées par cet agent comme constatations selon une planification. - -#### Prérequis - -Vous aurez besoin de : - -* L'URL de base de votre Wazuh Indexer, port inclus (l'Indexer écoute par défaut sur le port 9200). DefectDojo se connecte directement à l'Indexer, ce point de terminaison doit donc être accessible depuis DefectDojo. Pour les déploiements auto-gérés, il s'agit de l'hôte exécutant le Wazuh Indexer. Pour Wazuh Cloud, utilisez le point de terminaison de l'Indexer indiqué dans votre console Wazuh Cloud, distinct de l'URL du tableau de bord Wazuh. -* Un utilisateur et un mot de passe Indexer disposant d'un accès en lecture à l'index `wazuh-states-vulnerabilities-*`. Nous recommandons de créer un utilisateur dédié pour DefectDojo. - -La détection de vulnérabilités doit être activée dans Wazuh pour que l'index d'état des vulnérabilités soit alimenté. Consultez la [documentation de détection de vulnérabilités de Wazuh](https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html) pour plus d'informations. - -#### Mappages du connecteur - -1. Saisissez l'URL de base de votre Wazuh Indexer dans le champ **Location**, avec le schéma et le port, par exemple `https://your-indexer.example.com:9200`. N'incluez pas de chemin final. DefectDojo construit automatiquement les chemins de recherche. -2. Saisissez le nom d'utilisateur de l'Indexer dans le champ **Username**. -3. Saisissez le mot de passe de l'Indexer dans le champ **Password**. -4. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. Les constatations en dessous de la sévérité sélectionnée ne seront pas importées. - -## Wiz - -L'utilisation du connecteur Wiz nécessite la création d'un compte de service : consultez la [documentation Wiz](https://docs.wiz.io/wiz-docs/docs/service-accounts-settings#add-a-service-account) pour plus d'informations. Vous aurez besoin d'un compte Wiz pour accéder à la documentation. - -Le compte de service doit répondre à toutes les exigences suivantes. Un compte de service qui n'en respecte pas une peut tout de même s'authentifier avec succès mais n'importera rien : - -* **Type**: Custom Integration (GraphQL API). -* **API scopes**: au minimum `read:projects`, `read:issues`, et `read:vulnerabilities`. -* **Project visibility**: le compte de service doit être limité à chaque Wiz Project que vous souhaitez importer (ou à tous les Projects). Le connecteur découvre d'abord vos Wiz Projects, puis récupère les constatations de chaque Project — un compte qui peut lire les issues mais n'a de visibilité sur aucun Project ne découvre aucun Project, il n'y a donc rien à importer et aucune erreur n'est signalée par l'un ou l'autre des systèmes. - -#### **Mappages du connecteur** - -1. Saisissez votre Wiz Client ID dans le champ Client ID. -2. Saisissez le Wiz Client Secret dans le champ Secret. - -## **YesWeHack** - -Le connecteur YesWeHack utilise l'API REST de YesWeHack pour importer les rapports de vos programmes de bug bounty et de divulgation de vulnérabilités. DefectDojo crée un Enregistrement pour chaque programme auquel votre jeton a accès et importe ses rapports comme constatations. - -#### Prérequis - -Vous aurez besoin d'un **jeton d'accès personnel (PAT)** YesWeHack. Un accès en lecture à vos programmes suffit. Certains comptes exigent TOTP/MFA lors de la création d'un jeton ; une fois créé, c'est la valeur du jeton elle-même que le connecteur utilise. - -1. Dans YesWeHack, ouvrez les paramètres de votre compte et allez dans **API / Personal Access Tokens**. -2. Créez un jeton et copiez sa valeur. Elle n'est affichée qu'une seule fois. - -#### Mappages du connecteur - -1. Saisissez `https://api.yeswehack.com/` dans le champ **Location**. -2. Saisissez votre jeton d'accès personnel dans le champ **Secret**. -3. Optionnellement, définissez une **Minimum Severity** pour limiter les constatations importées. Les constatations en dessous de la sévérité sélectionnée ne seront pas importées. - -DefectDojo crée un Enregistrement distinct pour chaque programme auquel votre jeton a accès, et importe chaque rapport comme constatation. La sévérité de la constatation est déterminée par la notation CVSS du rapport (avec repli sur la priorité de triage), et son statut reflète l'état de workflow du rapport — par exemple, les rapports résolus sont importés comme atténués, et les rapports marqués comme invalides ou hors périmètre sont importés comme inactifs. diff --git a/docs/content/connectors/upstream/toolreference.ja.md b/docs/content/connectors/upstream/toolreference.ja.md deleted file mode 100644 index f2353fe28ff..00000000000 --- a/docs/content/connectors/upstream/toolreference.ja.md +++ /dev/null @@ -1,1500 +0,0 @@ ---- -title: Upstream Connectors ツールリファレンス -description: 対応している Connector ツールの一覧と、DefectDojo でのセットアップ方法 -aliases: -- /ja/import_data/pro/connectors/connectors_tool_reference/ -- /ja/en/connecting_your_tools/connectors/connectors_tool_reference ---- - -注: Upstream Connectors は DefectDojo Pro 限定の機能です。 - -対応ツール向けに Connector をセットアップする際は、そのツールの API に関する特定の情報を DefectDojo に提供する必要があります。基本的には、以下が必要です。 - -* **Location** \- 通常、ネットワーク内のツールの URL を指すフィールド -* **Secret** \- 通常は API キー - -ツールによっては、**Location** と **Secret** 以外にも追加の API 関連フィールドが必要になる場合があります。また、DefectDojo からの Connector 接続を受け入れるために、ツール側での設定変更が必要になることもあります。 - -![image](images/connectors_tool_reference.png) - -ツールごとに API の設定は異なるため、このガイドでは DefectDojo が接続できるように各ツールの API をセットアップする方法を説明します。 - -可能な限り、Connector 専用に利用する新しい「DefectDojo Bot」アカウントをセキュリティツール内に作成することをお勧めします。これにより、チームが手動で行った操作と Connector による自動操作を区別しやすくなります。 - -# **Asset Connectors** - -ほとんどの Connector はセキュリティツールから**検出事項**をインポートします。**Asset Connectors** はこれとは異なる動作をします。検出事項ではなく**アセットインベントリ**をインポートします。Asset Connector は外部プラットフォームに存在するアセット(例えば GitLab グループ内のリポジトリ)を列挙し、DefectDojo 内に対応する**製品**(アセット)と**製品タイプ**(組織)を自動的に作成・維持します。Asset Connector によって検出事項がインポートされることはありません。 - -* **Discover** と **Sync** はどちらもアセット一覧を突き合わせます。新しいアセットは `NEW` レコードとして表示され、(自動マッピングが有効な場合は自動的に)マッピングされると、DefectDojo はそのツールから導出された製品タイプ(例えば GitLab の namespace や Azure DevOps のプロジェクト)の下に製品を作成し、グループ化します。 -* アセットが後で上流側で削除された場合(例えばリポジトリが削除された場合)、次の Sync 時にマッピング済みのレコードが `MISSING` としてフラグされ、チームがトリアージできるようになります。DefectDojo が製品を無言で削除することはありません。 - -Azure DevOps、Backstage、Bitbucket、GitHub、GitLab、Jira Service Management Assets、ServiceNow CMDB は Asset Connectors です。runZero は主に Asset Connector ですが、脆弱性を検出事項としてインポートするオプションも備えています。以下に挙げるその他すべての Connector は検出事項をインポートします。 - -# **Supported Connectors** - -## **Acunetix 360** - -Acunetix 360 コネクタは、Acunetix 360 クラウドプラットフォーム(Invicti プラットフォーム)から**DAST 脆弱性の検出事項**をインポートします。DefectDojo はアカウント内でスキャンされた Web サイトを検出し、**Web サイト**ごとにレコードを作成します。Web サイトの検出事項は、その最新の完了済みスキャンから取得されます。 - -**ご注意ください:** このコネクタは(`online.acunetix360.com` のクラウド製品である)**Acunetix 360** 用です。異なる API を持つオンプレミス版の Acunetix Standard/Premium スキャナ用ではありません。 - -#### Prerequisites - -Acunetix 360 のアカウントと**API 認証情報**が必要です。Acunetix 360 でアカウントメニュー \> **API Settings** を開き、**API User ID** を確認して **API Token** を生成してください。コネクタはこれらを HTTP Basic 認証情報として使用するため、手動によるチーム操作と自動操作を区別するために専用のサービスアカウントを利用することをお勧めします。 - -#### Connector Mappings - -1. **Location** フィールドに Acunetix 360 の URL を入力します: `https://online.acunetix360.com`。 -2. **API User ID** フィールドに API User ID を入力します。 -3. **API Token** フィールドに API Token を入力します。 -4. 必要に応じて、インポートする検出事項を制限するために **Minimum Severity** を設定します。 - -スキャンされた各 Web サイトが 1 件のレコードになります。検出事項はその Web サイトの最新の完了済みスキャンから取得されます。Acunetix 360 で **Accepted Risk** または **False Positive** としてマークされた脆弱性もインポートされますが、非アクティブ(risk-accepted または false-positive)としてフラグされるため、DefectDojo 側の製品にベンダーによるトリアージ結果が反映されます。 - -## **Akamai API Security** - -Akamai API Security コネクタは API キーを使用して Akamai API からセキュリティの検出事項を取得します。DefectDojo は Akamai 環境を検出し、アカウントに設定された**Application** と **Host** ごとに個別のレコードを作成します。 - -#### Prerequisites - -Akamai API へのアクセス権を持つ API キーが必要です。自動操作とチームによる手動操作を明確に区別するため、DefectDojo 専用のサービスアカウントを作成することをお勧めします。 - -#### Connector Mappings - -1. **Location** フィールドに Akamai API のベース URL を入力します。この URL は Akamai インスタンス固有のものです。例: -2. **Secret** フィールドに有効な **API Key** を入力します。 - -DefectDojo は **Application** と **Host** をそれぞれ別のレコードとしてマッピングします。各 Application はレコード一覧に `{name} (application)` として、各 Host は `{name} (host)` として表示されます。 - -## **Anchore** - -Anchore コネクタはユーザーの API トークンを使用して Anchore Enterprise からデータを取得します。製品は「Applications」に基づいてマッピング・検出されます。Applications は Anchore 内の複数の Image で構成されます。詳細は [Anchore Enterprise Documentation](https://docs.anchore.com/current/docs/sbom_management/application_groups/application_management_anchorectl/) を参照してください。 - -#### Connector Mappings - -1. **Location** フィールドに Anchore の URL を入力します。これは Anchore にアクセスする際の URL です。 -2. Secret フィールドに有効な API Key を入力します。これは Burp Service アカウントに紐づく API キーです。 - -Anchore のトークン作成に関する詳細は、公式の [Anchore documentation](https://docs.anchore.com/current/docs/) を参照してください。 - -## **AWS Security Hub** - -AWS Security Hub コネクタは、Security Hub の API とやり取りするために AWS アクセスキーを使用します。 - -#### Prerequisites - -チームメンバーの AWS アクセスキーを使用するのではなく、DefectDojo 専用に AWS アカウント内で IAM ユーザーを作成し、そのユーザーの権限を Security Hub とのやり取りに必要な範囲に限定することをお勧めします。 - -AWS の「**[AWSSecurityHubReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubReadOnlyAccess.html)** ポリシー」は、コネクタに必要なレベルのアクセスを提供します。Connector 用にカスタムポリシーを作成したい場合は、以下の権限を含める必要があります。 - -* [DescribeHub](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_DescribeHub.html) -* [GetFindingAggregator](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingAggregator.html) -* [GetFindings](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindings.html) -* [ListFindingAggregators](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_ListFindingAggregators.html) - -実際に機能するポリシー定義は、以下のようになります。 - -``` -{ - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "AWSSecurityHubConnectorPerms", - "Effect": "Allow", - "Action": [ - "securityhub:DescribeHub", - "securityhub:GetFindingAggregator", - "securityhub:GetFindings", - "securityhub:ListFindingAggregators" - ], - "Resource": "*" - } - ] -} -``` - -**ご注意ください:** 最良の利用体験を提供するため、今後追加の API アクションが必要になる場合があり、その際はこのポリシーの更新が必要になります。 - -IAM ユーザーを作成し、適切なポリシー/ロールを使って必要な権限を割り当てたら、アクセスキーを生成し、それを使って Connector を作成します。 - -#### Connector Mappings - -1. **Location** フィールドに、[お使いのリージョンに対応する AWS API エンドポイント](https://docs.aws.amazon.com/general/latest/gr/sechub.html#sechub_region)を入力します。例えば `us-east-1` リージョンから結果を取得する場合は、以下を指定します。 - -`https://securityhub.us-east-1.amazonaws.com` -2. **Access Key** フィールドに有効な **AWS Access Key** を入力します。 -3. **Secret Key** フィールドに対応する **Secret Key** を入力します。 - -DefectDojo は Security Hub の**クロスリージョン集約**機能を使って複数のリージョンから検出事項を取得できます。[クロスリージョン集約](https://docs.aws.amazon.com/securityhub/latest/userguide/finding-aggregation.html)が有効な場合は、「**Aggregation Region**」の API エンドポイントを指定してください。追加でリンクされているリージョンについては、AWS アカウント ID とリージョン名に基づいて DefectDojo 内に ProductRecords が作成されます。 - -## **Azure DevOps** - -Azure DevOps コネクタは**Asset Connector**です。Azure DevOps 組織内のすべてのプロジェクトにある git リポジトリを列挙し、リポジトリごとに DefectDojo のアセットを作成し、Azure DevOps のプロジェクト単位で組織にグループ化します。検出事項はインポートされません。 - -#### Prerequisites - -組織用の Personal Access Token(PAT)が必要です。専用のサービスアカウントからトークンを作成することをお勧めします。必要なのは読み取りスコープのみです。 - -1. Azure DevOps で **User settings \> Personal access tokens \> New Token** を開きます。 -2. **Show all scopes** をクリックし、**Code: Read** と **Project and Team: Read** を選択します。 - -対応しているのは Azure DevOps Services(dev.azure.com)のみです。オンプレミスの Azure DevOps Server には現時点で対応していません。 - -#### Connector Mappings - -1. **Location** フィールドに組織の URL を入力します: `https://dev.azure.com/{your-organization}`。従来の `https://{your-organization}.visualstudio.com` 形式の URL も受け付けられ、余分なパスセグメント(例えば特定プロジェクトへのリンク)は無視されます。 -2. **Secret** フィールドに PAT を入力します。 - -各リポジトリは、そのリポジトリ名を冠したレコードとなり、Azure DevOps の**プロジェクト**単位でグループ化されます。無効化されたリポジトリはスキップされるため、リポジトリを無効化または削除すると、次の Sync でそのレコードは `MISSING` としてフラグされます。 - -## **Backstage** - -Backstage コネクタは**asset connector**です。検出事項をインポートする代わりに、[Backstage](https://backstage.io) の Software Catalog を DefectDojo に取り込み、製品階層とチームの所有関係をそれと同期させます。サービスインベントリと組織構造を Backstage で管理しており、DefectDojo にはそれを手作業ではなく自動的にミラーしてほしい組織向けに設計されています。 - -#### What gets mapped - -| Backstage | DefectDojo | -|---|---| -| **System** | 製品タイプ(System を持たない Component は、設定可能な「Backstage / Uncategorized」製品タイプの下にグループ化されます) | -| **Component** | 製品 — エンティティの `title`(なければ `name` にフォールバック)から命名され、カタログの description が付与されます | -| **Owning Group**(`ownedBy` リレーション) | 製品に紐づく DefectDojo のグループ(デフォルトのロール: Maintainer、設定変更可能) | -| **Owner email**(グループプロファイルの email、または User オーナーの email) | 同じ email を持つ DefectDojo ユーザーが既に存在する場合、そのユーザーが製品メンバーになります(ユーザーが新規作成されることはありません) | -| `metadata.tags`、`spec.type`、`spec.lifecycle`、namespace、domain | `backstage:` プレフィックス付きの製品タグ | -| `metadata.annotations` | レコードに(上限付きで)保存されます。特定の annotation は **Annotation Mappings** を通じて第一級の属性やタグに昇格できます | - -レコードはエンティティのサーバー側で割り当てられた `metadata.uid` をキーとするため、Backstage 上でのリネームは次回の同期でマッピング済みの製品を**その場で**更新します。重複は発生しません。製品名は常にカタログに追従します。このコネクタが管理する製品をリネームするには、Backstage 上で Component をリネームしてください(DefectDojo 側でのリネーム、または手動マッピング時に付けたカスタム名は、他の製品と衝突しない限り、次回の同期でカタログ名に合わせて調整されます)。所有者の変更は、製品のグループ割り当てを移動させます。カタログから消えた(または `backstage.io/orphan` annotation が付いた)Component は **MISSING** としてマークされます。DefectDojo が自ら製品を削除することはありません。Domain と Group の階層(親チーム)はタグ/メタデータとしてのみ記録され、追加の階層レベルを作成することはありません。 - -#### Prerequisites - -このコネクタは、Backstage バックエンドに対して**静的な external access token**で認証します。Backstage アプリの設定でトークンを定義し、(推奨として)catalog プラグインに限定してください。 - -```yaml -backend: - auth: - externalAccess: - - type: static - options: - token: ${DEFECTDOJO_BACKSTAGE_TOKEN} - subject: defectdojo-connector - accessRestrictions: - - plugin: catalog -``` - -強力なランダムトークンを生成し(例えば `openssl rand -hex 32`)、Backstage デプロイの環境変数に保存してください。詳細は [Backstage service-to-service auth documentation](https://backstage.io/docs/auth/service-to-service-auth) を参照してください。 - -#### Connector Mappings - -1. **Location** フィールドに **Backstage バックエンドのルート URL** を入力します。例: `https://backstage.example.com`(コネクタが `/api/catalog` を自動的に付加します)。これは**バックエンド**の URL である必要があり、フロントエンドの Web UI ではありません。 -2. **Secret** フィールドに静的な external access token を入力します。 - -以下はオプションのフィールドです(デフォルトのままにする場合は空欄にしてください)。 - -* **Namespaces** — インポート対象のカタログ namespace をカンマ区切りで指定します。空欄の場合はすべての namespace をインポートします。 -* **Component Types** — `spec.type` の値をカンマ区切りで指定します(例: `service,website`)。空欄の場合はすべてのタイプをインポートします。 -* **Page Size** — カタログクエリのページサイズ(1\-500、デフォルト 250)。 -* **TLS Verification** — Backstage が DefectDojo で検証できない証明書(内部 CA)を提供している場合にのみ `false` に設定してください。推奨されません。 -* **Uncategorized Product Type** — System を持たない Component に使用される製品タイプ(デフォルト `Backstage / Uncategorized`)。 -* **Owner Group Role** — マッピングされた製品に対して所有チームに付与されるロール(デフォルト `Maintainer`)。 -* **Annotation Mappings** — annotation キーをレコード属性名にマッピングする JSON オブジェクト、または annotation を製品タグとしてインポートするための `"tag"`。例: `{"github.com/project-slug": "GITHUB_PROJECT", "example.com/tier": "tag"}`。 - -**Auto\-Map** を有効にすると、1 回の Discover \+ Sync で製品タイプ / 製品 / 所有関係の構造全体が手作業なしで構築されます。Auto-Map を無効にした場合、検出された Component はマッピング判断待ちのレコードとして表示されます。 - -#### Limitations (v1) - -* Backstage の**グループメンバーシップは同期されません**。コネクタは所有チームを DefectDojo のグループとして作成・リンクしますが、そのグループへのユーザーの登録は ID プロバイダや管理者に委ねられます。 -* Component のみが製品になります。API、Resource、Domain はアセットとしてインポートされません(Domain はタグとして反映されます)。 -* タグと annotation は DefectDojo のフィールド上限に収まるよう正規化・制限されます(過大な値は切り詰められます)。 - -**逆方向についての補足:** Backstage の内部(エンティティページ上)で DefectDojo の検出事項やグレードを表示することは、DefectDojo REST API を利用する Backstage フロントエンドプラグインとして構築するのが自然な発展形ですが、これはこのコネクタの意図的なスコープ外です。このコネクタはあくまでカタログデータを DefectDojo に取り込むだけです。 - -## **Black Duck** - -Black Duck コネクタは、Black Duck(Synopsys / Black Duck)Hub インスタンスから**ソフトウェア構成分析(SCA)**の検出事項をインポートします。DefectDojo はインスタンス内のすべてのプロジェクトを検出し、**プロジェクト**ごとにレコードを作成します。プロジェクトの検出事項は、選択されたバージョンの脆弱な BOM コンポーネントから取得されます。 - -#### Prerequisites - -インポートしたいプロジェクトを閲覧できるユーザーの Black Duck **API トークン**が必要です。Black Duck でユーザーメニュー \> **My Access Tokens** \> **Create New Token** を開き、(少なくとも)読み取りアクセスを付与して、表示されたトークンをコピーしてください(表示されるのは一度きりです)。コネクタは各同期時にこのトークンを短命なベアラートークンと交換します。コネクタの secret フィールド以外に平文で保存されることはありません。 - -#### Connector Mappings - -1. **Location** フィールドに Black Duck の hub URL を入力します。例: `https://your-company.app.blackduck.com`。 -2. **Secret** フィールドに API トークンを入力します。 -3. 必要に応じて、インポートする検出事項を制限するために **Minimum Severity** を設定します。 - -各 Black Duck プロジェクトが 1 件のレコードになります。デフォルトでは、コネクタはプロジェクトの**リリース済み**バージョン(存在しない場合は最初のバージョンにフォールバック)をインポートします。そのバージョンの脆弱な BOM コンポーネントごとに、`{vulnerability} in {component}:{version}` というタイトルの検出事項が作成されます。 - -このコネクタは、ファイルベースの Black Duck パーサーとは別物です。このコネクタの検出事項は専用の **Black Duck - Connectors Import** スキャンタイプを使用します。 - -## **Bitbucket** - -Bitbucket コネクタは**Asset Connector**です。指定した Bitbucket Cloud ワークスペース内のリポジトリを列挙し、リポジトリごとに DefectDojo のアセットを作成し、Bitbucket のプロジェクト単位で組織にグループ化します。検出事項はインポートされません。 - -#### Prerequisites - -Bitbucket Cloud では**スコープ付き**の Atlassian API トークンが必要です。従来の(スコープなしの)Atlassian API トークンは、Bitbucket 側で「API Token provided has no Bitbucket scopes」エラーとして拒否されます。 - -1. [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens) にアクセスし、**Create API token with scopes** を選択します。 -2. **Bitbucket** アプリを選択し、読み取りスコープ `read:account:bitbucket`、`read:workspace:bitbucket`、`read:repository:bitbucket`、`read:project:bitbucket` を付与します。 - -対応しているのは Bitbucket Cloud(bitbucket.org)のみです。Bitbucket Server は 2024 年にサポートが終了しており、Bitbucket Data Center にも対応していません。 - -#### Connector Mappings - -1. **Location** フィールドに `https://bitbucket.org` を入力します。 -2. **Email** フィールドにトークンが紐づく Atlassian アカウントの email を入力します。 -3. **Secret** フィールドにスコープ付き API トークンを入力します。 -4. **Workspace Slugs** フィールドに、1 つ以上のワークスペース slug をカンマ区切りで入力します。このフィールドは必須です。Bitbucket のスコープ付き API トークンはワークスペースを自動的に一覧取得できないため、読み取り対象のワークスペースを DefectDojo に明示的に伝える必要があります。 - -各リポジトリは、そのリポジトリ名を冠したレコードとなり、Bitbucket の**プロジェクト**単位でグループ化されます。 - -## **Bugcrowd** - -Bugcrowd コネクタは、Bugcrowd REST API を使用してバグバウンティおよび脆弱性開示プログラムからの提出をインポートします。DefectDojo は API トークンがアクセスできるプログラムを検出し、プログラムごとにレコードを作成して、そのプログラムの提出内容を検出事項としてインポートします。 - -#### Prerequisites - -インポートしたいプログラムへのアクセス権を持つ Bugcrowd の **API トークン**が必要です。自動操作をチームによる手動操作と区別しやすくするため、DefectDojo 専用のサービスアカウントを作成することをお勧めします。トークンは Bugcrowd の **Organization settings \> API credentials** で生成します。提出、プログラム、ターゲットへの読み取りアクセスがあれば十分です。 - -#### Connector Mappings - -1. **Location** フィールドに `https://api.bugcrowd.com` を入力します。 -2. **Secret** フィールドに Bugcrowd API トークンを入力します。これは `Authorization: Token` ヘッダーとして送信されます。 -3. 必要に応じて、インポートする検出事項を制限するために **Minimum Severity** を設定します。 - -各 Bugcrowd **プログラム**が 1 件のレコードになり、その提出内容は Bugcrowd の深刻度を維持したまま検出事項としてインポートされます。重複した提出は除外されるため、再インポートしても同じ問題に対して重複した検出事項が作成されることはありません。 - -## **Bright Security** - -Bright Security コネクタは [Bright](https://brightsec.com)(旧 NeuraLegion)の API を使用して**DAST の検出事項**をインポートします。DefectDojo はトークンがアクセスできるすべてのスキャンを検出し、完了済みスキャンごとにレコードを作成して、そのスキャンの issue を検出事項としてインポートします。 - -#### Prerequisites - -Bright アプリの **User settings → API keys** で作成した Bright の**API キー**(`Org` または個人キー)が必要です。このキーは `Authorization: Api-Key` ヘッダーで送信され、ログに記録されることはありません。 - -#### Connector Mappings - -1. **Location** フィールドを空欄のままにすると `https://app.brightsec.com` が使用されます。または Bright のホストを明示的に入力してください。 -2. **Secret** フィールドに Bright の API キーを入力します。 -3. 必要に応じて、インポートする検出事項を制限するために **Minimum Severity** を設定します。 - -DefectDojo は完了済みの各**スキャン**を 1 件のレコードにマッピングし、各**issue**を検出事項にマッピングします。深刻度は Bright 自身の評価(Critical/High/Medium/Low)から取得され、CVSS スコア、CWE、修復情報が引き継がれ、影響を受けるエントリーポイントがエンドポイントとなり、リクエスト/レスポンスの証跡が説明に含まれます。検出事項は動的な検出事項として記録され、Bright の issue id で重複排除されます。 - -詳細は [Bright API documentation](https://docs.brightsec.com/) を参照してください。 - -## **BurpSuite** - -DefectDojo の Burp コネクタは、データを取得するために Burp の GraphQL API を呼び出します。 - -#### Prerequisites - -このコネクタをセットアップする前に、Burp Service Account の API キーが必要です。Burp のユーザーアカウントにはデフォルトで API キーがないため、この目的のために新しいユーザーを作成する必要がある場合があります。 - -API キーを持つ Service Account ユーザーのセットアップ方法については、[Burp Documentation](https://portswigger.net/burp/documentation/enterprise/user-guide/api-documentation/create-api-user) を参照してください。 - -#### Connector Mappings - -1. **Location** フィールドに Burp のルート URL を入力します。これは Burp ツールにアクセスする際の URL です。 -2. Secret フィールドに有効な API Key を入力します。これは Burp Service アカウントに紐づく API キーです。 - -Burp API の詳細については、公式の [Burp documentation](https://portswigger.net/burp/extensibility/enterprise/graphql-api/index.html) を参照してください。 - -## **Censys** - -Censys コネクタは Censys Platform からホストアセットを読み取り、各ホストの公開サービスを検出事項としてインポートします。スコープ対象のホストを列挙するために Censys Platform のグローバル検索 API を使用します。 - -#### Prerequisites - -API アクセスを備えた Censys **Platform** アカウントが必要です。 - -* Censys Platform Console の Personal Access Tokens で作成した**Personal Access Token**。 -* 同じ設定ページの「Current Organization」に表示される**Organization ID**。search エンドポイントへの API アクセスには組織が必要なため、Starter 以上のティアが必要です。無料ティアのトークンには organization ID がなく、search API を利用できません。 - -ホストごとの CVE およびリスクデータは Censys Core(エンタープライズ)ティアでのみ利用可能なため、それより下位のティアでは検出事項は脆弱性ではなく公開サービスを表します。 - -詳細は [Censys Platform API documentation](https://docs.censys.com/reference/get-started) を参照してください。 - -#### Connector Mappings - -1. **Location** フィールドに `https://api.platform.censys.io` を入力します。 -2. **API Key** フィールドに Personal Access Token を入力します。 -3. **Organization ID** を入力します。 -4. インポート対象を自社のアセットに絞り込む**Search Query**を入力します。例: `host.autonomous_system.asn: ` や `host.ip: 203.0.113.0/24`。 -5. 必要に応じて、インポートする検出事項を制限するために **Minimum Severity** を設定します。 - -DefectDojo はホストごとにレコードを作成し、その公開サービスを検出事項としてインポートします。 - -## **Checkmarx ONE** - -DefectDojo の Checkmarx ONE コネクタは、データを取得するために Checkmarx の API を呼び出します。 - -#### **Connector Mappings** - -1. **Checkmarx Tenant** フィールドに**Tenant Name** を入力します。この名前は Checkmarx ONE のログインページの右上に表示されているはずです。 -" Tenant: \<**your tenant name**\> " -​ -![image](images/connectors_tool_reference_2.png) - -2. 有効な API キーを入力します。新しく生成する必要がある場合があります。詳細は [Checkmarx API Documentation](https://docs.checkmarx.com/en/34965-68618-generating-an-api-key.html#UUID-f3b6481c-47f4-6cd8-9f0d-990896e36cd6_UUID-39ccc262-c7cb-5884-52ed-e1692a635e08) を参照してください。 -3. **Location** フィールドにテナントの場所を入力します。この URL は次の形式です。 -​`https://.ast.checkmarx.net/`。リージョンは、Checkmarx アプリ利用時の Checkmarx URL の先頭に表示されます。**** は主要な US サーバーです(リージョンプレフィックスはありません)。 - -#### **Branch handling** - -デフォルトでは、各同期はブランチに関わらず、プロジェクトの**直近の完了済みスキャン 1 件のみ**の検出事項をインポートします。CI で多数のブランチをスキャンしている場合、たまたま最後にスキャンされたブランチがその同期で「勝ち」となります。他のブランチにのみ存在する検出事項はインポートされず、同期のクローズ処理(close-old reconciliation)によって、異なるブランチが交互に最新スキャンになるたびに検出事項が開いたり閉じたりを繰り返すことがあります。 - -この動作を制御する 2 つのオプションフィールドがあります。 - -- **Branch**: すべてのプロジェクトを 1 つのブランチ名に固定します。そのブランチのスキャンのみがインポートされます。これはコネクタ全体に対する単一のグローバル値であるため、すべてのプロジェクトが同じ長期運用ブランチ(例えば `main`)を使用しているフリート向けです。 - - **`*` ワイルドカード**に対応しています。`*` を含む Branch 値は、単一のブランチではなく*一致するすべてのブランチ*を対象とします。例えば `release/*` は各リリースブランチをインポートし、`*` はすべてのブランチにマッチします。**Track Scanned Branches** と組み合わせることで、すべてを個別に追跡することなく、一群のブランチを追跡する方法になります。 - - ワイルドカードがスキャンウィンドウ内で**どのブランチにもマッチしない**場合、その同期は「ブランチに検出事項がない」として扱われるのではなく**スキップ**されます。これにより、一時的に何にもマッチしないパターンが、アセット上のすべての検出事項をクローズしてしまうことを防ぎます。 -- **Track Scanned Branches**: 有効にすると、各同期はプロジェクトの直近のスキャン履歴の中から完了済みスキャンを持つすべてのブランチを検出し、**各ブランチの最新の完了済みスキャン**をインポートします(ブランチごとに 1 回の再インポート)。各ブランチの検出事項は、マッピングされたアセット上の「\ \- \」という名前の独自のエンゲージメントに格納されるため、古い検出事項のクローズ処理はブランチ単位でスコープされます。あるブランチにマージされた修正が、別のブランチの検出事項をクローズすることはありません。プロジェクトの主要ブランチ(Checkmarx が報告するもの)が最初にインポートされるため、他のブランチで同じ検出事項が再発した場合、主要ブランチのオリジナルと重複排除されます。 - -**Track Scanned Branches** に関する注意点: - -- **自分にどのデフォルトが適用されるか確認してください。** ブランチ追跡は**新規インストールではデフォルトで有効**です。この変更より前から存在するインストールは従来の動作を維持するため、誰かがトグルを有効にするまでオフのままです。 -- 両方のフィールドが設定されている場合、追跡されるのは固定された **Branch** のみです。その Branch 値がワイルドカードパターンである場合も同様で、その場合はパターンに一致するすべてのブランチが追跡されます。 -- スキャンされなくなった(マージまたは削除された)ブランチは更新を受け取らなくなります。そのエンゲージメントは最後に判明している検出事項とともに表示され続けるため、レビューして一括でクローズできます。 -- 後でトグルをオフにしても安全です。ブランチごとのエンゲージメントはインポートを受け取らなくなり、次の同期からデフォルトのエンゲージメントが再開されます。 -- Connector は同期スケジュールに沿って状態を突き合わせます。ブランチ追跡は各同期をブランチ横断で完結させるものであり、同期と同期の間のデータをリアルタイム化するものではありません。 - -## **Cloudflare** - -Cloudflare コネクタは**Security Center insights** をインポートします。これは、DMARC レコードの欠落、DNSSEC が有効化されていない、証明書の問題など、Cloudflare がアカウントとゾーンについて表示するセキュリティ体制上の問題です。DefectDojo は、未解決の insight を持つゾーン(ドメイン)ごとにレコードを作成し、特定のゾーンに紐づかない insight についてはアカウントレベルのレコードを作成します。 - -#### Prerequisites - -Cloudflare の**API トークン**(従来の Global API Key ではない)が必要です。Cloudflare ダッシュボードの **My Profile > API Tokens > Create Token** で作成してください。最も手軽な方法は**「Read all resources」**テンプレートです。最小権限のトークンにする場合は、**Zone > Zone > Read**(すべてのゾーン)に加えて、Security Center 用のアカウントレベルの読み取りアクセスを付与してください。 - -#### Connector Mappings - -1. **Location** フィールドに `https://api.cloudflare.com/client/v4` を入力します。 -2. **Secret** フィールドに API トークンを入力します。 -3. 必要に応じて、インポートする検出事項を制限するために **Minimum Severity** を設定します。 - -DefectDojo は、トークンがアクセスできるアカウントとゾーンを自動検出します。アカウント ID は不要です。未解決(アクティブで、却下されていない)の insight のみがインポートされるため、Cloudflare 上で解決または却下した insight は、次の同期で DefectDojo 上でも自動的に緩和済みになります。 - -## **Cobalt.io** - -Cobalt.ioコネクタは、Cobalt.io API（v2）を使用して、Cobalt.io組織からペネトレーションテストの検出事項を取得します。DefectDojoは、APIトークンでアクセスできるすべての組織を検出し、Cobaltがペネトレーションテストを行う単位である**アセット**ごとに個別のレコードを作成します。 - -#### Prerequisites - -Cobalt.ioの**個人用APIトークン**が必要です。自動化された操作とチームによる手動操作を明確に区別できるよう、DefectDojo専用のサービスアカウントを作成することをお勧めします。Cobalt.io UIの**Settings > API Tokens**からトークンを生成してください。組織トークンは自動的に検出されるため、指定する必要はありません。 - -#### Connector Mappings - -1. **Location**フィールドにCobalt.io APIのベースURLを入力します: `https://api.cobalt.io`（またはリージョンごとのホスト、例: `https://api.us.cobalt.io`）。 -2. **Secret**フィールドに**個人用APIトークン**を入力します。 -3. 必要に応じて、同期を単一の組織に固定するために**Organization Token**を入力します。空欄のままにした場合、DefectDojoは個人用APIトークンがアクセスできるすべての組織を同期します。 - -DefectDojoは、Cobalt.ioの各**アセット**を個別のレコードとしてマッピングします。マッピングされた各アセットについて検出事項がインポートされ、Cobalt.io側のステータス（例: `valid_fix`、`wont_fix`、`invalid`）によってDefectDojo内の検出事項のステータスが決まります。 - -## **Contrast** - -Contrastコネクタは、Contrast Assess REST APIを使用してアプリケーションの脆弱性をインポートします。DefectDojoはContrast組織内のアプリケーションを検出し、それぞれについてレコードを作成します。 - -#### Prerequisites - -Contrastから4つの値が必要です。自動化された操作をチームの手動操作と区別しやすくするため、専用のサービスアカウントを作成することをお勧めします。Contrast UIの**User Settings > Profile > Your Keys**で以下を確認できます。 - -* 組織の**API Key**。 -* 個人の**Service Key**。 -* 認証情報の所有者である**username**（アカウントのログイン用メールアドレス）。 -* インポート元の組織のUUIDである**Organization ID**（**Organization Settings**にも表示されます）。 - -#### Connector Mappings - -1. **Location**フィールドに、Contrastへのアクセスに使用するベースURLを入力します。ホスト版の場合、通常は`https://app.contrastsecurity.com`です（またはリージョンごと・自己ホスト型のTeam ServerのURL）。 -2. **Username**フィールドにアカウントのログイン用メールアドレスを入力します。 -3. **API Key**フィールドに組織の**API Key**を入力します。 -4. **Service Key**フィールドに個人の**Service Key**を入力します。 -5. **Organization ID**フィールドに**Organization ID**（UUID）を入力します。 -6. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 - -各Contrastアプリケーションはレコードになり、その脆弱性は検出事項としてインポートされます。 - -## **Coverity** - -Coverityコネクタは、**Coverity Connect**サーバーから検出事項をインポートします。DefectDojoは、Coverityの**プロジェクト**ごとにレコードを作成します。 - -#### Connector Mappings - -1. **Location**フィールドにCoverity ConnectサーバーのURLを入力します。 -2. **Username**フィールドにCoverity Connectの**username**を入力します。 -3. **Secret**フィールドにユーザーのパスワードまたは認証キーを入力します。 -4. 必要に応じて、コネクタが読み取る保存済みissueビューを選択するために**View Name**を設定します。空欄のままにすると、デフォルトの**Outstanding Issues**が使用されます。 -5. 必要に応じて、デフォルトのSecurityおよびQuality（`RESOURCE_LEAK`）のissueフィルタより広くインポートするために、**Import All Issue Kinds**を`true`に設定します。 - -## **CrowdStrike Falcon** - -CrowdStrike Falconコネクタは、Falconプラットフォームから**Spotlightの脆弱性**と**EDR検知**を、2つの独立した検出事項タイプ（`CrowdStrike:Spotlight`と`CrowdStrike:Detections`）としてインポートします。DefectDojoは、Falconの**ホスト**ごとにレコードを作成します。 - -#### Prerequisites - -Falconコンソールの**Support > API Clients and Keys**で作成する、Falconの**APIクライアント**（Client IDとsecret）が必要です。インポートしたいデータに応じたスコープを付与してください: **Hosts: Read**（ホスト検出に必須）、**Vulnerabilities (Spotlight): Read**（Spotlightの検出事項用）、**Alerts: Read**（EDR検知用）。この2つの検出事項タイプは独立しており、クライアントに該当スコープがない場合、同期全体が失敗するのではなく、そのタイプの検出事項がスキップされます。そのため、**Alerts: Read**を持たないクライアントでも、Spotlightの脆弱性は問題なくインポートされます。 - -#### Connector Mappings - -1. **Location**フィールドに、コンソールのリージョンに対応するFalconクラウドのAPIベースURLを入力します。例: `https://api.crowdstrike.com`（US-1）、`https://api.us-2.crowdstrike.com`（US-2）、`https://api.eu-1.crowdstrike.com`（EU-1）、`https://api.laggar.gcw.crowdstrike.com`（US-GOV-1）。 -2. **Client ID**フィールドにAPIクライアントのClient IDを入力します。 -3. **Client Secret**フィールドにAPIクライアントのsecretを入力します。 -4. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 - -各Falconホストはレコードとなり、そのホスト名・OS・タイプにちなんで命名されます。Spotlightの脆弱性は**open**および**reopened**のものだけがインポートされるため、再インポートを行うと修復済みの検出事項はクローズされます。 - -## **Deepfence ThreatMapper** - -Deepfence ThreatMapperコネクタは、[ThreatMapper](https://github.com/deepfence/ThreatMapper)の管理コンソールREST APIを使用して**脆弱性スキャン**の結果をインポートします。DefectDojoは、ThreatMapperがスキャンしたすべてのノード（コンテナイメージ、ホスト、またはコンテナ）を検出し、それぞれについてレコードを作成したうえで、そのノードの直近に完了したスキャンを検出事項としてインポートします。 - -#### Prerequisites - -ThreatMapperの**APIトークン**が必要です。これはコンソールの**Settings → User Management**（ユーザーのAPIキー）にあります。コネクタは同期のたびにこのトークンを短命のアクセストークンと交換します。APIトークン自体がログに記録されることはありません。 - -#### Connector Mappings - -1. **Location**フィールドにThreatMapperコンソールのURLを入力します（例: `https://threatmapper.example.com`）。 -2. **Secret**フィールドにThreatMapperのAPIトークンを入力します。 -3. コンソールが自己署名証明書を使用している場合は、**Skip TLS Verification**を`true`に設定します。 -4. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 - -DefectDojoは、スキャン済みの各**ノード**をレコードにマッピングし、直近に完了した脆弱性スキャンに含まれる各**CVE**を検出事項にマッピングします。深刻度はThreatMapper自体の評価に基づき、影響を受けるパッケージ、CVSSスコア、修正バージョン（緩和策として）、参照リンク、詳細情報のブロックが引き継がれます。検出事項は動的検出事項として記録され、ノード・CVE・パッケージ・パッケージパスの組み合わせで重複排除されます。 - -詳細については、[ThreatMapperのドキュメント](https://community.deepfence.io/threatmapper/docs/v2.5/)を参照してください。 - -## Dependency-Track - -このコネクタは、REST API経由でオンプレミスのDependency-Trackインスタンスからデータを取得します。 - -​**Connector Mappings** - -1. **Location**フィールドにローカルのDependency-TrackサーバーのURLを入力します。 -2. **Secret**フィールドに有効なAPIキーを入力します。 - -Dependency-TrackのAPIキーを生成するには: - -1. **Access Management**: Dependency-Trackインターフェースで、Administration > Access Management > Teams に移動します。 -2. **Teams Setup**: 新しいチームを作成することも、既存のチームを選択することもできます。チームを使うことで、グループメンバーシップに基づいてAPIアクセスを管理できます。 -3. **Generate API Key**: 選択したチームの詳細ページで「API Keys」セクションを見つけます。+ボタンをクリックして新しいAPIキーを生成します。 -4. **Assign Permissions**: チームページの「Permissions」セクションで+ボタンをクリックし、権限セレクターを開きます。プロジェクトポートフォリオと脆弱性の詳細へのAPIアクセスを有効にするため、**VIEW_PORTFOLIO**と**VIEW_VULNERABILITY**の権限を選択します。 -5. 「**Select**」をクリックして、これらの権限を確認し保存します。 - -詳細については、**[Dependency-Track Documentation](https://docs.dependencytrack.org/integrations/rest-api/)**を参照してください。 - -## **Docker Scout** - -Docker Scoutコネクタは、Docker Scoutのmetrics exporter APIを使用して、組織のイメージの脆弱性状況を報告します。DefectDojoは、Docker Scoutの各stream（実行環境）を検出し、それぞれについて脆弱性とポリシー準拠状況のサマリーをインポートします。 - -#### Prerequisites - -**Docker Scoutに登録済み**のDocker組織の**owner**が作成した、Dockerのpersonal access tokenが必要です。metrics exporterは組織レベルの機能であるため、個人アカウントや、Docker Scoutに登録されていない組織では、データが返されません。 - -トークンは、Dockerアカウント設定の**Personal access tokens**から作成します。また、Dockerの**organization namespace**も必要になるため控えておいてください。 - -#### Connector Mappings - -1. **Location**フィールドに`https://api.scout.docker.com`を入力します。 -2. **Secret**フィールドにDockerのpersonal access tokenを入力します。 -3. Dockerの**Organization**namespaceを入力します。 -4. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。選択した深刻度未満の検出事項はインポートされません。 - -DefectDojoは、Docker Scoutのstreamごとに個別のレコードを作成し、そのstream内でDocker Scoutが集計した脆弱性について深刻度ごとに1件の検出事項をインポートするほか、Docker Scoutのポリシーに違反する各イメージについても検出事項をインポートします。Docker ScoutのmetricsAPIは個別のCVEではなく集計件数を報告するため、これらの検出事項はstreamの状況をまとめたものになります。イメージ単位・CVE単位の詳細については、Docker Scout上でそのstreamを開いて確認してください。 - -詳細については、[Docker Scoutのドキュメント](https://docs.docker.com/scout/)を参照してください。 - -## **Endor Labs** - -Endor Labsコネクタは、Endor Labs REST APIを使用してEndor Labsの**ネームスペース**全体を同期します。DefectDojoは、Endorの各**プロジェクト**をレコードとして検出し、そのプロジェクトの検出事項をインポートします。その際、Endorの**到達可能性（reachability）**判定も引き継がれるため、実際に到達可能なコードに影響する脆弱性を優先的に対応できます。 - -#### Prerequisites - -Endor Labsの**APIキー**（キー識別子とそのsecretの組み合わせ）と、同期したい**ネームスペース**が必要です。キーはEndor Labsプラットフォームの**Settings > Access > API Keys**で作成します。このキーには、対象ネームスペース内のプロジェクトと検出事項への読み取りアクセス権が必要です。 - -コネクタは、APIキーとsecretを短命のベアラートークンと交換することで認証を行います。secretはこの交換にのみ使用され、平文で保存されることはありません。 - -#### Connector Mappings - -1. **Location**フィールドに`https://api.endorlabs.com`を入力します。テナントが別のリージョンでホストされている場合は、そのリージョンのAPIベースURLを使用してください。 -2. 同期したいEndor Labsの**Namespace**を入力します（例: `your-org`や`your-org.team`）。 -3. **API Key**識別子を入力します。 -4. キーに対応する**API Secret**を入力します。 -5. 必要に応じて、設定したネームスペースの子ネームスペースからも検出事項をインポートするために、**Traverse Child Namespaces**を`true`に設定します。 -6. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。選択した深刻度未満の検出事項はインポートされません。 - -DefectDojoは、ネームスペース内のEndor Labsプロジェクトごとにレコードを作成し、その検出事項をインポートします。その際、Endorの深刻度レベルはDefectDojoの深刻度にマッピングされ、各脆弱性のCVE/GHSA識別子とCVSSスコア、およびEndorの到達可能性タグも引き継がれます。到達可能性の判定（例: *Reachable — vulnerable function is called*や*Unreachable*）は、検出事項のImpactおよびタグとして表示されます。 - -詳細については、**[Endor Labs REST APIのドキュメント](https://docs.endorlabs.com/rest-api/)**を参照してください。 - -## **Edgescan** - -Edgescanコネクタは、Edgescan REST APIを使用して、Edgescanアカウント全体のオープンな脆弱性をインポートします。DefectDojoは、すべてのEdgescanの**アセット**を列挙してそれぞれについてレコードを作成し、そのアセットのオープンな脆弱性を検出事項としてインポートします。アセットごとの個別設定はありません。 - -#### Prerequisites - -EdgescanのAPIトークンが必要です。Edgescanアカウントの**Account settings > API tokens**からラベルを入力し、**Create**をクリックして、生成されたトークンをコピーします（トークンは一度しか表示されません）。自動化された操作を区別しやすくするため、コネクタ専用のアカウントを使用することをお勧めします。 - -#### Connector Mappings - -1. **Location**フィールドにEdgescanのURLを入力します。標準的なホスト版プラットフォームの場合は`https://live.edgescan.com`、異なる場合はテナントのホストを入力してください。 -2. **Secret**フィールドにEdgescanのAPIトークンを入力します。これは`X-API-TOKEN`ヘッダーとして送信されます。 -3. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 - -各Edgescanアセットはレコードとなり、そのアセット上のオープンな脆弱性はそれぞれ検出事項としてインポートされます。深刻度は、Edgescanの数値スケール（1〜5）からDefectDojoの情報〜重大にマッピングされます。また、Edgescanが提供している場合は、CVE参照、CWE、CVSS v3ベクトルも含まれます。 - -## **Escape** - -Escapeコネクタは、[Escape](https://escape.tech) APIを使用して**APIセキュリティ（DAST）の検出事項**をインポートします。DefectDojoは、トークンがアクセスできるすべての組織と、それぞれの組織内のすべてのアプリケーションを列挙し、スキャンがあるアプリケーションごとにレコードを作成して、そのアプリケーションの最新スキャンのissueを検出事項としてインポートします。アプリケーションごとの個別設定はありません。 - -#### Prerequisites - -Escapeの**APIキー**が必要です。これはEscapeアプリの**Settings → API keys**で作成します。このキーは`Authorization: Key`ヘッダーで送信され、ログに記録されることはありません。 - -#### Connector Mappings - -1. **Location**フィールドを空欄のままにすると`https://public.escape.tech/v2`が使用されます。あるいは、EscapeのAPIホストを明示的に入力することもできます。 -2. **Secret**フィールドにEscapeのAPIキーを入力します。 -3. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 - -DefectDojoは、各**アプリケーション**をレコードにマッピングし、スキャンの各**issue**を検出事項にマッピングします。深刻度はEscapeの評価（重大/高/中/低）に基づき、CWEが引き継がれ、OWASPカテゴリとHTTPメソッドがタグになり、影響を受けるURLがエンドポイントになり、修復ガイダンスも含まれます。検出事項は動的検出事項として記録され、Escapeのissue IDで重複排除されます。 - -詳細については、[Escape APIのドキュメント](https://docs.escape.tech/)を参照してください。 - -## **Fairwinds Insights** - -Fairwinds Insightsコネクタは、[Fairwinds Insights](https://insights.fairwinds.com) REST APIを使用して、組織全体の**Kubernetesセキュリティの検出事項**をインポートします。DefectDojoは、アクティブな**クラスタ**をすべて列挙してそれぞれについてレコードを作成し、そのクラスタのSecurity **アクションアイテム**（Polaris、Trivy、Kube-bench、OPA、その他のInsightsレポートに由来）を検出事項としてインポートします。クラスタごとの個別設定はありません。 - -#### Prerequisites - -Fairwinds Insightsの**organization**名と**APIトークン**が必要です。トークンはInsightsアプリの**Organization Settings > Tokens**で作成します。`read_only`トークンで十分です。このトークンは組織単位のスコープを持ち、ベアラートークンとして送信されます。ログに記録されることはありません。 - -#### Connector Mappings - -1. **Location**フィールドを空欄のままにすると`https://insights.fairwinds.com`が使用されます。あるいは、Insightsのホストを明示的に入力することもできます。 -2. Insightsの**Organization**名（ダッシュボードのURLに表示されるスラッグ）を入力します。 -3. **Secret**フィールドにInsightsのAPIトークンを入力します。 -4. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 - -DefectDojoは、アクティブな各**クラスタ**をレコードにマッピングし、Securityの各**アクションアイテム**を検出事項にマッピングします。深刻度はFairwindsの数値スコア（DefectDojoの情報〜重大にマッピング）に基づき、そのアイテムを生成したFairwindsのレポート（`polaris`、`trivy`、`kube-bench`など）がツールタグになり、影響を受けるKubernetesリソースとコンテナイメージが含まれ、CVE識別子があれば抽出されます。検出事項は静的検出事項として記録され、Fairwindsのアクションアイテムのidで重複排除されます。 - -詳細については、[Fairwinds Insights APIのドキュメント](https://insights.docs.fairwinds.com/technical-details/api/)を参照してください。 - -## **Fortify** - -Fortifyコネクタは、Fortify（OpenText/Micro Focus）からSAST/DASTの結果をインポートします。同じプラットフォームを共有する2つのエディション、**SSC**（Software Security Center、自己ホスト型）と**Fortify on Demand（FoD）**（SaaS）の両方に対応しています。アカウント全体を同期し、DefectDojoはすべてのアプリケーション（SSCのproject version / FoDのrelease）を検出してそれぞれについてレコードを作成し、そのアプリケーションのissueを検出事項としてインポートします。 - -#### Prerequisites - -- **SSC**: **FortifyToken**が必要です。これはSSC UIの**Administration → Token Management**で作成します（CIToken/UnifiedLoginToken）。 -- **FoD**: **OAuth2 APIキー**が必要です。これは**Settings → API**から取得するClient IDとClient Secretです（`api-tenant`スコープを付与）。 - -トークンとOAuthのsecretがログに記録されることはありません。 - -#### Connector Mappings - -1. **Location**フィールドにFortifyのベースURLを入力します。SSCの場合はサーバーのホスト（コネクタが`/ssc/api/v1`を追加します）、FoDの場合はリージョンに応じたAPIホスト（例: `https://api.ams.fortify.com`）を入力します。 -2. **Edition**を`SSC`または`FoD`に設定します。 -3. **FoD**の場合は、OAuthの**Client ID**を入力します。SSCの場合は空欄のままにします。 -4. **Token / Client Secret**には、SSCのFortifyTokenまたはFoDのOAuthクライアントシークレットを入力します。 -5. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 - -DefectDojoは、Fortifyの各**アプリケーション**をレコードにマッピングし、各**issue**を検出事項にマッピングします。深刻度はFortify独自の**friority**評価（重大/高/中/低）に基づき、タイトルはissueのカテゴリとファイル・行番号を組み合わせたものになります。また、ファイルパス、行番号、kingdom、analyzer、engine typeが引き継がれます。静的解析エンジン（SCA）のissueは静的検出事項として、WebInspect（DAST）のissueは動的検出事項として記録されます。抑制済み・削除済み・非表示のissueはスキップされ、「Not an Issue」と判定されたissueは誤検知としてマークされ、「Exploitable」/レビュー済みのissueは検証済みとしてマークされます。 - -詳細については、[Fortify SSC](https://www.microfocus.com/documentation/fortify-software-security-center/)および[Fortify on Demand](https://api.ams.fortify.com/swagger/ui)のAPIドキュメントを参照してください。 - -## **GitGuardian** - -GitGuardianコネクタは、GitGuardian REST APIを使用して**secret incident**（GitGuardianが監視対象のソース全体で検出した、漏えいした認証情報）をインポートします。DefectDojoは、現在オープンなincidentを持つ監視対象ソース（リポジトリまたはperimeter）ごとにレコードを作成し、オープンな各incidentを検出事項としてインポートします。 - -セキュリティ上の理由から、コネクタがインポートするのはincidentの**メタデータ**（detector、深刻度、validity、status、GitGuardianへのリンク）のみです。漏えいしたsecretの値そのものがDefectDojoによって取得・保存されることはありません。影響を受けた箇所を確認するには、各検出事項に含まれるリンクからGitGuardianを参照してください。 - -#### Prerequisites - -GitGuardianのAPIキーが必要です。自動化された操作を区別しやすくするため、個人アクセストークンではなく**Service Accountトークン**を使用することをお勧めします。GitGuardianダッシュボードの**API**でトークンを作成し、以下の読み取りスコープを付与してください。 - -* `incidents:read` -* `sources:read` - -#### Connector Mappings - -1. **Location**フィールドにGitGuardianのAPI URLを入力します。SaaSプラットフォームの場合は`https://api.gitguardian.com`、自己ホスト型インスタンスの場合はそのAPI URLを入力します。 -2. **Secret**フィールドにAPIキーを入力します。 - -インポートされるのは**open**なincident（statusが`TRIGGERED`または`ASSIGNED`のもの）のみです。GitGuardian側でresolveまたはignoreにしたincidentは、次回の同期時にDefectDojo側でも自動的に緩和済みになります。有効性が確認済みのsecret（validityが*valid*）は、検証済みの検出事項としてインポートされます。 - -## **GitHub** - -GitHubコネクタは**アセットコネクタ**です。トークンがアクセスできるリポジトリを列挙し、それぞれについてDefectDojoのアセットを作成します。作成されたアセットは、GitHubのowner（組織またはユーザー）ごとにOrganizationsにグループ化されます。検出事項はインポートされません。 - -**Please note:** このコネクタがインポートするのはリポジトリの**インベントリ**のみです。GitHubのセキュリティアラート（code scanning、Dependabot、secret scanning）を検出事項としてインポートするには、以下の別途用意された**GitHub Advanced Security**コネクタを使用してください。この2つは互いに独立しており、併用することもできます。 - -#### Prerequisites - -コネクタはGitHubの**個人アクセストークン**で認証を行い、リポジトリの**メタデータ**（名前、説明、URL、owner）のみを読み取ります。コードやissue、セキュリティアラートにはアクセスしません。トークンのアカウントが所有・コラボレーション・組織メンバーとして参加しているすべてのリポジトリがインポートされるため、ミラーしたいリポジトリをそのアカウントが参照できることを確認してください。専用のサービスアカウントを使用することをお勧めします。 - -トークンに必要なのは、リポジトリメタデータへの読み取り専用アクセスのみです。 - -- *fine-grained*トークンの場合、インポート対象のリポジトリ（または組織全体）に対して**Repository permissions → Metadata: Read-only**の権限が必要です。 -- *classic*トークンの場合、プライベートリポジトリを含めるには**`repo`**スコープが必要です（パブリックリポジトリのみでよい場合は**`public_repo`**を使用してください）。加えて、組織所有のリポジトリを解決するために**`read:org`**も必要です。 - -サポートされるのはGitHub.com（GitHub Enterprise Cloudを含む）のみです。GitHub Enterprise **Server**は現時点でこのコネクタではサポートされていません。 - -#### Connector Mappings - -1. **Location**フィールドに`https://api.github.com`を入力します。 -2. **Secret**フィールドに個人アクセストークンを入力します。 - -組織やリポジトリのリストを入力する必要はありません。DefectDojoは、トークンが参照できるすべてのリポジトリをインポートします。各リポジトリはそのリポジトリ名にちなんだレコードとなり、GitHubの**owner**（組織またはユーザー）ごとにグループ化されます。リポジトリが後で削除されたり、トークンがそのアクセス権を失ったりした場合、対応するレコードは削除されるのではなく、次回の同期時に`MISSING`としてフラグが付けられます。DefectDojoが製品を黙って削除することはありません。 - -## **GitHub Advanced Security** - -GitHub Advanced Securityコネクタは、GitHubから**code scanning**、**Dependabot**、**secret scanning**のアラートを、3つの独立した検出事項タイプ（`GitHub:CodeScanning`、`GitHub:Dependabot`、`GitHub:SecretScanning`）としてインポートします。DefectDojoは、設定した組織内のアーカイブされていないすべてのリポジトリを検出し、それぞれについてレコードを作成します。 - -#### Prerequisites - -インポートしたいリポジトリでは、GitHub Advanced Security機能が有効になっている必要があります。コネクタはGitHubの**個人アクセストークン**で認証を行います。 - -1. GitHubで**Settings > Developer settings > Personal access tokens**を開き、対象の組織が所有する（またはアクセス権を持つ）トークンを作成します。 -2. セキュリティアラートへの読み取りアクセス権を付与します。*fine-grained*トークンの場合、組織のリポジトリに対して**Code scanning alerts**、**Dependabot alerts**、**Secret scanning alerts**への**Read-only**アクセスが必要です。*classic*トークンの場合は**`repo`**と**`security_events`**のスコープが必要です。 -3. トークンのownerがインポート対象のリポジトリを参照できることを確認してください。コネクタは、トークンがアクセスできるリポジトリしか参照できません。 - -#### Connector Mappings - -1. **Location**フィールドに`https://api.github.com`を入力します。GitHub Enterprise Serverの場合は`https:///api/v3`を使用してください。 -2. **Organization**フィールドに組織のログイン名を入力します。 -3. **Secret**フィールドに個人アクセストークンを入力します。 -4. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 - -アーカイブされていない各リポジトリはレコードとなり、3種類のアラートファミリーそれぞれについてオープンなアラートが照会されます。あるリポジトリで特定のアラートファミリーが有効になっていない場合、それはresolvedとして報告されるのではなくスキップされるため、無効化された機能によって誤ってクローズされることはありません。 - -## **GitLab** - -GitLabコネクタは**アセットコネクタ**です。トークンがアクセスできるすべてのproject（リポジトリ）を列挙し、それぞれについてDefectDojoのアセットを作成します。作成されたアセットは、GitLabのnamespace（グループまたはユーザー）ごとにOrganizationsにグループ化されます。検出事項はインポートされません。 - -#### Prerequisites - -**read_api**スコープを持つPersonal Access Tokenが必要です。専用のサービスアカウントからトークンを作成することをお勧めします。コネクタは、そのアカウントがメンバーになっているprojectを一覧表示します。 - -#### Connector Mappings - -1. **Location**フィールドにGitLabのURLを入力します: `https://gitlab.com`、または自己ホスト型インスタンスのベースURL。 -2. **Secret**フィールドにPersonal Access Tokenを入力します。 - -各projectはそのproject名にちなんだレコードとなり、**namespace**ごとにグループ化されます。GitLab上で削除待ち状態のproject（ユーザーによって削除されたが、GitLabのバックグラウンドジョブによってまだ完全に削除されていないもの）は自動的に除外されます。そのため、projectを削除すると、名前が変更された幽霊のようなアセットが残るのではなく、次回の同期時に対応するレコードが`MISSING`としてフラグ付けされます。 - -## **Google Cloud Security Command Center** - -Google Cloud SCCコネクタは、Security Command Center v2 REST APIを使用して、Google Cloudのorganization、folder、またはprojectからアクティブなセキュリティの検出事項をインポートします。DefectDojoは、オープンな検出事項を持つGoogle Cloudの**project**ごとにレコードを作成します。 - -#### Prerequisites - -組織でSecurity Command Centerが**有効化**されている必要があります（Standardティアは無料です）。次に、検出事項を一覧取得できるサービスアカウントと、そのJSONキーが必要です。 - -1. Google Cloudでサービスアカウントを作成します。DefectDojo専用のアカウントを作成することをお勧めします。 -2. インポートしたいスコープ（organization、folder、またはproject）に対して、**Security Center Findings Viewer**ロール（`roles/securitycenter.findingsViewer`）を付与します。 -3. そのサービスアカウントの**JSONキー**を作成してダウンロードします。 - -#### Connector Mappings - -1. 標準以外のエンドポイントを使用しない限り、**Location**フィールドはデフォルトの`https://securitycenter.googleapis.com`のままにします。 -2. **Parent Resource**フィールドに、インポート元のスコープを入力します: `organizations/{id}`、`folders/{id}`、または`projects/{id}`。 -3. サービスアカウントの**JSONキー**ファイルの内容全体を**Service Account Key**フィールドに貼り付けます。 -4. 必要に応じて、インポートする検出事項を制限するために**Minimum Severity**を設定します。 - -インポートされるのは`ACTIVE`かつミュートされていない検出事項のみです。そのため、SCCで非アクティブ化またはミュートした検出事項は、次回の同期時にDefectDojo側でも自動的に緩和済みになります。各検出事項が影響するGCPのprojectが、そのレコードになります。 - -## **Group-IB ASM** - -Group-IB ASM(Attack Surface Management)コネクタは、Group-IB ASM REST APIを使用して、外部の攻撃対象領域の**issue**(検出事項)をDefectDojoに取り込みます。DefectDojoは各Group-IBの**company/tenant**を個別のRecordとして検出し、そのcompanyのissueをスケジュールに基づいて増分的にインポートします。各issueが関連するアセット(ドメイン、IP、またはURL)は、生成された検出事項に**Endpoint**として付加されます。 - -#### Prerequisites - -Group-IB ASMのログイン情報とAPIキーが必要です。自動化された操作を手動のチーム操作と区別できるよう、DefectDojo専用のサービスアカウントを作成することをお勧めします。 - -APIキーを生成するには: - -1. Group-IB Attack Surface Managementを開き、左下の**Help**をクリックして**API**を選択します。 -2. (右上、ユーザー名の下にある)**Generate API Key**をクリックします。 -3. SSOパスワードを入力して**Next**をクリックし、次に**Copy token**をクリックします。 -4. キーをシークレットマネージャーに保管し、定期的なローテーションを計画してください。 - -#### Connector Mappings - -Group-IB ASMはHTTP Basic認証で認証を行います。ユーザー名はASMのログイン情報、パスワードはAPIキーです。**両方の値が必要です** — APIキーだけでは十分ではありません。 - -1. **Location**フィールドに`https://asm.group-ib.com`を入力します。これはすべてのGroup-IB ASMテナントで共通です。 -2. **Username**フィールドにASMのログイン情報(通常はメールアドレス)を入力します。 -3. **API Key**(Secret)フィールドにAPIキーを入力します。 -4. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。選択した深刻度を下回る検出事項はインポートされません。 - -DefectDojoは各Group-IBの**company**をcompany IDを識別子として個別のRecordにマッピングします。最初のSyncでは、DefectDojoは最近のissue履歴をバックフィルします。以降のSyncは増分的で、前回のSync以降に変更されたissueのみを(各issueの最新の`lastSeen`タイムスタンプで追跡して)取り込みます。 - -#### Scoping to a single company (optional) - -デフォルトでは、コネクタはお使いのAPI資格情報でアクセス可能なcompanyを(ASMの`clients`エンドポイント経由で)自動的に検出し、company一つにつき一つのRecordを作成します。これが推奨のセットアップであり、追加の設定は不要です。 - -`clients`エンドポイントがお使いのテナントで利用できない場合(たとえばパートナー/MSPアカウントに制限されている場合など)、コネクタの設定でツール固有フィールド`company_id`にそのcompanyの**company ID**を指定することで、単一のcompanyにスコープを限定できます。`company_id`が設定されている場合、DefectDojoはcompanyを列挙する代わりにそのcompanyを直接使用します。自動検出を使用するには未設定のままにしてください。 - -詳細については、Group-IB ASM REST APIマニュアル(製品内の**Help → API**から利用可能)を参照してください。 - -## **HackerOne** - -HackerOneコネクタは、HackerOne REST APIを使用して、バグバウンティまたは脆弱性開示プログラムからレポートをインポートします。DefectDojoはトークンがアクセスできる各プログラムのRecordを作成し、そのレポートを検出事項としてインポートします。 - -#### Prerequisites - -このコネクタはHackerOneの**customer** APIを使用しており、**organization APIトークン**が必要です。ユーザー設定の個人トークンはhacker APIに対してのみ有効で、ここでは認証できません。 - -1. HackerOneで**Organization Settings > API Tokens**に移動します。 -2. トークンを作成し、**identifier**と**token**の両方の値を控えておきます。プログラムへの読み取りアクセスがあれば十分です。 - -#### Connector Mappings - -1. **Location**フィールドに`https://api.hackerone.com`を入力します。 -2. **API Token Identifier**フィールドにトークンの**identifier**を入力します。 -3. **API Token**フィールドにトークンの値を入力します。 -4. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。 - -各プログラムがRecordとなり、そのレポートはHackerOneの深刻度評価を維持したまま検出事項としてインポートされます。 - -## **Harbor** - -Harborコネクタは、Harbor v2.0 REST APIを使用して、レジストリ全体のコンテナイメージの脆弱性をインポートします。DefectDojoはすべてのHarbor**project**を列挙し、それぞれにRecordを作成した上で、そのprojectのリポジトリとアーティファクトを走査し、**スキャン済み**の各アーティファクトから脆弱性をインポートします — その際、イメージ(リポジトリ+タグ/ダイジェスト)を検出事項のコンテキストとして保持します。イメージごとの個別設定はありません。 - -#### Prerequisites - -インポート対象のprojectへのpull/読み取りアクセス権を持つHarborアカウント(または**robotアカウント**)が必要です。専用のrobotアカウントの使用をお勧めします。Harborでprojectを開き(システムrobotの場合は**Administration > Robot Accounts**)、リポジトリとアーティファクトに対する**pull**権限を持つrobotを作成し、そのフルネームとシークレットをコピーします。robot名はデフォルトで`robot$`から始まりますが、このプレフィックスはHarborインスタンスごとに設定可能です(`robot_`を使用するものもあります) — Harborに表示されている名前をそのままコピーしてください。通常のユーザー名/パスワードも使用できます。 - -#### Connector Mappings - -1. **Location**フィールドにHarborのURLを入力します — 例: `https://harbor.example.com`。DefectDojoは`/api/v2.0`のAPIパスを自動的に付加します。 -2. **Username**フィールドにHarborのユーザー名、またはHarborに表示されているとおりのrobotアカウント名(デフォルトでは`robot$`)を入力します。 -3. **Secret**フィールドにパスワードまたはrobotアカウントのシークレットを入力します。これはHTTP Basic認証で送信されます。 -4. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。 - -各Harbor projectがRecordとなります。スキャンが完了しているアーティファクトごとに、その脆弱性が検出事項としてインポートされます。影響を受けるパッケージ/バージョン、CVSSに基づく深刻度、CVE、CWE、および修復方法(修正済みバージョン)は、Harborが提供している場合に含まれます。インポートされるのはスキャン済みのアーティファクトのみです — まだスキャンされていないイメージについては、Harbor側でスキャンを実行してください。 - -## **Have I Been Pwned** - -Have I Been Pwned(HIBP)コネクタは、HIBP REST APIを使用して、組織自身のドメイン上のどのアカウントが既知のデータ漏洩に含まれているかを報告します。DefectDojoはHIBPで検証済みの各ドメインを検出し、そのドメインに影響する漏洩ごとに1件の検出事項をインポートします。 - -#### Prerequisites - -ドメイン検索機能付きのHave I Been Pwned APIキーが必要です。これには**Core**サブスクリプション以上のプランが必要です。キーは[Have I Been Pwnedアカウント](https://haveibeenpwned.com/API/Key)から取得できます。 - -また、漏洩データを利用できるようにするには、HIBPアカウントで**少なくとも1つのドメインを検証**する必要があります。HIBPでは、アカウントの**Domain search**セクションから、DNS TXTレコード、metaタグ、ファイルアップロード、またはメールでドメインを検証できます。ドメインが検証されるまで、コネクタはドメインを検出せず、検出事項もインポートされません。 - -#### Connector Mappings - -1. **Location**フィールドに`https://haveibeenpwned.com`を入力します。 -2. **Secret**フィールドにAPIキーを入力します。 -3. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。選択した深刻度を下回る検出事項はインポートされません。 - -DefectDojoは、HIBPで検証済みの各ドメインごとに個別のRecordを作成し、そのドメイン上のアカウントに影響する漏洩ごとに1件の検出事項をインポートします。各検出事項の深刻度は漏洩で公開されたデータの種類を反映し、説明にはあなたのドメイン上で影響を受けたアカウントが記載されるため、チームが対応を取ることができます。 - -詳細については、[Have I Been Pwned APIドキュメント](https://haveibeenpwned.com/API/v3)を参照してください。 - -## **HCL AppScan** - -HCL AppScanコネクタは、AppScan v4 REST APIを使用して、**AppScan on Cloud(ASoC)**またはセルフホスト型の**AppScan 360°**(両者はAPIを共有しています)からissueをインポートします。アカウント全体を同期します。DefectDojoはすべてのアプリケーションを検出してそれぞれにRecordを作成し、そのアプリケーションのissue(DAST、SAST、IAST)を検出事項としてインポートします。 - -#### Prerequisites - -AppScanの**APIキー**が必要です — これはAppScanアカウント設定(API Key)で生成されるKey IDとKey Secretです。コネクタは実行ごとにこれらを短命のセッショントークンと交換します。Key ID、Key Secret、トークンはログに記録されません。 - -#### Connector Mappings - -1. **Location**フィールドにAppScanコンソールのURLを入力します。ASoCの場合は`https://cloud.appscan.com`(EUリージョンの場合は`https://eu.cloud.appscan.com`)、セルフホスト型のAppScan 360°の場合はインスタンスのホストを使用します。 -2. AppScan on Cloudの場合は**Provider**を`ASOC`に、セルフホスト型のAppScan 360°の場合は`A360`に設定します。 -3. **API Key ID**と**API Key Secret**を入力します。 -4. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。 - -DefectDojoは各AppScanの**application**をRecord(VEP)にマッピングし、各**issue**を検出事項にマッピングします。タイトルはissueの種類にドメイン/エンティティ/cause-id/URL/パスを付加したものになります。深刻度はInformational→情報にマッピングされます(Low/Medium/High/Criticalはそのまま渡されます)。CWE、ラベル付きの説明、修復方法とアドバイザリ、およびhost/portエンドポイントが引き継がれます。静的解析によるissueは静的検出事項として、動的/インタラクティブなissueは動的検出事項として記録され、openなissueはアクティブ、fixed/passedのissueは緩和済みになります。 - -詳細については、[AppScan REST APIドキュメント](https://help.hcl-software.com/appscan/ASoC/appseccloud_rest_apis.html)を参照してください。 - -## **Intigriti** - -Intigritiコネクタは、Intigritiの外部company APIを使用して、バグバウンティ/ペンテストの**submissions**をDefectDojoに取り込みます。companyアカウント全体を同期します。DefectDojoはトークンがアクセスできるすべてのプログラムを検出してそれぞれにRecordを作成し、そのプログラムのsubmissionを検出事項としてインポートします。 - -#### Prerequisites - -Intigritiの**company APIトークン**が必要です。Intigriti companyポータルの**Company Settings > API**(`company_external_api`スコープ)で、プログラムとsubmissionへの読み取りアクセス権を持つアクセストークンを生成します。DefectDojo専用のトークンを使用することをお勧めします。トークンはBearerトークンとして送信され、ログには記録されません。 - -#### Connector Mappings - -1. **Location**フィールドにIntigritiの外部company APIベースURLを入力します: `https://api.intigriti.com/external/company`。URLはHTTPSである必要があります。 -2. **Secret**フィールドにcompany APIトークンを入力します。 -3. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。 - -DefectDojoは各Intigritiの**program**をRecordに、各**submission**をsubmissionコードをキーとして検出事項にマッピングします。検出事項の深刻度はIntigritiの評価に従います(Exceptional/Critical→重大、続いてHigh/Medium/Low、それ以外はInformational)。submissionのライフサイクル状態は検出事項のステータスにマッピングされます — open/triageのsubmissionはアクティブ、acceptedのsubmissionは検証済み、closedのsubmissionはそのクローズ理由に応じて緩和済み、重複、対象外、誤検知、またはリスク受容済みになります。検出事項の説明には、レポートの脆弱性タイプ、影響を受けるアセット、証拠となるPoC(proof of concept)、および研究者の回答が記載されます。 - -詳細については、[Intigriti APIドキュメント](https://kb.intigriti.com/en/articles/6117846-intigriti-api)を参照してください。 - -## **Intruder** - -Intruderコネクタは、[Intruder REST API](https://developers.intruder.io/)を使用して、アカウント全体のセキュリティ状況をDefectDojoに取り込みます。各Intruderの**target**はRecord(Product)として検出され、target上のissueの各**occurrence**がFindingになります。 - -#### Connector Mappings - -1. **Location**フィールドは`https://api.intruder.io/`(デフォルトのIntruder APIサーバー)のままにしておきます。 -2. **Secret**フィールドにIntruderの**APIアクセストークン**を入力します。 - -Intruderの**My account > API Access Tokens**でアクセストークンを生成します(作成にはアカウントパスワードが必要で、トークンは一度しか表示されません)。詳細は[Intruder APIドキュメント](https://developers.intruder.io/docs/creating-an-access-token)を参照してください。 - -検出事項はoccurrenceごとに導出されます。深刻度はissueの深刻度から、CVEとCVSSはoccurrenceから、locationはtarget/portから取得され、snooze(一時停止)されたoccurrenceは非アクティブ(誤検知またはリスク受容済み)な検出事項としてインポートされます。 - -## **IriusRisk** - -IriusRiskコネクタは、APIトークンを使用して、お使いのIriusRiskインスタンスから脅威モデリングデータを取り込みます。 - -#### Prerequisites - -IriusRiskアカウントのAPIトークンが必要です。自動化された操作を手動のチーム操作と明確に区別できるよう、DefectDojo専用のサービスアカウントを作成することをお勧めします。 - -IriusRiskでAPIトークンを生成するには: - -1. IriusRiskインスタンスにログインします。 -2. 右上のメニューから**User Profile**に移動します。 -3. **API Token**を選択し、新しいトークンを生成します。 - -詳細については、[IriusRisk APIドキュメント](https://support.iriusrisk.com/hc/en-us/categories/360001148511)を参照してください。 - -#### Connector Mappings - -1. **Location URL**フィールドにIriusRiskインスタンスのURLを入力します。クラウドホスト型インスタンスの場合、通常は`https://{your-subdomain}.iriusrisk.com`です。オンプレミス環境の場合は、インスタンスのベースURLを使用してください。 -2. **Secret**フィールドに**API Token**を入力します。 -3. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。選択した深刻度を下回る検出事項はインポートされません。 - -## **JFrog Xray** - -JFrog Xrayコネクタは、JFrog Xray REST APIを使用して、Artifactoryリポジトリから脆弱性データを取得します。DefectDojoはJFrogインスタンス内のすべてのリポジトリを検出し、Xray経由で脆弱性レポートを生成して、スケジュールに基づいて検出事項をインポートします。 - -#### Prerequisites - -ArtifactoryとXrayの両方のAPIにアクセスできるAPIトークンが必要です。DefectDojo専用のサービスアカウントの作成をお勧めします。このアカウントには以下が必要です。 - -* Artifactoryリポジトリへの読み取りアクセス -* Xrayの脆弱性レポートを生成・閲覧する権限(Xrayの`Apply on Watches`権限、またはそれに相当するもの) - -#### Connector Mappings - -1. **Location**フィールドにJFrogインスタンスのベースURLを入力します。これはJFrogインスタンスのルートURLである必要があります。例: `https://your-instance.jfrog.io`。末尾にパスを含めないでください — DefectDojoが適切なAPIパスを自動的に構築します。 -2. **Secret**フィールドに有効な**Reference Token**を入力します。トークンはJFrog PlatformのUIの**User Management > Access Tokens**から生成できます。 -**Reference Token**を生成し、その値を使用する必要があります。 - -JFrog Xrayに必要なトークンスコープ: - -- **All Services** — DefectDojoはXRayとArtifactoryの両方のサービスへのアクセスが必要なため -- 最低限**Manage Reports + Manage Resources**が必要です。 - -デフォルトでは、DefectDojoは各Artifactory**リポジトリ**を個別のRecordとしてマッピングします。各Syncでリポジトリごとに完全な脆弱性レポートがXray経由で生成されるため、DefectDojo内の検出事項のステータスは常にリポジトリの現在の状態を反映します。 - -#### Repository Filter (optional) - -デフォルトでは、コネクタはJFrogインスタンス内の**すべて**のリポジトリを検出します。リポジトリ数が非常に多いインスタンス(その多くはセキュリティレビューに関係ない場合もあります)では、コネクタフォームの**Import Filters**の下にある任意項目の**Repository Filter**フィールドで検出範囲を絞り込むことができます。 - -このフィルタは検出時、つまり**リポジトリごとの処理が行われる前**に適用されます。フィルタ範囲外のリポジトリにはコストがかかりません — そのリポジトリのXrayレポートは生成されず、アーティファクトモードでは第1階層のアーティファクトも列挙されません。これにより、Syncにかかる時間とDefectDojoがJFrogインスタンスにかける負荷の両方を削減する、最も効果的な方法となります — これはSync後半に適用される他のどの設定よりも効果的です。特に大規模なインスタンスでは、**Artifact-Level Records**と併用することが推奨されます。 - -**構文:** リポジトリキーのカンマ区切りリストです。各項目には`*`ワイルドカードを使用できます。 - -* `*`を含む項目はパターンとして照合されます — `releases-*`は`releases-`で始まるすべてのリポジトリキーに一致し、`*docker-pr-local*`は`docker-pr-local`を含むすべてのキーに一致します。`*`は`/`を含む任意の文字列に一致します。 -* `*`を含まない項目は、リポジトリキーに**完全一致**する必要があります。 -* リストの**いずれかの**項目に一致すれば、そのリポジトリは検出されます。カンマの前後の空白は無視されます。 - -``` -releases-*, snapshots -``` - -上記の例では、`releases-`で始まるすべてのリポジトリキーに加えて、`snapshots`という名前に完全一致する単一のリポジトリを検出します。 - -補足: - -* このフィルタは**許可リスト(allow-list)**です — 一致するとそのリポジトリが選択されます。除外や否定の構文はないため、「Xを除くすべて」を直接表現することはできません。 -* 一致は完全一致・ワイルドカードともに**大文字小文字を区別します**。ワイルドカード文字は`*`のみで、`?`や文字範囲はサポートされていません。 -* **すべてのリポジトリを検出するには空欄のままにしてください。** 空白またはカンマのみの値は空欄として扱われます。 -* 何にも一致しないフィルタは単に何も検出しません — エラーにはなりません。Syncで予期せずリポジトリが見つからない場合は、コネクタログの`repository filter scoped discovery`のエントリを確認してください。これは全リポジトリ数のうち何件が一致したかを報告します。 -* このフィールドは接続作成後にも変更できます。 - -**後からフィルタを変更する場合:** 新たに絞り込まれたフィルタによって除外されたリポジトリは検出されなくなり、その既存のRecordはツールがそれ以上報告しなくなったproductに対する通常のライフサイクルに従います — **マッピング済み**のRecordは次のSyncで`MISSING`とフラグが立てられ、未マッピングの`NEW`のRecordは削除されます。すでにDefectDojoにインポートされた検出事項は削除されません。フィルタが管理するのは検出のみです。 - -#### Artifact-Level Records - -**Artifact-Level Records**のトグルをオンにすると、検出範囲がリポジトリの1階層下に変わります。リポジトリルート直下の第1階層の各エントリ(Dockerリポジトリの場合は各イメージ、汎用リポジトリの場合は各トップレベルのファイルまたはフォルダ)が、それぞれ独自のRecordになります。各Syncは引き続きリポジトリごとに1つのXrayレポートを生成しますが、DefectDojoは各脆弱性を影響を受けるアーティファクトに割り当てるため、JFrogインスタンスへの負荷は増加しません。 - -> **最初のSyncを行う前に、どちらのモードになっているか確認してください。** Artifact-Level Recordsは**新規インストールではデフォルトで有効**です。この機能より前から存在するインストールでは、既存のリポジトリレベルのレイアウトが維持されるため、誰かが有効化するまでトグルはオフのままです。どちらの場合も、トグルはいつでも変更できます。詳細は以下の*既存の接続の切り替え*を参照してください。 - -Artifact-Level Recordsを有効にすると: - -* リポジトリはRecordのままですが、**親アセット**になります。リポジトリ自体は検出事項を持ちませんが、Asset Hierarchy機能が有効な場合、DefectDojoは各アーティファクトアセットをそのリポジトリアセットに`parent`関係で自動的に関連付けます。これにより、アセットを親/子でフィルタリングでき、検出事項は階層をロールアップします。 -* 複数のアーティファクトに影響する脆弱性は、影響を受ける各アーティファクトのアセットにインポートされるため、すべてのアセットにそれぞれへ影響する検出事項の完全なセットが表示されます。 -* 検出事項は各アーティファクトの**最新ビルド**にスコープされるため、アーティファクトの検出事項は、Xrayがこれまでスキャンしたすべてのビルドの結果を蓄積するのではなく、現在のビルドを表します。 -* コネクタが作成した階層関係が、あなたが手動で作成した関係を上書きすることはありません。アセットにすでに割り当てた親がある場合、コネクタはそれに手を加えません。 -* トークンにはさらにArtifactory storage APIへの読み取りアクセスが必要です(上記のスコープに含まれています)。 - -**既存の接続をArtifact-Level Recordsに切り替える:** このトグルはいつでも変更できます。切り替え後の最初のSyncでは、マッピング対象として新しいアーティファクトRecordが表示されます — トグルを切り替える際は、検出事項が途切れなく移行するよう、接続で**Auto Map**を有効にしてください。リポジトリレベルのアセットは検出事項を受け取らなくなり、以前にインポートされた検出事項は次のSyncでクローズされます(同じ検出事項は新しいステータスで新しいアーティファクトアセットの下に再インポートされます)。古いリポジトリレベルの検出事項に付いていたメモと履歴は、リポジトリアセットに残ります。元に戻すとこの逆になります — リポジトリRecordが検出事項を持つ状態に戻り(以前にクローズされた検出事項は再一致して再オープンします)、アーティファクトRecordはMISSINGとしてマークされます。そのアセットと検出事項は保持されますが更新されなくなるため、任意のタイミングでアーカイブできます。 - -詳細については、[JFrog Xray REST APIドキュメント](https://jfrog.com/help/r/jfrog-rest-apis/xray-rest-apis)を参照してください。 - -## **Jira Service Management Assets** - -JSM Assetsコネクタは**Asset Connector**です。お使いのJira Service Management Assets(旧Insight)ワークスペース内のオブジェクトを列挙し、それぞれのオブジェクトに対してDefectDojoのAssetを作成します。オブジェクトスキーマごとにOrganizationsにグループ化されます。検出事項はインポートされません。 - -#### Prerequisites - -* AssetsはJira Service Managementの**PremiumまたはEnterprise**プランが必要です。FreeまたはStandardプランでは、サイトの他の部分は動作していても、Assets APIは`403 "Access to Assets API was denied"`を返します。 -* トークンに紐づくAtlassianアカウントは、そのサイトで**Jira Service Managementの製品アクセス権**(エージェントシート)を持っている必要があります。サイトへのアクセスだけでは不十分です。 -* [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens)でクラシックなAtlassian APIトークンを作成します。専用のサービスアカウントの使用をお勧めします。 - -#### Connector Mappings - -1. **Location**フィールドにAtlassianサイトのURLを入力します: `https://{your-site}.atlassian.net`。 -2. **Email**フィールドに、トークンが属するAtlassianアカウントのメールアドレスを入力します。 -3. **Secret**フィールドにAPIトークンを入力します。 - -各AssetsオブジェクトはオブジェクトのラベルにちなんだRecordとなり、その**object schema**でグループ化されます。 - -## **Kubescape** - -Kubescapeコネクタは、[Kubescapeオペレーター](https://kubescape.io/docs/install-operator/)によって生成されたKubernetesのposture(構成不備)結果を、クラスタのKubernetes APIから直接読み取ります — ARMO SaaSアカウントは不要です。オペレーターのクラスタ内ストレージ集約APIが提供する`WorkloadConfigurationScan`オブジェクト(`spdx.softwarecomposition.kubescape.io/v1beta1`)を読み取ります。posture結果を持つ各Kubernetesの**namespace**はRecord(Product)にマッピングされ、ワークロード上の失敗したcontrolはそれぞれFindingになります。 - -#### Prerequisites - -- 対象クラスタでKubescapeオペレーターがインストールされ、構成スキャンが有効になっている必要があります([クラスタへのインストール](https://kubescape.io/docs/install-operator/)を参照)。`kubectl get workloadconfigurationscans -A`で結果が存在することを確認してください。 -- 対象クラスタの`spdx.softwarecomposition.kubescape.io` APIグループ(`workloadconfigurationscans`に対するlist/get)への読み取りアクセスを許可する**kubeconfig**。 - -#### Connector Mappings - -1. **Location**フィールドにクラスタのAPIサーバーURL(またはわかりやすいクラスタ識別子)を入力します。 -2. `kubeconfig`フィールドに対象クラスタの**kubeconfig**を貼り付けます。必要に応じて`kube_context`でその中のコンテキストを選択し、`cluster_name`で検出されるProductにラベルを付けられます。 -3. posture結果を持つ各namespaceがRecordとして検出されます。DefectDojoのProductにマッピングしたいものを選択してください。 - -検出事項は失敗したcontrolごとに導出されます。control名とワークロードがFindingを識別し、深刻度はcontrolのスコア係数から取得され、control IDが脆弱性IDになり、各Findingは`https://hub.armosec.io/docs/`のcontrolリファレンスにリンクします。 - -## **Mend** - -Mendコネクタ(旧**WhiteSource**)は、Mend APIを使用して、Mend組織からセキュリティ検出事項をインポートします。DefectDojoは各Mend**project**にRecordを作成します。 - -#### Prerequisites - -Mendの**User Key**(個人アクセストークン)を持つMend(サービス)ユーザーと、Mendの**Organization UUID**が必要です。自動化された操作を手動のチーム操作と区別しやすくするため、専用のサービスアカウントの使用をお勧めします。Organization UUIDは、Mendアプリの**Administration > Organization UUID**にあります。 - -#### Connector Mappings - -1. **Location**フィールドにMendのAPI URLを入力します。このURLは**リージョン固有**です — Mend組織がホストされているリージョンのAPIベースURLを使用してください。 -2. **Email**フィールドにMendユーザーのログインメールアドレスを入力します。 -3. **Organization UUID**フィールドにMendの**Organization UUID**を入力します。 -4. **User Key**フィールドにMendの**User Key**を入力します。 -5. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。 - -## **Lacework / FortiCNAPP** - -Lacework / FortiCNAPPコネクタは、Lacework v2 APIを使用して、Laceworkアカウント全体の**ホストおよびコンテナの脆弱性**をインポートします。 - -#### Prerequisites - -Laceworkの**APIキー**(APIキーIDとシークレット)が必要です。これはLaceworkコンソールの**Settings → API keys**で作成します。コネクタは同期のたびにこれらを短命のアクセストークンと交換します。キーID、シークレット、トークンはログに記録されません。 - -#### Connector Mappings - -1. **Location**フィールドにLaceworkのアカウントURLを入力します — 例: `https://YOUR-ACCOUNT.lacework.net`(アカウント名のみでも受け付けられます)。 -2. **API Key ID**と**API Secret**を入力します。 -3. 必要に応じて**Minimum Severity**を設定し、インポートする検出事項を制限できます。 - -DefectDojoはLaceworkの**アカウント**をRecord(アカウント全体のスコープ)にマッピングします。各**container**と**host**の脆弱性はそれぞれ検出事項になります。深刻度はLacework独自の評価から取得され、影響を受けるパッケージとバージョンがcomponentになり、修正バージョンがmitigationになり、影響を受けるイメージ/ホストはタグとして記録されます。コンテナの脆弱性は静的検出事項(イメージスキャン)として、ホストの脆弱性は動的検出事項(実行中ホストのスキャン)として記録されます。 - -詳細については、[Lacework APIドキュメント](https://docs.lacework.net/api/v2/docs)を参照してください。 - -## **Microsoft Defender** - -Microsoft Defenderコネクタは、**Microsoft Defender Vulnerability Management (MDVM)** からデバイスの脆弱性検出事項をインポートします。これはデバイス／ソフトウェアバージョン／CVEの組み合わせごとに1件の検出事項であり、深刻度、CVSSスコア、悪用可能性のレベル、推奨されるセキュリティ更新プログラムを含みます。DefectDojoはお使いのDefenderの**デバイスグループ**を検出し、それぞれについてRecordを作成します。どのデバイスグループにも割り当てられていないデバイスは、合成的な**Unassigned**グループの下にまとめられます。 - -**ご注意ください:** このConnectorは、手動でエクスポートしたDefenderファイルをインポートするファイルベースの**「MSDefender Parser」**スキャンタイプとは別のものです。重複した検出事項を避けるため、製品ごとにいずれか一方のインポート経路を選択してください。 - -#### 前提条件 - -お使いのMicrosoftテナントには、Defenderの脆弱性エクスポートAPIを含むアクティブなライセンスが必要です: **Defender for Endpoint Plan 2**、**Microsoft Defender Vulnerability Management Standalone**、またはMDVMアドオン付きのMDE P1/P2のいずれかです。（MDVMの*アドオン*SKU単体では不十分で、その下にDefender for Endpoint Plan 2が必要です。） - -このコネクタは、クライアントクレデンシャルフローを使用してMicrosoft Entra IDの**アプリ登録**として認証を行います。作成手順は次のとおりです。 - -1. [Azureポータル](https://portal.azure.com)で **App registrations > New registration** を開きます。名前を付け（例: `defectdojo-connector`）、デフォルトのまま **Register** を選択します。 -2. アプリの **Overview** ページで、**Application (client) ID** と **Directory (tenant) ID** を控えます。 -3. **API permissions > Add a permission > APIs my organization uses** を開き、**WindowsDefenderATP** を検索します。表示されない場合は、テナントのDefenderバックエンドがまだプロビジョニングされていません。ライセンスがアクティブであることを確認し、一度 [security.microsoft.com](https://security.microsoft.com) を開いてから、数分後に再試行してください。 -4. **Application permissions** を選択し（*Delegated*ではありません — Delegated permissionsはコネクタのサービストークンには決して現れません）、**Vulnerability** を展開して **Vulnerability.Read.All** にチェックを入れ、**Add permissions** を選択します。 -5. **Grant admin consent** を選択して確認します。Statusカラムに緑色のチェックが表示される必要があります。このステップを行わないと、すべてのAPI呼び出しが403エラーを返します。 -6. **Certificates & secrets > New client secret** を開き、有効期限を設定し、シークレットの **Value** をただちにコピーします(一度しか表示されません)。シークレットが期限切れになるとConnectorは動作しなくなるため、期限日を控えておいてください。 - -#### Connector Mappings - -1. **Location** フィールドに `https://api.security.microsoft.com` を入力します。 -2. **Tenant ID** フィールドに **Directory (tenant) ID** を入力します。 -3. **Client ID** フィールドに **Application (client) ID** を入力します。 -4. **Client Secret** フィールドにクライアントシークレットの値を入力します。 -5. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 - -各Defenderデバイスグループが1件のRecordになります。Microsoftは、コネクタが読み取る脆弱性スナップショットをおよそ6時間ごとに再生成し、新しくオンボーディングされたデバイスが最初の脆弱性データを生成するまでに最大で約24時間かかることがあります — 新規テナントでは、デバイスがオンボーディングされ評価が完了するまで、Syncで検出事項が0件になるのが正常です。ライセンスの有効化自体もAPIに反映されるまで約20分以上かかることがあり、この間に発生する「No active license found」というエラーは自然に解消されます。 - -## **Microsoft Defender for Cloud** - -Microsoft Defender for Cloudコネクタは、Defender for Cloudを通じて表示される **Microsoft Defender Vulnerability Management (MDVM)** の脆弱性検出事項をインポートします。これには**サーバー**の検出事項(Azure VMのオペレーティングシステムおよびインストール済みソフトウェアのCVE)と**コンテナレジストリ**の検出事項(コンテナイメージのCVE)の両方が含まれ、深刻度、CVSSスコア、影響を受けるパッケージまたはイメージ、修復方法を含みます。DefectDojoは、サービスプリンシパルが読み取り可能なAzureの**サブスクリプション**を検出し、有効化されたサブスクリプションごとにRecordを作成します。 - -**ご注意ください:** このConnectorは、Defender for Endpoint APIからデバイスの検出事項をインポートする**Microsoft Defender**コネクタとは別のものです。Defender for Cloudは異なるAPIサーフェス(Azure Resource Manager / Resource Graph)と権限モデル(Azure RBAC)を持つAzure製品です。検出事項がどちらにあるかに応じて実行してください — 両方の製品を使用している場合は両方実行しても構いません。 - -#### 前提条件 - -**Microsoft Defender for Cloudが有効化された**1つ以上のAzureサブスクリプションが必要で、スキャン対象のリソースに応じて関連するDefenderプランを有効にしておく必要があります(**Microsoft Defender for Cloud > Environment settings** の下で、サブスクリプションを選択します): - -* **Defender for Servers (Plan 2)** — Azure VMのオペレーティングシステムおよびソフトウェアのCVE検出事項(エージェントレス脆弱性スキャン)。 -* **Defender for Containers** — コンテナレジストリのイメージCVE検出事項。 - -SQLの脆弱性評価および設定/ポスチャの検出事項は意図的に**インポートされません** — このコネクタはCVEの脆弱性のみをインポートします。 - -このコネクタは、クライアントクレデンシャルフローを使用してMicrosoft Entra IDの**アプリ登録**として認証を行います。 - -1. [Azureポータル](https://portal.azure.com)で **App registrations > New registration** を開きます。名前を付け(例: `defectdojo-connector`)、デフォルトのまま **Register** を選択します。 -2. アプリの **Overview** ページで、**Application (client) ID** と **Directory (tenant) ID** を控えます。 -3. **Certificates & secrets > New client secret** を開き、有効期限を設定し、シークレットの **Value** をただちにコピーします(一度しか表示されません)。シークレットが期限切れになるとConnectorは動作しなくなるため、期限日を控えておいてください。 -4. インポートしたい各サブスクリプションに対してアプリに読み取りアクセス権を付与します: **Subscriptions** を開き、サブスクリプションを選択し、**Access control (IAM) > Add > Add role assignment** を選びます。**Security Reader** ロール(または **Reader**)を選択し、**Members** タブで作成したアプリに割り当てます — ピッカーはクライアントIDと一致しないため、アプリの**名前**または**オブジェクトID**で検索してください。すべてのサブスクリプションについて繰り返します。 - -デバイスベースのMicrosoft Defenderコネクタとは異なり、API permissionやadmin consentは不要です。Defender for Cloudへのアクセスは、上記のAzure RBACロール割り当てのみによって管理されます。 - -#### Connector Mappings - -1. **Location** フィールドに `https://management.azure.com` を入力します。(政府専用クラウドなど特殊な環境では、対応するARMエンドポイントを使用してください。例: `https://management.usgovcloudapi.net`。) -2. **Tenant ID** フィールドに **Directory (tenant) ID** を入力します。 -3. **Client ID** フィールドに **Application (client) ID** を入力します。 -4. **Client Secret** フィールドにクライアントシークレットの値を入力します。 -5. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 - -有効化された各Azureサブスクリプションが1件のRecordになります。検出事項はAzure Resource Graphを通じて読み取られるため、Defender for Cloudがリソースをスキャンし終えるとすぐに反映されますが、スキャン自体はMicrosoftのスケジュールで実行されます — コンテナレジストリのイメージは通常プッシュから1時間以内にスキャンされますが、VMの最初のエージェントレス脆弱性スキャンには数時間かかることがあります。新しく有効化されたサブスクリプションでは、リソースがスキャンされるまでSyncで検出事項が0件になるのが正常です。 - -## **MobSF** - -MobSFコネクタは、[Mobile Security Framework (MobSF)](https://github.com/MobSF/Mobile-Security-Framework-MobSF) REST APIを使用して、モバイルアプリケーション(APK/IPA)の静的解析結果をインポートします。DefectDojoは、お使いのMobSFインスタンス上でスキャン済みのすべてのアプリを検出し、それぞれについてRecordを作成した上で、そのアプリの静的解析の検出事項をインポートします。 - -#### 前提条件 - -MobSFの**REST APIキー**が必要です。MobSFのホームページの **API** の下にあります(MobSFドキュメントでは `Authorization` 値としても示されています)。このキーはすべてのリクエストで送信され、ログに記録されることはありません。 - -#### Connector Mappings - -1. **Location** フィールドにMobSFのベースURLを入力します(例: `https://mobsf.example.com`)。 -2. **Secret** フィールドに、MobSFのREST APIキーを入力します。 -3. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 - -DefectDojoは、スキャン済みの各**アプリ**をRecordにマッピングし、MobSFのJSONレポートの複数のセクション — アプリケーションの権限、コード解析、署名証明書、Androidマニフェスト、Android APIの使用状況、バイナリ解析 — から検出事項をインポートします。各検出事項には**CWE 919**(モバイル)のタグが付けられ、深刻度はMobSF自身の評価(high、warning、info、secure/good)に基づきます — *dangerous*な権限はHighとして扱われます。検出事項は静的検出事項として記録され、スキャン、セクション、タイトル、深刻度、ファイルパスで重複排除されます。 - -詳細については、[MobSF REST APIドキュメント](https://mobsf.github.io/docs/#/rest_api)を参照してください。 - -## **NeuVector** - -NeuVectorコネクタは、[NeuVector](https://github.com/neuvector/neuvector) コントローラのREST APIを使用して、コンテナ**イメージの脆弱性スキャン**をインポートします。DefectDojoは、NeuVectorがスキャンしたすべてのイメージを検出し、それぞれについてRecordを作成した上で、そのイメージのスキャンレポートを検出事項としてインポートします。 - -#### 前提条件 - -スキャン結果の読み取り権限を持つコントローラアカウントの、NeuVectorの**ユーザー名とパスワード**が必要です。コネクタはこれらの認証情報でログインしてセッショントークンを取得します。パスワードとトークンはログに記録されることはありません。 - -#### Connector Mappings - -1. **Location** フィールドに、REST APIポートを含むNeuVectorコントローラのURLを入力します — 例: `https://neuvector.example.com:10443`。 -2. コントローラの **Username** と **Password** を入力します。 -3. コントローラが自己署名証明書を使用している場合は、**Skip TLS Verification** を `true` に設定します。 -4. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 - -DefectDojoは、スキャン済みの各**イメージ**をRecordにマッピングし、そのスキャンレポート内の各**CVE**を検出事項にマッピングします。深刻度はNeuVector自身の評価に基づき、影響を受けるパッケージとバージョン、CVSSv3スコアとベクター、修正バージョン(緩和策として)、参照リンクが引き継がれます。検出事項は、イメージ、CVE、パッケージ、バージョン、深刻度で重複排除されます。 - -詳細については、[NeuVector APIドキュメント](https://open-docs.neuvector.com/automation/automation)を参照してください。 - -## **Nuclei (ProjectDiscovery Cloud)** - -NucleiコネクタはProjectDiscovery Cloud Platform (PDCP) REST APIを使用して、お使いのPDCPアカウントから [nuclei](https://github.com/projectdiscovery/nuclei) のスキャン結果を取得します。DefectDojoはアカウント内のすべてのスキャンを検出し、**スキャン**ごとに個別のRecordを作成します。 - -#### 前提条件 - -ProjectDiscovery Cloudの**APIキー**が必要です。自動化された処理と手動のチーム操作を明確に区別するため、DefectDojo専用のサービスアカウントを作成することをお勧めします。ProjectDiscovery Cloud UI([cloud.projectdiscovery.io](https://cloud.projectdiscovery.io))の **Settings > API Key** からキーを生成します。結果は、ホスト型スキャンから、または `-dashboard` を付けて実行したnuclei CLIからPDCPに届きます。 - -#### Connector Mappings - -1. **Location** フィールドにPDCPのAPIベースURLを入力します: `https://api.projectdiscovery.io`。 -2. **Secret** フィールドに**APIキー**を入力します。 -3. 必要に応じて、**Team ID** を入力してチームワークスペースに同期範囲を絞り込みます(**Settings > Team** の下にあります)。空欄のままにすると、DefectDojoは個人用ワークスペースを同期します。 -4. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 - -DefectDojoは、各PDCPの**スキャン**を個別のRecordとしてマッピングし、情報レベルを含むすべての深刻度にわたって、そのスキャンの検出事項をインポートします。 - -## **OpenVAS / Greenbone** - -OpenVAS / Greenboneコネクタは、Greenbone(Greenbone Community EditionまたはGreenbone Enterprise)インスタンスから**ネットワーク脆弱性の検出事項**をインポートします。これは、HTTPではなく**GMP (Greenbone Management Protocol)** — TLSソケット上のXMLプロトコル — を介して `gvmd` と通信し、インスタンス全体を同期します。スキャン**タスク**を列挙してそれぞれについてDefectDojoの製品を作成し、各タスクの最新レポートの結果をインポートします。 - -#### 前提条件 - -Greenboneの**GMPユーザー**(ユーザー名とパスワード)と、gvmdのGMP TLSポート(デフォルトは**9390**)へのネットワークアクセスが必要です。Greenbone Community Editionのcomposeスタックは、unixソケット経由でgvmdをフロントに置いているため、ネットワーク経由のコネクタからそこに到達するには、ソケットに到達できる場所でコネクタを実行するか、GMP TLSポートを公開する必要があります(例: `gvmd.sock` へのTLSブリッジとして `socat` を使用)。 - -#### Connector Mappings - -1. **Location** フィールドにgvmdホストを入力します(ホスト名、または `host:port`)。 -2. GMPの **Username** と **Password** を入力します。 -3. 必要に応じて **GMP Port** を設定します(デフォルトは9390)。 -4. gvmdのデフォルトの自己署名証明書に対しては、検証用に **CA Certificate (PEM)** を指定するか、**Skip TLS Verification** を `true` に設定してください。 -5. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 - -各Greenboneタスクが1件のRecordになります。検出事項はタスクの最新の完了レポートから取得され、`` ごとに1件です。深刻度は結果の脅威レベルから取得され(Greenboneの `Log`/`Debug` の情報レベルはInfoにマッピングされます)、数値のCVSSスコアが記録されます。CVEの参照は脆弱性IDになり、NVTのsolutionは緩和策になり、各結果のホスト/ポートはエンドポイントになります。 - -## Probely - -このコネクタは、Probely REST APIを使用してデータを取得します。 - -​**Connector Mappings** - -1. **Location** フィールドに適切なAPIサーバーアドレスを入力します。( または のいずれか) -2. **Secret** フィールドに有効なAPIキーを入力します。 - -APIキーは、ProbelyのUser > API Keysメニューから確認できます。 -詳細については[Probelyのドキュメント](https://help.probely.com/en/articles/8592281-how-to-generate-an-api-key)を参照してください。 - -## Prowler - -Prowlerコネクタは**Prowler App** REST APIを使用して、セルフホスト型のProwler Appインスタンスからクラウドセキュリティポスチャ (CSPM) の検出事項をインポートします。DefectDojoは各Prowler**プロバイダ**(クラウドアカウント)をRecordとして検出し、そのプロバイダの最新の完了済みスキャンの**FAIL**検出事項をインポートします。 - -#### 前提条件 - -実行中のセルフホスト型**Prowler App**インスタンスと、ユーザーのメールアドレス+パスワード(JWT認証用)またはProwler Appの**APIキー**のいずれかが必要です。検出事項は、Prowler Appでクラウドアカウント(AWS、GCP、Azure、Kubernetesなど)を接続してスキャンを実行して初めて表示されます。 - -#### Connector Mappings - -1. **Location** フィールドにProwler AppのURLを入力します(例: `https://prowler.your-company.com`)。 -2. JWT認証の場合は、Prowler Appユーザーの **Email** と **Password** を入力します。あるいは、それらを空欄のままにして、Prowler Appの **API Key** を入力します。両方が指定された場合は、メール/パスワード(JWT)が使用されます。 -3. 必要に応じて **Minimum Severity** を設定し、インポートする検出事項を絞り込みます。選択した深刻度未満の検出事項はインポートされません。 - -DefectDojoは各ProwlerプロバイダについてRecordを作成し、その最新の完了済みスキャンのFAIL検出事項をインポートします。その際、Prowlerの深刻度をDefectDojoの深刻度にマッピングし、影響を受けるクラウドリソース(ARN/リソースID)をコンポーネントとして、チェックの修復方法とリスクを検出事項に反映します。ミュートされた検出事項はスキップされます。クラウドアカウント、リージョン、サービスはタグとして付与されます。 - -詳細については、**[Prowler App APIドキュメント](https://api.prowler.com/api/v1/docs)**を参照してください。 - -## Qualys - -Qualysコネクタは、Qualys Cloud Platformから**VMDRホストの脆弱性検出結果**をインポートします。これは、それぞれQualysのKnowledgeBase (QID) メタデータと結合されています。DefectDojoは、お使いのサブスクリプション内の各Qualys**ホスト**についてRecordを作成します。 - -#### 前提条件 - -**VMDR APIアクセス**を持つQualysユーザーアカウントと、サブスクリプションの**APIサーバー(プラットフォーム)URL**が必要です — これはサブスクリプションごとに異なります。Qualys UIの **Help > About** の下、またはQualysの[Platform Identification](https://www.qualys.com/platform-identification/)ページで確認できます(例: US Platform 1の場合は `https://qualysapi.qualys.com`、US Platform 2の場合は `https://qualysapi.qg2.apps.qualys.com`)。 - -#### Connector Mappings - -1. **Location** フィールドにQualysのAPIサーバーURLを入力します(例: `https://qualysapi.qualys.com`)。 -2. **Username** フィールドにQualys APIのユーザー名を入力します。 -3. **Secret** フィールドにQualys APIのパスワードを入力します。 -4. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 - -各Qualysホストが1件のRecordになります。Qualysが**Fixed**とマークした検出結果は除外されるため、再インポートによって修復済みの検出事項がクローズされます。 - -## **Quay** - -QuayコネクタはProject Quay REST APIを使用して、コンテナリポジトリを検出し、Quay組み込みの**Clair**スキャナが生成した脆弱性レポートをインポートします。DefectDojoは各Quay**リポジトリ**についてRecordを作成し、Syncのたびにアクティブな各タグのイメージマニフェストのClairセキュリティレポートを読み取ります。 - -#### 前提条件 - -Quayインスタンスでセキュリティスキャン(Clair)が有効になっている必要があり、Quayの**OAuth 2アクセストークン**が必要です: - -* Quayで、Organizationを作成(または開き)、**Applications** に移動し、OAuthアプリケーションを作成し、少なくとも**Read repositories**スコープで **Generate Token** を実行します。DefectDojo専用のアプリケーションを作成することをお勧めします。 -* トークンはすべてのリクエストでBearerトークンとして送信され、ログに記録されることはありません。 - -#### Connector Mappings - -1. **Location** フィールドにQuayのベースURLを入力します。例: `https://quay.io` またはセルフホストの `https://quay.example.com`。URLはHTTPSである必要があり、末尾にAPIパスを含めないでください — DefectDojoがAPIパスを自動的に構築します。 -2. **Secret** フィールドにOAuthアクセストークンを入力します。 -3. 必要に応じて **Namespace** を設定し、検出範囲を単一のQuay組織またはユーザーに限定します。空欄のままにすると、トークンが読み取れるすべてのリポジトリが検出されます。 -4. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 - -DefectDojoは各Quay**リポジトリ**をRecordにマッピングします。各リポジトリについてアクティブなタグを列挙し、それらを一意のイメージマニフェストへと重複排除した上で(複数のタグで共有されるマニフェストは1回だけスキャンされます)、各マニフェストのClairレポートを読み取ります。Clairがまだスキャンを完了していないマニフェスト(例えばマルチアーキテクチャのマニフェストリストや、まだキュー中のイメージ)は、後のSyncまでスキップされます。各Clairの脆弱性は検出事項になります — 影響を受けるパッケージがコンポーネントとなり、修正バージョンが緩和策となり、Clairの**Negligible**/**Unknown**の深刻度は**Informational**として記録されます。 - -詳細については、[Project Quay APIドキュメント](https://docs.projectquay.io/api_quay.html)および[Clairドキュメント](https://quay.github.io/clair/)を参照してください。 - -## **Rapid7 InsightAppSec** - -Rapid7 InsightAppSecコネクタは、InsightAppSecクラウドプラットフォームから**DAST脆弱性検出事項**をインポートし、アタックモジュールのメタデータ(例: *SQL Injection*)、CVSSスコア、スキャンで収集された証拠を付加します。DefectDojoは各InsightAppSecの**アプリ**についてRecordを作成します。 - -**ご注意ください:** このConnectorは、以下の**Rapid7 InsightVM**コネクタとは別のものです — InsightAppSecはInsightプラットフォーム上のRapid7のクラウドDAST製品であり、InsightVMの検出事項はお使いのSecurity Consoleから取得されます。 - -#### 前提条件 - -InsightAppSecを利用するInsightプラットフォームのアカウントと、プラットフォームの**APIキー**が必要です: [Rapid7 Insightプラットフォーム](https://insight.rapid7.com)で設定(歯車)メニュー > **API Keys** を開き、**User Key**(任意のロール)または**Organization Key**(プラットフォーム管理者)を生成します。表示された時点でキーをコピーしてください — 一度しか表示されません。 - -また、Insight URLに表示されるプラットフォームの**リージョン**(例: `us`、`us2`、`us3`、`eu`、`ca`、`au`、`ap`)も必要です。 - -#### Connector Mappings - -1. **Location** フィールドにリージョンのAPIエンドポイントを入力します — 例: `https://us.api.insight.rapid7.com`(`us` をお使いのリージョンに置き換えてください)。 -2. **API Key** フィールドにInsightプラットフォームのAPIキーを入力します。 -3. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 - -各InsightAppSecアプリが1件のRecordになります。**オープン**な脆弱性(UnreviewedまたはVerified)のみがインポートされます — Rapid7がRemediated、False Positive、Ignored、またはDuplicateとマークした検出事項は除外されるため、再インポートによってDefectDojo内でそれらがクローズされます。深刻度は直接マッピングされます(`SAFE` と `INFORMATIONAL` はInfoとしてインポートされます)。 - -## **Rapid7 InsightVM** - -Rapid7 InsightVMコネクタは、お使いのInsightVM**Security Console**(API v3)からアセットの脆弱性検出事項をインポートし、コンソールのグローバル脆弱性カタログで情報を付加します。DefectDojoは各InsightVM**サイト**についてRecordを作成します。 - -#### 前提条件 - -DefectDojoからお使いのSecurity Consoleへのネットワークアクセスと、コンソールの**ユーザーアカウント**が必要です — そのログイン情報がHTTP Basic認証に使用されます。コンソールAPIはデフォルトでポート**3780**で提供されます。 - -#### Connector Mappings - -1. **Location** フィールドに、ポートを含むSecurity ConsoleのURLを入力します — 例: `https://console.example.com:3780`。 -2. **Username** フィールドにコンソールのユーザー名を入力します。 -3. **Secret** フィールドにコンソールのパスワードを入力します。 -4. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 - -各InsightVMサイトが1件のRecordになります。コネクタはサイトのアセットを走査し、脆弱性のある検出事項をインポートします。 - -## **runZero** - -runZeroコネクタはrunZero Export APIを使用して、組織全体のアセットインベントリをDefectDojoに同期します。これは主に**アセット**コネクタです: DefectDojoはすべてのアセットを検出してそれぞれについてRecordを作成し、runZeroの**サイト**ごとにProduct Typeにグループ化します。オプションで、runZeroの脆弱性を検出事項としてインポートすることもできます。 - -#### 前提条件 - -runZero(Account → API)から組織の**Export Token**が必要で、これは `XT` というプレフィックスが付きます。このトークンは組織スコープ(組織がトークン内にエンコードされています)、読み取り専用であり、Bearerトークンとして送信されます — ログに記録されることはありません。コミュニティ/スタータープランも利用できます。 - -#### Connector Mappings - -1. **Location** フィールドにrunZeroコンソールのURLを入力します。例: `https://console.runzero.com`。URLはHTTPSである必要があります。 -2. **Secret** フィールドにExport Tokenを入力します。 -3. 必要に応じて **Import Vulnerabilities** を `true` に設定すると、runZeroの脆弱性も検出事項としてインポートされます。空欄のままにすると、アセットのみが同期されます。 -4. 必要に応じて **Minimum Severity** を設定し、インポートする脆弱性の検出事項を絞り込みます(脆弱性がインポートされる場合にのみ適用されます)。 - -DefectDojoは各runZero**アセット**をRecord (VEP) にマッピングします: 表示名はアセットの名前またはアドレスから取得され、そのサイト、種別、OS、アドレス、タグが属性として付与されます。アセットの**サイト**がそのProduct Typeになります。アセットは、DefectDojoが差分を調整する(追加/削除する)完全なエクスポートによって同期されます。**Import Vulnerabilities** が有効な場合、各runZeroの脆弱性はそのアセット上の検出事項になります — 深刻度、CVSSスコア、CVE、影響を受けるサービス(`protocol://address:port`)のエンドポイント、および修復方法がマッピングされます。 - -詳細については、[runZero APIドキュメント](https://help.runzero.com/)を参照してください。 - -## **Semgrep** - -このコネクタは、Semgrep REST APIを使用してデータを取得します。 - -#### Connector Mappings - -**Location** フィールドに `https://semgrep.dev/api/v1/` を入力します。 - -1. **Secret** フィールドに有効なAPIキーを入力します。これはTokensページで確認できます: -​ -左側のナビゲーションバーの「Settings」 \> Tokens \> Create new token ([https://semgrep.dev/orgs/\-/settings/tokens](https://semgrep.dev/orgs/-/settings/tokens)) - -詳細については[Semgrepのドキュメント](https://semgrep.dev/docs/semgrep-cloud-platform/semgrep-api/#tag__badge-list)を参照してください。 - -## **ServiceNow CMDB** - -ServiceNow CMDBコネクタは**アセットコネクタ**です: 検出事項をインポートする代わりに、お使いのServiceNow構成管理データベースからConfiguration Item (CI) を読み取り、各CIについてDefectDojoアセットを作成し、CIクラスごとにOrganizationにグループ化します。検出事項はインポートされません。 - -#### 前提条件 - -ServiceNowインスタンスと、ServiceNow Table API経由でCMDBテーブルを読み取れるアカウントが必要です。DefectDojo専用の読み取り専用サービスアカウントの利用をお勧めします。このアカウントには、インポートしたい `cmdb_ci` テーブルへの読み取りアクセス権が必要です。 - -#### Connector Mappings - -1. **Location** フィールドにServiceNowインスタンスのURLを入力します: `https://{your-instance}.service-now.com`。 -2. インスタンスの認証情報(ServiceNowのユーザー名とパスワード)を保持するServiceNowの**Tool Configuration**を選択または作成します。 - -各Configuration ItemがCIの名前を冠したRecordになり、その**CIクラス**(例: application、server、business serviceなど)でグループ化されます。DiscoveryとSyncはCIリストの差分を調整します: 新しいCIは `NEW` のRecordとして表示され、CMDBから削除されたCIは、チームがトリアージできるように次回のSyncで `MISSING` としてフラグが立てられます。DefectDojoが製品を黙って削除することはありません。 - -## **Shodan** - -Shodanコネクタは、Shodan REST APIを使用して、インターネットに露出しているホストでShodanが観測した脆弱性 (CVE) をインポートします。お使いの資産に取り込み範囲を限定するShodan検索クエリを指定し、DefectDojoは一致する各ホストについてRecordを作成し、そのCVEを検出事項としてインポートします。 - -#### 前提条件 - -Shodanの**Account**ページで確認できるShodan APIキーが必要です。脆弱性データ付きのホスト検索には、Shodanのメンバーシップまたは有料APIプランが必要です — 無料プランでは検索結果をページングできません。 - -#### Connector Mappings - -1. **Location** フィールドに `https://api.shodan.io` を入力します。 -2. **API Key** フィールドにShodan APIキーを入力します。 -3. **Search Query** フィールドに、お使いの組織の資産に取り込み範囲を限定するShodanクエリを入力します — 例: `hostname:example.com`、`net:203.0.113.0/24`、`org:"Example Inc"`。このクエリに一致するホストのみがインポートされるため、自組織が所有するインフラストラクチャに範囲を限定してください。 -4. 必要に応じて、インポートする検出事項を絞り込むために **Minimum Severity** を設定します。 - -一致する各ホストが1件のRecordになり、そのホストの露出しているサービス上でShodanが検出した各CVEが検出事項としてインポートされます — 深刻度はCVSSスコアから導出され、利用可能な場合はEPSSとCISA KEVのコンテキストが含まれます。検索結果の各ページはShodanのクエリクレジットを1つ消費します。 - -## SonarQube - -SonarQubeコネクタは、SonarCloudアカウントまたはローカルのSonarQubeインスタンスのいずれからでもデータを取得できます。 - -**SonarCloudユーザーの場合:** - -1. Locationフィールドに https://sonarcloud.io/ を入力します。 -2. Secretフィールドに有効な**APIキー**を入力します。 - -**SonarQube(オンプレミス)ユーザーの場合:** - -1. Locationフィールドにお使いのSonarQubeインスタンスのベースURLを入力します: 例 `https://my.sonarqube.com/` -2. Secretフィールドに有効な**APIキー**を入力します。これは**[User](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/)** [APIトークンタイプ](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/)である必要があります。 - -このトークンには、Sonar内のProjects、Vulnerabilities、Hotspotsへのアクセス権が必要です。 - -APIトークンは、SonarQubeアプリの **My Account -> Security -> Generate Token** から確認・生成できます。詳細については、[SonarQubeドキュメントを参照してください](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/)。 - -## **Snyk** - -Snykコネクタは、Snyk REST APIを使用してデータを取得します。 - -#### Connector Mappings - -1. **Location** フィールドに **[https://api.snyk.io/rest](https://api.snyk.io/v1)** または(リージョナルなEUデプロイメントの場合)**[https://api.eu.snyk.io/rest](https://api.eu.snyk.io/v1)** を入力します。 -2. **Secret** フィールドに有効なAPIキーを入力します。APIトークンは、Snykのユーザーの**[アカウント設定](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token)**[ページ](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token)にあります。 - -詳細については[Snyk APIドキュメント](https://docs.snyk.io/snyk-api)を参照してください。 - -## **Socket** - -Socket コネクタは [Socket.dev](https://socket.dev) API を使用して、**ソフトウェアサプライチェーンの検出事項**（依存関係に対する Socket のアラート — マルウェア、タイポスクワッティング、インストールスクリプト、既知の脆弱性、その他 70 以上のカテゴリ）をインポートします。DefectDojo はトークンがアクセスできる組織内のすべてのリポジトリを検出し、それぞれに対して Record を作成した上で、そのリポジトリの最新のフルスキャンからアラートをインポートします。 - -#### Prerequisites - -Socket の **API トークン**（Socket ダッシュボードの **Settings → API Tokens** で作成する組織トークンで、`repo:list` とフルスキャンの読み取りスコープを持つもの）が必要です。トークンはベアラートークンとして送信され、ログに記録されることはありません。 - -#### Connector Mappings - -1. **Location** フィールドを空欄のままにすると `https://api.socket.dev/v0` が使用されます。明示的に入力することもできます。 -2. **Secret** フィールドに Socket API トークンを入力します。 -3. 必要に応じて、**Minimum Severity** を設定してインポートする検出事項を絞り込みます。 - -DefectDojo は各**リポジトリ**を Record にマッピングし、その最新のフルスキャンからアラートをインポートします。各アラートは検出事項になります。深刻度は Socket 自身の評価(low、medium、high、critical)に基づき、影響を受けるパッケージはコンポーネントおよび PURL になり、アラートのカテゴリ(サプライチェーンリスク、品質、メンテナンス、脆弱性、ライセンス)はタグとして記録され、アラートの詳細は説明に反映されます。検出事項は静的検出事項として記録され、Socket のアラートキーで重複排除されます。 - -詳細については、[Socket API ドキュメント](https://docs.socket.dev/reference)を参照してください。 - -## **Sonatype IQ** - -Sonatype IQ コネクタは Sonatype IQ Server(Nexus Lifecycle)の REST API を使用して、オープンソースコンポーネントの脆弱性をインポートします。IQ 組織内のすべてのアプリケーションを列挙し、それぞれについて、設定したライフサイクルステージにおけるそのアプリケーションの最新レポートからコンポーネントの脆弱性をインポートします。DefectDojo は各アプリケーションに対して自動的に Record を作成します — アプリケーションごとの設定は不要です。 - -#### Prerequisites - -インポートしたいアプリケーションに対して **View IQ Elements** 権限を持つ Sonatype IQ ユーザーアカウントが必要です。Sonatype はパスワードではなく、(IQ Server の **My Profile > User Token** で生成する)**ユーザートークン**を使用した認証を推奨しています。トークンの 2 つの部分は、以下の Username フィールドと User Token フィールドにそれぞれ対応します。このコネクタはセルフホスト型の IQ Server と、Sonatype がホストする(SaaS)インスタンスの両方に対応しています。 - -#### Connector Mappings - -1. **Location** フィールドに IQ Server のベース URL を入力します — セルフホスト型サーバーの場合は `https://iq.example.com`、Sonatype がホストするインスタンスの場合は `https://.sonatype.app/platform` です。 -2. **Username** フィールドに IQ ユーザー(またはユーザートークンのユーザーコード部分)を入力します。 -3. **User Token** フィールドに IQ ユーザートークン(またはパスワード)を入力します。 -4. 必要に応じて、**Stage** を設定して、アプリケーションごとにどのライフサイクルステージのレポートをインポートするかを選択します(`build`、`stage-release`、`release` など)。空欄のままにすると `build` が使用されます。 -5. 必要に応じて、**Minimum Severity** を設定してインポートする検出事項を絞り込みます。 - -各アプリケーションは Record になり、選択したステージにおけるそのアプリケーションの最新レポート内の各セキュリティ問題が検出事項としてインポートされます。深刻度は問題の数値スコアから導出され、CVE 参照、CWE、CVSS ベクター、影響を受けるコンポーネントのパッケージ URL(PURL)が利用可能な場合は含まれます。 -## **Sysdig Secure** - -Sysdig Secure コネクタは、Sysdig Secure の脆弱性管理 API から**コンテナ / CNAPP 脆弱性検出事項**をインポートします。設定されたスコープ全体でアカウント全体を同期し、スキャン対象のアセットグループごとに DefectDojo 製品を作成します。 - -#### Prerequisites - -Sysdig Secure の **API トークン**: Sysdig Secure で **Settings > Sysdig Secure API Token** に移動し、トークンをコピーします。また、Sysdig の**リージョン URL**(例: `https://us2.app.sysdig.com`、`https://eu1.app.sysdig.com`、またはオンプレミスホスト)も必要です。 - -#### Connector Mappings - -1. **Location** フィールドに Sysdig のリージョン / ベース URL を入力します。 -2. **Secret** フィールドに API トークンを入力します。 -3. 必要に応じて **Scopes** を設定します — `runtime`、`registry`、`pipeline` のカンマ区切りリストです(空欄の場合はデプロイ済みワークロードのスコープである `runtime` になります)。 -4. 必要に応じて **Runtime Product Grouping** を設定します — ランタイムの結果を製品にどうマッピングするか(`cluster`、`namespace`、`workload`、`image`)を指定します(空欄の場合は `namespace` になります)。レジストリおよびパイプラインの結果は常にイメージリポジトリ単位でグループ化されます。 -5. 必要に応じて、**Minimum Severity** を設定してインポートする検出事項を絞り込みます。 - -各アセットグループは Record になります。各スキャン結果について、コネクタは脆弱性のあるすべてのパッケージを検出事項としてインポートします。**Runtime** の検出事項(デプロイ済みワークロード)は動的検出事項として記録され、Kubernetes のクラスター / 名前空間 / ワークロード / コンテナのコンテキストがタグ付けされます。**registry** および **pipeline** の検出事項は静的なイメージスキャン検出事項として記録されます。Sysdig の `NEGLIGIBLE` 深刻度は Info にマッピングされます。 - -## Tenable - -Tenable コネクタは **Tenable.io** REST API を使用してデータを取得します。 スキャンは Tenable VM の `/scans` エンドポイントから取得されます。 - -オンプレミス版の Tenable コネクタは現時点では利用できません。 - -#### **Connector Mappings** - -1. Location フィールドに を入力します。 -2. Secret フィールドに有効な **API キー**を入力します。 - -詳細については、[Tenable の API ドキュメント](https://docs.tenable.com/vulnerability-management/Content/Settings/my-account/GenerateAPIKey.htm)を参照してください。 - -## **Tenable Web App Scanning** - -Tenable Web App Scanning コネクタは、Tenable Web App Scanning から**Web アプリケーション(DAST)検出事項**をインポートします。これは Tenable(Vulnerability Management)とは別のコネクタです。両製品は対象とするアセットが異なり、それぞれ独立して設定されるため、どちらか一方、または両方を使用できます。 - -DefectDojo は**スキャン対象の Web アプリケーション**ごとに Record を作成します。アプリケーションは Web App Scanning のスキャン設定から検出されます。一度も実行されていない設定は、最初のスキャンが完了するまで Record を生成しません。複数の設定が同じアプリケーションをスキャンする場合、それらは 1 つの Record を共有します。 - -#### Prerequisites - -Web App Scanning の権限を持つユーザー用の Tenable **API キー**(アクセスキーとシークレットキー)。Tenable で **My Account > API Keys** に移動して生成し、そのユーザーがインポートしたいスキャンを閲覧できることを確認してください — Vulnerability Management に限定されたキーでは Web App Scanning のデータを読み取れません。 - -オンプレミス版の Tenable コネクタは現時点では利用できません。 - -#### Connector Mappings - -1. **Location** フィールドに を入力します。 -2. **Access Key** と **Secret Key** を入力します。 -3. 必要に応じて、**Minimum Severity** を設定してインポートする検出事項を絞り込みます。 - -検出事項は、チームが変更した深刻度も含め、Tenable がアカウントに対して報告する深刻度でインポートされます。各検出事項には、影響を受ける URL がエンドポイントとして、検出のきっかけとなったリクエストパラメータとペイロード、および Tenable の証拠と出力が再現手順として含まれ、検出プラグインが提供する場合は CWE、CVE、CVSS、EPSS の値も含まれます。 - -現在オープンまたは再オープンされている検出事項のみがインポートされます。Tenable が修正済みとマークした検出事項は、次回の同期時に DefectDojo でクローズされます。 - -## **Veracode** - -Veracode コネクタは、Veracode プラットフォームからアプリケーションの検出事項をインポートし、スキャンタイプごとに **SAST**、**DAST**、**SCA**、**Manual** の検出事項タイプに分けます。DefectDojo は Veracode の**アプリケーション**ごとに Record を作成します。 - -#### Prerequisites - -インポートしたいアプリケーションを閲覧できるアカウントに対して、Veracode の **API 認証情報**を生成します: Veracode プラットフォームでアカウントメニューを開き、**API Credentials** から **Generate API Credentials** を選択します([Veracode API 認証情報の管理](https://docs.veracode.com/r/c_api_credentials3)を参照)。**API ID** と **API Secret Key** の両方をコピーしてください — シークレットは一度しか表示されません。 - -#### Connector Mappings - -1. **Location** フィールドに Veracode API のベース URL を入力します: `https://api.veracode.com`(商用リージョン)、`https://api.veracode.eu`(欧州リージョン)、または `https://api.veracode.us`(米国連邦リージョン)です。 -2. **API ID** フィールドに API ID を入力します。 -3. **Secret** フィールドに API シークレットキーを入力します。 -4. 必要に応じて、**Minimum Severity** を設定してインポートする検出事項を絞り込みます。 - -各 Veracode アプリケーションは Record になります。**open**(未解決)の検出事項のみがインポートされるため、再インポートを行うと、Veracode が解決済みと報告した検出事項はクローズされます。 - -## **Wazuh** - -Wazuh コネクタは、Wazuh Indexer(OpenSearch)を使用して脆弱性の検出事項を取得します。Wazuh 4.8 以降では、検出された CVE は Wazuh サーバー API ではなく Indexer に保存されるため、このコネクタは `wazuh-states-vulnerabilities-*` インデックスから直接それらを読み取ります。 - -DefectDojo は Wazuh エージェント(エンドポイント)ごとに Record を作成し、そのエージェントで検出された CVE をスケジュールに基づいて検出事項としてインポートします。 - -#### Prerequisites - -以下が必要です。 - -* ポートを含む Wazuh Indexer のベース URL(Indexer はデフォルトでポート 9200 で待ち受けます)。DefectDojo は Indexer に直接接続するため、このエンドポイントは DefectDojo から到達可能である必要があります。セルフマネージド環境では、これは Wazuh Indexer を実行しているホストです。Wazuh Cloud の場合は、Wazuh Cloud コンソールに表示される Indexer エンドポイントを使用してください。これは Wazuh ダッシュボードの URL とは別のものです。 -* `wazuh-states-vulnerabilities-*` インデックスへの読み取りアクセス権を持つ Indexer のユーザーとパスワード。DefectDojo 専用のユーザーを作成することをお勧めします。 - -脆弱性状態インデックスにデータが投入されるよう、Wazuh で脆弱性検出を有効にしておく必要があります。詳細については、[Wazuh 脆弱性検出ドキュメント](https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html)を参照してください。 - -#### Connector Mappings - -1. **Location** フィールドに、スキームとポートを含む Wazuh Indexer のベース URL を入力します。例: `https://your-indexer.example.com:9200`。末尾にパスを含めないでください。DefectDojo が検索パスを自動的に構築します。 -2. **Username** フィールドに Indexer のユーザー名を入力します。 -3. **Password** フィールドに Indexer のパスワードを入力します。 -4. 必要に応じて、**Minimum Severity** を設定してインポートする検出事項を絞り込みます。選択した深刻度を下回る検出事項はインポートされません。 - -## Wiz - -Wiz コネクタを使用するには、サービスアカウントを作成する必要があります。詳細については [Wiz のドキュメント](https://docs.wiz.io/wiz-docs/docs/service-accounts-settings#add-a-service-account)を参照してください。ドキュメントにアクセスするには Wiz アカウントが必要です。 - -サービスアカウントは、以下の要件をすべて満たしている必要があります。いずれかを満たしていないサービスアカウントでも認証自体は成功しますが、何もインポートされません。 - -* **Type**: Custom Integration(GraphQL API)。 -* **API scopes**: 最低限 `read:projects`、`read:issues`、`read:vulnerabilities` が必要です。 -* **Project visibility**: サービスアカウントは、インポートしたいすべての Wiz Project(またはすべての Project)に対してスコープが設定されている必要があります。コネクタはまず Wiz Project を検出し、その後各 Project の検出事項を取得します — issue を読み取れても Project の可視性がないアカウントは Project を 1 つも検出できないため、インポートするものがなく、双方からエラーも報告されません。 - -#### **Connector Mappings** - -1. Client ID フィールドに Wiz の Client ID を入力します。 -2. Secret フィールドに Wiz の Client Secret を入力します。 - -## **YesWeHack** - -YesWeHack コネクタは、YesWeHack REST API を使用して、バグバウンティおよび脆弱性開示プログラムからレポートをインポートします。DefectDojo は、トークンがアクセスできるプログラムごとに Record を作成し、そのレポートを検出事項としてインポートします。 - -#### Prerequisites - -YesWeHack の **Personal Access Token(PAT)**が必要です。プログラムへの読み取りアクセス権があれば十分です。一部のアカウントではトークン作成時に TOTP/MFA が必要ですが、作成後はトークンの値自体をコネクタが使用します。 - -1. YesWeHack でアカウント設定を開き、**API / Personal Access Tokens** に移動します。 -2. トークンを作成し、その値をコピーします。値は一度しか表示されません。 - -#### Connector Mappings - -1. **Location** フィールドに `https://api.yeswehack.com/` を入力します。 -2. **Secret** フィールドに Personal Access Token を入力します。 -3. 必要に応じて、**Minimum Severity** を設定してインポートする検出事項を絞り込みます。選択した深刻度を下回る検出事項はインポートされません。 - -DefectDojo は、トークンがアクセスできるプログラムごとに個別の Record を作成し、各レポートを検出事項としてインポートします。検出事項の深刻度はレポートの CVSS 評価から取得され(利用できない場合はトリアージの優先度にフォールバックします)、そのステータスはレポートのワークフロー状態を反映します — 例えば、解決済みのレポートは緩和済みとしてインポートされ、無効または対象外とマークされたレポートは非アクティブとしてインポートされます。 diff --git a/docs/content/connectors/upstream/toolreference.md b/docs/content/connectors/upstream/toolreference.md deleted file mode 100644 index 080423dbf11..00000000000 --- a/docs/content/connectors/upstream/toolreference.md +++ /dev/null @@ -1,2550 +0,0 @@ ---- -title: "Upstream Connectors Tool Reference" -description: "Our list of supported Connector tools, and how to set them up with DefectDojo" -aliases: - - /import_data/pro/connectors/connectors_tool_reference/ - - /en/connecting_your_tools/connectors/connectors_tool_reference ---- -Note: Upstream Connectors are a DefectDojo Pro-only feature. - -When setting up a Connector for a supported tool, you'll need to give DefectDojo specific information related to the tool's API. At a base level, you'll need: - -* **Location** \-a field whichgenerallyrefers to your tool's URL in your network, -* **Secret** \- generally an API key. - -Some tools will require additional API\-related fields beyond **Location** and **Secret**. They may also require you to make changes on their side to accommodate an incoming Connector from DefectDojo. - -![image](images/connectors_tool_reference.png) - -Each tool has a different API configuration, and this guide is intended to help you set up the tool's API so that DefectDojo can connect. - -Whenever possible, we recommend creating a new 'DefectDojo Bot' account within your Security Tool which will only be used by the Connector. This will help you better differentiate between actions manually taken by your team, and automated actions taken by the Connector. - -# **Asset Connectors** - -Most Connectors import **findings** from a security tool. **Asset Connectors** work differently: they import your **asset inventory** instead. An Asset Connector enumerates the assets that exist in an external platform (for example, the repositories in a GitLab group) and automatically creates and maintains the matching **Assets** and **Organizations** in DefectDojo. No findings are imported by an Asset Connector. - -* **Discover** and **Sync** both reconcile the asset list. New assets appear as `NEW` Records; once mapped (automatically, if auto-mapping is enabled), DefectDojo creates the Asset and groups it under an Organization derived from the tool — for example, the GitLab namespace or the Azure DevOps project. -* If an asset is later removed upstream (for example, a repository is deleted), its mapped Record is flagged `MISSING` on the next Sync so your team can triage it. DefectDojo never silently deletes an Asset. - -Azure DevOps, Backstage, Bitbucket, GitHub, GitLab, JSM Assets, and ServiceNow CMDB are Asset Connectors. runZero is primarily an Asset Connector but can optionally import vulnerabilities as findings. All other Connectors listed below import findings. - -# **Supported Connectors** - -## **AccuKnox** - -The AccuKnox connector imports **cloud security posture (CSPM) findings** across your whole AccuKnox tenant. DefectDojo creates a Record for each **connected cloud account**, plus a tenant\-level catch\-all Record — findings that match no specific account land there, so nothing is silently dropped. - -#### Prerequisites - -An AccuKnox **access key**. An access key inherits the permissions of the user who created it, and the **Viewer** role is sufficient. - -**Access keys expire.** When one does, the Sync fails with an authentication error rather than degrading quietly — so an authentication failure on a previously working connector usually means the key needs replacing, not that the connection is misconfigured. - -#### Connector Mappings - -1. Enter your AccuKnox CSPM host in the **Location** field. -2. Enter the access key in the **Secret** field. -3. Optionally, enter your AccuKnox **Tenant ID** (workspace ID). It is sent with every read request. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each connected cloud account becomes a Record, with AccuKnox's own four severity levels (Critical, High, Medium, Low) carried through. - -## **Action1** - -The Action1 connector imports **endpoint vulnerability findings** from Action1. DefectDojo creates a Record for each **endpoint (host)**. - -#### Prerequisites - -An Action1 **API key and secret** pair. The key acts as the OAuth client ID and the secret is never logged. - -#### Connector Mappings - -1. Enter `https://app.action1.com/api/3.0` in the **Location** field. -2. Enter the API key in the **API Key (Client ID)** field. -3. Enter the API secret in the **API Secret** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -**One finding is created per endpoint-and-vulnerability pair**, so a single CVE present on fifty hosts produces fifty findings, each attached to its own host's Record. This is what makes per\-host remediation tracking possible, but it does mean finding counts scale with fleet size rather than with the number of distinct CVEs. - -## **Acunetix 360** - -The Acunetix 360 connector imports **DAST vulnerability findings** from the Acunetix 360 cloud platform (the Invicti platform). DefectDojo discovers your account's scanned websites and creates a Record for each **website**; the findings for a website come from its latest completed scan. - -**Please note:** this connector is for **Acunetix 360** (the cloud product at `online.acunetix360.com`). It is not for the on\-premises Acunetix Standard/Premium scanner, which has a different API. - -#### Prerequisites - -An Acunetix 360 account and an **API credential**: in Acunetix 360, open your account menu \> **API Settings**, and note the **API User ID** and generate an **API Token**. The connector authenticates with these as HTTP Basic credentials, so a dedicated service account is recommended to distinguish automated activity from manual team actions. - -#### Connector Mappings - -1. Enter your Acunetix 360 URL in the **Location** field: `https://online.acunetix360.com`. -2. Enter the API User ID in the **API User ID** field. -3. Enter the API Token in the **API Token** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each scanned website becomes a Record. Findings come from the website's latest completed scan; vulnerabilities Acunetix 360 has marked **Accepted Risk** or **False Positive** are still imported but flagged inactive (risk\-accepted or false\-positive) so the DefectDojo product reflects the vendor's triage. - -## **Akamai** - -The Akamai API Security connector uses an API key to pull security findings from the Akamai API. DefectDojo will discover your Akamai environment and create separate Records for each **Application** and **Host** configured in your account. - -#### Prerequisites - -You will need an API key with access to the Akamai API. We recommend creating a dedicated service account for DefectDojo to clearly distinguish automated activity from manual team actions. - -#### Connector Mappings - -1. Enter your Akamai API base URL in the **Location** field. This URL is specific to your Akamai instance: for example -2. Enter a valid **API Key** in the **Secret** field. - -DefectDojo will map **Applications** and **Hosts** as separate Records. Each Application will appear as `{name} (application)` and each Host as `{name} (host)` in your Records list. - -## **Akto** - -The Akto connector imports **API security testing findings** from Akto. DefectDojo creates a Record for each Akto **API collection**. - -#### Prerequisites - -An Akto **API key**, created under **Settings \> Integrations \> Akto APIs** in the Akto dashboard. It is sent as the `X-API-KEY` header and is never logged. - -#### Connector Mappings - -1. Enter `https://app.akto.io` in the **Location** field for Akto's SaaS platform. If you run Akto self\-hosted, enter your own dashboard URL instead. -2. Enter your Akto API key in the **API Key** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each API collection becomes a Record. Only **open** issues are imported, so issues you resolve in Akto are reflected in DefectDojo on the next Sync. Both Akto SaaS and self\-hosted deployments use this connector — the only difference is the **Location** you supply. - -## **Alert Logic** - -The Alert Logic connector imports **vulnerability exposures** from your Alert Logic account. DefectDojo creates a Record for each Alert Logic **deployment**, with no per\-deployment configuration required. - -#### Prerequisites - -An Alert Logic **access key ID and secret key**, created under **Configure \> API Keys**. DefectDojo exchanges them for a short\-lived session token on each Sync; neither the secret nor the token is ever logged. - -#### Connector Mappings - -1. Enter your region's API URL in the **Location** field — `https://api.cloudinsight.alertlogic.com` (US) or `https://api.cloudinsight.alertlogic.co.uk` (UK). Alert Logic is region\-partitioned, so this must match the region your account lives in. -2. Enter the access key ID in the **Access Key ID** field. -3. Enter the secret in the **Secret Key** field. -4. Optionally, enter an **Account ID** to override the account the credentials authenticate into. This is intended for managed\-service parent accounts operating on a child account. -5. Optionally, set a **Minimum Severity** to limit which findings are imported. - -This connector imports **vulnerability exposures only** — MDR incidents are deliberately out of scope. - -## **Anchore Enterprise** - -The Anchore connector uses a user's API token to pull data from Anchore Enterprise. Assets will be mapped and discovered based on "Applications", which are composed of multiple Images in Anchore - see [Anchore Enterprise Documentation](https://docs.anchore.com/current/docs/sbom_management/application_groups/application_management_anchorectl/) for more information. - -#### Connector Mappings - -1. The Anchore URL in the **Location** field: this is the URL where you access the Anchore. -2. Enter a valid API Key in the Secret field. This is the API key associated with your Burp Service account. - -See the official [Anchore documentation](https://docs.anchore.com/current/docs/) for more information on creating a token for Anchore. - -## **AppCheck** - -The AppCheck connector imports **DAST vulnerability findings** from the AppCheck NG platform. DefectDojo discovers every scan on your account and creates a Record for each **scan** — there is no per\-scan configuration. - -#### Prerequisites - -An AppCheck **API key**, from the **API** section of your AppCheck account. - -**Treat this key like a password.** AppCheck sends it as part of the request path rather than in a header, so it forms part of the URL. DefectDojo registers the key for redaction and never logs a full request URL, but apply the same care wherever else you store it. - -#### Connector Mappings - -1. Enter `https://api.appcheck-ng.com` in the **Location** field. -2. Enter your AppCheck API key in the **API Key** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each scan becomes a Record, and its findings come from that scan's most recent **completed** run — so a scan that is still in flight never truncates the finding set. AppCheck fans a scan out across several engines (its own scanner, **Nmap**, and **OpenVAS**) and normalizes the output, so each finding carries the engine that reported it. - -## **Aqua Security** - -The Aqua Security connector imports **container image and workload vulnerability findings** across your whole Aqua tenant. DefectDojo creates a Record for each scanned **registry/repository**. - -#### Prerequisites - -An **admin-generated** Aqua **API key and secret**, created under **Account Management \> API Keys**. The secret is shown only once when the key is generated, so capture it at that point. Neither value is ever logged. - -#### Connector Mappings - -1. Enter your Aqua tenant URL in the **Location** field — `https://.cloud.aquasec.com`. DefectDojo appends the API path itself. -2. Enter the API key in the **API Key** field. -3. Enter the API secret in the **API Secret** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each scanned registry/repository becomes a Record, and its image and workload vulnerabilities are imported as findings. - -## **Automox** - -The Automox connector imports **missing patches** from Automox. DefectDojo creates a Record for each Automox **device group**. - -**A finding here is a missing patch**, not a scanner result — this connector reports patches Automox is waiting to apply, so use it to track patch coverage rather than as a vulnerability scanner. - -#### Prerequisites - -An Automox **API key**, from **Settings \> API** in the Automox console. It is sent as a bearer token and never logged. - -#### Connector Mappings - -1. Enter `https://console.automox.com/api` in the **Location** field. -2. Enter your Automox API key in the **API Key** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each device group becomes a Record, carrying the patches awaiting installation on the devices in that group. - -## **Azure DevOps** - -The Azure DevOps connector is an **Asset Connector**: it enumerates the git repositories in every project of your Azure DevOps organization and creates a DefectDojo Asset for each repository, grouped into Organizations by Azure DevOps project. No findings are imported. - -#### Prerequisites - -You will need a Personal Access Token (PAT) for the organization. We recommend creating the token from a dedicated service account. Only read scopes are required: - -1. In Azure DevOps, open **User settings \> Personal access tokens \> New Token**. -2. Click **Show all scopes**, then select **Code: Read** and **Project and Team: Read**. - -Only Azure DevOps Services (dev.azure.com) is supported; on-premise Azure DevOps Server is not supported at this time. - -#### Connector Mappings - -1. Enter your organization URL in the **Location** field: `https://dev.azure.com/{your-organization}`. Legacy `https://{your-organization}.visualstudio.com` URLs are also accepted, and any extra path segments (for example, a link to a specific project) are ignored. -2. Enter the PAT in the **Secret** field. - -Each repository becomes a Record named after the repository, grouped by its Azure DevOps **project**. Disabled repositories are skipped, so disabling or deleting a repository flags its Record as `MISSING` on the next Sync. - -## **Backstage** - -The Backstage connector is an **asset connector**: instead of importing Findings, it pulls your [Backstage](https://backstage.io) Software Catalog into DefectDojo and keeps your Asset hierarchy and team ownership in sync with it. It is designed for organizations that maintain their service inventory and org structure in Backstage and want DefectDojo to mirror that structure instead of maintaining it by hand. - -#### What gets mapped - -| Backstage | DefectDojo | -|---|---| -| **System** | Organization (Components with no System are grouped under a configurable "Backstage / Uncategorized" Organization) | -| **Component** | Asset — named from the entity `title` (falling back to `name`), with the catalog description | -| **Owning Group** (`ownedBy` relation) | A DefectDojo Group linked to the Asset (default role: Maintainer, configurable) | -| **Owner email** (Group profile email, or a User owner's email) | An Asset Member, when a DefectDojo user with that email already exists (users are never created) | -| `metadata.tags`, `spec.type`, `spec.lifecycle`, namespace, domain | Asset tags under a `backstage:` prefix | -| `metadata.annotations` | Stored on the Record (bounded); selected annotations can be promoted to first-class attributes or tags via **Annotation Mappings** | - -Records are keyed by the entity's server\-assigned `metadata.uid`, so renames in Backstage update the mapped Asset **in place** on the next sync — no duplicates. The Asset name always tracks the catalog: to rename an Asset managed by this connector, rename the Component in Backstage (a DefectDojo\-side rename, or a custom name given during manual mapping, is reconciled back to the catalog name on the next sync unless it would collide with another Asset). Ownership changes move the Asset's group assignment. Components that disappear from the catalog (or are flagged with the `backstage.io/orphan` annotation) are marked **MISSING** — DefectDojo never deletes an Asset on its own. Domain and Group hierarchy (parent teams) are recorded as tags/metadata only; they do not create extra hierarchy levels. - -#### Prerequisites - -The connector authenticates with a **static external access token** against the Backstage backend. In your Backstage app config, define a token and (recommended) restrict it to the catalog plugin: - -```yaml -backend: - auth: - externalAccess: - - type: static - options: - token: ${DEFECTDOJO_BACKSTAGE_TOKEN} - subject: defectdojo-connector - accessRestrictions: - - plugin: catalog -``` - -Generate a strong random token (for example `openssl rand -hex 32`) and store it in your Backstage deployment's environment. See the [Backstage service-to-service auth documentation](https://backstage.io/docs/auth/service-to-service-auth) for details. - -#### Connector Mappings - -1. Enter your **Backstage backend root URL** in the **Location** field: for example `https://backstage.example.com` (the connector appends `/api/catalog`). This must be the **backend** URL, not the frontend web UI. -2. Enter the static external access token in the **Secret** field. - -Optional fields (leave blank for the defaults): - -* **Namespaces** — comma\-separated catalog namespaces to import; blank imports every namespace. -* **Component Types** — comma\-separated `spec.type` values (e.g. `service,website`); blank imports every type. -* **Page Size** — catalog query page size (1\-500, default 250). -* **TLS Verification** — set to `false` only if Backstage serves a certificate DefectDojo cannot verify (internal CA); not recommended. -* **Uncategorized Organization** — the Organization used for Components with no System (default `Backstage / Uncategorized`). -* **Owner Group Role** — the role granted to the owning team on mapped Assets (default `Maintainer`). -* **Annotation Mappings** — a JSON object mapping annotation keys to Record attribute names, or to `"tag"` to import an annotation as an Asset tag, e.g. `{"github.com/project-slug": "GITHUB_PROJECT", "example.com/tier": "tag"}`. - -With **Auto\-Map** enabled, a single Discover \+ Sync builds the complete Organization / Asset / ownership structure with no manual steps. With Auto\-Map disabled, discovered Components appear as Records awaiting your mapping decision. - -#### Limitations (v1) - -* Backstage **Group membership is not synchronized**: the connector creates/links the owning team as a DefectDojo Group, but populating that group's users is left to your identity provider or admins. -* Only Components become Assets; APIs, Resources, and Domains are not imported as assets (domains surface as tags). -* Tags and annotations are normalized and bounded to fit DefectDojo field limits (oversized values are truncated). - -**A note on the reverse direction:** displaying DefectDojo findings and grades *inside* Backstage (on entity pages) is a natural follow\-on that would be built as a Backstage frontend plugin consuming the DefectDojo REST API — it is deliberately out of scope for this connector, which only pulls catalog data into DefectDojo. - -## **Beagle Security** - -The Beagle Security connector imports **DAST findings** from Beagle Security. DefectDojo creates a Record for each **verified** application in your Beagle project tree — applications that have not been verified are not imported. - -#### Prerequisites - -A Beagle Security **personal access token**, sent as a bearer token. - -**Beagle access tokens expire.** When one does, Beagle returns an HTML error page rather than a JSON error, so an expired token can present as an unclear Sync failure. If a previously working connector starts failing, check the token first. - -#### Connector Mappings - -1. Enter your Beagle API URL in the **Location** field — `https://api.beaglesecurity.com/rest/v2`. -2. Enter the personal access token in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each verified application becomes a Record, and its findings come from that application's most recently **finished** test session — so a test still in progress does not replace your existing results. - -## **BigID** - -The BigID connector imports **data security posture (DSPM) findings** — exposed sensitive data, over-permissive access, and unprotected PII stores — from BigID's actionable insights. DefectDojo creates a Record for each BigID **data source**. - -> **Your sensitive data is never copied into DefectDojo.** Findings carry only identifiers, classifications, and affected-object **counts**. No sample or preview of the underlying sensitive data is read or written into a finding — which is what makes it safe to surface DSPM results alongside your other findings. - -#### Prerequisites - -A BigID **user token**, from **Administration \> Access Management**. DefectDojo exchanges it for a short\-lived system token on each Sync; the user token is never logged. - -#### Connector Mappings - -1. Enter your BigID instance URL in the **Location** field. -2. Enter the user token in the **User Token** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each BigID data source becomes a Record, carrying the actionable-insight cases raised against it. - -## **Black Duck** - -The Black Duck connector imports **software composition analysis (SCA)** findings from a Black Duck (Synopsys / Black Duck) Hub instance. DefectDojo discovers every project in the instance and creates a Record for each **project**; the findings for a project come from the vulnerable BOM components of its selected version. - -#### Prerequisites - -A Black Duck **API token** for a user that can see the projects you want to import. In Black Duck, open your user menu \> **My Access Tokens** \> **Create New Token**, grant it (at least) read access, and copy the token when it is shown — it is displayed only once. The connector exchanges this token for a short\-lived bearer on each sync; it is never stored in cleartext beyond the connector's secret field. - -#### Connector Mappings - -1. Enter your Black Duck hub URL in the **Location** field — for example `https://your-company.app.blackduck.com`. -2. Enter the API token in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each Black Duck project becomes a Record. By default the connector imports the project's **released** version (falling back to its first version); each vulnerable BOM component of that version becomes a finding, titled `{vulnerability} in {component}:{version}`. - -This connector is distinct from the file-based Black Duck parsers — its findings use the dedicated **Black Duck - Connectors Import** scan type. - -## **Bitbucket** - -The Bitbucket connector is an **Asset Connector**: it enumerates the repositories in the Bitbucket Cloud workspaces you name and creates a DefectDojo Asset for each repository, grouped into Organizations by Bitbucket project. No findings are imported. - -#### Prerequisites - -Bitbucket Cloud requires a **scoped** Atlassian API token — classic (unscoped) Atlassian API tokens are rejected by Bitbucket with an "API Token provided has no Bitbucket scopes" error. - -1. Go to [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens) and choose **Create API token with scopes**. -2. Select the **Bitbucket** app, then grant the read scopes: `read:account:bitbucket`, `read:workspace:bitbucket`, `read:repository:bitbucket`, and `read:project:bitbucket`. - -Only Bitbucket Cloud (bitbucket.org) is supported. Bitbucket Server reached end of life in 2024, and Bitbucket Data Center is not supported. - -#### Connector Mappings - -1. Enter `https://bitbucket.org` in the **Location** field. -2. Enter the Atlassian account email the token belongs to in the **Email** field. -3. Enter the scoped API token in the **Secret** field. -4. Enter one or more workspace slugs (comma-separated) in the **Workspace Slugs** field. This field is required: Bitbucket's scoped API tokens cannot list workspaces automatically, so DefectDojo needs to be told which workspaces to read. - -Each repository becomes a Record named after the repository, grouped by its Bitbucket **project**. - -## **Black Duck Continuous Dynamic** - -The Black Duck Continuous Dynamic connector imports **DAST findings** from the Continuous Dynamic platform. DefectDojo creates a Record for each **site** on your account, with no per\-site configuration. - -**Please note:** findings from this connector use the **WhiteHat Sentinel** scan type. Continuous Dynamic was sold as WhiteHat Sentinel Dynamic before the acquisition, and DefectDojo reuses that established mapping — so this is expected, not a misconfiguration. - -#### Prerequisites - -A Continuous Dynamic **API key**, from **Account \> API Keys**. Black Duck treats this key as equivalent to a username and password, so store it accordingly. - -#### Connector Mappings - -1. Enter `https://sentinel.whitehatsec.com` in the **Location** field. -2. Enter the API key in the **API Key** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each site becomes a Record. DefectDojo requests attack vectors, risk scores and descriptions from the API so that findings arrive complete — the same detail the file\-based WhiteHat Sentinel parser expects. - -## **Bugcrowd** - -The Bugcrowd connector uses the Bugcrowd REST API to import submissions from your bug bounty and vulnerability disclosure programs. DefectDojo discovers the programs your API token can access and creates a Record for each one, importing that program's submissions as findings. - -#### Prerequisites - -You will need a Bugcrowd **API token** with access to the programs you want to import. We recommend creating a dedicated service account for DefectDojo so automated activity is easy to distinguish from manual team actions. Generate the token in Bugcrowd under **Organization settings \> API credentials**; read access to submissions, programs, and targets is sufficient. - -#### Connector Mappings - -1. Enter `https://api.bugcrowd.com` in the **Location** field. -2. Enter your Bugcrowd API token in the **Secret** field. It is sent as an `Authorization: Token` header. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each Bugcrowd **program** becomes a Record, and its submissions are imported as findings with the Bugcrowd severity preserved. Duplicate submissions are excluded, so reimport does not create repeated findings for the same issue. - -## **Bright Security** - -The Bright Security connector uses the [Bright](https://brightsec.com) (formerly NeuraLegion) API to import **DAST findings**. DefectDojo discovers every scan the token can access and creates a Record for each completed scan, then imports that scan's issues as findings. - -#### Prerequisites - -You will need a Bright **API key**, created in the Bright app under **User settings → API keys** (an `Org` or personal key). The key is sent in the `Authorization: Api-Key` header and is never logged. - -#### Connector Mappings - -1. Leave the **Location** field blank to use `https://app.brightsec.com`, or enter your Bright host explicitly. -2. Enter the Bright API key in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo maps each completed **scan** to a Record and each **issue** to a finding: the severity comes from Bright's own rating (Critical/High/Medium/Low), the CVSS score, CWE and remediation are carried over, the affected entry point becomes the endpoint, and the request/response evidence is included in the description. Findings are recorded as dynamic findings and de-duplicated on Bright's issue id. - -See the [Bright API documentation](https://docs.brightsec.com/) for more information. - -## **Burp Suite Enterprise** - -DefectDojo’s Burp connector calls Burp’s GraphQL API to fetch data. - -#### Prerequisites - -Before you can set up this connector, you will need an API key from a Burp Service Account. Burp user accounts don’t have API keys by default, so you may need to create a new user specifically for this purpose. - -See [Burp Documentation](https://portswigger.net/burp/documentation/enterprise/user-guide/api-documentation/create-api-user) for a guide on setting up a Service Account user with an API key. - -#### Connector Mappings - -1. Enter Burp’s root URL in the **Location** field: this is the URL where you access the Burp tool. -2. Enter a valid API Key in the Secret field. This is the API key associated with your Burp Service account. - -See the official [Burp documentation](https://portswigger.net/burp/extensibility/enterprise/graphql-api/index.html) for more information on the Burp API. - -## **Calico Cloud** - -The Calico Cloud connector imports **container image vulnerability findings** from Calico Cloud Image Assurance. DefectDojo creates a Record for each scanned **image repository**. - -#### Prerequisites - -An Image Assurance **API token**, from **Image Assurance \> Access Settings** in the Calico Cloud UI. This is the same token the `tigera-scanner` CLI uses, and it is never logged. - -#### Connector Mappings - -1. Enter your Image Assurance API URL in the **Location** field — the same value you would pass to `tigera-scanner` as `--apiurl`. -2. Enter the token in the **API Token** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each scanned image repository becomes a Record, carrying the CVE results of its images. - -**Images whose scan results are not ready yet are skipped, not reported as clean.** Calico's registry scanner runs asynchronously, so an image can be absent from a Sync simply because its scan is still in progress — it will appear once results exist. This is worth knowing before reading a short finding list as a coverage gap. - -## **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: ` 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. - -#### **Connector Mappings** - -1. Enter your **Tenant Name** in the **Checkmarx Tenant** field. This name should be visible on the Checkmarx One login page in the top\-right hand corner: -" Tenant: \<**your tenant name**\> " -​ -![image](images/connectors_tool_reference_2.png) - -2. Enter a valid API key. You may need to generate a new one: see [Checkmarx API Documentation](https://docs.checkmarx.com/en/34965-68618-generating-an-api-key.html#UUID-f3b6481c-47f4-6cd8-9f0d-990896e36cd6_UUID-39ccc262-c7cb-5884-52ed-e1692a635e08) for details. -3. Enter your tenant location in the **Location** field. This URL is formatted as follows: -​`https://.ast.checkmarx.net/` . Your Region can be found at the beginning of your Checkmarx URL when using the Checkmarx app. **** is the primary US server (which has no region prefix). - -#### **Branch handling** - -By default, each sync imports the findings of a project's **single most recent completed scan, regardless of branch**. If your CI scans many branches, whichever branch happened to scan last "wins" that sync: findings that only exist on other branches are not imported, and the sync's close-old reconciliation can churn findings open and closed as different branches take turns being the latest scan. - -Two optional fields control this behavior: - -- **Branch**: pins every project to one branch name — only scans of that branch are imported. This is a single global value for the whole connector, so it fits fleets where every project uses the same long-lived branch (e.g. `main`). - - A **`*` wildcard** is supported. A Branch value containing `*` selects across *every* matching branch rather than a single one — for example `release/*` imports each release branch, and `*` matches every branch. Combined with **Track Scanned Branches**, this is the way to track a family of branches without tracking all of them. - - If a wildcard matches **no** branch within the scan window, that sync is **skipped** rather than treated as "the branch has no findings" — so a pattern that temporarily matches nothing cannot close every finding on the asset. -- **Track Scanned Branches**: when enabled, each sync finds every branch with a completed scan in the project's recent scan history and imports **the latest completed scan of each branch**, one reimport per branch. Each branch's findings live in their own engagement on the mapped asset, named "\ \- \", so closing stale findings is scoped per branch: a fix merged to one branch can never close another branch's findings. The project's primary branch (as reported by Checkmarx) is imported first, so re-occurrences of the same finding on other branches deduplicate against the primary branch's original. - -Notes on **Track Scanned Branches**: - -- **Check which default applies to you.** Branch tracking is **on by default for new installations**. Installations that predate the change keep their previous behavior, so the toggle is off for them until someone turns it on. -- When both fields are set, only the pinned **Branch** is tracked — including when that Branch value is a wildcard pattern, in which case every branch matching the pattern is tracked. -- A branch that stops being scanned (merged or deleted) stops receiving updates: its engagement remains visible with its last-known findings, which you can review and close in bulk. -- Turning the toggle off later is safe: per-branch engagements simply stop receiving imports and the default engagement resumes on the next sync. -- Connectors reconcile state on the sync schedule. Branch tracking makes each sync complete across branches; it does not make data real-time between syncs. - -## **Chef Automate** - -The Chef Automate connector imports **InSpec compliance findings**. DefectDojo groups the nodes Chef Automate reports on by their **environment**, and creates a Record for each environment. - -#### Prerequisites - -A Chef Automate **API token**. It is never logged. - -#### Connector Mappings - -1. Enter your Chef Automate server URL in the **Location** field. -2. Enter the API token in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each environment becomes a Record, carrying the **failed** InSpec controls from each of its nodes' **latest** compliance runs. Passing and skipped controls are not imported, so the finding list is your outstanding compliance work rather than a full control inventory. - -## **CI Fuzz** - -The CI Fuzz connector imports **fuzzing findings** from Code Intelligence CI Fuzz. DefectDojo creates a Record for each CI Fuzz **project**. - -#### Prerequisites - -A CI Fuzz **API token**, sent as a bearer token and never logged. - -#### Connector Mappings - -1. Enter `https://app.code-intelligence.com` in the **Location** field. -2. Enter the API token in the **API Token** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each CI Fuzz project becomes a Record, carrying that project's fuzzing findings. - -## **Cloudflare** - -The Cloudflare connector imports **Security Center insights** — security posture issues Cloudflare surfaces about your account and zones, such as a missing DMARC record, DNSSEC not being enabled, or a certificate problem. DefectDojo creates a Record for each zone (domain) that has open insights, plus an account-level Record for insights that are not tied to a specific zone. - -#### Prerequisites - -You will need a Cloudflare **API token** (not the legacy Global API Key). Create one under **My Profile > API Tokens > Create Token** in the Cloudflare dashboard. The quickest option is the **"Read all resources"** template; for a least-privilege token, grant **Zone > Zone > Read** (all zones) plus account-level read access for Security Center. - -#### Connector Mappings - -1. Enter `https://api.cloudflare.com/client/v4` in the **Location** field. -2. Enter the API token in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo auto-discovers the accounts and zones the token can access — no account ID is required. Only open (active, non-dismissed) insights are imported, so insights you resolve or dismiss in Cloudflare are automatically mitigated in DefectDojo on the next sync. - -## **Cobalt.io** - -The Cobalt.io connector uses the Cobalt.io API (v2) to pull pentest findings from your Cobalt.io organization. DefectDojo discovers every organization your API token can access and creates a separate Record for each **asset** (the unit Cobalt pentests). - -#### Prerequisites - -You will need a Cobalt.io **personal API token**. We recommend creating a dedicated service account for DefectDojo to clearly distinguish automated activity from manual team actions. Generate a token from **Settings \> API Tokens** in the Cobalt.io UI. Organization tokens are discovered automatically \- you do not need to supply them. - -#### Connector Mappings - -1. Enter the Cobalt.io API base URL in the **Location** field: `https://api.cobalt.io` (or your regional host, for example `https://api.us.cobalt.io`). -2. Enter your **personal API token** in the **Secret** field. -3. Optionally, enter an **Organization Token** to pin the sync to a single organization. When left blank, DefectDojo syncs every organization the personal API token can access. - -DefectDojo maps each Cobalt.io **asset** as a separate Record. Findings are imported for each mapped asset, with their Cobalt.io state (for example `valid_fix`, `wont_fix`, `invalid`) driving the finding status in DefectDojo. - -## **Codacy** - -The Codacy connector imports **code quality and security findings** from Codacy. DefectDojo enumerates every organization your token can see and creates a Record for each **repository that carries security issues** — repositories with none are not mapped. - -#### Prerequisites - -You need a Codacy **account** API token. - -> **A repository ("project") token will not work.** Codacy's repository tokens are valid only against its older API version, and this connector uses the current one. Pasting a project token produces authentication failures that look like an invalid key. Make sure you generate an **account** token. - -#### Connector Mappings - -1. Enter `https://app.codacy.com/api/v3` in the **Location** field. -2. Enter your Codacy **account** API token in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each repository with security issues becomes a Record. Only **open** Security and Risk Management items are imported, so items you resolve in Codacy are reflected on the next Sync. - -## **Contrast** - -The Contrast connector uses the Contrast Assess REST API to import application vulnerabilities. DefectDojo discovers the applications in your Contrast organization and creates a Record for each one. - -#### Prerequisites - -You will need four values from Contrast. We recommend creating a dedicated service account so automated activity is easy to distinguish from your team's manual actions. In the Contrast UI, under **User Settings > Profile > Your Keys**, you can find: - -* Your organization **API Key**. -* Your personal **Service Key**. -* The **username** the credentials belong to (the account's login email). -* Your **Organization ID** — the UUID of the organization to import from, also shown under **Organization Settings**. - -#### Connector Mappings - -1. Enter the base URL you use to access Contrast in the **Location** field — for the hosted product this is typically `https://app.contrastsecurity.com` (or your regional / self-hosted Team Server URL). -2. Enter the account login email in the **Username** field. -3. Enter the organization **API Key** in the **API Key** field. -4. Enter the personal **Service Key** in the **Service Key** field. -5. Enter the **Organization ID** (UUID) in the **Organization ID** field. -6. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each Contrast application becomes a Record, and its vulnerabilities are imported as findings. - -## **Coverity** - -The Coverity connector imports findings from a **Coverity Connect** server. DefectDojo creates a Record for each Coverity **project**. - -#### Connector Mappings - -1. Enter your Coverity Connect server URL in the **Location** field. -2. Enter the Coverity Connect **username** in the **Username** field. -3. Enter the user's password or authentication key in the **Secret** field. -4. Optionally, set a **View Name** to select which saved issues view the connector reads. Leave blank to use the default, **Outstanding Issues**. -5. Optionally, set **Import All Issue Kinds** to `true` to widen the import beyond the default Security and Quality (`RESOURCE_LEAK`) issue filter. - -## **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. - -## **CyberArk Certificate Manager** - -The CyberArk Certificate Manager connector imports **PKI/certificate posture findings**. DefectDojo creates a Record for each certificate's **owning application** (SaaS) or **policy folder** (self\-hosted). - -**These findings are DefectDojo's own analysis, not a vendor vulnerability list.** The connector enumerates your certificates and evaluates four posture rules against each one — **expiry**, **weak key**, **SHA\-1 signature**, and **self\-signed** — then raises findings from the results. If you go looking for a matching "vulnerabilities" list inside Certificate Manager, there isn't one. - -Both editions are supported, and the connector normalizes them so the same rules apply to each: - -* **`cloud`** — Certificate Manager SaaS, formerly TLS Protect Cloud. -* **`tpp`** — Certificate Manager Self\-Hosted, formerly Trust Protection Platform. - -#### Prerequisites - -* **Cloud:** a SaaS **API key**. -* **Self-hosted:** an **OAuth client ID** registered on the server, plus a **service account username and password**. - -#### Connector Mappings - -1. Enter your Certificate Manager URL in the **Location** field — `https://api.venafi.cloud` (or your region's host) for cloud, or your Trust Protection Platform host for self\-hosted. -2. Set **Edition** to `cloud` or `tpp`. It defaults to `cloud`. -3. For the **cloud** edition, enter the SaaS API key in **API Key (cloud)** and leave the `tpp` fields blank. -4. For the **tpp** edition, enter the **Client ID (tpp)**, **Username (tpp)** and **Password (tpp)**, and leave the cloud API key blank. -5. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Because the credential fields are shared between editions, only the ones matching your chosen **Edition** are required — the others should be left empty. - -## **Cyberwatch** - -The Cyberwatch connector imports **CVEs and security (compliance) issues** from a Cyberwatch appliance — both kinds in a single Sync. DefectDojo creates a Record for each asset, or "server", the appliance knows about. - -#### Prerequisites - -A Cyberwatch **API key ID and secret key**, created in the appliance under **Profile \> API keys**. The secret is never logged. - -#### Connector Mappings - -1. Enter your Cyberwatch appliance URL in the **Location** field. -2. Enter the API key ID in the **API Key** field. -3. Enter the secret in the **Secret Key** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each asset becomes a Record, carrying both its CVEs and its compliance findings. - -## **CyCognito** - -The CyCognito connector imports **external attack surface (EASM) findings** from the CyCognito platform. By default DefectDojo creates a Record for each **discovered asset**, across every asset type CyCognito tracks — IPs, domains, certificates, web apps and IP ranges. - -There is deliberately no per\-asset configuration: the point of an EASM source is that it finds assets nobody enumerated in advance, so newly discovered assets appear as Records without anyone editing a configuration. - -#### Prerequisites - -A CyCognito **API key**, created under **Settings \> API** in CyCognito. It is sent as the value of the `Authorization` header. - -#### Connector Mappings - -1. Enter `https://api.platform.cycognito.com` in the **Location** field. -2. Enter your CyCognito API key in the **API Key** field. -3. Optionally, set **Asset Grouping** to `organization` to create one Record per CyCognito **organization** instead of one per asset. Leave it blank for the default, one Record per asset. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Under **organization** grouping, assets that belong to no organization are collected into a Record named **Unattributed Assets**. - -## **Datadog** - -The Datadog connector imports **Cloud Security findings** — misconfigurations, identity risks and vulnerabilities — from the Datadog security findings API. DefectDojo creates a Record for each **cloud account** the findings belong to, so no per\-resource configuration is needed. - -#### Prerequisites - -You will need two credentials from Datadog: - -* An **API key**, from **Organization Settings \> API Keys**. -* An **application key**, from **Organization Settings \> Application Keys**, which must carry the **`security_monitoring_findings_read`** scope. - -Neither key is ever logged by DefectDojo. - -#### Connector Mappings - -1. Enter your organization's Datadog **site** in the **Location** field — for example `https://api.datadoghq.com`. Organizations on the EU, US3, US5 or AP1 sites must use their own site hostname. -2. Enter the API key in the **API Key** field. -3. Enter the application key in the **Application Key** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each cloud account that has findings becomes a Record. DefectDojo respects Datadog's rate limits, backing off and retrying rather than failing the Sync. - -## **Deepfence ThreatMapper** - -The Deepfence ThreatMapper connector uses the [ThreatMapper](https://github.com/deepfence/ThreatMapper) management-console REST API to import **vulnerability scan** results. DefectDojo discovers every node ThreatMapper has scanned — a container image, host, or container — and creates a Record for each, then imports that node's most recent completed scan as findings. - -#### Prerequisites - -You will need a ThreatMapper **API token**, found in the console under **Settings → User Management** (your user's API key). The connector exchanges it for a short-lived access token on each sync; the API token is never logged. - -#### Connector Mappings - -1. Enter your ThreatMapper console URL in the **Location** field (for example `https://threatmapper.example.com`). -2. In the **Secret** field, enter the ThreatMapper API token. -3. If your console uses a self-signed certificate, set **Skip TLS Verification** to `true`. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo maps each scanned **node** to a Record and each **CVE** in its latest completed vulnerability scan to a finding. The severity comes from ThreatMapper's own rating, and the affected package, CVSS score, fix version (as mitigation), reference links, and a details block are carried over. Findings are recorded as dynamic findings and de-duplicated on the node, CVE, package and package path. - -See the [ThreatMapper documentation](https://community.deepfence.io/threatmapper/docs/v2.5/) for more information. - -## **DeepSource** - -The DeepSource connector imports **static analysis findings** from DeepSource. DefectDojo enumerates every account your token can see and creates a Record for each **activated** repository. - -#### Prerequisites - -A DeepSource **personal access token**, sent as a bearer token. - -#### Connector Mappings - -1. Enter your DeepSource GraphQL API URL in the **Location** field — `https://api.deepsource.com/graphql/` for the cloud platform, or your own host's GraphQL path if self\-hosted. -2. Enter the personal access token in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each activated repository becomes a Record. DeepSource reports the currently-open set of issue occurrences rather than a per\-finding status, so each Sync reflects what is open at that moment. - -## **Dependency\-Track** - -This connector fetches data from a on\-premise Dependency\-Track instance, via REST API. - -​**Connector Mappings** - -1. Enter your local Dependency\-Track server URL in the **Location** field. -2. Enter a valid API key in the **Secret** field. - -To generate a Dependency\-Track API key: - -1. **Access Management**: Navigate to Administration \> Access Management \> Teams in the Dependency\-Track interface. -2. **Teams Setup**: You can either create a new team or select an existing one. Teams allow you to manage API access based on group membership. -3. **Generate API Key**: In the selected team's details page, find the "API Keys" section. Click the \+ button to generate a new API key. -4. **Assign Permissions**: In the "Permissions" section of the team's page, click the \+ button to open the permissions selector. Choose **VIEW\_PORTFOLIO** and **VIEW\_VULNERABILITY** permissions to enable API access to project portfolios and vulnerability details. -5. Click "**Select**" to confirm and save these permissions. - -For more information, see **[Dependency\-Track Documentation](https://docs.dependencytrack.org/integrations/rest-api/)**. - -## **Detectify** - -The Detectify connector imports **vulnerability findings** covering Application Scanning, Surface Monitoring and API Scanning in one connector. DefectDojo creates a Record for each **asset** in your account. - -#### Prerequisites - -A Detectify **API key**, from **Team settings \> API keys**. It is sent as the `X-Detectify-Key` header and never logged. - -Optionally, you can also supply the **base64 secret** paired with that key to have DefectDojo HMAC\-sign its requests. This is a **Professional plan** feature; without it, DefectDojo uses key\-only authentication, which works on all plans. - -#### Connector Mappings - -1. Enter `https://api.detectify.com/rest` in the **Location** field. -2. Enter your Detectify API key in the **API Key** field. -3. Optionally, enter the base64 secret in the **API Secret** field to enable request signing. Leave it blank for key\-only authentication. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each asset becomes a Record, carrying its vulnerabilities from all three Detectify scanning products. - -## **Docker Scout** - -The Docker Scout connector uses the Docker Scout metrics exporter API to report the vulnerability posture of your organization's images. DefectDojo discovers each Docker Scout stream (your runtime environments) and imports a summary of the vulnerabilities and policy compliance for each. - -#### Prerequisites - -You will need a Docker personal access token created by an **owner** of a Docker organization that is **enrolled in Docker Scout**. The metrics exporter is an organization-level feature, so a personal account, or an organization that is not enrolled in Docker Scout, will not return data. - -Create the token from your Docker account settings under **Personal access tokens**, and note your Docker **organization namespace**, which you will also need. - -#### Connector Mappings - -1. Enter `https://api.scout.docker.com` in the **Location** field. -2. Enter your Docker personal access token in the **Secret** field. -3. Enter your Docker **Organization** namespace. -4. 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 Docker Scout stream, and imports one finding per severity for the vulnerabilities Docker Scout counts in that stream, plus a finding for each image that fails your Docker Scout policy. Docker Scout's metrics API reports aggregate counts rather than individual CVEs, so these findings summarize the posture of a stream. Open the stream in Docker Scout for per-image and per-CVE detail. - -See the [Docker Scout documentation](https://docs.docker.com/scout/) for more information. - -## **Dragos** - -The Dragos connector imports **OT/ICS vulnerability findings** from a Dragos SiteStore deployment. DefectDojo creates a Record for each **OT zone** — one SiteStore deployment represents one site, so the zone is the meaningful grouping within it. - -#### Prerequisites - -A Dragos **API key ID and secret**, created under **Admin \> Users \> Add New API Key**. The key needs these read privileges: - -* `asset:read` -* `detection:read` -* `vulnerability:read` - -The secret is shown only once when the key is generated, so capture it then. It is never logged. - -#### Connector Mappings - -1. Enter your Dragos **SiteStore** host in the **Location** field. -2. Enter the API key ID in the **API Key ID** field. -3. Enter the secret in the **API Key Secret** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each OT zone becomes a Record, carrying the vulnerabilities detected on the assets in that zone. - -## **Elastic Security** - -The Elastic Security connector imports **cloud vulnerability, posture and detection findings** from an Elasticsearch cluster, as three separate finding types. DefectDojo creates a Record for each **cloud account**. - -Not every Elastic finding carries a cloud account, so DefectDojo falls back in order: the **Kubernetes cluster** (for KSPM findings with no cloud account), then the **host**. Anything identifying none of those lands in a single catch\-all Record rather than being dropped. - -#### Prerequisites - -An Elasticsearch **API key**, supplied as the base64 `id:api_key` value. - -**Prefer an API key over a username and password**, because a key can be scoped read\-only to just the security indices. A username and password are supported as a fallback for clusters that do not have API keys enabled. - -#### Connector Mappings - -1. Enter your Elasticsearch cluster URL in the **Location** field. -2. Enter the base64 API key in the **API Key** field. Leave it blank if you are using a username and password instead. -3. If you are not using an API key, enter the **Username** and password for HTTP Basic authentication. These are only used when no API key is supplied. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -## **Endor Labs** - -The Endor Labs connector uses the Endor Labs REST API to sync an entire Endor Labs **namespace**. DefectDojo discovers each Endor **project** as a Record and imports that project's findings, carrying Endor's **reachability** verdict so you can prioritize vulnerabilities whose affected code is actually reachable. - -#### Prerequisites - -You will need an Endor Labs **API key** (a key identifier plus its secret) and the **namespace** you want to sync. Create the key in the Endor Labs platform under **Settings \> Access \> API Keys**; the key needs read access to the projects and findings in that namespace. - -The connector authenticates by exchanging the API key and secret for a short-lived bearer token — the secret is used only for that exchange and is never stored in cleartext. - -#### Connector Mappings - -1. Enter `https://api.endorlabs.com` in the **Location** field. If your tenant is hosted in a different region, use that region's API base URL instead. -2. Enter the Endor Labs **Namespace** to sync (for example `your-org` or `your-org.team`). -3. Enter the **API Key** identifier. -4. Enter the **API Secret** paired with the key. -5. Optionally set **Traverse Child Namespaces** to `true` to also import findings from child namespaces of the configured namespace. -6. Optionally set a **Minimum Severity** to limit which findings are imported. Findings below the selected severity are not imported. - -DefectDojo creates a Record for each Endor Labs project in the namespace and imports its findings, mapping Endor severity levels to DefectDojo severities, the CVE/GHSA identifiers and CVSS score of each vulnerability, and Endor's reachability tags. The reachability verdict (for example *Reachable — vulnerable function is called* or *Unreachable*) is surfaced as the finding's Impact and as a tag. - -For more information, see the **[Endor Labs REST API documentation](https://docs.endorlabs.com/rest-api/)**. - -## **Edgescan** - -The Edgescan connector uses the Edgescan REST API to import open vulnerabilities across your whole Edgescan account. DefectDojo enumerates every Edgescan **asset** and creates a Record for each one, then imports that asset's open vulnerabilities as findings — there is no per\-asset configuration. - -#### Prerequisites - -You will need an Edgescan API token. Create one from your Edgescan account under **Account settings \> API tokens**: enter a label, click **Create**, and copy the generated token (it is shown only once). We recommend a dedicated account for the Connector so automated activity is easy to distinguish. - -#### Connector Mappings - -1. Enter your Edgescan URL in the **Location** field — `https://live.edgescan.com` for the standard hosted platform, or your tenant's host if different. -2. Enter your Edgescan API token in the **Secret** field. It is sent as the `X-API-TOKEN` header. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each Edgescan asset becomes a Record, and each open vulnerability on that asset is imported as a finding. Severity is mapped from Edgescan's numeric scale (1–5) to DefectDojo's Info–Critical, and CVE references, the CWE, and a CVSS v3 vector are included where Edgescan provides them. - -## **Escape** - -The Escape connector uses the [Escape](https://escape.tech) API to import **API\-security (DAST) findings**. DefectDojo enumerates every organization the token can access and every application within each, creates a Record for each application that has a scan, and imports that application's latest scan issues as findings — there is no per\-application configuration. - -#### Prerequisites - -You will need an Escape **API key**, created in the Escape app under **Settings → API keys**. The key is sent in the `Authorization: Key` header and is never logged. - -#### Connector Mappings - -1. Leave the **Location** field blank to use `https://public.escape.tech/v2`, or enter your Escape API host explicitly. -2. Enter the Escape API key in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo maps each **application** to a Record and each scan **issue** to a finding: the severity comes from Escape's rating (Critical/High/Medium/Low), the CWE is carried over, the OWASP category and HTTP method become tags, the affected URL becomes the endpoint, and the remediation guidance is included. Findings are recorded as dynamic findings and de\-duplicated on Escape's issue id. - -See the [Escape API documentation](https://docs.escape.tech/) for more information. - -## **Fairwinds Insights** - -The Fairwinds Insights connector uses the [Fairwinds Insights](https://insights.fairwinds.com) REST API to import **Kubernetes security findings** across your whole organization. DefectDojo enumerates every active **cluster** and creates a Record for each one, then imports that cluster's Security **action items** \(from Polaris, Trivy, Kube\-bench, OPA and the other Insights reports\) as findings — there is no per\-cluster configuration. - -#### Prerequisites - -You will need a Fairwinds Insights **organization** name and an **API token**. Create the token in the Insights app under **Organization Settings \> Tokens**; a `read_only` token is sufficient. The token is org\-scoped and is sent as a bearer token; it is never logged. - -#### Connector Mappings - -1. Leave the **Location** field blank to use `https://insights.fairwinds.com`, or enter your Insights host explicitly. -2. Enter your Insights **Organization** name (the slug shown in your dashboard URL). -3. Enter the Insights API token in the **Secret** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo maps each active **cluster** to a Record and each Security **action item** to a finding: severity comes from Fairwinds' numeric score \(mapped to DefectDojo's Info–Critical\), the Fairwinds report that produced the item \(`polaris`, `trivy`, `kube-bench`, ...\) becomes a tool tag, the affected Kubernetes resource and container image are included, and any CVE identifiers are extracted. Findings are recorded as static findings and de\-duplicated on the Fairwinds action\-item id. - -See the [Fairwinds Insights API documentation](https://insights.docs.fairwinds.com/technical-details/api/) for more information. - -## **Finite State** - -The Finite State connector imports **firmware and embedded-device findings** from Finite State. DefectDojo creates a Record for each **Asset**, which in Finite State is a **product line** rather than an individual firmware build. - -This matters for how your data is organized: a product line's findings are the union of its builds' findings, with the build recorded on each finding as a tag and in the description. One Record therefore accumulates the history of a firmware line, instead of fragmenting into a separate Record per release. - -#### Prerequisites - -A Finite State **API token**. It is sent in the `X-Authorization` header — not `Authorization` — which the connector handles for you. - -#### Connector Mappings - -1. Enter your Finite State subdomain in the **Location** field — for example `https://acme.finitestate.io`. DefectDojo appends the API path itself. -2. Enter the API token in the **API Token** field. -3. Optionally, set **Import Every Firmware Build** to `true` to import findings from **every** build of each asset. Leave it blank to import only the **newest** build, which is what most teams want. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Merged duplicates and deleted findings are excluded automatically, so they never reach DefectDojo. - -## **Fleet** - -The Fleet connector imports **software vulnerabilities** and **failing compliance policies** from Fleet, as two separate finding types. DefectDojo creates a Record for each Fleet **team**. - -Hosts that belong to no team still carry real vulnerabilities, so they are mapped to a synthetic **"No team"** Record rather than being dropped. - -> **Teams are a Fleet Premium feature.** On a free Fleet deployment the team list is unavailable, so **every host** lands in the single synthetic Record. That is expected, not a mapping failure. - -#### Prerequisites - -A Fleet **API token**, from **Account Settings \> Get API token**. The connector needs **read access only** — on Fleet Premium you can issue a scoped API\-only user for it. - -#### Connector Mappings - -1. Enter your Fleet server URL in the **Location** field. -2. Enter the API token in the **API Token** field. -3. Optionally, enable **Skip software vulnerabilities** to leave out CVEs found on installed software. Leave it off to import them. -4. Optionally, enable **Skip compliance policies** to leave out failing osquery policy checks. Leave it off to import them under their own scan type. -5. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Both imports are on by default — the two toggles exist to turn each off if you only want one kind of finding in DefectDojo. - -## **Fortify** - -The Fortify connector imports SAST/DAST results from Fortify (OpenText/Micro Focus), covering both editions that share the platform: **SSC** (Software Security Center, self-hosted) and **Fortify on Demand (FoD)** (SaaS). It syncs the whole account: DefectDojo discovers every application (SSC project version / FoD release) and creates a Record for each, then imports that application's issues as findings. - -#### Prerequisites - -- **SSC**: a **FortifyToken** — create one in the SSC UI under **Administration → Token Management** (a CIToken/UnifiedLoginToken). -- **FoD**: an **OAuth2 API key** — a Client ID and Client Secret from **Settings → API** (with the `api-tenant` scope). - -The token and OAuth secret are never logged. - -#### Connector Mappings - -1. Enter the Fortify base URL in the **Location** field: for SSC your server host (the connector adds `/ssc/api/v1`); for FoD the API host for your region, e.g. `https://api.ams.fortify.com`. -2. Set **Edition** to `SSC` or `FoD`. -3. For **FoD**, enter the OAuth **Client ID**; leave it blank for SSC. -4. In **Token / Client Secret**, enter the SSC FortifyToken or the FoD OAuth client secret. -5. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo maps each Fortify **application** to a Record and each **issue** to a finding: the severity comes from Fortify's own **friority** rating (Critical/High/Medium/Low), the title combines the issue category with its file and line, and the file path, line, kingdom, analyzer and engine type are carried over. Issues from static-analysis engines (SCA) are recorded as static findings and WebInspect (DAST) issues as dynamic findings; suppressed, removed and hidden issues are skipped, issues audited "Not an Issue" are marked false positive, and "Exploitable"/reviewed issues are marked verified. - -See the [Fortify SSC](https://www.microfocus.com/documentation/fortify-software-security-center/) and [Fortify on Demand](https://api.ams.fortify.com/swagger/ui) API documentation for more information. - -## **FOSSA** - -The FOSSA connector imports both **security vulnerabilities** and **license-policy violations** from FOSSA. DefectDojo creates a Record for each FOSSA **project**. - -#### Prerequisites - -A FOSSA **Full** API token. - -> **A Push-Only token will not work.** FOSSA's Push-Only tokens cannot read the APIs this connector uses, so the Sync fails to retrieve anything. This is the most common misconfiguration for this connector — make sure the token is a **Full** token. - -#### Connector Mappings - -1. Enter `https://app.fossa.com/api` in the **Location** field. -2. Enter your FOSSA Full API token in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each FOSSA project becomes a Record. Only your organization's **active** issues are imported, covering both vulnerability and license-policy findings — so this connector can drive licence compliance work as well as security remediation. - -## **GitGuardian** - -The GitGuardian connector uses the GitGuardian REST API to import **secret incidents** — exposed credentials GitGuardian has detected across your monitored sources. DefectDojo creates a Record for each monitored source (repository or perimeter) that currently has open incidents, and imports each open incident as a finding. - -For your security, the connector imports only incident **metadata** — the detector, severity, validity, status, and a link back to GitGuardian. The exposed secret value itself is never retrieved or stored by DefectDojo; follow the link in each finding to review the affected locations in GitGuardian. - -#### Prerequisites - -You will need a GitGuardian API key. We recommend a **Service Account token** (rather than a personal access token) so automated activity is easy to distinguish. Create it under **API** in the GitGuardian dashboard and grant these read scopes: - -* `incidents:read` -* `sources:read` - -#### Connector Mappings - -1. Enter your GitGuardian API URL in the **Location** field: `https://api.gitguardian.com` for the SaaS platform, or your self-hosted instance's API URL. -2. Enter the API key in the **Secret** field. - -Only **open** incidents (status `TRIGGERED` or `ASSIGNED`) are imported; incidents you resolve or ignore in GitGuardian are automatically mitigated in DefectDojo on the next sync. A confirmed-live secret (validity *valid*) is imported as a verified finding. - -## **GitHub** - -The GitHub connector is an **Asset Connector**: it enumerates the repositories your token can access and creates a DefectDojo Asset for each one, grouped into Organizations by GitHub owner (organization or user). No findings are imported. - -**Please note:** this connector imports your repository **inventory** only. To import GitHub security alerts — code scanning, Dependabot, and secret scanning — as findings, use the separate **GitHub Advanced Security** connector below. The two are independent and can be run together. - -#### Prerequisites - -The connector authenticates with a GitHub **personal access token** and reads only repository **metadata** (name, description, URL, and owner) — it does not access your code, issues, or security alerts. It imports every repository the token's account owns, collaborates on, or is an organization member of, so confirm the token's account can see the repositories you want to mirror. We recommend a dedicated service account. - -The token only needs read-only access to repository metadata: - -- A *fine-grained* token needs **Repository permissions → Metadata: Read-only**, granted to the repositories (or the whole organization) you want to import. -- A *classic* token needs the **`repo`** scope to include private repositories (use **`public_repo`** if you only need public ones), plus **`read:org`** so organization-owned repositories resolve. - -Only GitHub.com (including GitHub Enterprise Cloud) is supported. GitHub Enterprise **Server** is not supported by this connector at this time. - -#### Connector Mappings - -1. Enter `https://api.github.com` in the **Location** field. -2. Enter the personal access token in the **Secret** field. - -No organization or repository list needs to be entered — DefectDojo imports every repository the token can see. Each repository becomes a Record named after the repository, grouped by its GitHub **owner** (organization or user). If a repository is later deleted, or the token loses access to it, its mapped Record is flagged `MISSING` on the next Sync rather than removed — DefectDojo never silently deletes an Asset. - -## **GitHub Advanced Security** - -The GitHub Advanced Security connector imports **code scanning**, **Dependabot**, and **secret scanning** alerts from GitHub, as three separate finding types (`GitHub:CodeScanning`, `GitHub:Dependabot`, and `GitHub:SecretScanning`). DefectDojo discovers every non\-archived repository in the configured organization and creates a Record for each one. - -#### Prerequisites - -GitHub Advanced Security features must be enabled for the repositories you want to import. The connector authenticates with a GitHub **personal access token**: - -1. In GitHub, open **Settings \> Developer settings \> Personal access tokens** and create a token owned by (or with access to) the target organization. -2. Grant it read access to the security alerts: a *fine\-grained* token needs **Read\-only** access to **Code scanning alerts**, **Dependabot alerts**, and **Secret scanning alerts** on the organization's repositories; a *classic* token needs the **`repo`** and **`security_events`** scopes. -3. Confirm the token's owner can see the repositories you intend to import — the connector only sees repositories the token can access. - -#### Connector Mappings - -1. Enter `https://api.github.com` in the **Location** field. For GitHub Enterprise Server, use `https:///api/v3`. -2. Enter the organization login in the **Organization** field. -3. Enter the personal access token in the **Secret** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each non\-archived repository becomes a Record, queried across the three alert families for open alerts. An alert family that is not enabled for a repository is skipped rather than reported as resolved, so disabled features do not cause false closures. - -## **GitLab** - -The GitLab connector is an **Asset Connector**: it enumerates every project (repository) your token can access and creates a DefectDojo Asset for each one, grouped into Organizations by GitLab namespace (group or user). No findings are imported. - -#### Prerequisites - -You will need a Personal Access Token with the **read_api** scope. We recommend creating the token from a dedicated service account; the connector lists the projects that account is a member of. - -#### Connector Mappings - -1. Enter your GitLab URL in the **Location** field: `https://gitlab.com`, or the base URL of your self-hosted instance. -2. Enter the Personal Access Token in the **Secret** field. - -Each project becomes a Record named after the project, grouped by its **namespace**. Projects that are pending deletion in GitLab (deleted by a user, but not yet purged by GitLab's background job) are excluded automatically, so deleting a project flags its Record as `MISSING` on the next Sync instead of leaving behind a renamed ghost asset. - -## **Google Artifact Analysis** - -The Google Artifact Analysis connector imports **container image vulnerability findings** from Google Cloud. DefectDojo creates a Record for each **active** GCP project the service account can list — no per\-image or per\-repository configuration is needed. - -#### Prerequisites - -A Google **service account** with the **Container Analysis Occurrences Viewer** role, and a **JSON key** for it. Neither the key nor the token derived from it is ever logged. - -#### Connector Mappings - -1. Leave the **Location** field at the default unless you use a non\-standard endpoint. -2. Paste the **entire contents** of the service account JSON key file into the **Service Account Key** field. -3. Optionally, set **Parent** to narrow the sync to `organizations/{id}`, `folders/{id}` or `projects/{id}`. Leave it blank to sync every project the service account can list. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each active GCP project becomes a Record, carrying the vulnerability occurrences Artifact Analysis has recorded against its images. - -## **Google Cloud SCC** - -The Google Cloud SCC connector uses the Security Command Center v2 REST API to import active security findings from your Google Cloud organization, folder, or project. DefectDojo creates a Record for each Google Cloud **project** that has open findings. - -#### Prerequisites - -Security Command Center must be **activated** on your organization (the Standard tier is free). You will then need a service account that can list findings, and a JSON key for it: - -1. In Google Cloud, create a service account — a dedicated one for DefectDojo is recommended. -2. Grant it the **Security Center Findings Viewer** role (`roles/securitycenter.findingsViewer`) at the scope you want to import (organization, folder, or project). -3. Create a **JSON key** for the service account and download it. - -#### Connector Mappings - -1. Leave the **Location** field at the default `https://securitycenter.googleapis.com` unless you use a non-standard endpoint. -2. In the **Parent Resource** field, enter the scope to import from: `organizations/{id}`, `folders/{id}`, or `projects/{id}`. -3. Paste the full contents of the service-account **JSON key** file into the **Service Account Key** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Only `ACTIVE`, un-muted findings are imported, so findings you deactivate or mute in SCC are automatically mitigated in DefectDojo on the next sync. Each finding's affected GCP project becomes its Record. - -## **Group-IB ASM** - -The Group-IB ASM (Attack Surface Management) connector uses the Group-IB ASM REST API to pull external attack-surface **issues** (findings) into DefectDojo. DefectDojo discovers each Group-IB **company/tenant** as a separate Record and imports that company's issues on a scheduled, incremental basis. The asset each issue relates to (a domain, IP, or URL) is attached to the resulting finding as an **Endpoint**. - -#### Prerequisites - -You will need your Group-IB ASM login and an API key. We recommend creating a dedicated service account for DefectDojo so that automated activity can be distinguished from manual team actions. - -To generate an API key: - -1. Open Group-IB Attack Surface Management, click **Help** in the lower-left corner, and select **API**. -2. Click **Generate API Key** (top-right, under your username). -3. Enter your SSO password and click **Next**, then click **Copy token**. -4. Store the key in a secret manager and plan for regular rotation. - -#### Connector Mappings - -Group-IB ASM authenticates with HTTP Basic Auth, where the username is your ASM login and the password is your API key. **Both values are required** — the API key alone is not sufficient. - -1. Enter `https://asm.group-ib.com` in the **Location** field. This is the same for all Group-IB ASM tenants. -2. Enter your ASM login (usually an email address) in the **Username** field. -3. Enter your API key in the **API Key** (Secret) field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. Findings below the selected severity are not imported. - -DefectDojo maps each Group-IB **company** as a separate Record, using the company ID as the identifier. On the first Sync, DefectDojo backfills recent issue history; subsequent Syncs are incremental, pulling only issues changed since the last Sync (tracked by each issue's most recent `lastSeen` timestamp). - -#### Scoping to a single company (optional) - -By default, the connector automatically discovers the companies available to your API credentials (via the ASM `clients` endpoint) and creates one Record per company. This is the recommended setup and requires no extra configuration. - -If the `clients` endpoint is not available for your tenant — for example, when it is restricted to partner/MSP accounts — the connector can be scoped to one company by supplying its **company ID** as a `company_id` tool-specific field on the connector configuration. When `company_id` is set, DefectDojo uses that company directly instead of enumerating companies. Leave it unset to use automatic discovery. - -See the Group-IB ASM REST API manual (available in-product via **Help → API**) for more information. - -## **HackerOne** - -The HackerOne connector uses the HackerOne REST API to import reports from your bug bounty or vulnerability disclosure program. DefectDojo creates a Record for each program the token can access and imports its reports as findings. - -#### Prerequisites - -The connector uses HackerOne's **customer** API, which requires an **organization API token** — a personal token from your user settings only works against the hacker API and will not authenticate here. - -1. In HackerOne, go to **Organization Settings > API Tokens**. -2. Create a token and note both the **identifier** and the **token** value. Read access to the program is sufficient. - -#### Connector Mappings - -1. Enter `https://api.hackerone.com` in the **Location** field. -2. Enter the token **identifier** in the **API Token Identifier** field. -3. Enter the token value in the **API Token** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each program becomes a Record, and its reports are imported as findings with the HackerOne severity rating preserved. - -## **Halo Security** - -The Halo Security connector imports **attack surface findings** from Halo Security. DefectDojo creates a Record for each **monitored target**. - -#### Prerequisites - -A Halo Security **API key**. This connector uses a single key — there is no secret, key pair, or OAuth flow to configure. - -#### Connector Mappings - -1. Enter `https://api.halosecurity.com/api/v1` in the **Location** field. -2. Enter your Halo Security API key in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each monitored target becomes a Record, carrying the account's **active** issues that affect it, enriched from Halo's issue catalogue. - -A finding's identity combines the issue **and** the target it was found on. Halo's issue IDs are catalogue identifiers shared across targets, so the same issue affecting two targets is correctly tracked as two findings rather than collapsing into one. - -## **Harbor** - -The Harbor connector uses the Harbor v2.0 REST API to import container image vulnerabilities across your whole registry. DefectDojo enumerates every Harbor **project** and creates a Record for each one, then walks the project's repositories and artifacts and imports the vulnerabilities from each **scanned** artifact — carrying the image (repository + tag/digest) as finding context. There is no per\-image configuration. - -#### Prerequisites - -You will need a Harbor account (or a **robot account**) with pull/read access to the projects you want to import. We recommend a dedicated robot account: in Harbor, open a project (or **Administration \> Robot Accounts** for a system robot), create a robot with the **pull** permission on repositories and artifacts, and copy its full name and secret. Robot names start with `robot$` by default, but the prefix is configurable per Harbor instance (some use `robot_`) — copy the name exactly as Harbor displays it. A regular username/password also works. - -#### Connector Mappings - -1. Enter your Harbor URL in the **Location** field — for example `https://harbor.example.com`. DefectDojo appends the `/api/v2.0` API path automatically. -2. Enter the Harbor username, or a robot account name exactly as Harbor shows it (`robot$` by default), in the **Username** field. -3. Enter the password or robot account secret in the **Secret** field. It is sent using HTTP Basic authentication. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each Harbor project becomes a Record. For every artifact that has a completed scan, its vulnerabilities are imported as findings; the affected package/version, a CVSS\-derived severity, the CVE, the CWE, and a remediation (fixed version) are included where Harbor provides them. Only scanned artifacts are imported — trigger a scan in Harbor for images that have not been scanned yet. - -## **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. - -## **HCL AppScan** - -The HCL AppScan connector uses the AppScan v4 REST API to import issues from **AppScan on Cloud (ASoC)** or a self-hosted **AppScan 360°** (both share the API). It syncs the whole account: DefectDojo discovers every application and creates a Record for each, then imports that application's issues (DAST, SAST and IAST) as findings. - -#### Prerequisites - -You will need an AppScan **API key** — a Key ID and Key Secret generated under your AppScan account settings (API Key). The connector exchanges them for a short-lived session token on each run; the Key ID, Key Secret and token are never logged. - -#### Connector Mappings - -1. Enter the AppScan console URL in the **Location** field: for ASoC use `https://cloud.appscan.com` (or `https://eu.cloud.appscan.com` for the EU region); for AppScan 360° use your instance host. -2. Set **Provider** to `ASOC` for AppScan on Cloud, or `A360` for a self-hosted AppScan 360°. -3. Enter the **API Key ID** and **API Key Secret**. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo maps each AppScan **application** to a Record (VEP) and each **issue** to a finding: the title is the issue type with its domain / entity / cause-id / URL / path appended; the severity maps Informational → Info (Low/Medium/High/Critical pass through); the CWE, a labeled description, the remediation and advisory, and the host/port endpoint are carried over. Issues from static analysis are recorded as static findings and dynamic/interactive issues as dynamic findings; open issues are active and fixed/passed issues are mitigated. - -See the [AppScan REST API documentation](https://help.hcl-software.com/appscan/ASoC/appseccloud_rest_apis.html) for more information. - -## **HiddenLayer** - -The HiddenLayer connector imports **AI/ML model scan findings** from HiddenLayer's Model Scanner. DefectDojo creates a Record for each **scanned model**. - -#### Prerequisites - -A HiddenLayer API **client ID and client secret**, created under **Model Scanner \> API Access**. DefectDojo exchanges them for a short\-lived bearer token on each Sync; the secret is never logged. - -#### Connector Mappings - -1. Enter your tenant's regional API URL in the **Location** field — `https://api.us.hiddenlayer.ai` or `https://api.eu.hiddenlayer.ai`. -2. Enter the client ID in the **Client ID** field. -3. Enter the client secret in the **Client Secret** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -HiddenLayer returns model scan results as **SARIF** logs, and DefectDojo maps them the same way it maps an uploaded SARIF report — so these findings behave like SARIF imports elsewhere in the Asset. - -## **Holm Security** - -The Holm Security connector imports findings across **both** of Holm's asset classes — network/infrastructure scanning and web application scanning — through one connector. DefectDojo creates a Record for each **asset**. - -#### Prerequisites - -A Holm Security **API token**, from **Security Center \> API**. It is never logged. - -#### Connector Mappings - -1. Enter your **region's** API host in the **Location** field — for example `https://se-api.holmsecurity.com` for the Swedish region. Holm Security's API host is region\-specific, so this must match the region your account is in. -2. Enter the API token in the **API Token** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each asset becomes a Record, whether it was found by a network scan or a web scan. - -## **ImmuniWeb** - -The ImmuniWeb connector imports **web application security findings** from ImmuniWeb. DefectDojo creates a Record for each **tested asset** (website) on the account. - -#### Prerequisites - -An ImmuniWeb **premium API key**. - -> **A premium key is required, even though ImmuniWeb treats its API key as optional.** Without one, ImmuniWeb **truncates the vulnerability list** it returns. DefectDojo requires the key rather than importing a silently incomplete set of findings — an import that under\-reports is worse than one that will not start. - -#### Connector Mappings - -1. Enter your ImmuniWeb API URL in the **Location** field. -2. Enter your premium API key in the **API Key** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each tested asset becomes a Record, carrying that asset's detected vulnerabilities. - -## **InsightCloudSec** - -The InsightCloudSec connector imports **cloud security posture findings** from Rapid7 InsightCloudSec. DefectDojo creates a Record for each **onboarded cloud account**. - -**Please note:** InsightCloudSec (formerly DivvyCloud) is a **distinct Rapid7 product** from InsightVM and InsightAppSec, each of which has its own connector in this list. Make sure you are configuring the one that matches your Asset. - -#### Prerequisites - -An InsightCloudSec **API key**, from the **API Keys** page in your user profile. It is never logged. - -#### Connector Mappings - -1. Enter `https://cloudsec.insight.rapid7.com` in the **Location** field. Self\-hosted InsightCloudSec deployments use their own host. -2. Enter the API key in the **API Key** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -One finding is created per **insight and failing resource** pair, so a single policy failing across many resources produces a finding for each — grouped under the cloud account the resource belongs to. - -## **Intigriti** - -The Intigriti connector uses the Intigriti external company API to pull bug-bounty / pentest **submissions** into DefectDojo. It syncs the whole company account: DefectDojo discovers every program the token can access and creates a Record for each, then imports that program's submissions as findings. - -#### Prerequisites - -You will need an Intigriti **company API token**. In the Intigriti company portal, under **Company Settings > API** (the `company_external_api` scope), generate an access token with read access to your programs and submissions. A dedicated token for DefectDojo is recommended. The token is sent as a Bearer token and is never logged. - -#### Connector Mappings - -1. Enter the Intigriti external company API base URL in the **Location** field: `https://api.intigriti.com/external/company`. The URL must be HTTPS. -2. Enter the company API token in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo maps each Intigriti **program** to a Record and each **submission** to a finding, keyed by the submission code. The finding severity follows Intigriti's rating (Exceptional/Critical → Critical, then High/Medium/Low, otherwise Informational), and the submission's lifecycle state maps to the finding's status: open/triage submissions are active, accepted submissions are verified, and closed submissions become mitigated, a duplicate, out-of-scope, false-positive or risk-accepted according to their close reason. The finding description carries the report's vulnerability type, affected asset, proof of concept and the researcher's answers. - -See the [Intigriti API documentation](https://kb.intigriti.com/en/articles/6117846-intigriti-api) for more information. - -## **Intruder** - -The Intruder connector uses the [Intruder REST API](https://developers.intruder.io/) to pull your whole account's posture into DefectDojo. Each Intruder **target** is discovered as a Record (Asset); each **occurrence** of an issue on a target becomes a Finding. - -#### Connector Mappings - -1. Leave the **Location** field as `https://api.intruder.io/` (the default Intruder API server). -2. Enter an Intruder **API access token** in the **Secret** field. - -Generate an access token in Intruder under **My account > API Access Tokens** (you'll need your account password to create it, and the token is shown only once). See the [Intruder API documentation](https://developers.intruder.io/docs/creating-an-access-token) for details. - -Findings are derived per occurrence: severity comes from the issue severity, CVEs and CVSS from the occurrence, the location from the target/port, and a snoozed occurrence is imported as an inactive (false-positive or risk-accepted) finding. - -## **IriusRisk** - -The IriusRisk connector uses an API token to pull threat modeling data from your IriusRisk instance. - -#### Prerequisites - -You will need an API token from your IriusRisk account. We recommend creating a dedicated service account for DefectDojo to clearly distinguish automated activity from manual team actions. - -To generate an API token in IriusRisk: - -1. Log in to your IriusRisk instance. -2. Navigate to your **User Profile** in the top-right menu. -3. Select **API Token** and generate a new token. - -See the [IriusRisk API documentation](https://support.iriusrisk.com/hc/en-us/categories/360001148511) for more information. - -#### Connector Mappings - -1. Enter your IriusRisk instance URL in the **Location URL** field. For cloud-hosted instances this is typically `https://{your-subdomain}.iriusrisk.com`. For on-premise installations, use your instance's base URL. -2. Enter your **API Token** 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. - -## **JFrog XRay** - -The JFrog Xray connector uses the JFrog Xray REST API to fetch vulnerability data from your Artifactory repositories. DefectDojo will discover all repositories in your JFrog instance and generate vulnerability reports via Xray, importing findings on a scheduled basis. - -#### Prerequisites - -You will need an API token with access to both Artifactory and Xray APIs. We recommend creating a dedicated service account for DefectDojo. The account requires: - -* Read access to Artifactory repositories -* Permission to generate and view Xray vulnerability reports (`Apply on Watches` permission in Xray, or equivalent) - -#### Connector Mappings - -1. Enter your JFrog instance base URL in the **Location** field. This should be the root URL of your JFrog instance, for example `https://your-instance.jfrog.io`. Do not include a trailing path — DefectDojo will construct the appropriate API paths automatically. -2. Enter a valid **Reference Token** in the **Secret** field. Tokens can be generated under **User Management \> Access Tokens** in the JFrog Platform UI. -You'll need to generate a **Reference Token** and use that value. - -Required token scopes for JFrog Xray: - -- **All Services**, as DefectDojo needs access to both access to both XRay and Artifactory services -- **Manage Reports + Manage Resources** at a minimum. - -By default, DefectDojo maps each Artifactory **repository** as a separate Record. Each Sync generates a complete vulnerability report per repository via Xray, so finding statuses in DefectDojo always reflect the current state of the repository. - -#### Repository Filter (optional) - -By default the connector discovers **every** repository in your JFrog instance. On instances with a large number of repositories — many of which may not be relevant to security review — discovery can be narrowed with the optional **Repository Filter** field, under **Import Filters** on the connector form. - -The filter is applied during discovery, **before any per\-repository work is done**. A repository outside the filter costs nothing: no Xray report is generated for it and, in artifact mode, none of its first\-level artifacts are enumerated. This makes it the most effective way to cut both Sync time and the load DefectDojo places on your JFrog instance — more so than any setting applied later in the Sync. It is especially recommended alongside **Artifact\-Level Records** on large instances. - -**Syntax:** a comma\-separated list of repository keys. Each entry may use `*` wildcards: - -* An entry containing `*` is matched as a pattern — `releases-*` matches every repository key beginning `releases-`, and `*docker-pr-local*` matches any key containing `docker-pr-local`. A `*` matches any run of characters, including `/`. -* An entry with no `*` must match a repository key **exactly**. -* A repository is discovered if it matches **any** entry in the list. Spaces around commas are ignored. - -``` -releases-*, snapshots -``` - -The example above discovers every repository whose key starts with `releases-`, plus the single repository named exactly `snapshots`. - -Notes: - -* The filter is an **allow\-list** — a match selects a repository. There is no exclusion or negation syntax, so you cannot express "everything except X" directly. -* Matching is **case\-sensitive**, for both exact entries and wildcards. `*` is the only wildcard character; `?` and character ranges are not supported. -* **Leave it blank to discover every repository.** A value that is only spaces or commas is treated as blank. -* A filter that matches nothing simply discovers nothing — there is no error. If a Sync unexpectedly finds no repositories, check the connector log for the `repository filter scoped discovery` entry, which reports how many of the total repositories matched. -* The field can be changed after the connection is created. - -**Changing the filter later:** repositories that a newly narrowed filter now excludes are no longer discovered, and their existing Records follow the normal lifecycle for Assets the tool no longer reports — **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. - -#### Artifact-Level Records - -The **Artifact-Level Records** toggle changes discovery to one level below the repository: every first-level entry under a repository root (for Docker repositories, each image; for generic repositories, each top-level file or folder) becomes its own Record. Each Sync still generates a single Xray report per repository — DefectDojo attributes each vulnerability to the artifacts it impacts, so the load on your JFrog instance does not increase. - -> **Check which mode you are in before your first Sync.** Artifact\-Level Records is **on by default for new installations**. Installations that predate the feature keep their existing repository\-level layout, so the toggle is off for them until someone turns it on. In both cases the toggle can be changed at any time — see *Switching an existing connection* below. - -With Artifact-Level Records enabled: - -* Repositories remain as Records and become **parent assets**: they carry no findings themselves, but when the Asset Hierarchy feature is enabled, DefectDojo automatically relates each artifact asset to its repository asset with a `parent` relationship. Assets can then be filtered by parent/child, and findings roll up the hierarchy. -* A vulnerability that impacts several artifacts is imported into each affected artifact's asset, so every asset shows the complete set of findings that affect it. -* Findings are scoped to each artifact's **latest build**, so an artifact's findings describe its current build rather than accumulating results from every build Xray has ever scanned. -* Hierarchy relationships created by the connector never overwrite relationships you created by hand. If an asset already has a parent you assigned, the connector leaves it alone. -* The token additionally needs read access to the Artifactory storage API (included in the scopes above). - -**Switching an existing connection to Artifact-Level Records:** the toggle can be changed at any time. On the first Sync afterward, new artifact Records appear for mapping — enable **Auto Map** on the connection when flipping the toggle so findings move without a gap. The repository-level assets stop receiving findings and their previously imported findings are closed on their next Sync (the same findings are re-imported under the new artifact assets, with fresh status); notes and history on the old repository-level findings stay on the repository asset. Switching back reverses this: repository Records resume carrying findings (previously closed findings re-open as they re-match), and artifact Records are marked MISSING — their assets and findings are kept but stop updating, so you can archive them at your convenience. - -See the [JFrog Xray REST API documentation](https://jfrog.com/help/r/jfrog-rest-apis/xray-rest-apis) for more information. - -## **JSM Assets** - -The JSM Assets connector is an **Asset Connector**: it enumerates the objects in your Jira Service Management Assets (formerly Insight) workspace and creates a DefectDojo Asset for each object, grouped into Organizations by object schema. No findings are imported. - -#### Prerequisites - -* Assets requires a **Jira Service Management Premium or Enterprise** plan. On Free or Standard plans the Assets API responds with `403 "Access to Assets API was denied"`, even though the rest of the site works. -* The Atlassian account used must have **Jira Service Management product access** (an agent seat) on the site — site access alone is not enough. -* Create a classic Atlassian API token at [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens). We recommend a dedicated service account. - -#### Connector Mappings - -1. Enter your Atlassian site URL in the **Location** field: `https://{your-site}.atlassian.net`. -2. Enter the Atlassian account email the token belongs to in the **Email** field. -3. Enter the API token in the **Secret** field. - -Each Assets object becomes a Record named after the object's label, grouped by its **object schema**. - -## **Klocwork** - -The Klocwork connector imports **static analysis (SAST) findings** from a Perforce Klocwork server. DefectDojo enumerates the server's projects and creates a Record for each **project**. - -#### Prerequisites - -A Klocwork **username** and its **login token (`ltoken`)** — the token generated by `kwauth` and stored in the ltoken file. The token is never logged. - -#### Connector Mappings - -1. Enter your Klocwork server URL in the **Location** field. -2. Enter the Klocwork username the token belongs to in the **Username** field. -3. Enter the login token in the **Login Token (ltoken)** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each Klocwork project becomes a Record. Only issues Klocwork classes as **actionable** are imported, and only from each project's **latest build** — so the findings describe the current state of the project rather than accumulating across builds. - -## **Kubescape** - -The Kubescape connector reads Kubernetes posture (misconfiguration) results produced by the [Kubescape operator](https://kubescape.io/docs/install-operator/) directly from the cluster's Kubernetes API — no ARMO SaaS account is required. It reads the `WorkloadConfigurationScan` objects served by the operator's in-cluster storage aggregated API (`spdx.softwarecomposition.kubescape.io/v1beta1`). Each Kubernetes **namespace** that has posture results is mapped to a Record (Asset); each failed control on a workload becomes a Finding. - -#### Prerequisites - -- The Kubescape operator must be installed in the target cluster with configuration scanning enabled (see [Installing in your cluster](https://kubescape.io/docs/install-operator/)). Confirm results exist with `kubectl get workloadconfigurationscans -A`. -- A **kubeconfig** granting read access to the `spdx.softwarecomposition.kubescape.io` API group (list/get on `workloadconfigurationscans`) for the target cluster. - -#### Connector Mappings - -1. Enter the cluster's API server URL (or a friendly cluster identifier) in the **Location** field. -2. Paste the **kubeconfig** for the target cluster in the `kubeconfig` field. Optionally set `kube_context` to select a context within it, and `cluster_name` to label the discovered Assets. -3. Each namespace with posture results is discovered as a Record; map the ones you want to import to DefectDojo Assets. - -Findings are derived per failed control: the control name and workload identify the Finding, severity comes from the control's score factor, the control ID becomes the vulnerability ID, and each Finding links to its control reference at `https://hub.armosec.io/docs/`. - -## **Mend** - -The Mend connector (formerly **WhiteSource**) uses the Mend API to import security findings from your Mend organization. DefectDojo creates a Record for each Mend **project**. - -#### Prerequisites - -You will need a Mend (service) user with a **User Key** (a personal access token) and your Mend **Organization UUID**. We recommend a dedicated service account so automated activity is easy to distinguish from manual team actions. Find the Organization UUID in the Mend App under **Administration > Organization UUID**. - -#### Connector Mappings - -1. Enter your Mend API URL in the **Location** field. This URL is **region-specific** — use the API base URL for the region your Mend organization is hosted in. -2. Enter the login email of the Mend user in the **Email** field. -3. Enter your Mend **Organization UUID** in the **Organization UUID** field. -4. Enter the Mend **User Key** in the **User Key** field. -5. Optionally, set a **Minimum Severity** to limit which findings are imported. - -## **Lacework / FortiCNAPP** - -The Lacework / FortiCNAPP connector uses the Lacework v2 API to import **host and container vulnerabilities** for your whole Lacework account. - -#### Prerequisites - -You will need a Lacework **API key** — an API key id and secret, created in the Lacework console under **Settings → API keys**. The connector exchanges these for a short-lived access token on each sync; the key id, secret and token are never logged. - -#### Connector Mappings - -1. Enter your Lacework account URL in the **Location** field — for example `https://YOUR-ACCOUNT.lacework.net` (a bare account name is also accepted). -2. Enter the **API Key ID** and **API Secret**. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo maps the Lacework **account** to a Record (the whole-account scope). Each **container** and **host** vulnerability becomes a finding: the severity comes from Lacework's own rating, the affected package and version become the component, the fix version becomes the mitigation, and the affected image/host is recorded as tags. Container vulnerabilities are recorded as static findings (image scans) and host vulnerabilities as dynamic findings (running-host scans). - -See the [Lacework API documentation](https://docs.lacework.net/api/v2/docs) 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 Asset 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). - -## **Microsoft Defender for Cloud** - -The Microsoft Defender for Cloud connector imports vulnerability findings from **Microsoft Defender Vulnerability Management (MDVM)** as surfaced by Defender for Cloud — both **server** findings (Azure VM operating\-system and installed\-software CVEs) and **container\-registry** findings (container image CVEs), including severity, CVSS score, the affected package or image, and remediation. DefectDojo discovers the Azure **subscriptions** your service principal can read and creates a Record for each enabled subscription. - -**Please note:** this Connector is distinct from the **Microsoft Defender** connector, which imports device findings from the Defender for Endpoint API. Defender for Cloud is an Azure Asset with a different API surface (Azure Resource Manager / Resource Graph) and permission model (Azure RBAC). Run whichever matches where your findings live — or both, if you use both Assets. - -#### Prerequisites - -You need one or more **Azure subscriptions with Microsoft Defender for Cloud enabled**, with the relevant Defender plans turned on for the resources you want scanned (under **Microsoft Defender for Cloud \> Environment settings**, then select your subscription): - -* **Defender for Servers (Plan 2)** — Azure VM operating\-system and software CVE findings (agentless vulnerability scanning). -* **Defender for Containers** — container\-registry image CVE findings. - -SQL vulnerability\-assessment and configuration/posture findings are intentionally **not** imported — this connector imports CVE vulnerabilities only. - -The connector authenticates as a Microsoft Entra ID **app registration** using the client credentials flow: - -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 **Certificates & secrets \> New client secret**, set an expiry, and copy the secret **Value** immediately (it is shown only once). The Connector stops working when the secret expires, so note the date. -4. Grant the app read access to each subscription you want to import: open **Subscriptions**, select your subscription, then **Access control (IAM) \> Add \> Add role assignment**. Select the **Security Reader** role (or **Reader**), and on the **Members** tab assign it to the app you created — search for it by the app's **name** or **object ID**, as the picker does not match the client ID. Repeat for every subscription. - -Unlike the device\-based Microsoft Defender connector, no API permissions or admin consent are required: Defender for Cloud access is governed entirely by the Azure RBAC role assignment above. - -#### Connector Mappings - -1. Enter `https://management.azure.com` in the **Location** field. (For sovereign clouds, use the matching ARM endpoint, for example `https://management.usgovcloudapi.net`.) -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 enabled Azure subscription becomes a Record. Findings are read through Azure Resource Graph, so they surface promptly once Defender for Cloud has scanned your resources — but the scans themselves run on Microsoft's schedule: container\-registry images are usually scanned within an hour of being pushed, while a VM's first agentless vulnerability scan can take several hours. A newly enabled subscription will legitimately Sync zero findings until its resources have been scanned. - -## **MobSF** - -The MobSF connector uses the [Mobile Security Framework (MobSF)](https://github.com/MobSF/Mobile-Security-Framework-MobSF) REST API to import mobile application (APK/IPA) static-analysis results. DefectDojo discovers every app that has been scanned on your MobSF instance and creates a Record for each one, then imports that app's static-analysis findings. - -#### Prerequisites - -You will need your MobSF **REST API key**. Find it on the MobSF home page under **API** (also shown in the MobSF docs as the `Authorization` value). The key is sent on every request and is never logged. - -#### Connector Mappings - -1. Enter your MobSF base URL in the **Location** field (for example `https://mobsf.example.com`). -2. In the **Secret** field, enter the MobSF REST API key. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo maps each scanned **app** to a Record and imports its findings from the MobSF JSON report across several sections — application permissions, code analysis, the signing certificate, the Android manifest, Android API usage and binary analysis. Each finding is tagged with **CWE 919** (mobile), and its severity comes from MobSF's own rating (high, warning, info, secure/good) — a *dangerous* permission is treated as High. Findings are recorded as static findings and de-duplicated on the scan, section, title, severity and file path. - -See the [MobSF REST API documentation](https://mobsf.github.io/docs/#/rest_api) for more information. - -## **NetRise** - -The NetRise connector imports **firmware vulnerability findings** from NetRise. DefectDojo enumerates every firmware artifact in your tenant and creates a Record for each **product line** — the vendor and Asset pair — so a product line accumulates the findings of its artifacts. - -#### Prerequisites - -A NetRise API **client ID and secret**, plus the **organization ID** they belong to. The secret is never logged. - -#### Connector Mappings - -1. Enter your NetRise API URL in the **Location** field. -2. Enter the client ID in the **Client ID** field. -3. Enter the client secret in the **Client Secret** field. -4. Enter your **Organization ID**. -5. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each product line becomes a Record, carrying the CVEs found in its firmware artifacts. - -## **NeuVector** - -The NeuVector connector uses the [NeuVector](https://github.com/neuvector/neuvector) controller REST API to import container **image vulnerability scans**. DefectDojo discovers every image NeuVector has scanned and creates a Record for each, then imports that image's scan report as findings. - -#### Prerequisites - -You will need a NeuVector **username and password** for a controller account with permission to read scan results. The connector logs in with these credentials to obtain a session token; the password and token are never logged. - -#### Connector Mappings - -1. Enter your NeuVector controller URL in the **Location** field, including the REST API port — for example `https://neuvector.example.com:10443`. -2. Enter the controller **Username** and **Password**. -3. If your controller uses a self-signed certificate, set **Skip TLS Verification** to `true`. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo maps each scanned **image** to a Record and each **CVE** in its scan report to a finding. The severity comes from NeuVector's own rating, and the affected package and version, CVSSv3 score and vector, fix version (as mitigation) and reference link are carried over. Findings are de-duplicated on the image, CVE, package, version and severity. - -See the [NeuVector API documentation](https://open-docs.neuvector.com/automation/automation) for more information. - -## **Nightfall AI** - -The Nightfall AI connector imports **data loss prevention (DLP) violations** — sensitive data Nightfall has detected across your connected SaaS tools. DefectDojo creates a Record for each **connected integration** that has violations. - -The integration is the natural grouping here, because Nightfall's asset is the data source itself: Slack, Google Drive, GitHub, Jira, Confluence, Salesforce, Zendesk, Notion, Teams, OneDrive, the browser extension, and inline email. - -#### Prerequisites - -A Nightfall **API key**, sent as a bearer token and never logged. - -#### Connector Mappings - -1. Enter `https://api.nightfall.ai/dlp/v1` in the **Location** field. -2. Enter your Nightfall API key in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each integration with violations becomes a Record. Integrations with no violations are not mapped. - -## **NowSecure** - -The NowSecure connector imports **mobile application security findings**, covering both mobile SAST and DAST. DefectDojo creates a Record for each **mobile app** on the account. - -#### Prerequisites - -A NowSecure **Platform API token**, from **Profile \> Tokens \> Generate Token**. It is sent as a bearer token and never logged. - -#### Connector Mappings - -1. Enter `https://lab-api.nowsecure.com` in the **Location** field. -2. Enter the API token in the **API Token** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each mobile app becomes a Record, carrying the findings from that app's **latest assessment** — so results describe the current build rather than accumulating across assessments. - -## **Nozomi Networks** - -The Nozomi Networks connector imports **OT/ICS vulnerability findings** from Nozomi Vantage. DefectDojo creates a Record for each **network zone**, so one Record represents one zone of your operational network. - -#### Prerequisites - -A Vantage **access key name** and **key token**, created under **Administration \> Security \> Access Keys**. DefectDojo exchanges them for a short\-lived session token on each Sync; the key token is never logged. - -#### Connector Mappings - -1. Enter `https://api.vantage.nozominetworks.io` in the **Location** field. -2. Enter the access key name in the **Key Name** field. -3. Enter the key token in the **Key Token** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -This connector imports **vulnerabilities only** — it does not import alert-log events — and only those Vantage still reports as **unresolved**, so vulnerabilities you resolve in Vantage are reflected in DefectDojo on the next Sync. - -## **Nuclei (ProjectDiscovery Cloud)** - -The Nuclei connector uses the ProjectDiscovery Cloud Platform (PDCP) REST API to pull [nuclei](https://github.com/projectdiscovery/nuclei) scan results from your PDCP account. DefectDojo discovers every scan in the account and creates a separate Record for each **scan**. - -#### Prerequisites - -You will need a ProjectDiscovery Cloud **API key**. We recommend creating a dedicated service account for DefectDojo to clearly distinguish automated activity from manual team actions. Generate a key from **Settings \> API Key** in the ProjectDiscovery Cloud UI ([cloud.projectdiscovery.io](https://cloud.projectdiscovery.io)). Results reach PDCP either from hosted scans or from the nuclei CLI run with `-dashboard`. - -#### Connector Mappings - -1. Enter the PDCP API base URL in the **Location** field: `https://api.projectdiscovery.io`. -2. Enter your **API key** in the **Secret** field. -3. Optionally, enter a **Team ID** to scope the sync to a team workspace (found under **Settings \> Team**). When left blank, DefectDojo syncs your personal workspace. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo maps each PDCP **scan** as a separate Record and imports that scan's findings across every severity, including informational. - -## **OpenVAS / Greenbone** - -The OpenVAS / Greenbone connector imports **network vulnerability findings** from a Greenbone (Greenbone Community Edition or Greenbone Enterprise) instance. It talks to `gvmd` over **GMP (Greenbone Management Protocol)** — an XML protocol, not HTTP — and syncs the whole instance: it enumerates scan **tasks** and creates a DefectDojo product for each, importing the results of each task's latest report. - -GMP can be carried two ways, and which one you need depends on your Greenbone version: - -* **SSH** — what Greenbone documents from **GOS 4** onwards, and the right choice for a current instance. -* **TLS** — gvmd's older transport on port **9390**. It was the default only through GOS 3.1, and a current Greenbone commonly exposes no TLS listener at all. - -#### Prerequisites - -A Greenbone **GMP user** (username + password) in all cases. The GMP user is always required: SSH only carries the connection to `gvmd`, and GMP still authenticates over it. - -For the **SSH** transport, an SSH account on the Greenbone host that reaches `gvmd`, plus its host key fingerprint. Either arrangement works and the connector detects which one your host uses: - -* An account whose forced command connects the session to `gvmd` — the arrangement Greenbone appliances ship, and the one `gvm-tools` uses. The default account name is `gmp`. -* An ordinary account permitted to forward to gvmd's unix socket (`AllowStreamLocalForwarding`), which suits self\-managed and containerised installs. - -For the **TLS** transport, network access to gvmd's GMP TLS port (default **9390**). Note that the Greenbone Community Edition compose stack fronts `gvmd` with a unix socket and no TLS listener, so this transport needs something in front of the socket — for example a `socat` TLS bridge to `gvmd.sock`. - -#### Connector Mappings - -1. Enter the Greenbone host in the **Location** field. -2. Enter the GMP **Username** and **Password**. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Then configure one transport. - -**For SSH:** - -1. Set **Transport** to `ssh`. -2. Enter the **SSH Username** (defaults to `gmp`) and, if it is not 22, the **SSH Port**. -3. Provide either an **SSH Private Key** — with its **SSH Key Passphrase** if the key is encrypted — or an **SSH Password**. A key is preferred. -4. Enter the **SSH Host Key Fingerprint**. A server usually offers host keys of several types and there is no telling in advance which one gets negotiated, so paste **all** of them, separated by commas or spaces. `ssh-keyscan | ssh-keygen -lf -` prints them for every key the host offers, and its output can be pasted as\-is. Setting **Skip SSH Host Key Check** to `true` accepts any host key instead, which is not recommended. Note that **Skip TLS Verification** does *not* do this \- it covers the TLS certificate only, so that routinely skipping the check on gvmd's self\-signed certificate cannot quietly un\-pin your host keys. -5. Optionally set the **gvmd Socket Path** if your host permits socket forwarding but keeps the socket somewhere non\-standard. Left blank, the connector probes the usual locations. - -**For TLS:** - -1. Leave **Transport** blank. -2. Optionally set the **GMP Port** (defaults to 9390). -3. For gvmd's default self\-signed certificate, either provide a **CA Certificate (PEM)** to verify against, or set **Skip TLS Verification** to `true`. - -Each Greenbone task becomes a Record. Findings come from the task's latest finished report — one per ``. Severity is taken from the result's threat level (Greenbone's `Log`/`Debug` informational levels map to Info), with the numeric CVSS score recorded; CVE references become vulnerability ids, the NVT solution becomes the mitigation, and each result's host/port becomes an endpoint. - -## **Orca Security** - -The Orca Security connector imports **open alerts** from Orca — vulnerabilities, misconfigurations, malware and secrets alike. DefectDojo creates a Record for each **connected cloud account**. - -#### Prerequisites - -An Orca **API token**. - -**Orca tokens are region-scoped**, so the token and the API host must belong to the same region. If a Sync fails to authenticate with a token you know is valid, check that the **Location** matches the token's region. - -#### Connector Mappings - -1. Enter your **region-matched** Orca API host in the **Location** field. -2. Enter your Orca API token in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each connected cloud account becomes a Record. Only **open** alerts are imported, so alerts you close in Orca are reflected in DefectDojo on the next Sync. - -## **Ostorlab** - -The Ostorlab connector imports **mobile, web and attack-surface findings** — all three of Ostorlab's asset classes through one connector. DefectDojo creates a Record for each **scanned asset**, which may be an app bundle ID, a domain, or a host. - -#### Prerequisites - -An Ostorlab **API key**, created under **Settings \> API Keys**. It is sent as the `X-Api-Key` header and is never logged. - -#### Connector Mappings - -1. Enter `https://api.ostorlab.co` in the **Location** field. DefectDojo appends the GraphQL API path itself. -2. Enter your Ostorlab API key in the **API Key** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each scanned asset becomes a Record, and the vulnerabilities from every scan of that asset are imported against it. - -## **Parasoft DTP** - -The Parasoft DTP connector imports **static analysis violations** from a Parasoft DTP server. DefectDojo creates a Record for each DTP **report filter**. - -#### Prerequisites - -A Parasoft DTP **username and password**, used over HTTP Basic authentication. The password is never logged. - -#### Connector Mappings - -1. Enter your Parasoft DTP server URL in the **Location** field, including its port if it uses a non\-standard one. -2. Enter the DTP username in the **Username** field. -3. Enter the password in the **Password** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each report filter becomes a Record, carrying that filter's static analysis violations **from the latest build** — so findings describe the current state of the code rather than accumulating across builds. - -## **Picus Security** - -The Picus Security connector imports **breach and attack simulation (BAS) results** from the Picus platform — whether your existing security controls prevented, logged and alerted on each simulated attack. DefectDojo creates a Record for each **agent group**, so one Record represents one environment under test. - -#### Prerequisites - -You need a Picus **REST API refresh token**, generated by hand at **app.picussecurity.com \> Settings \> Rest API Token**. It is valid for **six months**, and DefectDojo exchanges it for short\-lived access tokens automatically. - -> **Paste the refresh token, not an access token.** Picus also issues a two\-hour **access token** from the same area. An access token pasted into the connector will authenticate at first and then stop working the same afternoon. The connector needs the six\-month refresh token. - -Because the refresh token expires after six months, plan to rotate it — the connector cannot renew it for you. - -#### Connector Mappings - -1. Enter `https://api.picussecurity.com` in the **Location** field. -2. Enter the six\-month REST API refresh token in the **Refresh Token** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each agent group becomes a Record, and its findings come from the **most recent run of every simulation** bound to that group. - -## **PingCastle** - -The PingCastle connector imports **Active Directory security posture findings** from a PingCastle Enterprise reporting server. DefectDojo creates a Record for each **Active Directory domain** the reporting server monitors, and that domain's **latest HealthCheck report** supplies its findings. - -This is a different category from most connectors in this list — identity and Active Directory posture, rather than application, cloud or container scanning. - -#### Prerequisites - -The PingCastle Enterprise **API key** — the same key your PingCastle agents use when they submit reports (the `--api-key` value passed alongside `--api-endpoint`). It is sent as the `X-API-Key` header. - -#### Connector Mappings - -1. Enter your **PingCastle Enterprise reporting server** URL in the **Location** field — the same address your agents submit to via `--api-endpoint`. -2. Enter the PingCastle Enterprise API key in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each monitored domain becomes a Record. DefectDojo reads the same HealthCheck risk rules that the file-based PingCastle parser reads from a local XML export, so findings are consistent whichever route you use. - -## Probely - -This connector uses the Probely REST API to fetch data. - -​**Connector Mappings** - -1. Enter the appropriate API server address in the **Location** field. (either or ) -2. Enter a valid API key in the **Secret** field. - -You can find an API key under the User \> API Keys menu in Probely. -See [Probely documentation](https://help.probely.com/en/articles/8592281-how-to-generate-an-api-key) for more info. - -## **Promptfoo** - -The Promptfoo connector imports **LLM red-teaming and evaluation findings** from Promptfoo Cloud. DefectDojo creates a Record for each **target application** (provider) that Promptfoo probed. - -#### Prerequisites - -A Promptfoo Cloud **API token**, sent as a bearer token and never logged. - -#### Connector Mappings - -1. Enter `https://api.promptfoo.app` in the **Location** field. -2. Enter your Promptfoo API token in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo reads every stored evaluation the token can see and works out which targets were probed. A target's findings are its **failing** probes across all evaluations, aggregated **per weakness** rather than one finding per probe run — so repeated evaluations of the same weakness stay a single finding. - -## Prowler - -The Prowler connector uses the **Prowler App** REST API to import cloud security posture (CSPM) findings from a self-hosted Prowler App instance. DefectDojo discovers each Prowler **provider** (cloud account) as a Record and imports the **FAIL** findings of that provider's latest completed scan. - -#### Prerequisites - -You will need a running, self-hosted **Prowler App** instance and either a user email + password (for JWT authentication) or a Prowler App **API key**. Findings only appear once you have connected a cloud account (AWS, GCP, Azure, Kubernetes, ...) in Prowler App and run a scan. - -#### Connector Mappings - -1. Enter your Prowler App URL in the **Location** field (for example `https://prowler.your-company.com`). -2. For JWT authentication, enter the Prowler App user **Email** and **Password**. Alternatively, leave those blank and enter a Prowler App **API Key**. If both are provided, the email/password (JWT) is used. -3. Optionally set a **Minimum Severity** to limit which findings are imported. Findings below the selected severity are not imported. - -DefectDojo creates a Record for each Prowler provider and imports the FAIL findings of its latest completed scan, mapping Prowler severities to DefectDojo severities, the affected cloud resource (ARN/resource id) as the component, and the check's remediation and risk into the finding. Muted findings are skipped. Cloud account, region, and service are attached as tags. - -For more information, see the **[Prowler App API documentation](https://api.prowler.com/api/v1/docs)**. - -## Qualys - -The Qualys connector imports **VMDR host vulnerability detections** — each joined with its Qualys KnowledgeBase (QID) metadata — from the Qualys Cloud Platform. DefectDojo creates a Record for each Qualys **host** in your subscription. - -#### Prerequisites - -A Qualys user account with **VMDR API access**, and your subscription's **API server (platform) URL** — this differs per subscription. Find it in the Qualys UI under **Help \> About**, or on the Qualys [Platform Identification](https://www.qualys.com/platform-identification/) page (for example `https://qualysapi.qualys.com` for US Platform 1, or `https://qualysapi.qg2.apps.qualys.com` for US Platform 2). - -#### Connector Mappings - -1. Enter your Qualys API server URL in the **Location** field (for example `https://qualysapi.qualys.com`). -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. - -Each Qualys host becomes a Record. Detections Qualys has marked **Fixed** are excluded, so reimport closes remediated findings. - -#### Host Tags (optional) - -By default the connector discovers **every** host in your Qualys subscription. On a large estate that produces a Record list far bigger than most teams want. It also makes every Sync download the detections of every host. - -The optional **Host Tags** field, under **Import Filters** on the connector form, restricts the connector to hosts carrying the Qualys asset tags you name. The restriction travels to Qualys as part of the request, so out-of-scope hosts are never returned. It applies to **both** the host listing and the detection download. Narrowing the scope therefore cuts Sync time and transfer volume, not just the length of the Record list. - -**Syntax:** a comma-separated list of Qualys asset tag **names**, exactly as they appear in the Qualys UI under **Asset Management \> Tags**. - -``` -Prod, Business Unit: Finance -``` - -The example above discovers every host tagged `Prod` plus every host tagged `Business Unit: Finance`. - -Notes: - -* Tag names are matched **exactly**, and **wildcards are not supported**. Qualys offers no pattern matching on tag names, so `Prod-*` matches a tag literally named `Prod-*` and nothing else. This differs from the JFrog Xray **Repository Filter** described above, which does accept `*`. -* A host is discovered if it carries **any** tag in the list, not all of them. -* Spaces **around** the commas are ignored. Spaces **inside** a tag name are kept, so `Business Unit: Finance` works as written. -* A tag name that itself contains a comma cannot be used here, because the comma separates entries. -* The filter is an **allow-list**. There is no exclusion or negation syntax, so you cannot express "everything except X". -* **Leave it blank to discover every host.** A value that is only spaces or commas is treated as blank. -* If the tag names match no host, nothing is discovered. Check the spelling against the Qualys UI, and check the visible-host count reported on the connection. -* The field can be changed after the connection is created. - -**Testing the connection** ignores this field on purpose, so it still confirms your username and password even when the tag names are wrong. - -**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. - -## **Quay** - -The Quay connector uses the Project Quay REST API to discover container repositories and import the vulnerability reports produced by Quay's built-in **Clair** scanner. DefectDojo creates a Record for each Quay **repository** and, on each Sync, reads the Clair security report of every active tag's image manifest. - -#### Prerequisites - -Security scanning (Clair) must be enabled on your Quay instance, and you will need a Quay **OAuth 2 access token**: - -* In Quay, create (or open) an Organization, go to **Applications**, create an OAuth application, then **Generate Token** with at least the **Read repositories** scope. A dedicated application for DefectDojo is recommended. -* The token is sent as a Bearer token on every request and is never logged. - -#### Connector Mappings - -1. Enter your Quay base URL in the **Location** field, for example `https://quay.io` or your self-hosted `https://quay.example.com`. The URL must be HTTPS; do not include a trailing API path — DefectDojo constructs the API paths automatically. -2. Enter the OAuth access token in the **Secret** field. -3. Optionally, set a **Namespace** to restrict discovery to a single Quay organization or user. Leave blank to discover every repository the token can read. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo maps each Quay **repository** to a Record. For each repository it lists the active tags, deduplicates them to their unique image manifests (a manifest shared by multiple tags is scanned once), and reads each manifest's Clair report. Manifests Clair has not finished scanning (for example a multi-architecture manifest list, or an image still queued) are skipped until a later Sync. Each Clair vulnerability becomes a finding — the affected package is the component, the fixed version becomes the mitigation, and Clair's **Negligible**/**Unknown** severities are recorded as **Informational**. - -See the [Project Quay API documentation](https://docs.projectquay.io/api_quay.html) and the [Clair documentation](https://quay.github.io/clair/) for more information. - -## **Qwiet AI** - -The Qwiet AI connector imports **SAST, SCA and secret findings** from Qwiet AI (formerly ShiftLeft), and carries Qwiet's **reachability signal** — an indication of whether vulnerable code is actually reachable — which DefectDojo has no other source for. DefectDojo creates a Record for each **application** in your organization. - -#### Prerequisites - -A Qwiet AI **preZero access token**, sent as a bearer token and never logged. Your organization is read from the token itself, so you do not normally need to supply it. - -#### Connector Mappings - -1. Enter `https://app.shiftleft.io` in the **Location** field — the host is still the legacy ShiftLeft domain. DefectDojo appends the API path itself. -2. Enter the access token in the **Access Token** field. -3. Optionally, enter an **Organization ID** to override the organization. Leave it blank to use the organization encoded in the access token. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each application becomes a Record, carrying its SAST, SCA and secret findings together. - -## **Rapid7 InsightAppSec** - -The Rapid7 InsightAppSec connector imports **DAST vulnerability findings** from the InsightAppSec cloud platform, enriched with attack\-module metadata (for example *SQL Injection*), CVSS scores, and the evidence collected by the scan. DefectDojo creates a Record for each InsightAppSec **app**. - -**Please note:** this Connector is distinct from the **Rapid7 InsightVM** connector below — InsightAppSec is Rapid7's cloud DAST product on the Insight platform, while InsightVM findings come from your own Security Console. - -#### Prerequisites - -An Insight platform account with InsightAppSec, and a platform **API key**: in the [Rapid7 Insight platform](https://insight.rapid7.com), open the settings (gear) menu \> **API Keys** and generate a **User Key** (any role) or an **Organization Key** (platform admins). Copy the key when it is shown — it is displayed only once. - -You also need your platform **region**, visible in your Insight URL (for example `us`, `us2`, `us3`, `eu`, `ca`, `au`, or `ap`). - -#### Connector Mappings - -1. Enter your regional API endpoint in the **Location** field — for example `https://us.api.insight.rapid7.com` (replace `us` with your region). -2. Enter the Insight platform API key in the **API Key** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each InsightAppSec app becomes a Record. Only **open** vulnerabilities (Unreviewed or Verified) are imported — findings Rapid7 has marked Remediated, a False Positive, Ignored, or Duplicate are excluded, so reimport closes them in DefectDojo. Severities map directly (`SAFE` and `INFORMATIONAL` import as Info). - -## **Rapid7 InsightVM** - -The Rapid7 InsightVM connector imports asset vulnerability findings from your InsightVM **Security Console** (API v3), enriched with the console's global vulnerability catalog. DefectDojo creates a Record for each InsightVM **site**. - -#### Prerequisites - -Network access from DefectDojo to your Security Console, and a console **user account** — its login is used for HTTP Basic authentication. The console API is served on port **3780** by default. - -#### Connector Mappings - -1. Enter your Security Console URL, including the port, in the **Location** field — for example `https://console.example.com:3780`. -2. Enter the console username in the **Username** field. -3. Enter the console password in the **Secret** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each InsightVM site becomes a Record; the connector walks the site's assets and imports their vulnerable findings. - -## **Red Hat Satellite** - -The Red Hat Satellite connector imports **errata** from your Satellite inventory as findings. DefectDojo enumerates every host and folds the fleet into Records along one Katello dimension of your choosing. - -**This is broader than "vulnerabilities."** Every applicable erratum on every host becomes a finding — that includes RHSA security advisories **and** bugfix and enhancement advisories. Use a **Minimum Severity** if you only want the security ones. - -#### Prerequisites - -A Satellite login with the **`view_hosts`** and **`view_content_views`** permissions. Satellite has no token endpoint, so the credentials are sent with every request over HTTP Basic authentication, and the password is never logged. - -#### Connector Mappings - -1. Enter your Satellite server URL in the **Location** field — for example `https://satellite.example.com`. -2. Enter the Satellite username in the **Username** field. -3. Enter the password in the **Password** field. -4. Optionally, set **Asset Grouping** to choose how hosts are folded into Records: `host-collection`, `lifecycle-environment`, `content-view`, or `host` for one Record per host. Leave it blank for `host-collection`. -5. Optionally, set **Skip TLS Verification** to `true` if your Satellite server uses the self\-signed certificate a default Satellite or Foreman install generates for itself. Leave it blank to verify certificates. -6. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Hosts that share a grouping value share a Record, and a new host joins the right Record automatically on the next Discover — so the mapping keeps up with your fleet without per\-host configuration. - -## **runZero** - -The runZero connector uses the runZero Export API to sync your whole organization's asset inventory into DefectDojo. It is primarily an **asset** connector: DefectDojo discovers every asset and creates a Record for each, grouped into an Organization by its runZero **site**. It can optionally also import runZero's vulnerabilities as findings. - -#### Prerequisites - -You will need an organization **Export Token** from runZero (Account → API), which is prefixed `XT`. The token is organization-scoped (the organization is encoded in the token), read-only, and is sent as a Bearer token — it is never logged. A community/starter tier is available. - -#### Connector Mappings - -1. Enter your runZero console URL in the **Location** field, for example `https://console.runzero.com`. The URL must be HTTPS. -2. Enter the Export Token in the **Secret** field. -3. Optionally set **Import Vulnerabilities** to `true` to also import runZero vulnerabilities as findings; leave it blank to sync assets only. -4. Optionally, set a **Minimum Severity** to limit which vulnerability findings are imported (applies only when vulnerabilities are imported). - -DefectDojo maps each runZero **asset** to a Record (VEP): the display name comes from the asset's name or address, and its site, type, OS, addresses and tags are attached as attributes; the asset's **site** becomes its Organization. Assets are synced with a full export that DefectDojo reconciles (adds/removes). When **Import Vulnerabilities** is enabled, each runZero vulnerability becomes a finding on its asset — mapping the severity, CVSS score, CVE, affected service (`protocol://address:port`) endpoint and the remediation. - -See the [runZero API documentation](https://help.runzero.com/) for more information. - -## **Scantist** - -The Scantist connector imports **SCA and SAST findings** from Scantist. DefectDojo creates a Record for each **project** on the account. - -#### Prerequisites - -A Scantist **API token**, generated in the Scantist UI under your account settings. - -#### Connector Mappings - -1. Enter `https://api.scantist.io` in the **Location** field. -2. Enter the API token in the **API Token** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each project becomes a Record, and its findings come from that project's **most recent completed scan**. - -## **Security Hub** - -The AWS Security Hub connector uses an AWS access key to interact with the Security Hub APIs. - -#### Prerequisites - -Rather than use the AWS access key from a team member, we recommend creating an IAM User in your AWS account specifically for DefectDojo, with that user's permissions limited to those necessary for interacting with Security Hub. - -AWS's "**[AWSSecurityHubReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubReadOnlyAccess.html)**policy" provides the required level of access for a connector. If you would like to write a custom policy for a Connector, you will need to include the following permissions: - -* [DescribeHub](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_DescribeHub.html) -* [GetFindingAggregator](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingAggregator.html) -* [GetFindings](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindings.html) -* [ListFindingAggregators](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_ListFindingAggregators.html) - -A working policy definition might look like the following: - -``` -{ - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "AWSSecurityHubConnectorPerms", - "Effect": "Allow", - "Action": [ - "securityhub:DescribeHub", - "securityhub:GetFindingAggregator", - "securityhub:GetFindings", - "securityhub:ListFindingAggregators" - ], - "Resource": "*" - } - ] -} -``` - -**Please note:** we may need to use additional API actions in the future to provide the best possible experience, which will require updates to this policy. - -Once you have created your IAM user and assigned it the necessary permissions using an appropriate policy/role, you will need to generate an access key, which you can then use to create a Connector. - -#### Connector Mappings - -1. Enter the appropriate [AWS API Endpoint for your region](https://docs.aws.amazon.com/general/latest/gr/sechub.html#sechub_region) in the **Location** field**:** for example, to retrieve results from the `us-east-1` region, you would supply - -`https://securityhub.us-east-1.amazonaws.com` -2. Enter a valid **AWS Access Key** in the **Access Key** field. -3. Enter a matching **Secret Key** in the **Secret Key** field. - -DefectDojo can pull Findings from more than one region using Security Hub's **cross\-region aggregation** feature. If [cross\-region aggregation](https://docs.aws.amazon.com/securityhub/latest/userguide/finding-aggregation.html) is enabled, you should supply the API endpoint for your "**Aggregation Region**". Additional linked regions will have ProductRecords created for them in DefectDojo based on your AWS account ID and the region name. - -## **Semgrep** - -This connector uses the Semgrep REST API to fetch data. - -#### Connector Mappings - -Enter `https://semgrep.dev/api/v1/` in the **Location** field. - -1. Enter a valid API key in the **Secret** field. You can find this on the Tokens page: -​ -"Settings" in the left navbar \> Tokens \> Create new token ([https://semgrep.dev/orgs/\-/settings/tokens389) - -See [Semgrep documentation](https://semgrep.dev/docs/semgrep-cloud-platform/semgrep-api/#tag__badge-list) for more info. - -## **ServiceNow CMDB** - -The ServiceNow CMDB connector is an **Asset Connector**: instead of importing findings, it reads Configuration Items (CIs) from your ServiceNow Configuration Management Database and creates a DefectDojo Asset for each CI, grouped into Organizations by CI class. No findings are imported. - -#### Prerequisites - -You will need a ServiceNow instance and an account that can read the CMDB tables over the ServiceNow Table API. We recommend a dedicated, read-only service account for DefectDojo. The account needs read access to the `cmdb_ci` tables you want to import. - -#### Connector Mappings - -1. Enter your ServiceNow instance URL in the **Location** field: `https://{your-instance}.service-now.com`. -2. Select or create a ServiceNow **Tool Configuration** holding the instance credentials (the ServiceNow username and password). - -Each Configuration Item becomes a Record named after the CI, grouped by its **CI class** (for example, application, server, or business service). Discovery and Sync reconcile the CI list: new CIs appear as `NEW` Records, and a CI removed from the CMDB is flagged `MISSING` on the next Sync so your team can triage it. DefectDojo never silently deletes an Asset. - -## **Shodan** - -The Shodan connector uses the Shodan REST API to import the vulnerabilities (CVEs) Shodan has observed on your internet-exposed hosts. You provide a Shodan search query that scopes the import to your own assets; DefectDojo creates a Record for each matching host and imports its CVEs as findings. - -#### Prerequisites - -You will need a Shodan API key, found on your Shodan **Account** page. Host search with vulnerability data requires a Shodan membership or a paid API plan — the free tier cannot page through search results. - -#### Connector Mappings - -1. Enter `https://api.shodan.io` in the **Location** field. -2. Enter your Shodan API key in the **API Key** field. -3. In the **Search Query** field, enter a Shodan query that scopes the import to your organization's assets — for example `hostname:example.com`, `net:203.0.113.0/24`, or `org:"Example Inc"`. Only hosts matching this query are imported, so keep it scoped to infrastructure you own. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each matching host becomes a Record, and each CVE Shodan detected on that host's exposed services is imported as a finding — severity is derived from the CVSS score, with EPSS and CISA KEV context included where available. Each page of search results consumes one Shodan query credit. - -## SonarQube - -The SonarQube Connector can fetch data from either a SonarCloud account or from a local SonarQube instance. - -**For SonarCloud users:** - -1. Enter https://sonarcloud.io/ in the Location field. -2. Enter a valid **API key** in the Secret field. - -**For SonarQube (on\-premise) users:** - -1. Enter the base url of your SonarQube instance in the Location field: for example `https://my.sonarqube.com/` -2. Enter a valid **API key** in the Secret field. This will need to be a **[User](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/)** [API Token Type](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/). - -The token will need to have access to Projects, Vulnerabilities and Hotspots within Sonar. - -API tokens can be found and generated via **My Account \-\> Security \-\> Generate Token** in the SonarQube app. For more information, [see SonarQube documentation](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/). - -## **Snyk** - -The Snyk connector uses the Snyk REST API to fetch data. - -#### Connector Mappings - -1. Enter **[https://api.snyk.io/rest394** or **[https://api.eu.snyk.io/rest395** (for a regional EU deployment) in the **Location** field. -2. Enter a valid API key in the **Secret** field. API Tokens are found on a user's **[Account Settings](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token)** [page](https://docs.snyk.io/getting-started/how-to-obtain-and-authenticate-with-your-snyk-api-token) in Snyk. - -See the [Snyk API documentation](https://docs.snyk.io/snyk-api) for more info. - -## **Socket** - -The Socket connector uses the [Socket.dev](https://socket.dev) API to import **software supply-chain findings** — Socket's alerts on your dependencies (malware, typosquats, install scripts, known vulnerabilities and 70+ other categories). DefectDojo discovers every repository across the organizations your token can access and creates a Record for each, then imports the alerts from that repository's latest full scan. - -#### Prerequisites - -You will need a Socket **API token** — an organization token created in the Socket dashboard under **Settings → API Tokens** (with the `repo:list` and full-scan read scopes). The token is sent as a bearer token and is never logged. - -#### Connector Mappings - -1. Leave the **Location** field blank to use `https://api.socket.dev/v0`, or enter it explicitly. -2. Enter the Socket API token in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -DefectDojo maps each **repository** to a Record and imports the alerts from its most recent full scan. Each alert becomes a finding: the severity comes from Socket's own rating (low, medium, high, critical), the affected package becomes the component and a PURL, the alert category (supply-chain risk, quality, maintenance, vulnerability, license) is recorded as tags, and the alert details are carried into the description. Findings are recorded as static findings and de-duplicated on Socket's alert key. - -See the [Socket API documentation](https://docs.socket.dev/reference) for more information. - -## **Sonatype IQ** - -The Sonatype IQ connector uses the Sonatype IQ Server (Nexus Lifecycle) REST API to import open\-source component vulnerabilities. It enumerates every application in your IQ organization and, for each one, imports the component vulnerabilities from that application's latest report at the lifecycle stage you configure. DefectDojo creates a Record for each application automatically — there is no per\-application configuration. - -#### Prerequisites - -You will need a Sonatype IQ user account with the **View IQ Elements** permission on the applications you want to import. Sonatype recommends authenticating with a **user token** (generated under **My Profile > User Token** in IQ Server) rather than a password; the token's two parts map to the Username and User Token fields below. The connector works with both self\-hosted IQ Server and Sonatype\-hosted (SaaS) instances. - -#### Connector Mappings - -1. In the **Location** field, enter your IQ Server base URL — for a self\-hosted server, `https://iq.example.com`; for a Sonatype\-hosted instance, `https://.sonatype.app/platform`. -2. Enter the IQ user (or the user\-code part of your user token) in the **Username** field. -3. Enter the IQ user token (or password) in the **User Token** field. -4. Optionally, set a **Stage** to choose which lifecycle stage's report is imported per application (`build`, `stage-release`, `release`, and so on). Leave it blank to use `build`. -5. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each application becomes a Record, and each security issue in that application's latest report for the selected stage is imported as a finding. Severity is derived from the issue's numeric score, and CVE references, CWE, the CVSS vector, and the affected component's package URL (PURL) are included where available. -## **SOOS** - -The SOOS connector imports **SCA findings** from SOOS. DefectDojo creates a Record for each **project** on the account. - -#### Prerequisites - -**Two credentials — neither works on its own:** - -* Your **Client ID**, which forms part of every request path. -* Your **API Key**, sent as a request header. - -Both are found under **SOOS \> Integrations**. - -#### Connector Mappings - -1. Enter `https://api.soos.io/api/` in the **Location** field. -2. Enter your SOOS **Client ID**. -3. Enter your SOOS **API Key**. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each project becomes a Record, carrying its scanned dependencies' vulnerabilities. - -## **Sysdig Secure** - -The Sysdig Secure connector imports **container / CNAPP vulnerability findings** from Sysdig Secure's vulnerability management API. It syncs the whole account across the configured scope(s) and creates a DefectDojo product for each scanned asset grouping. - -#### Prerequisites - -A Sysdig Secure **API token**: in Sysdig Secure, go to **Settings \> Sysdig Secure API Token** and copy the token. You also need your Sysdig **region URL** (for example `https://us2.app.sysdig.com`, `https://eu1.app.sysdig.com`, or your on\-premises host). - -#### Connector Mappings - -1. Enter your Sysdig region/base URL in the **Location** field. -2. Enter the API token in the **Secret** field. -3. Optionally set **Scopes** — a comma\-separated list of `runtime`, `registry`, and/or `pipeline` (leave blank for `runtime`, the deployed\-workload scope). -4. Optionally set **Runtime Asset Grouping** — how runtime results map to Assets: `cluster`, `namespace`, `workload`, or `image` (leave blank for `namespace`). Registry and pipeline results always group by image repository. -5. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each asset grouping becomes a Record. For each scan result the connector imports every vulnerable package as a finding. **Runtime** findings (deployed workloads) are recorded as dynamic findings and tagged with their Kubernetes cluster / namespace / workload / container context; **registry** and **pipeline** findings are recorded as static image\-scan findings. Sysdig's `NEGLIGIBLE` severity maps to Info. - -## **Tenable.io** - -The Tenable connector uses the **Tenable.io** REST API to fetch data. Scans are pulled from the Tenable VM `/scans` endpoint. - -On\-premise Tenable Connectors are not available at this time. - -#### **Connector Mappings** - -1. Enter in the Location field. -2. Enter a valid **API key** in the Secret field. - -See [Tenable's API Documentation](https://docs.tenable.com/vulnerability-management/Content/Settings/my-account/GenerateAPIKey.htm) for more info. - -## **Tenable Web App Scanning** - -The Tenable Web App Scanning connector imports **web application (DAST) findings** from Tenable Web App Scanning. It is a separate connector from Tenable (Vulnerability Management): the two Assets cover different assets and are configured independently, so you can use either or both. - -DefectDojo creates a Record for each **scanned web application**. Applications are discovered from your Web App Scanning scan configurations; a configuration that has never run does not produce a Record until its first scan completes. When more than one configuration scans the same application, they share a single Record. - -#### Prerequisites - -Tenable **API keys** (an access key and a secret key) for a user with Web App Scanning permissions. In Tenable, go to **My Account \> API Keys** to generate them, and confirm the user can view the scans you want to import — keys limited to Vulnerability Management cannot read Web App Scanning data. - -On\-premise Tenable connectors are not available at this time. - -#### Connector Mappings - -1. Enter in the **Location** field. -2. Enter your **Access Key** and **Secret Key**. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Findings are imported with the severity Tenable reports for your account, including any severity your team has recast. Each finding carries the affected URL as an endpoint, the request parameter and payload that triggered it, and Tenable's proof and output as steps to reproduce, along with CWE, CVE, CVSS and EPSS values where the detecting plugin supplies them. - -Only findings that are currently open or reopened are imported. A finding Tenable has marked fixed is closed in DefectDojo on the next sync. - -## **TruffleHog** - -The TruffleHog connector imports **secret detections** from TruffleHog Enterprise. DefectDojo creates a Record for each configured **scan source** — a repository, bucket or registry — and that source's detections become its findings. No per\-source configuration is required. - -**Secret handling.** Findings carry only the **redacted** secret as TruffleHog reports it. Raw secret material is read solely to compute the deduplication digest, and never reaches a finding field, a log line, or an error message. Response bodies are never logged, even with debug logging enabled, so a debug session cannot leak secret material. - -**Not to be confused with `trufflehog3`.** The separate `trufflehog3` parser in the supported tools list is a different tool with a different report format — it is not this connector's file equivalent. - -#### Prerequisites - -A TruffleHog **Enterprise** API token, sent as a bearer token. - -#### Connector Mappings - -1. Enter your TruffleHog Enterprise API host in the **Location** field. -2. Enter the Enterprise API token in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each configured scan source becomes a Record. - -## **Trustwave Fusion** - -The Trustwave Fusion connector imports findings from the Trustwave Fusion platform. DefectDojo creates a Record for each **asset**, derived from the findings themselves. - -#### Prerequisites - -A Trustwave Fusion **API token** for the tenant whose findings you want to import. - -#### Connector Mappings - -1. Enter your Trustwave Fusion API URL in the **Location** field. -2. Enter the API token in the **API Token** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each asset referenced by your findings becomes a Record, grouped by the asset the finding was reported against. - -## **Uptycs** - -The Uptycs connector imports **vulnerability findings** from your Uptycs tenant. DefectDojo creates a Record for each **asset group**. - -#### Prerequisites - -Three values from Uptycs: - -* Your **customer ID**, shown in the API key file. -* An **API key ID**, from **Configuration \> User \> API Keys**. -* The matching **API secret**, which DefectDojo uses to sign a per\-request token. It is never logged. - -#### Connector Mappings - -1. Enter your Uptycs stack URL in the **Location** field — for example `https://your-stack.uptycs.io`. -2. Enter the customer ID in the **Customer ID** field. -3. Enter the API key ID in the **Key** field. -4. Enter the API secret in the **Secret** field. -5. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each asset group becomes a Record. Uptycs vulnerabilities are read through its osquery-style query engine, so the imported finding set is whatever that query returns for your tenant. - -## **Vanta** - -The Vanta connector imports **failing compliance tests** from Vanta. DefectDojo creates a Record for each Vanta **integration**, plus an organization\-wide catch\-all for tests that belong to none. - -#### Prerequisites - -An OAuth **client ID and secret** from Vanta. Create them under **Settings \> Developer Console** as a **"Manage Vanta"** app — other app types will not have the access this connector needs. - -#### Connector Mappings - -1. Enter your Vanta API URL in the **Location** field. -2. Enter the OAuth client ID in the **Client ID** field. -3. Enter the client secret in the **Client Secret** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each **failing resource of a failing test** becomes a finding, grouped under the integration the test belongs to — so a single failing control across many resources produces a finding per resource. - -## **Veracode** - -The Veracode connector imports application findings from the Veracode platform, split by scan type into **SAST**, **DAST**, **SCA**, and **Manual** finding types. DefectDojo creates a Record for each Veracode **application**. - -#### Prerequisites - -Generate a Veracode **API credential** for an account that can see the applications you want to import: in the Veracode Platform, open your account menu \> **API Credentials** and select **Generate API Credentials** (see [Managing Veracode API credentials](https://docs.veracode.com/r/c_api_credentials3)). Copy both the **API ID** and the **API Secret Key** — the secret is shown only once. - -#### Connector Mappings - -1. Enter the Veracode API base URL in the **Location** field: `https://api.veracode.com` (commercial region), `https://api.veracode.eu` (European region), or `https://api.veracode.us` (US federal region). -2. Enter the API ID in the **API ID** field. -3. Enter the API secret key in the **Secret** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each Veracode application becomes a Record. Only **open** findings are imported, so reimport closes findings Veracode reports as resolved. - -## **Vulnerability Manager Plus** - -The Vulnerability Manager Plus connector imports **endpoint vulnerability findings** from ManageEngine Vulnerability Manager Plus. DefectDojo creates a Record for each **host**. - -#### Prerequisites - -A Vulnerability Manager Plus **API token**, from **Admin \> API key generation**. It is never logged. - -#### Connector Mappings - -1. Enter your Vulnerability Manager Plus server URL in the **Location** field. -2. Enter the API token in the **Auth Token** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each host becomes a Record, carrying the vulnerabilities detected on it. - -## **Wallarm** - -The Wallarm connector imports **API security findings** from Wallarm. DefectDojo creates a Record for each **affected domain**. - -#### Prerequisites - -A Wallarm **API token**, from **Console \> Settings \> API tokens**. A **Read Only** role is sufficient, and the token is never logged. - -#### Connector Mappings - -1. Enter your Wallarm cloud URL in the **Location** field — `https://api.wallarm.com` for the EU cloud or `https://us1.api.wallarm.com` for the US cloud. -2. Enter the API token in the **API Token** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each affected domain becomes a Record, carrying the account's API security vulnerabilities that affect it. - -## **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. - -## **WebInspect Enterprise** - -The WebInspect Enterprise connector imports **DAST findings** from a WebInspect Enterprise (WIE) server. DefectDojo creates a Record for each **application** the token can see. - -#### Prerequisites - -A WebInspect Enterprise **API token**. WIE accepts a Fortify\-style API token, and it is never logged. - -#### Connector Mappings - -1. Enter your WebInspect Enterprise server URL in the **Location** field. -2. Enter the API token in the **Secret** field. -3. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each application becomes a Record, and its findings come from that application's **most recent completed scan**. - -## 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. - -The service account must meet all of the following requirements. A service account that misses one of them can still authenticate successfully but will import nothing: - -* **Type**: Custom Integration (GraphQL API). -* **API scopes**: at minimum `read:projects`, `read:issues`, and `read:vulnerabilities`. -* **Project visibility**: the service account must be scoped to every Wiz Project you want imported (or to all Projects). The connector discovers your Wiz Projects first and then pulls each Project's findings — an account that can read issues but has no Project visibility discovers zero Projects, so there is nothing to import and no error is reported by either side. - -#### **Connector Mappings** - -1. Enter your Wiz Client ID in the Client ID field. -2. Enter the Wiz Client Secret in the Secret field. - -## **YesWeHack** - -The YesWeHack connector uses the YesWeHack REST API to import reports from your bug bounty and vulnerability disclosure programs. DefectDojo creates a Record for each program your token can access and imports its reports as findings. - -#### Prerequisites - -You will need a YesWeHack **Personal Access Token (PAT)**. Read access to your programs is sufficient. Some accounts require TOTP/MFA when creating a token; once created, the token value itself is what the connector uses. - -1. In YesWeHack, open your account settings and go to **API / Personal Access Tokens**. -2. Create a token and copy its value. It is only shown once. - -#### Connector Mappings - -1. Enter `https://api.yeswehack.com/` in the **Location** field. -2. Enter your Personal Access Token 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 program your token can access, and imports each report as a finding. The finding's severity is taken from the report's CVSS rating (falling back to the triage priority), and its status reflects the report's workflow state — for example, resolved reports are imported as mitigated, and reports marked invalid or out of scope are imported as inactive. - -## **Zimperium** - -The Zimperium connector imports **mobile application security findings** from Zimperium zScan. DefectDojo creates a Record for each zScan **mobile app**. - -#### Prerequisites - -A zScan **client ID and secret**, issued from **zConsole \> Account Management \> Authorizations** (the `ZSCAN_CLIENT_ID` and `ZSCAN_CLIENT_SECRET` values). DefectDojo exchanges them for a bearer token on each Sync; the secret is never logged. - -#### Connector Mappings - -1. Enter your **zConsole** host in the **Location** field. -2. Enter the client ID in the **Client ID** field. -3. Enter the client secret in the **Client Secret** field. -4. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each zScan mobile app becomes a Record, carrying the findings of that app's **latest completed assessment**. - -## **Zora** - -The Zora connector imports **Kubernetes cluster findings** from Zora. DefectDojo creates a Record for each **scanned cluster**. - -Zora is a multi\-cluster manager, so DefectDojo reads the Zora resources in your **management cluster** and maps each cluster Zora scans to its own Record. - -#### Prerequisites - -A **kubeconfig** granting read access to the **management cluster** where the Zora Operator writes its results. - -Unlike most connectors, this one does not use an API token — Zora exposes no REST API, and its results live only as Kubernetes resources, so DefectDojo reads them directly from the cluster. - -#### Connector Mappings - -1. Provide the kubeconfig for the management cluster. -2. Optionally, set a **Minimum Severity** to limit which findings are imported. - -Each scanned cluster becomes a Record, carrying the issues and vulnerability reports Zora recorded for it. diff --git a/docs/content/releases/pro/changelog.md b/docs/content/releases/pro/changelog.md index 71436da773c..95bc4059343 100644 --- a/docs/content/releases/pro/changelog.md +++ b/docs/content/releases/pro/changelog.md @@ -425,7 +425,7 @@ Additional features: ### Mar 5, 2026: v2.56.0 * **(API)** Restricted Note Types are now accessible via the API. -* **(Connectors)** Added **IriusRisk** connector: see [tools reference](/connectors/upstream/toolreference/) for configuration instructions. +* **(Connectors)** Added **IriusRisk** connector: see [tools reference](/connectors/toolreference/upstream/) for configuration instructions. * **(SAML)** SAML settings now support optional group attributes, allowing configurations that don't provide group mappings to work without errors. * **(SMTP)** Fixed an issue where DefectDojo would attempt SMTP authentication even when no credentials were configured, which could cause email delivery failures. * **(Universal Parser)** The Universal Parser now falls back to `clevercsv` for non-standard or malformed CSV files, improving compatibility with edge-case scanner outputs. @@ -791,7 +791,7 @@ Hotfix release - no significant feature changes. #### Apr 14, 2025: v2.45.1 -- **(Connectors)** Added a Connector for Wiz: see [tools reference](/connectors/upstream/toolreference/) for configuration instructions. +- **(Connectors)** Added a Connector for Wiz: see [tools reference](/connectors/toolreference/upstream/) for configuration instructions. #### Apr 7, 2025: v2.45.0 diff --git a/docs/content/supported_tools/parsers/api/blackduck.md b/docs/content/supported_tools/parsers/api/blackduck.md index 8ab0b240543..b306db27bfc 100644 --- a/docs/content/supported_tools/parsers/api/blackduck.md +++ b/docs/content/supported_tools/parsers/api/blackduck.md @@ -6,7 +6,7 @@ toc_hide: true > > The **BlackDuck API** pull parser, and the **Tool Configuration** setup described below, are deprecated as of **3.2.0** and will be **removed in 3.5.0 (November 2026)**. See the [3.2 upgrade notes](/releases/os_upgrading/3.2/). > -> **Migrate to:** the [Black Duck connector](/connectors/upstream/toolreference/#black-duck) (DefectDojo Pro), or import a Black Duck report as a [file](../../file/blackduck) — file import is not affected by this deprecation. +> **Migrate to:** the [Black Duck connector](/connectors/toolreference/black_duck/) (DefectDojo Pro), or import a Black Duck report as a [file](../../file/blackduck) — file import is not affected by this deprecation. All parsers which using API have common basic configuration step but with different values. Please, [read these steps](../) at first. diff --git a/docs/content/supported_tools/parsers/api/bugcrowd.md b/docs/content/supported_tools/parsers/api/bugcrowd.md index 5e5e9667210..c333edfc40a 100644 --- a/docs/content/supported_tools/parsers/api/bugcrowd.md +++ b/docs/content/supported_tools/parsers/api/bugcrowd.md @@ -8,7 +8,7 @@ aliases: > > The **Bugcrowd API Import** pull parser, and the **Tool Configuration** setup described below, are deprecated as of **3.2.0** and will be **removed in 3.5.0 (November 2026)**. See the [3.2 upgrade notes](/releases/os_upgrading/3.2/). > -> **Migrate to:** the [Bugcrowd connector](/connectors/upstream/toolreference/#bugcrowd) (DefectDojo Pro), or import a Bugcrowd report as a [file](../../file/bugcrowd) — file import is not affected by this deprecation. +> **Migrate to:** the [Bugcrowd connector](/connectors/toolreference/bugcrowd/) (DefectDojo Pro), or import a Bugcrowd report as a [file](../../file/bugcrowd) — file import is not affected by this deprecation. All parsers which using API have common basic configuration step but with different values. Please, [read these steps](../) at first. diff --git a/docs/content/supported_tools/parsers/api/cobalt.md b/docs/content/supported_tools/parsers/api/cobalt.md index b2805b9395b..8b8d0b67eae 100644 --- a/docs/content/supported_tools/parsers/api/cobalt.md +++ b/docs/content/supported_tools/parsers/api/cobalt.md @@ -7,7 +7,7 @@ toc_hide: true > > The **Cobalt.io API Import** pull parser, and the **Tool Configuration** setup described below, are deprecated as of **3.2.0** and will be **removed in 3.5.0 (November 2026)**. See the [3.2 upgrade notes](/releases/os_upgrading/3.2/). > -> **Migrate to:** the [Cobalt.io connector](/connectors/upstream/toolreference/#cobaltio) (DefectDojo Pro), or import a Cobalt.io report as a [file](../../file/cobalt) — file import is not affected by this deprecation. +> **Migrate to:** the [Cobalt.io connector](/connectors/toolreference/cobalt_io/) (DefectDojo Pro), or import a Cobalt.io report as a [file](../../file/cobalt) — file import is not affected by this deprecation. All parsers which using API have common basic configuration step but with different values. Please, [read these steps](../) at first. diff --git a/docs/content/supported_tools/parsers/api/edgescan.md b/docs/content/supported_tools/parsers/api/edgescan.md index 255219bf48f..477e2b48c4f 100644 --- a/docs/content/supported_tools/parsers/api/edgescan.md +++ b/docs/content/supported_tools/parsers/api/edgescan.md @@ -6,7 +6,7 @@ toc_hide: true > > The **Edgescan** API pull path described below, and the **Tool Configuration** it depends on, are deprecated as of **3.2.0** and will be **removed in 3.5.0 (November 2026)**. See the [3.2 upgrade notes](/releases/os_upgrading/3.2/). > -> **Migrate to:** the [Edgescan connector](/connectors/upstream/toolreference/#edgescan) (DefectDojo Pro), or import Edgescan results as a [JSON file](../../file/edgescan) — file import is not affected by this deprecation. +> **Migrate to:** the [Edgescan connector](/connectors/toolreference/edgescan/) (DefectDojo Pro), or import Edgescan results as a [JSON file](../../file/edgescan) — file import is not affected by this deprecation. Import Edgescan vulnerabilities by API or [JSON file](../../file/edgescan). diff --git a/docs/content/supported_tools/parsers/api/sonarqube.md b/docs/content/supported_tools/parsers/api/sonarqube.md index a7005ebeb91..2f776ab1e5d 100644 --- a/docs/content/supported_tools/parsers/api/sonarqube.md +++ b/docs/content/supported_tools/parsers/api/sonarqube.md @@ -8,7 +8,7 @@ aliases: > > The **SonarQube API Import** pull parser, and the **Tool Configuration** setup described below, are deprecated as of **3.2.0** and will be **removed in 3.5.0 (November 2026)**. See the [3.2 upgrade notes](/releases/os_upgrading/3.2/). > -> **Migrate to:** the [SonarQube connector](/connectors/upstream/toolreference/#sonarqube) (DefectDojo Pro), or import a SonarQube report as a [file](../../file/sonarqube) — file import is not affected by this deprecation. +> **Migrate to:** the [SonarQube connector](/connectors/toolreference/sonarqube/) (DefectDojo Pro), or import a SonarQube report as a [file](../../file/sonarqube) — file import is not affected by this deprecation. All parsers that use API pull have common basic configuration steps, but with different values. Please, [read these steps](../) first.