OpenText • Application security
OpenText Fortify SAST (formerly OpenText Static Application Security Testing, and originally Fortify Static Code Analyzer) covers modern and legacy stacks (including COBOL, Apex, mainframe-adjacent code) with source plus binary code analysis for regulated programs that need both.
Through Merito, OpenText Fortify SAST runs as either a standalone Fortify SAST license or inside the Fortify on Demand bundle, with policy tuning, custom-rule authoring, and CI/CD integration handled as the implementation work so the engine works the way the program needs rather than the way the defaults shipped.
What it is
OpenText Fortify SAST 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, while Fortify covers the modern and the legacy in one product. Neither the 2024-2025 rename nor the 26.3 rename back to the Fortify brand changed the engine.
Hybrid deployment is the operational shape. Programs run SAST inside Fortify on Demand 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 Fortify on Demand as the operational target.
Policy drift is what wears a SAST program down. Left on vendor-default policies, a SAST program produces huge false-positive volumes, loses developer trust by month two and ends up as a checkbox scan nobody reads. The fix is policy tuned to the customer's actual risk tolerance, suppressions that can be audited instead of piling up as ignored findings, and PR-time integration that shows developers results inside code review. Without that, even a strong engine generates noise.
Ideal use cases
What it is best at
20+ years in regulated production, with deployments across financial services, government, defense and healthcare. Teams that must defend their SAST engine choice to auditors can point to that operating record.
Analyzes both source code and compiled binaries. Programs scanning vendor-supplied components without source still get coverage. Few competing SAST tools handle binary analysis at this depth.
Java, .NET, JavaScript, Python, Go, Apex, COBOL, ABAP, PL/SQL, and more in one engine. Programs running enterprise codebases across modern and legacy do not stitch together specialist tools.
Same engine across deployment shapes. Programs running hybrid (SaaS for some applications, on-prem for regulated workloads) get one operational pattern.
AI-augmented triage and fix suggestions grounded in the customer's findings, available across SAST and the rest of the AppSec line.
Core capabilities
Static analysis core covering modern and legacy code in one engine.
Modern language coverage
Java, JavaScript, TypeScript, C#, .NET, Python, Go, Kotlin, Swift, C, C++, Objective-C, and more.
Legacy and enterprise stack coverage
Salesforce Apex, COBOL, ABAP, PL/SQL, RPG, and other enterprise stacks. Mainframe-adjacent code covered alongside modern microservices.
Source and binary analysis
Analyzes both source code and compiled binaries. Vendor-supplied components without source still get coverage.
Custom rule authoring
Programs encode internal coding standards as custom rules so policy enforcement runs inside the scanner.
What separates a working SAST program from a noisy one.
Policy tuning per application
Severity thresholds and rule sets are set per repository or business unit, so an internal tool is not held to the same bar as a customer-facing payment service.
Auditable suppression workflow
Suppression with expiry, reviewer assignment, and rationale capture. Suppressions stop being permanent ignore lists.
Findings-routing operating model
Triage assignment, ticketing integration, and PR-time visibility designed for continuous AppSec rather than batch scanning.
SAST inside the customer's release pipeline and operational fabric.
Hybrid deployment
SaaS, on-prem, and BYOC editions sharing the same engine and findings model.
PR-time scanning
Scans only the pull-request diff and posts its findings as review comments. Developers see issues in the review they were already doing.
Build-gate policy
Builds pass or fail on thresholds for severity, count and age. New vulnerabilities are blocked when they are introduced, while the existing backlog is triaged separately.
Compliance reporting
SAST results packaged as evidence for FedRAMP, HIPAA, PCI DSS, SOC 2 and ISO 27001 audits.
Where it fits in the stack
Deployment and implementation
Licensing and packaging
Standalone Fortify SAST
SAST on its own, run as SaaS, on-prem or as bring-your-own-cloud.
Best for: Programs that need SAST without the rest of the Fortify on Demand bundle.
Inside Fortify on Demand
SAST bundled with DAST and Fortify SCA in the Fortify on Demand SaaS subscription.
Best for: Programs running unified AppSec across SAST, DAST, and SCA.
Government Cloud (FedRAMP)
FedRAMP-authorized SAST for federal customers.
Best for: Federal programs requiring FedRAMP-authorized AppSec.
Merito services
Pick the engagement that matches where you are in the lifecycle.
Tenant or environment setup, deployment-shape decision, policy tuning, custom-rule authoring, CI/CD integration.
Explore serviceOn-prem Fortify SAST to Fortify on Demand modernization, including policy and suppression-history transfer.
Explore serviceAppSec program scoping for SAST adoption alongside Checkmarx, Veracode, Semgrep Code and Snyk Code.
Explore serviceSAST gates at pull request and build time, configured in Jenkins, GitHub Actions, GitLab CI, Azure DevOps or Bitbucket.
Explore serviceOngoing policy tuning and custom-rule upkeep, with the triage model adjusted as the codebase and team change.
Explore serviceCustom-rule authoring and policy-tuning workshops for AppSec architects, plus PR-integration onboarding for developers.
Explore serviceAppSec engineers who write Fortify custom rules and tune SAST policy, working inside your team for as long as the program needs.
Explore serviceOpenText Fortify SAST licensing
OpenText Fortify SAST pricing arrives with policy tuning, custom-rule authoring, suppression discipline, and PR-time CI/CD integration that turn 20+ years of Fortify engine depth into a working AppSec program rather than a vendor-default scanner.
Merito point of view
Plenty of programs run OpenText Fortify SAST with an engine that works fine, solid language coverage, and a backlog that still grows out of control. 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, and no SAST replacement fixes them.
OpenText Fortify SAST fits programs that need broad language coverage including legacy and enterprise stacks (COBOL, Apex, ABAP), that need source plus binary analysis for vendor-supplied components, and that treat regulated compliance (FedRAMP, HIPAA, PCI DSS) as a selection criterion. For programs already running mature Checkmarx One pipelines, switching to OpenText Fortify SAST is typically a 12-month effort that rarely pays back the disruption, and scoping calls that out.
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 Fortify on Demand; on-prem remains the right answer for programs with regulatory constraints that rule out SaaS scanning.
What buyers usually underestimate
As of July 13, 2026, the newest OpenText Fortify SAST release Merito has covered is 26.3. Read the 26.3 summary
Related from Merito
Related solutions
Related services
Related products
Frequently Asked Questions
Consultation request
Tell us which languages and stacks need coverage, any SAST tool you run now, and whether scanning is allowed in SaaS. A Merito OpenText specialist follows up within one business day.
Mature engine
20+ years of regulated production deployment. Source plus binary analysis. Broad coverage across modern and legacy stacks.
Policy first
Vendor defaults generate noise. Merito's first thirty days are policy tuning, custom-rule authoring, and suppression-workflow design.
Next step
A Merito OpenText Fortify SAST engagement starts with policy tuning, custom-rule authoring, and PR-time integration.