Why centralized vulnerability tracking matters for regulated teams
If your scanners report into separate exports and your tracker is a spreadsheet, the same weakness usually appears several times under different names, and nobody can show who owns it or when it was closed. DefectDojo's open-source edition is the open-source option for a central system of record, installed with Docker Compose inside your own cloud account, data center or air-gapped network, so scan data and remediation history never leave your control. Choose the scanners for coverage (Greenbone for network and host checks, Trivy for images and dependencies, ZAP for web applications, and any commercial scanner your contracts require) and let DefectDojo hold the results from all of them.
Duplicates and unowned findings are an evidence problem before they are a security problem. An examiner or auditor who samples a finding will ask for its discovery date, the severity assigned, the owner, the deadline and the closure record. If one flaw sits in three spreadsheets with three statuses, you cannot answer those questions consistently. DefectDojo identifies duplicates with per-parser hashcode fields, such as title and severity for Tenable reports or title, CWE and severity for ZAP reports, so overlapping imports collapse into one finding. Before you rely on that behavior, run a sample import from each scanner and confirm which fields the deduplication uses in your version.
Access control needs a decision before rollout. The open-source edition uses local accounts, while SSO with SAML, OIDC or OAuth, LDAP and MFA are DefectDojo Pro features, according to the DefectDojo README. If your access control rules require central sign-on, unique user identification enforced by a directory and MFA for every system user, the open-source edition alone may not meet them. Confirm the Pro licensing terms, the supported deployment options and the current feature list directly with DefectDojo, and document the account and review process for local users if you deploy the open-source edition.
Requirements that shape the DefectDojo build
This table maps each requirement that applies to a central findings tracker to its source and to what it means for the DefectDojo build. Read it as a checklist: each row names the gap in the open-source edition and the design decision you need to make before import work starts.
| Requirement | What it asks for | What it means for the build |
|---|---|---|
| Unique user identification (HIPAA 45 CFR 164.312) | Access control with unique user identification for systems holding ePHI | Each engineer and auditor needs a named account. Shared logins in DefectDojo break attribution, so plan named accounts from day one. |
| Person or entity authentication (HIPAA 45 CFR 164.312) | Verify that a user or entity is who they claim to be before access is granted | The open-source edition uses local accounts. Confirm whether local password policy meets your rule or whether SSO and MFA, which are Pro features per the README, are required. |
| MFA for system access (FTC Safeguards Rule 16 CFR 314.4) | Multi-factor authentication for any individual accessing any information system | Local accounts in the open-source edition do not provide MFA. Either choose a Pro edition with MFA or document a compensating control approved by your assessor. |
| Monitoring and logging of authorized user activity (FTC 16 CFR 314.4, HIPAA audit controls) | Record and examine activity in systems that hold sensitive data | Confirm what DefectDojo logs for finding status changes, risk acceptances and deletions, and forward application logs to your central log store. |
| Who changed a finding's status | Attribution of each status change, risk acceptance and severity edit to a person and a date | Define a rule that every status change needs a reason field and a named owner. Test that the history view shows the user for each transition before go-live. |
| Data residency for vulnerability data | Vulnerability inventories reveal weaknesses, so the data is sensitive and often must stay in approved locations | Host DefectDojo, its database and attachments in your own cloud account or data center. Confirm backup locations and where scanner exports are stored. |
| SLA configuration by severity | Remediation deadlines set by severity, applied consistently and reportable | Agree the deadline table with risk owners before import. Confirm how your DefectDojo version applies SLA ages and whether changes apply retroactively to open findings. |
| Import and deduplication rules | Consistent handling of repeat findings across weekly scans and multiple scanners | Choose one deduplication setting per parser and test it on a sample export. Confirm that hashcode fields match each scanner's output, for example title and severity for Tenable and title, CWE and severity for ZAP. |
Which scanner reports DefectDojo can ingest and how
Greenbone Community Edition is built on the OpenVAS project, and its results can be imported into DefectDojo through the OpenVAS parser, which accepts reports in CSV or XML format. The more reliable pattern for a recurring program is to avoid manual downloads altogether. The gvmd service stores scan configuration and results in PostgreSQL and offers the XML-based Greenbone Management Protocol (GMP), which tools such as gvm-tools can call on a schedule to pull results.
- Pick one export format per scan profile: Mixing CSV exports from one task with XML exports from another makes it harder to confirm that the same finding is recognized across runs.
- Keep task and target names stable: Renaming a target between scans changes the context that reviewers use to judge whether a finding is new, recurring or already accepted.
- Automate through GMP: Scheduled pulls through gvm-tools reduce the chance that a report is skipped or exported with the wrong filter.
- Record the feed date: Vulnerability test data is loaded by data containers at startup, so the feed version should be stored alongside each import for later audit.
- Map product names carefully: Findings on the same host should be attributed to the same engagement and asset so that duplicates do not appear across two products.
Confirm with your Greenbone deployment which export formats your installed version produces, and test one import against a known target before scheduling the full estate.
The Zed Attack Proxy (ZAP) produces XML reports that DefectDojo imports, with or without requests and responses included. Including the request and response detail gives reviewers evidence to reproduce a finding, but it also increases report size and may store sensitive data in the tracking database, so the choice should be made deliberately. ZAP's Automation Framework runs a YAML plan with jobs such as spider, activeScan and report, and it can be launched with the -cmd -autorun options, which suits pipelines.
- Use the Automation Framework in CI: A single YAML plan keeps the spider, active scan and report jobs identical from run to run.
- Gate on exit codes: ZAP exits with 0 on success, 1 on error and 2 when warnings are present, and an exitStatus job can set the exit code from scan results, so a pipeline can fail or continue on purpose.
- Decide on evidence storage: Importing with requests and responses helps triage, but confirm who can read the stored traffic in DefectDojo.
- Secure the ZAP API: The API is reachable only from the machine running ZAP by default and requires an API key, so keep the key out of plan files and logs.
- Keep the target URL consistent: Changing the base URL between runs can split one application into several records.
Confirm your ZAP version and the report template used by your plan, since the parser depends on the XML structure those templates produce.
DefectDojo's Tenable parser imports CSV exports and .nessus XML files, including reports from legacy Nessus and Nessus WAS. Teams that run Tenable Nessus alongside open-source scanners often export both formats from the same console. The parser identifies duplicates using a hashcode built from the title and severity of each finding, which means that a severity change between scans can make a recurring issue look new.
- Choose one format per source: Standardize on either CSV or .nessus for each scanner so that imports from a given source behave the same way.
- Watch severity changes: Because severity is part of the hashcode for Tenable reports, a rescored plugin will create a new finding unless someone reviews the match.
- Label WAS reports separately: Web application scan results from Nessus WAS should be imported under their own engagement or product so that they are not compared with network scan results.
- Keep plugin titles consistent: Changes to plugin naming across versions affect the title component of the hashcode.
- Store the export settings: Record the filters and scan template used for each export so the import can be reproduced during an assessment.
Confirm with your Tenable administrator which export types your license allows, since the available formats and any plugin output fields can vary by product edition.
DefectDojo's Qualys VMDR parser reads CSV exports in two variants: QID-centric and CVE-centric. The variants organize the same scan data around different keys. A QID-centric export lists one row per Qualys vulnerability identifier, while a CVE-centric export groups results by CVE. Choosing the wrong variant for a process, or switching between them, changes how many findings appear in DefectDojo and how they match earlier imports.
- Fix the variant in the procedure: Document whether the program uses QID-centric or CVE-centric exports and keep that choice for the life of the program.
- Align with the reporting view: Pick the variant that matches how the remediation team tracks work, whether by vulnerability identifier or by CVE.
- Review the first import closely: Compare counts against the Qualys console before trusting deduplication results.
- Plan for mixed estates: If Qualys runs next to Greenbone, confirm that both sources produce comparable identifiers for the same CVE before merging views.
- Note licensing limits: Export capabilities depend on the subscription, so confirm them with the Qualys account owner.
Confirm the exact CSV layout your Qualys subscription produces, because column names and the variant labels in your export should match what the parser documentation describes before automation is built on them.
DefectDojo's Nexpose parser imports Rapid7 Nexpose XML 2.0 reports, produced from the console's XML Export report format. That is the format to select when configuring exports, since other report types may not parse. For sources outside the parsers named in the supplied documentation, such as Trivy or other commercial scanners, the correct approach is to check DefectDojo's current parser list before designing an automated import, because the supported formats and deduplication keys are parser-specific.
- Select the XML Export format: Use the console's XML Export report format rather than a generic report template.
- Check the XML 2.0 version: Confirm the schema version the console produces, since the parser is documented against Nexpose XML 2.0.
- Verify parser support for Trivy: Container and dependency scanning output may use a different parser, so confirm the parser name and accepted file type in the DefectDojo documentation for your version.
- Test each new source in staging: Import a sample report into a test product and review duplicate counts before connecting production feeds.
- Document unsupported exports: If a scanner has no matching parser, record the workaround, such as a normalized CSV, and who maintains it.
Confirm the parser name, file type and deduplication fields for each scanner against the DefectDojo version you deploy, since parser support changes between releases.
Which platforms fit a central tracker and why
A central tracker only works if the scanners feeding it and the edition hosting it match your access and assurance needs. The cards below cover the tracker editions, the upstream scanners that import into them, and the decision on central sign-on and MFA that separates one option from another.
DefectDojo open-source edition
The open-source edition is licensed under BSD-3-Clause and installs with Docker Compose, so a small platform team can run it inside its own network. It exposes a REST API (API v2) with client libraries, which is how scanner pipelines push findings in without manual uploads. The latest release, 3.4.101, was published on October 14, 2026. Check that local accounts are acceptable for your reviewers, because the open-source edition does not provide central sign-on, and plan how you will back up its database and attachments.
DefectDojo Pro for central access
DefectDojo Pro is offered as SaaS or self-hosted on Kubernetes or Docker Compose. According to the project README, Pro is listed from $100 per month and adds SSO with SAML, OIDC or OAuth, LDAP and MFA. Choose it when the tracker must sit behind your existing identity provider and enforce multi-factor authentication for every reviewer. Confirm with the vendor whether the price covers your user count, hosting model and support terms, and whether a self-hosted deployment is what your data rules require.
Greenbone Community as an upstream scanner
Greenbone Community Edition runs network vulnerability tests through the OpenVAS scanner, and gvmd, which is licensed AGPL-3.0, manages scans, users and results. The openvas-scanner component is licensed GPL-2.0. DefectDojo's OpenVAS parser imports Greenbone reports in CSV or XML, so results can flow into the central tracker on a schedule. Confirm that the Community Feed covers the products you run, because enterprise product tests are excluded from it, and size the containers before you schedule large scan windows.
ZAP as the web application scanner
The Zed Attack Proxy is licensed under Apache-2.0 and runs as a scanner for web applications and APIs. Its Automation Framework runs a YAML plan with spider and active scan jobs, and the exit codes let a pipeline fail on findings. DefectDojo imports ZAP XML reports, with or without requests and responses. The ZAP API requires an API key for all actions and is reachable only from the local machine by default, so keep it off shared networks and store the key in your secrets manager, not in the plan file.
Choosing the edition by access requirement
The deciding question is whether central SSO and MFA are mandatory for everyone who can view or change findings. If they are, Pro or another edition with those features is the starting point, and the open-source edition becomes a pilot or a tracker for a small, controlled group. If local accounts are acceptable under your access policy, the open-source edition is enough to start. Ask your auditors which access controls they will sample, and test the chosen edition against them before you migrate spreadsheets.
Rolling out DefectDojo in phases
The rollout moves a team from scattered spreadsheets to one tracked register of findings in controlled steps, with each phase producing a record that management, risk owners and assessors can review. The sequence is deliberately ordered so that deduplication and SLAs are proven on real imports before anyone relies on the numbers.
Inventory scanners, reports and owners
Start by listing every source that produces vulnerability data, including Greenbone, Trivy, ZAP, commercial scanners, cloud services and manual spreadsheets. For each source, record the report format, how it is exported, who runs it, which systems it covers and who owns the remediation of those systems. The step closes when the inventory is signed off by the teams that run each scanner and by the owners who will be accountable for fixes.
Deploy DefectDojo inside the client network
Install the open-source edition inside your own cloud account, data center or private network using Docker Compose or Kubernetes, based on the platform skills and operating model your team already runs. Decide the local account policy at this stage, including password rules, who can create accounts and how administrator access is granted. Confirm which identity features you need, because the README states that SSO with SAML, OIDC or OAuth, LDAP and MFA are DefectDojo Pro features. The step is done when the instance is reachable only from approved networks, backups are tested and the account policy is written down.
Map parsers and test deduplication keys
Import a representative report from each source into a test product and check how each parser builds its hashcode. Tenable reports use title and severity, while ZAP reports use title, CWE and severity, so the same weakness reported by two tools may or may not merge. Repeat imports with a second scan of the same target and confirm that existing findings are updated rather than duplicated. The step closes with a written mapping for each scanner that records the parser used, the deduplication fields and the known gaps, reviewed by the engineers who will import the data.
Agree SLA policy by severity in writing
Work with the risk owners to set remediation deadlines for each severity level, along with rules for accepted risk, false positives and exceptions. Record who may approve an exception, how long it may last and what evidence must be attached. Configure those deadlines in DefectDojo so that overdue findings are flagged automatically. The step is complete when the signed policy matches the configured SLAs and a sample set of findings shows the expected due dates.
Connect ticketing and set assignment rules
Integrate DefectDojo with the ticketing system your engineering teams use and define how findings are routed to teams, based on asset ownership, product or business unit. Decide which findings create tickets automatically, which require triage first and how ticket status flows back into the register. Test the integration with a small set of findings, including a closed ticket and a re-opened finding. The step is done when each test finding reaches the correct owner, and the ticket and the DefectDojo record stay in agreement.
Build management and examiner report templates
Design the reports that leadership, risk committees and internal or external auditors will request, such as open findings by severity, overdue items, exceptions with approvals and remediation trends over time. Confirm which reports DefectDojo produces natively and which need an export or a spreadsheet step. Review each template with the people who will receive it, so that the fields match the questions they actually ask. The step closes when a sample pack has been reviewed and accepted by its recipients.
Run parallel reporting and cut over
For a defined period, keep the existing spreadsheets alive while the same scans are imported into DefectDojo, then compare open counts, owners and due dates between the two. Investigate every difference and correct parser settings, deduplication behavior or assignment rules until the two views agree for each source. Once the team accepts the results, freeze the spreadsheets as a read-only archive and make DefectDojo the system of record. The step is complete when the cutover decision is documented and the archived spreadsheets are stored with the retention rules set by your compliance owner.
Questions teams ask before centralizing scanner findings
What drives the cost of centralizing scanner findings in DefectDojo?
The cost depends on the number of scanners, the report formats they produce, how many systems and owners the findings must reach, and how much reporting management expects. DefectDojo's open-source edition is licensed under BSD-3-Clause, so the software itself carries no license fee. The one-time costs are infrastructure, parser mapping for each scanner, the SLA and ownership model, and integration with ticketing. The recurring costs are hosting, upgrades, backups, and the time someone spends triaging new findings each cycle. Ask any partner to split its quote into one-time setup and recurring support, and to name which scanners and integrations are in scope. Any commercial DefectDojo Pro subscription should be quoted separately, since the vendor lists Pro pricing starting at $100 per month in its README.
How long does a DefectDojo centralization project take?
Duration depends mainly on how many scanners feed the platform and how much of each report needs custom mapping. A project with a few well-supported scanners and clean exports moves faster than one with legacy tools, inconsistent CSV layouts, or spreadsheets that must be migrated. Parser support also varies by tool, so each report type needs a test import and a review of its deduplication behavior before it goes live. Ask the partner for a written plan that lists each scanner, its export format, the parser used, the test import results, and the sign-off points. Do not accept a timeline that has not been tied to that inventory.
What does our team need to provide before implementation starts?
Three inputs decide whether the project runs smoothly: named asset owners, representative scanner exports, and written SLA sign-off. Asset owners decide who receives each finding and who accepts or rejects a risk. Sample exports from every scanner, including the settings used to generate them, let the partner test parsers against real data instead of assumptions. Management or the risk function must approve the remediation deadlines by severity, because DefectDojo can enforce those deadlines only after someone has defined them. Your team should also confirm where the platform will run, who holds administrator access, and which ticketing system receives the work.
Can a small team run DefectDojo alone with Docker Compose?
A capable engineering team can install the open-source edition with Docker Compose, which the DefectDojo README names as the install method for that edition. Installation is the easy part. Keeping the platform useful requires ongoing work: upgrading releases, backing up the database, managing user accounts, maintaining parser configurations when scanners change their export formats, and tuning deduplication. Teams with no one who owns those tasks often end up with a working instance and stale data. Decide who will run the platform each month, what happens during an upgrade, and how restores are tested before choosing a self-run model or a partner-supported one.
Does the open-source DefectDojo edition support SSO and MFA?
The open-source edition uses local accounts. According to the DefectDojo README, SSO with SAML, OIDC or OAuth, LDAP and MFA are features of DefectDojo Pro. That limit matters if your policy requires central sign-on or multi-factor authentication for every tool that holds vulnerability data, which many regulated frameworks expect for administrative and privileged access. Before deciding, check whether your identity platform can front the application, whether a compensating control is acceptable, and whether Pro's self-hosted option fits your environment. Pro is worth pricing when the identity requirement is mandatory, the user count makes local account management costly, or audit evidence must show central authentication logs.
How does DefectDojo deduplicate findings from multiple scanners?
DefectDojo compares findings using a hashcode defined for each parser. For example, the documentation says Tenable reports use title and severity, while ZAP reports use title, CWE and severity. When two scanners flag the same issue with different titles or severities, the platform may treat them as separate findings, and when unrelated issues share fields, it may merge them. Review the deduplication settings for each parser using sample data from your own environment before trusting the counts. Ask the partner to show how duplicate and merged findings are reviewed and reported.
How are deduplication errors found and corrected?
Errors are found by sampling: an analyst compares findings in DefectDojo against the raw scanner output for the same host or application and checks whether distinct issues were merged or identical ones were duplicated. Corrections happen in a controlled way, either by adjusting the parser's hashcode fields, reimporting a report, or marking a finding as a duplicate or closed with a recorded reason. Each change should be logged so auditors can see why a finding count moved. Plan a recurring review after each new scanner or parser update, and assign one person to approve changes to deduplication rules.
What evidence should a partner hand over at the end?
A usable handover includes the parser and version used for each scanner, the deduplication rules, the SLA table signed by the business owners, the ticketing integration design, the user and role list, backup and restore procedures, and sample management reports. Ask for the test import results and the record of any correction made during testing. Those artifacts show assessors how findings move from scanner to remediation, and they let your own team operate the platform after the project closes. Confirm the format and location of these documents in the written scope before work starts.
Evidence examiners and auditors ask for from the tracker
This table lists the records an examiner or auditor typically asks for from a DefectDojo tracker, the component that produces each one, and what the reader should confirm in their own setup. Use it to decide which records DefectDojo holds, which must come from scanner exports, and which belong in the ticketing system. The main takeaway is that DefectDojo is the system of record for findings and status, but SLA exceptions approvals and access reviews need their own documented process.
| Evidence item | Produced by | What to confirm before an assessment |
|---|---|---|
| Finding inventory with source scanner and first-seen date | DefectDojo import records, plus original scanner export files | Keep raw Greenbone, Trivy and ZAP exports with import dates so the first-seen date can be traced to source |
| Deduplicated finding history | DefectDojo deduplication using per-parser hashcode fields | Confirm which hashcode each parser uses and document any manual merges or duplicate decisions |
| Severity-based SLA records | DefectDojo finding due dates set from configured SLA rules | Record the SLA values in your written policy and confirm they match the dates shown in the tracker |
| Exceptions with approvals | Documented risk acceptance in DefectDojo, approval record in the ticketing system or GRC tool | Each accepted risk needs an approver, a reason, an expiry and a link to the compensating control |
| Remediation ticket linkage | Ticketing system (such as Jira) linked to DefectDojo findings | Confirm each finding links to a ticket and that closed tickets match closed findings |
| User access list | DefectDojo user and group records, reviewed against the identity provider | Open-source edition uses local accounts, so confirm how account reviews and removals are recorded |
| Audit trail of status changes | DefectDojo finding history and notes, backed by database and application logs | Retain logs outside the application host and confirm they capture who changed a status and when |
| Management reports | DefectDojo reporting, exported with scan coverage data from scanners | Confirm report definitions cover open, overdue and accepted findings by severity and by owner |
What to ask an implementation partner about DefectDojo
Start with parser coverage. List every scanner that will feed DefectDojo (Greenbone, Trivy, ZAP, and each commercial scanner in your estate) and ask the partner to show, for each one, which parser handles the exact export format you will use. DefectDojo's Tenable parser reads CSV and .nessus files, the Qualys VMDR parser reads CSV exports in QID-centric and CVE-centric variants, and the OpenVAS parser reads Greenbone CSV or XML. Ask for a sample import from each source, the parser name used, and a written list of any scanner whose output needs a custom conversion step. Confirm the parser behavior against the current DefectDojo parser documentation before accepting it, because export formats change between scanner versions.
Ask for a written deduplication test plan before any production import. DefectDojo matches duplicates with per-parser hashcode fields, such as title and severity for Tenable and title, CWE and severity for ZAP, so the same host can appear as new findings if a scanner changes a title. Request test cases that re-import the same report twice, import overlapping reports from two scanners, and change a scanner's finding title. Ask who signs off the results and what happens to findings that are wrongly merged or split. Also ask how SLAs and exceptions are approved and recorded: the partner should document who may accept a risk, the approval fields kept on each finding, the expiry rule for exceptions, and the report that lists overdue items.
Ask how local accounts will be secured. The open-source edition uses local accounts, while SSO with SAML, OIDC or OAuth, LDAP and MFA are listed as DefectDojo Pro features, so the partner should state which controls it can apply on the open-source edition (password policy, admin role limits, network restriction) and what changes if you need SSO later. Ask for the database backup schedule, restore test results and the upgrade procedure, including how the partner checks migrations on a copy before touching production. Finally, ask how configuration will be documented for auditors, and whether the scope is fixed or covered by a retainer. Written scope should separate the one-time build, parser setup and deduplication testing from recurring upgrades, backups and support.
