OpenText Static Application Security Testing

OpenText Static Application Security Testing carries the Fortify Static Code Analyzer engine that has been in regulated production for two decades. The engine covers Java, JavaScript, TypeScript, C#, .NET, Python, Go, C, C++, Objective-C, Swift, Kotlin, Salesforce Apex, COBOL, ABAP, PL/SQL, and more, with both source-code and binary-code analysis. The binary-code analysis matters for regulated programs that need to scan vendor-supplied components without source.

Where Fortify SAST has historically differentiated is on regulated and legacy stacks. Programs running mainframe-adjacent COBOL alongside modern Java microservices, or Salesforce Apex alongside .NET enterprise applications, get one engine across the line. Single-language SAST tools force enterprises to bolt together specialist scanners; Fortify covers the modern and the legacy in one product. The 2024-2025 rebrand from Fortify SAST to OpenText Static Application Security Testing is cosmetic at the engine level.

Hybrid deployment is the operational shape. Programs run SAST inside Core Application Security as SaaS, on-prem for regulated workloads where SaaS is not permitted, or as bring-your-own-cloud (BYOC) for hybrid programs. The engine and findings model are consistent across deployment shapes, so AppSec programs that run hybrid (some applications in SaaS, others on-prem) get one operational pattern. Customers running on-prem-only Fortify Static Code Analyzer and considering modernization should look at the SaaS unification through Core Application Security as the operational target.

What disrupts SAST adoption is policy drift. Programs that take vendor-default policies and never tune them generate huge false-positive volumes, lose developer trust by month two, and eventually become a checkbox scan that nobody reads. Merito's engagement starts with policy tuning to the customer's actual risk tolerance, suppression discipline that is auditable rather than a graveyard of ignored findings, and PR-time integration so developers see results in the workflow they already use. Without that, even the best engine generates noise.

Merito has rolled out OpenText Static Application Security Testing (formerly Fortify SAST) on programs where the engine works fine, language coverage is solid, and the backlog still grows uncontrollably. The cause is policy drift. Vendor defaults generate noise, suppressions accumulate as a permanent ignore list, and findings flow to a queue nobody owns. Those are policy and operating-model problems; no SAST replacement fixes them.

Merito recommends OpenText SAST specifically when the program needs broad language coverage including legacy and enterprise stacks (COBOL, Apex, ABAP), when source plus binary analysis matters for vendor-supplied components, and when regulated compliance posture (FedRAMP, HIPAA, PCI DSS) is a buying criterion. For programs already running mature Checkmarx One pipelines, replacing them with OpenText SAST is a 12-month project that often does not deliver enough delta to justify the disruption. Merito runs that decision honestly.

The hybrid deployment model is real. Programs running SaaS for some applications and on-prem for regulated workloads share the engine and findings model. Most modernization engagements move toward the SaaS path through Core Application Security; on-prem remains the right answer for programs with regulatory constraints that rule out SaaS scanning.