3 million minutes back: putting AI on the AppSec backlog

New here? Start with part 1: The AppSec bottleneck isn’t finding vulnerabilities. It’s everything after.

In part one, we argued that the application security bottleneck sits after the scan, in triage and remediation, not in detection. The obvious question is what to do about it. The answer is not more scanning, and it is not blind auto-fixing. It is applying AI to the triage itself, carefully, with a human in the loop. This is also the answer to the louder question in the market. AI is not making application security obsolete. It is raising the volume of code and findings, which makes disciplined, governed remediation more valuable, not less.

Here is the approach, and the proof from putting it into production across OpenText’s own enterprise application portfolio.

How AI actually clears the backlog

Start with the goal. Not to find more issues, but to clear the ones you already have. OpenText^TM Fortify^TM Remediation Aviator^TM works on the findings your scans have already produced, and it moves them off the backlog in two steps.

First, it audits. Aviator reviews every finding, decides true positive or false positive, and explains its reasoning in plain language next to the code. This is where the backlog shrinks fastest, because a large share of any SAST backlog is noise, and every false positive Aviator confirms and suppresses is one your team never has to open again. Mean time to triage is where those hours were hiding, and it is exactly what our own deployment cut by 70 percent.

Then it remediates. For the issues that are real, Aviator produces a contextual fix the developer can review and apply, with optional auto-remediation where it is safe. Because the finding arrives already audited and explained, the developer trusts it and acts, instead of reassessing whether the finding is valid before touching the code. Triage is what makes the fix fast. The fix is what finally takes the issue off the list.

The order is the point. Auto-fixing code the tool was never confident about, or pushing changes silently into a repository, is how AI loses a developer’s trust. Audit first, then remediate, with a person in the loop, is how it earns a place in the workflow and actually shreds the backlog.

A few principles separate a responsible approach from the hype:

• It runs at scale without changing every developer’s pipeline, so adoption does not depend on a company-wide migration.
• It works inside the tools developers already use, so there is no new console to learn and no context to switch.
• It respects your code. The model does not train on, store, or learn from your source, and only the relevant code is sent for analysis.

We proved it on ourselves first

OpenText develops and maintains thousands of enterprise applications with more than 7,000 developers. That scale is unforgiving: any weakness in accuracy or throughput shows up immediately, and at volume, small error rates become large problems fast. So before asking any customer to trust it, we deployed our own AI auditing capability, now Fortify Remediation Aviator, against our own environment, and measured what happened.

The results, in the first eight weeks

From the guide, “AI AppSec, proven at scale: OpenText’s blueprint and outcomes”:

• 1,500 applications onboarded
• More than 300,000 findings analyzed and dispositioned
• Mean time to triage reduced by 70 percent
• Roughly 3 million minutes of manual review removed, about 50,000 hours, a productivity gain equivalent to 29 full-time engineers
• Developer satisfaction with security reviews improved in internal surveys

Read the 29-engineer figure carefully. It does not mean 29 people were removed. It means the equivalent of 29 full-time engineers’ worth of manual review time was handed back to the business and reinvested in building product. And a 70 percent cut in mean time to triage is the difference between a backlog that grows every sprint and one a team can finally keep pace with.

Why it scaled, the part people miss

The numbers came from adoption, and adoption came from developer experience. Automation that developers do not trust gets ignored, and automation that adds friction gets routed around. Aviator earned its place by presenting clear explanations and copy-ready guidance directly in the workflows developers already use, which cut review fatigue and cognitive load rather than adding to them. Because it was low-friction and the results held up under scrutiny, it spread organically across teams, regardless of language or toolchain. That is the lesson worth taking. Automation alone does not scale a security program. A developer-centric experience does.

Security teams can’t win by doing more manual work. They win by automating intelligently

— Frans van Buul, Director, Product Management, OpenText

Read the full blueprint: AI AppSec, proven at scale  (deployment model and the economics behind the numbers).

This is part 2 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.  —  The challenge this series is built around.

Part 3 (coming Sept. 3): Audit every finding, fix what’s real: inside Fortify Remediation Aviator  —  How OpenText delivers this, including SAST and DAST correlation.