What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Current product and module naming under OpenText: confirm with vendor
- Exact supported language list and translator availability per language: confirm
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Fortify Static Code Analyzer works in two phases. A translation phase converts each supported language into a normalized intermediate representation, using language-specific translators; for compiled languages this usually means wrapping the build so the translator sees what the compiler sees. An analysis phase then runs several engines over that representation: a data flow engine performing interprocedural taint tracking from sources to sinks, a control flow engine looking for ordered-operation defects such as use after close, a semantic engine for misused APIs, a structural engine matching on declarations and relationships, and a configuration engine that reads deployment descriptors and framework config files.
Rules live in a signed rulepack that the vendor updates, and customers can add custom rules to teach the engine about in-house sources, sinks and sanitizers. Findings are written to a portable result file that carries the full analysis evidence, which can be opened in a desktop audit workbench or uploaded to the server-side platform for tracking, metrics and compliance reporting against standards such as PCI DSS, OWASP and various government requirements. The result file being self-contained matters in practice: it lets an auditor reopen a scan from years ago with the full trace intact.
Where it fits
Fortify is a security-team platform. Scans run in the build pipeline, often nightly on large applications given translation and analysis time, with developers seeing results through IDE plugins and pipeline reports. It presumes a formal AppSec program with named auditors, a triage process and a defined risk acceptance path. Without those roles the finding volume on a large legacy application is unmanageable.
Strengths
- Language coverage extends to enterprise stacks that most modern tools ignore, including COBOL, ABAP and database procedural languages.
- Multiple analysis engines catch different defect shapes, not just taint flows, including framework configuration mistakes.
- Self-contained result files make findings portable and reviewable long after the scan host is gone, which auditors value.
- Custom rules give a mature program a real path to reducing noise on its own codebase.
Limitations
- Translation and scan times are long on large applications, which keeps it out of fast feedback loops and forces nightly scheduling.
- Default rulepacks produce very high finding counts, and an audit workflow with trained reviewers is effectively mandatory rather than optional.
- Operationally heavy: infrastructure, license administration and version management all need an owner.
Who it suits
Built for large regulated enterprises with legacy language estates and formal audit requirements, where breadth and evidence quality outweigh speed. A startup shipping a single modern web stack will find the operational weight far out of proportion to the benefit.
Used OpenText Fortify? Recommend it under your own name and title.
Recommend this tool