OpenText Application Security Aviator

Application Security Aviator is the AI augmentation layer for the OpenText Cybersecurity AppSec line. It is the same Aviator pattern OpenText runs across DevOps 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), Core SCA findings (proposing dependency upgrade paths and reachability-aware triage), and Core Application Security 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.

What disrupts Aviator adoption is treating it as autonomous output. The agent proposes; the AppSec analyst and developer decide. Programs that auto-merge AI suggestions ship regressions; 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.

Merito has watched programs adopt generic coding AI assistants for AppSec workflow, generate plausible-looking suggestions that ignore internal crypto wrappers and mandatory input gateways, and ship code that fails the customer's 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.

Merito recommends Aviator specifically when the AppSec program already runs OpenText AppSec scanners (Fortify SAST, DAST, Core SCA, or Core Application Security), when the team is willing to pilot before scaling, and when AI augmentation is a workflow improvement rather than a headcount-replacement claim. For programs 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. Merito treats pilot validation on a single application as non-negotiable before broad rollout. The supervision boundary (what suggestions can be auto-accepted versus what requires human review) is the single most important configuration decision and should be set conservatively at first.