Release 2.52.0: Merge Bugfix into Dev

.github/workflows/k8s-tests.yml

@@ -16,7 +16,7 @@ jobs:
           # databases, broker and k8s are independent, so we don't need to test each combination
           # lastest k8s version (https://kubernetes.io/releases/) and the oldest officially supported version
           # are tested (https://kubernetes.io/releases/)
-          - k8s: 'v1.34.1' # renovate: datasource=github-releases depName=kubernetes/kubernetes versioning=loose
+          - k8s: 'v1.34.0' # renovate: datasource=github-releases depName=kubernetes/kubernetes versioning=loose
             os: debian
           - k8s: 'v1.31.13' # Do not track with renovate as we likely want to rev this manually
             os: debian

.github/workflows/shellcheck.yml

@@ -2,124 +2,17 @@
 name: Shellcheck
 on:
   pull_request:
-env:
-  SHELLCHECK_REPO: 'koalaman/shellcheck'
-  SHELLCHECK_VERSION: 'v0.9.0' # renovate: datasource=github-releases depName=koalaman/shellcheck
-  SHELLCHECK_SHA: '038fd81de6b7e20cc651571362683853670cdc71' # Renovate config is not currently adjusted to update hash - it needs to be done manually for now
+
 jobs:
   shellcheck:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
         uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
 
-      - name: Grab shellcheck
-        run: |
-          set -e
-
-          SHELLCHECK_TARBALL_URL="https://github.com/${SHELLCHECK_REPO}/releases/download/${SHELLCHECK_VERSION}/shellcheck-${SHELLCHECK_VERSION}.linux.x86_64.tar.xz"
-          SHELLCHECK_TARBALL_LOC="shellcheck.tar.xz"
-          curl -L "${SHELLCHECK_TARBALL_URL}" -o "${SHELLCHECK_TARBALL_LOC}"
-          tarball_sha=$(shasum ${SHELLCHECK_TARBALL_LOC} | awk '{print $1}')
-          if [ "${tarball_sha}" != "${SHELLCHECK_SHA}" ]; then
-            echo "Got invalid SHA for shellcheck: ${tarball_sha}"
-            exit 1
-          fi
-          tar -xvf "${SHELLCHECK_TARBALL_LOC}"
-          cd "shellcheck-${SHELLCHECK_VERSION}" || exit 1
-          mv shellcheck "${GITHUB_WORKSPACE}/shellcheck"
-
-      - name: Run shellcheck
-        shell: bash
-        run: |
-          set -o pipefail
-
-          # Make sure we already put the proper shellcheck binary in place
-          if [ ! -f "./shellcheck" ]; then
-              echo "shellcheck not found"
-              exit 1
-          fi
-
-          # Make sure we know what to compare the PR's changes against
-          if [ -z "${GITHUB_BASE_REF}" ]; then
-              echo "No base reference supplied"
-              exit 1
-          fi
-
-          num_findings=0
-
-          # Execute shellcheck and add errors based on the output
-          run_shellcheck() {
-              local modified_shell_script="${1}"
-              local findings_file="findings.txt"
-
-              # Remove leftover findings file from previous iterations
-              if [ -f "${findings_file}" ]; then
-                  rm "${findings_file}"
-              fi
-
-              echo "Running shellcheck against ${modified_shell_script}..."
-
-              # If shellcheck reported no errors (exited with 0 status code), return
-              if ./shellcheck -f json -S warning "${modified_shell_script}" | jq -c '.[]' > "${findings_file}"; then
-                  return 0
-              fi
-
-              # Walk each of the individual findings
-              while IFS= read -r finding; do
-                  num_findings=$((num_findings+1))
-
-                  line=$(echo "${finding}" | jq '.line')
-                  end_line=$(echo "${finding}" | jq '.endLine')
-                  column=$(echo "${finding}" | jq '.column')
-                  end_column=$(echo "${finding}" | jq '.endColumn')
-                  code=$(echo "${finding}" | jq '.code')
-                  title="SC${code}"
-                  message="$(echo "${finding}" | jq -r '.message') See https://github.com/koalaman/shellcheck/wiki/${title}"
-
-                  echo "Line: ${line}"
-                  echo "End line: ${end_line}"
-                  echo "Column: ${column}"
-                  echo "End column: ${end_column}"
-                  echo "Title: ${title}"
-                  echo "Message: ${message}"
-
-                  # Raise an error with the file/line/etc
-                  echo "::error file=${modified_shell_script},line=${line},endLine=${end_line},column=${column},endColumn=${end_column},title=${title}::${message}"
-              done < ${findings_file}
-          }
-
-          # Find the shell scripts that were created or modified by this PR
-          find_modified_shell_scripts() {
-              shell_scripts="shell_scripts.txt"
-              modified_files="modified_files.txt"
-              modified_shell_scripts="modified_shell_scripts.txt"
-
-              find . -name "*.sh" -or -name "*.bash" | sed 's#^\./##' > "${shell_scripts}"
-              git diff --name-only "origin/${GITHUB_BASE_REF}" HEAD > "${modified_files}"
-
-              if [ ! -s "${shell_scripts}" ] || [ ! -s "${modified_files}" ]; then
-                  echo "No modified shell scripts detected"
-                  exit 0
-              fi
-
-              if ! grep -Fxf "${shell_scripts}" "${modified_files}" > "${modified_shell_scripts}"; then
-                echo "No modified shell scripts detected"
-                exit 0
-              fi
-          }
-
-          git fetch origin "${GITHUB_BASE_REF}" || exit 1
-
-          find_modified_shell_scripts
-
-          # Loop through the modified shell scripts
-          while IFS= read -r modified_shell_script; do
-              run_shellcheck "${modified_shell_script}"
-          done < ${modified_shell_scripts}
-
-          # If shellcheck reported any findings, fail the workflow
-          if [ ${num_findings} -gt 0 ]; then
-              echo "shellcheck reported ${num_findings} findings."
-              exit 1
-          fi
+      - name: Run ShellCheck
+        uses: ludeeus/action-shellcheck@00cae500b08a931fb5698e11e79bfbd38e612a38 # 2.0.0
+        with:
+          version: 'v0.11.0' # renovate: datasource=github-releases depName=koalaman/shellcheck versioning=loose
+        env:
+          SHELLCHECK_OPTS: -e SC1091 -e SC2086  # TODO: fix following findings

.github/workflows/test-helm-chart.yml

@@ -107,12 +107,25 @@ jobs:
     steps:
       - name: Checkout
         uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
-
+
+      - name: Update values in HELM chart
+        if: startsWith(github.head_ref, 'renovate/') || startsWith(github.head_ref, 'dependabot/')
+        run: |
+          yq -i '.annotations."artifacthub.io/changes" += "- kind: changed\n  description: ${{ github.event.pull_request.title }}\n"' helm/defectdojo/Chart.yaml
+
+      - name: Run helm-docs (update)
+        uses: losisin/helm-docs-github-action@a57fae5676e4c55a228ea654a1bcaec8dd3cf5b5 # v1.6.2
+        if: startsWith(github.head_ref, 'renovate/') || startsWith(github.head_ref, 'dependabot/')
+        with:
+          chart-search-root: "helm/defectdojo"
+          git-push: true
+
       # Documentation provided in the README file needs to contain the latest information from `values.yaml` and all other related assets.
       # If this step fails, install https://github.com/norwoodj/helm-docs and run locally `helm-docs --chart-search-root helm/defectdojo` before committing your changes.
       # The helm-docs documentation will be generated for you.
-      - name: Run helm-docs
+      - name: Run helm-docs (check)
         uses: losisin/helm-docs-github-action@a57fae5676e4c55a228ea654a1bcaec8dd3cf5b5 # v1.6.2
+        if: ! startsWith(github.head_ref, 'renovate/') || startsWith(github.head_ref, 'dependabot/')
         with:
           fail-on-diff: true
           chart-search-root: "helm/defectdojo"

docs/content/en/connecting_your_tools/connectors/connectors_tool_reference.md

@@ -172,6 +172,8 @@ The SonarQube Connector can fetch data from either a SonarCloud account or from
 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**
@@ -187,7 +189,7 @@ See the [Snyk API documentation](https://docs.snyk.io/snyk-api) for more info.
 
 ## Tenable
 
-The Tenable connector uses the **Tenable.io** REST API to fetch data.
+The Tenable connector uses the **Tenable.io** REST API to fetch data.  Currently, only vulnerability scans are imported - Web App Scans cannot be imported with the Connector.
 
 On\-premise Tenable Connectors are not available at this time.
 

docs/content/en/share_your_findings/integrations.md

@@ -9,7 +9,7 @@ Supported Integrations:
 - [Azure Devops](/en/share_your_findings/integrations_toolreference/#azure-devops-boards)
 - [GitHub](/en/share_your_findings/integrations_toolreference/#github)
 - [GitLab Boards](/en/share_your_findings/integrations_toolreference/#gitlab)
-- ServiceNow (Coming Soon)
+- [ServiceNow](/en/share_your_findings/integrations_toolreference/#servicenow)
 
 ## Opening the Integrations page
 

docs/content/en/share_your_findings/integrations_toolreference.md

@@ -1,6 +1,6 @@
 ---
 title: "Integrators Tool Reference"
-description: "Beta Feature"
+description: "Detailed setup guides for Integrators"
 weight: 1
 ---
 
@@ -101,7 +101,7 @@ The GitLab integration allows you to add issues to a [GitLab Project](https://do
 
 ### Issue Tracker Mapping
 
-- **Project Name**: The name of the project in GitLab that you want to send issues to
+- **Project Name**: The name of the project in GitLab that you want to send issues to.
 
 ### Severity Mapping Details
 
@@ -122,3 +122,62 @@ By default, GitLab has statuses of 'opened' and 'closed'.  Additional status lab
 - **Closed Mapping**: `closed`
 - **False Positive Mapping**: `closed`
 - **Risk Accepted Mapping**: `closed`
+
+## ServiceNow
+
+The ServiceNow Integration allows you to push DefectDojo Findings as ServiceNow Incidents.
+
+### Instance Setup
+
+Your ServiceNow instance will require you to obtain a Refresh Token, associated with the User or Service account that will push Incidents to ServiceNow.
+
+You'll need to start by creating an OAuth registration on your ServiceNow instance for DefectDojo:
+
+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 ID** 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`

docs/content/en/working_with_findings/finding_priority.md

@@ -58,8 +58,9 @@ High. Criticality is a subjective field, so when assigning this field, consider
 Product compares to other Products in your organization.
 * **User Records** is a numerical estimation of user records in a database (or a system
 that can access that database).
-* **Revenue** is a numerical estimation of annual revenue for the Product. It is not
-possible to set a currency type in DefectDojo, so make sure that all of your Revenue
+* **Revenue** is a numerical estimation of annual revenue for the Product. To calculate Priority, DefectDojo will calculate a percentage by comparing this Product's revenue to the sum of all Products within the Product Type.
+
+It is not possible to set a currency type in DefectDojo, so make sure that all of your Revenue
 estimations have the same currency denomination. (“50000” could mean $50,000
 US Dollars or ¥50,000 Japanese Yen - the denomination does not matter as long as
 all of your Products have revenue calculated in the same currency).
@@ -85,9 +86,6 @@ Findings within a Product can have additional metadata which can further adjust
 * Whether the Finding is in the KEV (Known Exploited Vulnerabilities) database, which is checked by DefectDojo on a regular basis
 * The tool-reported Severity of a Finding (Info, Low, Medium, High, Critical)
 
-Currently, Priority calculation and the underlying formula cannot be adjusted. These
-numbers are meant as a reference only - your team’s actual priority for remediation
-may vary from the DefectDojo calculation.
 
 ## Finding Risk Calculation
 

docs/content/en/working_with_findings/priority_adjustments.md

@@ -0,0 +1,62 @@
+---
+title: "Adjusting Priority and Risk (Pro)"
+description: "Change weighting of Priority and Risk calculations"
+weight: 2
+---
+
+DefectDojo Pro's Priority and Risk calculations can be adjusted, allowing you to tailor DefectDojo Pro to match your internal standards for Finding Priority and Risk.
+
+## Prioritization Engines
+
+Similar to SLA configurations, Prioritization Engines allow you to set the rules governing how Priority and Risk are calculated.
+
+![image](images/priority_default.png)
+
+DefectDojo comes with a built-in Prioritization Engine, which is applied to all Products.  However, you can edit this Prioritization Engine to change the weighting of **Finding** and **Product** multipliers, which will adjust how Finding Priority and Risk are assigned.
+
+### Finding Multipliers
+
+Eight contextual factors impact the Priority score of a Finding.  Three of these are Finding-specific, and the other five are assigned based on the Product that holds the Finding.
+
+You can tune your Prioritization Engine by adjusting how these factors are applied to the final calculation.
+
+![image](images/priority_sliders.png)
+
+Select a factor by clicking the button, and adjust this slider allows you to control the percentage a particular factor is applied.  As you adjust the slider, you'll see the Risk thresholds change as a result.
+
+#### Finding-Level Multipliers
+
+* **Severity** - a Finding's Severity level
+* **Exploitability** - a Finding's KEV and/or EPSS score
+* **Endpoints** - the amount of Endpoints associated with a Finding
+
+#### Product-Level Multipliers
+
+* **Business Criticality** - the related Product's Business Criticality (None, Very Low, Low, Medium, High, or Very
+High)
+* **User Records** - the related Product's User Records count
+* **Revenue** - the related Product's revenue, relative to the total revenue of the Product Type
+* **External Audience** - whether or not the related Product has an external audience
+* **Internet Accessible** - whether or not the related Product is internet accessible
+
+### Risk Thresholds
+
+Based on the tuning of the Priority Engine, DefectDojo will automatically recommend Risk Thresholds.  However, these thresholds can be adjusted as well and set to whatever values you deem appropriate.
+
+![image](images/risk_threshold.png)
+
+## Creating New Prioritization Engines
+
+You can use multiple Prioritization Engines, which can each be assigned to different Products.
+
+![image](images/priority_engine_new.png)
+
+Creating a new Prioritization Engine will open the Prioritization Engine form.  Once this form is submitted, a new Prioritization Engine will be added to the table.
+
+## Assigning Prioritization Engines to Products
+
+Each Product can have a Prioritization Engine currently in use via the **Edit Product** form for a given Product.
+
+![image](images/priority_chooseengine.png)
+
+Note that when a Product's Prioritization Engine is changed, or a Prioritization Engine is updated, the Product's Prioritization Engine or the Prioritization Engine itself will be "Locked" until the prioritization calculation has completed.