diff --git a/docs/assets/images/oidc_pro.png b/docs/assets/images/oidc_pro.png new file mode 100644 index 00000000000..80a2dfdba09 Binary files /dev/null and b/docs/assets/images/oidc_pro.png differ diff --git a/docs/content/en/connecting_your_tools/import_scan_files/import_scan_ui.md b/docs/content/en/connecting_your_tools/import_scan_files/import_scan_ui.md index 342d1dcc2c6..dac6195a6d3 100644 --- a/docs/content/en/connecting_your_tools/import_scan_files/import_scan_ui.md +++ b/docs/content/en/connecting_your_tools/import_scan_files/import_scan_ui.md @@ -65,9 +65,27 @@ This option is especially relevant when using the API to import data. If uploadi * **Source Code Management URI** can also be specified. This form option must be a valid URI. * **Group By:** if you want to create Finding Groups out of this File, you can specify the grouping method here. -### Next Steps +### Triage-less scanners: Do Not Reactivate field -Once your upload has completed, you should be redirected to the Test Page which contains the Findings found in the scan file. You can start working with those results right away, but feel free to consult the following articles: +Some scanners might not include triage information in their reports (e.g. tfsec). They simply scan code or dependencies, flag issues, and return everything, regardless of whether a vulnerability has already been triaged or not. -* Learn how to organize your Product Hierarchy to manage different contexts for your Findings and Tests: [Product Hierarchy Overview](/en/working_with_findings/organizing_engagements_tests/product_hierarchy/). -* Learn how to extend a Test with additional Findings and reports: [Reimport Guide](../using_reimport/) \ No newline at end of file +To handle this case, DefectDojo also includes a "Do not reactivate" checkbox in uploading reports (also in the reimport API), so you can use DefectDojo as the source of truth for triage, instead of reactivating your triaged Findings on each import / reimport. + +### Using the Scan Completion Date (API: `scan_date`) field + +DefectDojo offers a plethora of supported scanner reports, but not all of them contain the +information most important to a user. The `scan_date` field is a flexible smart feature that +allows users to set the completion date of the a given scan report, and have it propagate +down to all the findings imported. This field is **not** mandatory, but the default value for +this field is the date of import (whenever the request is processed and a successful response is returned). + +Here are the following use cases for using this field: + +1. The report **does not** set the date, and `scan_date` is **not** set at import + - Finding date will be the default value of `scan_date` +2. The report **sets** the date, and the `scan_date` is **not** set at import + - Finding date will be whatever the report sets +3. The report **does not** set the date, and the `scan_date` is **set** at import + - Finding date will be whatever the user set for `scan_date` +4. The report **sets** the date, and the `scan_date` is **set** at import + - Finding date will be whatever the user set for `scan_date` diff --git a/docs/content/en/customize_dojo/user_management/configure_sso.md b/docs/content/en/customize_dojo/user_management/configure_sso.md index c0a830e6f6f..45bd70c3279 100644 --- a/docs/content/en/customize_dojo/user_management/configure_sso.md +++ b/docs/content/en/customize_dojo/user_management/configure_sso.md @@ -16,6 +16,8 @@ Users can connect to DefectDojo with a Username and Password, but if you prefer, All of these methods can only be configured by a Superuser in DefectDojo. DefectDojo Pro users can quickly set up SSO through their system settings, while Open Source users will need to configure these settings on the back-end by setting an environment variable within Docker. This article covers both methods of configuration. +**NOTE: DefectDojo Pro users will all need to add the IP addresses of SAML or SSO services to their Firewall whitelist. See [Firewall Rules](/en/cloud_management/using-cloud-manager/#changing-your-firewall-settings) for more information.** + ## Disable username / password use You may wish to disable traditional username/password login on your instance. @@ -513,6 +515,59 @@ GET parameter starts with `http://` instead of 2. Restart DefectDojo, and 'Login With Okta' should appear on the login screen. +## OIDC (OpenID Connect) + +Adding OIDC gives you the option to authenticate users using a generic OIDC provider. + +### Pro Configuration + +In DefectDojo Pro, OIDC can be configured from the OIDC settings page: + +![image](images/oidc_pro.png) + +Fill out the form as follows + +1. Enter your OIDC endpoint in the Endpoint field. This is the base URL of your OIDC instance (you do not need to include `/.well-known/open-id-configuration/`) + +2. Enter your OIDC Client ID in the Client ID field. + +3. Enter the OIDC Client Secret in the Client Secret field. + +4. Check the box for Enable OIDC. + +Once the form has been submitted, Log In With OIDC should be added as an option to the DefectDojo login page. + + +### Open-Source + +The minimum configuration requires you to set the following environment variables: + + {{< highlight python >}} + DD_SOCIAL_AUTH_OIDC_AUTH_ENABLED=True, + DD_SOCIAL_AUTH_OIDC_OIDC_ENDPOINT=(str, 'https://example.com'), + DD_SOCIAL_AUTH_OIDC_KEY=(str, 'YOUR_CLIENT_ID'), + DD_SOCIAL_AUTH_OIDC_SECRET=(str, 'YOUR_CLIENT_SECRET') + {{< /highlight >}} + +The rest of the OIDC configuration will be auto-detected by fetching data from: + - /.well-known/open-id-configuration/ + +You can also optionally set the following variables: + + {{< highlight python >}} + DD_SOCIAL_AUTH_OIDC_ID_KEY=(str, ''), #the key associated with the OIDC user IDs + DD_SOCIAL_AUTH_OIDC_USERNAME_KEY=(str, ''), #the key associated with the OIDC usernames + DD_SOCIAL_AUTH_OIDC_WHITELISTED_DOMAINS=(list, ['']), #list of domains allowed for login + DD_SOCIAL_AUTH_OIDC_JWT_ALGORITHMS=(list, ["RS256","HS256"]), + DD_SOCIAL_AUTH_OIDC_ID_TOKEN_ISSUER=(str, ''), + DD_SOCIAL_AUTH_OIDC_ACCESS_TOKEN_URL=(str, ''), + DD_SOCIAL_AUTH_OIDC_AUTHORIZATION_URL=(str, ''), + DD_SOCIAL_AUTH_OIDC_USERINFO_URL=(str, ''), + DD_SOCIAL_AUTH_OIDC_JWKS_URI=(str, ''), + {{< /highlight >}} + +Once these variables have been set, restart DefectDojo. Log In With OIDC should now be added to the DefectDojo login page. + ## SAML Configuration DefectDojo Pro users can follow this guide to set up a SAML configuration using the DefectDojo UI. Open-Source users can set up SAML via environment variables, using the following [guide](./#open-source-saml). diff --git a/docs/content/en/open_source/archived_docs/integrations/_index.md b/docs/content/en/open_source/archived_docs/integrations/_index.md deleted file mode 100644 index 38a96445b03..00000000000 --- a/docs/content/en/open_source/archived_docs/integrations/_index.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: "Integrations" -description: "A lot of integrations help to fit DefectDojo in your environment" -weight: 3 -toc: true -sidebar: - collapsed: true -seo: - title: "" # custom title (optional) - description: "" # custom description (recommended) - canonical: "" # custom canonical URL (optional) - robots: "" # custom robot tags (optional) ---- diff --git a/docs/content/en/open_source/archived_docs/integrations/social-authentication.md b/docs/content/en/open_source/archived_docs/integrations/social-authentication.md deleted file mode 100644 index 91ebd89d4e1..00000000000 --- a/docs/content/en/open_source/archived_docs/integrations/social-authentication.md +++ /dev/null @@ -1,519 +0,0 @@ ---- -title: "Authentication via OAuth2/SAML2" -description: "OAuth2/SAML2 let users authenticate against enterprise directories." -draft: false -weight: 3 -exclude_search: true ---- - -## Auth0 - -In the same way as with other identity providers, it's now possible to -leverage Auth0 to authenticate users on DefectDojo. - -1. Inside your Auth0 dashboard create a new application (Applications / - Create Application / Single Page Web Application). -2. On the new application set the following fields: - - Name: "Defectdojo" - - Allowed Callback URLs: - **https://the_hostname_you_have_dojo_deployed:your_server_port/complete/auth0/** -3. Copy the following info from the application: - - Domain - - Client ID - - Client Secret -4. Now, edit the settings (see [Configuration](../../open_source/installation/configuration)) with the following - information: - - {{< highlight python >}} - DD_SOCIAL_AUTH_AUTH0_OAUTH2_ENABLED=True - DD_SOCIAL_AUTH_AUTH0_KEY=(str, '**YOUR_CLIENT_ID_FROM_STEP_ABOVE**'), - DD_SOCIAL_AUTH_AUTH0_SECRET=(str,'**YOUR_CLIENT_SECRET_FROM_STEP_ABOVE**'), - DD_SOCIAL_AUTH_AUTH0_DOMAIN=(str, '**YOUR_AUTH0_DOMAIN_FROM_STEP_ABOVE**'), - {{< /highlight >}} - -5. Restart DefectDojo, and you should now see a **Login with Auth0** - button on the login page. - -## Google - -New to DefectDojo, a Google account can now be used for Authentication, -Authorization, and a DefectDojo user. Upon login with a Google account, -a new user will be created if one does not already exist. The criteria -for determining whether a user exists is based on the users username. In -the event a new user is created, the username is that of the Google -address without the domain. Once created, the user creation process will -not happen again as the user is recalled by its username, and logged in. -In order to make the magic happen, a Google authentication server needs -to be created. Closely follow the steps below to guarantee success. - -1. Navigate to the following address and either create a new account, - or login with an existing one: [Google Developers - Console](https://console.developers.google.com) -2. Once logged in, find the key shaped button labeled **Credentials** - on the left side of the screen. Click **Create Credentials**, and - choose **OAuth Client ID**: - - ![image](images/google_1.png) - -3. Select **Web Applications**, and provide a descriptive name for the - client. - - ![image](images/google_2.png) - -4. Add the pictured URLs in the **Authorized Redirect URLs** section. - This part is very important. If there are any mistakes here, the - authentication client will not authorize the request, and deny - access. -5. Once all URLs are added, finish by clicking **Create** - -6. Now with the authentication client created, the **Client ID** and - **Client Secret Key** need to be copied over to the settings. - Click the newly created client and copy the values: - - ![image](images/google_3.png) - -7. Edit the settings (see [Configuration](../../open_source/installation/configuration) with the following - information: - - {{< highlight python >}} - DD_SOCIAL_AUTH_GOOGLE_OAUTH2_ENABLED=True, - DD_SOCIAL_AUTH_GOOGLE_OAUTH2_KEY=(str, '**YOUR_CLIENT_ID_FROM_STEP_ABOVE**'), - DD_SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET=(str, '**YOUR_CLIENT_SECRET_FROM_STEP_ABOVE**'), - {{< /highlight >}} - - To authorize users you will need to set the following: - - {{< highlight python >}} - DD_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_DOMAINS = ['example.com', 'example.org'] - {{< /highlight >}} - - As an environment variable: - - {{< highlight python >}} - DD_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_DOMAINS = example.com,example.org - {{< /highlight >}} - - or - - {{< highlight python >}} - DD_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_EMAILS = [''] - {{< /highlight >}} - - As an environment variable: - - {{< highlight python >}} - DD_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_EMAILS = email@example.com,email2@example.com - {{< /highlight >}} - -## OKTA - -In a similar fashion to that of Google, using OKTA as a OAuth2 provider -carries the same attributes and a similar procedure. Follow along below. - -1. Navigate to the following address and either create a new account, - or login with an existing one: [OKTA Account - Creation](https://www.okta.com/developer/signup/) -2. Once logged in, enter the **Applications** and click **Add - Application**: - - ![image](images/okta_1.png) - -3. Select **Web Applications**. - - ![image](images/okta_2.png) - -4. Add the pictured URLs in the **Login Redirect URLs** section. This - part is very important. If there are any mistakes here, the - authentication client will not authorize the request, and deny - access. Check the **Implicit** box as well. - - ![image](images/okta_3.png) - -5. Once all URLs are added, finish by clicking **Done**. - -6. Return to the **Dashboard** to find the **Org-URL**. Note this value - as it will be important in the settings file. - - ![image](images/okta_4.png) - -7. Now, with the authentication client created, the **Client ID** and - **Client Secret** Key need to be copied over to the settings. - Click the newly created client and copy the values: - - ![image](images/okta_5.png) - -8. Edit the settings (see [Configuration](../../open_source/installation/configuration)) with the following - information: - - {{< highlight python >}} - DD_SOCIAL_AUTH_OKTA_OAUTH2_ENABLED=True, - DD_SOCIAL_AUTH_OKTA_OAUTH2_KEY=(str, '**YOUR_CLIENT_ID_FROM_STEP_ABOVE**'), - DD_SOCIAL_AUTH_OKTA_OAUTH2_SECRET=(str, '**YOUR_CLIENT_SECRET_FROM_STEP_ABOVE**'), - DD_SOCIAL_AUTH_OKTA_OAUTH2_API_URL=(str, 'https://{your-org-url}/oauth2'), - {{< /highlight >}} - -If during the login process you get the following error: *The -'redirect_uri' parameter must be an absolute URI that is whitelisted -in the client app settings.* and the `redirect_uri` HTTP -GET parameter starts with `http://` instead of -`https://` you need to add -`SOCIAL_AUTH_REDIRECT_IS_HTTPS = True` in the settings. - -## Azure Active Directory -### Azure AD Configuration -You can now use your corporate Azure Active Directory to authenticate -users to Defect Dojo. Users will be using your corporate Azure AD -account (A.K.A. Office 365 identity) to authenticate via OAuth, and all -the conditional access rules and benefits from Azure Active Directory -will also apply to the Defect Dojo Authentication. Once the user signs -in, it will try to match the UPN of the user to an existing e-mail from -a user in Defect Dojo, and if no match is found, a new user will be -created in Defect Dojo, associated with the unique id/value of the user -provided by your Azure AD tenant. Then, you can assign roles to this -user, such as 'superuser'. - -1. Navigate to the following address and follow instructions to create - a new app registration - - - - -2. Once you register an app, take note of the following information: - - - **Application (client) ID** - - **Directory (tenant) ID** - - Under Certificates & Secrets, create a new **Client Secret** - -3. Under Authentication > Redirect URIs, add a *WEB* type of uri where - the redirect points to - - - - - **OR** - - **https://the_hostname_you_have_dojo_deployed:your_server_port/complete/azuread-tenant-oauth2/** - -4. Edit the settings (see [Configuration](../../open_source/installation/configuration)) with the following - information: - - {{< highlight python >}} - DD_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY=(str, 'YOUR_APPLICATION_ID_FROM_STEP_ABOVE'), - DD_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET=(str, 'YOUR_CLIENT_SECRET_FROM_STEP_ABOVE'), - DD_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID=(str, 'YOUR_DIRECTORY_ID_FROM_STEP_ABOVE'), - DD_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_ENABLED = True - {{< /highlight >}} - -5. Restart your Dojo, and you should now see a **Login with Azure AD** - button on the login page which should *magically* work - -### Automatic Import of User-Groups -To import groups from Azure AD users, the following environment variable needs to be set: - - {{< highlight python >}} - DD_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_GET_GROUPS=True - {{< /highlight >}} - -This will ensure the user is added to all the groups found in the Azure AD Token. Any missing groups will be created in DefectDojo (unless filtered). This group synchronization allows for product access via groups to limit the products a user can interact with. - -The Azure AD token returned by Azure will also need to be configured to include group IDs. Without this step, the -token will not contain any notion of a group, and the mapping process will report that the current user is not a member of any -groups. To update the format of the token, add a group claim that applies to whatever group type you are using. -If unsure of what type that is, select `All Groups`. Do not activate `Emit groups as role claims` within the Azure AD -"Token configuration" page. - -Application API permissions need to be updated with the `Group.Read.All` permission so that groups can be read on behalf -of the user that has successfully signed in. - -To limit the amount of groups imported from Azure AD, a regular expression can be used as the following: - - {{< highlight python >}} - DD_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_GROUPS_FILTER='^team-.*' # or 'teamA|teamB|groupC' - {{< /highlight >}} - -### Automatic Cleanup of User-Groups - -To prevent authorization creep, old Azure AD groups a user is not having anymore can be deleted with the following environment parameter: - - {{< highlight python >}} - DD_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_CLEANUP_GROUPS=True - {{< /highlight >}} - -When a user is removed from a given group in Azure AD, they will also be removed from the corresponding group in DefectDojo. -If there is a group in DefectDojo, that no longer has any members, it will be left as is for record purposes. - -## Gitlab - -In a similar fashion to that of Google and OKTA, using Gitlab as a -OAuth2 provider carries the same attributes and a similar procedure. -Follow along below. - -1. Navigate to your Gitlab settings page and got to the Applications - section - - - - - **OR** - - **https://the_hostname_you_have_gitlab_deployed:your_gitlab_port/profile/applications** - -2. Choose a name for your application -3. For the Redirect URI, enter the DefectDojo URL with the following - format - - - **https://the_hostname_you_have_dojo_deployed:your_server_port/complete/gitlab/** - -4. Edit the settings (see [Configuration](../../open_source/installation/configuration)) with the following - information: - - {{< highlight python >}} - DD_SOCIAL_AUTH_GITLAB_KEY=(str, 'YOUR_APPLICATION_ID_FROM_STEP_ABOVE'), - DD_SOCIAL_AUTH_GITLAB_SECRET=(str, 'YOUR_SECRET_FROM_STEP_ABOVE'), - DD_SOCIAL_AUTH_GITLAB_API_URL=(str, 'https://gitlab.com'), - DD_SOCIAL_AUTH_GITLAB_OAUTH2_ENABLED = True - {{< /highlight >}} - - Additionally, if you want to import your Gitlab projects as DefectDojo - products, add the following line to your settings: - - {{< highlight python >}} - DD_SOCIAL_AUTH_GITLAB_PROJECT_AUTO_IMPORT = True - {{< /highlight >}} - - **Important:** if you enable this setting on already working instance with gitlab integrations, it will require new grant "read_repository" by user - -5. Restart DefectDojo, and you should now see a **Login with Gitlab** - button on the login page. - -## Keycloak -There is also an option to use Keycloak as OAuth2 provider in order to authenticate users to Defect Dojo, also by using -the social-auth plugin. - -Here are suggestion on how to configure Keycloak and DefectDojo: - -### Configure Keycloak -(assuming you already have an existing realm, otherwise create one) -1. Navigate to your keycloak realm and add a new client of type openid-connect. Choose a name for the client id and use this value below for DD_SOCIAL_AUTH_KEYCLOAK_KEY). -2. In the client settings: - * Set `access type` to `confidential` - * Under `valid Redirect URIs`, add the URI to your defect dojo installation, e.g. 'https:///*' - * Under `web origins`, add the same (or '+') - * Under `Fine grained openID connect configuration` -> `user info signed response algorithm`: set to `RS256` - * Under `Fine grained openID connect configuration` -> `request object signature algorithm`: set to `RS256` - * -> save these settings in keycloak (hit save button) -3. Under `Scope` -> `Full Scope Allowed` set to `off` -4. Under `mappers` -> add a custom mapper here: - * Name: `aud` - * Mapper type: `audience` - * Included audience: select your client/client-id here - * Add ID to token: `off` - * Add access to token: `on` -5. Under `credentials`: copy the secret (and use as DD_SOCIAL_AUTH_KEYCLOAK_SECRET below) -6. In your realm settings -> keys: copy the "Public key" (signing key) (use for DD_SOCIAL_AUTH_KEYCLOAK_PUBLIC_KEY below) -7. In your realm settings -> general -> endpoints: look into openId endpoint configuration - and look up your authorization and token endpoint (use them below) - -### Configure OIDC -Provides the option to authenticate users using a generic OIDC provider. - -The minimum configuration requires: - - {{< highlight python >}} - DD_SOCIAL_AUTH_OIDC_AUTH_ENABLED=True, - DD_SOCIAL_AUTH_OIDC_OIDC_ENDPOINT=(str, 'https://example.com'), - DD_SOCIAL_AUTH_OIDC_KEY=(str, 'YOUR_CLIENT_ID'), - DD_SOCIAL_AUTH_OIDC_SECRET=(str, 'YOUR_CLIENT_SECRET') - {{< /highlight >}} - -The rest of the OIDC configuration will be auto-detected by fetching data from: - - /.well-known/open-id-configuration/ - -You can also optionally set the following: - - {{< highlight python >}} - DD_SOCIAL_AUTH_OIDC_ID_KEY=(str, ''), #the key associated with the OIDC user IDs - DD_SOCIAL_AUTH_OIDC_USERNAME_KEY=(str, ''), #the key associated with the OIDC usernames - DD_SOCIAL_AUTH_OIDC_WHITELISTED_DOMAINS=(list, ['']), #list of domains allowed for login - DD_SOCIAL_AUTH_OIDC_JWT_ALGORITHMS=(list, ["RS256","HS256"]), - DD_SOCIAL_AUTH_OIDC_ID_TOKEN_ISSUER=(str, ''), - DD_SOCIAL_AUTH_OIDC_ACCESS_TOKEN_URL=(str, ''), - DD_SOCIAL_AUTH_OIDC_AUTHORIZATION_URL=(str, ''), - DD_SOCIAL_AUTH_OIDC_USERINFO_URL=(str, ''), - DD_SOCIAL_AUTH_OIDC_JWKS_URI=(str, ''), - {{< /highlight >}} - -### Configure Defect Dojo -Edit the settings (see [Configuration](../../open_source/installation/configuration)) with the following - information: - - {{< highlight python >}} - DD_SESSION_COOKIE_SECURE=True, - DD_CSRF_COOKIE_SECURE=True, - DD_SECURE_SSL_REDIRECT=True, - DD_SOCIAL_AUTH_KEYCLOAK_OAUTH2_ENABLED=True, - DD_SOCIAL_AUTH_KEYCLOAK_PUBLIC_KEY=(str, ''), - DD_SOCIAL_AUTH_KEYCLOAK_KEY=(str, ''), - DD_SOCIAL_AUTH_KEYCLOAK_SECRET=(str, ''), - DD_SOCIAL_AUTH_KEYCLOAK_AUTHORIZATION_URL=(str, ''), - DD_SOCIAL_AUTH_KEYCLOAK_ACCESS_TOKEN_URL=(str, '') - {{< /highlight >}} - -or, alternatively, for helm configuration, add this to the `extraConfig` section: - -```yaml -DD_SESSION_COOKIE_SECURE: 'True' -DD_CSRF_COOKIE_SECURE: 'True' -DD_SECURE_SSL_REDIRECT: 'True' -DD_SOCIAL_AUTH_KEYCLOAK_OAUTH2_ENABLED: 'True' -DD_SOCIAL_AUTH_KEYCLOAK_PUBLIC_KEY: '' -DD_SOCIAL_AUTH_KEYCLOAK_KEY: '' -DD_SOCIAL_AUTH_KEYCLOAK_SECRET: '' -DD_SOCIAL_AUTH_KEYCLOAK_AUTHORIZATION_URL: '' -DD_SOCIAL_AUTH_KEYCLOAK_ACCESS_TOKEN_URL: '' -``` - -Optionally, you *can* set `DD_SOCIAL_AUTH_KEYCLOAK_LOGIN_BUTTON_TEXT` in order to customize the login button's text caption. - -## GitHub Enterprise -1. Navigate to your GitHub Enterprise Server and follow instructions to create a new OAuth App [https://docs.github.com/en/enterprise-server/developers/apps/building-oauth-apps/creating-an-oauth-app](https://docs.github.com/en/enterprise-server/developers/apps/building-oauth-apps/creating-an-oauth-app) -2. Choose a name for your application -3. For the Redirect URI, enter the DefectDojo URL with the following - format - - **https://the_hostname_you_have_dojo_deployed:your_server_port/complete/github-enterprise/** -4. Edit the settings (see [Configuration](../../open_source/installation/configuration)) with the following - information: - {{< highlight python >}} - DD_SOCIAL_AUTH_GITHUB_ENTERPRISE_KEY=(str, 'GitHub Enterprise OAuth App Client ID'), - DD_SOCIAL_AUTH_GITHUB_ENTERPRISE_SECRET=(str, 'GitHub Enterprise OAuth App Client Secret'), - DD_SOCIAL_AUTH_GITHUB_ENTERPRISE_URL=(str, 'https://github..com/'), - DD_SOCIAL_AUTH_GITHUB_ENTERPRISE_API_URL=(str, 'https://github..com/api/v3/'), - DD_SOCIAL_AUTH_GITHUB_ENTERPRISE_OAUTH2_ENABLED = True, - {{< /highlight >}} -5. Restart DefectDojo, and you should now see a **Login with GitHub Enterprise** - button on the login page. - -## SAML 2.0 -In a similar direction to OAuth, this SAML addition provides a more secure -perogative to SSO. For definitions of terms used and more information, -see the plugin [plugin homepage](https://github.com/IdentityPython/djangosaml2). - -1. Navigate to your SAML IdP and find your metadata -2. Edit the settings (see [Configuration](../../open_source/installation/configuration)) with the following - information: - - {{< highlight python >}} - DD_SAML2_ENABLED=(bool, **True**), - # SAML Login Button Text - DD_SAML2_LOGIN_BUTTON_TEXT=(str, 'Login with SAML'), - # If the metadata can be accessed from a url, try the - DD_SAML2_METADATA_AUTO_CONF_URL=(str, ''), - # Otherwise, downlaod a copy of the metadata into an xml file, and - # list the path in DD_SAML2_METADATA_LOCAL_FILE_PATH - DD_SAML2_METADATA_LOCAL_FILE_PATH=(str, '/path/to/your/metadata.xml'), - # Fill in DD_SAML2_ATTRIBUTES_MAP to corresponding SAML2 userprofile attributes provided by your IdP - DD_SAML2_ATTRIBUTES_MAP=(dict, { - # format: SAML attrib:django_user_model - 'Email': 'email', - 'UserName': 'username', - 'Firstname': 'first_name', - 'Lastname': 'last_name' - }), - # May configure the optional fields - {{< /highlight >}} - -NOTE: *DD_SAML2_ATTRIBUTES_MAP* in k8s can be referenced as extraConfig (e.g. `DD_SAML2_ATTRIBUTES_MAP: 'Email'='email', 'Username'='username'...`) - -NOTE: *DD_SITE_URL* might also need to be set depending on the choices you make with the metadata.xml provider. (File versus URL). - -4. Checkout the SAML section in dojo/`dojo/settings/settings.dist.py` and verfiy if it fits your requirement. If you need help, take a look at the [plugin -documentation](https://djangosaml2.readthedocs.io/contents/setup.html#configuration). - -5. Restart DefectDojo, and you should now see a **Login with SAML** button (default setting of DD_SAML2_LOGIN_BUTTON_TEXT) on the login page. - -NOTE: In the case when IDP is configured to use self signed (private) certificate, -than CA needs to be specified by define environments variable -REQUESTS_CA_BUNDLE that points to the path of private CA certificate. - -### Advanced Configuration -The [https://github.com/IdentityPython/djangosaml2](djangosaml2) plugin has a lot of options. For details take a look at the [plugin -documentation](https://djangosaml2.readthedocs.io/contents/setup.html#configuration). All default options in DefectDojo can overwritten in the local_settings.py. If you want to change the organization name, you can add the following lines: - -{{< highlight python >}} -if SAML2_ENABLED: - SAML_CONFIG['contact_person'] = [{ - 'given_name': 'Extra', - 'sur_name': 'Example', - 'company': 'DefectDojo', - 'email_address': 'dummy@defectdojo.com', - 'contact_type': 'technical' - }] - SAML_CONFIG['organization'] = { - 'name': [('DefectDojo', 'en')], - 'display_name': [('DefectDojo', 'en')], - }, -{{< /highlight >}} - -### Migration from django-saml2-auth -Up to relase 1.15.0 the SAML integration was based on [https://github.com/fangli/django-saml2-auth](django-saml2-auth). Which the switch to djangosaml2 some parameters has changed: - -* DD_SAML2_ASSERTION_URL: not necessary any more - automatically generated -* DD_SAML2_DEFAULT_NEXT_URL: not necessary any more - default forwarding from defectdojo is used -* DD_SAML2_NEW_USER_PROFILE: not possible any more - default profile is used, see User Permissions -* DD_SAML2_ATTRIBUTES_MAP: Syntax has changed -* DD_SAML2_CREATE_USER: Default value changed to False, to avoid security breaches - -## RemoteUser - -This implementation is suitable if the DefectDojo instance is placed behind HTTP Authentication Proxy. -Dojo expects that the proxy will perform authentication and pass HTTP requests to the Dojo instance with filled HTTP headers. -The proxy should check if an attacker is not trying to add a malicious HTTP header and bypass authentication. - -Values which need to be set: - -* `DD_AUTH_REMOTEUSER_ENABLED` - Needs to be set to `True` -* `DD_AUTH_REMOTEUSER_USERNAME_HEADER` - Name of the header which contains the username -* `DD_AUTH_REMOTEUSER_EMAIL_HEADER`(optional) - Name of the header which contains the email -* `DD_AUTH_REMOTEUSER_FIRSTNAME_HEADER`(optional) - Name of the header which contains the first name -* `DD_AUTH_REMOTEUSER_LASTNAME_HEADER`(optional) - Name of the header which contains the last name -* `DD_AUTH_REMOTEUSER_GROUPS_HEADER`(optional) - Name of the header which contains the comma-separated list of groups; user will be assigned to these groups (missing groups will be created) -* `DD_AUTH_REMOTEUSER_GROUPS_CLEANUP`(optional) - Same as [#automatic-import-of-user-groups](AzureAD implementation) -* `DD_AUTH_REMOTEUSER_TRUSTED_PROXY` - Comma separated list of proxies; Simple IP and CIDR formats are supported -* `DD_AUTH_REMOTEUSER_LOGIN_ONLY`(optional) - Check [Django documentation](https://docs.djangoproject.com/en/3.2/howto/auth-remote-user/#using-remote-user-on-login-pages-only) - -*WARNING:* There is possible spoofing of headers (for all `DD_AUTH_REMOTEUSER_xxx_HEADER` values). Read Warning in [Django documentation](https://docs.djangoproject.com/en/3.2/howto/auth-remote-user/#configuration) - -## User Permissions - -When a new user is created via the social-auth, only the default permissions are active. This means that the newly created user does not have access to add, edit, nor delete anything within DefectDojo. There are two parameters in the System Settings to influence the permissions for newly created users: - -### Default group - -When both the parameters `Default group` and `Default group role` are set, the new user will be a member of the given group with the given role, which will give him the respective permissions. - -### Groups from Identity Providers - -Some Identity Providers are able to send list of groups to which should user belongs. This functionality is implemented only for Identity Providers mentioned below. For all others, we will be more than happy for contribution (hint: functions `assign_user_to_groups` and `cleanup_old_groups_for_user` from [`dojo/pipeline.py`](https://github.com/DefectDojo/django-DefectDojo/blob/master/dojo/pipeline.py) might be useful). - -- [Azure](#automatic-import-of-user-groups): Check `DD_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_GET_GROUPS` and `DD_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_CLEANUP_GROUPS` -- [RemoteUser](#remoteuser): Check `DD_AUTH_REMOTEUSER_GROUPS_HEADER` and `DD_AUTH_REMOTEUSER_GROUPS_CLEANUP` - -## Login speed-up - -You can bypass the login form if you are only using SSO/Social authentication for login in by enabling these two environment variables: - -```yaml -DD_SOCIAL_LOGIN_AUTO_REDIRECT: "true" -DD_SOCIAL_AUTH_SHOW_LOGIN_FORM: "false" -``` - -### Login form fallback - -If you are using "login speed-up", it can be useful to be able to login by the standard way, for example when an admin -user needs to log in because of a change of some settings or permissions. This feature is accessible by a visiting the URL -`/login?force_login_form`. - - -## Other Providers - -In an effort to accommodate as much generality as possible, it was -decided to implement OAuth2 with the -[social-auth](https://github.com/python-social-auth/social-core/tree/master/social_core/backends) -ecosystem as it has a library of compatible providers with documentation -of implementation. Conveniently, each provider has an identical -procedure of managing the authenticated responses and authorizing access -within a given application. The only difficulty is creating a new -authentication client with a given OAuth2 provider. diff --git a/docs/content/en/open_source/archived_docs/usage/models.md b/docs/content/en/open_source/archived_docs/usage/models.md deleted file mode 100644 index f08996d96dc..00000000000 --- a/docs/content/en/open_source/archived_docs/usage/models.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: "Core data classes" -description: "DefectDojo is made to be flexible to conform to your program, rather than making your team conform to the tool." -draft: false -weight: 1 -exclude_search: true ---- - -![image](images/dd-hierarchy.png) - -## Product Type - -Product types represent the top level model, these can be business unit -divisions, different offices or locations, development teams, or any -other logical way of distinguishing "types" of products. - -Examples: -: - IAM Team - - Internal / 3rd Party - - Main company / Acquisition - - San Francisco / New York offices - -## Product - -This is the name of any project, program, or product that you are -currently testing. - -Examples: -: - Wordpress - - Internal wiki - - Slack - -## Engagement - -Engagements are moments in time when testing is taking place. They are -associated with a name for easy reference, a time line, a lead (the user -account of the main person conducting the testing), a test strategy, and -a status. Engagement consists of two types: Interactive and CI/CD. An -interactive engagement is typically an engagement conducted by an -engineer, where findings are usually uploaded by the engineer. A CI/CD -engagement, as it's name suggests, is for automated integration with a -CI/CD pipeline. - -Examples: -: - Beta - - Quarterly PCI Scan - - Release Version X - -## Test - -Tests are a grouping of activities conducted by engineers to attempt to -discover flaws in a product. Tests are bundled within engagements, have a -start and end date and are defined by a test type. - -Examples: -: - Burp Scan from Oct. 29, 2015 to Oct. 29, 2015 - - Nessus Scan from Oct. 31, 2015 to Oct. 31, 2015 - - API Test from Oct. 15, 2015 to Oct. 20, 2015 - -## Finding - -A finding represents a flaw discovered while testing. It can be -categorized with severities of Critical, High, Medium, Low, and -Informational (Info). - -Examples: -: - OpenSSL 'ChangeCipherSpec' MiTM Potential Vulnerability - - Web Application Potentially Vulnerable to Clickjacking - - Web Browser XSS Protection Not Enabled - -## Endpoint - -Endpoints represent testable systems defined by their IP address or Fully Qualified Domain Name. - -Examples: -: - https://www.example.com - - https://www.example.com:8080/products - - 192.168.0.36 diff --git a/docs/content/en/open_source/archived_docs/usage/permissions.md b/docs/content/en/open_source/archived_docs/usage/permissions.md deleted file mode 100644 index 4430ad01b2a..00000000000 --- a/docs/content/en/open_source/archived_docs/usage/permissions.md +++ /dev/null @@ -1,125 +0,0 @@ ---- -title: "Permissions" -description: "Users have different functionality available to them, depending on their system-wide permissions and on the role they have as a member of a particular Product or Product Type." -weight: 3 -draft: false ---- - -## System-wide permissions - -* Administrators (aka superusers) have no limitations in the system. They can change all settings, manage users and have read / write access to all data. -* Staff users can add Product Types, and have access to data according to their role in a Product or Product Type. -* Regular users have limited functionality available. They cannot add Product Types but have access to data according to their role in a Product or Product Type - -## Product and Product Type permissions - -Users can be assigned as members to Products and Product Types, giving them one out of five predefined roles. The role defines what kind of access a user has to functions for interacting with data of that Product or Product Type: - -**Product / Product Type roles:** - -| | Reader | Writer | Maintainer | Owner | API Importer | -|-----------------------------|:------:|:------:|:----------:|:-----:|:------------:| -| Add Product Type | | | 1) |1) | | -| View Product Type | x | x | x | x | x | -| Remove yourself as a member | x | x | x | x | | -| Manage Product Type members | | | x | x | | -| Edit Product Type | | | x | x | | -| Add Product | | | x | x | | -| Add Product Type member as Owner | | | | x | | -| Delete Product Type | | | | x | | -| | | | | | | -| View Product | x | x | x | x | x | -| Remove yourself as a member | x | x | x | x | | -| Manage Product members | | | x | x | | -| Edit Product | | | x | x | | -| Add Product member as Owner | | | | x | | -| Delete Product | | | | x | | -| | | | | | | -| View Engagement | x | x | x | x | x | -| Add Engagement | | x | x | x | x | -| Edit Engagement | | x | x | x | x | -| Risk Acceptance | | x | x | x | | -| Delete Engagement | | | x | x | | -| | | | | | | -| View Test | x | x | x | x | x | -| Add Test | | x | x | x | | -| Edit Test | | x | x | x | x | -| Delete Test | | | x | x | | -| | | | | | | -| View Finding | x | x | x | x | x | -| Add Finding | | x | x | x | | -| Edit Finding | | x | x | x | | -| (Re-)Import Scan Result | | x | x | x | x | -| Delete Finding | | | x | x | | -| | | | | | | -| View Finding Group | x | x | x | x | x | -| Add Finding Group | | x | x | x | | -| Edit Finding Group | | x | x | x | | -| Delete Finding Group | | x | x | x | | -| | | | | | | -| View Endpoint | x | x | x | x | x | -| Add Endpoint | | x | x | x | | -| Edit Endpoint | | x | x | x | | -| Delete Endpoint | | | x | x | | -| | | | | | | -| Edit Benchmark | | x | x | x | | -| Delete Benchmark | | | x | x | | -| | | | | | | -| View Components | x | x | x | x | x | -| | | | | | | -| View Note History | x | x | x | x | | -| Add Note | x | x | x | x | | -| Edit Note | (x) 2) | x | x | x | | -| Delete Note | (x) 2) | (x) 2) | x | x | | - - -1) Every superuser can add Product Types. Regular users are not allowed to add Product Types, unless they are a Global Owner or Maintainer. - -2) Every user is allowed to edit and delete his own notes. - -The role of a user within a Product Type is inherited by all Products of that Product Type, unless the user is explicitly defined as a member of a Product with a different role. In that case, if a user doesn't have a certain right for the Product Type, it is then checked if he has the right for the Product. - -A Product Type needs to have at least one owner. The last owner cannot be removed. - -## Global permissions - -Users can be assigned a global role in the *Edit User* dialog. A global role gives a user access to all Product Types and Products, including the underlying data, with permissions according to the respective role. - -A use case for a global role could be the Chief Information Security Officer of a company who needs an overview of all systems. If he gets the global role `Reader`, he can see the findings for all products and also all metrics. - -Since global roles give users access to all data, only superusers are allowed to edit it. - -## Groups ## - -If you have a number of users who should all have the same permissions for some Products or Product Types, you can put them together in a group. The group defines the roles for Products and Product Types that are applied to all members of the group. - -The membership of a group itself has a role that determines what permissions the member has to manage the group: - -| | Reader | Maintainer | Owner | -|-----------------------------|:------:|:----------:|:-----:| -| Add Group 1) | | | | -| View Group | x | x | x | -| Remove yourself as a member | x | x | x | -| Manage Group members | | x | x | -| Edit Group | | x | x | -| Add Group member as Owner | | | x | -| Delete Group | | | x | - -1) Every superuser can add groups. Regular users are not allowed to add groups. - -The permissions to manage the roles of Products and Product types for a group is defined by the role of the user in the respective Product or Product Type. - -Groups can have a global role too. This global role gives all members of the group access to all Product Types and Products, including the underlying data, with permissions according to the respective role. - -## Configuration permissions - -Many configuration dialogues and API endpoints can be enabled for users or groups of users, regardless of their **superuser** status: - -![Configuration permissions](images/configuration_permissions.png) - -3 configurations can still only be changed by superusers: -* System settings -* Notifications on system level -* Configuration permissions for users and groups - -These configuration settings are a powerful tool and should be used with great care. diff --git a/docs/content/en/open_source/archived_docs/usage/productgrading.md b/docs/content/en/open_source/archived_docs/usage/productgrading.md deleted file mode 100644 index 3ead06d24f4..00000000000 --- a/docs/content/en/open_source/archived_docs/usage/productgrading.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Product Health Grading" -description: "Products are graded based on their health." -draft: false -weight: 2 ---- - -## Product Health Grading - -Within DefectDojo's system settings, you have the opportunity to enable a grading system for your products. For that you have to enable ("Enable Product Grading"). Then, the products are graded with the following possible grades: -- Grade A -- Grade B -- Grade C -- Grade D -- Grade F - -The best grade is A going down to the worst grade F. By default the grades stick to the achieved percentage mentioned in grade converation [here](https://en.wikipedia.org/wiki/Academic_grading_in_the_United_States). - -### Calculation of the grades -The code that performs the grade calculations can be found [here](https://github.com/DefectDojo/django-DefectDojo/blob/76e11c21e88fb84b67b6da27c78fbbe1899e7e78/dojo/management/commands/system_settings.py#L8). - -The highest health score is 100 and it decreases based on the number of findings for each severity (critical, high, medium, low) within the product. In the following code snippet you can see the rules. -Note that the following abbreviations were used: - -- crit: amount of critical findings within the product -- high: amount of high findings within the product -- med: amount of medium findings within the product -- low: amount of low findings within the product - -```python -health=100 -if crit > 0: - health = 40 - health = health - ((crit - 1) * 5) -if high > 0: - if health == 100: - health = 60 - health = health - ((high - 1) * 3) -if med > 0: - if health == 100: - health = 80 - health = health - ((med - 1) * 2) -if low > 0: - if health == 100: - health = 95 - health = health - low -if health < 5: - health = 5 -return health -``` \ No newline at end of file diff --git a/docs/content/en/open_source/archived_docs/usage/workflows.md b/docs/content/en/open_source/archived_docs/usage/workflows.md deleted file mode 100644 index 62882ba8352..00000000000 --- a/docs/content/en/open_source/archived_docs/usage/workflows.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: "Example workflows" -description: "Two examples how DefectDojo can be used in day-to-day operations." -draft: false -weight: 4 ---- - - -Example 1 - Bill the security engineer --------------------------------------- - -Bill wants a place to keep track of what he\'s worked on, so that he can -show his boss exactly what issues he reports, and statistics about how -long it takes to close them. - -When he is asked to audit an application, Bill registers a new Product -in DefectDojo, and creates a new Engagement. Here he sets some basic -information, like how long he expects the Engagement will take, who will -be leading the testing (himself), what Product he will be working on, -and what tests he will be doing. - -Next, he can add a Test to the Engagement, or upload a Nessus scan and -start picking out the real vulnerabilities from the false positives -(Nessus scan Findings are imported as inactive by default). - -Within the Test section, Bill can add Findings for any issues that he -has uncovered during his audit. He can assign a severity to the -Findings, describe replication steps, mitigation strategies, and impact -on the system. This will come in handy when he wants to generate a -report to send to the development team responsible for this Product, or -his manager. - -Once Bill has completed his Engagement, he can close the Engagement on -the main Engagement page. He can then view the results of his Tests, and -generate a report to send to the development team. - -If Bill hears back from the development team that they won\'t be able to -fix the issue for a while, he can make a note of this on the Engagement -page. Bill will also receive Alerts for any bugs that persist longer -than they are supposed to based on their severity. - -Example 2 - John the QE manager -------------------------------- - -John wants to keep tabs on what his team members are up to, and find -issues that are taking a long time to get fixed. He creates his own -DefectDojo account with superuser privileges so that he can view other -team members\' metrics. - -To get a better idea of what his team members are currently working on, -he can start by checking the Calendar. This will show him any active -Engagements that his team is involved in, based on the dates assigned to -those Engagements. - -He can view metrics for a Product Type, such as \"Third Party Apps\" to -track his team\'s activity and follow up with Product teams who have -long-lived bugs. He can also look at all the Findings for which there is -a Risk Acceptance associated, and ensure that the proper documentation -or timeline has been provided for the Findings in question. - -If he wants to check on a particular team member\'s progress, he can -look at the Engineer Metrics dashboard under \"Additional Metrics\" for -that user. diff --git a/docs/content/en/open_source/performance.md b/docs/content/en/open_source/performance.md index 70dfa44b421..4504e4a3158 100644 --- a/docs/content/en/open_source/performance.md +++ b/docs/content/en/open_source/performance.md @@ -1,5 +1,5 @@ --- -title: "Performance Enhancements" +title: "Performance Enhancements (Open Source)" description: "Settings to configure to enhance performance in DefectDojo" draft: false weight: 4 @@ -15,17 +15,6 @@ change many filters to only search on names, rather than the objects themselves. This change will save many large queries, and will improve the performance of UI based interactions. -## Asynchronous Import - -DefectDojo offers an experimental feature to aynschronously import security reports. -This feature works in most use cases, but struggles when doing things such as pushing -to Jira during the import process. Because Endpoints are still being processed and -created even after the import procedure is completed, pushing Findings to Jira can -result in incomplete Jira tickets. It is advised to wait until after import has been -completed (reaches 100%). - -To enable this feature, set `ASYNC_FINDING_IMPORT` to True in `local_settings.py` - ## Asynchronous Delete For larger instances, deleting an object can take minutes for all related objects to be diff --git a/docs/content/en/open_source/archived_docs/integrations/source-code-repositories.md b/docs/content/en/working_with_findings/organizing_engagements_tests/source-code-repositories.md similarity index 59% rename from docs/content/en/open_source/archived_docs/integrations/source-code-repositories.md rename to docs/content/en/working_with_findings/organizing_engagements_tests/source-code-repositories.md index c6f3b333a98..0bb47f6dc33 100644 --- a/docs/content/en/open_source/archived_docs/integrations/source-code-repositories.md +++ b/docs/content/en/working_with_findings/organizing_engagements_tests/source-code-repositories.md @@ -1,17 +1,18 @@ --- -title: "Source code repositories" +title: "Link Findings to source code" description: "Integration of repositories to navigate to the locaction of findings in the source code." draft: false weight: 5 --- -Findings can have a filepath and a line number as the location of the vulnerability. This is typically set when scanning an application with a Static Application Security Test (SAST) tool. If the repository of the source code is specified in the Engagement, DefectDojo will present the filepath as a link and the user can navigate directly to the location of the vulnerability. +Certain tools (particularly SAST tools) will include the associated file name and line number in vulnerability data. If the repository of the source code is specified in the Engagement, DefectDojo will present the filepath as a link and the user can navigate directly to the location of the vulnerability. ## Setting the repository in the Engagement and Test ### Engagement While editing the Engagement, users can set the URL of the specific SCM repo. -For Interactive Engagement it needs to be the URL including the branch: + +For an Interactive Engagement, it needs to be a URL that specifies the branch: - for GitHub - like https://github.com/DefectDojo/django-DefectDojo/tree/dev ![Edit Engagement (GitHub)](images/source-code-repositories_1.png) - for GitLab - like https://gitlab.com/gitlab-org/gitlab/-/tree/master @@ -21,13 +22,13 @@ For Interactive Engagement it needs to be the URL including the branch: - for standalone/onpremise BitBucket https://bb.example.com/scm/some-project/some-repo.git or https://bb.example.com/scm/some-user-name/some-repo.git for user public repo (like git clone url) ![Edit Engagement (Bitbucket standalone)](images/source-code-repositories-bitbucket-onpremise_1.png) -For CI/CD Engagement, where user could set commit hash, branch/tag and code line it should look like examples below: -- for GitHub - like https://github.com/DefectDojo/django-DefectDojo -- for GitLab - like https://gitlab.com/gitlab-org/gitlab -- for public BitBucket, Gitea and Codeberg - like https://bitbucket.org/some-user/some-project.git (like git clone url) -- for standalone/onpremise BitBucket https://bb.example.com/scm/some-project.git or https://bb.example.com/scm/some-user-name/some-repo.git for user public repo (like git clone url) +For CI/CD Engagements, the commit hash, branch/tag and code line can vary, so you only need to include the URL of the repository. +- for GitHub - like `https://github.com/DefectDojo/django-DefectDojo` +- for GitLab - like `https://gitlab.com/gitlab-org/gitlab` +- for public BitBucket, Gitea and Codeberg - like `https://bitbucket.org/some-user/some-project.git` (like git clone url) +- for standalone/onpremise BitBucket `https://bb.example.com/scm/some-project.git` or `https://bb.example.com/scm/some-user-name/some-repo.git` for user public repo (like git clone url) -If user does not set commit hash or branch/tag in appropriate fields of CI/CD Engagement edit form, the URL should look like in Interactive Engagement edit form. +In a CI/CD Engagement, you can specify a commit hash or branch/tag in the **Edit Engagement** form, which will be appended to any links rendered by DefectDojo. If these are not set, the SCM URL will need to contain a complete link which includes the code branch. SCM navigation URL is composed from Repo URL using SCM Type. A specific SCM type can be set in Product custom field "scm-type". If no "scm-type" is set and the URL contains "https://github.com", a "github" SCM type is assumed. @@ -42,7 +43,7 @@ Product SCM type add: Possible SCM types could be 'github', 'gitlab', 'bitbucket', 'bitbucket-standalone', 'gitea', 'codeberg' or nothing (for default github). -## Link in Finding +## Source code Links in Findings When viewing a finding, the location will be presented as a link, if the repository of the source code has been set in the Engagement: