Trackr.Live The landing site for Trackr Services
§ Trackr.Live

OpenText Fortify

Start with the name, because the name is the trap. If you still call this HP Fortify or Micro Focus Fortify, you are two owners behind. The ownership chain runs Fortify Software to HP (2010) to HPE, then into Micro Focus when HPE spun its software assets out in 2017, and finally to OpenText, which closed the Micro Focus acquisition in 2023. As of 2026 it is an OpenText product, and no divestiture has pulled the appsec line back out. Get the vendor right in your SSP narrative, because an assessor who reads “Micro Focus Fortify SCA” in a 2026 document is going to wonder how stale the rest of the implementation write-up is.

A dataflow taint path traced through abstract stacked code blocks, a tainted input on one edge propagating along thin connective lines to a vulnerable sink, most paths dimmed and one highlighted.

The harder part is that the “Fortify” brand itself is on its way out. OpenText is renaming the whole line to descriptive product names, and “Fortify” now survives mostly in parentheses inside the docs. The Static Code Analyzer is OpenText SAST. WebInspect is OpenText DAST. Software Security Center, the on-prem management server, is OpenText Application Security (you will still see SSC scattered through configs and the SSC Server service name). Fortify on Demand, the SaaS offering, is OpenText Core Application Security. The rename is real but messy: documentation is still served off microfocus.com, release notes lead with “OpenText SAST (Fortify Static Code Analyzer),” and half the community forum threads use both names in the same sentence. For mapping purposes, treat the legacy name as load-bearing. Your practitioners learned this tool as SCA and FoD, and that is what they will grep for.

The four products and what they’re called now

One table, because the rename is the single thing people get wrong, and a mapping is faster to read than four paragraphs.

Current name Legacy name What it is Where it runs
OpenText SAST Fortify Static Code Analyzer (SCA) Static analysis engine, dataflow/taint SAST On-prem / CI agents; also the engine behind FoD
OpenText DAST Fortify WebInspect Dynamic scanner against running web apps/APIs On-prem or against staging; the FoD dynamic backend
OpenText Application Security Software Security Center (SSC) Management server: results store, audit, triage, reporting On-prem server
OpenText Core Application Security Fortify on Demand (FoD) SaaS appsec (static, dynamic, open-source) OpenText-hosted, FedRAMP path

There is a fifth piece worth naming because it confuses version conversations: the Application Security Content, the Secure Coding Rulepacks. That is what actually decides what SAST flags, and it ships on its own schedule.

Two version numbers, not one

Fortify moved to calendar versioning a while back, so “latest version” is two moving numbers and you need both. The engine line is 26.x. 26.1 shipped early in 2026, 26.2 followed (it landed first on the Core Application Security/FoD side), and 25.2 was the prior line. The rulepacks version separately as YYYY.x. Application Security Content 2026.1.0 is a real, distinct artifact from the 26.1 engine, and it is the one that changes findings under you. The 2026.1 content added the OWASP Top 10 2025 correlation, a 2025 CWE Top 25 mapping, and, the part federal teams care about, a correlation to DISA Application Security and Development STIG version 6.4.

Watch the compatibility floor. Starting with rulepack 26.1, content only loads on engine versions still inside their maintenance window, and anything older than SCA 24.2 won’t load the 26.1 rulepacks at all. If your CI agents and your release gate are on different engine builds, you can get rulepack drift where dev sees a finding the gate doesn’t, or the reverse. That mismatch is a real triage headache and it is entirely self-inflicted.

For raw capability: OpenText SAST 26.2 claims 1,537 vulnerability categories across 45-plus languages, with 26.2 adding C++23, PHP 8.5, and Kotlin 2.3 (K2 compiler). The deep, mature coverage is the languages the tool has carried for years, Java, C/C++, .NET, where the dataflow analysis and the rulepacks are genuinely strong.

Where it lands in the federal flow

The anchor is SA-11, developer security testing. SAST output is the canonical SA-11(1) static analysis evidence and DAST covers SA-11(8) dynamic analysis. That is the control most ATO packages are actually citing when they reference Fortify. SA-15 picks up the development process and tooling side. RA-5 ties in for the DAST angle, vulnerability scanning against a running application, which is a different activity from infrastructure vuln scanning even though the control number overlaps. SR comes in through SCA’s open-source composition work and rulepack provenance.

One control it is not: CM-6. Configuration-settings checking against a STIG or SCAP baseline is not Fortify’s job; that’s SCAP and STIG tooling. If you see Fortify cited against CM-6 in an SSP, someone padded the control mapping.

The federal pull is RMF SA-11 expectations plus DoD’s application security requirements. The old DISA Application Security and Development STIG (the ASD STIG) is still live and still the thing DoD appsec gets measured against; OpenText explicitly correlates the Fortify taxonomy to ASD STIG v6.4 in the current rulepack, which is not an accident, that’s the audience. The DoD Enterprise DevSecOps Reference Design names SAST and DAST as pipeline gates, and Fortify slots into both.

On the acceptance-path question, the answer changed recently. The DoDIN APL program sunset on 30 September 2025; scheduled testing wrapped by the end of 2025, with DISA maintaining the existing product repository through FY2026. Cybersecurity requirements are moving to the DISA RME Vendor STIG program, interoperability to UCR-CORE. So “is it on the APL” is no longer the question to lead with for new procurements; the Vendor STIG path is. Verify where your specific program sits, because the transition is mid-flight.

The cleaner federal story is FedRAMP. OpenText Core Application Security (Fortify on Demand) is FedRAMP Authorized at Moderate, listed on the Marketplace (listing F1301101857) with an original authorization date of 4 February 2015, and it carries reuses from multiple agencies. If you need an appsec-as-a-service path with the paperwork already done, that’s the one. The Marketplace listing is the citation to put in front of your AO, not a vendor data sheet.

Deeper: Raw SAST output is not findings. OpenText SAST emits issues; an issue becomes a finding only after a human audits it. That audit, the act of marking exploitable versus not-an-issue versus suspicious in SSC/OpenText Application Security, is the thing that constitutes your SA-11(1) evidence. An ISSO who exports the raw scan and drops it into the POA&M as-is has done the wrong work and inflated their own remediation queue with false positives. The triage pass is the control. Budget for it the same way you budget for the scan itself, because the audit time on a large first scan can dwarf the scan time.

Who runs it, and how often

SAST is run by developers or the appsec team as a CI gate (per-PR or per-build for incremental scans) and as a slower, deeper release-gate scan. SSC is where ISSOs and appsec pull results and triage. DAST runs against staging on a slower cadence, because you need something deployed to scan. In practice the deep full scans are slow and memory-hungry enough that nobody runs them per-commit; the incremental scan carries the CI gate and the full scan happens on a cadence that fits the build window.

The eMASS reality is worth flagging up front: Fortify results do not flow to eMASS natively. Teams export and summarize the SA-11 evidence by hand, which means someone owns a recurring manual step that tends to rot the moment that person changes roles. Plan for it as a process, not a one-time integration.

What’s good, and what people gripe about

The strengths are real. Deep language coverage, mature taint analysis, and a federal track record longer than most of its competitors have existed. For Java, C/C++, and .NET the rulepacks find things lighter tools miss, and the audit trail through SSC is built for exactly the evidence chain an ATO wants.

The complaints are also real, and consistent. False-positive volume is the perennial one, and tuning that down is ongoing labor, not a setup task. Full SCA scans are slow and hungry on large codebases; the translate phase alone can eat memory on a monolith. The SSC audit workflow is heavy. Licensing is enterprise-priced and opaque enough that “what does this cost” is a procurement project. And the tooling has felt dated next to newer CI-native entrants like Snyk, Checkmarx, and GitHub Advanced Security.

Here is the opinion, and reasonable people will disagree: for a greenfield, CI-native shop with no existing ATO baggage, the false-positive-tuning tax makes a lighter, faster SAST genuinely more attractive, and I would not default to Fortify there. But for a federal program that has already built its SA-11 evidence chain, its audit conventions, and its assessor relationships around Fortify, ripping it out costs more than it saves. The FedRAMP-Moderate FoD path and the years of accepted audit artifacts are the actual product for a lot of federal buyers, more than the engine itself. The switching cost, not the scan quality, is what keeps it installed.

Operations and where teams trip

Deployment is one of two shapes: on-prem SAST plus SSC that you run and patch, or SaaS Core Application Security where OpenText runs it. CI integration goes through the scan client and plugins for Jenkins, Azure DevOps, and GitLab.

The thing that catches people is the two-phase model. SAST doesn’t scan source directly; it does sourceanalyzer ... translate then sourceanalyzer ... scan, and the translate phase needs a clean, buildable project. Build integration is the genuinely hard part of a Fortify rollout, not the scanning. If the build is flaky, the translate is incomplete, and an incomplete translate quietly under-reports, which is worse than a loud failure. Results land in SSC, you export for eMASS and the POA&M, and ticketing flows through SSC’s API into Jira or Azure DevOps.

Common ways it goes sideways: build that won’t translate cleanly; scan-time and memory tuning on large repos; rulepack version drift between the dev agents and the gate; and treating raw output as findings without the audit pass. That last one is the expensive mistake, because it floods the POA&M with noise and buries the issues that matter.

Pin your rulepack version across the pipeline, budget the audit time as real work, and keep the vendor name current in your documents. The tool earns its place in federal shops on the strength of the evidence chain it produces, not on being the fastest scanner in the room, and the day OpenText finishes burying the Fortify name your docs should already be ahead of it.

Sources

Adjacent material on this site