Merge pull request #12385 from DefectDojo/bugfix

Release 2.46.0: Merge Bugfix into Dev

Author: rossops

.github/workflows/gh-pages.yml

@@ -52,6 +52,7 @@ jobs:
 
       - name: Deploy
         uses: peaceiris/actions-gh-pages@4f9cc6602d3f66b9c108549d475ec49e8ef4d45e # v4.0.0
+        if: github.repository == 'DefectDojo/django-DefectDojo' # Deploy docs only in core repo, not in forks - it would just fail in fork
         with: # publishes to the `gh-pages` branch by default
           github_token: ${{ secrets.GITHUB_TOKEN }}
           publish_dir: ./docs/public

.github/workflows/release-1-create-pr.yml

@@ -9,8 +9,13 @@ on:
       # the actual branch that can be chosen on the UI is made irrelevant by further steps
       # because someone will forget one day to change it.
       from_branch:
-        description: "Select branch to release from ('release/x.y.z'. If `dev` is entered, a new release branch will be created from `dev`)"
+        description: "Select branch to release from. Dev branch releases happen the first monday of the month. Otherwise, use bugfix."
         required: true
+        type: choice
+        default: 'bugfix'
+        options:
+          - bugfix
+          - dev
       release_number:
         description: "Release version (x.y.z format)"
         required: true
@@ -19,6 +24,18 @@ jobs:
   create_pr:
     runs-on: ubuntu-latest
     steps:
+      - name: Validate proper bugfix branch release_number format is being used
+        if: ${{ inputs.from_branch == 'bugfix' }}
+        run: |
+          # Expect the last octet in release_number to not be 0
+          echo "${{ inputs.release_number }}" | grep "^[0-9]*\.[0-9]*\.[1-9]$"
+
+      - name: Validate proper dev branch release_number format is being used
+        if: ${{ inputs.from_branch == 'dev' }}
+        run: |
+          # Expect the last octet in release_number to not be 1-9
+          echo "${{ inputs.release_number }}" | grep "^[0-9]*\.[0-9]*\.0$"
+
       - id: Set-GitHub-org
         run: echo "GITHUB_ORG=${GITHUB_REPOSITORY%%/*}" >> $GITHUB_ENV
 
@@ -28,15 +45,9 @@ jobs:
           ref: ${{ inputs.from_branch }}
 
       - name: Create release branch
-        if: ${{ !startsWith(inputs.from_branch, 'release/') }}
         run: |
           echo "NEW_BRANCH=release/${{ inputs.release_number }}" >> $GITHUB_ENV
 
-      - name: Use existing release branch
-        if: startsWith(inputs.from_branch, 'release/')
-        run: |
-          echo "NEW_BRANCH=${{ inputs.from_branch }}" >> $GITHUB_ENV
-
       - name: Configure git
         run: |
           git config --global user.name "${{ env.GIT_USERNAME }}"

.github/workflows/slack-pr-reminder.yml

@@ -8,6 +8,7 @@ on:
 jobs:
   notify-reviewers:
     runs-on: ubuntu-latest
+    if: github.repository == 'DefectDojo/django-DefectDojo' # Notify only in core repo, not in forks - it would just fail in fork
 
     steps:
       - name: Checkout repository

docs/assets/images/tags_importscan.png

@@ -10,6 +10,11 @@ For Open Source release notes, please see the [Releases page on GitHub](https://
 
 ## Apr 2025: v2.45
 
+### Apr 28, 2025: v2.45.3
+
+- **(Tools)** Fortify parser can now assign False Positive status to Findings according to the audit.xml file.
+- **(Import)** Reimporting a scan can now handle special statuses assigned by a tool.  Now, if a Finding was initially imported as Active, but the status was changed to False Positive, Out Of Scope or Risk Accepted by a subsequent report, that status will now be respected and applied to the Finding by Reimport.
+
 ### Apr 22, 2025: v2.45.2
 
 ![image](images/risk_table.png)

docs/assets/images/tags_product.png

@@ -9,6 +9,7 @@ You can use Generic Findings Import as a method to ingest JSON or CSV files into
 Files uploaded using Generic Findings Import must conform to the accepted format with respect to CSV column headers / JSON attributes.
 
 These attributes are supported for CSV:
+
 - Date: Date of the finding in mm/dd/yyyy format.
 - Title: Title of the finding
 - CweId: Cwe identifier, must be an integer value.
@@ -104,18 +105,32 @@ Example:
 }
 ```
 
-This parser supports an attribute `name` and `type` to be able to define `TestType`. Based on this, you can define custom `HASHCODE_FIELDS` or `DEDUPLICATION_ALGORITHM` in the settings.
+This parser supports some additional attributes to be able to define custom `TestTypes` as well as influencing some meta fields on the `Test`:
+
+- `name`: The internal name of the tool you are using. This is primarily informational, and used for reading the report manually.
+- `type`: The name of the test type to create in DefectDojo with the suffix of `(Generic Findings Import)`. The suffix is an important identifier for future users attempting to identify the test type to supply when importing new reports. This value is very important when fetching the correct test type to import findings into, so be sure to keep the `type` consistent from import to import! As an example, a report submitted with a `type` of `Internal Company Tool` will produce a test type in DefectDojo with the title `Internal Company Tool (Generic Findings Import)`. With this newly created test type, you can define custom `HASHCODE_FIELDS` or `DEDUPLICATION_ALGORITHM` in the settings.
+- `version`: The version of the tool you are using. This is primarily informational, and is used for reading the report manually and tracking format changes from version to version.
+- `description`: A brief description of the test. This could be an explanation of what the tool is reporting, where the tools is maintained, who the point of contact is for the tool when issues arise, or anything in between.
+- `static_tool`: Dictates that tool used is running static analysis methods to discover vulnerabilities.
+- `dynamic_tool`: Dictates that tool used is running dynamic analysis methods to discover vulnerabilities.
+- `soc`: Dictates that tool is used for reporting alerts from a soc (Pro Edition Only).
 
 Example:
 
 ```JSON
 {
     "name": "My wonderful report",
     "type": "My custom Test type",
+    "version": "1.0.5",
+    "description": "A unicorn tool that is capable of static analysis, dynamic analysis, and even capturing soc alerts!",
+    "static_tool": true,
+    "dynamic_tool": true,
+    "soc": true,
     "findings": [
     ]
 }
 ```
 
 ### Sample Scan Data
+
 Sample Generic Findings Import scans can be found [here](https://github.com/DefectDojo/django-DefectDojo/tree/master/unittests/scans/generic).

docs/content/en/changelog/changelog.md

@@ -315,8 +315,9 @@ In order to use Google Authentication, a Google Authentication Server will need
     - **Google OAuth Secret** should be set to your **Client Secret Key**.
     - **Whitelisted Domains** can be set to the domain name used by your organization.  However, this will allow login from any user with this domain name in their Google email address.
     - Alternatively, if you only want to allow specific Google email addresses to log in to DefectDojo, you can enter those in the **Whitelisted E-mail Addresses** section of the form. `([email protected],[email protected])`, etc.
+    - Note that you must add at least one user or domain to the whitelist, or DefectDojo will not allow any users to log in using Google OAuth.
 
-2. Check the **Enable Azure AD OAuth** box.  Submit the form, and `Login With Google` will be added as an option to the Login menu.
+2. Check the **Enable Google OAuth** box.  Submit the form, and `Login With Google` will be added as an option to the Login menu.
 
 ### Open-Source
 
@@ -678,4 +679,4 @@ 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.
+authentication client with a given OAuth2 provider.

docs/content/en/connecting_your_tools/parsers/generic_findings_import.md

@@ -68,7 +68,7 @@ If you have a testing and remediation effort related to a specific aspect of you
 
 ‘This Finding was discovered by our scanning tool, but after reviewing the Finding we have discovered that this reported vulnerability does not exist.’
 
-Once you’ve reviewed a Finding, you might discover that the vulnerability reported does not actually exist. The False Positive status allows DefectDojo to keep track of this information, and future imports will also apply the False Positive status to this Finding.
+Once you’ve reviewed a Finding, you might discover that the vulnerability reported does not actually exist. The False Positive status will be maintained by reimport and prevent matching findings from being opened or closed, which assists with noise reduction.  
 
 If a different scanning tool finds a similar Finding, it will not be recorded as a False Positive. DefectDojo can only compare Findings within the same tool to determine if a Finding has already been recorded.
 

docs/content/en/customize_dojo/user_management/configure_sso.md

@@ -0,0 +1,178 @@
+---
+title: "Tags"
+description: "Use Tags to create a new slice of your data model"
+draft: false
+weight: 2
+exclude_search: false
+---
+
+Tags are ideal for grouping objects in a manner that can be filtered out into smaller, more digestible chunks.  They can be used to denote status, or to create custom sets of Product Type, Products, Engagements or Findings across the data model.
+
+In DefectDojo, tags are a first class citizen and are recognized as the facilitators
+of organization within each level of the [data model](../Product_hierarchy).
+
+Here is an example with a Product with two tags and four findings each with a single tag:
+
+![High level example of usage with tags](images/tags-high-level-example.png)
+
+### Tag Formats
+
+Tags can be formatted in any of the following ways:
+- StringWithNoSpaces
+- string-with-hyphens
+- string_with_underscores
+- colons:acceptable
+
+## Tag Management (Pro UI)
+
+### Adding and Removing
+
+Tags can be managed in the following ways:
+
+1. **Creating or Editing new objects**
+
+   When a new object is created or edited through the UI or API, there is a field for specifying
+   the tags to be set on a given object.
+
+   ![tag](images/tags_product.png)
+
+2. **When Importing/Reimporting Findings**
+
+  Tags are available on the Import/Reimport form, both in the UI and via the API.  When this form is submitted, the **Test** will be tagged with `[tag]` and `[daily-import]`.  If "Apply Tags to Findings" or "Apply Tags to Endpoints" is selected, those objects will also be tagged.  Tags provide an opportunity to append automation run details and tool information that may not be captured in the Test or Finding object directly. 
+
+   ![tag](images/tags_importscan.png)
+
+3. **Via Bulk Edit**
+
+  When many Findings are selected from a table, you can use the Bulk Edit menu to change the associated Tags for many Findings simultaneously.  Note that this will replace all Finding-level Tags with the Tags specified; existing Finding Tags will be overwritten.
+
+  ![bulk editing findings](images/Bulk_Editing_Findings.png)
+
+  For more information, see our guide to [Bulk Editing Findings](/en/working_with_findings/findings_workflows/editing_findings/#bulk-edit-findings).
+
+
+## Tag Management (Classic UI / OpenSource)
+
+### Adding and Removing
+
+Tags can be managed in the following ways:
+
+1. Creating or Editing new objects
+
+   When a new object is created or edited through the UI or API, there is a field for specifying
+   the tags to be set on a given object. This field is a multiselect field that also has
+   auto completion to make searching and adding existing tags a breeze. Here is what the field 
+   looks like on the Product from the screenshot in the previous section:
+
+   ![Tag management on an object](images/tags-management-on-object.png)
+
+2. Import and Reimport
+
+    Tags can also be applied to a given test at the time of import or reimport. This is a very
+    handy use case when importing via the API with automation as it provides an opportunity to
+    append automation run details and tool information that may not be captured in the test
+    or finding object directly. 
+
+    The field looks and behaves exactly as it does on a given object
+
+3. Bulk Edit Menu (Findings only)
+
+    When needing to update many Findings with the same set of tags, the bulk edit menu can be
+    used to ease the burden.
+
+    In the following example, lets say I want to update the tags of the two findings with the tag "tag-group-alpha" to be a new tag list like this ["tag-group-charlie", "tag-group-delta"]. 
+    First I would select the tags to be updated:
+
+    ![Select findings for bulk edit tag update](images/tags-select-findings-for-bulk-edit.png)
+
+    Once a finding is selected, a new button appears with the name "Bulk Edit". Clicking this button
+    produces a dropdown menu with many options, but the focus is just on tags for now. Update the
+    field to have the desired tag list as follows, and click submit
+
+    ![Apply changes for bulk edit tag update](images/tags-bulk-edit-submit.png)
+
+    The tags on the selected Findings will be updated to whatever was specified in the tags field
+    within the bulk edit menu
+
+    ![Completed bulk edit tag update](images/tags-bulk-edit-complete.png)
+
+## Tag Inheritance
+
+**Pro UI note: though Tag inheritance can be configured using the Pro UI, inherited Tags currently can only be accessed and filtered for through the Classic UI or the API.**
+
+When Tag Inheritance is enabled, tags applied to a given Product will automatically be applied to all objects under Products in the [Product Hierarchy](/en/working_with_findings/organizing_engagements_tests/Product_hierarchy).
+
+### Configuration
+
+Tag Inheritance can be enabled at the following scope levels:
+- Global Scope
+  - Every Product system wide will begin applying tags to all children objects (Engagements, Tests and Findings)
+  - This is set within the System Settings
+- Product Scope
+  - Only the selected Product will begin applying tags to all children objects (Engagements, Tests and Findings)
+  - This is set at the Product creation/edit page
+
+### Behaviors
+
+When Tag Inheritance is enabled, standard Tags can be added to and removed from objects in the standard way.
+However inherited tags cannot be removed from a child object without removing them from the parent object
+See the following example of adding a tag "test_only_tag" to the Test object and a tag "engagement_only_tag" to the Engagement.
+
+![Example of inherited tags](images/tags-inherit-exmaple.png)
+
+When updates are made to the tag list on a Product, the same changes are made to all objects within the Product asynchronously. The duration of this task directly correlates to the number the objects contained within a finding.
+
+**Open-Source:** If Tag changes are not observed within a reasonable time period, consult the celery worker logs to identify where any problems might have arisen.
+
+
+### Filtering for Tags (Classic UI)
+
+Tags can be filtered in many ways through both the UI and the API. For example, here is a snippet
+of the Finding filters:
+
+![Snippet of the finding filters](images/tags-finding-filter-snippet.png)
+
+There are ten fields related to tags:
+
+ - Tags: filter on any tags that are attached to a given Finding
+   - Examples:
+     - Finding will be returned
+       - Finding Tags: ["A", "B", "C"]
+       - Filter Query: "B"
+     - Finding Will *not* be returned
+       - Finding Tags: ["A", "B", "C"]
+       - Filter Query: "F"
+ - Not Tags: filter on any tags that are *not* attached to a given Finding
+   - Examples:
+     - Finding will be returned
+       - Finding Tags: ["A", "B", "C"]
+       - Filter Query: "F"
+     - Finding Will *not* be returned
+       - Finding Tags: ["A", "B", "C"]
+       - Filter Query: "B"
+ - Tag Name Contains: filter on any tags that contain part or all of the query in the given Finding
+   - Examples:
+     - Finding will be returned
+       - Finding Tags: ["Alpha", "Beta", "Charlie"]
+       - Filter Query: "et" (part of "Beta")
+     - Finding Will *not* be returned
+       - Finding Tags: ["Alpha", "Beta", "Charlie"]
+       - Filter Query: "meg" (part of "Omega")
+ - Not Tags: filter on any tags that do *not* contain part or all of the query in the given Finding
+   - Examples:
+     - Finding will be returned
+       - Finding Tags: ["Alpha", "Beta", "Charlie"]
+       - Filter Query: "meg" (part of "Omega")
+     - Finding Will *not* be returned
+       - Finding Tags: ["Alpha", "Beta", "Charlie"]
+       - Filter Query: "et" (part of "Beta")
+
+For the other six tag filters, they follow the same rules as "Tags" and "Not Tags" as above,
+but at different levels in the data model:
+
+ - Tags (Test): filter on any tags that are attached to the Test of a given Finding
+ - Not Tags (Test): filter on any tags that are *not* attached to the Test of a given Finding
+ - Tags (Engagement): filter on any tags that are attached to the Engagement of a given Finding
+ - Not Tags (Engagement): filter on any tags that are *not* attached to the Engagement of a given Finding
+ - Tags (Product): filter on any tags that are attached to the Product of a given Finding
+ - Not Tags (Product): filter on any tags that are *not* attached to the Product of a given Finding

docs/content/en/working_with_findings/findings_workflows/finding_status_definitions.md

@@ -1527,8 +1527,6 @@ class Meta:
 
 
 class RiskAcceptanceSerializer(serializers.ModelSerializer):
-    recommendation = serializers.SerializerMethodField()
-    decision = serializers.SerializerMethodField()
     path = serializers.SerializerMethodField()
 
     def create(self, validated_data):
@@ -1556,14 +1554,6 @@ def update(self, instance, validated_data):
             ra_helper.remove_finding_from_risk_acceptance(user, instance, finding)
         return instance
 
-    @extend_schema_field(serializers.CharField())
-    def get_recommendation(self, obj):
-        return Risk_Acceptance.TREATMENT_TRANSLATIONS.get(obj.recommendation)
-
-    @extend_schema_field(serializers.CharField())
-    def get_decision(self, obj):
-        return Risk_Acceptance.TREATMENT_TRANSLATIONS.get(obj.decision)
-
     @extend_schema_field(serializers.CharField())
     def get_path(self, obj):
         engagement = Engagement.objects.filter(