OpenText Fortify Remediation Aviator: Audit every finding, fix what’s real.
How Fortify Remediation Aviator audits findings, correlates SAST and DAST, and shreds the backlog.

New here? Start with part 1: the AppSec triage problem, and part 2: the proof at scale.
If your security backlog is growing faster than your team can clear it, the answer is not another scanner. It is intelligent automation of the work between the scan and the resolution: triage, prioritization, and guided fixes. That is what https://www.opentext.com/products/application-security-aviatorOpenText™ Fortify™ Remediation Aviator™ does, and it builds on the Fortify static analysis you may already run, so the depth of detection you rely on stays exactly where it is.
What it does, starting with the audit
Fortify Remediation Aviator is an AI code security assistant. It audits your SAST results, sorting true positives from false positives and explaining the reasoning in plain language next to the code, so a developer sees not just what was flagged but why it is, or is not, a real issue. High-confidence false positives can be suppressed so your team stops re-litigating the same noise scan after scan. For confirmed issues, Aviator suggests a contextual fix a developer can review and apply, with optional auto-remediation where it is safe. Triage is the core value; the fix follows from it. Coverage spans 44+ languages and a broad set of vulnerability categories.
New in 26.3: SAST and DAST correlation
A single vulnerability often shows up twice. A static scan flags it in the source code, anchored to a line. A dynamic scan flags it against the running application, anchored to a URL. On their own, those look like two separate findings in two separate tools. Aviator now uses AI to correlate them, matching the static finding and the dynamic finding that describe the same underlying issue. Take a SQL injection flaw: SAST points to the exact line where untrusted input reaches a query, and DAST confirms the same weakness is reachable and exploitable through a live endpoint. Correlated, they become one high-confidence finding rather than two you have to reconcile by hand. Your team can prioritize what is both present in the code and exploitable at runtime, instead of guessing which findings deserve attention first.
Built to scale without re-plumbing your pipelines
Aviator runs server-side and can be enabled centrally through OpenText Application Security, so findings are enriched once and made available to developers in the workflows they already use. There is no new tool for every developer to install and no pipeline to rebuild. It operates on your existing scan results, fits SaaS, off-cloud, Fortify Hosted, and Fortify on Demand, and scales with your portfolio instead of your headcount.
Private by design, with no LLM bill to manage
Trust matters as much as capability. Your source code is not used to train the model, and it is not stored or learned from. Only the relevant portions of code are sent for analysis, under a contractual confidentiality agreement with the model provider. And because model costs are included in the subscription, there is no separate LLM bill for your team to forecast, meter, or manage. The economics are predictable, and the privacy posture is one you can put in front of your own security review.
It builds on what you already own
https://www.opentext.com/products/application-security-aviatorFortify Remediation Aviator is an add-on to OpenText™ Fortify™ SAST and OpenText™ Fortify™ on Demand. If you already run Fortify, you already have the detection depth; Aviator turns that output into triaged, prioritized, fixable work, and gives your team back the hours that used to disappear into manual review. If you are earlier in your journey, it is a reason to start with a platform that treats triage and remediation as first-class problems, not afterthoughts.
See it on your own findings: Request a demo.
This is part 3 of a three-part series on the application security triage bottleneck. Read the rest for the full picture:
Part 1: The AppSec bottleneck isn’t finding vulnerabilities. It’s everything after. — Why the bottleneck sits after the scan.
Part 2: 3 million minutes back: putting AI on the AppSec backlog — The approach and the proof at scale.




