Cross-product AI surface
One AI layer across SAST, DAST, Fortify SCA, and Fortify on Demand. Programs running the full AppSec line get unified AI augmentation rather than per-scanner AI.
OpenText • Application security
OpenText Fortify Remediation Aviator (formerly OpenText Application Security Aviator) is the cross-product AI surface for OpenText AppSec, grounded in the customer's own findings, triage history, and codebase. It plugs into Fortify on Demand, SAST, DAST, and Fortify SCA so AI suggestions reflect the actual program rather than generic LLM output.
A Merito Aviator engagement starts with grounding configuration against the customer's Fortify findings and prior triage decisions, pairs Aviator with the rest of the AppSec portfolio, and pilots on a single application before broad rollout so AI augments the program instead of replacing scanning with hallucinated suggestions.
What it is
Fortify Remediation Aviator is the AI augmentation layer for the OpenText Cybersecurity AppSec line. It is the same Aviator pattern OpenText runs across Software Delivery Aviator (test generation, defect clustering on the DevOps catalog) and Content Aviator (grounded search on the Content catalog), applied to AppSec specifically. Aviator is not a replacement for SAST, DAST, or SCA. It sits on top of those scanners and turns their findings into developer-aware triage, remediation guidance, and risk-aware reporting.
Grounding is the load-bearing technical claim. Aviator reads from the customer's actual Fortify findings, triage history, and source code rather than from a generic public-code corpus. Vendors that fine-tune AppSec AI on public code without hooking into the customer's findings store give plausible suggestions that miss internal coding conventions, mandated wrappers, and compensating-control logic. Aviator's suggestions are grounded in the actual program, which is the entire reason to layer AI on AppSec instead of buying a generic coding assistant.
Cross-product coverage is the platform claim. Aviator works on SAST findings (suggesting fixes for static-analysis flow paths), DAST findings (correlating dynamic findings with source-level fixes), Fortify SCA findings (proposing dependency upgrade paths and reachability-aware triage), and Fortify on Demand as the unifying SaaS surface. Programs running multiple OpenText AppSec scanners get AI augmentation across the whole line; programs running only one get a more limited Aviator footprint.
Aviator goes wrong when teams treat its output as autonomous. The agent proposes, and the AppSec analyst and developer decide. Programs that auto-merge AI suggestions ship regressions, while programs that treat suggestions as a high-quality first draft for human review ship faster with fewer false starts. Merito's engagement defines the supervision boundary, tunes the grounding against the customer's findings store, and pilots Aviator on a single application before broad rollout. Customer adoption of Aviator is still early and the AppSec team should validate suggestion quality on real findings before committing to enterprise scale.
Ideal use cases
What it is best at
One AI layer across SAST, DAST, Fortify SCA, and Fortify on Demand. Programs running the full AppSec line get unified AI augmentation rather than per-scanner AI.
Reads from the customer's actual Fortify findings, triage history, and codebase. Generic AppSec AI fine-tuned on public code cannot match that grounding.
Customers running Software Delivery Aviator or Content Aviator already have the operational pattern. Adopting Fortify Remediation Aviator extends a known surface rather than introducing a new AI shape.
Every AI suggestion is logged with grounding context for regulated AppSec audits. Programs using AI in regulated workloads get the trail they need.
Designed to run on a single application first, validate suggestion quality, and then expand. Programs that scale Aviator across the portfolio without piloting often regret it.
Core capabilities
Where Aviator adds value across the AppSec line.
SAST fix suggestions
Reads SAST findings from Fortify Static Application Security Testing and proposes fixes grounded in the flow path and the customer's codebase.
DAST and SAST correlation
Correlates dynamic findings from Dynamic Application Security Testing with source-level fixes in the codebase. Single triage view across runtime and source.
Fortify SCA triage
Proposes dependency upgrade paths, reachability-aware triage, and license-policy guidance on Fortify SCA findings.
Fortify on Demand unification
Aviator output flows through Fortify on Demand as the unifying SaaS surface across the AppSec line.
What makes Aviator work better than generic AppSec AI.
Findings-store grounding
Reads from the customer's actual Fortify findings, suppression history, and triage decisions to produce suggestions grounded in the program.
Codebase context
Consumes the customer's codebase patterns so suggestions match the team's actual coding conventions, internal wrappers, and compensating-control logic.
Supervision boundaries
Configurable boundaries on what suggestions can be auto-accepted versus what requires human review. Auto-accept is off by default for regulated workloads.
Audit logging
Every AI suggestion logged with grounding context, suggestion content, and disposition for audit-ready trails.
AI augmentation in the workflow, not a separate dashboard.
IDE integration
VS Code, IntelliJ, and Eclipse plugins surface Aviator suggestions during authoring.
PR review surfaces
GitHub, GitLab, Bitbucket, and Azure DevOps Repos integration so suggestions land on PR comments.
Ticketing integration
Suggestions flow into Jira, Azure Boards, and ServiceNow alongside the underlying findings.
Reporting and metrics
Suggestion-acceptance rate, time-to-remediation, and false-positive rate exported for AppSec program reporting.
Where it fits in the stack
Deployment and implementation
Licensing and packaging
Fortify Remediation Aviator with Fortify on Demand
Aviator paired with the Fortify on Demand SaaS bundle (SAST + DAST + Fortify SCA).
Best for: Programs running Fortify on Demand as the unifying AppSec platform.
Fortify Remediation Aviator with standalone scanners
Aviator paired with standalone SAST, DAST, or Fortify SCA licenses.
Best for: Programs running specific OpenText AppSec scanners without the Fortify on Demand bundle.
Merito services
Pick the engagement that matches where you are in the lifecycle.
Grounding configuration, IDE and PR-review wiring, supervision-boundary design, pilot-to-rollout planning.
Explore serviceAppSec AI augmentation scoping for Fortify Remediation Aviator alongside Checkmarx Developer Assist and generic coding AI.
Explore serviceChampion programs that teach developers to treat Aviator fix suggestions as a first draft for review, not autonomous output.
Explore serviceNamed engineer, priority SLAs, and release-time coverage for Fortify Remediation Aviator.
Explore serviceLong-term run support including grounding maintenance, supervision-boundary tuning, and rollout to additional applications.
Explore serviceGrounding workshops and supervision-boundary design for AppSec architects, plus sessions for the developers who act on Aviator suggestions.
Explore serviceAppSec engineers who know Fortify findings and Aviator grounding, working inside your team through the pilot and the rollout that follows.
Explore serviceOpenText Fortify Remediation Aviator licensing
Aviator pricing arrives with grounding configuration, supervision-boundary design, IDE and PR-review wiring, and pilot-to-rollout planning that turn AI augmentation into a defensible AppSec capability rather than a checkbox subscription.
Merito point of view
Programs that adopted generic coding AI assistants for AppSec work have ended up with plausible-looking suggestions that ignore internal crypto wrappers and mandatory input gateways, and with code that fails their own coding standards. The reason is grounding. Aviator works because it reads from the customer's actual Fortify findings, triage history, and codebase rather than from a public-code corpus. That makes the suggestions correct for this team rather than confidently wrong.
Aviator is the right fit when the AppSec program already runs OpenText AppSec scanners (Fortify SAST, DAST, Fortify SCA, or Fortify on Demand), when the team is willing to pilot before scaling, and when AI augmentation is a workflow improvement rather than a headcount-replacement claim. Without an existing OpenText AppSec footprint, Aviator does not apply. For programs running Checkmarx, Developer Assist and Triage and Remediation are the equivalent grounded AI options.
Customer adoption of Aviator across the OpenText AppSec line is still early, so a pilot on a single application has to come before broad rollout. The supervision boundary, meaning which suggestions can be auto-accepted and which need human review, decides how much risk Aviator carries, so it should start conservative and loosen only as suggestion quality is proven.
What buyers usually underestimate
Related from Merito
Related solutions
Related services
Related products
Frequently Asked Questions
Consultation request
Share your existing OpenText AppSec footprint and your AI augmentation goals. A Merito OpenText specialist follows up within one business day.
Grounded AI
Aviator reads from the customer's Fortify findings store. Generic coding LLMs cannot match that grounding.
Pilot first
Aviator adoption is early. One application is piloted and its suggestion quality measured before enterprise rollout.
Next step
A Merito Fortify Remediation Aviator engagement starts with grounding configuration and pilot validation. Generic coding AI suggestions look correct and frequently are not.