DefectDojo Features

Below are the main sections within DefectDojo. Each is designed to allow for ease of use and simple organization of Products and their Tests. The Models page will help you understand the terminology we use below, so we recommend taking a look at that first.


The following attributes describe a Product:

A short name for the product, used for easy identification. This field can hold up to 300 characters.
Used to fully describe the product. This field can hold up to 2000 characters.
Product Manager
Provides the ability to store who manages the product lifecycle. Useful for contacting team members. This field can hold up to 200 characters.
Technical Contact
Provides the ability to store who should be contacted in case of technical questions and/or difficulties.models. This field can hold up to 200 characters.
Provides the ability to store who manages the technical resources for the product. This field can hold up to 200 characters.
Date Created
Stores when the Product was fist added to DefectDojo.
Date Update
Stores when the Product was updated.
Business Criticality
Criticality of the product.
Type of product: web, API, mobile etc.
Stage of product development
Product Type
Used to group products together.
Authorized Users
List of users who are allowed to view and interact with the product.

Products are listed on the /product page and can be filtered by their attributes as well as sorted by their name and product type.

Product Listing Page

Visual representation of a product:

View Product Page

Product with metrics:

View Product Page With Metrics Displayed


The following attributes describe an Engagement:

Helps distinguish one Engagement from another on the same product. This field can hold up to 300 characters.
Target Start Date
The projected start date for this engagement.
Target End Date
The projected end date for this engagement.
The DefectDojo user who is considered the lead for this group of tests.
The Product being tested as part of this group of tests.
Denotes if the Engagement is currently active or not.
Test Strategy
The URL of the testing strategy defined for this Engagement.
Threat Model
The document generated by a threat modeling session discussing the risks associated with this product at this moment in time.
Describes the current state of the Engagement. Values include In Progress, On Hold and Completed.

Engagements are listed in the /engagement page and can be filtered by their attributes as well as sorted by the product or product type.

Engagement Listing Page

Visual representation of an engagement:

View Engagement Page


Endpoints represent testable systems defined by IP address or Fully Qualified Domain Name.

The following attributes describe an Endpoint:

The communication protocol such as ‘http’, ‘https’, ‘ftp’, etc.
The host name or IP address, you can also include the port number. For example ‘’, ‘’, ‘localhost’, ‘’.
The location of the resource, it should start with a ‘/’. For example “/endpoint/420/edit”
The query string, the question mark should be omitted. “For example ‘group=4&team=8’
The fragment identifier which follows the hash mark. The hash mark should be omitted. For example ‘section-13’, ‘paragraph-2’.
The Product that this endpoint should be associated with.

Endpoints are listed in the /endpoints page and can be filtered by their attributes as well as sorted by the product or host.

Endpoint Listing Page

Visual representation of an endpoint:

View Endpoint Page

Visual representation of an endpoint with metrics displayed:

View Endpoint Page with metrics


Findings represent a flaw within the product being tested. The following attributes help define a Finding:

A short description of the flaw (Up to 100 characters)
Longer more descriptive information about the flaw.
The date the flaw was discovered.
The CWE number associated with this flaw.
The severity level of this flaw (Critical, High, Medium, Low, Informational)
Numerical Severity
The numerical representation of the severity (S0, S1, S2, S3, S4)
Text describing how to best fix the flaw.
Text describing the impact this flaw has on systems, products, enterprise, etc.
The hosts within the product that are susceptible to this flaw.
The external documentation available for this flaw.
The test that is associated with this flaw. The flaw belong to the test.
Is Template
Denotes of this finding is a template and can be reused.
Denotes if this flaw is active or not.
Denotes if this flaw has been manually verified by tester.
False Positive
Denotes if this flaw has been deemed a false positive by the tester.
Denotes if this flaw is a duplicate of other flaws reported.
Out Of Scope
Denotes if this flaw falls outside the scope of the test and/or engagement.
Denotes if this flaw has been fixed, by storing the date it was fixed.
Mitigated By
Documents who has deemed this flaw as fixed.
Documents who reported the flaw.
Last Reviewed
Provides the date the flaw was last “touched” by a tester.
Last Reviewed By
Provides the person who last reviewed the flaw.
Stores information pertinent to the flaw or the mitigation.
Finding images can now be uploaded to help with documentation and proof of vulnerability.

If you are upgrading from an older version of DefectDojo, you will have to complete the following and make sure MEDIA_ROOT and MEDIA_URL are properly configured:

Add imagekit to INSTALLED_APPS:

    'polymorphic',  # provides admin templates

Add r’^media/’ to LOGIN_EXEMPT_URLS:


Then run the following commands (make sure your virtual environment is activated):

pip install django-imagekit
pip install pillow --upgrade
./ makemigrations dojo
./ makemigrations
./ migrate

New installations will already have finding images configured.

Findings are listed on the /finding/open, /finding/closed, /finding/accepted and /finding/all pages. They can be filtered by their attributes as well as sorted by their Name, Date, Reviewed Date, Severity and Product.

Finding Listing Page

Finding Listing Page

Finding Listing Page

Visual representation of a Finding:

Finding View Finding View Finding View
Automatically Flag Duplicate Findings
‘De-duplication’ is a feature that when enabled will compare findings to automatically identify duplicates. To enable de-duplication go to System Settings and check Deduplicate findings. Dojo deduplicates findings by comparing endpoints, CWE fields, and titles. If a two findings share a URL and have the same CWE or title, Dojo marks the less recent finding as a duplicate. When deduplication is enabled, a list of deduplicated findings is added to the engagement view.


DefectDojo provides a number of metrics visualization in order to help with reporting, awareness and to be able to quickly communicate a products/product type’s security stance.

The following metric views are provided:

Product Type Metrics

This view provides graphs displaying Open Bug Count by Month, Accepted Bug Count by Month, Open Bug Count by Week, Accepted Bug Count by Week as well as tabular data on Top 10 Products by bug severity, Detail Breakdown of all reported findings, Opened Findings, Accepted Findings, Closed Findings, Trending Open Bug Count, Trending Accepted Bug Count, and Age of Issues.

Product Type Metrics
Product Type Counts

This view provides tabular data of Total Current Security Bug Count, Total Security Bugs Opened In Period, Total Security Bugs Closed In Period, Trending Total Bug Count By Month, Top 10 By Bug Severity, and Open Findings. This view works great for communication with stakeholders as it is a snapshot in time of the product.

Product Type Counts
Simple Metrics

Provides tabular data for all Product Types. The data displayed in this view is the total number of S0, S1, S2, S3, S4, Opened This Month, and Closed This Month.

Simple Metrics
Engineer Metrics

Provides graphs displaying information about a testers activity.

Simple Metrics
Metrics Dashboard

Provides a full screen, auto scroll view with many metrics in graph format. This view is great for large displays or “Dashboards.”

Metrics Dashboard


DefectDojo users inherit from django.contrib.auth.models.User.

A username, first name, last name, and email address can be associated with each. Additionally the following describe the type of use they are:

Designates whether this user should be treated as active. Unselect this instead of deleting accounts.
Staff status
Designates whether the user can log into this site.
Superuser status
Designates that this user has all permissions without explicitly assigning them.


The calendar view provides a look at all the engagements occurring during the month displayed. Each entry is a direct link to the Engagement view page.

Port Scans

DefectDojo has the ability to run a port scan using nmap. Scan can be configured for TCP or UDP ports as well as for a Weekly, Monthly or Quarterly frequency.

Port Scan Form

In order for the scans to kick off the must run. It is easy to set up a cron job in order to kick these off at the appropriate frequency. Below is an example cron entry:

0 0 * * 0 /root/.virtualenvs/dojo/bin/python /root/defect-dojo/ run_scan Weekly
0 0 1 * * /root/.virtualenvs/dojo/bin/python /root/defect-dojo/ run_scan Monthly
0 0 1 3,6,9,12 * /root/.virtualenvs/dojo/bin/python /root/defect-dojo/ run_scan Quarterly
Port Scan Form

The scan process will email the configured recipients with the results.

These scans call also be kicked off on demand by selecting the Launch Scan Now option in the view scan screen.

Port Scan Form


Notification settings

DefectDojo can inform you of different events in a variety of ways. You can be notified about things like an upcoming engagement, when someone mentions you in a comment, a scheduled report has finished generating, and more.

The following notification methods currently exist: - Email - Slack - HipChat - Alerts within DefectDojo

You can set these notifications on a global scope (if you have administrator rights) or on a personal scope. For instance, an administrator might want notifications of all upcoming engagements sent to a certain Slack channel, whereas an individual user wants email notifications to be sent to the user’s specified email address when a report has finished generating.

In order to identify and notify you about things like upcoming engagements, DefectDojo runs scheduled tasks for this purpose. These tasks are scheduled and run using Celery beat, so this needs to run for those notifications to work. Instructions on how to run Celery beat are available in the Reports section.


OWASP ASVS Benchmarks

DefectDojo utilizes the OWASP ASVS Benchmarks to benchmark a product to ensure the product meets your application technical security controls. Benchmarks can be defined per the organizations policy for secure development and multiple benchmarks can be applied to a product.

Benchmarks are available from the Product view. To view the configured benchmarks select the dropdown menu from the right hand drop down menu. You will find the selection near the bottom of the menu entitled: ‘OWASP ASVS v.3.1’.

OWASP ASVS Benchmarks Menu

In the Benchmarks view for each product, the default level is ASVS Level 1. On the top right hand side the drop down can be changed to the desired ASVS level (Level 1, Level 2 or Level 3). The publish checkbox will display the ASVS score on the product page and in the future this will be applied to reporting.


On the left hand side the ASVS score is displayed with the desired score, the % of benchmarks passed to achieve the score and the total enabled benchmarks for that AVSV level.

Additional benchmarks can be added/updated in the Django admin site. In a future release this will be brought out to the UI.


Report Listing

DefectDojo’s reports can be generated in AsciiDoc and PDF. AsciiDoc is recommended for reports with a large number of findings.

The PDF report is generated using wkhtmltopdf via Celery and sane defaults are included in the file. This allows report generation to be asynchronous and improves the user experience.

If you are updating from an older version of DefectDojo, you will need to install wkhtmltopdf on your own. Please follow the directions for your specific OS in the wkhtmltopdf documentation.

Some operating systems are capable of installing wkhtmltopdf from their package managers:


To get report email notifications, make sure you have a working email configuration in the system settings, and enable notifications for generated reports in the notification settings.


brew install Caskroom/cask/wkhtmltopdf


sudo apt-get install wkhtmltopdf


sudo yum install wkhtmltopdf


Version in debian/ubuntu repos have reduced functionality (because it compiled without the wkhtmltopdf QT patches), such as adding outlines, headers, footers, TOC etc. To use this options you should install static binary from wkhtmltopdf site.

Additionally, DefectDojo takes advantage of python-PDFKit to interact with the wkhtmltopdf commandline interface. It is easily installed by running:

pip install pdfkit

It will also be necessary to add the path of wkhtmltopdf to your file. By default the following entry ships with DefectDojp:

WKHTMLTOPDF_PATH = '/usr/local/bin/wkhtmltopdf'

However you make have to update that entry to suite your installation.

Celery is included with DefectDojo and needs to be kicked off in order for reports to generate/work. In development you can run the celery process like:

celery -A dojo worker -l info --concurrency 3

In production it is recommended that the celery process be daemonized. Supervisor is also included with DefectDojo and can be set up by following the Celery documentation. A sample celeryd.conf can be found at.

Celery beat should also be running, this will enable defectDojo to perform periodic checks of things like upcoming and stale engagements as well as allowing for celery to clean up after itself and keep your task database from getting too large. In development you can run the process like:

celery beat -A dojo -l info

In production it is recommended that the celery beat process also be daemonized. A sample celerybeatd.conf can be found here.

If you are upgrading from an older version of DefectDojo, you will have to install Celery on your own. To do this you you can run:

pip install celery

If you are using virtual environments make sure your environment is activated. You can also follow the installation instructions from the Celery documentation.

Reports can be generated for:

  1. Groups of Products
  2. Individual Products
  3. Endpoints
  4. Product Types
  5. Custom Reports
Report Generation

Filtering is available on all Report Generation views to aid in focusing the report for the appropriate need.

Custom reports allow you to select specific components to be added to the report. These include:

  1. Cover Page
  2. Table of Contents
  3. WYSIWYG Content
  4. Findings List
  5. Endpoint List
  6. Page Breaks

The custom report workflow takes advantage of the same asynchronous process described above.

JIRA Integration

DefectDojo’s JIRA integration is bidirectional. You may push findings to JIRA and share comments. If an issue is closed in JIRA it will automatically be closed in Dojo.

Preparing Jira, Enabling the Webhook
  1. Visit https://<YOUR JIRA URL>/plugins/servlet/webhooks
  2. Click ‘Create a Webhook’
  3. For the field labeled ‘URL’ enter: https://<YOUR DOJO DOMAIN>/webhook/
  4. Under ‘Comments’ enable ‘Created’. Under Issue enable ‘Updated’.
Configurations in Dojo
  1. Navigate to the System Settings from the menu on the left side or by directly visiting <your url>/system_settings.
  2. Enable ‘Enable JIRA integration’ and click submit.
Adding JIRA to Dojo
  1. Click ‘JIRA’ from the left hand menu.
  2. Select ‘Add Configuration’ from the drop-down.
  3. To obtain the ‘open status key’ and ‘closed status key’ visit https://<YOUR JIRA URL>/rest/api/latest/issue/<ANY VALID ISSUE KEY>/transitions?expand=transitions.fields
  4. The ‘id’ for ‘Todo’ should be filled in as the ‘open status key’
  5. The ‘id’ for ‘Done’ should be filled in as the ‘closed status key’

To obtain ‘epic name id’: If you have admin access to JIRA:

  1. visit: https://<YOUR JIRA URL>/secure/admin/ViewCustomFields.jspa
  2. Click on the cog next to ‘Epic Name’ and select view.
  3. The numeric value for ‘epic name id’ will be displayed in the URL
  4. Note: dojojira uses the same celery functionality as reports. Make sure the celery runner is setup correclty as described:


  1. login to JIRA
  2. visit https://yourjiraurl/rest/api/2/field and use control+F or grep to search for ‘Epic Name’ it should look something like this:

{“id”:”customfield_122”,”key”:”customfield_122”,”name”:”Epic Name”,”custom”:true,”orderable”:true,”navigable”:true,”searchable”:true,”clauseNames”:[“cf[122]”,”Epic Name”],”schema”:{“type”:”string”,”custom”:”com.pyxis.greenhopper.jira:gh-epic-label”,”customId”:122}},

In the above example 122 is the number needed

Issue Consolidation

DefectDojo allows users to automatically consolidate issues from multiple scanners to remove duplicates.

To enable this feature, hover over the configuration tab on the left menu and click on system settings. In system settings, click ‘Deduplicate findings’. Click ‘Submit’ at the bottom of the page.

When deduplication is enabled, Dojo will compare CWE, title, and endpoint details for all findings in a given product. If an issue is added with either the CWE or title being the same while the endpoint is also the same, Dojo marks the old issue as a duplicate.

False Positive Removal

DefectDojo allows users to tune out false positives by enabling False Positive History. This will track what engineers have labeled as false positive for a specific product and for a specific scanner. While enabled, when a tool reports the same issue that has been flagged as a false positive previously, it will automatically mark the finding as a false positive, helping to tune overly verbose security tools.


Deduplication is a process that allows DefectDojo to find out that a finding has already been imported


Global configuration

The deduplication can be activated in “System Settings” by ticking “Deduplicate findings”.

An option to delete duplicates can be found in the same menu, and the maximum number of duplicates to keep for the same finding can be configured.

Engagement configuration

When creating an engagement or later by editing the engagement the “Deduplication on engagement” checkbox can be ticked.

  • If activated: Findings are only deduplicated within the same engagement. Findings present in different engagements cannot be duplicates
  • Else: Findings are deduplicated across the whole product

How it works - APIv1 and manual import

When importing a report using the APIv1 /api/v1/importscan/ or manually through the GUI:

  • Duplicates are detected based on cwe, title, line, file_path, date, dynamic/static finding, hash_code
  • When a duplicate is found:
    • The newly imported finding takes status: inactive, duplicate
    • An “Original” link is displayed after the finding status, leading to the original finding

How it works - APIv2

When importing a report using the APIv2 api/v2/import-scan/:

  • Duplicates are detected based on hash_code only
  • Parameters of interest are
    • skip_duplicates : if true, duplicates are not inserted at all
    • close_old_findings : if true, findings that are not duplicates and that were in the previous scan of the same type (example ZAP) for the same product (or engagement in case of “Deduplication on engagement”) and that are not present in the new scan are closed (Inactive, Verified, Mitigated)
    • if skip_duplicates and close_old_findings are both false, not deduplication is done