Two decades of DAST engine depth
20+ years of regulated DAST production in financial services, government, defense and healthcare, which gives security teams a scanner their auditors already know.
OpenText • Application security
OpenText Fortify DAST (formerly OpenText Dynamic Application Security Testing) exercises running web applications, REST and GraphQL APIs, and mobile-app backends with authenticated session handling, OWASP Top 10 coverage, and source-correlation back to OpenText Fortify SAST.
A Merito OpenText Fortify DAST engagement points the DAST engine at the customer's actual runtime application surface, builds out authenticated session handling for SSO and OAuth flows, and routes findings into Fortify on Demand alongside the existing SAST and SCA backlog.
What it is
OpenText Fortify DAST has run in regulated industries for two decades, including financial services, government, defense and healthcare. The name changes along the way did not change the engine. Programs on older releases move to OpenText Fortify DAST without re-authoring scans.
Authenticated scanning is the load-bearing capability. Most applications worth testing sit behind authentication, and DAST that cannot maintain session through SSO, multi-step login, or token refresh ends up scanning the public landing page and missing the application. OpenText Fortify DAST handles SAML, OAuth, OIDC, multi-factor flows, custom session protocols, and the long-tail authentication shapes regulated programs ship. Programs running unauthenticated DAST are not running DAST.
Source correlation back to SAST is the platform advantage. DAST findings cross-reference back to Fortify SAST findings on the same code path, so AppSec sees both the source-level vulnerability and the runtime confirmation in one ticket. Aviator AI augmentation extends across DAST and SAST findings together, proposing fixes grounded in the customer's actual codebase. Programs running DAST as a standalone tool against a different vendor's SAST get fragmented findings; programs running OpenText Fortify DAST inside Fortify on Demand get unified backlog math.
Environment access decides whether DAST works. DAST needs a runnable application with realistic data, working authentication, and network reachability from the scanner. Programs that run DAST against an empty staging environment with a generic test account scan a hollow shell. Implementation therefore starts with environment readiness (test data, authentication wiring, scan-window scheduling) before the scanner touches anything real, and tunes policy to each application surface instead of running default rules across web, API and mobile as if they were the same.
Ideal use cases
What it is best at
20+ years of regulated DAST production in financial services, government, defense and healthcare, which gives security teams a scanner their auditors already know.
SAML, OAuth, OIDC, multi-factor, custom session protocols. Long-tail authentication shapes regulated programs ship. Tools that lose session after the first redirect end up testing nothing useful.
Same scanner covers web apps, REST and GraphQL APIs, and mobile-app backends. Programs stop stitching together specialist DAST tools per surface.
DAST findings cross-link to the Fortify SAST flow path that introduced them. AppSec sees source and runtime in one ticket inside Fortify on Demand.
Fortify Remediation Aviator proposes fixes grounded in DAST findings cross-correlated with SAST source paths.
Core capabilities
What separates DAST that finds real issues from DAST that scans the public landing page.
Authenticated session handling
SAML, OAuth 2.0, OIDC, multi-factor, and custom session protocols. The scanner stays logged in across multi-step flows.
OWASP Top 10 and beyond
Coverage of injection, broken auth, misconfiguration, sensitive data exposure, and the rest of the OWASP catalog. Plus business-logic flaws caught through guided exploration.
API scanning (REST, GraphQL, SOAP)
Imports OpenAPI, GraphQL schema, or Postman collections and tests every endpoint with realistic auth and payload.
Mobile DAST
Native iOS and Android app scanning plus the backend services they call.
Adapting the scanner to the customer's actual application surface.
Application-specific tuning
Scan policies tunable per application, with web, API, and mobile policies separated rather than blended into one default.
Crawling depth and scope
Configurable crawl depth, allow-and-deny lists, and parameter handling so the scan covers what matters.
Scan windows and rate limiting
Configurable scan windows, request rate, and concurrency so DAST does not knock production-shaped staging environments offline.
Where DAST results go once a scan finishes, inside Fortify on Demand.
Source correlation with SAST
DAST findings cross-link to Fortify SAST flow paths and Fortify SCA dependencies inside Fortify on Demand.
Aviator AI augmentation
AI-augmented triage and fix suggestions grounded in DAST findings.
Build-gate and ticketing integration
DAST results gate the staging-to-prod promotion and flow into Jira, Azure Boards, and ServiceNow.
Compliance reporting
Runtime test results reported as evidence for PCI DSS, HIPAA, FedRAMP, SOC 2 and ISO 27001 audits.
Where it fits in the stack
Deployment and implementation
Licensing and packaging
Standalone Fortify DAST
DAST licensed by itself for SaaS, on-prem or BYOC deployment.
Best for: Programs that need DAST without the rest of the Fortify on Demand bundle.
Inside Fortify on Demand
DAST included with SAST and Fortify SCA in the Fortify on Demand bundle.
Best for: Programs running unified AppSec.
Government Cloud (FedRAMP)
FedRAMP-authorized DAST 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, authenticated-scanning wiring, policy tuning per application, CI/CD integration.
Explore serviceOn-prem OpenText Fortify DAST to Fortify on Demand modernization, with scan policies and findings history carried over.
Explore serviceAppSec program scoping for OpenText Fortify DAST adoption alongside Checkmarx DAST, StackHawk, and Bright.
Explore serviceDAST scheduled and gated in Jenkins, GitHub Actions, GitLab CI, Azure DevOps, and Bitbucket pipelines.
Explore serviceChampion programs that help developers read runtime findings and fix the source code behind them.
Explore serviceNamed engineer, priority SLAs, and release-time coverage for OpenText Fortify DAST.
Explore serviceLong-term run support including authenticated-scan maintenance, scan-window operation, and policy evolution.
Explore serviceAuthenticated-session workshops, API DAST onboarding and CI/CD integration training for AppSec architects and engineers.
Explore serviceEngineers who configure authenticated scans and scan windows, working inside your AppSec team during and after rollout.
Explore serviceOpenText Fortify DAST licensing
OpenText Fortify DAST pricing arrives with authenticated-session wiring, per-application policy tuning, scan-window scheduling, and CI/CD integration that turn 20 years of Fortify DAST engine depth into a working AppSec program.
Merito point of view
Some DAST programs run nightly against production-shaped staging, generate thousands of findings, and still miss every business-logic flaw because the scanner lost its session at the SSO redirect. Authenticated scanning is the difference between testing the application and testing the public landing page. OpenText Fortify DAST handles real session protocols across the long-tail authentication shapes regulated programs ship, and a program that adopts DAST without configuring authentication correctly is doing compliance theater.
OpenText Fortify DAST is the better choice when the program is consolidating onto Fortify on Demand or already runs OpenText AppSec, when source correlation with SAST matters, and when regulated DAST evidence (FedRAMP, HIPAA, PCI DSS) is required. Teams that want developer-led cloud DAST without the rest of OpenText may be better served by StackHawk or Bright, and scoping lays out that comparison.
API DAST is where the program math changes. The API surface is usually the actual application; the web frontend is the easy half. Programs running DAST without API scanning are scanning the visible part and missing the structural risk. Merito's engagements include OpenAPI or GraphQL schema ingestion as a default.
What buyers usually underestimate
Related from Merito
Related solutions
Related services
Related products
Frequently Asked Questions
Consultation request
Share your application surface (web, API, mobile), authentication shape, and current DAST tool if any. A Merito OpenText specialist follows up within one business day.
Fortify DAST depth
20+ years of regulated DAST production. SAML, OAuth, OIDC, MFA, custom session protocols.
Source correlation
DAST findings cross-link to Fortify SAST flow paths inside Fortify on Demand.
Next step
A Merito OpenText Fortify DAST engagement starts with authentication wiring and per-application policy tuning. Default-rule scans against landing pages are not DAST.