Open Pentest Format (OPF) Integration with DefectDojo

Open Pentest Format (OPF) Integration with DefectDojo

The Open Pentest Format (OPF) is a portable JSON format for penetration test findings and finding libraries. It describes individual findings, either reusable templates or results from a specific engagement, with fields for severity, CVSS score and vector, CWE and CVE IDs, impact, recommendation, steps to reproduce, references, and affected assets. OPF is maintained by Cairn, a penetration testing platform, and the specification is published under CC0 1.0, with the schema and examples on GitHub. The current version is 1.1, and DefectDojo imports .opf.json files.

Open Pentest Format (OPF) Integration with DefectDojo

We ask our testing partners for Open Pentest Format (OPF) files because a PDF report is where pentest findings go to be forgotten. With OPF, DefectDojo imports each finding as a structured record on the Asset that was tested, with CVSS, CWE, reproduction steps, and the recommendation already in the right fields. Manual test results then sit next to our scanner findings, follow the same SLAs, and can be retested and closed like anything else.

Why Open Pentest Format (OPF) Matters

Penetration tests produce some of the most valuable findings a security program gets, and some of the hardest to track, because they usually arrive as documents.

• OPF gives pentest findings a structure, so they can move between tools without retyping.
• It carries the details a developer needs: impact, numbered reproduction steps, a recommendation, and references.
• It records affected assets as URLs, source paths, or cloud resource identifiers, which ties each finding to something concrete.
• It is free to implement, so testers and tool vendors don't need a license to produce it.

Advantages of This Integration

• Pentest findings become tracked work. Each OPF finding becomes a DefectDojo Finding that can be assigned, put under an SLA, pushed to Jira, and closed when a retest confirms the fix.
• Fields land where they belong. Recommendation maps to Mitigation, impact to Impact, steps to Steps to Reproduce, and references to References, instead of everything piling into one description.
• CVSS handled by version. DefectDojo detects whether the CVSS vector is v3 or v4 and stores it in the matching field with a computed score, falling back to the tool's score when no vector can be used.
• Endpoints for web findings. Affected assets written as URLs become DefectDojo endpoints, while source paths and ARNs are listed in the description.
• Comparable results over time. Reimporting a retest into the same Test mitigates findings that are gone and keeps one history per issue, so year-over-year pentest results are easy to compare.

How This Integration Works

DefectDojo imports OPF files with the OPF Scan scan type.

1. Get an OPF file. Export the engagement's findings from a tool that writes OPF (Cairn exports it, and Cairn publishes converter tools for other formats), or ask your testing provider for an .opf.json deliverable. The parser expects a JSON object with a findings array; findings without a title are skipped.

2. Import it. In the UI, open the Engagement for the test, choose Import Scan Results, select OPF Scan, and upload the file. To automate, use the API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=OPF Scan" 
  -F "file=@q3-pentest.opf.json" 
  -F "product_name=customer-portal" 
  -F "engagement_name=Q3 Penetration Test" 
  -F "auto_create_context=true"

DefectDojo Pro users can use Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "OPF Scan" 
  --report-path "./q3-pentest.opf.json" 
  --product-name "customer-portal" 
  --engagement-name "Q3 Penetration Test" 
  --auto-create-context

3. Import the retest. When the tester delivers a retest file, reimport it into the same Test with /api/v2/reimport-scan/. Findings missing from the retest are mitigated, and findings still present stay open with their history.

HTML markup in the description, impact, recommendation, and reproduction steps is converted to plain text, with paragraphs and list items kept as line breaks.

Data Granularity: What Gets Imported

Use Cases

Annual third-party pentest: The provider delivers an OPF file with the report. The security team imports it into the tested Asset, assigns findings to the owning teams, and the SLA clock starts the day the findings land rather than when someone transcribes the PDF.

Retest verification: After fixes ship, the tester sends a retest OPF file. Reimporting it closes what was fixed and leaves what wasn't, which gives a clear record for the remediation report.

Internal red team or AppSec reviews: An internal team that writes findings in a tool supporting OPF imports them the same way, so manual review results and scanner results share one backlog and one set of metrics.

Mapping manual findings to frameworks: OWASP category and MITRE technique values become tags, so a security lead can filter manual findings by category for reporting or training priorities.

Operational Tips

• Use one Engagement per pentest and one Test per deliverable, and reimport retests into that Test. That keeps the before and after in one place.
• Deduplication hashes title, CWE, severity, and description. If a tester rewrites a finding's description in the retest, it will import as new, so ask providers to keep finding text stable between the initial and retest files.
• Ask testers to write affected web assets as full URLs. Only values containing a scheme become endpoints; bare hostnames and paths stay in the description.
• Supply a CVSS vector rather than only a score. A v3 or v4 vector is parsed and scored by DefectDojo; a v2 vector has no field to hold it, so the provided score is used instead.
• Set SLAs for manual findings with the delivery date in mind. Findings are dated from the file's export date when it is present.
• Risk-accept findings the business won't fix before the next test, with an expiry date, so they're reviewed again when the next OPF file arrives.