Release: Merge release into master from: release/2.45.3

components/package.json

@@ -1,6 +1,6 @@
 {
   "name": "defectdojo",
-  "version": "2.45.2",
+  "version": "2.45.3",
   "license" : "BSD-3-Clause",
   "private": true,
   "dependencies": {

docs/content/en/about_defectdojo/contact_defectdojo_support.md

@@ -1,9 +1,9 @@
 ---
-title: "Contact DefectDojo Support"
+title: "Get Support"
 description: "For Pro users: [email protected] + other options"
 draft: "false"
 pro-feature: true
-weight: 3
+weight: 7
 ---
 
 Need help with DefectDojo? Here are some ways to get assistance.

docs/content/en/about_defectdojo/examples_of_use.md

@@ -0,0 +1,153 @@
+---
+title: "💡 Common Use-Cases"
+description: "Use Cases and examples"
+draft: "false"
+weight: 2
+chapter: true
+---
+
+This article is based on DefectDojo Inc's February Office Hours: "Tackling Common-Use Cases".
+<iframe width="560" height="315" src="https://www.youtube.com/embed/44vv-KspHBs?si=ilRBlfo-wvX5DPVg" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
+
+## Examples of Use-Cases
+
+DefectDojo is designed handle any security implementation: no matter your security team size, IT complexity level, or reporting volume.  These stories are intended as jumping-off points for your own needs, but they're based on real examples from our community and DefectDojo Pro team.
+
+### Large Enterprise: RBAC and Engagements
+
+'BigCorp' is a large multinational enterprise, with a CISO and a centralized IC security group that includes AppSec. 
+
+Security at BICORP is highly centralized.  Certain things are delegated out to BISOs (Business Information Security Officers).
+
+The key concerns for BigCorp are:
+
+- Set and maintain a consistent testing method across all business units in the organization
+- Meet compliance requirements and avoid regulatory issues
+
+#### Testing Model
+
+BigCorp handles security data from many sources:
+
+- CI/CD jobs that run SAST, SCA and Secret scanning tools automatically
+- Third-party Pen testing for certain Products
+- PCI compliance auditing for certain Products
+
+Each of these report categories can be handled by a separate Engagement, with a separate Test for each kind of test in DefectDojo.
+
+![image](images/example_product_hierarchy_bigcorp.png)
+
+- If a Product has a CI/CD pipeline, all of the results from that pipeline can be continuously imported into a single open-ended Engagement. Each tool used will create a separate Test within the 'CI/CD' Engagement, which can be continuously updated with new data.
+- Each Pen Test effort can have a separate Engagement created to contain all of the results: e.g. 'Q1 Pen Test 2024', 'Q2 Pen Test 2024', etc.
+- BigCorp will likely want to run their own mock PCI Audit so that they're prepared for the real thing when it happens. The results of those audits can also be stored as a separate Engagement.
+
+#### RBAC Model
+
+- Each BISO has Reader access assigned for each business unit (Product Type) that they're in charge of.
+- Each Product Owner has Writer access for the Product that they're in charge of.  Within their Product, these Product Owners can interact with DefectDojo - they can keep notes, set up pipelines, create Risk Acceptances or use other features.
+- Developers at BigCorp have no access to DefectDojo at all, and they don't need it - the Product Owner can push Jira tickets directly from DefectDojo which contain all of the relevant vulnerability information.  The developers are already using Jira, so they don't have to track remediation any differently than a different development task.
+
+### Embedded Systems: Version-Controlled Reporting
+
+Cyber Robotics is a company that sells manufacturing hardware that comes with embedded software systems.  They have a Chief Product Officer that oversees both their product and cybersecurity as a whole.
+
+Though they have less diverse security information to manage than BigCorp, it's still essential for them to properly contextualize their security information so that they can proactively respond to any significant Findings.
+
+Key concerns for Cyber Robotics:
+
+- They have a limited product line but **many** versions of each product that they need to properly catalog.
+- Maintenance for their products is complex and costs are high, so unnecessary work needs to be avoided.
+
+#### Testing Model
+
+Cyber Robotics has a standardized testing process for all of their embedded systems: 
+
+- CI/CD, SAST, and SCA tests are run.
+- Security Control Reviews
+- Network Scans
+- Third Party Code Review
+
+However, because each version of their software is isolated, they'll inevitably have a lot of data to organize, much of which is only useful in a single context (the particular version of the software they're running).
+
+Cyber Robotics can solve this problem by using Product Types here to represent a single product line, and individual Products for each separate version.  This will allow them to drill down to determine which Products are associated with a single vulnerability.
+
+![image](images/example_product_hierarchy_robotics.png)
+
+Assigning software versions to Products, rather than Engagements allows Cyber Robotics to limit access to a particular software version, if necessary.  Field technicians and Support staff can be granted access to a single version of the software without having to give them access to the entire product line.
+
+#### RBAC Model
+
+The AppSec team here has Global Roles assigned that govern their level of interaction.
+
+- The Chief Product Officer has Global Reader access to DefectDojo, as with the CISO in BigCorp.
+- Individual Product Owners have Global Reader access to any Product in DefectDojo, as well as Writer access to the Product that they own.
+
+On the Support side:
+
+- Support Personnel are temporarily granted Reader access to specific Products that they're assigned to maintain, but they do not have access to all DefectDojo data.
+
+### Dynamic IT environments and microservices: Cloud Services company
+
+Kate's Cloud Service operates a rapidly changing environment that uses Kubernetes, microservices, and automation.  Kate's Cloud Service has a VP of Cloud that oversees Cloud Security issues.  They also have a CISO who manages the software development on offer, but for this example we will focus specifically on their Cloud security concerns.
+
+Kate's Cloud Service has fully automated all of their reporting, and ingests data into DefectDojo as soon as reports are produced.
+
+Key Concerns for Kate's Cloud Service:
+
+- managing multi-tenant cloud security, preventing cross-customer interaction while enabling shared service delivery
+- handling rapid changes in their cloud environment
+
+#### Tagging Shared Services
+
+Because Kate's model contains many shared services that can impact other Products, the team Tags the results to indicate which cloud offerings rely on those services.  This allows any issues with shared services to be traced back to the relevant teams, and reports in DefectDojo.  Each of these Shared Services are in a single Product Type that separates them from the main Cloud offerings.
+
+![image](images/example_product_hierarchy_microservices.png)
+
+Because the company is rapidly growing, with frequently changing tech leads, Kate can use Tags to track which tech lead is currently responsible for each cloud product, avoiding the need for constant manual updates to their DefectDojo system.  These Tech Lead associations are tracked by a service that's external to DefectDojo and can govern the import pipelines or call the DefectDojo API.
+
+#### RBAC Model
+
+On the Security/Compliance side:
+
+- The Product Security Team that owns DefectDojo has admin access to the entire system.
+- Analysts working for the VP of Cloud are granted read-only access across the system, allowing them to generate the necessary reports and metrics for the VP to assess the security of various cloud offerings.
+
+On the development side:
+
+- Tech Leads for each specific cloud product (e.g., compute, storage, shared services) have **Maintainer access** to their assigned Product, to triage the security results related to their specific cloud product offering. They can review Findings and take action within their Product, and can also reorganize their Finding data significantly.
+- Developers working on specific Products are given **Writer Access** to the Product they're working on, enabling them to comment on Findings, request Peer Reviews, and create Risk Acceptances.
+
+### Onboarding New Acquisitions: SaaSy Software
+
+SaaSy software is a rapidly growing firm which frequently acquires other software companies.  Every time a new company is acquired, the Director Of Quality engineering and the AppSec team is suddenly in charge of many new code repos, developers and processes.  Their DefectDojo model ensures that they can get up to speed as soon as possible.
+
+Key Concerns for SaaSy Software:
+
+- avoiding public security issues while maintaining compliance programs (such as SOC2)
+- ability to confidently onboard tools and processes from new products
+- ability to report and categorize vulnerabilities on both in-production and in-development branches
+
+#### Testing Model
+
+Testing at SaaSy is focused on broad strokes rather than standardized tool use, since each acquisition comes with their own tools and processes for AppSec.  SaaSy needs to perform both internal assessments (CI/CD, DAST, Container scans, Threat Modeling) and external assessments (3rd party Pen Tests, Compliance audits.)
+
+To assist with onboarding new applications, SaaSy software has a standard approach to their data model.  Each time SaaSy onboards a new application, they create a new Product Type for that app, and create sub-products for the repositories that make it up; (Front-End, Backend API, etc.)
+
+![image](images/example_product_hierarchy_saas.png)
+
+Each of these Products is further subdivided into Engagements, one for the main branch and one for each branch of development.  Tests within these Engagements are used to categorize the testing efforts.  Development branches have separate Tests which store the results of CI/CD and SCA scans.  The Main branch has those as well, but also adds Tests which store Manual Code Review and Threat Model reports.
+
+All of these Tests are open-ended and can be updated on a regular basis using Reimport.  Deduplication is only handled at the Engagement level, which prevents Findings in one Code branch from closing Findings in another.
+
+By applying this model consistently, SaaSy has a model that they can apply to any new software acquisition, and the AppSec team can quickly begin monitoring the data to ensure compliance.
+
+#### RBAC Model
+
+On the Security/Compliance side:
+
+- The AppSec team at SaaSy software owns DefectDojo and has full admin access to the software.
+- QE and Compliance teams have read-only access to the entire system, to pull reports and dive into data if required.
+
+On the development side:
+
+- Each Product Owner has Writer access to the Product they own in DefectDojo, which allows them to write Risk Acceptances and view metrics for the Product.
+- Developers have read-only access to each Product they work on.  They can Request Peer Reviews on Findings or issues they are trying to remediate.

docs/content/en/about_defectdojo/new_user_checklist.md

@@ -2,7 +2,7 @@
 title: "☑️ New User Checklist"
 description: "Get Started With DefectDojo"
 draft: "false"
-weight: 2
+weight: 3
 chapter: true
 ---
 

docs/content/en/about_defectdojo/pro_features.md

@@ -1,8 +1,8 @@
 ---
-title: "Pro Features List"
+title: "📊 Pro Features List"
 description: "List of Pro Features in DefectDojo"
 draft: "false"
-weight: 2
+weight: 4
 chapter: true
 exclude_search: true
 ---

docs/content/en/about_defectdojo/request_a_trial.md

@@ -2,7 +2,7 @@
 title: "Request a DefectDojo Pro Trial"
 description: "How to request and work with a trial of DefectDojo Cloud"
 draft: "false"
-weight: 4
+weight: 6
 pro-feature: true
 ---
 

docs/content/en/about_defectdojo/ui_pro_vs_os.md

@@ -1,8 +1,8 @@
 ---
-title: "🎨 Beta UI Features"
+title: "🎨 Pro UI Changes"
 description: "Working with different UIs in DefectDojo"
 draft: "false"
-weight: 4
+weight: 5
 pro-feature: true
 ---
 

docs/content/en/changelog/changelog.md

@@ -10,10 +10,20 @@ For Open Source release notes, please see the [Releases page on GitHub](https://
 
 ## Apr 2025: v2.45
 
+### Apr 22, 2025: v2.45.2
+
+![image](images/risk_table.png)
+
+- **(Beta UI)** Added a link to Universal Importer to the sidebar, which provides access to the [Universal Importer and DefectDojo CLI](/en/connecting_your_tools/external_tools/) tools.
+- **(Beta UI)** Added smart Prioritization and Risk fields to DefectDojo Pro, which can be used to more easily triage Findings based on the impact of the Product they affect.  See [Priority](/en/working_with_findings/finding_priority/) documentation for more information.
+- **(Tools)** Updated Fortify Webinspect parser to handle Fortify's new XML report format.
+
 ### Apr 14, 2025: v2.45.1
+
 - **(Connectors)** Added a Connector for Wiz: see [tools reference](/en/connecting_your_tools/connectors/connectors_tool_reference/) for configuration instructions.
 
 ### Apr 7, 2025: v2.45.0
+
 - **(Beta UI)** Added Calendar view to Beta UI: Calendar view now displays Tests and Engagements, and can be filtered.  Clicking on a Calendar entry now displays a more detailed description of the object.
 ![image](images/pro_calendar_view.png)
 - **(Universal Parser)** Added the ability to map an EPSS score from a file.  Note that this field **will** be updated by EPSS database sync, but this gives a user the ability to capture that field from initial import.

docs/content/en/connecting_your_tools/parsers/file/fortify.md

@@ -3,22 +3,22 @@ title: "Fortify"
 toc_hide: true
 ---
 You can either import the findings in .xml or in .fpr file format. </br>
-If you import a .fpr file, the parser will look for the file 'audit.fvdl' and analyze it. An extracted example can be found [here](https://github.com/DefectDojo/django-DefectDojo/tree/master/unittests/scans/fortify/audit.fvdl).
+If you import a .fpr file, the parser will look for the file 'audit.fvdl' and analyze it. An extracted example can be found [here](https://github.com/DefectDojo/django-DefectDojo/tree/master/unittests/scans/fortify/audit.fvdl). The optional `audit.xml` is also parsed. All vulnerabilities marked with `suppressed="true"` will be marked as false positive.
 
 ### Sample Scan Data
 Sample Fortify scans can be found [here](https://github.com/DefectDojo/django-DefectDojo/tree/master/unittests/scans/fortify).
 
 ### Fortify Webinspect report formats.
-Fortify Webinspect released in version 24.2 a new xml report format. This parser is able to handle both report formats. See [this issue](https://github.com/DefectDojo/django-DefectDojo/issues/12065) for further information. 
+Fortify Webinspect released in version 24.2 a new xml report format. This parser is able to handle both report formats. See [this issue](https://github.com/DefectDojo/django-DefectDojo/issues/12065) for further information.
 
 #### Generate XML Output from Foritfy
-This section describes how to import XML generated from a Fortify FPR. It assumes you 
+This section describes how to import XML generated from a Fortify FPR. It assumes you
 already have, or know how to acquire, an FPR file. Once you have the FPR file you will need
 use Fortify's ReportGenerator tool (located in the bin directory of your fortify install).
 ```FORTIFY_INSTALL_ROOT/bin/ReportGenerator```
 
 By default, the Report Generator tool does _not_ display all issues, it will only display one
-per category. To get all issues, copy the [DefaultReportDefinitionAllIssues.xml](https://github.com/DefectDojo/django-DefectDojo/tree/master/unittests/scans/fortify/DefaultReportDefinitionAllIssues.xml) to:  
+per category. To get all issues, copy the [DefaultReportDefinitionAllIssues.xml](https://github.com/DefectDojo/django-DefectDojo/tree/master/unittests/scans/fortify/DefaultReportDefinitionAllIssues.xml) to:
 ```FORTIFY_INSTALL_ROOT/Core/config/reports```
 
 Once this is complete, you can run the following command on your .fpr file to generate the

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

@@ -597,6 +597,10 @@ NOTE: In the case when IDP is configured to use self signed (private) certificat
 than CA needs to be specified by define environments variable
 REQUESTS_CA_BUNDLE that points to the path of private CA certificate.
 
+#### Troubleshooting
+
+The SAML Tracer browser add-on can help troubleshoot SAML problems: [Chrome](https://chromewebstore.google.com/detail/saml-tracer/mpdajninpobndbfcldcmbpnnbhibjmch?hl=en), [Firefox](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/).
+
 #### Advanced Configuration
 The [djangosaml2](https://github.com/IdentityPython/djangosaml2) plugin has a lot of options. For details take a look at the [plugin documentation](https://djangosaml2.readthedocs.io/contents/setup.html#configuration).
 

docs/content/en/working_with_findings/finding_priority.md

@@ -0,0 +1,77 @@
+---
+title: "Finding Priority Enhancement (Pro)"
+description: "How DefectDojo ranks your Findings"
+weight: 1
+---
+
+Additional Finding filters are available in DefectDojo Pro to more easily triage, filter and prioritize Findings.
+
+* Priority sorts Findings based on the context and importance of the Product they are stored in.
+* Risk considers the Product's context, with a greater emphasis on the exploitability of a Finding.
+
+## Finding Priority
+
+In DefectDojo Pro, Priority is a calculated field on Findings that can be used to sort or filter Findings according to Product-level metadata:
+
+- Product's Business Criticality
+- Whether the Product has an External Audience
+- Whether the Product is Internet Accessible
+- The Product's estimated revenue or user records count 
+
+DefectDojo Pro's Finding Priority assigns a numerical rank to each Finding according to this metadata, to provide users with a stronger context on triage and remediation.
+
+![image](images/pro_finding_priority.png)
+
+The range of Priority values is from 0 to 1150.  The higher the number, the more urgency the Finding is to triage or remediate.
+
+Priority numbers can be used with other filters to compare Findings in any context, such as:
+
+* within a single Product, Engagement or Test
+* globally in all DefectDojo Products
+* between a few specific Products
+
+## How Priority is calculated
+
+Every Active finding will have a Priority calculated.  Inactive or Duplicate Findings will not.
+
+Priority is set based on the following factors:
+
+#### Product-Level
+
+- The assigned Criticality for the Product (if defined)
+- The estimated User Records for the Product (if defined)
+- The estimated Revenue for the Product (if defined)
+- If the Product has External Audience defined
+- If the Product has Internet Accessible defined.
+
+All of these metadata fields can be set on the Edit Product form for a given Product.
+
+#### Finding-Level
+
+- Whether or not the Finding has an [EPSS score](/en/working_with_findings/intro_to_findings/#monitor-current-vulnerabilities-using-cves-and-epss-scores-pro-feature), this is automatically kept up to date for Pro customers
+- How many Endpoints in the Product are affected by this Finding
+- Whether or not a Finding is Under Review
+
+If no relevant metadata at the Finding or Product level is set, the Priority level will follow the Severity for a given Finding.
+
+- Critical = 90
+- High = 70
+- Medium = 50
+- Low = 30
+- Info = 10
+
+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
+
+![image](images/risk_table.png)
+
+The Risk column on a Findings table is another way to quickly prioritize Findings.  Risk is calculated using a Finding's Priority level, but also factors in a Finding's exploitability to a greater degree.  This is meant as a less granular, more 'executive-level' version of Priority.
+
+The four assignable Risk levels are:
+
+![image](images/pro_risk_levels.png)
+
+A Finding's EPSS / exploitability is much more emphasized in the Risk calculation.  As a result, a Finding can have both a high priority and a low risk value.
+
+As with Finding Priority, the Risk calculation cannot currently be adjusted.

dojo/__init__.py

@@ -4,6 +4,6 @@
 # Django starts so that shared_task will use this app.
 from .celery import app as celery_app  # noqa: F401
 
-__version__ = "2.45.2"
+__version__ = "2.45.3"
 __url__ = "https://github.com/DefectDojo/django-DefectDojo"
 __docs__ = "https://documentation.defectdojo.com"