Fortify Integration with DefectDojo

Fortify Integration with DefectDojo

Fortify is a family of application security testing products now owned by OpenText, which acquired it with Micro Focus. Its static analysis engine, Fortify Static Code Analyzer (renamed OpenText Static Application Security Testing, or OpenText SAST), scans source code in many languages for security flaws such as injection, insecure cryptography, and unsafe data handling, and writes results to an FPR file. FPR files are reviewed in Fortify's audit tools or Software Security Center (now OpenText Application Security), and can be converted to XML with Fortify's ReportGenerator. DefectDojo imports both FPR and XML, and DefectDojo Pro adds a Fortify connector for Software Security Center (SSC) and Fortify on Demand (FoD).

Fortify Integration with DefectDojo

Fortify is our deepest static analyzer, and it is also the one whose results are hardest to share. FPR files open in Fortify's own tools, and developers outside the AppSec team rarely look at them. Importing Fortify results into DefectDojo puts every issue on the Asset that owns the code, with the CWE, the vulnerable file and line, Fortify's recommendation text, and any suppressions or comments our auditors already made. From there it gets an owner, an SLA, and a ticket, just like findings from our other scanners. On DefectDojo Pro, the Fortify connector can pull issues straight from SSC or Fortify on Demand, so nobody has to move FPR files around.

Why Fortify Matters

Data-flow static analysis finds classes of vulnerability that pattern matching and dependency scanning can't.

• Fortify traces untrusted input from where it enters the application to where it is used, which is how injection and similar flaws are found.
• It supports a wide range of languages, which matters for organizations with older Java, .NET, and C/C++ code alongside newer services.
• Its rule metadata (impact, likelihood, CWE mapping, and remediation guidance) gives each issue context beyond a line number.
• FPR results live inside Fortify tooling, which separates them from the rest of an application's risk picture.

Advantages of This Integration

What we gained by routing Fortify results through DefectDojo:

• Fortify's priority preserved. For FPR imports, DefectDojo computes severity from the rule's impact and the issue's likelihood, the same model Fortify uses for its Critical, High, Medium, and Low priorities.
• Audit decisions carried over. When an FPR includes audit.xml, issues marked suppressed import as inactive false positives, and auditors' threaded comments appear in the finding's Impact field.
• CWE and code location. FPR findings carry the CWE from Fortify's rule metadata, plus the file path and line, so reporting by weakness class works across tools.
• Reimport lifecycle. Reimporting the next scan into the same Test mitigates issues that were fixed and adds new ones.
• Account-wide sync with DefectDojo Pro. The Fortify connector discovers every application (SSC project version or FoD release), creates a Record for each, and imports its issues on a schedule, with audit outcomes such as "Not an Issue" carried over.
• Ownership outside Fortify. Findings can be assigned, pushed to Jira, and tracked against SLAs by developers who never open a Fortify tool.

How This Integration Works

DefectDojo provides two scan types for Fortify: Fortify Scan and Fortify Scan v2. Both accept .fpr and .xml files and choose the parser by file extension, so keep the extension on the file you upload. They differ only for FPR imports: Fortify Scan records the first line of the code snippet (which can include up to three lines of leading context), while Fortify Scan v2 records the line Fortify reports for the vulnerability itself. Use v2 for new Assets, especially when deduplicating on file and line across tools. Existing Assets can stay on Fortify Scan, because switching changes hashcodes.

1. Produce the results. A static scan writes an FPR file:

sourceanalyzer -b payments-api -scan -f payments-api.fpr

To import XML instead, convert the FPR with ReportGenerator. By default ReportGenerator lists only one issue per category, so use the DefaultReportDefinitionAllIssues.xml template from the DefectDojo repository (copied into Fortify's Core/config/reports directory):

ReportGenerator -format xml -f payments-api.xml -source payments-api.fpr -template DefaultReportDefinitionAllIssues.xml

2. Import the file. In the UI, open the Engagement, choose Import Scan Results, select Fortify Scan v2, and upload the file. To automate, use the import API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Fortify Scan v2" \
  -F "file=@payments-api.fpr" \
  -F "product_name=payments-api" \
  -F "engagement_name=Fortify SAST" \
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "Fortify Scan v2" \
  --report-path "./payments-api.fpr" \
  --product-name "payments-api" \
  --engagement-name "Fortify SAST" \
  --auto-create-context

The XML parser also recognizes the report format that Fortify WebInspect (now OpenText DAST) introduced in version 24.2, producing findings with a host endpoint and the raw response attached.

Option: Fortify connector (DefectDojo Pro). Instead of exporting files, configure the Fortify connector in the DefectDojo Pro UI. It covers both editions:

• Location: the Fortify base URL. For SSC, your server host (the connector adds /ssc/api/v1). For FoD, the API host for your region, for example https://api.ams.fortify.com.
• Edition: SSC or FoD.
• Client ID: the FoD OAuth Client ID. Leave it blank for SSC.
• Token / Client Secret: for SSC, a FortifyToken (CIToken or UnifiedLoginToken) created under Administration > Token Management. For FoD, the OAuth client secret from Settings > API, with the api-tenant scope.
• Minimum Severity: optional, limits which findings are imported.

The connector syncs the whole account. Each application becomes a Record that you map to an Asset.

Data Granularity: What Gets Imported

The table describes FPR imports, which carry the most detail.

XML from ReportGenerator maps differently: the title is Category - FileName: LineStart, severity comes from Fortify's priority (Friority) field, the description includes the abstract, snippet, source snippet, and explanation, and the issue ID becomes the unique ID. Issues with the same title appear once.

The DefectDojo Pro connector maps each Fortify issue directly. Severity comes from Fortify's friority rating (Critical, High, Medium, Low), and the title combines the issue category with its file and line. File path, line, kingdom, analyzer, and engine type are carried over. Static analysis issues are recorded as static findings and WebInspect (DAST) issues as dynamic findings. Suppressed, removed, and hidden issues are skipped, issues audited "Not an Issue" are marked false positive, and "Exploitable" or reviewed issues are marked verified.

Use Cases

In a release pipeline: A build stage runs a Fortify scan and reimports the FPR into the Asset's Fortify Test. Developers see new Critical and High issues in DefectDojo or Jira without access to Fortify's audit tools.

Keeping audit work: An AppSec team that already reviews issues in Fortify suppresses false positives and adds comments there. Importing the audited FPR carries those decisions into DefectDojo, so nobody triages the same issue twice.

Correlating with other SAST tools: With a CWE and file location on each finding, results from Fortify and a second static analyzer for the same repository can be compared on one Asset. Fortify Scan v2's precise line number makes that comparison more reliable.

Portfolio reporting: Security leaders get open Fortify findings by Organization and Asset, with SLA status, instead of collecting per-project reports.

Operational Tips

• Prefer FPR over XML. FPR imports carry CWE, the computed priority, audit suppressions, and comments, which the XML path does not.
• Start new Assets on Fortify Scan v2, and don't switch an existing Asset between the two scan types, or every finding will look new.
• If you import XML, always use the all-issues report template. The default template drops all but one issue per category.
• Upload files with their real .fpr or .xml extension. The parser rejects any other extension.
• Suppress noise in Fortify before export where possible, so the import arrives with false positives already marked.
• On DefectDojo Pro, pick one path per application. The connector and the file parsers build titles differently, so mixing connector syncs and FPR imports on one Asset can show the same issue twice. The SSC token and FoD client secret are never logged.
• Use minimum_severity to start with Critical and High findings on large legacy code bases, then lower it as the backlog shrinks.