Fortify SAST: Static Application Security Testing Guide

Fortify Static Code Analyzer (SCA), from OpenText (formerly Micro Focus, formerly HP), is one of the most widely deployed SAST tools in regulated industries — financial services, healthcare, government. If your organization needs to demonstrate security compliance (PCI-DSS, HIPAA, FedRAMP), you've probably encountered Fortify.

This guide covers how Fortify works, how to set it up, and how security and QA teams use it effectively.

What Fortify Scans For

Fortify analyzes source code to find security vulnerabilities using a combination of:

• Dataflow analysis — tracks tainted data from sources (user input, external APIs) to dangerous sinks (SQL queries, file writes, HTML output)
• Control flow analysis — checks execution paths for security-relevant conditions
• Semantic analysis — understands language semantics, not just pattern matching
• Configuration analysis — flags insecure settings in config files

The Fortify Taxonomy covers 1000+ vulnerability categories across OWASP Top 10, CWE, SANS Top 25, and more.

Supported languages: Java, C/C++, C#, VB.NET, ASP.NET, JavaScript, TypeScript, Python, Ruby, PHP, ABAP, COBOL, Kotlin, Swift, Go, and others.

Fortify Deployment Options

Fortify SCA (on-premises): Install on developer machines or CI servers. Scan locally and upload results to Software Security Center (SSC) for centralized management.

Fortify on Demand (FoD): SaaS model. Upload your code (or source via API), Fortify scans it in their cloud, results come back via the portal. Good for teams without infrastructure to manage.

Fortify ScanCentral: Distributed scanning infrastructure — offload scans from CI machines to a dedicated scan farm.

Basic Scan Workflow (Fortify SCA)

Translation Step

Fortify first translates your source into an intermediate representation:

# Java (Maven project)
sourceanalyzer -b my-project mvn compile

# Java (direct)
sourceanalyzer -b my-project -source 11 \
  -cp "libs/*.jar" src/**/*.java

# JavaScript/TypeScript
sourceanalyzer -b my-project \
  -js-src-files "src/**/*.ts"

# C#
sourceanalyzer -b my-project \
  msbuild MyProject.sln /t:rebuild

Analysis Step

sourceanalyzer -b my-project \
  -scan \
  -format fpr \
  -f results.fpr

The .fpr (Fortify Project Results) file contains all findings. Open it in Fortify Audit Workbench for review, or upload to SSC.

Upload to Software Security Center

fortifyclient uploadFPR \
  -file results.fpr \
  -url https://ssc.yourcompany.com/ssc \
  -authtoken $SSC_TOKEN \
  -application "My App" \
  -applicationVersion "1.0"

CI/CD Integration

GitHub Actions

name: Fortify SAST
on:
  push:
    branches: [main, develop]

jobs:
  fortify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Set up Java
        uses: actions/setup-java@v3
        with:
          java-version: '17'
      
      - name: Fortify Scan
        uses: fortify/github-action@v1
        with:
          sast-scan: true
        env:
          FOD_URL: ${{ secrets.FOD_URL }}
          FOD_CLIENT_ID: ${{ secrets.FOD_CLIENT_ID }}
          FOD_CLIENT_SECRET: ${{ secrets.FOD_CLIENT_SECRET }}
          FOD_RELEASE: "My App:1.0"

Jenkins Pipeline

pipeline {
    agent any
    stages {
        stage('Fortify Translation') {
            steps {
                sh "sourceanalyzer -b ${JOB_NAME} mvn compile"
            }
        }
        stage('Fortify Scan') {
            steps {
                sh "sourceanalyzer -b ${JOB_NAME} -scan -f results.fpr"
                sh "fortifyclient uploadFPR -file results.fpr -url ${SSC_URL} -authtoken ${SSC_TOKEN} -application ${APP_NAME} -applicationVersion ${APP_VERSION}"
            }
        }
    }
}

Working with Software Security Center (SSC)

SSC is the centralized portal where your team triages findings. Key concepts:

Applications and Versions: SSC organizes findings by application → version. Each CI scan uploads to a specific version.

Issue State Machine:

• New — first detected
• Existing — was present in a previous scan, still present
• Removed — was flagged, no longer present (fixed or code deleted)
• Suppressed — false positive or accepted risk

Audit Sessions: SSC lets multiple team members review findings simultaneously without conflicts.

Triaging Issues

For each finding:

1. Read the Abstract — one-line description of what Fortify found
2. Review the Analysis Evidence — the dataflow trace showing source → sink
3. Check Recommendations — Fortify's suggested fix pattern
4. Set Analysis state: Not an Issue, Reliability Issue, Bad Practice, Suspicious, Exploitable
5. Set Review status: Under Review, Reviewed

Mark false positives with a comment explaining why. These persist across future scans so you don't re-triage the same issue.

Issue Categories to Prioritize

Sort by Friority (Fortify's composite score of likelihood × impact) rather than just severity. A high-severity finding in dead code ranks lower than a medium finding in your login flow.

Custom Rules

For internal libraries and frameworks Fortify doesn't know about, write custom rules in Fortify's XML format:

<RulePack xmlns="xmlns://www.fortify.com/schema/rules">
  <Rules version="3.14">
    <Rule formatVersion="3.14" language="java">
      <TaintPropagationRule>
        <RuleID>custom-taint-source-001</RuleID>
        <Description>Custom taint source for internal request wrapper</Description>
        <Method>com.yourcompany.web.Request.getUserInput</Method>
        <TaintFlags>+XSS +SQL</TaintFlags>
      </TaintPropagationRule>
    </Rule>
  </Rules>
</RulePack>

Load custom rules:

sourceanalyzer -b my-project \
  -rules custom-rules.xml \
  -scan -f results.fpr

Suppressing False Positives in Code

/* fortify[SQL_Injection] */
String query = "SELECT * FROM users WHERE id = " + id;

// Or with reason
@SuppressWarnings("fortify:SQL_Injection")
public String getUser(int id) { ... }

Use code-level suppression sparingly — prefer triaging in SSC so suppressions are tracked with justifications.

Metrics and Reporting

SSC provides built-in reports:

• OWASP Top 10 Report — compliance mapping
• PCI-DSS Report — maps findings to PCI requirements
• Developer Workload Report — shows how many open issues each developer owns
• Trend Report — defect count over time per application version

For compliance audits, the OWASP and PCI-DSS reports are usually what auditors ask for.

Fortify vs. Dynamic Testing

Fortify finds structural vulnerabilities — paths in code that could be exploited. It doesn't know if a vulnerability is actually reachable at runtime with real inputs.

Dynamic testing (DAST, or functional security tests) verifies that exploits actually work against a running application. The combination gives you full coverage: Fortify finds what's theoretically broken; functional tests confirm what's actually exploitable.

For teams running automated regression, HelpMeTest can execute security-relevant functional scenarios (login bypass attempts, injection via form fields) 24/7 alongside your Fortify SAST pipeline.

Common Mistakes

Scanning without translation. If the translation step fails silently (missing classpath, wrong JDK), the scan produces zero findings — which looks like a clean bill of health. Always verify the translation artifact count before trusting results.

Treating Friority as severity. A Friority 5.0 critical in rarely-executed code is less urgent than a Friority 3.5 medium in your authentication flow. Use Friority as a starting point, then apply context.

No ownership. If no one owns findings in SSC, they sit in "New" forever. Assign application versions to security champions or team leads.

Skipping custom rules for internal frameworks. If your app routes user input through an internal validation library, Fortify may miss injection points. Custom rules fill that gap.

Summary

Fortify SCA is the go-to SAST tool for enterprise and regulated environments. It offers comprehensive vulnerability coverage, strong compliance reporting, and deep integration with CI/CD pipelines.

The workflow is: translate → scan → upload to SSC → triage → fix → rescan to confirm. Build that loop into every sprint and defect density will drop measurably over time.