Findings (Pro)

Organizations → Assets → Engagements → Tests → FINDINGS

Overview

Findings represent the lowest level of the Product Hierarchy where individual vulnerabilities are tracked and managed and serve as the main way that DefectDojo standardizes and guides the reporting and remediation process of your security tools. Regardless of whether a vulnerability was reported in SonarQube, Acunetix, or your team’s custom tool, Findings give you the ability to manage each vulnerability in the same way.

Examples of Findings include:

• Cookie Not Marked as HttpOnly
• Out-of-Date Version (PHP)
• Out-of-Band Code Evaluation (PHP)
• Out-of-Date Version (MySQL)
• Backup Source Code Detected
• Blind Cross-Site Scripting

In addition to storing the vulnerability data and providing a remediation framework, DefectDojo also enhances your Findings in the following ways:

• Automatically adding related EPSS scores to a Finding to describe exploitability
• Automatically translating a security tool’s severity metric into a Severity score for each Finding, which confers an SLA onto the Finding according to your Asset’s SLA configuration.

Overall, Findings are designed to work with the Product Hierarchy to standardize your efforts, and apply a consistent method to each Asset.

Accessing Findings

Findings are accessible via the sidebar. The submenu provides access to Active and Mitigated Findings, All Findings (regardless of Open or Closed status), Finding Groups, Finding Templates, and the New Finding workflow. Individual Findings are also accessible from within the Test that contains them.

Permissions

Every Finding belongs to a Test, allowing DefectDojo to preserve which scan or assessment originally identified the vulnerability.

As Findings belong to Tests, access to Findings is determined by a User’s access to the Asset that contains the Test. Tests do not have independent access control lists.

Findings View

Finding views contain a variety of tables to help interpret a Finding’s status at a glance.

Finding Overview

• Description: The description of the Finding (added automatically depending on the type of Finding, or created manually).
• Mitigation: Suggested steps to mitigate.
• General Mitigation Policy: The standardized mitigation policy for the selected Finding. Mitigation policies can be found and edited in the sidebar under Configuration → Mitigation Policies.
• Impact: Potential impact of leaving the Finding unresolved.
• References: URL to cross-reference the third-party scan tool’s specific description of the Finding. For example, References could be links to a relevant entry in a Finding catalog, or a single advisory URL.
• Files: Any files that have been added to contextualize the Finding.
• Notes: Notes left by Users related to the Finding. Marking a note as Private will mean it will not be included in any generated reports that include the selected Finding.

Metadata

• ID: DefectDojo’s unique Finding ID.
• Organization, Asset, Engagement, and Test: The parent objects of the selected Finding.
• Status: The status of the Finding (e.g., Active, Verified, False Positive, Duplicate, Out of Scope, and Under Defect Review).
• Severity: The severity rating of that Finding, which is applied automatically.
• Risk: A 4-level ranking system that factors in a Finding’s exploitability and is applied automatically.
• Priority: A calculated numerical rank applied to all Findings that allows you to quickly understand vulnerabilities in context.
• Age: How old the selected Finding is.
• SLA: The due date by which the Finding is intended to be resolved.
• Type: Whether the Finding has been detected from a static or dynamic application security tool (Static, Dynamic or Static/Dynamic).
• Location and Line: The file and line number in which the selected Finding was found.
• Component Name and Version: The name and version of the component in which the selected Finding was found.
• Date Discovered: The date on which the Finding was discovered.
• Planned Remediation Date and Version: The date on which the Finding is planned to be remediated, and the version of the affected component in which the fix will be implemented.
• Service: Connected Services that are affected by the selected Finding.
• Reporter: The User who revealed the Finding.
• CWE: The CWE classification of the Finding.
• Vulnerability IDs: Publicly recognized vulnerability identifiers associated with the Finding, such as CVE, GHSA, or other standardized advisory references.
• Unique ID From Tool: A stable identifier assigned by the source tool to a specific Finding instance.
• Vulnerability ID From Tool: A proprietary vulnerability or rule identifier assigned by the source tool to describe the type of vulnerability that was detected.
• EPSS Score / Percentile: ESS score and percentile for the CVE.
• Known Exploited: Whether there is confirmation that the vulnerability has been exploited.
• Ransomware Used: Whether ransomware was involved in the exploitation of the vulnerability.
• KEV Date: The date the Finding was added to the KEV catalog.
• Found By: The type of tool that identified the vulnerability.
• CVSSv3 and CVSSv4 Vector and Score: The CVSS3 and CVSS4 vector and score of the selected Finding.
• Integrator Tickets: Third-party issue tracker ticket numbers associated with the Finding.

Vulnerable Endpoints

This section includes a table of the Endpoints that the selected Finding affects, along with any relevant metadata.

Additional Details

• Request/Response Pairs: A copy of the message sent by the client and the server’s reply to the request.
• Steps to Reproduce: Steps for reproducing the Finding.
• Severity Justification: Written description of why a certain Severity rating was associated with the Finding.

Findings Data

Findings require the following metadata:

• Name
• Date
• Severity
• Description

In addition to metadata corresponding to the tables in a Finding’s view, optional metadata fields include:

• Tags: Any tags that have been added to the Finding.
• Owners: The group of users that will be responsible for the selected Finding.
• Push to Jira: Pushes the Finding to Jira for ticketing purposes.
• Risk and priority settings: Offers the option to override DefectDojo’s automatic calculation of the Finding’s risk and priority.
• Number of occurrences: Number of occurrences in the source tool when several vulnerabilities were found and aggregated by the scanner.
• Effort estimation: The level of effort involved in fixing the Finding (e.g., Low, Medium, or High).

The exact metadata available will depend on the parser/scanner that revealed the Finding.

Deduplication

DefectDojo includes deduplication capabilities that help identify and manage Findings representing the same underlying vulnerability. As scan results are imported from one or more tools, DefectDojo uses configurable matching logic to identify Findings that represent the same vulnerability.

More information about deduplication can be found here.

Reimport

DefectDojo’s Reimport function allows Findings to be updated as new scan results are imported. When a scan is reimported, DefectDojo compares the incoming results against existing Findings and updates matching records instead of creating entirely new ones. This preserves valuable context such as status changes, remediation history, comments, and ownership information.

Risk Acceptances

Risk Acceptances are a special status that can be applied to Findings to formally document and operationalize the decision to acknowledge them without immediately remediating them.

Statuses

Each Finding created in DefectDojo has a Status that communicates relevant information and helps your team keep track of their progress in resolving issues.

Working with Findings

Creating Findings

While most Findings are generated automatically through scan imports and integrations, DefectDojo also supports the manual creation of Findings. Manual Findings are useful for tracking vulnerabilities and security concerns identified through penetration testing, architecture reviews, compliance assessments, bug bounty programs, consultant engagements, or other activities that do not produce scanner output.

Editing Findings

The ⋮ kebab menu next to Findings contains the following functions:

• Edit Finding: Edit the Finding.
• Close Finding: Initiates the process of closing the Finding.
• Request Review: Initiates the Peer Review process and changes the Finding’s status to “Under Review.”
• Add Risk Acceptance: Initiates the Risk Acceptance process.
• Add Note: Initiates the process to add a note to the Finding.

Closing Findings

Once the work on a Finding is complete, you can manually close it by clicking Close Finding within the Finding’s ⋮ kebab menu or gear menu.

Finding Groups

Finding Groups allow you to treat multiple related Findings as a single logical unit for triage, reporting, and remediation coordination.

Accessing Finding Groups

Finding Groups can be accessed via the sidebar. The submenu provides access to Open and Closed Finding Groups as well as All Finding Groups (regardless of Open status).

Creating Finding Groups

Finding Groups can be created either manually or automatically. Notably, Finding Groups can only be created from the Findings contained within a single Test.

Finding Templates

Finding Templates allow Users to create reusable templates for commonly reported vulnerabilities and security issues. A template can include standardized information such as a title, description, impact, steps to reproduce, mitigation, references, and other Finding metadata.