Vulnerability management requirements checklist

A single finding often arrives from several scanners, and the duplicates are what make a backlog unmanageable. A missing patch on an internal web server can show up in a Greenbone report, a Tenable export and a Trivy scan of the same host's packages, each with its own wording. DefectDojo reduces that noise by computing a hashcode per finding, and the fields it uses depend on the parser. For Tenable reports the hashcode is built from title and severity, while for ZAP reports it uses title, CWE and severity. Those rules are sensible defaults, but they can merge findings that should stay separate or split findings that should match, so the requirement is to document which fields each scanner feeds into the hashcode and to decide whether that matches how your team counts a vulnerability.

Deduplication only helps if every surviving finding has an owner, a remediation deadline set by severity and a defined path for exceptions. Your checklist should require deadlines per severity level that the security and IT leadership have approved in writing, assignment of each finding to a named team or asset owner, and a risk acceptance workflow that records who approved a deferred fix, why, and when the decision expires. Ticketing integration is the step that turns those records into work. Confirm with your ticketing vendor how DefectDojo's findings and status changes will create, update and close tickets, and whether closed tickets reopen findings when a scan still detects the issue.

Test deduplication with overlapping reports from your own scanners before you commit. Export the same hosts from each scanner you plan to use, import them into a test instance, and count how many findings collapse, how many merge incorrectly and how many duplicates survive. Check that a risk acceptance on one finding does not silently cover a different issue, and that a rescan closes the right items. Ask any implementation partner to show this test on your data, not on a vendor sample, and record the results as part of the design evidence you will need for audits.

The program should be able to produce five kinds of record on request: scan schedules, scan coverage reports, remediation timelines by severity, exception approvals and rescan results. A schedule shows what was scanned, how often and with which profile. A coverage report compares that schedule against the asset inventory, so an assessor can see which hosts, containers and dependencies were never scanned. Remediation timelines show when each finding was opened, assigned, fixed or accepted, measured against the deadline set for its severity. Exception approvals record who accepted a risk, why, for how long and with which compensating control. Rescan results prove that a fix was verified, not just reported as done. Greenbone and Trivy can produce the underlying scan output, and DefectDojo can hold findings, deadlines and approval history in one place, but the reader should confirm which of these records each tool keeps natively and which must be exported or assembled by hand.

Frameworks do not agree on cadence or deadlines. One framework may require quarterly internal scans, another may require continuous monitoring with deadlines set by the agency, and a third may leave the interval to a documented risk analysis. Before the program sets its SLAs, the team should list every framework that applies to the environment and write down the scan frequency and remediation expectation each one states, then choose the stricter value wherever two overlap. The sector and framework pages in this group cover those specifics, and this checklist should not be read as a substitute for them. Where a framework does not state a number, the organization should document its own interval and justify it in the risk analysis, because an assessor will test whether the stated schedule was followed.

DeployOpen prepares systems, controls and evidence for compliance assessments, including scan configuration, reporting templates and evidence folders. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors or certification bodies make those determinations. Before building any report, confirm with the assessor which format, sampling period and level of detail they expect, whether they want raw scanner exports or summarized dashboards, and how they want exceptions documented. Agree that format in writing during scoping so the reporting work is built once and not reworked at audit time.

The requirements that most often separate one platform from another are rarely the ones on the feature list. Ask how each candidate handles authenticated scan success on mixed estates: the share of Windows, Linux, network appliance and container hosts where credentials actually log in and return package data, not just open ports. A scanner that reports hundreds of hosts as scanned but only sees open ports produces findings that look complete and are not. Ask for the credential types each tool supports, how it reports a failed login, and whether a failed login is flagged in the report rather than silently downgraded.

Next, test false positive handling and duplicate handling across scanners. Greenbone, Trivy and any commercial scanner will report the same CVE on the same package under different titles and identifiers. Check whether the tracking layer, such as DefectDojo, deduplicates these with per-parser hashcode fields, as its documentation describes, and whether suppressions and risk acceptances carry over when a finding is re-imported. Confirm the feed licensing and update path: which vulnerability tests are in the free feed, which need an enterprise feed, and how updates reach an isolated network. Feed gaps show up as missing findings, so ask for the exact list of covered products in your environment.

Finally, run a proof of concept against a sample of your own assets, with pass or fail criteria written before the first scan. A reasonable sample includes one domain controller, one database server, one container host, one network device and one system you already know is vulnerable. Set criteria such as: credentialed login succeeds on every sampled host, the known vulnerable system is flagged, duplicates collapse to one ticket, the API completeness for ticketing test (create, update and close a finding through the API, as your ticketing system requires) passes, and an auditor can read the report without a walkthrough. Agree the criteria with your security and audit leads, record the results, and let a failed criterion decide the shortlist.