PRODUCT INTELLIGENCE APPSEC

OpenText
Static application security testing

OpenText Fortify SAST

Enterprise static analysis that needs a deliberate build and audit workflow

OpenText Fortify SAST is a static-testing product known for legacy-language breadth, including COBOL and ABAP. The vendor describes broad language and framework support plus remediation assistance. A broader OpenText Application Security portfolio includes software-as-a-service and self-managed testing around that static core.

01 / EDITORIAL JUDGMENT

The Atlas take.

Fortify Static Code Analyzer is now presented in current OpenText materials as Fortify SAST and OpenText Static Application Security Testing. The underlying evaluation remains source-analysis coverage, integration with enterprise builds, and the ability to audit and remediate findings. Atlas analysis: it fits a program prepared to manage analysis infrastructure and specialist triage, particularly across a varied application estate. Naming updates should not be mistaken for a required product migration. Confirm the exact release and deployment, and keep static-code analysis distinct from separately scoped software-composition and dynamic testing.

Our interpretation of the cited evidence. Independent hands-on effectiveness remains unassessed.

02 / DEFINE THE BOUNDARY

What you are actually evaluating.

Audit Workbench style review, false-positive handling, and the OpenText versus former Micro Focus contract and support path are operational boundaries. Language-list marketing does not prove the team's compiler and framework are modeled. Self-managed analysis is a reason teams still evaluate Fortify for regulated code.

Names you may encounter Fortify SAST · Micro Focus Fortify · OpenText Fortify Static Code Analyzer · Fortify Static Code Analyzer. Historical names do not establish current feature equivalence.

03 / THE CONTROL PATH

Where it sits. How it works.

Atlas architecture interpretation: follow the actual artifact through the selected analysis engine and back to an owned development decision.

Conceptual architecture Atlas interpretation · verify the proposed configuration
  1. 01

    Application build context

    Source, framework support, and packaging describe what the static engine can inspect.

  2. 02

    Fortify static analysis

    Selected deployment analyzes supported code and produces findings for review.

  3. 03

    Audit and remediation

    AppSec validates data flows, assigns fixes, and retains repeat-scan evidence.

04 / WHAT EARNS ITS PLACE

Strengths, with the evidence attached.

Atlas analysis of documented capabilities; availability and behavior depend on the edition and environment.

01

Deployment can follow enterprise constraints

Current product information describes cloud, hosted, and off-cloud arrangements for static testing.

02

Developer integration is part of the product

The product documents IDE, build, pipeline, and issue-tracking integration paths.

Inspect the documented capability notes
  • Static analysis with vendor-described breadth across languages and frameworks, including legacy languages such as COBOL and ABAP.
  • Remediation assistance attached to static findings.
  • Broader OpenText Application Security portfolio options for software-as-a-service and self-managed testing around the static analyzer.

05 / KNOW THE COMPROMISES

The tradeoffs to take seriously.

Architectural implications and procurement questions from Atlas; these are not independently measured product failures.

Static and composition analysis differ

The current product FAQ explicitly treats dependency analysis as a complementary SCA product.

Names require release-specific reconciliation

Official release notes describe product-name changes; use current release documentation when comparing inherited installations.

06 / FROM PURCHASE TO PRACTICE

Make it work in your environment.

A proposed implementation sequence. Confirm supported versions, permissions, and rollback with the current documentation.

  1. 01

    Freeze product and release scope

    Record the engine, management components, hosting, and entitled adjacent analysis.

  2. 02

    Integrate the actual build

    Verify modules, frameworks, generated code, and exclusions against production build behavior.

  3. 03

    Establish finding audit

    Assign technical reviewers and define accepted-risk, ownership, and verified-fix records.

07 / THE OPERATING COMMITMENT

The bill is only part of the cost.

Commercial shape

Quote static analysis, management, hosting, and any adjacent products explicitly; include build-integration and audit labor.

  • Analysis and management entitlement
  • Hosted versus self-managed infrastructure
  • Build onboarding and finding-audit effort
AFTER GO-LIVE

What your team owns

Build integration, analysis configuration, security-content updates, and finding audit require ownership. Atlas analysis: include a difficult enterprise application in the pilot rather than only a small demo. Preserve the analyzed revision and build context so developers can reproduce a finding and auditors can understand why it was accepted or fixed.

Confirm the full order form: modules, usage meters, support, retention, and exit costs. A public price is not your complete operating estimate.

08 / COMPARE THE JOB

Put these beside it.

Alternatives worth examining for the same problem. Check each offering’s scope before treating it as a substitute.

Open a comparison workspace ↗

09 / MAKE THE DECISION OBSERVABLE

Earn confidence through a real evaluation.

Suggested by Atlas. Agree acceptance criteria, use synthetic fixtures in an authorized environment, and capture both useful work and failed controls.

  1. TEST 01

    Verify analysis completeness

    Acceptance evidence: Retain build capture, analyzed modules, exclusions, and engine version.

  2. TEST 02

    Audit one data flow

    Acceptance evidence: Have a developer reproduce the reported source-to-sink issue and document any mitigation.

  3. TEST 03

    Confirm a fixed finding

    Acceptance evidence: Retain the code revision, application tests, repeated analysis, and audited state transition.

START WITH ONE EXERCISE

Run Fortify Static Code Analyzer on a lab project you own in a language the team cares about, including a seeded weakness. Use the self-managed or SaaS path that matches policy.

Evidence to look for: The seeded weakness is found or a modeling gap is documented, review notes capture any false-positive decision, and the evidence pack names OpenText as the current vendor.

Questions to bring to the vendor
  1. Does the analyzer model this team's compiler, build options, and frameworks, not just list the language name?
  2. How are false positives reviewed and suppressed in the actual audit workflow?
  3. What remains of former Micro Focus contracts, and who supports the product under OpenText?
Take the evaluation brief with you ↓

10 / SHOW THE WORK

Evidence, and what is still unknown.

What this research cannot establish

  • No independent vulnerability-detection or analysis-capacity benchmark was performed.
  • Exact release support and component licensing require confirmation against the deployment.

Dossier research reviewed October 18, 2026. Earlier profile references are retained for traceability; products and commercial terms change.

  1. OpenText Fortify Static Code Analyzer ↗Earlier profile reference
  2. Fortify SAST product and deployment ↗Product information
  3. Current product naming in OpenText release notes ↗Documentation
  4. OpenText application-security release overview ↗Product information

KEEP BUILDING YOUR JUDGMENT

Understand the system around the tool.

Read the APPSEC field guide ↗

Find your next idea.

Tip: press / to open search. Escape closes this window.