OpenText™ Static Application Security  
Testing (Fortify Static Code Analyzer)  
Software Version: 25.2.0  
User Guide  
Document Release Date: April 2025  
Software Release Date: April 2025  
User Guide  
Legal notices  
Open Text Corporation  
275 Frank Tompa Drive, Waterloo, Ontario, Canada, N2L 0A1  
Copyright notice  
Copyright 2003 - 2025 Open Text.  
The only warranties for products and services of Open Text and its affiliates and licensors (“Open Text”) are as may be set forth  
in the express warranty statements accompanying such products and services. Nothing herein should be construed as  
constituting an additional warranty. Open Text shall not be liable for technical or editorial errors or omissions contained herein.  
The information contained herein is subject to change without notice.  
Trademark notices  
“OpenText” and other Open Text trademarks and service marks are the property of Open Text or its affiliates. All other  
trademarks or service marks are the property of their respective owners.  
Documentation updates  
The title page of this document contains the following identifying information:  
l
Software Version number  
l
Document Release Date, which changes each time the document is updated  
l
Software Release Date, which indicates the release date of this version of the software  
This document was produced for OpenText™ Static Application Security Testing CE 25.2 on April 04, 2025.  
Page 2 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Contents  
Preface  
13  
13  
13  
13  
Contacting Customer Support  
For more information  
Product feature videos  
Change log  
14  
Chapter 1: Introduction  
Product name changes  
18  
18  
OpenText SAST  
19  
19  
About the analyzers  
Licensing  
21  
21  
21  
22  
23  
24  
Renewing an expired license  
Fortify Software Security Content  
Fortify ScanCentral SAST  
OpenText Application Security Tools  
Sample projects  
Related documents  
24  
24  
25  
25  
26  
26  
All products  
Fortify ScanCentral SAST  
Fortify Software Security Center  
OpenText SAST  
OpenText Application Security Tools  
Chapter 2: System requirements  
28  
Hardware requirements  
Sample scans  
28  
30  
Supported platforms and architectures  
Software requirements  
31  
32  
33  
Supported languages  
Page 3 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Supported libraries, frameworks, and technologies  
35  
41  
42  
42  
43  
43  
Supported build tools  
Supported compilers  
Fortify Software Security Content  
Virtual Machine support  
Acquiring software  
Verifying software downloads  
45  
46  
Preparing your system for digital signature verification  
Chapter 3: Installing OpenText SAST  
47  
About installing OpenText SAST  
47  
48  
50  
52  
53  
Installing OpenText SAST  
Installing OpenText SAST silently  
Installing OpenText SAST in text-based mode on non-Windows platforms  
Manually installing Fortify Software Security Content  
Using Docker to install and run OpenText SAST  
Creating a Dockerfile to install OpenText SAST  
Running the container  
53  
53  
54  
55  
Example Docker run commands for translation and scan  
Upgrading OpenText SAST  
55  
About uninstalling OpenText SAST  
56  
56  
57  
57  
Uninstalling OpenText SAST  
Uninstalling OpenText SAST silently  
Uninstalling OpenText SAST in text-based mode on non-Windows platforms  
Post-installation tasks  
58  
58  
58  
59  
59  
60  
60  
61  
Running the post-install tool  
Migrating properties files  
Specifying a locale  
Configuring Fortify Security Content updates  
Configuring the connection to Fortify Software Security Center  
Removing proxy server settings  
Adding trusted certificates  
Chapter 4: Analysis process overview  
Analysis process  
62  
62  
Page 4 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Translation phase  
63  
63  
Special considerations for the translation phase  
Analysis phase  
64  
64  
65  
66  
Applying a scan policy to the analysis  
Creating custom scan policies  
Regular expression analysis  
Translation and analysis phase verification  
66  
Chapter 5: Translating Java code  
68  
Java translation command-line syntax  
Java command-line options  
68  
69  
71  
Java command-line examples  
Handling Java warnings  
Java translation warnings  
72  
72  
Translating Jakarta EE (Java EE) applications  
Translating Java files  
73  
73  
73  
73  
Translating JSP projects, configuration files, and deployment descriptors  
Jakarta EE (Java EE) translation warnings  
Translating Java bytecode  
74  
Troubleshooting JSP translation and analysis issues  
Unable to translate some JSPs  
75  
75  
75  
Increased issues count in JSP-related categories  
Chapter 6: Translating Kotlin code  
76  
Kotlin command-line syntax  
Kotlin command-line options  
Kotlin command-line examples  
76  
77  
78  
Kotlin and Java translation interoperability  
Translating Kotlin scripts  
78  
79  
Chapter 7: Translating Visual Studio projects  
Visual Studio project translation prerequisites  
Visual Studio Project command-line syntax  
80  
80  
80  
Handling special cases for translating Visual Studio projects  
Running translation from a script  
82  
82  
Page 5 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Translating plain .NET and ASP.NET projects  
82  
82  
83  
83  
83  
Translating C/C++ and Xamarin projects  
Translating projects with settings containing spaces  
Translating a single project from a Visual Studio solution  
Analyzing projects that build multiple executable files  
Alternative ways to translate Visual Studio projects  
Alternative translation options for Visual Studio solutions  
Translating without explicitly running OpenText SAST  
84  
84  
84  
Chapter 8: Translating C and C++ code  
86  
86  
86  
87  
87  
C and C++ Code translation prerequisites  
C and C++ command-line syntax  
Scanning pre-processed C and C++ code  
C/C++ Precompiled Header Files  
Chapter 9: Translating JavaScript and TypeScript code  
Translating pure JavaScript projects  
Excluding dependencies  
89  
89  
90  
Managing issue detection in NPM dependencies  
Examples of excluding NPM dependencies  
90  
91  
Translating JavaScript projects with HTML files  
93  
93  
Including external JavaScript or HTML in the translation  
Chapter 10: Translating Python code  
95  
Python translation command-line syntax  
Python command-line options  
95  
95  
97  
Python command-line examples  
Translating Python in a virtual environment  
Python virtual environment example  
Conda environment example  
97  
97  
98  
Including imported modules and packages  
Including namespace packages  
98  
98  
99  
Translating Django and Flask  
Page 6 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 11: Translating code for mobile platforms  
100  
Translating Apple iOS projects  
100  
100  
101  
iOS project translation prerequisites  
iOS code analysis command-line syntax  
Translating Android projects  
101  
102  
102  
102  
Android project translation prerequisites  
Android code analysis command-line syntax  
Filtering issues detected in Android layout files  
Chapter 12: Translating Go code  
Go command-line syntax  
103  
103  
104  
105  
106  
Go command-line options  
Including custom Go build tags  
Resolving dependencies  
Chapter 13: Translating Dart and Flutter code  
Dart and Flutter translation prerequisites  
Dart and Flutter command-line syntax  
Dart and Flutter command-line examples  
107  
107  
108  
108  
Chapter 14: Translating PHP code  
PHP command-line options  
109  
109  
Chapter 15: Translating ABAP code  
110  
About downloading source files  
INCLUDE processing  
110  
111  
Importing the transport request  
111  
112  
112  
116  
Adding OpenText SAST to your Favorites list  
Running the Fortify ABAP Extractor  
Uninstalling the Fortify ABAP Extractor  
Chapter 16: Translating Ruby code  
117  
Ruby command-line syntax  
Ruby command-line options  
117  
117  
Page 7 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Adding libraries  
118  
118  
Adding gem paths  
Chapter 17: Translating COBOL code  
119  
120  
Preparing COBOL source and copybook files for translation  
COBOL command-line syntax  
120  
121  
121  
121  
Translating COBOL source files without file extensions  
Translating COBOL source files with arbitrary file extensions  
COBOL command-line options  
122  
122  
Using Legacy COBOL translation  
Legacy COBOL translation command-line options  
Chapter 18: Translating Salesforce Apex and Visualforce code  
Apex and Visualforce translation prerequisites  
Apex and Visualforce command-line syntax  
124  
124  
125  
Chapter 19: Translating other languages and configurations  
126  
Analyzing Solidity code  
Importing dependencies  
Managing compiler versions  
126  
126  
126  
Translating Flex and ActionScript  
Flex and ActionScript command-line options  
ActionScript command-line examples  
Handling resolution warnings  
127  
127  
129  
130  
130  
ActionScript warnings  
Translating ColdFusion code  
130  
130  
131  
ColdFusion command-line syntax  
ColdFusion (CFML) command-line options  
Analyzing SQL  
131  
132  
132  
PL/SQL command-line example  
T-SQL command-line example  
Translating Scala code  
132  
Translating Infrastructure as Code (IaC)  
133  
133  
133  
ARM translation command-line examples  
Bicep translation command-line examples  
Page 8 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
AWS CloudFormation translation command-line examples  
134  
134  
HCL translation command-line examples  
Translating JSON  
134  
135  
135  
135  
137  
138  
Translating YAML  
Translating Dockerfiles  
Translating ASP/VBScript virtual roots  
Classic ASP command-line example  
VBScript command-line example  
Chapter 20: Integrating the analysis into a build  
Build integration  
139  
139  
Integrating with Gradle  
140  
140  
140  
141  
142  
144  
Using Gradle integration  
Gradle integration examples  
Troubleshooting Gradle integration  
Using the Gradle plugin  
Working with Java or Kotlin projects that have subprojects  
Integrating with Maven  
145  
145  
145  
146  
Installing and updating the Fortify Maven Plugin  
Testing the Fortify Maven Plugin installation  
Using the Fortify Maven Plugin  
Integrating with Ant  
Integrating with Make  
Integrating with CMake  
147  
148  
149  
Integrating with Bazel  
149  
150  
Bazel build integration examples  
Chapter 21: Command-line interface  
Translation options  
Analysis options  
151  
151  
153  
156  
159  
Output options  
Other options  
Directives  
161  
162  
LIM license directives  
Page 9 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Specifying files and directories  
163  
165  
Chapter 22: Command-line tools  
About updating Fortify Software Security Content  
Updating Fortify Software Security Content  
fortifyupdate command-line options  
166  
166  
167  
Checking the scan status with SCAState  
SCAState command-line options  
169  
169  
Chapter 23: Improving performance  
Antivirus software  
172  
172  
172  
Tuning options  
Quick scan  
173  
174  
174  
Limiters  
Using quick scan and full scan  
Configuring scan speed with speed dial  
Breaking down codebases  
174  
176  
Limiting analyzers and languages  
Disabling analyzers  
176  
176  
177  
Disabling languages  
177  
177  
178  
178  
179  
180  
Optimizing FPR files  
Using filter files  
Using filter sets  
Excluding source code from the FPR  
Reducing the FPR file size  
Opening large FPR files  
Monitoring long running scans  
Using the SCAState tool  
Using JMX tools  
181  
181  
182  
182  
182  
Using JConsole  
Using Java VisualVM  
Chapter 24: Troubleshooting  
Exit codes  
183  
183  
184  
Memory tuning  
Page 10 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Java heap exhaustion  
184  
185  
185  
Native heap exhaustion  
Stack overflow  
Scanning complex functions  
186  
187  
188  
Dataflow Analyzer limiters  
Control Flow and Null Pointer analyzer limiters  
Issue non-determinism  
Locating the log files  
188  
189  
Configuring log files  
189  
190  
Understanding log levels  
Reporting issues and requesting enhancements  
191  
Appendix A: Filtering the analysis  
192  
Excluding issues with filter files  
Filter file example  
192  
194  
Using filter sets to exclude issues  
196  
Appendix B: Using mobile build sessions  
Mobile build session version compatibility  
Creating a mobile build session  
198  
198  
199  
199  
Importing a mobile build session  
Appendix C: Configuration options  
200  
Properties files  
200  
200  
201  
Properties file format  
Precedence of setting properties  
fortify-sca.properties  
202  
202  
209  
210  
211  
213  
215  
216  
218  
Translation and analysis phase properties  
Regex analysis properties  
LIM license properties  
Rule properties  
Java and Kotlin properties  
Visual Studio and MSBuild project properties  
JavaScript and TypeScript properties  
Python properties  
Page 11 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Go properties  
219  
220  
220  
222  
222  
223  
223  
224  
224  
227  
227  
227  
228  
Ruby properties  
COBOL properties  
PHP properties  
ABAP properties  
Flex and ActionScript properties  
ColdFusion (CFML) properties  
SQL properties  
Output properties  
Mobile build session (MBS) properties  
Proxy properties  
Logging properties  
Debug properties  
fortify-sca-quickscan.properties  
fortify-rules.properties  
229  
232  
Appendix D: Fortify Java annotations  
239  
Dataflow annotations  
Source annotations  
Passthrough annotations  
Sink annotations  
240  
240  
240  
241  
242  
Validate annotations  
Field and variable annotations  
242  
242  
243  
Password and private annotations  
Non-negative and non-zero annotations  
Other annotations  
243  
243  
243  
Check return value annotation  
Dangerous annotations  
Send Documentation Feedback  
244  
Page 12 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Preface  
Preface  
Contacting Customer Support  
Visit the Customer Support website to:  
l
Manage licenses and entitlements  
l
Create and manage technical assistance requests  
l
Browse documentation and knowledge articles  
l
Download software  
l
Explore the Community  
For more information  
For more information about OpenText Application Security Testing products, visit OpenText  
Application Security.  
Product feature videos  
You can find videos that highlight OpenText Application Security Software products and features on  
the Fortify Unplugged YouTube™ channel.  
Page 13 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
 
User Guide  
Change log  
Change log  
The following table lists changes made to this document. Revisions to this document are published  
between software releases only if the changes made affect product functionality.  
Software  
release /  
Document  
version  
Changes  
25.2.0  
Added:  
l
"System requirements" on page 28  
l
Instructions on how to create a custom scan policy ("Applying a scan policy  
to the analysis" on page 64)  
Updated:  
l
Incorporated product name changes (see "Product name changes" on  
page 18)  
l
l
l
l
Installer file names changed for product name change (see various topics in  
"Installing OpenText SAST" on page 47)  
Test projects are excluded by default in translation of Visual Studio projects  
(see "Visual Studio Project command-line syntax" on page 80)  
Added support for Jupyter notebooks (see "Translating Python code" on  
page 95)  
Setting limiter properties is no longer required to translate code created  
using the Django or Flask framework  
Removed:  
l
Properties com.fortify.sca.SuppressLowSeverityand  
com.fortify.sca.LowSeverityCutoffwere removed because they  
reference metadata that is deprecated in the Rulepacks.  
l
The com.fortify.sca.hoa.Enableproperty was removed from this  
document and will be removed from the product in a future release.  
24.4.0  
Updated:  
l
Added installer for Linux on ARM (see "Installing OpenText SAST" on  
Page 14 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Change log  
Software  
release /  
Document  
version  
Changes  
page 48)  
l
l
l
l
Scan policies can exclude dataflow issues based on taint flags (see  
"Applying a scan policy to the analysis" on page 64)  
By default, NPM dependencies are excluded from the analysis phase (see  
"Managing issue detection in NPM dependencies" on page 90)  
Support added for Flask and Jinja2 (see "Translating Python code" on  
page 95)  
Added the -gotagsoption to include custom build tags in OpenText SAST  
translation of Go project (see "Including custom Go build tags" on page 105  
and "Go properties" on page 219)  
l
l
Changes to the command-line options to analyze PL/SQL (see "Analyzing  
SQL" on page 131)  
Added an option to disable build tool name resolution and translate build  
script files as source files (see "Translation options" on page 151 and  
"Translation and analysis phase properties" on page 202)  
l
The -excludeoption is supported in Ant, Bazel, Gradle, and Maven build  
integrations (see "Integrating with Ant" on page 147, "Integrating with  
Bazel" on page 149, "Using Gradle integration" on page 140, "Using the  
Fortify Maven Plugin" on page 146, and "Translation options" on page 151)  
Removed:  
l
Modular analysis was removed from this document. This feature is  
deprecated and will be removed from the product in the next release.  
24.2.0  
Added:  
l
"Integrating with Bazel" on page 149  
"Integrating with CMake" on page 149  
l
Updated:  
l
The default scan policy has changed (see "Applying a scan policy to the  
analysis" on page 64)  
l
Option added to specify a JDK version that is not distributed with OpenText  
SAST to use for translation (see "Java command-line options" on page 69)  
Page 15 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Change log  
Software  
release /  
Document  
version  
Changes  
l
The default Python version has changed (see "Python command-line  
options" on page 95)  
l
The default PHP version has changed (see "PHP command-line options" on  
page 109)  
Removed:  
l
The -apexoption and corresponding configuration property are  
deprecated and no longer required to translate Apex and Visualforce code  
23.2.0  
Added:  
l
l
l
l
"Translating Python in a virtual environment" on page 97  
"Analyzing Solidity code" on page 126  
"Troubleshooting Gradle integration" on page 141  
"Using the Gradle plugin" on page 142  
Updated:  
l
Improved the example Dockerfile to install OpenText SAST (see "Creating a  
Dockerfile to install OpenText SAST" on page 53)  
l
l
l
l
l
l
Added considerations about generated code for the translation phase  
("Translation phase" on page 63)  
The default JDK version was changed from 1.8 to 11 (see "Java command-  
line options" on page 69 and "Kotlin command-line options" on page 77)  
Improved instructions for translating Java bytecode (see "Translating Java  
bytecode" on page 74)  
Improved instructions for excluding NPM dependencies (see "Managing  
issue detection in NPM dependencies" on page 90)  
Added a property to enable translation of minified JavaScript files (see  
"JavaScript and TypeScript properties" on page 216)  
Added rule properties for Apex and PowerShell (see "fortify-  
rules.properties" on page 232)  
Page 16 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Change log  
Software  
release /  
Document  
version  
Changes  
Removed:  
l
Removed all mentions of the -fcontaineroption for running an OpenText  
SAST image as a container as it is no longer necessary and has been  
removed.  
Page 17 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
Chapter 1: Introduction  
This guide provides instructions for using OpenText™ Static Application Security Testing (OpenText  
SAST) to scan code on most major programming platforms. This guide is intended for people  
responsible for security audits and secure coding.  
This section contains the following topics:  
Product name changes  
OpenText SAST  
18  
19  
21  
21  
21  
22  
23  
24  
24  
Licensing  
Renewing an expired license  
Fortify Software Security Content  
Fortify ScanCentral SAST  
OpenText Application Security Tools  
Sample projects  
Related documents  
Product name changes  
OpenText is in the process of changing the following product names:  
Previous name  
New name  
Fortify Static Code Analyzer  
Fortify Software Security Center  
Fortify WebInspect  
OpenText™ Static Application Security Testing (OpenText SAST)  
OpenText™ Application Security  
OpenText™ Dynamic Application Security Testing (OpenText DAST)  
OpenText™ Core Application Security  
Fortify on Demand  
Debricked  
OpenText™ Core Software Composition Analysis (OpenText Core SCA)  
OpenText™ Application Security Tools  
Fortify Applications and Tools  
The product names have changed on product splash pages, mastheads, login pages, and other places  
where the product is identified. The name changes are intended to clarify product functionality and to  
better align the Fortify Software products with OpenText. In some cases, such as on the  
documentation title page, the old name might temporarily be included in parenthesis. You can expect  
to see more changes in future product releases.  
Page 18 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 1: Introduction  
OpenText SAST  
OpenText SAST (Fortify Static Code Analyzer) is a set of software security analyzers that search for  
violations of security-specific coding rules and guidelines in a variety of languages. OpenText SAST  
produces analysis information to help you deliver more secure software, and make security code  
reviews more efficient, consistent, and complete. Its design enables you to incorporate customer-  
specific security rules.  
For a list of supported languages, libraries, compilers, and build tools, see "System requirements" on  
page 28.  
To analyze your application with OpenText SAST, you can:  
l
Perform the analysis directly from an IDE using one of the Secure Code Plugins: Fortify Extension  
for Visual Studio, Fortify Plugin for Eclipse, and Fortify Analysis Plugin for IntelliJ IDEA and Android  
Studio). You can also run the analysis from Fortify Audit Workbench.  
You can also view the security vulnerability analysis results in the IDE and Fortify Audit Workbench  
or upload the results to Fortify Software Security Center. For a description of the tools, see  
"OpenText Application Security Tools" on page 23.  
l
Integrate the analysis into your build system or run the analysis from the command line.  
This guide focuses primarily on this method of performing the analysis.  
About the analyzers  
OpenText SAST comprises eight vulnerability analyzers: Buffer, Configuration, Content, Control Flow,  
Dataflow, Null Pointer, Semantic, and Structural. Each analyzer accepts a different type of rule  
specifically tailored to provide the information necessary for the corresponding type of analysis  
performed. Rules are definitions that identify elements in the source code that might result in security  
vulnerabilities or are otherwise unsafe. The following table describes each analyzer.  
Analyzer  
Description  
Dataflow  
The Dataflow Analyzer detects potential vulnerabilities that involve tainted data  
(user-controlled input or private data) put to potentially dangerous use. The  
Dataflow Analyzer uses interprocedural taint propagation analysis to detect the  
flow of data between a site of user input (or private data) through the  
application to a dangerous function call or operation. For example, the Dataflow  
Analyzer detects whether a user-controlled input string dynamically generates  
HTML (Cross-Site Scripting) and detects whether a user-controlled string  
constructs SQL queries (SQL injection).  
Page 19 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 1: Introduction  
Analyzer  
Description  
Control Flow  
The Control Flow Analyzer detects potentially dangerous sequences of  
operations. By analyzing control flow paths in a program, the Control Flow  
Analyzer determines whether a set of operations are executed in a certain order.  
For example, the Control Flow Analyzer detects time of check/time of use issues  
and race conditions, and checks whether utilities, such as XML readers, are  
configured properly before being used.  
Buffer  
The Buffer Analyzer detects buffer overflow vulnerabilities that involve writing  
or reading more data than a buffer can hold. The buffer can be either stack-  
allocated or heap-allocated. The Buffer Analyzer uses limited interprocedural  
analysis to determine whether there is a condition that causes the buffer to  
overflow. If any execution path to a buffer leads to a buffer overflow, OpenText  
SAST reports it as a buffer overflow vulnerability and points out the variables  
that might cause the overflow. If the value of the variable causing the buffer  
overflow is tainted (user-controlled), then OpenText SAST reports it as well and  
displays the dataflow trace to show how the variable is tainted.  
Structural  
The Structural Analyzer detects potentially dangerous flaws in the structure or  
definition of the program. By understanding the way programs are structured,  
the Structural Analyzer identifies violations of secure programming practices  
and techniques that are often difficult to detect through inspection because they  
encompass a wide scope involving both the declaration and use of variables and  
functions. For example, the Structural Analyzer detects hard-coded secrets,  
cookie misconfiguration in code, and encryption weaknesses.  
Configuration  
The Configuration Analyzer searches for mistakes, weaknesses, and policy  
violations in application deployment configuration files. For example, the  
Configuration Analyzer checks for reasonable timeouts in user sessions in a web  
application. The Configuration Analyzer also performs regular expression  
analysis (see "Regular expression analysis" on page 66).  
Semantic  
Content  
The Semantic Analyzer detects potentially dangerous uses of functions and APIs  
at the intra-procedural level.  
The Content Analyzer searches for security issues and policy violations in HTML  
content. In addition to static HTML pages, the Content Analyzer performs these  
checks on files that contain dynamic HTML, such as PHP, JSP, and classic ASP  
files.  
Null Pointer  
The Null Pointer Analyzer detects dereferences of pointer variables that are  
Page 20 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 1: Introduction  
Analyzer  
Description  
assigned the null value. The Null Pointer Analyzer detection is performed at the  
intra-procedural level. Issues are detected only when the null assignment, the  
dereference, and all the paths between them occur within a single function.  
Licensing  
OpenText SAST requires a license to perform both the translation and analysis (scan) phases of  
security analysis (for more information about these phases, see "Analysis process" on page 62).  
You must download the Fortify license file for your product from the Software Licenses and  
Downloads (SLD) portal. Use the credentials that Customer Support has provided for access.  
To install OpenText SAST, you must have a Fortify license file (fortify.license) and optionally  
you can use the Fortify License and Infrastructure Manager to manage concurrent licenses for  
OpenText SAST. With a LIM managed concurrent license, multiple installations of OpenText SAST can  
share a single license. For information about how to set up the LIM with licenses for OpenText SAST,  
see OpenText™ Fortify License and Infrastructure Manager Installation and Usage Guide. For more  
information about managing your LIM license from OpenText SAST, see "LIM license directives" on  
page 162.  
Note: Using OpenText™ Fortify License and Infrastructure Manager (LIM) to manage concurrent  
licenses for OpenText SAST requires LIM version 21.2.0 or later.  
Renewing an expired license  
The license for OpenText SAST expires annually.  
To update an expired license:  
l
Put the updated Fortify license file in the root directory where OpenText SAST is installed.  
To update an expired LIM managed concurrent license, see the OpenText™ Fortify License and  
Infrastructure Manager Installation and Usage Guide.  
Fortify Software Security Content  
OpenText SAST uses a knowledge base of rules to enforce secure coding standards applicable to the  
codebase for static analysis. Fortify Software Security Center is required for both translation and  
analysis. You can download and install security content when you install OpenText SAST (see  
"Installing OpenText SAST" on page 47). Alternatively, you can download or import previously  
downloaded Fortify Software Security Content with the fortifyupdate command-line tool as a post-  
installation task (see "Manually installing Fortify Software Security Content" on page 53).  
Page 21 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 1: Introduction  
Fortify Software Security Content (security content) consists of Fortify Secure Coding Rulepacks and  
external metadata:  
l
Fortify Secure Coding Rulepacks describe general secure coding idioms for popular languages and  
public APIs  
l
External metadata includes mappings from the Fortify categories to alternative categories (such as  
CWE, OWASP Top 10, and PCI)  
OpenText provides the ability to write custom rules that add to the functionality of OpenText SAST  
and the Fortify Secure Coding Rulepacks. For example, you might need to enforce proprietary security  
guidelines or analyze a project that uses third-party libraries or other pre-compiled binaries that are  
not already covered by the Fortify Secure Coding Rulepacks. You can also customize the external  
metadata to map Fortify issues to different taxonomies, such as internal application security  
standards or additional compliance obligations. For instructions on how to create your own custom  
rules or custom external metadata, see the OpenText™ Static Application Security Testing Custom  
Rules Guide.  
OpenText recommends that you periodically update the security content. You can use fortifyupdate  
to obtain the latest security content. For more information, see "Updating Fortify Software Security  
Content" on page 166.  
Fortify ScanCentral SAST  
You can use OpenText™ Fortify ScanCentral SAST to manage your resources by offloading the  
OpenText SAST analysis phase from build machines to a collection of machines provisioned for this  
purpose. For most languages, Fortify ScanCentral SAST can perform both the translation and the  
analysis (scan) phases. Users of Fortify Software Security Center can direct Fortify ScanCentral SAST  
to output the FPR file directly to the server. You have the option to install a Fortify ScanCentral SAST  
client when you install OpenText SAST.  
You can analyze your code in one of two ways:  
l
If your application is written in a language supported for Fortify ScanCentral SAST translation, you  
can offload the translation and analysis (scan) phase of the analysis to Fortify ScanCentral SAST.  
l
Perform the translation phase on a local build machine and generate a mobile build session (MBS).  
Start the scan with Fortify ScanCentral SAST using the MBS file. In addition to freeing up the build  
machines, this process gives you the ability to expand the system by adding more resources as  
needed, without having to interrupt the build process. For more information about MBS, see "Using  
mobile build sessions" on page 198.  
For information about the specific supported languages for translation and how to configure and use  
Fortify ScanCentral SAST, see the OpenText™ Fortify ScanCentral SAST Installation, Configuration,  
and Usage Guide.  
Page 22 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 1: Introduction  
OpenText Application Security Tools  
OpenText provides applications and tools (including Secure Code Plugins) that integrate with  
OpenText SAST, Fortify ScanCentral SAST, and Fortify Software Security Center. The following table  
describes the applications that are available for installation with the OpenText Application Security  
Tools installer. For instructions about installing the OpenText Application Security Tools, see the  
OpenText™ Application Security Tools Guide.  
Application  
Description  
OpenText™ Fortify Audit  
Workbench  
An application that provides a graphical user interface to help  
you organize, investigate, and prioritize analysis results so  
that developers can fix security flaws quickly.  
OpenText™ Fortify Plugin for  
Eclipse  
Adds the ability to scan and analyze the entire codebase of a  
project and apply software security rules that identify the  
vulnerabilities in your Java code from the Eclipse IDE. The  
results are displayed, along with descriptions of each of the  
security issues and suggestions for their elimination.  
OpenText™ Fortify Analysis  
Adds the ability to run scans on the entire codebase of a  
project and apply software security rules that identify the  
vulnerabilities in your code from IntelliJ IDEA and Android  
Studio.  
Plugin for IntelliJ IDEA and  
Android Studio  
OpenText™ Fortify Extension for  
Visual Studio  
Adds the ability to scan and locate security vulnerabilities in  
your solutions and projects and displays the scan results in  
Visual Studio. The results include a list of issues uncovered,  
descriptions of the type of vulnerability each issue represents,  
and suggestions on how to fix them. This extension also  
includes remediation functionality that works with audit  
results stored on a Fortify Software Security Center server.  
OpenText™ Fortify Custom Rules An application to create and edit custom rules.  
Editor  
Fortify Scan Wizard  
Provides a graphical user interface that enables you to  
prepare a script to scan your code (either locally or remotely  
using Fortify ScanCentral SAST) and then optionally upload  
the results to Fortify Software Security Center.  
BIRTReportGenerator  
Command-line tools to generate issue reports (BIRT) and  
Page 23 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 1: Introduction  
Application  
Description  
ReportGenerator  
legacy reports from FPR files.  
Sample projects  
OpenText provides sample projects available as a separate download in the OpenText_SAST_  
Fortify_Samples_<version>.zippackage.  
The ZIP file contains two directories: basicand advanced. Each code sample includes a README.txt  
file that provides instructions on how to scan the code with OpenText SAST and view the results in  
Fortify Audit Workbench.  
The basicdirectory includes an assortment of simple language-specific code samples. The  
advanceddirectory includes more advanced samples.  
Related documents  
This topic describes documents that provide information about OpenText Application Security  
Software products.  
Note: Most guides are available in both PDF and HTML formats.  
All products  
The following documents provide general information for all products. Unless otherwise noted, these  
documents are available on the Product Documentation website for each product.  
Document / file name  
Description  
About OpenText Application Security This paper provides information about how to access  
Software Documentation  
OpenText Application Security Software product  
documentation.  
appsec-docs-n-<version>.pdf  
Note: This document is included only with the  
product download.  
OpenText Application Security  
Software Release Notes  
This document provides an overview of the changes made  
to OpenText Application Security Software for this release  
and important information not included elsewhere in the  
product documentation.  
Page 24 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 1: Introduction  
Fortify ScanCentral SAST  
The following document provides information about Fortify ScanCentral SAST. This document is  
available on the Product Documentation website at  
https://www.microfocus.com/documentation/fortify-software-security-center.  
Document / file name  
Description  
OpenText™ Fortify ScanCentral SAST This document provides information about how to install,  
Installation, Configuration, and Usage configure, and use Fortify ScanCentral SAST to streamline  
Guide  
the static code analysis process. It is written for anyone  
who intends to install, configure, or use Fortify  
ScanCentral SAST to offload the resource-intensive  
translation and scanning phases of their OpenText SAST  
process.  
sc-sast-ugd-<version>.pdf  
Fortify Software Security Center  
The following document provides information about Fortify Software Security Center. This document  
is available on the Product Documentation website at  
https://www.microfocus.com/documentation/fortify-software-security-center.  
Document / file name  
Description  
OpenText™ Applicaton Security  
User Guide  
This document provides Fortify Software Security Center  
users with detailed information about how to deploy and use  
Fortify Software Security Center. It provides all the  
information you need to deploy, configure, and use Fortify  
Software Security Center.  
ssc-ugd-<version>.pdf  
It is intended for use by system and instance administrators,  
database administrators (DBAs), enterprise security leads,  
development team managers, and developers. Fortify  
Software Security Center provides security team leads with a  
high-level overview of the history and status of a project.  
Page 25 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 1: Introduction  
OpenText SAST  
The following documents provide information about OpenText SAST (Fortify Static Code Analyzer).  
Unless otherwise noted, these documents are available on the Product Documentation website at  
https://www.microfocus.com/documentation/fortify-static-code.  
Document / file name  
Description  
OpenText™ Static Application  
Security Testing User Guide  
This document describes how to install and use OpenText  
SAST to scan code on many of the major programming  
platforms. It is intended for people responsible for security  
audits and secure coding.  
sast-ugd-<version>.pdf  
OpenText™ Static Application  
This document provides the information that you need to  
Security Testing Custom Rules Guide create custom rules for OpenText SAST. This guide  
includes examples that apply rule-writing concepts to  
real-world security issues.  
sast-cr-ugd-<version>.zip  
Note: This document is included only with the  
product download.  
OpenText™ Fortify License and  
Infrastructure Manager Installation  
and Usage Guide  
This document describes how to install, configure, and use  
the Fortify License and Infrastructure Manager (LIM),  
which is available for installation on a local Windows  
server and as a container image on the Docker platform.  
lim-ugd-<version>.pdf  
OpenText Application Security Tools  
The following documents provide information about OpenText Application Security Tools. These  
documents are available on the Product Documentation website at  
https://www.microfocus.com/documentation/fortify-static-code-analyzer-and-tools.  
Document / file name  
Description  
OpenText™ Application Security  
Tools Guide  
This document describes how to install application  
security tools. It provides an overview of the applications  
and command-line tools that enable you to scan your code  
with OpenText SAST, review analysis results, work with  
analysis results files, and more.  
sast-tgd-<version>.pdf  
OpenText™ Fortify Audit Workbench This document describes how to use Fortify Audit  
Page 26 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 1: Introduction  
Document / file name  
Description  
User Guide  
Workbench to scan software projects and audit analysis  
results. This guide also includes how to integrate with bug  
trackers, produce reports, and perform collaborative  
auditing.  
awb-ugd-<version>.pdf  
OpenText™ Fortify Plugin for Eclipse This document provides information about how to install  
User Guide  
and use the Fortify Plugin for Eclipse to analyze and audit  
your code.  
ep-udg-<version>.pdf  
OpenText™ Fortify Analysis Plugin for This document describes how to install and use the Fortify  
IntelliJ IDEA and Android Studio User  
Guide  
to  
Analysis Plugin for IntelliJ IDEA and Android Studio  
analyze your code and optionally upload the results to  
Fortify Software Security Center.  
iap-udg-<version>.pdf  
OpenText™ Fortify Extension for  
Visual Studio User Guide  
This document provides information about how to install  
and use the Fortify Extension for Visual Studio to analyze,  
audit, and remediate your code to resolve security-related  
issues in solutions and projects.  
vse-ugd-<version>.pdf  
Page 27 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
Chapter 2: System requirements  
This chapter describes the system requirements, supported languages, build tools, and compilers, and  
how to acquire the OpenText SAST software package.  
This section contains the following topics:  
Hardware requirements  
Supported platforms and architectures  
Software requirements  
28  
31  
32  
33  
41  
42  
42  
43  
43  
45  
Supported languages  
Supported build tools  
Supported compilers  
Fortify Software Security Content  
Virtual Machine support  
Acquiring software  
Verifying software downloads  
Hardware requirements  
System resources such as CPU, memory, and storage can drastically impact the overall analysis time  
for a project. It depends on many factors related to the target project codebase such as overall code  
size, composition, language, and code complexity. The following guidance provides some general  
starting points based on our experience scanning many different real-world applications.  
Application  
size and  
complexity  
CPU  
cores  
RAM  
(GB)  
Description  
Small and  
simple  
4
16 A small standalone system that runs on a server or desktop  
such as a batch job or a command-line tool and includes:  
l
Less than 10,000 functions  
Page 28 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 2: System requirements  
Application  
size and  
complexity  
CPU  
cores  
RAM  
(GB)  
Description  
Small and  
simple  
(dynamic  
language)  
8
32 A standalone system that works with complex computer  
models such as a tax calculation system or a scheduling  
system and includes:  
l
Less than 10,000 functions  
l
Primarily a dynamic language such as JavaScript,  
TypeScript, Python, PHP, and Ruby  
Medium  
16  
32  
64– A three-tiered business system with transactional data  
128 processing such as a financial system or a commercial  
website and includes:  
l
Less than 100,000 functions  
l
Over one million lines of code  
Large and  
complex  
256 A system that delivers content such as an application server,  
database server, or content management system and  
includes:  
l
Over 1 million functions  
l
Several million lines of code  
OpenText SAST takes advantage of all CPU cores available on your system to reduce the scan time of  
large projects. When you run OpenText SAST, avoid running other CPU intensive processes during  
the OpenText SAST execution because it expects to have the full resources of your hardware  
available for the scan.  
Additional system resource tuning considerations:  
l
Virtual systems—Virtualization enables hardware resources to be scaled by identifying unused  
resources in a workload and reallocating them to other workloads. Because OpenText SAST  
analysis is generally a long running resource intensive process (especially in large and complex  
projects), OpenText recommends dedicated resources at the virtualization layer to reduce resource  
swapping.  
l
CPU—Overall processing power can have significant impact on the total time required for analysis.  
OpenText recommends a high end processor with a fast clock speed (GHz per core). It is important  
to note that there is a correlation between the number of cores available to the system and the  
amount of memory that might be needed.  
l
Memory—For more information on how to determine the amount of memory required for optimal  
performance, see "Memory tuning" on page 184. Note that analysis of dynamic languages such as  
JavaScript, TypeScript, Python, PHP, and Ruby require more memory during the scan phase that  
Page 29 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 2: System requirements  
other languages.  
l
Disk I/O—Project translation and scan are I/O intensive activities that serialize large amounts of  
data and benefit from faster storage. OpenText recommends that you run analysis on faster SSD  
storage when possible.  
l
Number of functions—You can verify the number of functions modeled during the analysis by  
running a scan with the -debugoption and looking for the last occurrence of the  
NameTable.funs: ###value in the Support log file.  
See also  
"Sample scans" below  
Sample scans  
These sample scans were performed using OpenText SAST version 25.2.0 on dedicated virtual  
machines. These scans were run with Fortify Software Security Content 25.1 Update. The following  
table shows the scan times you can expect for several common open-source projects.  
Analysis  
Translation time (scan) time  
System  
Language  
Project name  
(mm:ss)  
(mm:ss) Total issues  
LOC configuration  
.NET (C#)  
SharpZipLib  
2:22  
11:26  
00:50  
04:04  
00:55  
01:42  
13:12  
03:11  
02:09  
109  
31,779 Windows Server  
2022 with 4 CPUs  
and 32 GB of RAM  
ABAP  
C/C++  
Java  
abap2UI5  
00:14  
00:37  
00:17  
00:10  
04:51  
00:21  
00:34  
10  
58,857 Linux (AlmaLinux  
9) with 4 CPUs and  
32 GB of RAM  
nasm 0.98.38  
WebGoat 8  
741  
80  
35,960 Linux (Centos 7)  
with 8 CPUs and  
32 GB of RAM  
23,412 Linux (AlmaLinux  
9) with 4 CPUs and  
32 GB of RAM  
Java  
WordPress for  
Android  
342  
158  
3,552  
834  
35,167 Linux (AlmaLinux  
9) with 4 CPUs and  
32 GB of RAM  
JavaScript  
PHP  
three.js  
678,332 Linux (CentOS 8)  
with 8 CPUs and 64  
GB RAM  
CakePHP  
phpBB 3  
136,463 Linux (AlmaLinux  
9) with 4 CPUs and  
32 GB of RAM  
PHP  
206,728 Linux (AlmaLinux  
Page 30 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 2: System requirements  
Analysis  
Translation time (scan) time  
System  
Language  
Project name  
(mm:ss)  
(mm:ss) Total issues  
LOC configuration  
9) with 4 CPUs and  
32 GB of RAM  
Python 3  
numpy-1.13.3  
02:03  
07:57  
66  
562,731 Linux (CentOS 4/5)  
with x86 and 32  
GB RAM  
Swift  
MediaBrowser  
rxjs-7.8.1  
00:20  
01:55  
01:23  
06:21  
9
5
17,611  
with 4 CPUs  
macOS  
and 16 GB of RAM  
TypeScript  
247,193 Linux (CentOS 8)  
with 8 CPUs and 64  
GB RAM  
Supported platforms and architectures  
OpenText SAST supports the platforms and architectures listed in the following table.  
Operating  
system  
Distributions and  
versions  
Platforms  
Notes  
Microsoft  
Windows®  
x64  
Windows 10, 11  
Windows Server  
2019, 2022  
Linux®  
x64  
CentOS Linux 7.x  
(7.6 or later)  
ARM  
Red Hat®  
Enterprise Linux®  
7.x (7.2 or later),  
8.x (8.2 or later),  
9.x  
SUSE® Linux®  
Enterprise Server  
15  
Ubuntu® 20.04.1  
LTS, 22.04.1 LTS  
macOS®  
x64  
14, 15  
The M series are Apple designed CPUs based  
Page 31 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 2: System requirements  
Operating  
system  
Distributions and  
versions  
Platforms  
Notes  
M series  
on the ARM architecture. OpenText SAST can  
run on M series processors through the  
Rosetta emulation layer.  
IBM® AIX®  
7.1, 7.2, 7.3  
Power ISA  
Important! You must have the IBM XL  
C/C++ for AIX 16.1 Runtime environment  
package installed.  
Software requirements  
The OpenText SAST installation includes an embedded OpenJDK/JRE version 17.0.14, which the  
software requires. You do not need to install Java 17.  
To use OpenText SAST, you must have Read and Write permissions for the OpenText SAST  
installation directory.  
The following table lists software requirements for analysis of specific project types.  
Language  
Software  
Operating systems  
Visual Studio, MSBuild, or  
.NET projects  
.NET Framework 4.8 or later (MSBuild Windows  
only)  
Windows, Linux  
.NET SDK 8.0  
ABAP®/BSP  
All  
Fortify ABAP Extractor is supported  
on a system running ABAP Platform  
2023 / ABAP Version 7.58.  
Bicep  
.NET SDK 8.0  
Windows, Linux  
Windows  
COBOL  
Microsoft Visual C++ 2017  
Redistributable (x86)  
Note: This is not a requirement  
for legacy COBOL analysis.  
Scala  
The Akka compiler plugin is available All  
in the Maven Central Repository.  
Page 32 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 2: System requirements  
Supported languages  
OpenText SAST supports the programming languages listed in the following table.  
Language /  
framework  
Versions  
.NET (Core)  
1.0-9.x  
.NET Framework 2.0–4.8  
ABAP/BSP  
ActionScript  
Apex  
6.x, 7.x  
3.0  
55–61  
Bicep  
0.12.x–0.15.31  
5–13  
C#  
C
C11, C17, C23 (see "Supported compilers" on page 42)  
C++  
C++11, C++14, C++17, C++20 (see  
2.0, 3.0  
)
"Supported compilers" on page 42  
Classic ASP  
(with VBScript)  
COBOL  
IBM Enterprise COBOL for z/OS 6.1–6.3 (CICS, IMS, DB2, and IBM MQ)  
Visual COBOL 6.0–8.0  
ColdFusion  
Dart™  
8–10  
2.12-3.1  
any  
Docker®  
(Dockerfiles)  
Go™  
programming  
language  
1.12–1.23  
2.0  
HCL  
Page 33 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 2: System requirements  
Language /  
framework  
Versions  
Note: HCL language support is specific to Terraform and supported cloud  
provider Infrastructure as Code (IaC) configurations.  
HTML  
Java  
5 or earlier  
7–21  
(including  
Android)  
JavaScript  
JSON  
ECMAScript® 2015–2024  
ECMA-404  
1.2–2.1  
1.3–2.0  
4
JSP  
Kotlin  
MXML (  
Flex®  
)
Objective-C/C++  
PHP  
2.0 (see "Supported compilers" on page 42)  
7.3–8.4  
PL/SQL  
Python®  
Ruby  
8–23  
2.6–3.13  
1.x  
Scala  
2.11–2.13, 3.3.0–3.3.5  
0.4.12–0.8.21  
Solidity  
Swift®  
5.0–5.10, 6.0 (see "Supported compilers" on page 42 for supported swiftc  
versions)  
T-SQL  
SQL Server 2005, 2008, 2012  
TypeScript  
VBScript  
3.6–5.4  
2.0, 5.0  
Page 34 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 2: System requirements  
Language /  
framework  
Versions  
Visual Basic  
(VB.NET)  
15.0–16.9  
Visual Basic  
XML  
6.0  
1.0, 1.1  
1.2  
YAML  
Supported libraries, frameworks, and technologies  
OpenText SAST supports the libraries, frameworks, and technologies listed in this section with  
dedicated Fortify Secure Coding Rulepacks and vulnerability coverage beyond core supported  
languages.  
Java  
Adobe Flex Blaze DS  
Ajanta  
Apache Slide  
iBatis  
Mozilla Rhino  
MyBatis  
Spring AI  
Apache Spring  
Security (Acegi)  
IBM MQ  
Spring MVC  
Amazon Web Services  
(AWS) SDK  
IBM WebSphere  
Jackson  
MyBatis-Plus  
Netscape LDAP API  
OkHttp  
Spring Boot  
Apache Struts  
Apache Tapestry  
Apache Tomcat  
Apache Torque  
Apache Util  
Spring Data Commons  
Spring Data JPA  
Spring Data MongoDB  
Spring Data Redis  
Spring for GraphQL  
Spring HATEOAS  
Spring JMS  
Android  
Jakarta Activation  
Jakarta EE (Java EE)  
Jasypt  
Android Jetpack  
Apache Axiom  
Apache Axis  
Apache Beam  
OpenCSV  
Oracle Application  
Development  
Framework (ADF)  
Java Annotations  
Java Excel API  
JavaMail  
Apache Velocity  
Oracle BC4J  
Apache Beehive NetUI Apache Wicket  
Oracle JDBC  
Apache Catalina  
Apache Cocoon  
Apache Commons  
Apache ECS  
Apache Xalan  
Apache Xerces  
ATG Dynamo  
Azure SDK  
Castor  
JAX-RS  
Spring JMX  
Oracle OA Framework  
Oracle tcDataSet  
JAXB  
Spring Messaging  
Spring Security  
Spring Webflow  
Spring WebSockets  
Spring WS  
Jaxen  
Oracle XML Developer  
Kit (XDK)  
JBoss  
Apache Hadoop  
JDesktop  
JDOM  
OWASP Enterprise  
Security API (ESAPI)  
Apache  
HttpComponents  
Display Tag  
Dom4j  
OWASP HTML  
Sanitizer  
Jetty  
Stripes  
Apache Jasper  
Apache Log4j  
Apache Lucene  
GDS AntiXSS  
Google Cloud  
JGroups  
Sun JavaServer Faces  
(JSF)  
OWASP Java Encoder  
Plexus Archiver  
json-simple  
Page 35 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 2: System requirements  
Apache MyFaces  
Apache OGNL  
Apache ORO  
Apache POI  
Google Dataflow  
Google Guava  
Google Web Toolkit  
gRPC  
JTidy Servlet  
JXTA  
Realm  
Tungsten  
Restlet  
Weblogic  
JYaml  
SAP Web Dynpro  
Saxon  
WebSocket  
XStream  
Liferay Portal  
MongoDB  
Apache SLF4J  
Gson  
SnakeYAML  
Spring  
YamlBeans  
ZeroTurnaround ZIP  
Zip4J  
Hibernate  
Kotlin  
Kotlin support includes all libraries covered for Java and the following Kotlin libraries.  
Kotlin standard library  
Scala  
Scala support includes all libraries covered for Java and the following Scala libraries.  
Akka HTTP  
Scala Play  
Scala Slick  
.NET  
.NET Framework, .NET Azure SDK  
Core, and .NET  
Standard  
Hot Chocolate  
MongoDB  
SharePoint Services  
SharpCompress  
SharpZipLib  
Castle ActiveRecord  
IBM Informix .NET  
Provider  
MySQL  
Connector/NET  
CsvHelper  
.NET WebSockets  
Json.NET Log4Net  
NHibernate  
NLog  
Dapper  
SQLite .NET Provider  
SubSonic  
ADO.NET Entity  
Framework  
Microsoft  
ApplicationBlocks  
DB2 .NET Provider  
DotNetZip  
Npgsql  
Sybase ASE ADO.NET  
Data Provider  
ADODB  
Microsoft My  
Framework  
Open XML SDK  
Entity Framework  
Entity Framework Core  
fastJSON  
Amazon Web Services  
(AWS) SDK  
Oracle Data Provider  
for .NET  
Xamarin  
Microsoft Practices  
Enterprise Library  
Xamarin Forms  
YamlDotNet  
ASP.NET MVC  
OWASP AntiSamy  
Saxon  
ASP.NET SignalR  
ASP.NET Web API  
Microsoft Web  
Protection Library  
gRPC  
C
ActiveDirectory LDAP CURL Library  
Apple System Logging GLib  
MySQL  
OpenSSL  
Sun RPC  
WinAPI  
Netscape LDAP  
ODBC  
POSIX Threads  
SQLite  
(ASL)  
JNI  
Page 36 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 2: System requirements  
C++  
Boost Smart Pointers  
MFC  
STL  
WMI  
SQL  
Oracle ModPLSQL  
PHP  
ADOdb  
PHP DOM  
PHP Mhash  
PHP Mysql  
PHP Reflection  
PHP Simdjson  
PHP SimpleXML  
PHP Smarty  
PHP WordPress  
PHP XML  
Advanced PHP  
Debugging  
PHP Extension  
PHP Hash  
PHP OCI8  
PHP XMLReader  
PHP Zend  
CakePHP  
PHP OpenSSL  
PHP PostgreSQL  
PHP JSON  
PHP Debug  
PHP Mcrypt  
PHP Sodium  
PHP Zip  
JavaScript/TypeScript/HTML5  
Angular  
Gemini API  
GraphQL.js  
Handlebars  
Helmet  
JS-YAML  
React  
Sequelize  
Underscore.js  
Vue  
Anthropic Claude  
Apollo Server  
Bluebird  
LangChain  
React Native  
Mustache  
React Native Async  
Storage  
Node.js Azure Storage  
React Router  
child-process-promise iOS JavaScript Bridge Node.js Core  
SAPUI5/OpenUI5  
Express  
jQuery  
OpenAI  
Python  
aiopg  
Graphene  
_mysql  
pycrypto  
PyCryptodome  
pycurl  
requests  
simplejson  
six  
Amazon Web Services gRPC  
(AWS) Lambda  
MySQL  
Connector/Python  
httplib2  
Amazon SageMaker  
Anthropic Claude  
Azure Functions  
Django  
MySQLdb  
OpenAI  
Jinja2  
pylibmc  
TensorFlow  
Twisted Mail  
urllib3  
LangChain  
libxml2  
PyMongo  
PySpark  
oslo.config  
pandas  
lxml  
PyYAML  
WebKit  
Flask  
Paramiko  
psycopg2  
memcache-client  
Google Cloud  
Ruby  
MySQL  
pg  
Rack  
Thor  
SQLite  
Page 37 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 2: System requirements  
Objective-C  
AFNetworking  
Apple CoreFoundation Apple  
Apple  
SBJson  
LocalAuthentication  
Apple MessageUI  
Apple Security  
Apple Social  
WatchConnectivity  
Apple AddressBook  
Apple AppKit  
Apple CoreLocation  
Apple CoreServices  
Apple CoreTelephony  
Apple Foundation  
SFHFKeychainUtils  
SSZipArchive  
ZipArchive  
ZipUtilities  
ZipZap  
Apple WatchKit  
Apple WebKit  
Hpple  
Apple CFNetwork  
Apple ClockKit  
Apple UIKit  
Objective-Zip  
Realm  
Apple CommonCrypto Apple HealthKit  
Apple CoreData  
Swift  
Alamofire  
Apple CoreFoundation Apple MessageUI  
Apple WatchKit  
Apple WebKit  
Hpple  
Zip  
Apple AddressBook  
Apple CFNetwork  
Apple ClockKit  
Apple CoreLocation  
Apple Foundation  
Apple HealthKit  
Apple Security  
Apple Social  
Apple SwiftUI  
Apple UIKit  
ZipArchive  
ZIPFoundation  
ZipUtilities  
ZipZap  
Realm  
Apple CommonCrypto Apple  
SQLite  
LocalAuthentication  
Apple CoreData  
Apple  
SSZipArchive  
WatchConnectivity  
COBOL  
Auditor  
CICS  
Micro Focus  
POSIX  
SQL  
COBOL Run-time  
System  
DLI  
MQ  
Go  
GORM  
logrus  
gRPC  
Dart  
Flutter  
Page 38 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 2: System requirements  
Configuration  
.NET Configuration  
Docker Configuration Java Apache Struts  
Java OWASP  
AntiSamy  
OpenAPI Specification  
Oracle Application  
(Dockerfiles)  
Adobe Flex  
(ActionScript)  
Configuration  
Java Apache Tomcat  
Configuration  
GitHub Actions  
Java Spring and Spring Development  
MVC  
Framework (ADF)  
Google Android  
Configuration  
Java Blaze DS  
Ajax Frameworks  
Java Spring Boot  
Java Spring Mail  
Java Spring Security  
PHP Configuration  
PHP WordPress  
Java Hibernate  
Configuration  
Amazon Web Service  
(AWS)  
iOS Property List  
J2EE Configuration  
Java Apache Axis  
Java iBatis  
Configuration  
Silverlight  
Configuration  
Ansible  
Java Spring  
WebSockets  
Java IBM WebSphere  
Terraform (AWS,  
Azure, GCP)  
AWS CloudFormation  
Java Apache Log4j  
Configuration  
Azure Resource  
Manager (ARM)  
Java MyBatis  
Configuration  
Java Weblogic  
Kubernetes  
Mule  
WS-SecurityPolicy  
XML Schema  
Java Apache Spring  
Security (Acegi)  
Build Management  
Infrastructure as Code: Amazon Web Services  
API Gateway  
App Mesh  
AppSync  
Config  
Elastic Load Balancing Lightsail  
SageMaker  
(ELB)  
ConfigurationRecorder  
Location Service  
Secrets Manager  
ElastiCache  
EMR  
Database Migration  
Service (DMS)  
Lookout for  
Equipment  
Simple Notification  
Service (SNS)  
Athena  
DataSync  
DocumentDB  
DynamoDB  
EC2  
FinSpace  
FSx  
Mainframe  
Modernization  
Simple Queue Service  
(SQS)  
Aurora  
Backup  
Managed Streaming  
for Apache Kafka  
(MSK)  
Simple Storage  
Service (S3)  
Global Accelerator  
Glue  
Batch  
Certificate Manager  
CloudFormation  
CloudFront  
CloudTrail  
CloudWatch  
CodeBuild  
CodeCommit  
CodeStar  
Step Functions  
Systems Manager  
Timestream  
Transfer Family  
VPC  
Elastic Block Store (EBS) GuardDuty  
MemoryDB for Redis  
MQ  
Elastic Container  
Registry (ECR)  
HealthLake  
Identity and Access  
Neptune  
Elastic Container Service Management (IAM)  
(ECS)  
OpenSearch Service  
Image Builder  
Quantum Ledger  
Database (QLDB)  
Elastic File System (EFS)  
VPC Lattice  
Key Management  
Elastic Kubernetes  
Service (EKS)  
Service (KMS)  
Kinesis  
WorkSpaces Family  
RDS  
Redshift  
Rekognition  
Route 53  
Cognito  
Kinesis Video Streams  
Page 39 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 2: System requirements  
Infrastructure as Code: Microsoft Azure  
App Service  
Cache for Redis  
Cognitive Search  
Container Registry  
Cosmos DB  
Data Factory  
Defender for Cloud  
Event Hubs  
Machine Learning  
MariaDB  
Site Recovery  
Spring Apps  
SQL  
Application Gateway  
Automation  
Media Services  
Monitor  
Microsoft Entra  
Domain Services  
Front Door  
Storage Accounts  
Database for MariaDB Grafana  
NetApp Files  
Private Cloud  
Policy  
Virtual Machine Scale  
Sets  
Azure Health Data  
Services  
Database for MySQL  
Hostname Binding  
Virtual Machines  
Web PubSub  
Database for  
PostgreSQL  
IoT Central  
IoT Hub  
Azure Kubernetes  
Service (AKS)  
Portal  
Databricks  
Data Box  
Key Vault  
Logic Apps  
SignalR Service  
Batch  
Blob Storage  
Infrastructure as Code: Google Cloud  
Access Context  
Manager  
Backup for GKE  
BigQuery  
Cloud Load Balancing Filestore  
Media CDN  
Cloud Logging  
Cloud Spanner  
Cloud SQL  
Google Cloud Platform Memorystore  
AlloyDB  
Cloud Bigtable  
Cloud DNS  
Google Kubernetes  
Engine (GKE)  
Pub/Sub  
Apigee API  
Management  
Secret Manager  
Workflows  
Identity and Access  
Management (IAM)  
Cloud Functions  
Cloud Storage  
Compute Engine  
App Engine  
Cloud Key  
Management  
Artifact Registry  
Secrets  
.netrc  
Defined  
DES  
HashiCorp (Terraform,  
Vault)  
New Relic  
npm  
Sendbird  
SendGrid  
Sentry  
1Password  
Heroku  
DigitalOcean  
Docker  
NuGet  
Okta  
Actually Good  
Encryption (AGE)  
HexChat  
SHA1  
Adafruit  
HubSpot  
Doppler  
Droneci  
OpenVPN  
SHA256  
SHA512  
Shippo  
Adobe  
Intercom  
Password in  
comment  
Airtable  
Java  
Dropbox  
Duffel  
Algolia  
JFrog (Artifactory)  
JSON Web Token  
KDE Wallet (Kwallet)  
KeePass  
Password in  
connection string  
Shopify  
Sidekiq  
Alibaba (Aliyun)  
Amazon (AWS, MWS)  
Apple (macOS)  
Apache HTTP  
Asana  
Dynatrace  
EasyPost  
Encryption key  
Etsy  
Password in  
PowerShell script  
Slack  
SonarQube  
Square  
Password in URI  
Password Safe  
Kraken  
Kucoin  
Facebook  
Squarespace  
PayPal (Braintree)  
Page 40 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 2: System requirements  
Atlassian  
Authress  
Fastly  
LaunchDarkly  
Linear  
Pidgin  
StackHawk  
Stripe  
Finicity  
Finnhub  
Flickr  
Plaid  
Basic access  
authentication  
LinkedIn  
Lob  
Planetscale  
PostgreSQL  
Postman  
Prefect  
Pulumi  
Sumologic  
Telegram  
Travis  
bcrypt  
Flutterwave  
Frame.io  
Freshbooks  
Git  
Mailchimp  
Mailgun  
Beamer  
Trello  
Bearer token  
Bitbucket  
Bittrex  
Mapbox  
Mattermost  
MD5  
Twilio  
PuTTY  
Twitch  
GitHub  
GitLab  
PyPI  
Twitter  
Typeform  
Yandex  
Zendesk  
Brevo (Sendinblue)  
Clojars  
MessageBird  
RapidAPI  
Readme  
Gitter  
Microsoft (Azure App  
Storage, Cosmos DB,  
Functions and Bitlocker,  
Code Climate  
Codecov  
GNOME  
RSA Security  
Ruby (Ruby on Rails,  
RubyGems)  
PowerShell, RDP, VBScript)  
GNU (Bash)  
GoCardless  
Coinbase  
Confluent  
Contentful  
Databricks  
Datadog  
Microsoft (Outlook)  
Mutt  
Sauce Labs  
Secret key  
Google (API, Google  
Cloud, OAuth)  
MySQL  
Grafana  
Secure Shell Protocol  
(SSH)  
Netlify  
Supported build tools  
OpenText SAST supports the build tools listed in the following table.  
Build tool  
Apache Ant™  
Bazel  
Versions  
1.9.x, 1.10.x  
6.x–7.x  
Notes  
Bazel integration supports Java and Python.  
dotnet  
6.0–9.x  
Gradle  
(build integration)  
5.0–8.10  
OpenText SAST Gradle integration supports Java, Kotlin,  
and C/C++.  
Gradle  
5.6.4–8.5  
OpenText SAST Gradle Plugin supports Java and Kotlin.  
(Gradle plugin)  
Apache Maven™  
Software  
3.6.x, 3.8.x,  
3.9.x  
Page 41 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 2: System requirements  
Build tool  
MSBuild  
Versions  
Notes  
14.x–17.11  
xcodebuild  
15–15.4, 16–  
16.2  
Supported compilers  
OpenText SAST supports the compilers listed in the following table.  
Compiler  
Versions  
Operating systems  
Windows, Linux, macOS  
Windows, Linux, macOS, AIX  
Windows, Linux, macOS  
Windows, Linux, macOS, AIX  
Windows, Linux, macOS, AIX  
Windows, Linux, macOS  
Windows  
gcc  
GNU gcc 6.x–13  
GNU gcc 4.9–5.x  
GNU g++ 6.x–13  
GNU g++ 4.9–5.x  
9, 10, 11, 12, 13, 14, 17, 21  
7, 8, 9  
g++  
OpenJDK javac  
Oracle javac  
cl (MSVC)  
Clang  
2015, 2017, 2019, 2022  
15.0.0, 16.0.0  
macOS  
1
Swiftc  
5.9, 5.9.2, 5.10, 6.0, 6.0.2, 6.0.3  
macOS  
1
OpenText SAST supports applications built in the following Xcode versions: 15–15.4, 16–16.2.  
Fortify Software Security Content  
Fortify Secure Coding Rulepacks are backward compatible with all supported OpenText SAST  
versions. This ensures that Rulepack updates do not break any working OpenText SAST installation.  
Page 42 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 2: System requirements  
Virtual Machine support  
You can run OpenText Application Security Software products on an approved operating system in  
virtual machine environments. You must provide dedicated CPU and memory resources that meet the  
minimum hardware requirements. If you find issues that cannot be reproduced on the native  
environments with the recommended processing, memory, and disk resources, you must work with  
the provider of the virtual environment to resolve them.  
Note: If you run OpenText Application Security Software products in a VM environment,  
OpenText strongly recommends that you have CPU and memory resources fully committed to  
the VM to avoid performance degradation.  
Acquiring software  
OpenText SAST (Fortify Static Code Analyzer) is available as an electronic download. For instructions  
on how to download the software from the Software Licenses and Downloads (SLD) portal, click  
Contact Us / Self Help to review the videos and the Quick Start Guide.  
The following table lists the available packages and describes their contents.  
File name  
Description  
OpenText_SAST_Fortify_  
Windows_<version>.zip  
OpenText SAST package for Windows  
This package includes:  
l
OpenText SAST installer, which includes the following  
components:  
l
OpenText SAST  
l
Fortify ScanCentral SAST client  
l
Fortify License and Infrastructure Manager installer  
l
OpenText SAST Custom Rules Guide bundle  
l
About OpenText Application Security Software Documentation  
Note: Fortify Software Security Content (Rulepacks and  
external metadata) can be downloaded during the installation.  
OpenText_SAST_Fortify_  
Signature file for the OpenText SAST Windows package  
Windows_<version>.zip.sig  
Page 43 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 2: System requirements  
File name  
Description  
OpenText_SAST_Fortify_  
Linux-ARM_<version>.tar.gz  
OpenText SAST package for Linux on ARM  
This package includes:  
l
OpenText SAST installer, which includes the following  
components:  
l
OpenText SAST  
l
Fortify ScanCentral SAST client  
l
OpenText SAST Custom Rules Guide bundle  
l
About OpenText Application Security Software Documentation  
Note: Fortify Software Security Content (Rulepacks and  
external metadata) can be downloaded during the installation.  
OpenText_SAST_Fortify_  
Linux-ARM_  
Signature file for the OpenText SAST Linux on ARM package  
<version>.tar.gz.sig  
OpenText_SAST_Fortify_  
Linux_<version>.tar.gz  
OpenText SAST package for Linux  
This package includes:  
l
OpenText SAST installer, which includes the following  
components:  
l
OpenText SAST  
l
Fortify ScanCentral SAST client  
l
OpenText SAST Custom Rules Guide bundle  
l
About OpenText Application Security Software Documentation  
Note: Fortify Software Security Content (Rulepacks and  
external metadata) can be downloaded during the installation.  
OpenText_SAST_Fortify_  
Linux_<version>.tar.gz.sig  
Signature file for the OpenText SAST Linux package  
OpenText SAST package for macOS  
OpenText_SAST_Fortify_  
Mac_<version>.tar.gz  
Page 44 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 2: System requirements  
File name  
Description  
This package includes:  
l
OpenText SAST installer, which includes the following  
components:  
l
OpenText SAST  
l
Fortify ScanCentral SAST client  
l
OpenText SAST Custom Rules Guide bundle  
l
About OpenText Application Security Software Documentation  
Note: Fortify Software Security Content (Rulepacks and  
external metadata) can be downloaded during the installation.  
OpenText_SAST_Fortify_  
Signature file for the OpenText SAST macOS package  
Mac_<version>.tar.gz.sig  
OpenText_SAST_Fortify_  
AIX_<version>.tar.gz  
OpenText SAST package for AIX  
This package includes:  
l
OpenText SAST installer  
l
OpenText SAST Custom Rules Guide bundle  
l
About OpenText Application Security Software Documentation  
OpenText_SAST_Fortify_  
Signature file for the  
AIX package  
OpenText SAST  
AIX_<version>.tar.gz.sig  
OpenText_SAST_Fortify_  
Samples_<version>.zip  
Code samples to help you learn to use OpenText SAST  
Signature file for OpenText SAST code samples  
OpenText_SAST_Fortify_  
Samples_<version>.zip.sig  
Verifying software downloads  
This topic describes how to verify the digital signature of the signed file that you downloaded from  
the Customer Support website. Verification ensures that the downloaded package has not been  
altered since it was signed and posted to the site. Before proceeding with verification, download the  
OpenText Application Security Software product files and their associated signature (*.sig) files.  
You are not required to verify the package to use the software, but your organization might require it  
for security reasons.  
Page 45 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 2: System requirements  
Preparing your system for digital signature verification  
Note: These instructions describe a third-party product and might not match the specific,  
supported version you are using. See your product documentation for the instructions for your  
version.  
To prepare your system for electronic media verification:  
1. Go to the GnuPG website.  
2. Download and install GnuPG Privacy Guard.  
3. Generate a private key, as follows:  
a.  
Run the following command (on a Windows system, run the command without the $prompt):  
$ gpg --gen-key  
b.  
c.  
When prompted for key type, select DSA and Elgamal.  
When prompted for a key size, select 2048.  
d.  
When prompted for the length of time the key should be valid, select key does not  
expire.  
e. Answer the user identification questions and provide a passphrase to protect your private  
key.  
4.  
Download the OpenText GPG public keys (compressed tar file) from  
https://mysupport.microfocus.com/documents/10180/0/MF_public_keys.tar.gz.  
5. Extract the public keys.  
6. Import each downloaded key with GnuPG with the following command:  
gpg --import <path_to_key>/<key_file>  
Page 46 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
Chapter 3: Installing OpenText SAST  
This chapter describes how to install and uninstall OpenText SAST (Fortify Static Code Analyzer).  
This chapter also describes basic post-installation tasks. See "System requirements" on page 28 to be  
sure that your system meets the minimum hardware and software requirements.  
This section contains the following topics:  
About installing OpenText SAST  
Using Docker to install and run OpenText SAST  
Upgrading OpenText SAST  
47  
53  
55  
56  
58  
About uninstalling OpenText SAST  
Post-installation tasks  
About installing OpenText SAST  
This section describes how to install OpenText SAST. Several command-line tools are installed  
automatically with OpenText SAST (see "Command-line tools" on page 165). You can optionally  
include a Fortify ScanCentral SAST client and the Fortify Software Security Center fortifyclient utility  
with the OpenText SAST installation. For information about Fortify ScanCentral SAST, see the  
OpenText™ Fortify ScanCentral SAST Installation, Configuration, and Usage Guide.  
You must provide a Fortify license file and optionally LIM license pool credentials during the  
installation. The following table lists the different ways to install OpenText SAST.  
Installation method  
Instructions  
Perform the installation using a  
standard install wizard  
"Installing OpenText SAST" on the next page  
Perform the installation silently  
(unattended)  
"Installing OpenText SAST silently" on page 50  
Perform a text-based installation on  
non-Windows systems  
"Installing OpenText SAST in text-based mode on  
non-Windows platforms" on page 52  
Perform the installation using Docker  
"Using Docker to install and run OpenText SAST" on  
page 53  
For best performance, install OpenText SAST on the same local file system where the code that you  
want to scan resides.  
Page 47 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 3: Installing OpenText SAST  
Note: On non-Windows systems, you must install OpenText SAST as a user that has a home  
directory with write permission. Do not install OpenText SAST as a non-root user that has no  
home directory.  
After you complete the installation, see "Post-installation tasks" on page 58 for additional steps you  
can perform to complete your system setup. You can also configure settings for runtime analysis,  
output, and performance of OpenText SAST by updating the installed configuration files. For  
information about the configuration options for OpenText SAST, see "Configuration options" on  
page 200.  
Installing OpenText SAST  
To install OpenText SAST:  
1. Run the installer file for your operating system to start the OpenText SAST Setup wizard:  
l
Windows: OpenText_SAST_Fortify_windows-x64_<version>.exe  
l
Linux: OpenText_SAST_Fortify_linux-x64_<version>.runor OpenText_SAST_  
Fortify_linux-arm64_<version>.run  
l
macOS: OpenText_SAST_Fortify_osx-x64_<version>.app.zip  
Uncompress the ZIP file before you run the APP installer file.  
l
AIX: OpenText_SAST_Fortify_aix-ppc64_<version>.run  
where <version> is the software release version, and then click Next.  
2. Review and accept the license agreement, and then click Next.  
3.  
(Optional) Select components to install, and then click Next.  
4. If the installer detects that the system does not include the minimum software required to  
analyze some types of projects, a System Requirements page displays any missing  
requirements and which projects require them. Click Next.  
See "Software requirements" on page 32 for all software requirements.  
5. Choose where to install OpenText SAST, and then click Next.  
If you selected to include Fortify ScanCentral SAST client with the installation in step 3, then you  
must specify a location that does not include spaces in the path.  
Important! Do not install OpenText SAST in the same directory where OpenText™  
Application Security Tools is installed.  
6.  
Specify the path to the fortify.licensefile, and then click Next.  
7. (Optional) On the LIM License page, select Yes to manage your concurrent licenses with Fortify  
License and Infrastructure Manager (LIM), and then click Next.  
Note: When OpenText SAST performs a task that requires a license, the application will  
attempt to acquire a LIM lease from the license pool. If OpenText SAST fails to acquire a  
license due to a communication issue with the LIM server, it will use the Fortify license file. To  
change this behavior, use the com.fortify.sca.lim.WaitForInitialLicensein the  
Page 48 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 3: Installing OpenText SAST  
fortify-sca.propertiesfile (see "LIM license properties" on page 210).  
a.  
Type the LIM API URL, the license pool name, and the license pool password.  
b. Click Next.  
The LIM Proxy Settings page opens.  
c. If connection to the LIM server requires a proxy server, type the proxy host (hostname or  
IP address of your proxy server) and optionally a port number.  
d. Click Next.  
8. To update the security content for your installation:  
Note: For deployment environments that do not have access to the internet during  
installation, you can update the security content using the fortifyupdate command-line tool.  
See "Manually installing Fortify Software Security Content" on page 53.  
a. Type the web address of the update server.  
To use the Fortify Rulepack update server for security content updates, keep the web  
address https://update.fortify.com. You can also use Fortify Software Security Center  
as the update server.  
b. (Optional) If connection to the update server requires a proxy server, type the proxy host and  
port number.  
c. If you want to update the security content manually, clear the Update security content  
after installation check box.  
d. Click Next.  
9. Specify if you want to migrate from a previous installation on your system.  
Migrating from a previous installation preserves OpenText SAST artifact files. For more  
information, see "Upgrading OpenText SAST" on page 55.  
Note: You can also migrate artifacts using the scapostinstallcommand-line tool. For  
information on how to use the post-install tool to migrate from a previous installation, see  
"Migrating properties files" on page 58.  
To migrate artifacts from a previous installation:  
a.  
On the OpenText SAST (Fortify) Migration page, select Yes, and then click Next.  
b. Specify the location of the existing installation on your system, and then click Next.  
To skip migration of artifacts from a previous release, leave the migration selection set to No, and  
then click Next.  
10. Click Next on the Ready to Install page to install OpenText SAST, any selected components,  
and Fortify security content.  
If you selected to update security content, the Security Content Update Result window displays  
the security content update results.  
11. Click Finish to close the Setup wizard.  
Page 49 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 3: Installing OpenText SAST  
Installing OpenText SAST silently  
A silent installation enables you to complete the installation without any user prompts. To install  
silently, you need to create an option file to provide the necessary information to the installer. Using  
the silent installation, you can replicate the installation parameters on multiple machines.  
Important! Do not install OpenText SAST in the same directory where OpenText™ Application  
Security Tools is installed.  
When you install OpenText SAST silently, the installer does not download the Fortify Software  
Security Center by default. You can enable download of the Fortify security content in the options file  
or you can install the Fortify security content manually (see "Manually installing Fortify Software  
Security Content" on page 53).  
To install OpenText SAST silently:  
1. Create an options file.  
a. Create a text file that contains the following line:  
fortify_license_path=<license_file_location>  
where <license_file_location> is the full path to your fortify.licensefile.  
b. To use a LIM license server, add the following lines with your LIM license pool credentials to  
the options file:  
lim_url=<lim_url>  
lim_pool_name=<license_pool_name>  
lim_pool_password=<license_pool_pwd>  
c. To use a location for Fortify Software Security Content updates that is different than the  
default of https://update.fortify.com, add the following line:  
update_server=<update_server_url>  
d. If you require a proxy server for the Fortify security content download, add the following lines:  
update_proxy_server=<proxy_server>  
update_proxy_port=<port_number>  
e. To enable download of Fortify security content, add the following line:  
update_security_content=1  
f. Add more installation instructions, as needed, to the options file.  
To obtain a list of installation options that you can add to your options file, open a command  
prompt, and then type the installer file name and the --helpoption. This command displays  
Page 50 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 3: Installing OpenText SAST  
each available command-line option preceded with a double dash and the available  
parameters enclosed in angle brackets. For example, if you want to see the progress of the  
install displayed at the command line, add unattendedmodeui=minimalto your options file.  
Notes:  
o
The command-line options are case-sensitive.  
o
The installation options are not the same on all supported operating systems. Run the  
installer with --helpto see the options available for your operating system.  
The following example Windows options file specifies the location of the license file, the  
location of a Fortify Software Security Center server and proxy information to obtain Fortify  
Software Security Content, a request to migrate from a previous release, and the location of  
the OpenText SAST installation directory:  
fortify_license_path=C:\Users\admin\Desktop\fortify.license  
update_server=https://my_ssc_host:8080/ssc  
update_proxy_server=webproxy.abc.company.com  
update_proxy_port=8080  
migrate_sca=1  
install_dir=C:\Fortify  
The following options file example is for Linux and macOS:  
fortify_license_path=/opt/Fortify/fortify.license  
update_server=https://my_ssc_host:8080/ssc  
update_proxy_server=webproxy.abc.company.com  
update_proxy_port=8080  
migrate_sca=1  
install_dir=/opt/Fortify  
2. Save the options file.  
3. Run the silent install command for your operating system.  
Note: You might need to run the command prompt as an administrator before you run the  
installer.  
Windows  
Linux  
OpenText_SAST_Fortify_windows-x64_<version>.exe --mode  
unattended--optionfile <full_path_to_options_file>  
./OpenText_SAST_Fortify_linux-x64_<version>.run --mode  
unattended--optionfile <full_path_to_options_file>  
or  
./OpenText_SAST_Fortify_linux-arm64_<version>.run --mode  
unattended--optionfile <full_path_to_options_file>  
Page 51 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 3: Installing OpenText SAST  
macOS  
AIX  
You must uncompress the ZIP file before you run the command.  
OpenText_SAST_Fortify_osx-x64_<version>.app/Contents/  
MacOS/installbuilder.sh --mode unattended --optionfile <full_  
path_to_options_file>  
./OpenText_SAST_Fortify_aix-ppc64_<version>.run --mode  
unattended --optionfile <full_path_to_options_file>  
The installer creates an installer log file when the installation is complete. This log file is in the  
following location, which depends on your operating system.  
Windows  
C:\Users\<username>\AppData\Local\Temp\OpenTextSASTFortify-  
<version>-install.log  
Non-Windows  
/tmp/OpenTextSASTFortify-<version>-install.log  
Installing OpenText SAST in text-based mode on non-Windows  
platforms  
You perform a text-based installation on the command line. During the installation, you are prompted  
for information required to complete the installation. Text-based installations are not supported on  
Windows systems.  
Important! Do not install OpenText SAST in the same directory where OpenText™ Application  
Security Tools is installed.  
To perform a text-based installation of OpenText SAST, run the text-based install command for your  
operating system as listed in the following table.  
Linux  
./OpenText_SAST_Fortify_linux-x64_<version>.run --mode text  
or  
./OpenText_SAST_Fortify_linux-arm64_<version>.run --mode text  
macOS  
AIX  
You must uncompress the provided ZIP file before you run the command.  
OpenText_SAST_Fortify_osx-x64_<version>.app/Contents/  
MacOS/installbuilder.sh --mode text  
./OpenText_SAST_Fortify_aix-ppc64_<version>.run --mode text  
Page 52 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 3: Installing OpenText SAST  
Manually installing Fortify Software Security Content  
You can install Fortify Software Security Content (Fortify Secure Coding Rulepacks and  
metadata) automatically during the installation. However, you can also download Fortify Software  
Security Content from the Fortify Rulepack update server, and then use the fortifyupdate command-  
line tool to install it. This option is provided for deployment environments that do not have access to  
the Internet during installation.  
Use fortifyupdate to install Fortify security content from either a remote server or a locally  
downloaded file.  
To install security content:  
1.  
2.  
Open a command window and go to <sast_install_dir>/bin/.  
At the command prompt, type fortifyupdate.  
If you have previously downloaded the Fortify Software Security Content from the Fortify  
Rulepack update server, run fortifyupdatewith the -importoption and the path to the  
directory where you downloaded the ZIP file.  
You can also use this same tool to update your Fortify Software Security Content. For more  
information about the fortifyupdate command-line tool, see "Updating Fortify Software Security  
Content" on page 166.  
Using Docker to install and run OpenText SAST  
You can install OpenText SAST in a Docker image and then run OpenText SAST as a Docker  
container.  
Note: You can only run OpenText SAST in Docker on supported Linux platforms.  
Creating a Dockerfile to install OpenText SAST  
This topic describes how to create a Dockerfile to install OpenText SAST in a Docker image.  
The Dockerfile must include the following instructions:  
1. Set a Linux system to use for the base image.  
Note: If you intend to use build tools when you run OpenText SAST, make sure that the  
required build tools are installed in the image. For information about using the supported  
build tools, see "Build integration" on page 139.  
2. Copy the OpenText SAST installer, the Fortify license file, and installation options file to the  
Docker image using the COPY instruction.  
For instructions on how to create an installation options file, see "Installing OpenText SAST  
silently" on page 50.  
Page 53 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 3: Installing OpenText SAST  
3. Run the OpenText SAST installer using the RUN instruction.  
You must run the installer in unattended mode. For more information, see "Installing OpenText  
SAST silently" on page 50.  
4. Run fortifyupdate to install the Fortify security content using the RUN instruction.  
Important! OpenText SAST requires installation of the Fortify Software Security Content to  
perform analysis of projects. The following example installs Fortify Software Security  
Content from a previously downloaded local file during the build of the image. For more  
information about downloading and installing Fortify Software Security Content using the  
fortifyupdate tool, see "Manually installing Fortify Software Security Content" on the  
previous page.  
5. To configure the image so you can run OpenText SAST, set the entry point to the location of the  
installed sourceanalyzer executable using the ENTRYPOINT instruction.  
The default sourceanalyzer installation path is: /opt/Fortify/OpenText_SAST_Fortify_  
<version>/bin/sourceanalyzer.  
The following is an example of a Dockerfile to install OpenText SAST:  
FROM ubuntu:18.04  
WORKDIR /app  
ENV APP_HOME="/app"  
ENV RULEPACK="MyRulepack.zip"  
COPY fortify.license ${APP_HOME}  
COPY OpenText_SAST_Fortify_linux-x64_25.2.0.run ${APP_HOME}  
COPY optionFile ${APP_HOME}  
COPY ${RULEPACK} ${APP_HOME}  
RUN ./OpenText_SAST_Fortify_linux-x64_25.2.0.run --mode unattended \  
--optionfile "${APP_HOME}/optionFile" && \  
/opt/Fortify/OpenText_SAST_Fortify_25.2.0/bin/fortifyupdate -import ${RULEPACK} && \  
rm OpenText_SAST_Fortify_linux-x64_25.2.0.run optionFile  
ENTRYPOINT ["/opt/Fortify/OpenText_SAST_Fortify_25.2.0/bin/sourceanalyzer"]  
To create the docker image using the Dockerfile from the current directory, you must use the docker  
build command. For example:  
docker buildx build -f <docker_file> -t <image_name> "."  
Running the container  
This topic describes how to run the OpenText SAST image as a container and provides example  
Docker run commands for translation and scan.  
Note: When you run OpenText SAST in a container and especially if you also leverage runtime  
container protections, make sure that OpenText SAST has the appropriate permission to run  
Page 54 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 3: Installing OpenText SAST  
build commands (for example, javac).  
To run the OpenText SAST image as a container, you must mount two directories from the host file  
system to the container:  
l
The directory that contains the source files you want to analyze.  
l
A temporary directory to store the OpenText SAST build session between the translate and scan  
phases and to share the output files (logs and FPR file) with the host.  
Specify this directory using the –project-rootcommand-line option in both the OpenText SAST  
translate and scan commands.  
The following example commands mount the input directory /sourcesin /srcand the temporary  
directory in /scratch_docker. The image name in the example is fortify-sast.  
Example Docker run commands for translation and scan  
The following example mounts the temporary directory and the sources directory, and then runs  
OpenText SAST from the container for the translation phase:  
docker run -v /scratch_local/:/scratch_docker -v /sources/:/src  
-it fortify-sast –b MyProject -project-root /scratch_docker [<sca_options>]  
/src  
The following example mounts the temporary directory, and then runs OpenText SAST from the  
container for the analysis phase:  
docker run -v /scratch_local/:/scratch_docker  
-it fortify-sast –b MyProject -project-root /scratch_docker –scan [<sca_  
options>] –f /scratch_docker/MyResults.fpr  
The MyResults.fproutput file is created in the host's /scratch_localdirectory.  
Upgrading OpenText SAST  
To upgrade OpenText SAST, install the new version in a different location than where your current  
version is installed and choose to migrate settings from the previous installation. This migration  
preserves and updates the artifact files located in the <sast_install_dir>/Core/config  
directory.  
If you choose not to migrate any settings from a previous release, OpenText recommends that you  
save a backup of the following data if it has been modified:  
l
<sast_install_dir>/Core/config/rulesfolder  
l
<sast_install_dir>/Core/config/customrulesfolder  
l
<sast_install_dir>/Core/config/ExternalMetadatafolder  
l
<sast_install_dir>/Core/config/CustomExternalMetadatafolder  
Page 55 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 3: Installing OpenText SAST  
l
<sast_install_dir>/Core/config/server.propertiesfile  
l
<sast_install_dir>/Core/config/scalesfolder  
After you install the new version, you can uninstall the previous version. For more information, see  
"About uninstalling OpenText SAST" below.  
Note: You can leave the previous version installed. If you have multiple versions installed on the  
same system, the most recently installed version is used when you run the command from the  
command line.  
About uninstalling OpenText SAST  
This section describes how to uninstall OpenText SAST. You can use the standard install wizard, or  
you can silently install OpenText SAST. You can also perform a text-based uninstallation on non-  
Windows systems.  
Uninstalling OpenText SAST  
To uninstall OpenText SAST:  
1. Go to the installation directory.  
2. Run the uninstall command for your operating system as described in the following table.  
OS  
Uninstall command  
Windows  
Uninstall_OpenTextSASTFortify.exe  
Alternatively, you can uninstall the application from the Windows interface. See  
the Microsoft Windows documentation for instructions.  
Linux  
AIX  
./Uninstall_OpenTextSASTFortify  
macOS  
Uninstall_OpenTextSASTFortify.app  
3. You are prompted to indicate whether to remove the entire application or individual components.  
Make your selection, and then click Next.  
If you are uninstalling specific components, select the components to remove on the Select  
Components to Uninstall page, and then click Next.  
4. You are prompted to indicate whether to remove all application settings. Do one of the following:  
l
Click Yes to remove the application settings for the components installed with the version of  
OpenText SAST that you are uninstalling.  
The OpenText SAST (sca<version>) application settings folder is not removed.  
l
Click No to retain the application settings on your system.  
Page 56 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 3: Installing OpenText SAST  
Uninstalling OpenText SAST silently  
To uninstall OpenText SAST silently:  
1. Go to the installation directory.  
2. Run the uninstall command for your operating system as described in the following table.  
OS  
Uninstall command  
Windows  
Uninstall_OpenTextSASTFortify.exe --mode unattended  
./Uninstall_OpenTextSASTFortify --mode unattended  
Linux  
AIX  
macOS  
Uninstall_  
OpenTextSASTFortify.app/Contents/MacOS/installbuilder.sh  
--mode unattended  
Note: For Windows, Linux, and macOS, the uninstaller removes the application settings for the  
components installed with the version of OpenText SAST that you are uninstalling.  
Uninstalling OpenText SAST in text-based mode on non-Windows  
platforms  
To uninstall OpenText SAST in text-based mode:  
1. Go to the installation directory.  
2. Run the uninstall command for your operating system as described in the following table.  
OS  
Uninstall command  
Linux  
AIX  
./Uninstall_OpenTextSASTFortify --mode text  
macOS  
Uninstall_  
OpenTextSASTFortify.app/Contents/MacOS/installbuilder.sh --mode  
text  
Page 57 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 3: Installing OpenText SAST  
Post-installation tasks  
Post-installation tasks prepare you to start using OpenText SAST.  
Running the post-install tool  
You can use the post-install command-line tool to migrate properties files from a previous version of  
OpenText SAST, configure Fortify security content updates, and configure settings to connect to  
Fortify Software Security Center.  
To run the post-install tool:  
1.  
2.  
Go to <sast_install_dir>/bin/.  
At the command prompt, type scapostinstall.  
3. Type one of the following:  
l
To display settings, type s.  
l
To return to the previous prompt, type r.  
l
To exit the tool, type q.  
Migrating properties files  
To migrate properties files from a previous version of OpenText SAST to the current version installed  
on your system:  
1.  
2.  
3.  
4.  
5.  
6.  
Go to <sast_install_dir>/bin/.  
At the command prompt, type scapostinstall.  
Type 1to select Migration.  
Type 1to select Static Code Analyzer Migration.  
Type 1to select Migrate from an existing Fortify installation.  
Type 1to select Set previous Fortify installation directory.  
7. Type the previous install directory.  
8.  
9.  
Type sto confirm the settings.  
Type 2to perform the migration.  
Type yto confirm.  
10.  
Page 58 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 3: Installing OpenText SAST  
Specifying a locale  
English is the default locale for an OpenText SAST installation.  
To change the locale for your OpenText SAST installation:  
1.  
2.  
3.  
4.  
5.  
Go to <sast_install_dir>/bin/.  
At the command prompt, type scapostinstall.  
Type 2to select Settings.  
Type 1to select General.  
Type 1to select Locale.  
6. Type one of the following locale codes:  
l
en(English)  
l
es(Spanish)  
l
ja(Japanese)  
l
ko(Korean)  
l
pt_BR(Brazilian Portuguese)  
l
zh_CN(Simplified Chinese)  
l
zh_TW(Traditional Chinese)  
Configuring Fortify Security Content updates  
Specify how you want to obtain Fortify security content. You must also specify proxy information if it  
is required to reach the server.  
To specify settings for Fortify Security Content updates:  
1.  
2.  
3.  
4.  
5.  
Go to <sast_install_dir>/bin/.  
At the command prompt, type scapostinstall.  
Type 2to select Settings.  
Type 2to select Fortify Update.  
To change the Fortify Rulepack update server URL, type 1, and then type the URL.  
The default Fortify Rulepack update server URL is https://update.fortify.com.  
6. To specify a proxy for Fortify security content updates, do the following:  
a.  
Type 2to select Proxy Server, and then type the name of the proxy server.  
Exclude the protocol and port number (for example, some.secureproxy.com).  
b.  
c.  
Type 3to select Proxy Server Port, and then type the proxy server port number.  
(Optional) You can also specify a proxy server user name (option 4) and password (option 5).  
Page 59 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 3: Installing OpenText SAST  
Configuring the connection to Fortify Software Security Center  
Specify how to connect to Fortify Software Security Center. If your network uses a proxy server to  
reach the Fortify Software Security Center server, you must specify the proxy information.  
To specify settings for connecting to Fortify Software Security Center:  
1.  
2.  
3.  
4.  
5.  
Go to <sast_install_dir>/bin/.  
At the command prompt, type scapostinstall.  
Type 2to select Settings.  
Type 3to select Software Security Center Settings.  
Type 1to select Server URL, and then type the Fortify Software Security Center server URL.  
6. To specify proxy settings for the connection, do the following:  
a.  
Type 2to select Proxy Server, and then type the name of the proxy server.  
Exclude the protocol and port number (for example, some.secureproxy.com).  
b.  
c.  
Type 3to select Proxy Server Port, and then type the proxy server port number.  
To specify a proxy server user name and password, use option 4for the username and  
option 5for the password.  
7.  
(Optional) You can also specify the following:  
l
Whether to update Fortify Software Security Content from your Fortify Software Security  
Center server (option 6)  
l
The Fortify Software Security Center user name (option 7)  
Removing proxy server settings  
If you previously specified proxy server settings for the Fortify Rulepack update server or Fortify  
Software Security Center and it is no longer required, you can remove these settings.  
To remove the proxy settings for obtaining Fortify Software Security Content updates or connecting  
to Fortify Software Security Center:  
1.  
2.  
3.  
4.  
Go to <sast_install_dir>/bin/.  
At the command prompt, type scapostinstall.  
Type 2to select Settings.  
Type 2to select Fortify Updateor type 3to select Software Security Center Settings.  
5. Type the number that corresponds to the proxy setting you want to remove, and then type a  
minus sign (-) to remove the setting.  
6. Repeat step 5 for each proxy setting you want to remove.  
Page 60 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 3: Installing OpenText SAST  
Adding trusted certificates  
Connection from OpenText SAST to other OpenText Application Security Software products and  
external systems might require communication over HTTPS. Some examples include:  
l
OpenText SAST by default requires an HTTPS connection to communicate with the LIM server for  
license management.  
The property com.fortify.sca.lim.RequireTrustedSSLCertdetermines whether the  
connection with the LIM server requires a trusted SSL certificate. For more information about this  
property, see "LIM license properties" on page 210.  
l
The fortifyupdate command-line tool uses an HTTPS connection either automatically during a  
Windows system installation or manually (see "Manually installing Fortify Software Security  
Content" on page 53) to update Fortify security content.  
l
OpenText SAST configured as a Fortify ScanCentral SAST sensor uses an HTTPS connection to  
communicate with the Controller.  
When using HTTPS, OpenText SAST and its applications will by default apply standard checks to the  
presented SSL server certificate, including a check to determine if the certificate is trusted. If your  
organization runs its own certificate authority (CA) and OpenText SAST needs to trust connections  
where the server presents a certificate issued by this CA, you must configure OpenText SAST to trust  
the CA. Otherwise, the use of HTTPS connections might fail.  
You must add the trusted certificate of the CA to the OpenText SAST keystore. The OpenText SAST  
keystore is in the <sast_install_dir>/jre/lib/security/cacertsfile. You can use the  
keytool command to add the trusted certificate to the keystore.  
To add a trusted certificate to the OpenText SAST keystore:  
1. Open a command prompt, and then run the following command:  
<sast_install_dir>/jre/bin/keytool -importcert -alias <alias_name> -  
cacerts -file <cert_file>  
where:  
l
<alias_name> is a unique name for the certificate you are adding.  
l
<cert_file> is the name of the file that contains the trusted root certificate in PEM or  
DER format.  
2. Enter the keystore password.  
Note: The default password is changeit.  
3. When prompted to trust this certificate, select yes.  
Page 61 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
Chapter 4: Analysis process overview  
This section contains the following topics:  
Analysis process  
62  
63  
64  
66  
Translation phase  
Analysis phase  
Translation and analysis phase verification  
Analysis process  
There are four distinct phases that make up the analysis process:  
1. Build Integration—Choose whether to integrate OpenText SAST into your build tool. For  
descriptions of build integration options, see "Integrating the analysis into a build" on page 139.  
2. Translation—Gathers source code using a series of commands and translates it into an  
intermediate format associated with a build ID. The build ID is usually the name of the project you  
are translating. For more information, see "Translation phase" on the next page.  
3. Analysis—Scans source files identified in the translation phase and generates an analysis result  
file (typically in the Fortify Project Results (FPR) format). FPR files have the .fprextension. For  
more information, see "Analysis phase" on page 64.  
4. Verification of translation and analysis—Verifies that the source files were scanned using the  
correct Rulepacks and that no errors were reported. For more information, see "Translation and  
analysis phase verification" on page 66.  
OpenText recommends that you perform translation and analysis commands from a user account with  
least privilege access. OpenText does not recommend that you run OpenText SAST as a root user or  
translate a project that requires root access, because it might not work properly.  
The following is the fundamental sequence of commands to translate and analyze code:  
1. Remove all existing OpenText SAST temporary files for the specified build ID.  
sourceanalyzer -b MyProject -clean  
Always begin an analysis with this step to analyze a project with a previously used build ID.  
2. Translate the project code.  
sourceanalyzer -b MyProject <files_to_analyze>  
For most languages, this step can consist of multiple calls to sourceanalyzer with the same build  
ID. For more details, see "Translation phase" on the next page.  
Page 62 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 4: Analysis process overview  
3. Analyze the project code and save the results in a Fortify Project Results(FPR) file.  
sourceanalyzer -b MyProject -scan -f MyResults.fpr  
For more information, see "Analysis phase" on the next page.  
Translation phase  
To successfully translate a project that is normally compiled, make sure that you have any  
dependencies required to build the project available. For languages that have any specific  
requirements, see the chapters for the specific source code type.  
The basic command-line syntax to perform the first step of the analysis process, file translation, is:  
sourceanalyzer -b <build_id> ... <files>  
or  
sourceanalyzer -b <build_id> ... <compiler_command>  
The translation phase consists of one or more invocations of OpenText SAST using the  
sourceanalyzercommand. OpenText SAST uses a build ID (-boption) to tie the invocations  
together. Subsequent invocations of sourceanalyzeradd any newly specified source or  
configuration files to the file list associated with the build ID.  
After translation, you can use the -show-build-warningsdirective to list any warnings and errors  
that occurred in the translation phase:  
sourceanalyzer -b <build_id> -show-build-warnings  
To view the files associated with a build ID, use the -show-filesdirective:  
sourceanalyzer -b <build_id> -show-files  
Special considerations for the translation phase  
Consider the following special considerations before you perform the translation phase on your  
project:  
l
When you translate dynamic languages (JavaScript/TypeScript, PHP, Python, and Ruby), you must  
specify all source files together in one invocation. OpenText SAST does not support adding new  
files to the file list associated with the build ID on subsequent invocations.  
l
Generated code is automatically generated by a script or a tool such as a parsing tool. This code  
can be optimized, minimized, or large and complex. Therefore, OpenText recommends that you  
exclude it from translation because it would be challenging to fix any vulnerabilities OpenText  
Page 63 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 4: Analysis process overview  
SAST might report in this code. Use the -excludecommand-line option to exclude this type of  
code from translation.  
l
To translate the project on a build machine, and then run the scan on a better performance system,  
see "Using mobile build sessions" on page 198.  
Analysis phase  
The analysis phase scans the intermediate files created during translation and creates the  
vulnerability results file (FPR).  
This phase consists of one invocation of sourceanalyzer. You specify the build ID and include the -  
scandirective with any other required analysis or output options (see "Analysis options" on page 153  
and "Output options" on page 156).  
The following example shows the command-line syntax to perform the analysis phase and save the  
results in an FPR file:  
sourceanalyzer -b MyProject -scan -f MyResults.fpr  
Note: By default, OpenText SAST includes the source code in the FPR file.  
To combine multiple builds into a single scan command, add the additional builds to the command  
line:  
sourceanalyzer -b MyProject1 -b MyProject2 -b MyProject3 -scan -f  
MyResults.fpr  
Applying a scan policy to the analysis  
For the analysis (scan) phase, you can specify a scan policy to help you identify the most serious  
vulnerabilities so you can remediate the code quickly. The following table describes the three  
provided scan policies.  
Policy  
name  
Description  
security  
This is the default scan policy, which excludes issues related to code quality, dataflow  
from sources that are typically trusted, and issues that are typically noisy from the  
analysis results. Use this policy to focus code remediation on the security issues.  
devops  
This scan policy expands on the security policy, by excluding additional issues that  
might be considered noise, and reducing more low priority issues. Use this scan policy  
when scan speed is a priority, and developers review results directly (without any  
intermediate auditing). Issues that remain after you apply this scan policy are probably  
Page 64 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 4: Analysis process overview  
Policy  
name  
Description  
serious security issues that require remediation.  
Note: This devops scan policy does not automatically include any customization  
made to the local security scan policy.  
classic  
This scan policy does not exclude any issues. Use this scan policy to see all issues, or if  
you prefer to filter issues with project templates so it is easier to see hidden issues.  
To specify a scan policy for your analysis, include the -scan-policy(or -sc) option in the analysis  
phase as shown in the following example:  
sourceanalyzer -b MyProject -scan -scan-policy devops -f MyResults.fpr  
Alternatively, you can specify the scan policy with the com.fortify.sca.ScanPolicyproperty in  
the fortify-sca.propertiesfile. For example:  
com.fortify.sca.ScanPolicy=devops  
Note: You can apply a filter file (see "Excluding issues with filter files" on page 192) in addition to  
a scan policy setting for an analysis. In this case, OpenText SAST applies both the scan policy and  
the filter file to the analysis.  
Creating custom scan policies  
The scan policy files reside in the <sast_install_dir>/Core/config/scalesdirectory. There is  
one file for each scan policy. You can change the settings in these policy files to customize your scan  
policies or you can create your own scan policy files. For information about the syntax used for the  
scan policy files, see "Excluding issues with filter files" on page 192.  
To create a custom scan policy file:  
1.  
2.  
Go to <sast_install_dir>/Core/config/scales/.  
Open a text editor and create a file named scan-policy-<name>.txt, where <name> is the  
name for your custom scan policy.  
3.  
Add filters to the scan-policy-<name>.txtfile and save it.  
4. To use the custom scan policy for your analysis, type the command as shown in the following  
example. In this example, the scan policy file name is scan-policy-myscanpolicy.txt.  
sourceanalyzer -b MyProject -scan -scan-policy myscanpolicy -f  
MyResults.fpr  
Alternatively, you can specify the custom scan policy in the fortify-sca.propertiesfile.  
Page 65 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 4: Analysis process overview  
See also  
"Translation and analysis phase properties" on page 202  
Regular expression analysis  
Regular expression (regex) analysis provides the ability for using regular expression rules to detect  
vulnerabilities in both file content and file names. This analysis can detect vulnerable secrets such as  
passwords, keys, and credentials in project files.  
Important! Regex analysis is language agnostic and therefore it might detect vulnerabilities in  
file types that OpenText SAST does not officially support.  
Regex analysis recursively examines all file paths and path patterns included in the translation phase.  
Every file found is analyzed unless it is specifically excluded. To manage the files that are included in  
regex analysis, the following options are available:  
l
Exclude any file or directory with the -excludeoption in the translation phase.  
For more information about this option, see "Translation options" on page 151.  
l
By default, regex analysis excludes all detectible binary files. To include binary files in the analysis,  
add the following property to the fortify-sca.propertiesfile (or include this property on the  
command line using the -Doption):  
com.fortify.sca.regex.ExcludeBinaries = false  
l
By default, regex analysis excludes files larger than 10 MB to ensure that the scan time is  
acceptable. You can change the maximum file size (in megabytes) with the following property:  
com.fortify.sca.regex.MaxSize = <max_file_size_mb>  
Regex analysis is enabled by default. To disable regex analysis, add the following property to the  
fortify-sca.propertiesfile or include it on the command line:  
com.fortify.sca.regex.Enable = false  
See also  
"Regex analysis properties " on page 209  
Translation and analysis phase verification  
Fortify Audit Workbench certification indicates whether the code analysis from a scan is complete and  
valid. The project summary in Fortify Audit Workbench shows the following specific information about  
OpenText SAST scanned code:  
l
List of files scanned, with file sizes and timestamps  
l
Java class path used for the translation (if applicable)  
Page 66 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 4: Analysis process overview  
l
Rulepacks used for the analysis  
l
OpenText SAST runtime settings and command-line options  
l
Any errors or warnings encountered during translation or analysis  
l
Machine and platform information  
Note: To obtain result certification, you must specify FPR for the analysis phase output format.  
To view result certification information, open the FPR file in Fortify Audit Workbench and select Tools  
> Project Summary > Certification. For more information, see the OpenText™ Fortify Audit  
Workbench User Guide.  
Page 67 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
Chapter 5: Translating Java code  
This section describes how to translate Java code.  
OpenText SAST supports analysis of Jakarta EE (Java EE) applications (including JSP files,  
configuration files, and deployment descriptors), Java Bytecode, and Java code with Lombok  
annotations.  
This section contains the following topics:  
Java translation command-line syntax  
Handling Java warnings  
68  
72  
73  
74  
75  
Translating Jakarta EE (Java EE) applications  
Translating Java bytecode  
Troubleshooting JSP translation and analysis issues  
Java translation command-line syntax  
To translate Java code, all types defined in a library that are referenced in the code must have a  
corresponding definition in the source code, a class file, or a JAR file. Include all source files on the  
OpenText SAST command line.  
If your project contains Java code that refers to Kotlin code, make sure that the Java and Kotlin code  
are translated in the same OpenText SAST instance so that the Java references to Kotlin elements are  
resolved correctly. Kotlin to Java interoperability does not support Kotlin files provided by the –  
sourcepathoption. For more information about the –sourcepathoption, see "Java command-line  
options" on the next page  
The basic command-line syntax to translate Java code is shown in the following example:  
sourceanalyzer -b <build_id> -cp <classpath> <files>  
With Java code, OpenText SAST can either:  
l
Emulate the compiler, which might be convenient for build integration  
l
Accept source files directly, which is convenient for command-line scans  
For information about how to integrate OpenText SAST with Ant, see "Integrating with Ant" on  
page 147.  
To have OpenText SAST emulate the compiler, type:  
sourceanalyzer -b <build_id> javac [<translation_options>]  
Page 68 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 5: Translating Java code  
To pass files directly to OpenText SAST, type:  
sourceanalyzer -b <build_id> -cp <classpath> [<translation_options>]  
<files> | <file_specifiers>  
where:  
l
<translation_options> are options passed to the compiler.  
l
-cp <classpath> specifies the class path to use for the Java source code.  
Include all JAR dependencies normally used to build the project. Separate multiple paths with  
semicolons (Windows) or colons (non-Windows).  
Similar to javac, OpenText SAST loads classes in the order they appear in the class path. If there  
are multiple classes with the same name in the list, OpenText SAST uses the first loaded class. In  
the following example, if both A.jarand B.jarinclude a class called MyData.class, OpenText  
SAST uses the MyData.classfrom A.jar.  
sourceanalyzer -cp A.jar:B.jar myfile.java  
OpenText strongly recommends that you avoid using duplicate classes with the -cpoption.  
OpenText SAST loads JAR files in the following order:  
a.  
b.  
c.  
From the -cpoption  
From jre/lib  
From <sast_install_dir>/Core/default_jars  
This enables you to override a library class by including the similarly-named class in a  
JAR specified with the -cpoption.  
For descriptions of all the available Java-specific command-line options, see "Java command-line  
options" below.  
Java command-line options  
The following table describes the Java command-line options (for Java SE and Jakarta EE).  
Java or Jakarta EE option  
Description  
Specifies the application server to process JSP files.  
-appserver  
weblogic| websphere  
Equivalent property name:  
com.fortify.sca.AppServer  
Specifies the application server’s home.  
-appserver-home <dir>  
l
For Oracle® WebLogic®, this is the path to the directory  
that contains the server/libdirectory.  
l
For IBM® WebSphere®, this is the path to the directory  
Page 69 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 5: Translating Java code  
Java or Jakarta EE option  
Description  
that contains the JspBatchCompilerscript.  
Equivalent property name:  
com.fortify.sca.AppServerHome  
Specifies the version of the application server.  
-appserver-version  
<version>  
Equivalent property name:  
com.fortify.sca.AppServerVersion  
Specifies the class path used to analyze Java source code.  
The format is the same as javac: a semicolon- or colon-  
separated list of directories. You can use OpenText SAST  
file specifiers as shown in the following example:  
-cp <paths> |  
-classpath <paths>  
-cp "build/classes:lib/*.jar"  
For information about file specifiers, see "Specifying files  
and directories" on page 163.  
Equivalent property name:  
com.fortify.sca.JavaClasspath  
-extdirs <dirs>  
Similar to the javac extdirsoption, accepts a semicolon- or  
colon-separated list of directories. Any JAR files found in  
these directories are included implicitly on the class path.  
Equivalent property name:  
com.fortify.sca.JavaExtdirs  
Specifies one or more directories that contain compiled Java  
sources.  
-java-build-dir <dirs>  
Indicates the Java™ Development Kit (JDK) version for  
which the Java code is written. For supported versions, see  
-source <version> |  
-jdk <version>  
"Supported languages" on page 33. The default is version  
11.  
Equivalent property name:  
com.fortify.sca.JdkVersion  
Specifies a directory that contains a JDK. Use this option to  
specify a version that is not included in the OpenText SAST  
-custom-jdk-dir  
installation (<sast_install_dir>/Core/bootcp/). For  
Page 70 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 5: Translating Java code  
Java or Jakarta EE option  
Description  
supported versions, see "Supported languages" on page 33.  
Equivalent property name:  
com.fortify.sca.CustomJdkDir  
Displays any unresolved types, fields, and functions  
referenced in translated Java source files at the end of the  
translation. It lists only field and function references for  
which the receiver type is a resolved Java type. Displays  
each class, field, and function with the source information of  
the first translated occurrence in the code. This information  
is also written in the log file.  
-show-unresolved-symbols  
Equivalent property name:  
com.fortify.sca.ShowUnresolvedSymbols  
Specifies a semicolon- or colon-separated list of directories  
that contain source code that is not included in the scan but  
is used for name resolution. The source path is similar to  
class path, except it uses source files instead of class files for  
resolution. Only source files that are referenced by the  
target file list are translated.  
-sourcepath <dirs>  
Equivalent property name:  
com.fortify.sca.JavaSourcePath  
See also  
"Java and Kotlin properties" on page 213  
Java command-line examples  
To translate a single file named MyServlet.javawith javaee.jaras the class path, type:  
sourceanalyzer -b MyServlet -cp lib/javaee.jar MyServlet.java  
To translate all .javafiles in the srcdirectory using all JAR files in the libdirectory as a class path,  
type:  
sourceanalyzer -b MyProject -cp "lib/*.jar" "src/**/*.java"  
To translate and compile the MyCode.javafile with the javac compiler, type:  
sourceanalyzer -b MyProject javac -classpath libs.jar MyCode.java  
Page 71 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 5: Translating Java code  
Handling Java warnings  
To see all warnings that were generated during translation, type the following command before you  
start the scan phase:  
sourceanalyzer -b <build_id> -show-build-warnings  
Java translation warnings  
You might see the following warnings in the Java code translation.  
Warning  
Resolution  
These warnings are typically caused by  
missing resources. For example, some of  
Unable to resolve type...  
Unable to resolve function...  
Unable to resolve field...  
Unable to locate import...  
Unable to resolve symbol...  
the .jarand .classfiles required to  
build the application might not have been  
specified.  
To resolve these warnings, make sure that  
you include all the required files that your  
application uses.  
This warning is typically caused by  
duplicate classes in the Java files.  
Multiple definitions found for class...  
To resolve these warnings, make sure that  
the source files displayed in the warning  
are not duplicates of the same file  
included several times in the sources to  
translate (for example if it contains two  
versions of the same project). If a  
duplicate exists, remove one of them from  
the files to translate. Then OpenText  
SAST can determine which version of the  
class to use.  
This warning can also indicate that classes  
are missing. To resolve this, make sure to  
add all required JAR files to the classpath.  
Page 72 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 5: Translating Java code  
Translating Jakarta EE (Java EE) applications  
To translate Jakarta EE applications, OpenText SAST processes Java source files and  
Jakarta EE components such as JSP files, deployment descriptors, and configuration files. While you  
can process all the pertinent files in a Jakarta EE application in one step, your project might require  
that you break the procedure into its components for integration in a build process or to meet the  
needs of various stakeholders in your organization.  
Translating Java files  
To translate Jakarta EE applications, use the same procedure used to translate Java files. For  
examples, see "Java command-line examples" on page 71.  
Translating JSP projects, configuration files, and deployment  
descriptors  
In addition to translating the Java files in your Jakarta EE (Java EE) application, you might also need  
to translate JSP files, configuration files, and deployment descriptors. Your JSP files must be part of a  
Web Application Archive (WAR). If your source directory is already organized in a WAR file format,  
you can translate the JSP files directly from the source directory. If not, you might need to deploy  
your application and translate the JSP files from the deployment directory.  
For example:  
sourceanalyzer -b MyJavaApp "/**/*.jsp" "/**/*.xml"  
where /**/*.jsprefers to the location of your JSP project files and /**/*.xmlrefers to the location  
of your configuration and deployment descriptor files.  
Jakarta EE (Java EE) translation warnings  
You might see the following warning in the translation of Jakarta EE applications:  
Could not locate the root (WEB-INF) of the web application. Please build  
your web application and try again. Failed to parse the following jsp  
files:  
<list_of_jsp_files>  
This warning indicates that your web application is not deployed in the standard WAR directory  
format or does not contain the full set of required libraries. To resolve the warning, make sure that  
your web application is in an exploded WAR directory format with the correct WEB-INF/liband  
WEB-INF/classesdirectories that contain all the .jarand .classfiles required for your  
Page 73 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 5: Translating Java code  
application. Also verify that you have all the TLDfiles for all your tags and the corresponding JAR files  
with their tag implementations.  
Translating Java bytecode  
OpenText recommends that you do not translate Java bytecode and JSP/Java code in the same call  
to sourceanalyzer. Use multiple invocations of sourceanalyzerwith the same build ID to  
translate a project that contains both bytecode and JSP/Java code.  
To translate bytecode:  
1.  
Add the following properties to the fortify-sca.propertiesfile (or include these properties  
on the command line using the -Doption):  
com.fortify.sca.fileextensions.class=BYTECODE  
com.fortify.sca.fileextensions.jar=ARCHIVE  
This specifies how OpenText SAST processes .classand .jarfiles.  
2. Do one of the following:  
l
Request that OpenText SAST decompile the bytecode classes to regular Java files for  
inclusion in the translation.  
Add the following property to the fortify-sca.propertiesfile:  
com.fortify.sca.DecompileBytecode=true  
or include this property on the command line for the translation phase with the -Doption:  
sourceanalyzer -b MyProject -Dcom.fortify.sca.DecompileBytecode=true  
-cp "lib/*.jar" "src/**/*.class"  
l
Request that OpenText SAST translate bytecode without decompilation.  
For best results, OpenText recommends that the bytecode be compiled with full debug  
information (javac -g).  
Include bytecode in the translation phase by specifying the Java bytecode files that you want  
to translate. For best performance, specify only the .jaror .classfiles that require  
scanning. In the following example, the .classfiles are translated:  
sourceanalyzer -b MyProject -cp "lib/*.jar" "src/**/*.class"  
Page 74 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 5: Translating Java code  
Troubleshooting JSP translation and analysis issues  
The following sections provide troubleshooting information for JSP analysis.  
Unable to translate some JSPs  
OpenText SAST uses either the built-in compiler or your specific application server JSP compiler to  
translate JSP files into Java files for analysis. If the JSP parser encounters problems when OpenText  
SAST converts JSP files to Java files, you will see a message similar to the following:  
Failed to translate the following jsps into analysis model. Please see the  
log file for any errors from the jsp parser and the user manual for hints  
on fixing those  
<list_of_jsp_files>  
This typically happens for one or more of the following reasons:  
l
The web application is not laid out in a proper deployable WAR directory format  
l
Some JAR files or classes required for the application are missing  
l
Some tag libraries or their definitions (TLD) for the application are missing  
To obtain more information about the problem, perform the following steps:  
1. Open the OpenText SAST log file in an editor.  
2. Search for the following strings:  
l
Jsp parser stdout:  
l
Jsp parser stderr:  
The JSP parser generates these errors. Resolve the errors and rerun OpenText SAST.  
For more information about how to analyze Jakarta EE applications, see "Translating Jakarta EE (Java  
EE) applications" on page 73.  
Increased issues count in JSP-related categories  
If the analysis results contain a considerable increase in the number of vulnerabilities in JSP-related  
categories such as cross-site scripting compared with earlier OpenText SAST versions, you can  
specify the -legacy-jsp-dataflowoption in the analysis phase (with the -scanoption). This  
option enables additional filtering on JSP-related dataflow to reduce the number of spurious false  
positives detected.  
The equivalent property for this option that you can specify in the fortify-sca.propertiesfile is  
com.fortify.sca.jsp.LegacyDataflow.  
Page 75 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
Chapter 6: Translating Kotlin code  
This section describes how to translate Kotlin code.  
This section contains the following topics:  
Kotlin command-line syntax  
76  
78  
79  
Kotlin and Java translation interoperability  
Translating Kotlin scripts  
Kotlin command-line syntax  
The translation of Kotlin code is similar to the translation of Java code. To translate Kotlin code, all  
types defined in a library that are referenced in the code must have a corresponding definition in the  
source code, a class file, or a JAR file. Include all source files on the OpenText SAST command line.  
The basic command-line syntax to translate Kotlin code is shown in the following example:  
sourceanalyzer –b <build_id> -cp <classpath> [<translation_options>]  
<files>  
where  
l
-cp <classpath> specifies the class path to use for the Kotlin source code.  
Include all JAR dependencies normally used to build the project. Separate multiple paths with  
semicolons (Windows) or colons (non-Windows).  
OpenText SAST loads classes in the order they appear in the class path. If there are multiple  
classes with the same name in the list, OpenText SAST uses the first loaded class. In the following  
example, if both A.jarand B.jarinclude a class called MyData.class, OpenText SAST uses the  
MyData.classfrom A.jar.  
sourceanalyzer –cp "A.jar:B.jar" myfile.kt  
OpenText strongly recommends that you avoid using duplicate classes with the -cpoption.  
For descriptions of all the available Kotlin-specific command-line options, see "Kotlin command-line  
options" on the next page.  
Page 76 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 6: Translating Kotlin code  
Kotlin command-line options  
The following table describes the Kotlin-specific command-line options.  
Kotlin option  
Description  
Specifies the class path used to analyze Kotlin source code,  
which is a semicolon- or colon-separated list of directories.  
You can use OpenText SAST file specifiers as shown in the  
following example:  
-cp <paths> |  
-classpath <paths>  
-cp "build/classes:lib/*.jar"  
For information about file specifiers, see "Specifying files  
and directories" on page 163.  
Equivalent property name:  
com.fortify.sca.JavaClasspath  
Indicates the JDK version for which the Kotlin code is  
written. For supported versions, see "Supported languages"  
-source <version> |  
-jdk <version>  
on page 33. The default is version 11.  
Equivalent property name:  
com.fortify.sca.JdkVersion  
Specifies a semicolon- or colon-separated list of directories  
that contain Java source code that is not included in the  
scan but is used for name resolution. The source path is  
similar to class path, except it uses source files instead of  
class files for resolution. Only source files that are  
referenced by the target file list are translated.  
-sourcepath <dirs>  
Equivalent property name:  
com.fortify.sca.JavaSourcePath  
-jvm-default <mode>  
Specifies the generation of the DefaultImplsclass for  
methods with bodies in Kotlin interfaces. The valid values  
for <mode> are:  
l
disable—Specifies to generate the DefaultImplsclass  
for each interface that contains methods with bodies.  
l
all—Specifies to generate the DefaultImplsclass if an  
interface is annotated with  
Page 77 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 6: Translating Kotlin code  
Kotlin option  
Description  
@JvmDefaultWithCompatibility.  
l
all-compatibility—Specifies to generate the  
DefaultImplsclass unless an interface is annotated  
with @JvmDefaultWithoutCompatibility.  
Equivalent property name:  
com.fortify.sca.KotlinJvmDefault  
See also  
"Java and Kotlin properties" on page 213  
Kotlin command-line examples  
To translate a single file named MyKotlin.ktwith A.jaras the class path, type:  
sourceanalyzer -b MyProject -cp lib/A.jar MyKotlin.kt  
To translate all .ktfiles in the srcdirectory using all JAR files in the libdirectory as a class path,  
type:  
sourceanalyzer -b MyProject -cp "lib/**/*.jar" "src/**/*.kt"  
To translate a gradle project using gradlew, type:  
sourceanalyzer -b MyProject gradlew clean assemble  
To translate all files in the srcdirectory using Java dependencies from src/javaand all JAR files in  
the libdirectory and subdirectories as a class path, type:  
sourceanalyzer –b MyProject –cp "lib/**/*.jar" -sourcepath "src/java" "src"  
Kotlin and Java translation interoperability  
If your project contains Kotlin code that refers to Java code, you can provide Java files to the  
translator the same way as Kotlin files that refers to another Kotlin file. You can provide them as part  
of the translated project source or as –sourcepathparameters.  
If your project contains Java code that refers to Kotlin code, make sure that the Java and Kotlin code  
are translated in the same OpenText SAST instance so that the Java references to Kotlin elements are  
resolved correctly. Kotlin to Java interoperability does not support Kotlin files provided by the –  
sourcepathoption. For more information about the –sourcepathoption, see "Kotlin command-line  
options" on the previous page  
Page 78 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 6: Translating Kotlin code  
Translating Kotlin scripts  
OpenText SAST supports translation of Kotlin scripts excluding experimental script customization.  
Script customization includes adding external properties, providing static or dynamic dependencies,  
and so on. Script definitions (templates) are used to create custom scripts and the template is applied  
to the script based on the *.ktsextension. OpenText SAST translates *.ktsfiles but does not apply  
these templates.  
Page 79 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
Chapter 7: Translating Visual Studio projects  
OpenText SAST provides a build integration to support translation of the following Visual Studio  
project types:  
l
C/C++ projects  
l
C# projects that target .NET Framework and .NET Core  
l
ASP.NET applications that target ASP.NET framework and ASP.NET Core  
l
Xamarin applications that target Android™ and iOS platforms  
For a list of supported versions of relevant programming languages and frameworks, as well as Visual  
Studio and MSBuild versions, see "Supported languages" on page 33 and "Supported build tools" on  
page 41.  
This section contains the following topics:  
Visual Studio project translation prerequisites  
Visual Studio Project command-line syntax  
80  
80  
82  
84  
Handling special cases for translating Visual Studio projects  
Alternative ways to translate Visual Studio projects  
Visual Studio project translation prerequisites  
OpenText recommends that each project you translate is complete and that you perform the  
translation in an environment where you can build it without errors. For a list of software environment  
requirements, see "Software requirements" on page 32. A complete project contains the following:  
l
All necessary source code files (C/C++, C#, or VB.NET).  
l
All required reference libraries.  
This includes those from relevant frameworks, NuGet packages, and third-party libraries.  
l
For C/C++ projects, include all necessary header files that do not belong to the Visual Studio or  
MSBuild installation.  
l
For ASP.NET and ASP.NET Core projects, include all the necessary ASP.NET page files.  
The supported ASP.NET page types are ASAX, ASCX, ASHX, ASMX, ASPX, AXML, BAML, CSHTML,  
Master, RAZOR, VBHTML, and XAML.  
Visual Studio Project command-line syntax  
The basic syntax to translate a Visual Studio solution or project is to specify the corresponding build  
option for your project as part of the OpenText SAST translation command. This starts a build  
Page 80 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 7: Translating Visual Studio projects  
integration that analyzes your solution and project files and automatically executes the appropriate  
translation steps.  
Important! To ensure that the build integration correctly pulls in all of the appropriate project  
dependencies and resources, you must run the OpenText SAST command from a command  
prompt with access to your build environment configuration. OpenText strongly recommends  
you run this command from the Developer Command Prompt for Visual Studio to ensure an  
optimal environment for the translation.  
In the following examples, OpenText SAST translates all the projects contained in the Visual Studio  
solution Sample.sln. You can also translate one or more specific projects by providing a semicolon-  
separated list of projects.  
By default, test projects are excluded from the translation. Projects in your solution that reference  
NUnit, xunit, or MSTest are considered a test project. To include test projects in the translation, add  
the MSBuild option /p:ScaForceTranslateTestProjects=Trueto your sourceanalyzer  
command.  
l
For a .NET 6.0 or later solution on Windows or Linux, use the following commands to translate the  
solution:  
a. Optionally, run the following command to remove any intermediate files from previous project  
builds:  
dotnet clean Sample.sln  
b. Optionally, run the following command to ensure that all required reference libraries are  
downloaded and installed in the project. Run this command from the top-level folder of the  
project:  
dotnet restore Sample.sln  
c. Run one of the following OpenText SAST commands depending on how your project build is  
implemented. You can include any additional build parameters in this command:  
sourceanalyzer –b MyProject dotnet msbuild Sample.sln  
or  
sourceanalyzer –b MyProject dotnet build Sample.sln  
l
For a C, C++, and .NET Framework solution (4.8.x or earlier) on Windows, use the following  
command to translate the solution:  
sourceanalyzer –b MyProject msbuild /t:rebuild [<msbuild_options>]  
Sample.sln  
Page 81 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 7: Translating Visual Studio projects  
Note: If you run OpenText SAST from a Windows Command Prompt instead of the Visual  
Studio Developer Command Prompt, you must set up the environment and make sure the path  
to the MSBuild executable required to build your project is included in the PATH environment  
variable.  
After the translation is complete, perform the analysis phase and save the results in an FPR file as  
shown in the following example:  
sourceanalyzer –b MyProject -scan -f MyResults.fpr  
Handling special cases for translating Visual Studio  
projects  
Running translation from a script  
To perform the translation in a non-interactive mode such as with a script, establish an optimal  
environment for translation by executing the following command before you run the OpenText SAST  
translation:  
cmd.exe /k <vs_install_dir>/Common7/Tools/VSDevCmd.bat  
where <vs_install_dir> is the directory where you installed Visual Studio.  
Translating plain .NET and ASP.NET projects  
You can translate plain .NET and ASP.NET projects from the Windows Command Prompt as well as  
from a Visual Studio environment. When you translate from the Windows Command Prompt, make  
sure the path to the MSBuild executable required to build your project is included in the PATH  
environment variable.  
Translating C/C++ and Xamarin projects  
You must translate C/C++ and Xamarin projects either from a Developer Command Prompt for Visual  
Studio or from the Fortify Extension for Visual Studio.  
Note: For Xamarin projects, there is no need to use a custom rule for the Xamarin.Android API if a  
rule for the corresponding native Android API exists in the Fortify Secure Coding Rulepacks.  
Doing so can cause duplicate issues to be reported.  
Page 82 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 7: Translating Visual Studio projects  
Translating projects with settings containing spaces  
If your project is built with a configuration or other settings file that contains spaces, make sure to  
enclose the setting values in quotes. For example, to translate a Visual Studio solution Sample.sln  
that is built with configuration My Configuration, use the following command:  
sourceanalyzer –b MySampleProj msbuild /t:rebuild  
/p:Configuration="My Configuration" Sample.sln  
Translating a single project from a Visual Studio solution  
If your Visual Studio solution contains multiple projects, you have the option to translate a single  
project instead of the entire solution. Project files have a file name extension that ends with proj  
such as .vcxprojand .csproj. To translate a single project, specify the project file instead of the  
solution as the parameter for the MSBuild command.  
The following example translates the Sample.vcxprojproject file:  
sourceanalyzer –b MySampleProj msbuild /t:rebuild Sample.vcxproj  
Analyzing projects that build multiple executable files  
If your Visual Studio or MSBuild project builds multiple executable files (such as files with the file  
name extension *.exe), OpenText strongly recommends that you run the analysis phase separately  
for each executable file to avoid false positive issues in the analysis results. To do this, use the –  
binary-nameoption when you run the analysis phase and specify the executable file name or .NET  
assembly name as the parameter.  
The following example shows how to translate and analyze a Visual Studio solution Sample.slnthat  
consists of two projects, Sample1 (a C++ project with no associated .NET assembly name) and  
Sample2 (a .NET project with .NET assembly name Sample2). Each project builds a separate  
executable file, Sample1.exeand Sample2.exe, respectively. The analysis results are saved in  
Sample1.fprand Sample2.fprfiles.  
sourceanalyzer -b MySampleProj msbuild /t:rebuild Sample.sln  
sourceanalyzer -b MySampleProj -scan -binary-name Sample1.exe -f  
Sample1.fpr  
sourceanalyzer -b MySampleProj -scan -binary-name Sample2.exe -f  
Sample2.fpr  
For more information about the -binary-nameoption, see "Analysis options" on page 153.  
Page 83 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 7: Translating Visual Studio projects  
Alternative ways to translate Visual Studio projects  
This section describes alternative methods of translating Visual Studio projects.  
Alternative translation options for Visual Studio solutions  
The following are two alternative ways of translation available only for Visual Studio solutions:  
l
Use the Fortify Extension for Visual Studio  
The Fortify Extension for Visual Studio runs the translation and analysis (scan) phases together in  
one step.  
l
Append a devenv command to the OpenText SAST command  
The following command translates the Visual Studio solution Sample.sln:  
sourceanalyzer –b MySampleProj devenv Sample.sln /rebuild  
Note that OpenText SAST converts a devenv invocation to the equivalent MSBuild invocation,  
therefore in this case, the solution with this command is built by MSBuild instead of the devenv  
tool.  
Translating without explicitly running OpenText SAST  
You have the option to translate your Visual Studio project without invoking OpenText SAST directly.  
This requires the Fortify.targetsfile, which is located in <sast_install_dir>\Core\private-  
bin\sca\MSBuildPluginin the DotNetand Frameworkdirectory. You can specify the file using an  
absolute or relative path in the build command line that builds your project. Use the path with the  
Dotnetor Frameworkdirectory depending on the build command you are using: dotnet.exeor  
MSBuild.exerespectively. For example:  
dotnet.exe msbuild /t:rebuild /p:CustomAfterMicrosoftCommonTargets=<sast_  
install_dir>\Core\private-bin\sca\MSBuildPlugin\Dotnet\Fortify.targets  
Sample.sln  
or  
msbuild.exe /t:rebuild  
/p:CustomAfterMicrosoftCommonTargets=<sast_install_dir>\Core\private-  
bin\sca\MSBuildPlugin\Framework\Fortify.targets Sample.sln  
Page 84 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 7: Translating Visual Studio projects  
There are several environment variables that you can set to configure the translation of your project.  
Most of them have default values, which OpenText SAST uses if the variable is not set. These  
variables are listed in the following table.  
Environment  
variable  
Description  
Default value  
FORTIFY_  
MSBUILD_  
BUILDID  
Specifies the OpenText SAST build ID for  
translation. Make sure that you set this  
value.  
None  
This is equivalent to the OpenText SAST -b  
option.  
FORTIFY_  
MSBUILD_  
DEBUG  
Enables debug mode. This is equivalent to  
False  
False  
the OpenText SAST –debugoption.  
FORTIFY_  
MSBUILD_  
DEBUG_  
Enables verbose debug mode. This is  
equivalent to the OpenText SAST –debug-  
verboseoption. Takes precedence over  
VERBOSE  
FORTIFY_MSBUILD_DEBUG variable if both  
are set to true.  
FORTIFY_  
MSBUILD_MEM  
Specifies the memory requirements for  
Automatic allocation based on  
physical memory available on  
the system  
translation in the form of the JVM -Xmx  
option. For example, -Xmx2G.  
FORTIFY_  
MSBUILD_  
SCALOG  
Specifies the location (absolute path) of the  
OpenText SAST log file.  
%LOCALAPPDATA%/Fortify/  
sca/log/sca.log  
This is equivalent to the OpenText SAST -  
logfileoption.  
Page 85 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
Chapter 8: Translating C and C++ code  
This section describes how to translate C and C++ code. OpenText SAST supports standard ANSI C  
and C++ and might not support all non-standard C++ constructs.  
Important! The chapter describes how to translate C and C++ code that is not a part of a Visual  
Studio or MSBuild project. For instructions on how to translate Visual Studio or MSBuild projects,  
see "Translating Visual Studio projects" on page 80.  
This section contains the following topics:  
86  
86  
87  
87  
C and C++ Code translation prerequisites  
C and C++ command-line syntax  
Scanning pre-processed C and C++ code  
C/C++ Precompiled Header Files  
C and C++ Code translation prerequisites  
Make sure that you have any dependencies required to build the project available, including headers  
for third-party libraries. OpenText SAST translation does not require object files and static/dynamic  
library files.  
If you use Gradle to build your C++ project, make sure that the C++ Application Plugin is added to  
your Gradle file in one of the following formats:  
apply plugin: 'cpp'  
plugins {  
id 'cpp-application'  
}
See also  
"Using Gradle integration" on page 140  
C and C++ command-line syntax  
Command-line options passed to the compiler affect preprocessor execution and can enable or  
disable language features and extensions. For OpenText SAST to interpret your source code in the  
same way as the compiler, the translation phase for C/C++ source code requires the complete  
Page 86 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 8: Translating C and C++ code  
compiler command line. Prefix your original compiler command with the sourceanalyzercommand  
and options.  
The basic command-line syntax for translating a single file is:  
sourceanalyzer -b <build_id> [<sca_options>] <compiler> [<compiler_  
options>] <file>.c  
where:  
l
<sca_options> are options passed to OpenText SAST.  
l
<compiler> is the name of the C/C++ compiler you use, such as gcc, g++, or cl. See "Supported  
languages" on page 33 for a list of supported C/C++ compilers.  
l
<compiler_options> are options passed to the C/C++ compiler.  
l
<file>.cmust be in ASCII or UTF-8 encoding.  
Note: All OpenText SAST options must precede the compiler options.  
The compiler command must successfully complete when executed on its own. If the compiler  
command fails, then the OpenText SAST command prefixed to the compiler command also fails.  
For example, if you compile a file with the following command:  
gcc -I. -o hello.o -c helloworld.c  
then you can translate this file with the following command:  
sourceanalyzer -b MyProject gcc -I. -o hello.o -c helloworld.c  
OpenText SAST executes the original compiler command as part of the translation phase. In the  
previous example, the command produces both the translated source suitable for scanning, and the  
object file hello.ofrom the gccexecution. You can use the OpenText SAST -ncoption to disable  
the compiler execution.  
Scanning pre-processed C and C++ code  
If, before compilation, your C/C++ build executes a third-party C preprocessor that OpenText SAST  
does not support, you must start the OpenText SAST translation on the intermediate file. OpenText  
SAST touchless build integration automatically translates the intermediate file provided that your  
build executes the unsupported preprocessor and supported compiler as two commands connected  
by a temporary file rather than a pipe chain.  
C/C++ Precompiled Header Files  
Some C/C++ compilers support Precompiled Header Files, which can improve compilation  
performance. Some compilers' implementations of this feature have subtle side-effects. When the  
Page 87 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 8: Translating C and C++ code  
feature is enabled, the compiler might accept erroneous source code without warnings or errors. This  
can result in a discrepancy where OpenText SAST reports translation errors even when your compiler  
does not.  
If you use your compiler's Precompiled Header feature, disable Precompiled Headers, and then  
perform a full build to make sure that your source code compiles cleanly.  
Page 88 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
Chapter 9: Translating JavaScript and  
TypeScript code  
You can analyze JavaScript projects that contain JavaScript, TypeScript, JSX, and TSX source files, as  
well as JavaScript embedded in HTML files.  
Some JavaScript frameworks are transpiled (source-to-source compilation) to plain JavaScript, which  
is generated code. Use the -excludecommand-line option to exclude this type of code.  
When you translate JavaScript and TypeScript code, make sure that you specify all source files  
together in one invocation. OpenText SAST does not support adding new files to the file list  
associated with the build ID on subsequent invocations.  
OpenText SAST does not translate minified JavaScript (*.min.js).  
Note: There are some types of minified JavaScript files that OpenText SAST cannot automatically  
detect for exclusion from the translation. Use the -excludecommand-line option to exclude  
these files directly.  
This section contains the following topics:  
Translating pure JavaScript projects  
89  
Excluding dependencies  
90  
90  
93  
93  
Managing issue detection in NPM dependencies  
Translating JavaScript projects with HTML files  
Including external JavaScript or HTML in the translation  
Translating pure JavaScript projects  
The basic command-line syntax to translate JavaScript is:  
sourceanalyzer –b <build_id> <js_file_or_dir>  
where <js_file_or_dir> is either the name of the JavaScript file to be translated or a directory that  
contains multiple JavaScript files. You can also translate multiple files by specifying *.jsfor the <js_  
file_or_dir>.  
Page 89 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 9: Translating JavaScript and TypeScript code  
Excluding dependencies  
You can avoid translating specific dependencies by adding them to the appropriate property setting  
in the fortify-sca.propertiesfile. Files specified in the following properties are not translated:  
l
com.fortify.sca.skip.libraries.ES6  
l
com.fortify.sca.skip.libraries.jQuery  
l
com.fortify.sca.skip.libraries.javascript  
l
com.fortify.sca.skip.libraries.typescript  
Each property specifies a list of comma- or colon-separated file names (without path information).  
The files specified in these properties apply to both local files and files on the internet. Suppose, for  
example, that the JavaScript code includes the following local file reference:  
<script src="js/jquery-ui.js" type="text/javascript" charset="utf-  
8"></script>  
By default, the com.fortify.sca.skip.libraries.jQueryproperty in the fortify-  
sca.propertiesfile includes jquery-us.js, and therefore OpenText SAST does not translate the  
file shown in the previous example.  
You can use regular expressions for the file names. Note that OpenText SAST automatically inserts  
the regular expression '(-?\d+\.\d+\.\d+)?'before .min.jsor .jsfor each file name included  
in the com.fortify.sca.skip.libraries.jQueryproperty value.  
Note: You can also exclude local files or entire directories with the -excludecommand-line  
option. For more information about this option, see "Translation options" on page 151.  
To provide a thorough analysis, dependent files are included in the translation even if the  
dependency is in a language that is disabled with the -disable-languageoption. For more  
information about the option to disable languages, see "Translation options" on page 151).  
Managing issue detection in NPM dependencies  
By default, OpenText SAST does not report issues in NPM dependencies (files in the node_modules  
directory). This is configured with the com.fortify.sca.exclude.node.modulesproperty, which  
is set to trueby default.  
Setting the com.fortify.sca.exclude.node.modulesproperty to falsedirects OpenText SAST  
to use the following options, which determines what results to report for NPM dependencies:  
l
The com.fortify.sca.follow.importsproperty is enabled by default and directs OpenText  
SAST to resolve all imported files (including NPM dependencies) used in the project and include  
them in the translation and the subsequent analysis. For resolution to find imported files within the  
Page 90 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 9: Translating JavaScript and TypeScript code  
project, OpenText SAST uses an algorithm similar to Node.js (see the Node.js website for more  
information).  
Setting this property to false prevents imported NPM dependencies that are not explicitly included  
on the command-line from being included in the translation and analysis.  
l
The com.fortify.sca.exclude.unimported.node.modulesproperty is enabled by default  
and directs OpenText SAST to exclude node_modules directories that are not referenced by the  
project. This property is enabled by default to avoid translating dependencies that are not needed  
for the final project such as those only required for the build system.  
Setting this property to false causes OpenText SAST to include in the translation (and subsequent  
analysis) all modules discovered during resolution (with the com.fortify.sca.follow.imports  
property enabled) that are not referenced by the project.  
You can use the -excludeoption together with the two properties listed previously to specifically  
exclude modules. Use of this option takes precedence over the previously described property  
configurations.  
Note: OpenText does not recommend using the -exclude option to exclude node modules if  
com.fortify.sca.exclude.node.modulesis set to true, because it can change the quality  
of the results.  
See also  
"Examples of excluding NPM dependencies" below  
Examples of excluding NPM dependencies  
The following examples illustrate three different scenarios for excluding NPM dependencies. All these  
examples use the following directory structure:  
./  
RootProjectDir  
innerSrcDir  
node_modules  
innerProjectReferencedModule  
index.ts  
moduleNotReferencedByProject  
index.ts  
innerProject.ts (contains import from innerProjectReferencedModule)  
node_modules  
projectReferencedModule  
index.ts  
moduleNotReferencedByProject  
index.ts  
projectMain.ts (contains import from projectReferencedModule)  
Example 1  
This example shows the files are translated with  
com.fortify.sca.exclude.unimported.node.modulesset to false. In this case,  
Page 91 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 9: Translating JavaScript and TypeScript code  
com.fortify.sca.follow.importsand  
com.fortify.sca.exclude.unimported.node.modulesare both set to true.  
sourceanalyzer RootProjectDir/ -Dcom.fortify.sca.exclude.node.modules=false  
The following files are included in the translation for Example 1:  
./RootProjectDir/innerSrcDir/innerProject.ts  
./RootProjectDir/innerSrcDir/node_  
modules/innerProjectReferencedModule/index.ts  
./RootProjectDir/projectMain.ts  
./RootProjectDir/node_modules/projectReferencedModule/index.ts  
Example 2  
This example shows that in addition to modules referenced by the project, modules found during  
resolution but not referenced by the project are also included in the translation.  
sourceanalyzer RootProjectDir/ -  
Dcom.fortify.sca.exclude.unimported.node.modules=false  
The following files are included in the translation for Example 2:  
./RootProjectDir/innerSrcDir/innerProject.ts  
./RootProjectDir/innerSrcDir/node_  
modules/innerProjectReferencedModule/index.ts  
./RootProjectDir/innerSrcDir/node_  
modules/moduleNotReferencedByProject/index.ts  
./RootProjectDir/projectMain.ts  
./RootProjectDir/node_modules/projectReferencedModule/index.ts  
./RootProjectDir/node_modules/moduleNotReferencedByProject/index.ts  
Example 3  
This example shows use of the -exclude option to exclude all files under any node_modules  
directory. The -excludeoption overrides resolution of modules based on the configuration of the  
com.fortify.sca.follow.importsand  
com.fortify.sca.exclude.unimported.node.modulesproperties.  
sourceanalyzer RootProjectDir/ -exclude "**/node_modules/*.*"  
The following files are included in the translation for Example 3:  
./RootProjectDir/innerSrcDir/innerProject.ts  
./RootProjectDir/projectMain.ts  
Page 92 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 9: Translating JavaScript and TypeScript code  
Translating JavaScript projects with HTML files  
If the project contains HTML files in addition to JavaScript files, set the  
com.fortify.sca.EnableDOMModelingproperty to true in the fortify-sca.propertiesfile or  
on the command line as shown in the following example:  
sourceanalyzer –b MyProject <js_file_or_dir>  
-Dcom.fortify.sca.EnableDOMModeling=true  
When you set the com.fortify.sca.EnableDOMModelingproperty to true, this can decrease false  
negative reports of DOM-related attacks, such as DOM-related cross-site scripting issues.  
Note: If you enable this option, OpenText SAST generates JavaScript code to model the DOM  
tree structure in the HTML files. The duration of the analysis phase might increase (because  
there is more translated code to analyze).  
If you set the com.fortify.sca.EnableDOMModelingproperty to true, you can also specify  
additional HTML tags for OpenText SAST to include in the DOM modeling with the  
com.fortify.sca.DOMModeling.tagsproperty. By default, OpenText SAST includes the following  
HTML tags: body, button, div, form, iframe, input, head, html, and p.  
For example, to additionaly include the HTML tags uland liin the DOM model, use the following  
command:  
sourceanalyzer –b MyProject <js_file_or_dir>  
-Dcom.fortify.sca.DOMModeling.tags=ul,li  
Including external JavaScript or HTML in the  
translation  
To include external JavaScript or HTML files that are specified with the srcattribute, you can specify  
which domains OpenText SAST can download and include in the translation phase. To do this, specify  
one or more domains with the com.fortify.sca.JavaScript.src.domain.whitelistproperty.  
Note: You can also set this property globally in the fortify-sca.propertiesfile.  
For example, you might have the following statement in your HTML file:  
<script src='http://xyzdomain.com/foo/bar.js' language='text/javascript'/>  
</script>  
Page 93 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 9: Translating JavaScript and TypeScript code  
If you are confident that the xyzdomain.comdomain is a safe location from which to download files,  
then you can include it in the translation phase by adding the following property specification on the  
command line:  
-Dcom.fortify.sca.JavaScript.src.domain.whitelist="xyzdomain.com/foo"  
Note: You can omit the www.prefix from the domain in the property value. For example, if the src  
tag in the original HTML file specifies to download files from www.google.com, you can specify  
just the google.comdomain.  
To trust more than one domain, include each domain separated by the vertical bar character (|) as  
shown in the following example:  
-Dcom.fortify.sca.JavaScript.src.domain.whitelist=  
"xyzdomain.com/foo|abcdomain.com|123.456domain.com”  
If you are using a proxy server, then you need to include the proxy server information on the  
command line as shown in the following example:  
-Dhttp.proxyHost=example.proxy.com -Dhttp.proxyPort=8080  
For a complete list of proxy server options, see the Networking Properties Java documentation.  
Page 94 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
Chapter 10: Translating Python code  
OpenText SAST translates Python applications, and processes files with the .pyextension as Python  
source code. OpenText SAST supports translation of Jupyter notebooks and the Django and Flask  
frameworks.  
This section contains the following topics:  
Python translation command-line syntax  
Translating Python in a virtual environment  
Including imported modules and packages  
Including namespace packages  
95  
97  
98  
98  
99  
Translating Django and Flask  
Python translation command-line syntax  
The basic command-line syntax to translate Python code is:  
sourceanalyzer -b <build_id> -python-version <python_version>  
-python-path <dirs> <files>  
Note: When you translate Python code, make sure that you specify all source files together in one  
invocation. OpenText SAST does not support adding new files to the file list associated with the  
build ID on subsequent invocations.  
Python command-line options  
The following table describes the Python options.  
Python option  
Description  
Specifies the Python source code version to scan. The valid values for  
-python-version  
<version>  
<version> are 2and 3. The default value is 3.  
Equivalent property name:  
com.fortify.sca.PythonVersion  
Page 95 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 10: Translating Python code  
Python option  
Description  
Disables the automatic calculation of a common root directory of all  
project source files to use for importing modules and packages.  
-python-no-auto-  
root-calculation  
Equivalent property name:  
com.fortify.sca.PythonNoAutoRootCalculation  
-python-path  
Specifies a semicolon-separated (Windows) or colon-separated (non-  
<dirs>  
Windows) list of additional import directories. You can use the -python-  
pathoption to specify all paths used to import packages or modules.  
Include all paths to namespace package directories with this option.  
OpenText SAST sequentially searches the specified paths for each  
imported file and uses the first file encountered.  
Equivalent property name:  
com.fortify.sca.PythonPath  
-django-template-  
dirs <dirs>  
Specifies a semicolon-separated (Windows) or colon-separated (non-  
Windows) list of directories that contain Django templates. OpenText  
SAST sequentially searches the specified paths for each Django template  
file and uses the first template file encountered.  
Equivalent property name:  
com.fortify.sca.DjangoTemplateDirs  
Specifies that OpenText SAST does not automatically discover Django  
templates.  
-django-disable-  
autodiscover  
Equivalent property name:  
com.fortify.sca.DjangoDisableAutodiscover  
-jinja-template-  
dirs <dirs>  
Specifies a semicolon-separated (Windows) or colon-separated (non-  
Windows) list of directories that contain Jinja2 templates. OpenText  
SAST sequentially searches the specified paths for each Jinja2 template  
file and uses the first template file encountered.  
Equivalent property name:  
com.fortify.sca.JinjaTemplateDirs  
Specifies that OpenText SAST does not automatically discover Django or  
Jinja2 templates.  
-disable-template-  
autodiscover  
Equivalent property name:  
com.fortify.sca.DisableTemplateAutodiscover  
Page 96 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 10: Translating Python code  
See also  
"Python properties" on page 218  
Python command-line examples  
Translate Python 3 code on Windows:  
sourceanalyzer -b Python3Proj -python-path  
"C:\Python312\Lib;C:\Python312\Lib\site-packages" src/*.py  
Translate Python 2 code on Windows:  
sourceanalyzer -b MyPython2 -python-version 2 -python-path  
"C:\Python27\Lib;C:\Python27\Lib\site-packages" src/*.py  
Translate Python 3 code on non-Windows:  
sourceanalyzer -b Python3Proj -python-path  
/usr/lib/python3.12:/usr/local/lib/python3.12/site-packages src/*.py  
Translate Python 2 code on non-Windows:  
sourceanalyzer -b MyPython2 -python-version 2 -python-path  
/usr/lib/python2.7:/usr/local/lib/python2.7/site-packages src/*.py  
Translating Python in a virtual environment  
This section describes how to translate Python projects in virtual environments. Make sure that all  
project dependencies are installed in your virtual environment. To translate a Python project in a  
virtual environment, include the -python-pathoption to specify the project dependencies.  
Python virtual environment example  
To translate a Python project where the virtual environment name is myenvand the dependencies for  
the project are installed in the myenv/lib/python<version>/site-packagesdirectory, type:  
sourceanalyzer –b mybuild -python-path "myenv/lib/python<version>/site-  
packages/" myproject/  
Page 97 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 10: Translating Python code  
Conda environment example  
To translate a Python project where the conda environment name is myenvand the project  
dependencies are installed in the <conda_install_  
dir>/envs/myenv/lib/python<version>/site-packagesdirectory, type:  
sourceanalyzer –b mybuild -python-path "<conda_install_  
dir>/envs/myenv/lib/python<version>/site-packages/" myproject/  
Including imported modules and packages  
To translate Python applications and prepare for a scan, OpenText SAST searches for any imported  
modules and packages used by the application. OpenText SAST does not respect the PYTHONPATH  
environment variable, which the Python runtime system uses to find imported modules and packages.  
OpenText SAST searches for imported modules and packages using the list of directories in the  
following order:  
1. The common root directory for all project source files. which OpenText SAST calculates  
automatically. For example, if there are two project directories PrimaryDir/project1/*and  
PrimaryDir/project2/*, the common root directory is PrimaryDir.  
To remove the common root directory as a search target for imported modules and packages,  
include the -python-no-auto-root-calculationoption in the translation command.  
2.  
The directories specified with the -python-pathoption.  
OpenText SAST includes a subset of modules from the standard Python library (module  
"builtins", all modules originally written in C, and others) in the translation. OpenText SAST first  
searches for a standard Python library module in the set included with OpenText SAST and then  
in the paths specified with the -python-pathoption. If your Python code imports any module  
that OpenText SAST cannot find, it produces a warning. To make sure that all modules of the  
standard Python library are found, add the path to your standard Python library in the -python-  
pathlist.  
3. The current directory that contains the file being translated. For example, when OpenText SAST  
translates a PrimaryDir/project1/a.py, the directory PrimaryDir/project1is added as  
the last directory to search for imported modules and packages.  
Including namespace packages  
To translate namespace packages, include all the paths to the namespace package directories with  
the -python-pathoption. For example, if you have two subpackages for a namespace package  
package_namein multiple folders:  
Page 98 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 10: Translating Python code  
/path_1/package_name/subpackageA  
/path_2/package_name/subpackageB  
Include /path_1;/path_2with the -python-pathoption in the sourceanalyzer command line.  
Translating Django and Flask  
By default, OpenText SAST attempts to discover Django and Jinja2 templates in the project root  
directory. All detected Django and Jinja2 templates are automatically added to the translation. You  
can specify additional locations of Django or Jinja2 template files by adding the -django-template-  
dirsor the -jinja-template-dirsoption to the sourceanalyzer command.  
If you do not want OpenText SAST to automatically discover Django and Jinja2 templates, use the -  
disable-template-autodiscoveroption. If your project requires Django or Jinja2 templates, but  
the project is configured such that the templates are in an unexpected location, use the -django-  
template-dirsor -jinja-template-dirsoption to specify the directories that contain the  
templates in addition to the -disable-template-autodiscoveroption as shown in the following  
non-Windows examples:  
sourceanalyzer -b djangoProj -python-path  
/usr/lib/python3.12:/usr/local/lib/python3.12/site-packages djangoProj -  
django-template-dirs djangoProj/templatedir1:/djangoProj/dir2 -disable-  
template-autodiscover  
sourceanalyzer -b flaskProj -python-path  
/usr/lib/python3.12:/usr/local/lib/python3.12/site-packages flaskProj -  
jinja-template-dirs flaskProj/templatedir1:/flaskProj/dir2 -disable-  
template-autodiscover  
The following example translates a Python project that has a combination of Django and Jinja2  
templates on Windows:  
sourceanalyzer -b pythonProj -python-path  
"C:\Python312\Lib;C:\Python312\Lib\site-packages" flaskProj -django-  
template-dirs "C:\djangoProj\templatedir1;C:\djangoProj\dir2" -jinja-  
template-dirs "C:\flaskProj\templatedir1;C:\flaskProj\dir2" -disable-  
template-autodiscover  
Page 99 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
Chapter 11: Translating code for mobile  
platforms  
OpenText SAST supports analysis of the following mobile application source languages:  
l
Swift, Objective-C, and Objective-C++ for Apple® iOS applications developed using Xcode®  
l
Java for Android applications  
For information about translating Xamarin applications, see "Translating Visual Studio projects" on  
page 80.  
This section contains the following topics:  
Translating Apple iOS projects  
Translating Android projects  
100  
101  
Translating Apple iOS projects  
This section describes how to translate Swift, Objective-C, and Objective-C++ source code for iOS  
applications. OpenText SAST automatically integrates with the Xcode Command Line Tool,  
Xcodebuild, to identify the project source files.  
iOS project translation prerequisites  
The following are the prerequisites for translating iOS projects:  
l
Objective-C++ projects must use the non-fragile Objective-C runtime (ABI version 2 or 3).  
l
Use Apple’s xcode-selectcommand-line tool to set your Xcode path. OpenText SAST uses the  
system global Xcode configuration to find the Xcode toolchain and headers.  
l
Make sure that all source files required for a successful Xcode build are provided.  
You can exclude files from the analysis using the -excludeoption (see "iOS code analysis  
command-line syntax" on the next page).  
l
l
Make sure that you have any dependencies required to build the project available.  
To translate Swift code, make sure that you have available all third-party modules, including  
CocoaPods. Bridging headers must also be available. However, Xcode usually generates them  
automatically during the build.  
l
l
If your project includes property list files in binary format, you must first convert them to XML  
format. You can do this with the Xcode putilcommand.  
To translate Objective-C projects, ensure that the headers for third-party libraries are available.  
Page 100 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 11: Translating code for mobile platforms  
l
To translate Watchkit® applications, make sure that you translate both the iPhone application  
target and the WatchKit extension target.  
iOS code analysis command-line syntax  
The command-line syntax to translate iOS code using Xcodebuild is:  
sourceanalyzer -b <build_id> xcodebuild [<compiler_options>]  
where <compiler_options> are the supported options that are passed to the Xcode compiler. You  
must include the buildoption with any <compiler_options>. The OpenText SAST Xcodebuild  
integration does not support the output format of alternate build commands such as xcodebuild  
archive.  
Note: Xcodebuild compiles the source code when you run this command.  
To exclude files from the analysis, use the -excludeoption (see "Translation options" on page 151).  
All source files that match the exclude specification are not translated, even if they are included in the  
Xcode build. The following is an example:  
sourceanalyzer -b MyProject -exclude "**/TestFile.swift" xcodebuild clean  
build  
If your application uses any property list files (for example, <file>.plist), translate these files with  
a separate sourceanalyzercommand. Use the same build ID that you used to translate the project  
files. The following is an example:  
sourceanalyzer -b MyProject <path_to_plist_files>  
If your project uses CocoaPods, include -workspaceto build the project. For example:  
sourceanalyzer -b DemoAppSwift xcodebuild clean build -workspace  
DemoAppSwift.xcworkspace -scheme DemoAppSwift -sdk iphonesimulator  
After the translation is complete, you can perform the analysis phase and save the results in an  
FPR file, as shown in the following example:  
sourceanalyzer -b DemoAppSwift -scan -f MyResults.fpr  
Translating Android projects  
This section describes how to translate Java source code for Android applications. You can use  
OpenText SAST to scan the code with Gradle from either:  
Page 101 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 11: Translating code for mobile platforms  
l
Your operating system's command line  
l
A terminal window running in Android Studio  
The way you use Gradle is the same for either method.  
Note: You can also scan Android code directly from Android Studio with the Fortify Analysis  
Plugin for IntelliJ IDEA and Android Studio. For more information, see the OpenText™ Fortify  
Analysis Plugin for IntelliJ IDEA and Android Studio User Guide.  
Android project translation prerequisites  
The following are the prerequisites for translating Android projects:  
l
Android Studio and the relevant Android SDKs are installed on the system where you will run the  
scans  
l
Your Android project uses Gradle for builds.  
If you have an older project that does not use Gradle, you must add Gradle support to the  
associated Android Studio project  
Use the same version of Gradle that is provided with the version of Android Studio that you use to  
create your Android project  
l
Make sure you have available all dependencies that are required to build the Android code in the  
application's project  
l
To translate your Android code from a command window that is not displayed within Android  
Studio, make sure that Gradle Wrapper (gradlew) is defined on the system path  
Android code analysis command-line syntax  
Use gradlew to scan Android projects, which is similar to using Gradle except that you use the Gradle  
Wrapper. For information about how to translate your Android project using the Gradle Wrapper, see  
"Using Gradle integration" on page 140.  
Filtering issues detected in Android layout files  
If your Android project contains layout files (used to design the user interface), your project files  
might include R.javasource files that are automatically generated by Android Studio. When you  
scan the project, OpenText SAST can detect issues associated with these layout files.  
OpenText recommends that Issues reported in any layout file be included in your standard audit so  
you can carefully determine if any of them are false positives. After you identify issues in layout files  
that you are not interested in, you can filter them out as described in "Filtering the analysis" on  
page 192. You can filter out the issues based on the Instance ID.  
Page 102 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
Chapter 12: Translating Go code  
This section describes how to translate Go code. OpenText SAST supports analysis of Go code on  
Windows, Linux, and macOS.  
This section contains the following topics:  
Go command-line syntax  
Go command-line options  
Including custom Go build tags  
Resolving dependencies  
103  
104  
105  
106  
Go command-line syntax  
For the best results, your project must be compilable and you must have all required dependencies  
available.  
The following entities are excluded from the translation (and the scan):  
l
Vendor folder  
l
All projects defined by any go.modfiles in subfolders, except the project defined by the go.modfile  
under the %PROJECT_ROOT%  
l
All files with the _test.gosuffix (unit tests)  
The basic command-line syntax to translate Go code is:  
sourceanalyzer -b <build_id> [-gopath <dir>] [-goroot <dir>] <files>  
For best results, OpenText recommends that you use Go modules for all Go projects and translate the  
Go code one module at a time. Ensure that the values for the <files> parameter for the sourceanalyzer  
command are in the directory that contains the go.modfile. This is the same directory where you run  
the go buildcommand to build the project. If the project consists of more than one module, you can  
run the sourceanalyzer command multiple times with the same <build_id> value to tie the translation  
results for all modules together.  
Use of the GOPATH development mode for builds is still supported but be aware that this can cause  
problems if you are trying to compare two scans in tools such as Fortify Audit Workbench or Fortify  
Software Security Center. Without a go.modfile to define a fixed identifier path for the module, the Go  
language system identifies each module by its absolute path on the local file system. Therefore, two  
scans of the same module from different subdirectories or on different machines produce different  
module identifiers, which prevents matching issues from correlating properly across the two scans.  
The GOPATH development mode is deprecated for the Go compiler and SDK and will be removed in a  
future Go release.  
Page 103 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 12: Translating Go code  
Go command-line options  
The following table describes the command-line options that are specifically for translating Go code.  
Go option  
Description  
Specifies a comma-separated list of custom build tags for a Go project.  
-gotags <go_build_  
tags>  
This is equivalent to the -tagsoption for the gocommand. For more  
information, see "Including custom Go build tags" on the next page.  
Equivalent property name:  
com.fortify.sca.gotags  
Specifies the value of the GOPATH environment variable to use for  
translating a Go project. If this option is not specified, then OpenText  
SAST uses the existing value of the GOPATH system environment  
variable.  
-gopath <dir>  
You must specify the gopath directory as an absolute path. The  
following examples show valid values for <dir>:  
/home/projects/go_workspace/my_proj  
C:\projects\go_workspace\my_proj  
The following example is an invalid value for <dir>:  
go_workspace/my_proj  
If this option and the GOPATH system environment variable is not set,  
then the gopath defaults to a subdirectory named goin the user's  
home directory ($HOME/goon Linux and %USERPROFILE%\goon  
Windows), unless that directory contains a Go distribution.  
When using modules, the GOPATH environment variable is not  
required to resolve package imports. However, GOPATH still  
determines the output directory to use when downloading missing  
module dependencies.  
Note: OpenText SAST does not fully support older Go projects  
that rely solely on the GOPATH environment variable to resolve  
package imports.  
Equivalent property name:  
Page 104 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 12: Translating Go code  
Go option  
Description  
com.fortify.sca.GOPATH  
Specifies the location of the Go installation. If this option is not  
specified, the GOROOT system environment variable is used.  
-goroot <dir>  
If this option is not specified and the GOROOT system environment  
variable is not set, then OpenText SAST uses the Go compiler included  
in the OpenText SAST installation.  
Equivalent property name:  
com.fortify.sca.GOROOT  
Specifies one or more comma-separated proxy URLs. You can also  
-goproxy <url>  
specify director off(to disable network usage).  
If this option is not specified and the GOPROXY system environment  
variable is not set, then OpenText SAST uses  
https://proxy.golang.org,direct.  
Equivalent property name:  
com.fortify.sca.GOPROXY  
See also  
"Go properties" on page 219  
Including custom Go build tags  
If your Go project includes files that require custom build tags, then you can include these build tags  
in the OpenText SAST translation using the -gotagsoption. For example:  
sourceanalyzer -b MyProject -gotags release "src/**/*.go"  
The OpenText SAST -gotagsoption does not allow you to override automatic build tags for the  
operating system, architecture, or Go version (for example, //go:build linux, //go:build arm,  
//go:build go1.21). To translate your Go project for a different operating system or architecture,  
set the appropriate cross-compile targets in the GOOS and GOARCH environment variables. To set a  
specific Go version, specify the path for the Go SDK version in the GOROOT environment variable or  
the -gorootoption.  
Page 105 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 12: Translating Go code  
Resolving dependencies  
OpenText SAST supports two dependency management systems built into Go:  
l
Modules  
To translate a Go project that uses modules, the project must include a go.modfile that specifies  
the required dependencies, and a corresponding go.sumfile for verifying downloaded  
dependencies. Specify the directory that contains the go.modfile as the project root in the  
sourceanalyzer command.  
OpenText SAST downloads all required dependencies using the native Go toolchain. If access to  
the internet is restricted on the machine where you run OpenText SAST, then do one of the  
following:  
l
If you are using an artifact management system such as Artifactory, set the GOPROXY  
environment variable or use the -goproxyoption described in "Go command-line options" on  
page 104.  
l
Download all required dependencies using modules and vendoring.  
If you use manual vendoring, set the GOFLAGS environment variable to -mod=vendorbefore  
you start the translation.  
l
GOPATH dependency resolution  
If you are using a third-party dependency management system such as dep, you must download all  
dependencies before you start the translation.  
The GOPATH development mode identifies dependencies using the absolute path on the local file  
system, which can cause problems when correlating scans from different subdirectories or on  
different machines.  
See also  
"Go command-line syntax" on page 103  
Page 106 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
Chapter 13: Translating Dart and Flutter  
code  
This section describes how to translate Dart and Flutter code. OpenText SAST supports analysis of  
Dart and Flutter code on Windows and Linux.  
This section contains the following topics:  
Dart and Flutter translation prerequisites  
Dart and Flutter command-line syntax  
Dart and Flutter command-line examples  
107  
108  
108  
Dart and Flutter translation prerequisites  
The following are the prerequisites for translating Dart and Flutter projects:  
l
Make sure that you have a supported Dart SDK (for Dart-only projects) and the Flutter SDK (for  
Flutter projects) installed on your system. See "Supported languages" on page 33 for the supported  
Dart versions.  
l
Download the project dependencies by running one of the following commands:  
l
For Flutter projects, use flutter pub get.  
l
For Dart-only projects, use dart pub get.  
For example, to download the dependencies for a Flutter project that has the project root  
myproject, run the following commands:  
cd myproject  
flutter pub get  
Important! If the project includes nested packages with different pubspec.yamlfiles, you  
must run dart pub getor flutter pub getfor each package root.  
Important! Make sure that the following are included in the project directory:  
l
The pubspec.yamlfile, which specifies the dependencies  
l
The .dart_tooldirectory, which includes the package_config.jsonfile automatically  
generated by the pubtool  
Page 107 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 13: Translating Dart and Flutter code  
Dart and Flutter command-line syntax  
The basic command-line syntax to translate Dart and Flutter code is:  
sourceanalyzer –b <build_id> <translation_options> <dirs>  
sourceanalyzer –b <build_id> <translation_options> <files>  
Dart and Flutter command-line examples  
To translate a Dart or Flutter project with the my_appproject root directory:  
sourceanalyzer -b MyProject my_app/  
To translate the a_widget.dartfile in the my_appproject root directory:  
sourceanalyzer -b MyProject my_app/a_widget.dart  
To translate all dart source files in the my_dart_projdirectory:  
sourceanalyzer -b MyProject "my_dart_proj/**/*.dart"  
Page 108 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
Chapter 14: Translating PHP code  
The syntax to translate a single PHP file named MyPHP.phpis shown in the following example:  
sourceanalyzer -b <build_id> MyPHP.php  
To translate a file where the source or the php.inifile entry includes a relative path name (starts  
with ./or ../), consider setting the PHP source root as shown in the following example:  
sourceanalyzer -php-source-root <path> -b <build_id> MyPHP.php  
For more information about the -php-source-rootoption, see the description in "PHP command-  
line options" below.  
When you translate PHP code, make sure that you specify all source files together in one invocation.  
OpenText SAST does not support adding new files to the file list associated with the build ID on  
subsequent invocations.  
This section contains the following topics:  
109  
PHP command-line options  
PHP command-line options  
The following table describes the PHP-specific command-line options.  
PHP option  
Description  
Specifies an absolute path to the project root directory. The relative path  
name first expands from the current directory. If the file is not found,  
-php-source-root  
<path>  
then the path expands from the specified PHP source root directory.  
Equivalent property name:  
com.fortify.sca.PHPSourceRoot  
-php-version  
<version>  
Specifies the PHP version. The default version is 8.2. For a list of valid  
versions, see "Supported languages" on page 33.  
Equivalent property name:  
com.fortify.sca.PHPVersion  
See also  
"PHP properties" on page 222  
Page 109 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
Chapter 15: Translating ABAP code  
ABAP code translation requires additional preparation steps to extract the code from the SAP®  
database and prepare it for scanning. See "Importing the transport request" on the next page for more  
information. This section assumes you have a basic understanding of SAP and ABAP.  
This section contains the following topics:  
About downloading source files  
110  
111  
112  
112  
116  
Importing the transport request  
Adding OpenText SAST to your Favorites list  
Running the Fortify ABAP Extractor  
Uninstalling the Fortify ABAP Extractor  
About downloading source files  
To translate ABAP code, the Fortify ABAP Extractor program downloads source files to the  
presentation server, and optionally, starts OpenText SAST. You need to use an account with  
permission to download files to the local system and execute operating system commands.  
Because the extractor program is executed online, you might receive a max dialog work process  
time reachedmessage if the volume of source files selected for extraction exceeds the allowable  
process run time. To work around this, download large projects as a series of smaller Extractor tasks.  
For example, if your project consists of four different packages, download each package separately  
into the same project directory. If the exception occurs frequently, work with your SAP Basis  
administrator to increase the maximum time limit (rdisp/max_wprun_time).  
When a PACKAGE is extracted from ABAP, the Fortify ABAP Extractor extracts everything from  
TDEVCwith a parentclfield that matches the package name. It then recursively extracts everything  
else from TDEVCwith a parentclfield equal to those already extracted from TDEVC. The field  
extracted from TDEVCis devclass.  
The devclassvalues are treated as a set of program names and handled the same way as a program  
name, which you can provide.  
Programs are extracted from TRDIRby comparing the name field with either:  
l
The program name specified in the selection screen  
l
The list of values extracted from TDEVCif a package was provided  
The rows from TRDIRare those for which the name field has the given program name and the  
expression LIKEprogramnameis used to extract rows.  
This final list of names is used with READ REPORTto get code out of the SAP system. This method  
reads classes and methods out as well as merely REPORTS, for the record.  
Page 110 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 15: Translating ABAP code  
Each READ REPORTcall produces a file in the temporary folder on the local system. OpenText SAST  
translates and scans this set of files to produce an FPR file that you can open with Fortify Audit  
Workbench.  
See also  
"ABAP properties" on page 222  
INCLUDE processing  
As source code is downloaded, the Fortify ABAP Extractor detects INCLUDEstatements in the source.  
When found, it downloads the include targets to the local machine for analysis.  
Importing the transport request  
To scan ABAP code, you need to import the Fortify ABAP Extractor transport request on your SAP  
Server. You can find the transport request in <sast_install_dir>/Tools/SAP_Extractor.zip.  
The Fortify ABAP Extractor package, SAP_Extractor.zip, contains the following files:  
l
K900<release_number>.<system_id>  
l
R900<release_number>.<system_id>  
These files make up the SAP transport request that you must import into your SAP system from  
outside your local Transport Domain. Have your SAP administrator or an individual authorized to  
install transport requests on the system import the transport request. These files contain a program, a  
transaction (YSCA), and the program user interface. After you import them into your system, you can  
extract your code from the SAP database and prepare it for OpenText SAST scanning.  
Installation note  
If you get the transport request import error: Install release does not match the current  
version, then the transport request installation has failed. See "Software requirements" on page 32  
for supported ABAP versions.  
To try to resolve this issue, perform the following steps:  
1. Re-run the transport request import.  
The Import Transport Request dialog box opens.  
2. Select the Options tab.  
3. Select the Ignore Invalid Component Version check box.  
4. Complete the import procedure.  
If this does not resolve the issue or if your system runs on an SAP version with a different table  
structure, OpenText recommends that you export your ABAP file structure using your own  
technology so that OpenText SAST can scan the ABAP code.  
Page 111 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 15: Translating ABAP code  
Adding OpenText SAST to your Favorites list  
Adding OpenText SAST to your Favorites list is optional, but doing so can make it quicker to access  
and start OpenText SAST scans. The following steps assume that you use the user menu in your day-  
to-day work. If your work is done from a different menu, add the Favorites link to the menu that you  
use. Before you create the OpenText SAST entry, make sure that the SAP server is running and you  
are in the SAP Easy Access area of your web-based client.  
To add OpenText SAST to your Favorites list:  
1.  
From the SAP Easy Access menu, type S000in the transaction box.  
The SAP Menu opens.  
2. Right-click the Favorites folder and select Insert transaction.  
The Manual entry of a transaction dialog box opens.  
3.  
Type YSCAin the Transaction Code box.  
4. Click the green check mark icon.  
The Extract ABAP code and launch SCA item appears in the Favorites list.  
5.  
Click the Extract ABAP code and launch SCA link to start the Fortify ABAP Extractor.  
Running the Fortify ABAP Extractor  
To run the Fortify ABAP Extractor:  
1.  
Start the Fortify ABAP Extractor from the Favorites link, the transaction code, or manually start  
the Extractor object.  
This opens the Fortify ABAP Extractor.  
Page 112 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 15: Translating ABAP code  
2. Select the code to download.  
Provide the start and end name for the range of software components, packages, programs, or  
BSP applications that you want to scan.  
Note: You can specify multiple objects or ranges.  
Page 113 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 15: Translating ABAP code  
3. Provide the OpenText SAST-specific parameters described in the following table.  
Field  
Description  
FPR File Path (Optional) Type or select the directory where you want to store the scan  
results file (FPR). Include the name for the FPR file in the path name. You must  
provide the FPR file path to automatically scan the downloaded code on the  
same machine where you are running the extraction process.  
Working  
Directory  
Type or select the directory where you want to store the extracted source  
code.  
Build-ID  
(Optional) Type the build ID for the scan.  
uses the build ID to  
OpenText SAST  
identify the translated source code, which is necessary to scan the code. You  
must specify the build ID to automatically translate the downloaded code on  
the same machine where you are running the extraction process.  
Translation  
Parameters  
(Optional) Type any additional  
command-line translation  
OpenText SAST  
options. You must specify translation options to automatically translate the  
downloaded code on the same machine where you are running the extraction  
process or to customize the translation options.  
Scan  
Parameters  
(Optional) Type any OpenText SAST command-line scan options. You must  
specify scan options to scan the downloaded code automatically on the same  
machine where you are running the extraction process or to customize the  
scan options.  
Page 114 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 15: Translating ABAP code  
Field  
Description  
ZIP File Name  
(Optional) Type a ZIP file name if you want your output in a compressed  
package.  
Maximum  
Call-chain  
Depth  
A global SAP-function F is not downloaded unless F was explicitly selected or  
unless F can be reached through a chain of function calls that start in  
explicitly-selected code and whose length is this number or less. OpenText  
recommends that you do not specify a value greater than 2 unless directed to  
do so by Customer Support.  
4. Provide action information described in the following table.  
Field  
Description  
Download  
Select the Download check box to have OpenText SAST download the source  
code extracted from your SAP database.  
Build  
Scan  
Select the Build check box to have OpenText SAST translate all downloaded  
ABAP code and store it using the specified build ID. This action requires that  
you have an installed version of OpenText SAST on the machine where you are  
running the  
. It is often easier to move the downloaded  
Fortify ABAP Extractor  
source code to a system where OpenText SAST is installed.  
Select the Scan check box to have OpenText SAST run a scan of the specified  
build ID. This action requires that the translate (build) action was previously  
performed. This action requires that you have an installed version of OpenText  
on the machine where you are running the  
. It is  
SAST  
Fortify ABAP Extractor  
often easier to move the downloaded source code to a predefined OpenText  
SAST machine.  
Launch  
AWB  
Select the  
the specified FPR file.  
check box to start  
and open  
Launch AWB  
Fortify Audit Workbench  
Create ZIP  
File  
Select the  
check box to compress the output. You can also  
Create ZIP File  
manually compress the output after the source code is extracted from your SAP  
database.  
Export  
SAP  
Select the  
check box to export SAP standard code  
Export SAP standard code  
as well as custom code.  
standard  
code  
Page 115 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 15: Translating ABAP code  
5. Click Execute.  
Uninstalling the Fortify ABAP Extractor  
To uninstall the ABAP extractor:  
1.  
In ABAP Workbench, open the Object Navigator.  
2. Select package Y_FORTIFY_ABAP.  
3. Expand the Programs tab.  
4. Right-click the following element, and then select Delete.  
l
Program: Y_FORTIFY_SCA  
Page 116 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
Chapter 16: Translating Ruby code  
This section contains the following topics:  
Ruby command-line syntax  
Adding libraries  
117  
118  
118  
Adding gem paths  
Ruby command-line syntax  
The basic command-line syntax to translate Ruby code is:  
sourceanalyzer –b <build_id> <file>  
where <file> is the name of the Ruby file you want to scan. To include multiple Ruby files, separate  
them with a space, as shown in the following example:  
sourceanalyzer –b <build_id> file1.rb file2.rb file3.rb  
In addition to listing individual Ruby files, you can use the asterisk (*) wildcard to select all Ruby files  
in a specified directory. For example, to find all the Ruby files in a directory called src, use the  
following sourceanalyzercommand:  
sourceanalyzer –b <build_id> src/*.rb  
Note: When you translate Ruby code, make sure that you specify all source files together in one  
invocation. OpenText SAST does not support adding new files to the file list associated with the  
build ID on subsequent invocations.  
Ruby command-line options  
The following table describes the Ruby translation options.  
Ruby option  
Description  
Specifies one or more paths to directories that contain Ruby libraries  
(see "Adding libraries " on the next page)  
-ruby-path <dirs>  
Equivalent property name:  
com.fortify.sca.RubyLibraryPaths  
Page 117 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 16: Translating Ruby code  
Ruby option  
Description  
Specifies the path(s) to a RubyGems location (see "Adding gem paths"  
below)  
-rubygem-path  
<dirs>  
Equivalent property name:  
com.fortify.sca.RubyGemPaths  
See also  
"Ruby properties" on page 220  
Adding libraries  
If your Ruby source code requires a specific library, add the Ruby library to the sourceanalyzer  
command. Include all ruby libraries that are installed with ruby gems. For example, if you have a  
utils.rbfile that resides in the /usr/share/ruby/myPersonalLibrarydirectory, then add the  
following to the sourceanalyzercommand:  
-ruby-path /usr/share/ruby/myPersonalLibrary  
Separate multiple libraries with semicolons (Windows) or colons (non-Windows). The following is an  
example of the option on non-Windows system:  
-ruby-path /path/one:/path/two:/path/three  
Adding gem paths  
To add all RubyGems and their dependency paths, import all RubyGems. To obtain the Ruby gem  
paths, run the gem envcommand. Under GEM PATHS, look for a directory similar to:  
/home/myUser/gems/ruby-version  
This directory contains another directory called gems, which contains directories for all the gem files  
installed on the system. For this example, use the following in your command line:  
-rubygem-path /home/myUser/gems/ruby-version/gems  
If you have multiple gemsdirectories, separate them with semicolons (Windows) or colons (non-  
Windows ) such as:  
-rubygem-path /path/to/gems:/another/path/to/more/gems  
Note: On Windows systems, separate the gemsdirectories with a semicolon.  
Page 118 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
Chapter 17: Translating COBOL code  
The COBOL translation runs on Windows systems only and supports modern COBOL dialects.  
Alternatively, you can use the legacy COBOL translation (see "Using Legacy COBOL translation" on  
page 122).  
For a list of supported technologies for translating COBOL code, see "Supported languages" on  
page 33. OpenText SAST does not currently support custom rules for COBOL applications.  
Note: To scan COBOL with OpenText SAST, you must have an OpenText SAST license file that  
specifically includes COBOL scanning capabilities. Contact Customer Support for more  
information about how to obtain the required license file.  
This section contains the following topics:  
Preparing COBOL source and copybook files for translation  
COBOL command-line syntax  
120  
120  
122  
Using Legacy COBOL translation  
Page 119 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 17: Translating COBOL code  
Preparing COBOL source and copybook files for  
translation  
Before you can analyze a COBOL program, you must copy the following program components to the  
Windows system where you run OpenText SAST:  
l
COBOL source code  
OpenText strongly recommends that your COBOL source code files have extensions .CBL, .cbl,  
.COB, or .cob. If your source code files do not have extensions or have non-standard extensions,  
you must follow the instructions in "Translating COBOL source files without file extensions" on the  
next page and "Translating COBOL source files with arbitrary file extensions" on the next page.  
l
All copybook files that the COBOL source code uses  
This includes All SQL INCLUDE files that the COBOL source code references (a SQL INCLUDE file is  
technically a copybook file)  
Important! The copybook files must have the extension .CPYor .cpy.  
If your COBOL source code contains:  
COPY FOO  
or  
EXEC SQL INCLUDE FOO END-EXEC  
then FOOis the name of a COBOL copybook and the corresponding copybook file has the name  
FOO.CPYor FOO.cpy.  
OpenText recommends that you place your COBOL source code files in a directory called sources  
and your copybook files in a directory called copybooks. Create these directories at the same level.  
COBOL command-line syntax  
The basic syntax used to translate a single COBOL source code file is:  
sourceanalyzer -b <build_id> <path>  
The basic syntax used to scan a translated COBOL program and save the analysis results in an  
FPR file is:  
sourceanalyzer -b <build_id> -scan -f <results>.fpr  
See also  
"Specifying files and directories" on page 163  
Page 120 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 17: Translating COBOL code  
Translating COBOL source files without file extensions  
If you have COBOL source files (not copybook files) retrieved from a mainframe without .COBor .CBL  
file extensions (which is typical for COBOL file names), then you must include the following in the  
translation command line:  
-noextension-type COBOL  
The following example command translates COBOL source code without file extensions:  
sourceanalyzer -b MyProject -noextension-type COBOL -copydirs copybooks  
sources  
Translating COBOL source files with arbitrary file extensions  
If you have COBOL source files with an arbitrary extension .xyz, then you must include the following  
in the translation command line:  
-Dcom.fortify.sca.fileextensions.xyz=COBOL  
You must also include the expression *.xyzin the file or directory specifier, if any (see "Specifying  
files and directories" on page 163).  
COBOL command-line options  
The following table describes the COBOL command-line options. To use legacy COBOL translation,  
see "Legacy COBOL translation command-line options" on the next page.  
COBOL option  
Description  
Specifies one or more semicolon-separated directories where OpenText  
SAST looks for copybook files.  
-copydirs <dirs>  
Equivalent property name:  
com.fortify.sca.CobolCopyDirs  
-dialect <dialect>  
Specifies the COBOL dialect. The valid values for <dialect> are  
COBOL390and MICROFOCUS. The dialect value is case insensitive. The  
default value is COBOL390.  
Equivalent property name:  
com.fortify.sca.CobolDialect  
Specifies one or more semicolon-separated COBOL checker directives.  
-checker-  
Page 121 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 17: Translating COBOL code  
COBOL option  
Description  
directives  
<directives>  
Note: This option is intended for advanced users of OpenText™  
Server Express.  
Equivalent property name:  
com.fortify.sca.CobolCheckerDirectives  
Using Legacy COBOL translation  
Use the legacy COBOL translation if either of the following is true:  
l
You run OpenText SAST on a non-Windows operating system.  
For supported non-Windows platforms and architectures, see "Supported platforms and  
architectures" on page 31.  
l
Your COBOL dialect is different than what is supported by the default COBOL translation (see the  
-dialectoption in "COBOL command-line options" on the previous page).  
Prepare the COBOL source code and copybook files as described in "Preparing COBOL source and  
copybook files for translation" on page 120 and use the command-line syntax described in "COBOL  
command-line syntax" on page 120. Note that the legacy COBOL translation accepts copybook files  
with or without file extensions. If the copybook files have file extensions, use the -copy-extensions  
command-line option (see "Legacy COBOL translation command-line options" below).  
Legacy COBOL translation command-line options  
The following table describes the command-line options for the legacy COBOL translation.  
Legacy COBOL option Description  
-cobol-legacy  
Specifies translation of COBOL code using legacy COBOL translation.  
This option is required to enable legacy COBOL translation.  
Equivalent Property Name:  
com.fortify.sca.CobolLegacy  
Specifies one or more semicolon- or colon-separated directories where  
OpenText SAST looks for copybook files.  
-copydirs <dirs>  
Equivalent Property Name:  
com.fortify.sca.CobolCopyDirs  
Specifies one or more semicolon- or colon-separated copybook file  
-copy-extensions  
<ext>  
Page 122 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 17: Translating COBOL code  
Legacy COBOL option Description  
extensions.  
Equivalent Property Name:  
com.fortify.sca.CobolCopyExtensions  
Specifies fixed-format COBOL to direct OpenText SAST to only look for  
source code between columns 8–72 in all lines of code. The default is  
free-format.  
-fixed-format  
IBM® Enterprise COBOL code is typically fixed-format. The following are  
indications that you might need the -fixed-formatoption:  
l
The COBOL translation appears to hang indefinitely  
l
OpenText SAST reports numerous parsing errors in the  
COBOL translation  
Equivalent Property Name:  
com.fortify.sca.CobolFixedFormat  
Page 123 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
Chapter 18: Translating Salesforce Apex and  
Visualforce code  
This section contains the following topics:  
Apex and Visualforce translation prerequisites  
Apex and Visualforce command-line syntax  
124  
125  
Apex and Visualforce translation prerequisites  
To translate Apex and Visualforce projects, make sure that all the source code to scan is available on  
the same machine where you have installed OpenText SAST.  
To scan your custom Salesforce® app, download it to your local computer from your Salesforce  
organization (org) where you develop and deploy it. The downloaded version of your app consists of:  
l
Apex classes in files with the .clsextension  
l
Visualforce web pages in files with the .pageextension  
l
Apex code files called database “trigger” functions in files with the .triggerextension  
l
Visualforce component files in files with the .componentextension  
l
Objects in files with the .objectextension  
Page 124 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 18: Translating Salesforce Apex and Visualforce code  
Use the Ant Migration Tool available on the Salesforce website to download your app from your org in  
the Salesforce cloud to your local computer. Make sure that the project manifest files are set up  
correctly for the specified target in your build.xmlfile. For example, the following package.xml  
manifest file provides OpenText SAST with all classes, custom objects, pages, and components.  
<?xml version="1.0" encoding="UTF-8"?>  
<Package xmlns=http://soap.sforce.com/2006/04/metadata>  
<types>  
<members>*</members>  
<name>ApexClass</name>  
</types>  
<types>  
<members>*</members>  
<name>ApexTrigger</name>  
</types>  
<types>  
<members>*</members>  
<name>ApexPage</name>  
</types>  
<types>  
<members>*</members>  
<name>ApexComponent</name>  
</types>  
<types>  
<members>*</members>  
<name>CustomObject</name>  
</types>  
<version>55.0</version>  
</Package>  
Configure the retrieve targets using the Ant Migration Tool documentation. If your organization uses  
any apps from the app exchange, make sure that these are downloaded as packaged targets.  
Apex and Visualforce command-line syntax  
The basic command-line syntax to translate Apex and Visualforce code is:  
sourceanalyzer -b <build_id> <files>  
where <files> is an Apex or Visualforce file or a path to the source files.  
Important! Supported file extensions for the source files are: .cls, .component, .trigger,  
.object, and .page.  
Page 125 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
Chapter 19: Translating other languages and  
configurations  
This section contains the following topics:  
Analyzing Solidity code  
126  
Translating Flex and ActionScript  
Translating ColdFusion code  
Analyzing SQL  
127  
130  
131  
132  
133  
134  
135  
135  
135  
137  
138  
Translating Scala code  
Translating Infrastructure as Code (IaC)  
Translating JSON  
Translating YAML  
Translating Dockerfiles  
Translating ASP/VBScript virtual roots  
Classic ASP command-line example  
VBScript command-line example  
Analyzing Solidity code  
The basic command-line syntax to translate and scan Solidity code is:  
sourceanalyzer -b <build_id> <files>  
sourceanalyzer -b <build_id> -scan -f <results>.fpr  
Importing dependencies  
OpenText SAST translation only supports import statements for files with relative and absolute paths.  
Import statements for libraries is not supported.  
Managing compiler versions  
OpenText SAST downloads compilers that are referenced in the code with the pragma statement  
from the Solidity compiler repository. By default, OpenText SAST downloads Solidity compilers to  
${flight.workdir}/solidity.  
Page 126 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 19: Translating other languages and configurations  
If a file does not contain a pragma statement, then the default of ^0.8.0is used. You can specify  
different default compiler version to use in the analysis by including the  
flight.solidity.defaultCompilerVersionproperty on the command line. The version you  
specify must exist in the Solidity compiler repository. For example:  
sourceanalyzer -b MyProject ./  
sourceanalyzer -b MyProject -scan -  
Dflight.solidity.defaultCompilerVersion=0.8.16 -f MyResults.fpr  
If a proxy is required for the connection to download Solidity compilers, include the proxy information  
with -Dhttps.proxyHostand -Dhttps.proxyPort. For example:  
sourceanalyzer -b MyProject ./  
sourceanalyzer -b MyProject -scan -Dhttps.proxyHost=MyProxyHost -  
Dhttps.proxyPort=1234 -f MyResults.fpr  
You can add flight.solidity.defaultCompilerVersionto the fortify-sca.properties  
file.  
See also  
"Properties files" on page 200  
Translating Flex and ActionScript  
The basic command-line syntax to translate ActionScript is:  
sourceanalyzer -b <build_id> -flex-libraries <libs> <files>  
where:  
<libs> is a semicolon-separated (Windows) or a colon-separated (non-Windows) list of library names  
to which you want to "link" and <files> are the files to translate.  
Flex and ActionScript command-line options  
Use the following command-line options to translate Flex files. You can also specify this information in  
the properties configuration file (fortify-sca.properties) as noted in each description.  
Flex and ActionScript  
option  
Description  
Specifies the location of the root of a valid Flex SDK. This directory must  
-flex-sdk-root  
<dir>  
contain a frameworks folder that contains a flex-config.xmlfile. It  
Page 127 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 19: Translating other languages and configurations  
Flex and ActionScript  
option  
Description  
must also contain a binfolder that contains an MXMLC executable.  
Equivalent property name:  
com.fortify.sca.FlexSdkRoot  
Specifies a semicolon-separated (Windows) or a colon-separated (non-  
Windows) list of library names to which you want to link. In most cases,  
-flex-libraries  
<libs>  
this list includes flex.swc, framework.swc, and playerglobal.swc  
(usually found in frameworks/libs/in your Flex SDK root).  
Note: You can specify SWC or SWF files as Flex libraries (SWZ is not  
currently supported).  
Equivalent property name:  
com.fortify.sca.FlexLibraries  
Specifies a semicolon-separated (Windows) or a colon-separated (non-  
Windows) list of root directories where MXML sources are located.  
-flex-source-roots  
<dirs>  
Normally, these contain a subfolder named com.  
For example, if the Flex source root specified is foo/bar/src, then  
foo/bar/src/com/fortify/manager/util/Foo.mxmlis  
transformed into an object named com.fortify.manager.util.Foo  
(an object named Fooin the package com.fortify.manager.util).  
Equivalent property name:  
com.fortify.sca.FlexSourceRoots  
Note: The -flex-sdk-rootand –flex-source-rootsoptions are primarily for MXML  
translation, and are optional if you are scanning pure ActionScript. Use –flex-librariesfor to  
resolve all ActionScript linked libraries.  
OpenText SAST translates MXML files into ActionScript, and then runs them through an ActionScript  
parser. The generated ActionScript is simple to analyze; not rigorously correct like the Flex runtime  
model. Consequently, you might get parse errors with MXML files. For instance, the XML parsing  
might fail, translation to ActionScript might fail, and the parsing of the resulting ActionScript might  
also fail. If you see any errors that do not have a clear connection to the original source code, notify  
Customer Support.  
See also  
"Flex and ActionScript properties" on page 223  
Page 128 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 19: Translating other languages and configurations  
ActionScript command-line examples  
The following examples provide command-line syntax to translation ActionScript.  
Example 1  
The following example is for a simple application that contains only one MXML file and a single SWF  
library (MyLib.swf):  
sourceanalyzer -b MyFlexApp -flex-libraries lib/MyLib.swf -flex-sdk-root  
/home/myself/flex-sdk/ -flex-source-roots . my/app/FlexApp.mxml  
This identifies the location of the libraries to include and the Flex SDK and the Flex source root  
locations. The single MXML file, located in /my/app/FlexApp.mxml, results in the translation of the  
MXML application as a single ActionScript class called FlexAppand located in the my.apppackage.  
Example 2  
The following example is for an application in which the source files are relative to the srcdirectory.  
It uses a single SWF library, MyLib.swf, and the Flex and framework libraries from the Flex SDK:  
sourceanalyzer -b MyFlexProject -flex-sdk-root /home/myself/flex-sdk/  
-flex-source-roots src/ -flex-libraries lib/MyLib.swf "src/**/*.mxml"  
"src/**/*.as"  
This example locates the Flex SDK and uses file specifiers to include the .asand .mxmlfiles in the  
srcfolder. It is not necessary to explicitly specify the .SWCfiles located in the –flex-sdk-root,  
although this example does so for the purposes of illustration. OpenText SAST automatically locates  
all .SWCfiles in the specified Flex SDK root, and it assumes that these are libraries intended for use in  
translating ActionScript or MXML files.  
Example 3  
In this example, the Flex SDK root and Flex libraries are specified in the properties file because typing  
the information for each sourceanalyzer run is time consuming and the data does not change often.  
Divide the application into two sections and store them in folders: a main section folder and a modules  
folder. Each folder contains a srcfolder where the paths start. File specifiers contain wild cards to  
pick up all the .mxmland .asfiles in both srcfolders. An MXMLfile in  
main/src/com/foo/util/Foo.mxmlis translated as an ActionScript class named Fooin the  
package com.foo.util, for example, with the source roots specified here:  
sourceanalyzer -b MyFlexProject -flex-source-roots main/src:modules/src  
"./main/src/**/*.mxml" "./main/src/**/*.as" "./modules/src/**/*.mxml"  
"./modules/src/**/*.as"  
Page 129 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 19: Translating other languages and configurations  
Handling resolution warnings  
To see all warnings that were generated during translation, type the following command before you  
start the scan phase:  
sourceanalyzer -b <build_id> -show-build-warnings  
ActionScript warnings  
You might receive a message similar to the following:  
The ActionScript front end was unable to resolve the following imports:  
a.b at y.as:2. foo.bar at somewhere.as:5. a.b at foo.mxml:8.  
This error occurs when OpenText SAST cannot find all the required libraries. You might need to  
specify additional SWC or SWF Flex libraries (using the -flex-librariesoption or the  
com.fortify.sca.FlexLibrariesproperty) so that OpenText SAST can complete the analysis.  
Translating ColdFusion code  
To treat undefined variables in a CFML page as tainted, uncomment the following line in <sast_  
install_dir>/Core/config/fortify-sca.properties:  
#com.fortify.sca.CfmlUndefinedVariablesAreTainted=true  
This instructs the Dataflow Analyzer to watch out for register-globals-style vulnerabilities. However,  
enabling this property interferes with Dataflow Analyzer findings in which a variable in an included  
page is initialized to a tainted value in an earlier-occurring included page.  
ColdFusion command-line syntax  
The basic command-line syntax to translate ColdFusion source code is:  
sourceanalyzer -b <build_id> -source-base-dir <dir> <files> | <file_  
specifiers>  
where:  
l
<build_id> specifies a build ID for the project  
l
<dir> specifies the root directory of the web application  
l
<files> | <file_specifiers> specifies the CFML source code files  
For a description of how to use <file_specifiers>, see "Specifying files and directories" on  
page 163.  
Page 130 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 19: Translating other languages and configurations  
Note: OpenText SAST calculates the relative path to each CFML source file with the  
-source-base-dirdirectory as the starting point. OpenText SAST uses these relative paths  
when it generates instance IDs. If you move the entire application source tree to a different  
directory, the OpenText SAST- generated instance IDs remain the same if you specify an  
appropriate parameter for the -source-base-diroption.  
ColdFusion (CFML) command-line options  
The following table describes the CFML options.  
ColdFusion option  
Description  
The web application root directory.  
-source-base-dir <web_app_root_dir> <files>  
| <file_specifiers>  
Equivalent property name:  
com.fortify.sca.SourceBaseDir  
See also  
"ColdFusion (CFML) properties" on page 223  
Analyzing SQL  
On Windows (and Linux for .NET projects only), OpenText SAST assumes that files with the .sql  
extension are T-SQL rather than PL/SQL. If you have PL/SQL files with the .sqlextension on  
Windows, you must configure OpenText SAST to treat them as PL/SQL.  
The basic syntax to translate and scan PL/SQL is:  
sourceanalyzer -b <build_id> -sql-language PL/SQL <files>  
sourceanalyzer -b <build_id> -sql-language PL/SQL -scan -f <results>.fpr  
Alternatively, you can change the default behavior for files with the .sqlextension. In the fortify-  
sca.propertiesfile, set the com.fortify.sca.fileextensions.sqlproperty to PLSQL.  
The basic syntax to translate and scan T-SQL is:  
sourceanalyzer -b <build_id> -sql-language TSQL <files>  
sourceanalyzer -b <build_id> -scan -f <results>.fpr  
See also  
"SQL properties" on page 224  
Page 131 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 19: Translating other languages and configurations  
PL/SQL command-line example  
The following example commands translate and scan two PL/SQL files:  
sourceanalyzer -b MyProject -sql-language PL/SQL x.pks y.pks  
sourceanalyzer -b MyProject -sql-language PL/SQL -scan -f MyResults.fpr  
The following example commands translate and scan all PL/SQL files in the sourcesdirectory:  
sourceanalyzer -b MyProject -sql-language PL/SQL "sources/**/*.pks"  
sourceanalyzer -b MyProject -sql-language PL/SQL -scan -f MyResults.fpr  
T-SQL command-line example  
The following example translates two T-SQL files:  
sourceanalyzer -b MyProject x.sql y.sql  
The following example translates all T-SQL files in the sourcesdirectory:  
sourceanalyzer -b MyProject "sources\**\*.sql"  
Note: This example assumes the com.fortify.sca.fileextensions.sqlproperty in  
fortify-sca.propertiesis set to TSQL, which is the property's default value.  
Translating Scala code  
Translating Scala code requires the following:  
l
The Akka compiler plugin  
You can download this plugin from the Maven Central Repository.  
l
An Akka (formerly Lightbend) license file  
This license file is included with the OpenText SAST installation in the <sast_install_  
dir>/plugins/lightbenddirectory  
For instructions on how set up the license and translate Scala code, see the Akka documentation  
Fortify SCA for Scala.  
Important! If your project contains source code other than Scala, you must translate the Scala  
code using the Scala Fortify compiler plugin, and then translate other source code with  
sourceanalyzer using the same build ID before you run the analysis phase.  
Page 132 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 19: Translating other languages and configurations  
Translating Infrastructure as Code (IaC)  
OpenText SAST translates Azure Resource Manager (ARM), Bicep, AWS CloudFormation, and  
HCL templates.  
Note: HCL analysis support is specific to Terraform and supported cloud provider Infrastructure  
as Code (IaC) configurations.  
For best results, make sure that the template files are deployment valid. The templates must not  
contain:  
l
Validation errors that are static and locally detectable (for example, type errors or references to  
undefined variables or functions).  
l
Predeployment errors that occur during template interpretation, but before any resources are  
deployed or modified (for example, invalid array indexing operations).  
l
Deployment errors that occur in the cloud (for example, dynamically referencing a non-existent  
resource).  
OpenText recommends that AWS CloudFormation file name extensions are .json, .yaml,  
.template, or .txt. OpenText SAST supports other extensions only if they are not commonly used  
by other languages or file types (such as .javaor .html).  
By default, OpenText SAST translates files with the HCL extensions .hcland .tf.  
ARM translation command-line examples  
Translate an ARM template:  
sourceanalyzer -b MyProject ArmTemplate.json  
Translate all ARM templates in a directory:  
sourceanalyzer -b MyProject "src/**/*.json"  
Bicep translation command-line examples  
Translate a single Bicep template:  
sourceanalyzer -b MyProject BicepTemplate.bicep  
Translate all Bicep templates in a directory:  
sourceanalyzer -b MyProject "src/**/*.bicep"  
Page 133 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 19: Translating other languages and configurations  
AWS CloudFormation translation command-line examples  
Translate AWS CloudFormation templates that have different extensions:  
sourceanalyzer -b MyProject CFTemplateA.template CFTemplateB.yaml  
CFTemplateC.json CFTemplateD.customext  
Translate all AWS CloudFormation templates in a directory that have the .templateextension:  
sourceanalyzer -b MyProject "src/**/*.template"  
Translate all AWS CloudFormation templates in a directory that have either the .jsonor .yaml  
extension:  
sourceanalyzer -b MyProject "src/**/*.json" "src/**/*.yaml"  
HCL translation command-line examples  
Translate two HCL templates with different extensions:  
sourceanalyzer -b MyProject HCLTemplateA.hcl HCLTemplateB.tf  
Translate all HCL templates in a directory:  
sourceanalyzer -b MyProject "src/**/*.tf" "src/**/*.hcl"  
See also  
"Translating JSON" below  
"Translating YAML" on the next page  
Translating JSON  
By default, OpenText SAST translates files with the JSON extension .jsonas JSON. The following  
example translates a JSON file:  
sourceanalyzer -b MyProject x.json  
The following example translates all JSON files in the sourcesdirectory:  
sourceanalyzer -b MyProject "sources/**/*.json"  
Page 134 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 19: Translating other languages and configurations  
Translating YAML  
By default, OpenText SAST translates files with the YAML extensions .yamland .yml. The following  
example translates two YAML files with different file extensions:  
sourceanalyzer -b MyProject x.yaml y.yml  
The following example translates all YAML files in the sourcesdirectory:  
sourceanalyzer -b MyProject "sources/**/*.yaml" "sources/**/*.yml"  
Translating Dockerfiles  
By default, OpenText SAST translates the following files as Dockerfiles: Dockerfile*, dockerfile*,  
*.Dockerfile, and *.dockerfile.  
Note: You can modify the file name extension used to detect Dockerfiles using the  
com.fortify.sca.fileextensionsproperty. See "Translation and analysis phase properties"  
on page 202.  
OpenText SAST accepts the following escape characters in Dockerfiles: backslash (\) and backquote  
(`). If the escape character is not set in the Dockerfile, then OpenText SAST assumes that the  
backslash is the escape character.  
The syntax to translate a directory that contains Dockerfiles is shown in the following example:  
sourceanalyzer -b <build_id> <dir>  
If the Dockerfile is malformed, OpenText SAST writes an error to the log file to indicate that the file  
cannot be parsed and skips the analysis of the Dockerfile. The following is an example of the error  
written to the log:  
Unable to parse dockerfile ProjA.Dockerfile, error on Line 1:20: mismatched  
input '\n' expecting {LINE_EXTEND, WHITESPACE}  
Unable to parse config file  
C:/Users/jsmith/MyProj/docker/dockerfile/ProjA.Dockerfile  
Translating ASP/VBScript virtual roots  
OpenText SAST allows you to handle ASP virtual roots. For web servers that use virtual directories as  
aliases that map to physical directories, OpenText SAST enables you to use an alias.  
Page 135 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 19: Translating other languages and configurations  
For example, you can have virtual directories named Includeand Librarythat refer to the physical  
directories C:\WebServer\CustomerOne\incand C:\WebServer\CustomerTwo\Stuff,  
respectively.  
The following example shows the ASP/VBScript code for an application that uses virtual includes:  
<!--#include virtual="Include/Task1/foo.inc"-->  
For this example, the previous ASP code refers to the file in the following physical location:  
C:\Webserver\CustomerOne\inc\Task1\foo.inc  
The real directory replaces the virtual directory name Includein this example.  
Accommodating virtual roots  
To provide the mapping of each virtual directory to OpenText SAST, you must set the  
com.fortify.sca.ASPVirtualRoots.name_of_virtual_directoryproperty in your OpenText  
SAST command-line invocation as shown in the following example:  
sourceanalyzer -Dcom.fortify.sca.ASPVirtualRoots.<virtual_directory>=<full_  
path_to_corresponding_physical_directory>  
Note: On Windows, if the physical path includes spaces, you must enclose the property setting in  
quotes:  
sourceanalyzer "-Dcom.fortify.sca.ASPVirtualRoots.<virtual_  
directory>=<full_path_to_corresponding_physical_directory>"  
To expand on the example in the previous section, pass the following property value to OpenText  
SAST:  
-Dcom.fortify.sca.ASPVirtualRoots.Include="C:\WebServer\CustomerOne\inc"  
-Dcom.fortify.sca.ASPVirtualRoots.Library="C:\WebServer\CustomerTwo\Stuff"  
This maps Includeto C:\WebServer\CustomerOne\incand Libraryto  
C:\WebServer\CustomerTwo\Stuff.  
When OpenText SAST encounters the #includedirective:  
<!-- #include virtual="Include/Task1/foo.inc" -->  
OpenText SAST determines if the project contains a physical directory named Include. If there is no  
such physical directory, OpenText SAST looks through its runtime properties and finds the -  
Dcom.fortify.sca.ASPVirtualRoots.Include=  
"C:\WebServer\CustomerOne\inc"setting. OpenText SAST then looks for this file:  
C:\WebServer\CustomerOne\inc\Task1\foo.inc.  
Page 136 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 19: Translating other languages and configurations  
Alternatively, you can set this property in the fortify-sca.propertiesfile located in <sast_  
install_dir>\Core\config. You must escape the backslash character (\) in the path of the  
physical directory as shown in the following example:  
com.fortify.sca.ASPVirtualRoots.Library=C:\\WebServer\\CustomerTwo\\Stuff  
com.fortify.sca.ASPVirtualRoots.Include=C:\\WebServer\\CustomerOne\\inc  
Note: The previous version of the ASPVirtualRoot property is still valid. You can use it on the  
OpenText SAST command line as follows:  
-Dcom.fortify.sca.ASPVirtualRoots=C:\WebServer\CustomerTwo\Stuff;  
C:\WebServer\CustomerOne\inc  
This prompts OpenText SAST to search through the listed directories in the order specified when it  
resolves a virtual include directive.  
Using virtual roots example  
You have a file as follows:  
C:\files\foo\bar.asp  
To specify this file, use the following include:  
<!-- #include virtual="/foo/bar.asp">  
Then set the virtual root in the sourceanalyzercommand as follows:  
-Dcom.fortify.sca.ASPVirtualRoots=C:\files\foo  
This strips the /foofrom the front of the virtual root. If you do not specify fooin the  
com.fortify.sca.ASPVirtualRootsproperty, then OpenText SAST looks for  
C:\files\bar.aspand fails.  
The sequence to specify virtual roots is as follows:  
1. Remove the first part of the path in the source.  
2. Replace the first part of the path with the virtual root as specified on the command line.  
Classic ASP command-line example  
To translate a single file classic ASP written in VBScript named MyASP.asp, type:  
sourceanalyzer -b mybuild "MyASP.asp"  
Page 137 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 19: Translating other languages and configurations  
VBScript command-line example  
To translate a VBScript file named myApp.vb, type:  
sourceanalyzer -b mybuild "myApp.vb"  
Page 138 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
Chapter 20: Integrating the analysis into a  
build  
You can integrate the analysis into supported build tools.  
This section contains the following topics:  
Build integration  
139  
140  
145  
147  
148  
149  
149  
Integrating with Gradle  
Integrating with Maven  
Integrating with Ant  
Integrating with Make  
Integrating with CMake  
Integrating with Bazel  
Build integration  
You can translate entire projects with a single operation. Prefix your original build operation with the  
sourceanalyzercommand followed by the OpenText SAST options.  
The basic command-line syntax to translate a complete project is:  
sourceanalyzer -b <build_id> [<sca_options>] <build_tool> [<build_tool_  
options>]  
where <build_tool> is the name of your build tool, such as make, gmake, msbuild, devenv, or  
xcodebuild. See "Supported build tools" on page 41 for a list of supported build tools. OpenText SAST  
executes your build tool and intercepts all compiler operations to collect the specific command line  
used for each input.  
Note: OpenText SAST only processes the compiler commands that the build tool executes. If you  
do not clean your project before you execute the build, then OpenText SAST only processes  
those files that the build tool re-compiles.  
For information about how to integrate with Xcodebuild, see "iOS code analysis command-line syntax"  
on page 101. For information about integration with MSBuild, see "Translating Visual Studio projects"  
on page 80.  
Page 139 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 20: Integrating the analysis into a build  
Successful build integration requires that the build tool:  
l
Executes a supported compiler  
For a list of supported compilers, see "Supported compilers" on page 42.  
l
Executes the compiler on the operating system path search, not with a hardcoded path (This  
requirement does not apply to xcodebuild integration.)  
l
Executes the compiler, rather than executing a sub-process that then executes the compiler  
Integrating with Gradle  
OpenText SAST provides translation integration with projects that are built with Gradle. You can  
either integrate without modifying your build script or use the OpenText SAST Gradle plugin, which  
invokes OpenText SAST using tasks.  
Using Gradle integration  
You can translate projects that are built with Gradle without any modification of the build.gradle  
file. When the build runs, OpenText SAST translates the source files as they are compiled.  
Alternatively, you can use the OpenText SAST Gradle Plugin to perform the analysis from within your  
Gradle build script (see "Using the Gradle plugin" on page 142).  
See "Supported build tools" on page 41 for platforms and languages supported specifically for Gradle  
integration. Any files in the project in unsupported languages for Gradle integration are not translated  
(with no error reporting). These files are therefore not analyzed, and any existing potential  
vulnerabilities can go undetected.  
To integrate OpenText SAST into your Gradle build, make sure that the sourceanalyzerexecutable  
is included in the PATH environment variable. Always use the sourceanalyzerexecutable from the  
system PATH for all Gradle commands to build the project.  
Note: If you have multiple OpenText SAST installations, make sure that the version you want to  
use for your Gradle projects is defined before all other OpenText SAST versions included in the  
PATH environment variable.  
Prepend the Gradle command line with the sourceanalyzercommand as follows:  
sourceanalyzer -b <build_id> <sca_options> gradle [<gradle_options>]  
<gradle_tasks>  
Gradle integration examples  
sourceanalyzer -b MyProject gradle clean build  
sourceanalyzer -b MyProject gradle --info assemble  
Page 140 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 20: Integrating the analysis into a build  
If your build file name is different than build.gradle, then include the build file name with the --  
build-fileoption as shown in the following example:  
sourceanalyzer -b MyProject gradle --build-file sample.gradle clean  
assemble  
You can also use the Gradle Wrapper (gradlew) as shown in the following example:  
sourceanalyzer -b MyProject gradlew [<gradle_options>]  
Translate a project and exclude a file from the translation:  
sourceanalyzer -b MyProject -exclude src\test\**\* gradlew build  
If your application uses XML or property configuration files, translate these files with a separate  
sourceanalyzercommand. Use the same build ID that you used for the project files. The following  
are examples:  
sourceanalyzer -b MyProject <path_to_xml_files>  
sourceanalyzer -b MyProject <path_to_properties_files>  
After OpenText SAST translates the project with gradle or gradlew, you can then perform the analysis  
phase and save the results in an FPR file as shown in the following example:  
sourceanalyzer -b MyProject -scan -f MyResults.fpr  
See also  
"Using the Gradle plugin" on the next page  
Troubleshooting Gradle integration  
If you use configuration caching (--configuration-cacheoption) in your Gradle build with  
OpenText SAST Gradle integration, the build reports the following messages:  
Configuration cache problems found in this build.  
You also might see a message similar to the following:  
FAILURE: Build failed with an exception...  
You can safely ignore this message with respect to the OpenText SAST translation because the  
project is translated. You can verify that the project is translated using the -show-filesoption. For  
example:  
sourceanalyzer -b mybuild -show-files  
Page 141 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 20: Integrating the analysis into a build  
Using the Gradle plugin  
The OpenText SAST installation includes a Gradle plugin located in <sast_install_  
dir>/plugins/gradle. To use the OpenText SAST Gradle Plugin, you need to first configure the  
plugin for your Java or Kotlin project and then use the plugin to analyze your project. The Gradle  
plugin provides three OpenText SAST tasks for the analysis: sca.clean, sca.translate, and sca.scan. See  
"Supported build tools" on page 41 for platforms and languages supported specifically for OpenText  
SAST Gradle plugin.  
Note: If you have multiple OpenText SAST installations, make sure that the version you want to  
use for your Gradle projects is defined before all other OpenText SAST versions included in the  
PATH environment variable.  
To configure the OpenText SAST Gradle Plugin:  
1. Edit the Gradle settings file to specify the path to the plugin:  
l
Groovy DSL (settings.gradle):  
pluginManagement {  
repositories {  
gradlePluginPortal()  
maven {  
url = uri("file://<sast_plugin_path>")  
}
}
}
l
Kotlin DSL (settings.gradle.kts):  
pluginManagement {  
repositories {  
maven(url = uri("file://<sast_plugin_path>"))  
gradlePluginPortal()  
}
}
2. Add entries to the build script as shown in the following examples:  
l
Groovy DSL (build.gradle):  
id 'com.fortify.sca.plugins.gradlebuild' version '25.2'  
Page 142 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 20: Integrating the analysis into a build  
and  
SCAPluginExtension {  
buildId = "MyProject"  
options = ["-encoding", "utf-8", "-logfile", "MyProject.log",  
"-debug-verbose"]  
}
or the following example entry excludes files from the translation:  
SCAPluginExtension {  
buildId = "MyProject"  
options = ["-encoding", "utf-8", "-logfile", "MyProject.log",  
"-debug-verbose", "-exclude", "src/test/**/*"]  
}
l
Kotlin DSL (build.gradle.kts):  
plugins {  
id ("com.fortify.sca.plugins.gradlebuild") version "25.2"  
...  
}
and  
SCAPluginExtension {  
buildId = "MyProject"  
options = listOf("-encoding", "utf-8", "-logfile", "MyProject.log",  
"-debug-verbose")  
}
or the following example entry excludes files from the translation:  
SCAPluginExtension {  
buildId = "MyProject"  
options = listOf("-encoding", "utf-8", "-logfile", "MyProject.log",  
"-debug-verbose", "-exclude", "src/test/**/*")  
}
3. Save and close the Gradle settings and Gradle build files.  
Analyze a Java or Kotlin project with following command sequence:  
l
To remove all existing OpenText SAST temporary files for an existing Java or Kotlin project build,  
run the following:  
Page 143 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 20: Integrating the analysis into a build  
gradlew sca.clean  
l
To run the translation phase for the configured Java or Kotlin project, run the following:  
gradlew sca.translate  
l
To analyze the configured Java or Kotlin project, run the following:  
gradlew sca.scan  
This task runs successfully if OpenText SAST has already translated the project using the  
OpenText SAST Gradle Plugin.  
Working with Java or Kotlin projects that have subprojects  
If you have a Java or Kotlin multi-project build (with subprojects), then you must configure the  
OpenText SAST Gradle plugin using an allprojectsblock. This is shown in the following examples.  
Groovy DSL (build.gradle)  
allprojects {  
apply plugin: "com.fortify.sca.plugins.gradlebuild"  
SCAPluginExtension {  
buildId = "MyProject"  
options = ["-encoding", "utf-8", "-logfile", "MyProject.log",  
"-debug-verbose"]  
...  
}
}
Kotlin DSL (build.gradle.kts):  
allprojects {  
apply(plugin = "com.fortify.sca.plugins.gradlebuild")  
SCAPluginExtension {  
buildId = "MyProject"  
options = listOf("-encoding", "utf-8", "-logfile", "MyProject.log",  
"-debug-verbose")  
...  
}
}
See also  
"Using Gradle integration" on page 140  
Page 144 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 20: Integrating the analysis into a build  
Integrating with Maven  
OpenText SAST includes a Maven plugin that provides a way to add the following capabilities to your  
Maven project builds:  
l
OpenText SAST clean, translate, scan  
l
OpenText SAST export mobile build session (MBS) for a translated project  
l
Send translated code to Fortify ScanCentral SAST  
l
Upload results to Fortify Software Security Center  
You can use the plugin directly or integrate its functionality into your build process.  
Installing and updating the Fortify Maven Plugin  
The Fortify Maven Plugin is located in <sast_install_dir>/plugins/maven. This directory  
contains a binary and a source version of the plugin in both zip and tarball archives. To install the  
plugin, extract the version (binary or source) that you want to use, and then follow the instructions in  
the included README.TXTfile. Perform the installation in the directory where you extracted the  
archive.  
For information about supported versions of Maven, see "Supported build tools" on page 41.  
If you have a previous version of the Fortify Maven Plugin installed, then install the latest version.  
Uninstalling the Fortify Maven Plugin  
To uninstall the Fortify Maven Plugin, manually delete all files from the <maven_local_  
repo>/repository/com/fortify/ps/maven/plugindirectory.  
Testing the Fortify Maven Plugin installation  
After you install the Fortify Maven Plugin, use one of the included sample files to be sure your  
installation works properly.  
To test the Fortify Maven Plugin using the Eightball sample file:  
1.  
Add the directory that contains the sourceanalyzerexecutable to the path environment  
variable.  
For example:  
export set PATH=$PATH:/<sast_install_dir>/bin  
or  
set PATH=%PATH%;<sast_install_dir>/bin  
Page 145 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 20: Integrating the analysis into a build  
2.  
3.  
Type sourceanalyzer -versionto test the path setting.  
OpenText SAST displays the version information if the path setting is correct.  
Go to the sample Eightball directory: <root_dir>/samples/EightBall.  
4. Type the following command:  
mvn com.fortify.sca.plugins.maven:sca-maven-plugin:<ver>:clean  
where <ver> is the version of the Fortify Maven Plugin you are using. If the version is not  
specified, Maven uses the latest version of the Fortify Maven Plugin installed in the local  
repository.  
Note: To see the version of the Fortify Maven Plugin, open the pom.xmlfile that you  
extracted in <root_dir> in a text editor. The Fortify Maven Plugin version is specified in the  
<version>element.  
5. If the command in step 4 completed successfully, then the Fortify Maven Plugin is installed  
correctly. The Fortify Maven Plugin is not installed correctly if you get the following message:  
[ERROR] Error resolving version for plugin  
'com.fortify.sca.plugins.maven:sca-maven-plugin' from the repositories  
Check the Maven local repository and try to install the Fortify Maven Plugin again.  
Using the Fortify Maven Plugin  
There are two ways to perform an analysis on a maven project:  
l
In an OpenText SAST build integration  
In this method, prepend the maven command used to build your project with the sourceanalyzer  
command and any OpenText SAST options. To analyze your files as part of an OpenText SAST  
build integration:  
a. Clean out the previous build:  
sourceanalyzer -b MyProject -clean  
b. Translate the code:  
sourceanalyzer -b MyProject [<sca_options>] [<mvn_command_with_  
options>]  
Examples:  
sourceanalyzer -b MyProject mvn package  
Page 146 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 20: Integrating the analysis into a build  
sourceanalyzer -b MyProject -exclude "**/Test/*.java" mvn clean  
install  
See "Command-line interface" on page 151 for descriptions of available OpenText SAST  
options.  
c.  
Run the scan and save the results in an FPR file as shown in the following example:  
sourceanalyzer -b MyProject [<sca_scan_options>] -scan -f  
MyResults.fpr  
l
As a Maven Plugin  
In this method, you perform the analysis tasks as goals with the mvncommand. For example, use  
the following command to translate source code:  
mvn com.fortify.sca.plugins.maven:sca-maven-plugin:25.2.0:translate  
For example, use the following command to translate source code and exclude test files:  
mvn -Dfortify.sca.exclude=“**/Test/*.java”  
com.fortify.sca.plugins.maven:sca-maven-plugin:25.2.0:translate  
To analyze your code this way, see the documentation included with the Fortify Maven Plugin. The  
following table describes where to find the documentation after you install the Fortify Maven  
Plugin.  
Package type Documentation location  
Binary  
Source  
<root_dir>/docs/index.html  
<root_dir>/sca-maven-plugin/target/site/index.html  
Integrating with Ant  
You can translate Java source files for projects that use an Ant build file. You can apply this  
integration on the command line without modifying the Ant build.xmlfile. When the build runs,  
OpenText SAST intercepts all javactask invocations and translates the Java source files as they are  
compiled. Make sure that you pass any properties to Ant by adding them to the ANT_OPTS  
environment variable. Do not include them in the sourceanalyzer command.  
Note: You must translate any JSP files, configuration files, or any other non-Java source files that  
are part of the application in a separate step.  
To use the Ant integration, make sure that the sourceanalyzerexecutable is in the PATH  
environment variable.  
Page 147 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 20: Integrating the analysis into a build  
Prepend your Ant command-line with the sourceanalyzercommand as follows:  
sourceanalyzer -b <build_id> [<sca_options>] ant [<ant_options>]  
For example, to translate a Java project and exclude a file from the translation:  
sourceanalyzer -b MyProjectA -logfile MyProjectA.log -exclude src/module-  
info.java ant  
Integrating with Make  
To integrate OpenText SAST with make, run sourceanalyzerwith Make for the build process. For  
example, if you build your project with the following build commands:  
make clean  
make  
make install  
You can simultaneously translate and compile the entire project with the following example  
commands:  
make clean  
sourceanalyzer -b MyProject make  
make install  
As an alternative to build integration, you can modify your build script to prefix each compiler, linker,  
and archiver operation with the sourceanalyzercommand. For example, a makefile often defines  
variables for the names of these tools:  
CC=gcc  
CXX=g++  
LD=ld  
AR=ar  
You can prepend the tool references in the makefile with the sourceanalyzercommand and the  
appropriate options.  
CC=sourceanalyzer -b MyProject gcc  
CXX=sourceanalyzer -b MyProject g++  
LD=sourceanalyzer -b MyProject ld  
AR=sourceanalyzer -b MyProject ar  
When you use the same build ID for each operation, OpenText SAST automatically combines each of  
the separately-translated files into a single translated project.  
Page 148 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 20: Integrating the analysis into a build  
Integrating with CMake  
On non-Windows systems, you can translate projects that are built with CMake by incorporating a  
JSON compilation database in the OpenText SAST command. This is only supported for Makefile and  
Ninja generators (see the CMake Reference Documentation for more information).  
To integrate OpenText SAST with a CMake build:  
1.  
2.  
Generate a compile_commands.jsonfile for your CMake project.  
Add -DCMAKE_EXPORT_COMPILE_COMMANDS=yesto the cmakeconfigure command. For  
example:  
cmake -G Ninja -DCMAKE_EXPORT_COMPILE_COMMANDS=yes  
Include the JSON compilation database in your sourceanalyzercommand as follows:  
sourceanalyzer -b <build_id> compile_commands.json  
Integrating with Bazel  
You can translate projects written in Java or Python that are built with Bazel. When the build runs,  
OpenText SAST translates the source files as they are compiled. See "Supported build tools" on  
page 41 for supported Bazel versions.  
Make sure the following requirements are met before you run the OpenText SAST Bazel integration:  
l
Your Bazel build runs without errors.  
l
The sourceanalyzerexecutable is included in the PATH environment variable.  
After the build is complete, always run the OpenText SAST analysis phase with the same version of  
OpenText SAST that is included in the PATH environment variable.  
To run the translation phase for the configured Java or Python, go to the Bazel workspace directory,  
and then run the OpenText SAST command with the target you want to build. Prepend the Bazel  
build command line with the sourceanalyzercommand as follows:  
sourceanalyzer -b <build_id> <sca_options> bazel build <target>  
Note: If you have multiple OpenText SAST installations, make sure that the version you want to  
use for your Bazel projects is defined before all other OpenText SAST versions included in the  
PATH environment variable.  
Page 149 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 20: Integrating the analysis into a build  
Bazel build integration examples  
Translate a project for a specific target:  
sourceanalyzer -b MyProjectA bazel build //proja:my-prj  
Translate target abcin package proja/abc:  
sourceanalyzer -b MyProjectA bazel build //proja/abc  
or  
sourceanalyzer -b MyProjectA bazel build //proja/abc:abc  
Translate all targets in the package proja/abc:  
sourceanalyzer -b MyProjectA bazel build //proja/abc:all  
Translate all targets within the projb/directory:  
sourceanalyzer -b MyProjectB bazel build //projb/...  
Specify a specific JDK version for the translation:  
sourceanalyzer -b MyProjectC -jdk 17 bazel build //projc:my-java-prj  
Translate a project and exclude a file from the translation:  
sourceanalyzer -b MyProjectC -exclude C:\test\MY-JAVA-  
APP\src\main\java\com\example\HelpContent.java bazel build //projc:my-java-  
prj  
Specify Python project dependencies for the translation:  
sourceanalyzer -b MyProjectD -python-path /usr/local/lib/python3.6/ bazel  
build //projd:my-python-app  
OpenText SAST Bazel integration does not support multiple targets and related actions such as  
excluding targets.  
See also  
"Java command-line options" on page 69  
"Python command-line options" on page 95  
Page 150 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
Chapter 21: Command-line interface  
This chapter describes general OpenText SAST command-line options and how to specify source files  
for analysis. Command-line options that are specific to a language are described in the chapter for  
that language.  
This section contains the following topics:  
Translation options  
Analysis options  
Output options  
151  
153  
156  
159  
161  
163  
Other options  
Directives  
Specifying files and directories  
Translation options  
The following table describes the translation options.  
Translation option  
Description  
Specifies a build ID. OpenText SAST uses a build ID to track the files  
that are compiled and combined as part of a build, and then later, to  
scan those files.  
-b <build_id>  
Equivalent property name:  
com.fortify.sca.BuildID  
Specifies a colon-separated list of languages to exclude from the  
-disable-language  
<languages>  
translation phase. The valid language values are abap,  
actionscript, apex, cfml, cobol, configuration, cpp, dart,  
dotnet, golang, objc, php, python, ruby, swift, and vb.  
Equivalent property name:  
com.fortify.sca.DISabledLanguages  
Specifies a colon-separated list of languages to translate. The valid  
-enable-language  
<languages>  
language values are abap, actionscript, apex, cfml, cobol,  
configuration, cpp, dart, dotnet, golang, objc, php, python,  
ruby, swift, and vb.  
Page 151 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 21: Command-line interface  
Translation option  
Description  
Equivalent property name:  
com.fortify.sca.EnabledLanguages  
Specifies the files to exclude from the translation. Files excluded from  
translation are also not scanned. Separate multiple file paths with  
semicolons (Windows) or colons (non-Windows). The following  
-exclude  
<file_specifiers>  
example excludes all Java files in any Testsubdirectory.  
sourceanalyzer -b MyProject –cp "**/*.jar" "**/*"  
-exclude "**/Test/*.java"  
See "Specifying files and directories" on page 163 for more  
information on how to use file specifiers.  
Equivalent property name:  
com.fortify.sca.exclude  
Specifies the source file encoding type. OpenText SAST enables you  
to scan a project that contains differently encoded source files. To  
-encoding <encoding_  
name>  
work with a multi-encoded project, you must specify the -encoding  
option in the translation phase, when OpenText SAST first reads the  
source code file. OpenText SAST remembers this encoding in the  
build session and propagates it into the FVDL file.  
Valid encoding names are from the java.nio.charset.Charset.  
Typically, if you do not specify the encoding type, OpenText SAST  
uses file.encodingfrom the java.io.InputStreamReader  
constructor with no encoding parameter. In a few cases (for example  
with the ActionScript parser), OpenText SAST defaults to UTF-8  
encoding.  
Equivalent property name:  
com.fortify.sca.InputFileEncoding  
When specified before a compiler command line, OpenText SAST  
translates the source file but does not run the compiler.  
-nc  
Page 152 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 21: Command-line interface  
Translation option  
Description  
Specifies the file type for source files that have no extension. The  
-noextension-type  
<file_type>  
valid file type values are ABAP, ACTIONSCRIPT, APEX, APEX_OBJECT,  
APEX_TRIGGER, ARCHIVE, ASPNET, ASP, ASPX, BITCODE, BSP,  
BYTECODE, CFML, COBOL, CSHARP, DART, DOCKERFILE, FLIGHT,  
GENERIC, GO, HCL, HOCON, HTML, INI, JAVA, JAVA_PROPERTIES,  
JAVASCRIPT, JINJA, JSON, JSP, JSPX, JUPYTER, KOTLIN, MSIL, MXML,  
OBJECT, PHP, PLSQL, PYTHON, RUBY, RUBY_ERB, SCALA, SWIFT, SWC,  
SWF, TLD, SQL, TSQL, TYPESCRIPT, VB, VB6, VBSCRIPT, VISUAL_  
FORCE, VUE, and XML, and YAML.  
Specifies to include build script files that have the same name as a  
build tool (such as gradlew) during translation as source files.  
-disable-compiler-  
resolution  
Equivalent property name:  
com.fortify.sca.DisableCompilerName  
Specifies the directory to store intermediate files generated in the  
translation and analysis phases. OpenText SAST makes extensive use  
of intermediate files located in this project root directory. In some  
cases, you can achieve better performance for analysis by making  
sure this directory is on local storage rather than on a network drive.  
-project-root  
Equivalent property name:  
com.fortify.sca.ProjectRoot  
Analysis options  
The following table describes the analysis options.  
Analysis option  
Description  
Specifies the build ID used in a prior translation command.  
-b <build_id>  
Equivalent property name:  
com.fortify.sca.BuildID  
Causes OpenText SAST to perform a security analysis for the specified  
build ID.  
-scan  
Specifies a scan policy for the analysis. The valid policy names are  
-scan-policy  
|
<policy_name>  
classic, security, and devops. For more information, see "Applying a  
Page 153 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 21: Command-line interface  
Analysis option  
Description  
-sc<policy_name>  
scan policy to the analysis" on page 64.  
Equivalent property name:  
com.fortify.sca.ScanPolicy  
Specifies the analyzers you want to enable with a colon- or comma-  
-analyzers  
<analyzer_list>  
separated list of analyzers. The valid analyzer names are buffer,  
content, configuration, controlflow, dataflow, nullptr,  
semantic, and structural. You can use this option to disable  
analyzers that are not required for your security requirements.  
Equivalent property name:  
com.fortify.sca.DefaultAnalyzers  
Uses speed dial to scan the project with a scan precision level. The lower  
the scan precision level, the faster the scan performance. The valid  
-p <level> |  
-scan-precision  
<level>  
values are 1, 2, 3, and 4. For more information, see "Configuring scan  
speed with speed dial" on page 174.  
Equivalent property name:  
com.fortify.sca.PrecisionLevel  
Specifies the directory to store intermediate files generated in the  
translation and analysis phases. OpenText SAST makes extensive use of  
intermediate files located in this project root directory. In some cases,  
you can achieve better performance for analysis by making sure this  
directory is on local storage rather than on a network drive.  
-project-root  
Equivalent property name:  
com.fortify.sca.ProjectRoot  
Specifies the issue template file to use for the scan. This only affects  
-project-template  
<file>  
scans on the local machine. If you upload the FPR to Fortify Software  
Security Center, it uses the issue template assigned to the application  
version.  
Equivalent property name:  
com.fortify.sca.ProjectTemplate  
Page 154 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 21: Command-line interface  
Analysis option  
Description  
Quickly scan the project for critical- and high-priority issues using the  
-quick  
fortify-sca-quickscan.propertiesfile, which provides a less in-  
depth analysis. By default, quick scan disables the Buffer Analyzer and  
the Control Flow Analyzer. In addition, it applies the Quick View filter set.  
For more information, see "Quick scan" on page 173.  
Equivalent property name:  
com.fortify.sca.QuickScanMode  
Specifies a results filter file. For more information, see "Filtering the  
analysis" on page 192.  
-filter <file>  
-bin <binary> |  
Equivalent property name:  
com.fortify.sca.FilterFile  
Specifies a subset of source files to scan. Only the source files that were  
linked in the named binary at build time are included in the scan. You can  
use this option multiple times to specify the inclusion of multiple binaries  
in the scan.  
-binary-name  
<binary>  
Equivalent property name:  
com.fortify.sca.BinaryName  
Used to test custom rules. Disables all rules of the specified type in the  
default Rulepacks. You can use this option multiple times to specify  
multiple rule types.  
-disable-default-  
rule-type  
<type>  
The <type> parameter is the XML tag minus the suffix Rule. For  
example, use DataflowSourcefor DataflowSourceRule elements. You  
can also specify specific sections of characterization rules, such as  
Characterization:Control flow, Characterization:Issue, and  
Characterization:Generic.  
The <type> parameter is case-insensitive.  
Used to test custom rules. Disables rules in default Rulepacks that lead  
directly to issues. OpenText SAST still loads rules that characterize the  
behavior of functions.  
-no-default-issue-  
rules  
Note: This is equivalent to disabling the following rule types:  
DataflowSink, Semantic, Controlflow, Structural, Configuration,  
Content, Statistical, Internal, and Characterization:Issue.  
Page 155 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 21: Command-line interface  
Analysis option  
Description  
Equivalent property name:  
com.fortify.sca.NoDefaultIssueRules  
Used to test custom rules. Disables loading of rules from the default  
Rulepacks. OpenText SAST processes the Rulepacks for description  
elements and language libraries, but processes no rules.  
-no-default-rules  
Equivalent property name:  
com.fortify.sca.NoDefaultRules  
Used to test custom rules. Disables source rules in the default Rulepacks.  
-no-default-  
source-rules  
Note: Characterization source rules are not disabled.  
Equivalent property name:  
com.fortify.sca.NoDefaultSourceRules  
Used to test custom rules. Disables sink rules in the default Rulepacks.  
-no-default-sink-  
rules  
Note: Characterization sink rules are not disabled.  
Equivalent property name:  
com.fortify.sca.NoDefaultSinkRules  
Specifies a custom Rulepack or directory. You can use this option  
multiple times to specify multiple Rulepack files. If you specify a  
directory, OpenText SAST includes all the files in the directory with the  
-rules <file> |  
<dir>  
.binand .xmlextensions.  
Equivalent property name:  
com.fortify.sca.RulesFile  
Output options  
The following table describes the output options. Apply all these options during the analysis phase  
(with the -scanoption). You can specify the build-label, build-project, and build-version  
options during the translation phase and they are overridden if specified again for the analysis phase.  
Output option  
Description  
Specifies the file to which analysis results are written. If you do not  
specify an output file, OpenText SAST writes the output to the terminal.  
-f <file> |  
-output-file  
Page 156 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 21: Command-line interface  
Output option  
Description  
Equivalent property name:  
<file>  
com.fortify.sca.ResultsFile  
-format <format>  
Controls the output format. Valid options are fpr, fvdl, fvdl.zip,  
text, and auto. The default is auto, which selects the output format  
based on the file name extension of the file provided with the -foption.  
The FVDL is an XML file that contains the detailed OpenText SAST  
analysis results. This includes vulnerability details, rule descriptions,  
code snippets, command-line options used in the scan, and any scan  
errors or warnings.  
The FPR is a package of the analysis results that includes the FVDL file  
as well as extra information such as a copy of the source code used in the  
scan, the external metadata, and custom rules (if applicable). Fortify  
Audit Workbench is automatically associated with the .fprextension.  
Note: If you use result certification, you must specify the fprformat.  
See the OpenText™ Fortify Audit Workbench User Guide for  
information about result certification.  
You can prevent some information from being included in the FPR or  
FVDL file to improve scan time or output file size. See other options in  
this table and see "Optimizing FPR files" on page 177.  
Equivalent property name:  
com.fortify.sca.Renderer  
-append  
Appends results to the file specified with the -foption. The resulting  
FPR file contains the issues from the earlier scan as well as issues from  
the current scan. The build information and program data (lists of  
sources and sinks) sections are also merged. To use this option, the  
output file format must be fpror fvdl. For information on the -format  
output option, see the description in this table.  
The engine data, which includes Fortify Software Security Content  
information, command-line options, system properties, warnings, errors,  
and other information about the execution of OpenText SAST (as  
opposed to information about the program being analyzed), is not  
merged. Because engine data is not merged with the -appendoption,  
OpenText does not certify results generated with -append.  
Page 157 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 21: Command-line interface  
Output option  
Description  
If this option is not specified, OpenText SAST adds any new findings to  
the FPR file, and labels the older result as previousfindings.  
In general, only use the -appendoption when it is impossible to analyze  
an entire application at once.  
Equivalent property name:  
com.fortify.sca.OutputAppend  
Specifies a label for the project to include in the analysis results. You can  
include this option during the translation or the analysis phase.  
OpenText SAST does not use this label for code analysis.  
-build-label  
<label>  
Equivalent property name:  
com.fortify.sca.BuildLabel  
Specifies a name for the project to include in the analysis results. You can  
include this option during the translation or the analysis phase.  
OpenText SAST does not use this name for code analysis.  
-build-project  
<project_name>  
Equivalent property name:  
com.fortify.sca.BuildProject  
Specifies a version for the project to include in the analysis results. You  
can include this option during the translation or the analysis phase.  
OpenText SAST does not use this version for code analysis.  
-build-version  
<version>  
Equivalent property name:  
com.fortify.sca.BuildVersion  
Excludes source files from the analysis results file. The analysis results  
will still include snippets.  
-disable-source-  
bundling  
Equivalent property name:  
com.fortify.sca.FPRDisableSourceBundling  
Excludes the Fortify Software Security Content descriptions from the  
analysis results file.  
-fvdl-no-  
descriptions  
Equivalent property name:  
com.fortify.sca.FVDLDisableDescriptions  
Excludes engine data from the analysis results file. The engine data  
-fvdl-no-  
enginedata  
includes Fortify Software Security Content information, command-line  
options, system properties, warnings, errors, and other information about  
Page 158 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 21: Command-line interface  
Output option  
Description  
the OpenText SAST execution.  
Equivalent property name:  
com.fortify.sca.FVDLDisableEngineData  
Excludes program data from the analysis results file. This removes the  
taint source information from the Functions view in Fortify Audit  
Workbench.  
-fvdl-no-progdata  
Equivalent property name:  
com.fortify.sca.FVDLDisableProgramData  
Excludes the code snippets from the analysis results file.  
-fvdl-no-snippets  
Equivalent property name:  
com.fortify.sca.FVDLDisableSnippets  
Other options  
The following table describes other options.  
Other option  
Description  
Reads command-line options from the specified file. The plain text <file>  
@<file>  
contains options and parameters, each on a separate line.  
For example, instead of running the command sourceanalyzer -b  
my_build_id -source 17 -cp lib.jar Test.java, you can run  
the following command: sourceanalyzer @optfile.txtwhere the  
optfile.txtfile contains:  
"-b"  
"my_build_id"  
"-source"  
"17"  
"-cp"  
"lib.jar"  
"Test.java"  
Prints a summary of the command-line options.  
-h|  
-?|  
-help  
Page 159 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 21: Command-line interface  
Other option  
Description  
Includes debug information in the OpenText SAST Support log file,  
which is only useful for Customer Support to help troubleshoot.  
-debug  
Equivalent property name:  
com.fortify.sca.Debug  
-debug-verbose  
This is the same as the -debugoption, but it includes more details,  
specifically for parse errors.  
Equivalent property name:  
com.fortify.sca.DebugVerbose  
Includes performance information in the OpenText SAST Support log.  
-debug-mem  
-verbose  
Equivalent property name:  
com.fortify.sca.DebugTrackMem  
Sends verbose status messages to the console and to the OpenText  
SAST Support log file.  
Equivalent property name:  
com.fortify.sca.Verbose  
Specifies the log file that OpenText SAST creates. For default log file  
locations, see "Locating the log files" on page 189.  
-logfile <file>  
Equivalent property name:  
com.fortify.sca.LogFile  
Directs OpenText SAST to overwrite the log file for each run of  
sourceanalyzer. Without this option, OpenText SAST appends  
information to the log file.  
-clobber-log  
Equivalent property name:  
com.fortify.sca.ClobberLogFile  
Disables the command-line progress information.  
-quiet  
Equivalent property name:  
com.fortify.sca.Quiet  
Displays the OpenText SAST version and versions of various  
independent modules included with OpenText SAST (all other  
functionality is contained in OpenText SAST).  
-version|  
-v  
Enables automatic allocation of memory based on the physical memory  
-autoheap  
Page 160 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 21: Command-line interface  
Other option  
Description  
available on the system. This is the default memory allocation setting.  
Manually specifies the maximum amount of memory OpenText SAST  
uses.  
-Xmx<size>M| G  
Note: OpenText recommends that you use the default memory  
allocation setting defined by -autoheapinstead of manually  
specifying the maximum memory with this option.  
Heap sizes between 32 GB and 48 GB are not advised due to internal  
JVM implementations. Heap sizes in this range perform worse than at 32  
GB. The JVM optimizes heap sizes smaller than 32 GB. If your scan  
requires more than 32 GB, then you need 64 GB or more. As a guideline,  
assuming no other memory intensive processes are running, do not  
allocate more than 2/3 of the available memory.  
When you specify this option, make sure that you do not allocate more  
memory than is physically available, because this degrades performance.  
As a guideline, and the assumption that no other memory intensive  
processes are running, do not allocate more than 2/3 of the available  
memory.  
Directives  
Use only one directive at a time and do not use any directive in conjunction with translation or  
analysis commands. Use the directives described in the following table to list information about  
previous translation commands.  
Directive  
Description  
Deletes all OpenText SAST intermediate files and build records. If you  
specify a build ID, only files and build records that relate to that build  
ID are deleted.  
-clean  
Displays all objects created but not used in the production of any other  
binaries. If fully integrated into the build, it lists all the binaries  
produced.  
-show-binaries  
-show-build-ids  
Displays a list of all known build IDs.  
Page 161 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 21: Command-line interface  
Directive  
Description  
-show-build-tree  
When you scan with the -binoption, displays all files used to create  
the binary and all files used to create those files in a tree layout. If the  
-binoption is not present, the tree is displayed for each binary.  
Note: This option can generate an extensive amount of  
information.  
-show-build-warnings Use with the -boption to display any errors and warnings that  
occurred in the translation phase on the console.  
Note: Fortify Audit Workbench also displays these errors and  
warnings in the results Certification tab.  
-show-files  
-show-loc  
Displays the files included in the specified build ID. When the -bin  
option is present, displays only the source files that went into the  
binary.  
Use with the -boption to display the number of lines in the translated  
code.  
LIM license directives  
OpenText SAST provides directives to manage the usage of your LIM license. You can store or clear  
the LIM license pool credentials. You can also request (and release) a detached lease for offline  
analysis if the specified license pool permits detached leases.  
Note: By default, OpenText SAST requires an HTTPS connection to the LIM server and you must  
have a trusted certificate. For more information, see "Adding trusted certificates" on page 61.  
Use the directives described in the following table for a license managed by the LIM.  
LIM directive  
Description  
Stores your LIM license pool credentials so that OpenText SAST uses  
the LIM for licensing. The proxy information is optional. OpenText  
SAST stores the pool password and the proxy credentials provided  
-store-license-pool-  
credentials "<lim_  
url>|<lim_pool_  
name>|<lim_pool_  
pwd>|<proxy_  
with this directive in the fortify-sca.propertiesfile as  
encrypted data. If your license pool credentials change after you have  
installed OpenText SAST, you can run this directive again to save the  
new credentials.  
url>|<proxy_  
user>|<proxy_pwd>"  
Page 162 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 21: Command-line interface  
LIM directive  
Description  
Example:  
sourceanalyzer -store-license-pool-credentials  
"https://<ip_address>:<port>|TeamA|mypassword"  
Associated property names:  
com.fortify.sca.lim.Url  
com.fortify.sca.lim.PoolName  
com.fortify.sca.lim.PoolPassword  
com.fortify.sca.lim.ProxyUrl  
com.fortify.sca.lim.ProxyUsername  
com.fortify.sca.lim.ProxyPassword  
-clear-license-pool-  
credentials  
Removes the LIM license pool credentials from the fortify-  
sca.propertiesfile. If your license pool credentials change, you  
can remove them with this directive, and then use the -store-  
license-pool-credentialsdirective to save the new credentials.  
Requests a detached lease from the LIM license pool for exclusive use  
on this system for the specified duration (in minutes). This enables  
you to run OpenText SAST even when disconnected from your  
corporate intranet.  
-request-detached-  
lease <duration>  
Note: To use this directive, the license pool must be configured  
to allow detached leases.  
Releases a detached lease back to the license pool.  
-release-detached-  
lease  
Specifying files and directories  
File specifiers are expressions that allow you to pass a long list of files or a directory to OpenText  
SAST using wildcard characters. OpenText SAST recognizes two types of wildcard characters: a single  
asterisk character (*) matches part of a file name, and double asterisk characters (**) recursively  
matches directories. You can specify one or more files, one or more file specifiers, or a combination of  
files and file specifiers. Separate multiple file specifiers with semicolons (Windows) or colons (non-  
Windows).  
<files> | <file_dir_specifiers>  
Windows and many Linux shells automatically expand parameters that contain the asterisk character  
(*), so you must enclose file-specifier expressions in quotes. Also, on Windows, you can use the  
backslash character (\) as the directory separator instead of the forward slash (/).  
Page 163 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 21: Command-line interface  
Note: File specifiers do not apply to languages that require compiler or build integration.  
The following table describes examples of file and directory specifiers.  
File or directory specifier  
Description  
Matches all files in the named directory and any  
subdirectories or the named directory when used for a  
directory parameter.  
<dir>  
"<dir>/**/*"  
"<dir>/**/Example.java"  
Matches any file named Example.javafound in the  
named directory or any subdirectories.  
Matches any file with the specified extension found in the  
named directory.  
"<dir>/*.java"  
"<dir>/*.jar"  
Matches any file with the specified extension found in the  
named directory or any subdirectories.  
"<dir>/**/*.kt"  
"<dir>/**/*.jar"  
Matches all directories and files found in the named  
"<dir>/**/beta/**"  
directory that have betain the path, including betaas a  
file name.  
"<dir>/**/classes/"  
Matches all directories and files with the name classes  
found in the named directory and any subdirectories.  
Matches all files in the current directory tree that have a  
"**/test/**"  
testelement in the path, including testas a file name.  
Matches all files in the current directory tree that have a  
"**/test/**/*;**/build/**/*"  
or a  
element in the path, including  
or  
test  
test  
build  
or  
as a file name.  
build  
"**/test/**/*:**/build/**/*"  
"**/webgoat/*"  
Matches all files in any webgoatdirectory in the current  
directory tree.  
Matches:  
l
/src/main/java/org/owasp/webgoat  
l
/test/java/org/owasp/webgoat  
Does not match (assignmentsdirectory does not match)  
l
/test/java/org/owasp/webgoat/assignments  
Page 164 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
Chapter 22: Command-line tools  
OpenText SAST command-line tools enable you to manage Fortify Software Security Content,  
perform post-installation configurations, and monitor scans. These tools are located in <sast_  
install_dir>/bin. The tools for Windows are provided as .bator .cmdfiles. The following table  
describes the command-line tools installed with OpenText SAST.  
Note: By default, log files for OpenText SAST tools are written to the following directory:  
l
Windows: C:\Users\<username>\AppData\Local\Fortify\<tool_name>-  
<version>\log  
l
Non-Windows: <userhome>/.fortify/<tool_name>-<version>/log  
Tool  
Description  
More information  
fortifyupdate  
Compares installed security content to the current version "About updating  
and makes any required updates  
With this tool you can:  
Fortify Software  
Security Content"  
on the next page  
FPRUtility  
OpenText™  
Application  
Security Tools  
Guide  
l
Merge audited projects  
l
Verify FPR signatures  
l
Display information from an FPR file  
l
Combine or split source code files and audit projects into  
FPR files  
l
Alter an FPR  
scapostinstall  
SCAState  
This tool enables you to migrate properties files from a  
previous version of OpenText SAST, specify a locale, and  
specify a proxy server for security content updates and for  
Fortify Software Security Center.  
"Running the post-  
install tool" on  
page 58  
Provides state analysis information on the JVM during the "Checking the scan  
analysis phase  
status with  
SCAState" on  
page 169  
Page 165 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 22: Command-line tools  
This section contains the following topics:  
About updating Fortify Software Security Content  
Checking the scan status with SCAState  
166  
169  
About updating Fortify Software Security Content  
You can use the fortifyupdate command-line tool to download the latest Fortify Secure Coding  
Rulepacks and metadata from OpenText.  
The fortifyupdate tool gathers information about the existing security content in your OpenText  
SAST installation and contacts the Fortify Rulepack update server with this information. The server  
returns new or updated security content, and removes any obsolete security content from your  
OpenText SAST installation. If your installation is current, a message is displayed to that effect.  
Updating Fortify Software Security Content  
Use the fortifyupdate command-line tool to either download security content or import a local copy of  
the security content. This tool is located in the <sast_install_dir>/bindirectory.  
The default read timeout for this tool is 180 seconds. To change the timeout setting, add the  
rulepackupdate.SocketReadTimeoutSecondsproperty in the server.properties  
configuration file. For more information, see the OpenText™ Application Security Tools Guide.  
The basic command-line syntax for fortifyupdate is shown in the following example:  
fortifyupdate [<options>]  
To update your OpenText SAST installation with the latest Fortify Secure Coding Rulepacks and  
external metadata from the Fortify Rulepack update server, type the following command:  
fortifyupdate  
To update security content from the local system:  
fortifyupdate -import <my_local_rules>.zip  
To update security content from a Fortify Software Security Center server using credentials:  
fortifyupdate -url <ssc_url> -sscUser <username> -sscPassword <password>  
Page 166 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 22: Command-line tools  
fortifyupdate command-line options  
The following table describes the fortifyupdate options.  
fortifyupdate option  
Description  
Specifies to accept the public key. When this is  
-acceptKey  
specified, you are not prompted to provide a public key.  
Use this option to accept the public key if you update  
Fortify Software Security Content from a non-standard  
location with the -urloption.  
Specifies to use the SSL certificate provided by the  
server.  
-acceptSSLCertificate  
-import <file>.zip  
Imports the ZIP file that contains security content. By  
default, Rulepacks are imported into the <sast_  
install_dir>/Core/config/rulesdirectory.  
Specifies a core directory where fortifyupdate stores  
the update. If this is not specified, the fortifyupdate  
performs the update in the <sast_install_dir>.  
-coreDir <dir>  
Important! Make sure that you copy the contents  
of the <sast_install_dir>/config/keys  
folder and paste it to a config/keysfolder in this  
directory before you run fortifyupdate.  
Specifies to only update external metadata.  
Specifies to only update Rulepacks.  
-includeMetadata  
-includeRules  
Specifies a locale. English is the default if no security  
content exists for the specified locale. The valid values  
are:  
-locale <locale>  
l
en(English)  
l
es(Spanish)  
l
ja(Japanese)  
l
ko(Korean)  
l
pt_BR(Brazilian Portuguese)  
Page 167 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 22: Command-line tools  
fortifyupdate option  
Description  
l
zh_CN(Simplified Chinese)  
l
zh_TW(Traditional Chinese)  
Note: The values are not case-sensitive.  
Alternatively, you can specify a default locale for  
security content updates in the fortify.properties  
configuration file. For more information, see the  
OpenText™ Application Security Tools Guide.  
Specifies a proxy server network name or IP address.  
Specifies a proxy server port number.  
-proxyhost <host>  
-proxyport <port>  
Specifies a user name if the proxy server requires  
authentication.  
-proxyUsername  
<username>  
Specifies the password if the proxy server requires  
authentication.  
-proxyPassword  
<password>  
Displays the currently installed Rulepacks including any  
custom rules and custom metadata.  
-showInstalledRules  
Displays the currently installed external metadata.  
-showInstalledExternalMetadata  
-url <url>  
Specifies a URL from which to download the security  
content. The default URL is  
https://update.fortify.comor the value set for  
the rulepackupdate.serverproperty in the  
server.propertiesconfiguration file.  
For more information about the server.properties  
configuration file, see the OpenText™ Application  
Security Tools Guide.  
You can download the security content from a Fortify  
Software Security Center server by providing a Fortify  
Software Security Center URL.  
Specify one of the following types of credentials if you update security content from Fortify  
Software Security Center with the -urloption:  
Page 168 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 22: Command-line tools  
fortifyupdate option  
Description  
Specifies a  
account by user name and password.  
user  
-sscUsername  
-sscPassword  
Fortify Software Security Center  
Specifies a Fortify Software Security Center  
-sscAuthToken  
authentication token of type UnifiedLoginToken,  
CIToken, or ToolsConnectToken.  
Checking the scan status with SCAState  
Use the SCAState tool to see up-to-date state analysis information during the analysis phase.  
To check the state:  
1. Start a scan.  
2. Open another command window.  
3. Type the following at the command prompt:  
SCAState [<options>]  
See also  
"SCAState command-line options" below  
SCAState command-line options  
The following table describes the SCAState options.  
SCAState option  
Description  
Displays all available information.  
-a|  
--all  
Displays information that is useful to debug SCAState behavior.  
Prints a thread dump for every thread.  
-debug  
-ftd|  
--full-thread-dump  
Displays the help information for the SCAState tool.  
-h|  
--help  
Specifies the file to which the heap dump is written. The file is  
interpreted relative to the remote scan’s working directory; this is  
-hd<filename> |  
--heap-dump<filename>  
Page 169 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 22: Command-line tools  
SCAState option  
Description  
not necessarily the same directory where you are running  
SCAState.  
Displays the ongoing status of a running scan. This is the default.  
If possible, this information is displayed in a separate terminal  
window.  
-liveprogress  
-nogui  
Causes the  
state information to display in the  
OpenText SAST  
current terminal window instead of in a separate window.  
Displays information about the source code being scanned,  
including how many source files and functions it contains.  
-pi|  
--program-info  
-pid <process_id>  
Specifies the currently running OpenText SAST process ID. Use  
this option if there are multiple OpenText SAST processes running  
simultaneously.  
To obtain the process ID on Windows systems:  
1. Open a command window.  
2.  
At the command prompt, type tasklist.  
A list of processes is displayed.  
3.  
Find the java.exeprocess in the list and note its PID.  
To find the process ID on Linux systems:  
l
At the command prompt, type ps aux | grep  
sourceanalyzer.  
Displays scan information up to the point at which the command is  
issued. This includes the elapsed time, the current phase of the  
analysis, and the number of results already obtained.  
-progress  
Displays configuration settings (this does not include sensitive  
information such as passwords).  
-properties  
-scaversion  
Displays the OpenText SAST version number for the  
sourceanalyzer that is currently running.  
Prints a thread dump for the main scanning thread.  
-td|  
--thread-dump  
Displays information from the timers and counters that are  
-timers  
Page 170 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 22: Command-line tools  
SCAState option  
Description  
instrumented in OpenText SAST.  
Displays the SCAState version.  
-version  
-vminfo  
Displays the following statistics that JVM standard MXBeans  
provides: ClassLoadingMXBean, CompilationMXBean,  
GarbageCollectorMXBeans, MemoryMXBean,  
OperatingSystemMXBean, RuntimeMXBean, and ThreadMXBean.  
<none>  
Displays scan progress information (this is the same as -  
progress).  
Note: OpenText SAST writes Java process information to the location of the TMP system  
environment variable. On Windows systems, the TMP system environment variable location is  
C:\Users\<username>\AppData\Local\Temp. If you change this TMP system environment  
variable to point to a different location, SCAState cannot locate the sourceanalyzerJava  
process and does not return the expected results. To resolve this issue, change the TMP system  
environment variable to match the new TMP location. OpenText recommends that you run  
SCAState as an administrator on Windows.  
Page 171 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
Chapter 23: Improving performance  
This chapter provides guidelines and tips to optimize memory usage and performance when  
analyzing different types of codebases with OpenText SAST.  
This section contains the following topics:  
Antivirus software  
172  
172  
173  
174  
176  
176  
177  
181  
Tuning options  
Quick scan  
Configuring scan speed with speed dial  
Breaking down codebases  
Limiting analyzers and languages  
Optimizing FPR files  
Monitoring long running scans  
Antivirus software  
The use of antivirus software can negatively impact OpenText SAST performance. If you notice long  
scan times, OpenText recommends that you temporarily exclude the internal OpenText SAST files  
from your antivirus software scan. You can also do the same for the directories where the source code  
resides, however the performance impact on the analysis is less than with the internal directories.  
By default, OpenText SAST creates internal files in the following location:  
l
Windows: c:\Users\<username>\AppData\Local\Fortify\sca<version>  
l
Non-Windows: <userhome>/.fortify/sca<version>  
where <version> is the version of OpenText SAST you are using.  
Tuning options  
OpenText SAST can take a long time to process complex projects. The time is spent in different  
phases:  
l
Translation  
l
Analysis  
Page 172 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 23: Improving performance  
OpenText SAST can produce large analysis result files (FPRs), which can take a long time to audit and  
upload to Fortify Software Security Center. This is referred to as the following phase:  
l
Audit/Upload  
The following table lists tips on how to improve performance in the different time-consuming phases.  
Phase  
Option  
Description  
More information  
Translation  
Translate and scan on  
build-session different machines  
"Using mobile build sessions" on  
page 198  
-export-  
-import-  
build-session  
Analysis  
Analysis  
Run a quick scan  
"Quick scan" below  
-quick  
Set the scan precision  
"Configuring scan speed with  
speed dial" on the next page  
-scan-  
precision  
Analysis  
Scan the files related to "Breaking down codebases" on  
-bin  
a binary  
page 176  
Analysis  
Analysis  
Set maximum heap size  
-Xmx<size>M| G  
-Xss<size>M| G  
"Memory tuning" on page 184  
"Memory tuning" on page 184  
Set stack size for each  
thread  
Analysis  
Apply a filter using a  
filter file  
-filter  
<file>  
"Using filter files" on page 177  
Audit/Upload  
Analysis  
Exclude source files  
from the FPR file  
"Excluding source code from the  
FPR" on page 178  
-disable-  
source-  
bundling  
Audit/Upload  
Quick scan  
Quick scan mode provides a way to quickly scan your projects for critical- and high-priority issues.  
OpenText SAST performs the scan faster by reducing the depth of the analysis. It also applies the  
Quick View filter set. Quick scan settings are configurable. For more details about the configuration of  
quick scan mode, see "fortify-sca-quickscan.properties" on page 229.  
Quick scans are a great way to get many applications through an assessment so that you can quickly  
find issues and begin remediation. The performance improvement you get depends on the complexity  
and size of the application. Although the scan is faster than a full scan, it does not provide as robust a  
result set. OpenText recommends that you run full scans whenever possible.  
Page 173 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 23: Improving performance  
Limiters  
The depth of the OpenText SAST analysis sometimes depends on the available resources. OpenText  
SAST uses a complexity metric to trade off these resources with the number of vulnerabilities that it  
can find. Sometimes, this means giving up on a particular function when it does not look like  
OpenText SAST has enough resources available.  
OpenText SAST enables the user to control the “cutoff” point by using OpenText SAST limiter  
properties. The different analyzers have different limiters. You can run a predefined set of these  
limiters using a quick scan. See the "fortify-sca-quickscan.properties" on page 229 for descriptions of  
the limiters.  
To enable quick scan mode, use the -quickoption with -scanoption. With quick scan mode enabled,  
OpenText SAST applies the properties from the <sast_install_dir>/Core/config/fortify-  
sca-quickscan.propertiesfile, in addition to the standard <sast_install_  
dir>/Core/config/fortify-sca.propertiesfile. You can adjust the limiters that OpenText  
SAST uses by editing the fortify-sca-quickscan.propertiesfile. If you modify fortify-  
sca.properties, it also affects quick scan behavior. OpenText recommends that you do  
performance tuning in quick scan mode, and leave the full scan in the default settings to produce a  
highly accurate scan. For description of the quick scan mode properties, see "Properties files" on  
page 200.  
Using quick scan and full scan  
l
Run full scans periodically—A periodic full scan is important as it might find issues that quick  
scan mode does not detect. Run a full scan at least once per software iteration. If possible, run a full  
scan periodically when it will not interrupt the development workflow, such as on a weekend.  
l
Compare quick scan with a full scan—To evaluate the accuracy impact of a quick scan, perform a  
quick scan and a full scan on the same codebase. Open the quick scan results in Fortify Audit  
Workbench and merge it into the full scan. Group the issues by New Issue to produce a list of  
issues detected in the full scan but not in the quick scan.  
l
Quick scans and Fortify Software Security Center—To avoid overwriting the results of a full  
scan, by default Fortify Software Security Center ignores uploaded FPR files scanned in quick scan  
mode. However, you can configure a Fortify Software Security Center application version so that  
FPR files scanned in quick scan are processed. For more information, see analysis results  
processing rules in the OpenText™ Applicaton Security User Guide.  
Configuring scan speed with speed dial  
You can configure the speed and depth of the scan by specifying a precision level for the analysis  
phase. You can use these precision levels to adjust the scan time to fit for example, into a pipeline and  
quickly find a set of vulnerabilities while the developer is still working on the code. Although scans  
with the speed dial settings are faster than a full scan, it does not provide as robust a result set.  
OpenText recommends that you run full scans whenever possible.  
Page 174 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 23: Improving performance  
The precision level controls the depth and precision of the scan by associating configuration  
properties with each level. The configuration properties files for each level are in the <sast_  
install_dir>/Core/config/scalesdirectory. There is one file for each level: (level-  
<precision_level>.properties). You can modify the settings in these files to create your own  
specific precision levels.  
Notes:  
l
By default, Fortify Software Security Center blocks uploaded analysis results that were created  
with a precision level less than four. However, you can configure your Fortify Software Security  
Center application version so that uploaded audit projects scanned with these precision levels  
are processed.  
l
If you merge a speed dial scan with a full scan, this might remove issues from previous scans  
that still exist in your application (and would be detected again with a full scan).  
To specify the speed dial setting for a scan, include the -scan-precision(or -p) option in the scan  
phase as shown in the following example:  
sourceanalyzer -b MyProject -scan -scan-precision <level> -f MyResults.fpr  
Note: You cannot use the speed dial setting and the -quickoption in the same scan command.  
The following table describes the four precision levels.  
Precision  
level  
Description  
1
This is the quickest scan and is recommended to scan a few files. By default, a scan  
with this precision level disables the Buffer Analyzer, Control Flow Analyzer,  
Dataflow Analyzer, and Null Pointer Analyzer.  
2
3
By default, a scan with this precision level enables all analyzers. The scan runs  
quicker by performing with reduced limiters. This results in fewer issues detected.  
This precision level improves intermediate development scan speeds by up to 50%  
(with a reduction in reported issues). Specifically, this level improves the scan time  
for typed languages such as Java and C/C++.  
4
This is equivalent to a full scan.  
You can also specify the scan precision level with the com.fortify.sca.PrecisionLevelproperty  
in the fortify-sca.propertiesfile. For example:  
com.fortify.sca.PrecisionLevel=1  
Page 175 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 23: Improving performance  
Breaking down codebases  
It is more efficient to break down large projects into independent modules. For example, if you have a  
portal application that consists of several modules that are independent of each other or have few  
interactions, you can translate and scan the modules separately. The caveat to this is that you might  
lose dataflow issue detection if some interactions exist.  
For C/C++, you might reduce the scan time by using the –binoption with the –scanoption. You need  
to pass the binary file as the parameter (such as -bin <filename>.exe -scanor -bin  
<filename>.dll -scan). OpenText SAST finds the related files associated with the binary and  
scans them. This is useful if you have several binaries in a makefile.  
The following table lists some useful OpenText SAST command-line options to break down  
codebases.  
Option  
Description  
Specifies a subset of source files to scan. Only the source files that were  
linked in the named binary at build time are included in the scan. You can  
use this option multiple times to specify the inclusion of multiple binaries  
in the scan.  
-bin <binary>  
Displays all objects that were created but not used in the production of  
any other binaries. If fully integrated into the build, it lists all the binaries  
produced.  
-show-binaries  
-show-build-tree  
When used with the -binoption, displays all files used to create the  
binary and all files used to create those files in a tree layout. If the -bin  
option is not present, OpenText SAST displays the tree for each binary.  
Limiting analyzers and languages  
Occasionally, you might find that a significant amount of the scan time is spent either running one  
analyzer or analyzing a particular language. It is possible that this analyzer or language is not  
important to your security requirements. You can limit the specific analyzers that run and the specific  
languages that OpenText SAST translates.  
Disabling analyzers  
To disable specific analyzers, include the -analyzersoption to OpenText SAST at scan time with a  
comma- or colon-separated list of analyzers to enable. The valid parameter values for the -  
analyzersoption are buffer, content, configuration, controlflow, dataflow, nullptr,  
semantic, and structural.  
Page 176 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Chapter 23: Improving performance  
For example, to run a scan that only includes the Dataflow, Control Flow, and Buffer analyzers, use the  
following scan command:  
sourceanalyzer -b MyProject -analyzers dataflow:controlflow:buffer -scan -f  
MyResults.fpr  
You can also do the same thing by setting com.fortify.sca.DefaultAnalyzersin the OpenText  
SAST property file <sast_install_dir>/Core/config/fortify-sca.properties. For example,  
to achieve the equivalent of the previous scan command, set the following in the properties file:  
com.fortify.sca.DefaultAnalyzers=dataflow:controlflow:buffer  
Disabling languages  
To disable specific languages, include the -disable-languageoption in the translation phase,  
which specifies a list of languages that you want to exclude. The valid language values are abap,  
actionscript, apex, cfml, cobol, configuration, cpp, dart, dotnet, golang, objc, php,  
python, ruby, swift, and vb.  
For example, to perform a translation that excludes configuration and PHP files, use the following  
command:  
sourceanalyzer -b MyProject <src_files> -disable-language configuration:php  
You can also disable languages by setting the com.fortify.sca.DISabledLanguagesproperty in  
the OpenText SAST properties file <sast_install_dir>/Core/config/fortify-  
sca.properties. For example, to achieve the equivalent of the previous translation command, set  
the following in the properties file:  
com.fortify.sca.DISabledLanguages=configuration:php  
For languages that are not available with the -disable-language, use the -excludeoption. For  
more information, see "Translation options" on page 151.  
Optimizing FPR files  
This chapter describes how to handle performance issues related to the audit results (FPR) file. These  
topics describe how to reduce the scan time, reduce FPR file size, and tips for opening large FPR files.  
Using filter files  
You can use a file to filter out specific vulnerability instances, rules, and vulnerability categories from  
the analysis results. If you determine that a certain issue category or rule is not relevant for a  
particular scan, you can stop OpenText SAST from adding them to the FPR. Using a filter file can  
reduce both the scan time and analysis results file size.  
Page 177 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 23: Improving performance  
For example, if you scan a simple program that just reads a specified file, you might not want to see  
path manipulation issues, because these are not likely planned as part of the functionality. To filter  
out path manipulation issues, create a file that contains a single line:  
Path Manipulation  
Save this file as filter.txt. Use the -filteroption in the analysis phase as shown in the following  
example:  
sourceanalyzer -b MyProject -scan -filter filter.txt -f MyResults.fpr  
The analysis output in MyResults.fprdoes not include any issues with the category Path  
Manipulation. For more information and an example of a filter file, see "Excluding issues with filter  
files" on page 192.  
Using filter sets  
Filters in an issue template determine how the results from OpenText SAST are shown. In addition to  
filters, filter sets enable you to have a selection of filters used at any one time. Each FPR has an issue  
template associated with it. You can use filter sets to reduce the number of issues based on  
conditions you specify with filters in an issue template. This can dramatically reduce the size of an  
FPR.  
To do this, use Fortify Audit Workbench to create a filter in a filter set, and then run the OpenText  
SAST scan with the filter set and the containing issue template. For more information and a basic  
example of how to create a filter set, see "Using filter sets to exclude issues" on page 196.  
Note: Although filtering issues with a filter set can reduce the size of the FPR, they do not usually  
reduce the scan time. OpenText SAST examines the filter set after it calculates the issues to  
determine whether to write them to the FPR file. The filters in a filter set determine the rule types  
that OpenText SAST loads.  
Excluding source code from the FPR  
You can reduce the size of the FPR file by excluding the source code information from the FPR. This is  
especially valuable for large source files or codebases. Typically, you do not get a scan time reduction  
for small source files using this method.  
There are properties you can use to prevent OpenText SAST from including source code in the FPR.  
You can set either property in the <sast_install_dir>/Core/config/fortify-  
sca.propertiesfile or specify an option on the command line. The following table describes these  
settings.  
Property name  
Description  
Excludes source code from the FPR.  
com.fortify.sca.  
FPRDisableSourceBundling=true  
Page 178 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 23: Improving performance  
Property name  
Description  
Command-Line Option:  
-disable-source-bundling  
Excludes code snippets from the FPR.  
com.fortify.sca.  
FVDLDisableSnippets=true  
Command-Line Option:  
–fvdl-no-snippets  
The following command-line example uses both options to exclude both the source code and code  
snippets from the FPR:  
sourceanalyzer -b MyProject -disable-source-bundling  
-fvdl-no-snippets -scan -f MySourcelessResults.fpr  
Reducing the FPR file size  
There are a few ways to reduce the size of FPR files. The quickest way to do this without affecting  
results is to exclude the source code from the FPR as described in "Excluding source code from the  
FPR" on the previous page. You can also reduce the size of a merged FPR with the FPRUtility (see the  
OpenText™ Application Security Tools Guide).  
There are a few other properties that you can use to select what is excluded from the FPR. You can  
set these properties in the <sast_install_dir>/Core/config/fortify-sca.propertiesfile or  
specify an option on the command line for the analysis (scan) phase.  
Property name  
Description  
Excludes the metatable from the FPR. Fortify Audit  
Workbench uses the metatable to map information  
in Functions view.  
com.fortify.sca.  
FPRDisableMetatable  
=true  
Command-Line Option:  
-disable-metatable  
com.fortify.sca.  
FVDLDisableDescriptions  
=true  
Excludes rule descriptions from the FPR. If you do  
not use custom descriptions, the descriptions in the  
Fortify Taxonomy (https://vulncat.fortify.com) are  
used.  
Command-Line Option:  
-fvdl-no-descriptions  
Excludes engine data from the FPR. This is useful if  
your FPR contains many warnings when you open  
the file in Fortify Audit Workbench.  
com.fortify.sca.  
FVDLDisableEngineData  
=true  
Page 179 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 23: Improving performance  
Property name  
Description  
Command-Line Option:  
-fvdl-no-enginedata  
Note: If you exclude engine data from the FPR,  
you must merge the FPR with the current audit  
project locally before you upload it to Fortify  
Software Security Center. Fortify Software  
Security Center cannot merge it on the server  
because the FPR does not contain the  
OpenText SAST version.  
Excludes the program data from the FPR. This  
removes the Taint Sources information from the  
Functions view in Fortify Audit Workbench. This  
property typically only has a minimal effect on the  
overall size of the FPR file.  
com.fortify.sca.  
FVDLDisableProgramData  
=true  
Command-Line Option:  
-fvdl-no-progdata  
Opening large FPR files  
To reduce the time required to open a large FPR file in Fortify Audit Workbench, you can set some  
properties in the <sast_install_dir>/Core/config/fortify.propertiesfile. For more  
information about these properties, see the OpenText™ Application Security Tools Guide. The  
following table describes the properties you can use to reduce the time to open large FPR files.  
Property name  
Description  
Disables use of the code navigation features  
in Fortify Audit Workbench.  
com.fortify.  
model.DisableProgramInfo=true  
Sets the start and end index for issue cutoff.  
com.fortify.  
model.IssueCutoffStartIndex  
=<num> (inclusive)  
The IssueCutoffStartIndexproperty is  
inclusive and IssueCutoffEndIndexis  
exclusive so that you can specify a subset of  
issues you want to see. For example, to see  
the first 100 issues, specify the following:  
com.fortify.  
model.IssueCutoffEndIndex  
=<num> (exclusive)  
com.fortify.model.  
IssueCutoffStartIndex=0  
com.fortify.model.  
IssueCutoffEndIndex=101  
Because the IssueCutoffStartIndexis 0  
Page 180 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Chapter 23: Improving performance  
Property name  
Description  
by default, you do not need to specify this  
property.  
Sets the start index for issue cutoff by  
category. These two properties are similar to  
the previous cutoff properties except these  
are specified for each category. For example,  
to see the first five issues for every category,  
specify the following:  
com.fortify.  
model.IssueCutoffByCategoryStartIndex=  
<num> (inclusive)  
com.fortify.  
model.IssueCutoffByCategoryEndIndex=  
<num> (exclusive)  
com.fortify.model.  
IssueCutoffByCategoryEndIndex=6  
Minimizes the data loaded from the FPR. This  
also restricts usage of the Functions view and  
might prevent Fortify Audit Workbench from  
loading the source from the FPR.  
com.fortify.  
model.MinimalLoad=true  
Specifies the number of OpenText SAST  
reported warnings to load from the FPR. For  
projects with many scan warnings, reducing  
this number from a default of 3000 can  
speed up the load time of large FPR files.  
com.fortify.  
model.MaxEngineErrorCount=  
<num>  
Specifies the JVM heap memory size for  
Fortify Audit Workbench to start external  
command-line tools such as iidmigrator and  
fortifyupdate.  
com.fortify.  
model.ExecMemorySetting  
Monitoring long running scans  
When you run OpenText SAST, large and complex scans can often take a long time to complete.  
During the scan it is not always clear what is happening. While OpenText recommends that you  
provide your debug logs to the Customer Support team, there are a couple of ways to see what  
OpenText SAST is doing and how it is performing in real-time.  
Using the SCAState tool  
The SCAState command-line tool enables you to see up-to-date state analysis information during the  
analysis phase. The SCAState tool is located in the <sast_install_dir>/bindirectory. In addition  
Page 181 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 23: Improving performance  
to a live view of the analysis, it also provides a set of timers and counters that show where OpenText  
SAST spends its time during the analysis phase. For more information about how to use SCAState, see  
the "Checking the scan status with SCAState" on page 169.  
Using JMX tools  
You can use tools to monitor OpenText SAST with JMX technology. These tools can provide a way to  
track OpenText SAST performance over time. For more information about these tools, see the Oracle®  
documentation.  
Note: These are third-party tools and OpenText does not provide or support them.  
Using JConsole  
JConsole is an interactive monitoring tool that complies with the JMX specification. The disadvantage  
of JConsole is that you cannot save the output.  
To use JConsole, you must first set some additional JVM parameters. Set the following environment  
variable:  
export SCA_VM_OPTS="-Dcom.sun.management.jmxremote  
-Dcom.sun.management.jmxremote.port=9090  
-Dcom.sun.management.jmxremote.ssl=false  
-Dcom.sun.management.jmxremote.authenticate=false"  
After the JMX parameters are set, start a scan. During the scan, start JConsole to monitor OpenText  
SAST locally or remotely with the following command:  
jconsole <host_name>:9090  
Using Java VisualVM  
Java VisualVM offers the same capabilities as JConsole. It also provides more detailed information on  
the JVM and enables you to save the monitor information to an application snapshot file. You can  
store these files and open them later with Java VisualVM.  
Similar to JConsole, before you can use Java VisualVM, you must set the same JVM parameters  
described in "Using JConsole" above.  
After the JVM parameters are set, start the scan. You can then start Java VisualVM to monitor the  
scan either locally or remotely with the following command:  
jvisualvm <host_name>:9090  
Page 182 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
Chapter 24: Troubleshooting  
This section contains the following topics:  
Exit codes  
183  
184  
186  
188  
189  
189  
191  
Memory tuning  
Scanning complex functions  
Issue non-determinism  
Locating the log files  
Configuring log files  
Reporting issues and requesting enhancements  
Exit codes  
The following table describes the possible OpenText SAST exit codes.  
Exit  
code Description  
0
1
2
Success  
Generic failure  
Invalid input files  
(this might indicate that an attempt was made to translate a file that has an extension  
that OpenText SAST does not support)  
3
4
Process timed out  
Analysis completed with numbered warning messages written to the console and/or to  
the log file  
5
Analysis completed with numbered error messages written to the console and/or to the  
log file  
6
7
Scan phase was unable to generate issue results  
Unable to detect a valid license or the LIM license expired at run time  
By default, OpenText SAST only returns exit codes 0, 1, 2, 3, or 7.  
OpenText™ Static Application Security Testing (25.2.0)  
Page 183 of 244  
 
 
User Guide  
Chapter 24: Troubleshooting  
You can extend the default exit code options by setting the com.fortify.sca.ExitCodeLevel  
property in the <sast_install_dir>/Core/Config/fortify-sca.propertiesfile.  
The valid values are:  
l
nothing—Returns any of the default exit codes (0, 1, 2, 3, or 7).  
l
warnings—Returns exit codes 4 and 5 in addition to the default exit codes.  
l
errors—Returns exit code 5 in addition to the default exit codes.  
l
no_output_file—Returns exit code 6 in addition to the default exit codes.  
Memory tuning  
The amount of physical RAM required for a scan depends on the complexity of the code. By default,  
OpenText SAST automatically allocates the memory it uses based on the physical memory available  
on the system. This is generally sufficient. As described in "Output options" on page 156, you can  
adjust the Java heap size with the -Xmx command-line option.  
This section describes suggestions for what you can do if you encounter OutOfMemory errors during  
the analysis.  
Note: You can set the memory allocation options discussed in this section to run for all scans by  
setting the SCA_VM_OPTSenvironment variable.  
Java heap exhaustion  
Java heap exhaustion is the most common memory problem that might occur during OpenText SAST  
scans. It is caused by allocating too little heap space to the Java virtual machine that OpenText SAST  
uses to scan the code. You can identify Java heap exhaustion from the following symptom.  
Symptom  
One or more of these messages appears in the OpenText SAST log file and in the command-line  
output:  
There is not enough memory available to complete analysis. For details on  
making more memory available, please consult the user manual.  
java.lang.OutOfMemoryError: Java heap space  
java.lang.OutOfMemoryError: GC overhead limit exceeded  
Resolution  
To resolve a Java heap exhaustion problem, allocate more heap space to the OpenText SAST Java  
virtual machine when you start the scan. To increase the heap size, use the -Xmxcommand-line  
option when you run the OpenText SAST scan. For example, -Xmx1Gmakes 1 GB available. Before  
you use this parameter, determine the maximum allowable value for Java heap space. The maximum  
value depends on the available physical memory.  
Page 184 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 24: Troubleshooting  
Heap sizes between 32 GB and 48 GB are not advised due to internal JVM implementations. Heap  
sizes in this range perform worse than at 32 GB. Heap sizes smaller than 32 GB are optimized by the  
JVM. If your scan requires more than 32 GB, then you need 64 GB or more. As a guideline, assuming  
no other memory intensive processes are running, do not allocate more than 2/3 of the available  
memory.  
If the system is dedicated to running OpenText SAST, you do not need to change it. However, if the  
system resources are shared with other memory-intensive processes, subtract an allowance for those  
other processes.  
Note: You do not need to account for other resident but not active processes (while OpenText  
SAST is running) that the operating system might swap to disk. Allocating more physical memory  
to OpenText SAST than is available in the environment might cause “thrashing,” which typically  
slows down the scan along with everything else on the system.  
Native heap exhaustion  
Native heap exhaustion is a rare scenario where the Java virtual machine can allocate the Java  
memory regions on startup, but is left with so few resources for its native operations (such as garbage  
collection) that it eventually encounters a fatal memory allocation failure that immediately terminates  
the process.  
Symptom  
You can identify native heap exhaustion by abnormal termination of the OpenText SAST process and  
the following output on the command line:  
# A fatal error has been detected by the Java Runtime Environment:  
#
# java.lang.OutOfMemoryError: requested ... bytes for GrET ...  
Because this is a fatal Java virtual machine error, it is usually accompanied by an error log created in  
the working directory with the file name hs_err_pidNNN.log.  
Resolution  
Because the problem is a result of overcrowding within the process, the resolution is to reduce the  
amount of memory used for the Java memory regions (Java heap). Reducing this value should reduce  
the crowding problem and allow the scan to complete successfully.  
Stack overflow  
Each thread in a Java application has its own stack. The stack holds return addresses,  
function/method call arguments, and so on. If a thread tends to process large structures with  
recursive algorithms, it might need a large stack for all those return addresses. With the JVM, you can  
set that size with the -Xssoption.  
Page 185 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 24: Troubleshooting  
Symptoms  
This message typically appears in the OpenText SAST log file, but might also appear in the command-  
line output:  
java.lang.StackOverflowError  
Resolution  
The default stack size is 16 MB. To increase the stack size, pass the -Xssoption to the  
sourceanalyzercommand. For example, -Xss32Mincreases the stack to 32 MB.  
Scanning complex functions  
During a scan, the Dataflow Analyzer might encounter a function for which it cannot complete the  
analysis and reports the following message:  
Function <name> is too complex for <analyzer> analysis and will be skipped  
(<identifier>)  
where:  
l
<name> is the name of the source code function  
l
<analyzer> is the name of the analyzer  
l
<identifier> is the type of complexity, which is one of the following:  
l
l: Too many distinct locations  
l
m: Out of memory  
l
s: Stack size too small  
l
t: Analysis taking too much time  
l
v: Function visits exceed the limit  
The depth of analysis OpenText SAST performs sometimes depends on the available resources.  
OpenText SAST uses a complexity metric to trade off these resources against the number of  
vulnerabilities that it can find. Sometimes, this means giving up on a particular function when  
OpenText SAST does not have enough resources available. This is normally when you see the  
"Function too complex" messages.  
When you see this message, it does not necessarily mean that OpenText SAST completely ignored  
the function in the program. For example, the Dataflow Analyzer typically visits a function many times  
before completing the analysis, and might not have run into this complexity limit in the previous visits.  
In this case, the results include everything learned from the previous visits.  
You can control the "give up" point using OpenText SAST properties called limiters. Different  
analyzers have different limiters.  
The following sections provide a discussion of a resolution for this issue.  
Page 186 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 24: Troubleshooting  
Dataflow Analyzer limiters  
There are three types of complexity identifiers for the Dataflow Analyzer:  
l
l: Too many distinct locations  
l
m: Out of memory  
l
s: Stack size too small  
l
v: Function visits exceed the limit  
To resolve the issue identified by s, increase the stack size for by setting -Xssto a value greater than  
16 MB.  
To resolve the complexity identifier of m, increase the physical memory for OpenText SAST.  
To resolve the complexity identifier of l, you can adjust the following limiters in the OpenText SAST  
property file <sast_install_dir>/Core/config/fortify-sca.propertiesor on the command  
line.  
Property name  
Default value  
1000  
com.fortify.sca.  
limiters.MaxTaintDefForVar  
4000  
4
com.fortify.sca.  
limiters.MaxTaintDefForVarAbort  
com.fortify.sca.  
limiters.MaxFieldDepth  
The MaxTaintDefForVarlimiter is a dimensionless value expressing the complexity of a function,  
while MaxTaintDefForVarAbortis the upper bound for it. Use the MaxFieldDepthlimiter to  
measure the precision when the Dataflow Analyzer analyzes any given object. OpenText SAST always  
tries to analyze objects at the highest precision possible.  
If a given function exceeds the MaxTaintDefForVarlimit at a given precision, the Dataflow Analyzer  
analyzes that function with lower precision (by reducing the MaxFieldDepthlimiter). When you  
reduce the precision, it reduces the complexity of the analysis. When the precision cannot be reduced  
any further, OpenText SAST then proceeds with analysis at the lowest precision until either it finishes,  
or the complexity exceeds the MaxTaintDefForVarAbortlimiter. In other words, OpenText SAST  
tries harder at the lowest precision to get at least some results from the function. If OpenText SAST  
reaches the MaxTaintDefForVarAbortlimiter, it gives up on the function entirely and you get the  
"Function too complex" warning.  
To resolve the complexity identifier of v, you can adjust the property  
com.fortify.sca.limiters.MaxFunctionVisits. This property sets the maximum number of  
times the taint propagation analyzer visits functions. The default is 50.  
Page 187 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 24: Troubleshooting  
Control Flow and Null Pointer analyzer limiters  
There are two types of complexity identifiers for both Control Flow and Null Pointer analyzers:  
l
m: Out of memory  
l
t: Analysis taking too much time  
Due to the way that the Dataflow Analyzer handles function complexity, it does not take an indefinite  
amount of time. Control Flow and Null Pointer analyzers, however, can take an exceptionally long time  
when analyzing complex functions. Therefore, OpenText SAST provides a way to abort the analysis  
when this happens, and then you get the "Function too complex" message with a complexity identifier  
of t.  
To change the maximum amount of time these analyzers spend to analyze functions, you can adjust  
the following property values in the OpenText SAST property file <sast_install_  
dir>/Core/config/fortify-sca.propertiesor on the command line.  
Default  
Property name  
Description  
value  
Sets the time limit (in milliseconds) for Control  
Flow analysis on a single function.  
600000  
(10  
com.fortify.sca.  
CtrlflowMaxFunctionTime  
minutes)  
Sets the time limit (in milliseconds) for Null  
Pointer analysis on a single function.  
300000  
(5 minutes)  
com.fortify.sca.  
NullPtrMaxFunctionTime  
To resolve the complexity identifier of m, increase the physical memory for OpenText SAST.  
Note: If you increase these limiters or time settings, it makes the analysis of complex functions  
take longer. It is difficult to characterize the exact performance implications of a particular value  
for the limiters/time, because it depends on the specific function in question. If you never want to  
see the "Function too complex" warning, you can set the limiters/time to an extremely high value,  
however it can cause unacceptable scan time.  
Issue non-determinism  
Running in parallel analysis mode might introduce issue non-determinism. If you experience any  
problems, contact Customer Support, and disable parallel analysis mode. Disabling parallel analysis  
mode results in sequential analysis, which can be substantially slower but provides deterministic  
results across multiple scans.  
Page 188 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 24: Troubleshooting  
To disable parallel analysis mode:  
1.  
2.  
Open the fortify-sca.propertiesfile located in the <sast_install_dir>/Core/config  
directory in a text editor.  
Change the value for the com.fortify.sca.MultithreadedAnalysisproperty to false.  
com.fortify.sca.MultithreadedAnalysis=false  
Locating the log files  
By default, OpenText SAST creates log files in the following location:  
l
Windows: C:\Users\<username>\AppData\Local\Fortify\sca<version>\log  
l
Non-Windows: <userhome>/.fortify/sca<version>/log  
where <version> is the version of OpenText SAST that you are using.  
The following table describes the OpenText SAST default log files.  
File names  
Description  
The standard log provides a log of informational  
messages, warnings, and errors that occurred in the run of  
sourceanalyzer.  
sca.log  
scaX.log  
The OpenText SAST Support log provides:  
sca_FortifySupport.log  
scaX_FortifySupport.log  
l
The same log messages as the standard log file, but  
with additional details  
l
Additional detailed messages that are not included in  
the standard log file  
This log file is helpful to Customer Support or the  
development team to troubleshoot any issues.  
To specify a log file on the command line, see "Other options" on page 159.  
If you encounter warnings or errors that you cannot resolve, provide the OpenText SAST Support log  
file to Customer Support.  
Configuring log files  
You can configure the information that OpenText SAST writes to the log files by setting logging  
properties (see "Logging properties" on page 227). You can configure the following log file settings:  
Page 189 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Chapter 24: Troubleshooting  
l
The location and name of the log file  
Property: com.fortify.sca.LogFile  
l
Log level (see "Understanding log levels" below)  
Property: com.fortify.sca.LogLevel  
l
Whether to overwrite the log files for each run of sourceanalyzer  
Property: com.fortify.sca.ClobberLogFile  
Command-line option: -clobber-log  
Understanding log levels  
The log level you select gives you all log messages equal to and greater than it. The following table  
lists the log levels in order from least to greatest. For example, the default log level of INFO includes  
log messages with the following levels: INFO, WARN, ERROR, and FATAL. You can set the log level  
with the com.fortify.sca.LogLevelproperty in the <sast_install_  
dir>/Core/config/fortify-sca.propertiesfile or on the command-line using the -Doption.  
Log level Description  
DEBUG  
Includes information that Customer Support or the development team can use  
to troubleshoot an issue  
INFO  
Basic information about the translation or scan process  
WARN  
Information about issues where the translation or scan did not stop, but might require  
your attention for accurate results  
ERROR  
FATAL  
Information about an issue that might require attention  
Information about an error that caused the translation or scan to abort  
Page 190 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Chapter 24: Troubleshooting  
Reporting issues and requesting enhancements  
Feedback is critical to the success of this product. To request enhancements or patches, or to report  
issues, visit Customer Support at https://www.microfocus.com/support.  
Include the following information when you contact customer support:  
l
Product: OpenText SAST  
l
Version number of OpenText SAST and any independent OpenText SAST modules: To determine  
the version numbers, run the following:  
sourceanalyzer -version  
l
Platform: (for example, Red Hat Enterprise Linux <version>)  
l
Operating system: (such as Linux)  
To request an enhancement, include a description of the feature enhancement.  
To report an issue, provide enough detail so that support can duplicate the issue. The more  
descriptive you are, the faster support can analyze and resolve the issue. Also include the log files, or  
the relevant portions of them, from when the issue occurred.  
Page 191 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
Appendix A: Filtering the analysis  
This section describes two methods of filtering out vulnerabilities from the analysis results (FPR)  
during the scan phase. You can use a filter file to remove issues based on specific vulnerability  
instances, rules, and vulnerability categories. You can also use a filter set (created in Fortify Audit  
Workbench) to remove issues that are hidden from view in an issue template.  
Caution! OpenText recommends that you only use filter files if you are an advanced user. Do not  
use filter files for standard audits, because auditors typically want to see and evaluate all issues  
that OpenText SAST finds.  
This section contains the following topics:  
Excluding issues with filter files  
Using filter sets to exclude issues  
192  
196  
Excluding issues with filter files  
You can create a file to filter out particular vulnerability instances, rules, and vulnerability categories  
when you run the sourceanalyzercommand. You specify the file with the -filteranalysis option.  
A filter file is a text file that you can create with any text editor. You specify only the filter items that  
you do not want in this file.  
Note: The filter types described in this section apply to both filter files and scan policy files (see  
"Applying a scan policy to the analysis" on page 64).  
The following table lists the available filter types and provides examples for each.  
Filter type  
Notes  
Examples  
Category  
A category only covers all  
subcategories  
Poor Error Handling  
J2EE Bad Practices: Leftover  
Debug Code  
Note: OpenText SAST applies  
category filters in the  
initialization phase before any  
analysis has taken place.  
Instance ID  
An instance ID of a specific issue  
6291C6A33303ED270C269917AA8A1005  
Note: OpenText SAST applies  
Page 192 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Appendix A: Filtering the analysis  
Filter type  
Notes  
instance ID filters after the  
Examples  
analysis phase.  
Rule ID  
A rule ID that leads to the reporting  
of a specific issue  
823FE039-A7FE-4AAD-B976-  
9EC53FFE4A59  
Note: OpenText SAST applies  
rule ID filters in the initialization  
phase before any analysis has  
taken place.  
1
Priority  
The priority values in ascending  
priority <= low  
order are low, medium, high, and  
critical.  
priority < medium  
Taint flags  
Enclose taint flag expressions in  
(SYSTEMINFO || EXCEPTIONINFO)  
(WEB || (DATABASE && PRIVATE))  
(NETWORK && !XSS)  
parentheses. Use the logical &&, ||,  
and !operators to specify an  
expression. For a list of taint flags,  
see OpenText™ Static Application  
Security Testing Custom Rules  
Guide.  
1
Impact  
impact < 0.5  
1
Likelihood  
likelihood <= 1.5  
confidence < 1.8  
probability <= 1.2  
accuracy <= 1.0  
1
Confidence  
1
Probability  
1
Accuracy  
1
For the priority and metadata filters, use less than (<) or less than or equal to (<=).  
See also  
"Filter file example" on the next page  
Page 193 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix A: Filtering the analysis  
Filter file example  
As an example, the following output is from a scan of the EightBall.javasample. This sample  
project is included in the OpenText_SAST_Fortify_Samples_<version>.ziparchive in the  
basic/eightballdirectory.  
The following commands are executed to produce the analysis results:  
sourceanalyzer -b eightball EightBall.java  
sourceanalyzer -b eightball -scan  
Page 194 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix A: Filtering the analysis  
The following results show five detected issues:  
[F7A138CDE5235351F6A4405BA4AD7C53 : low : Unchecked Return Value : semantic  
]
EightBall.java(12) : Reader.read()  
[6291C6A33303ED270C269917AA8A1005 : high : Path Manipulation : dataflow ]  
EightBall.java(12) : ->new FileReader(0)  
EightBall.java(8) : <=> (filename)  
EightBall.java(8) : <->Integer.parseInt(0->return)  
EightBall.java(6) : <=> (filename)  
EightBall.java(4) : ->EightBall.main(0)  
[176CC0B182267DD538992E87EF41815F : critical : Path Manipulation : dataflow  
]
EightBall.java(12) : ->new FileReader(0)  
EightBall.java(6) : <=> (filename)  
EightBall.java(4) : ->EightBall.main(0)  
[E4B3ACF92911ED6D98AAC15876739EC7 : high : Unreleased Resource : Streams :  
controlflow ]  
EightBall.java(12) : start -> loaded : new FileReader(...)  
EightBall.java(14) : loaded -> end_of_scope : end scope : Resource  
leaked  
EightBall.java(12) : start -> loaded : new FileReader(...)  
EightBall.java(12) : java.io.IOException thrown  
EightBall.java(12) : loaded -> loaded : throw  
EightBall.java(12) : loaded -> end_of_scope : end scope : Resource  
leaked : java.io.IOException thrown  
[BB9F74FFA0FF75C9921D0093A0665BEB : low : J2EE Bad Practices : Leftover  
Debug Code : structural ]  
EightBall.java(4)  
The following is an example filter file that performs the following:  
l
Remove all results related to the J2EE Bad Practice category  
l
Remove the Path Manipulation based on its instance ID  
l
Remove any dataflow issues that were generated from a specific rule ID  
#This is a category to filter from scan output  
J2EE Bad Practices  
Page 195 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix A: Filtering the analysis  
#This is an instance ID of a specific issue to be filtered  
#from scan output  
6291C6A33303ED270C269917AA8A1005  
#This is a specific Rule ID that leads to the reporting of a  
#specific issue in the scan output: in this case the  
#dataflow sink for a Path Manipulation issue.  
823FE039-A7FE-4AAD-B976-9EC53FFE4A59  
To test the filtered output, copy the above text and paste it into a file with the name test_  
filter.txt.  
To apply the filtering in the test_filter.txtfile, execute the following command:  
sourceanalyzer -b eightball -scan -filter test_filter.txt  
The filtered analysis produces the following results:  
[176CC0B182267DD538992E87EF41815F : critical : Path Manipulation : dataflow  
]
EightBall.java(12) : ->new FileReader(0)  
EightBall.java(6) : <=> (filename)  
EightBall.java(4) : ->EightBall.main(0)  
[E4B3ACF92911ED6D98AAC15876739EC7 : high : Unreleased Resource : Streams :  
controlflow ]  
EightBall.java(12) : start -> loaded : new FileReader(...)  
EightBall.java(14) : loaded -> end_of_scope : end scope : Resource  
leaked  
EightBall.java(12) : start -> loaded : new FileReader(...)  
EightBall.java(12) : java.io.IOException thrown  
EightBall.java(12) : loaded -> loaded : throw  
EightBall.java(12) : loaded -> end_of_scope : end scope : Resource  
leaked : java.io.IOException thrown  
Using filter sets to exclude issues  
You can use filter sets in an issue template created in Fortify Audit Workbench to filter issues from  
the analysis results. When you apply a filter set that hides issues from view during the analysis phase,  
OpenText SAST does not write the hidden issues to the FPR. To do this, use Fortify Audit Workbench  
to create a filter set, and then run the OpenText SAST scan with the filter set and the issue template,  
Page 196 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix A: Filtering the analysis  
which contains the filter set. For more detailed instructions about how to create filters and filter sets  
in Fortify Audit Workbench, see the OpenText™ Fortify Audit Workbench User Guide.  
The following example describes the basic steps for how to create and use a filter in an issue template  
to remove issues from an FPR:  
1. Suppose you use OWASP Top 10 2021, and you only want to see issues categorized within this  
standard. In Fortify Audit Workbench, create a new filter set called OWASP_Filter  
2.  
In Fortify Audit Workbench, create a visibility filter in the OWASP_Filterfilter set:  
If [OWASP Top 10 2021] does not contain A Then hide issue  
This filter looks through the issues and if an issue does not map to an OWASP Top 10 2021  
category with ‘A’ in the name, then it hides it. Because all OWASP Top 10 2021 categories start  
with ‘A’ (A01, A02, …, A10), then any category without the letter ‘A’ is not in the OWASP Top 10  
2021. The filter hides the issues from view in Fortify Audit Workbench, but they are still in the  
FPR.  
3.  
In Fortify Audit Workbench, export the issue template to a file called IssueTemplate.xml.  
4. Using OpenText SAST, specify the filter set in the analysis phase with the following command:  
sourceanalyzer -b MyProject -scan -project-template IssueTemplate.xml  
-Dcom.fortify.sca.FilterSet=OWASP_Filter -f MyFilteredResults.fpr  
Although filtering issues with a filter set can reduce the size of the FPR, it does not usually reduce the  
scan time. OpenText SAST examines the filter set after it calculates the issues to determine whether  
to write them to the FPR file. The filters in a filter set determine the rule types that OpenText SAST  
loads.  
Page 197 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
Appendix B: Using mobile build sessions  
With an OpenText SAST mobile build session (MBS), you can translate a project on one machine and  
scan it on another. A mobile build session (MBS file) includes all the files needed for the analysis phase  
including the source code. To improve scan time, you can perform the translation on the build  
computer, and then use a better equipped computer for the scan by doing either of the following:  
l
Use Fortify ScanCentral SAST client to move the MBS to sensors for analysis (see "Fortify  
ScanCentral SAST" on page 22)  
l
Move the build session (MBS file) to another computer that has an OpenText SAST installation,  
import the MBS (see "Importing a mobile build session" on the next page), and then run the  
analysis.  
Note: OpenText Core Application Security (Fortify on Demand) users can generate an MBS file to  
package translated code for uploading some languages.  
You must have the same version of Fortify Software Security Content (Rulepacks) installed on both  
the system where you perform the translation and the system where you perform the analysis.  
This section contains the following topics:  
Mobile build session version compatibility  
Creating a mobile build session  
198  
199  
199  
Importing a mobile build session  
Mobile build session version compatibility  
The OpenText SAST version on the translate machine must be compatible with the OpenText SAST  
version on the analysis machine. The version number format is <major>.<minor>.<patch>.<build_  
number> (for example, 25.2.0.0140). The <major> and <minor> portions of the OpenText SAST  
version numbers on both the translation and the analysis machines must match. For example, 25.2.0  
and 25.2.x are compatible. To determine the OpenText SAST version number, type sourceanalyzer  
-von the command line.  
You can obtain the build ID and the OpenText SAST version from an MBS file with the following  
command:  
sourceanalyzer -import-build-session <file>.mbs  
-Dcom.fortify.sca.ExtractMobileInfo=true  
Page 198 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Appendix B: Using mobile build sessions  
Creating a mobile build session  
On the machine where you performed the translation, issue the following command to generate a  
mobile build session:  
sourceanalyzer -b <build_id> -export-build-session <file>.mbs  
where <file>.mbsis the file name you provide for the OpenText SAST mobile build session.  
Importing a mobile build session  
After you move the <file>.mbsfile to the machine where you want to perform the scan, you can  
import the mobile build session into the OpenText SAST project root directory.  
To import the mobile build session, type the following command:  
sourceanalyzer -import-build-session <file>.mbs  
After you import your OpenText SAST mobile build session, you can proceed to the analysis phase.  
Perform a scan with the same build ID that was used in the translation.  
You cannot merge multiple mobile build sessions into a single MBS file. Each exported build session  
must have a unique build ID. However, after all the build IDs are imported on the same OpenText  
SAST installation, you can scan multiple build IDs in one scan with the -boption (see "Analysis phase"  
on page 64).  
Page 199 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
Appendix C: Configuration options  
The OpenText SAST installer places a set of properties files on your system. Properties files contain  
configurable settings for OpenText SAST runtime analysis, output, and performance.  
This section contains the following topics:  
Properties files  
200  
fortify-sca.properties  
fortify-sca-quickscan.properties  
fortify-rules.properties  
202  
229  
232  
Properties files  
The properties files are located in the <sast_install_dir>/Core/configdirectory. The installed  
properties files contain default values. OpenText recommends that you consult with your project  
leads before you make changes to the properties in the properties files. You can modify any of the  
properties in the configuration file with any text editor. You can also specify the property on the  
command line with the -Doption.  
The following table lists the OpenText SAST properties files. Property files for the OpenText SAST  
applications and tools are described in the OpenText™ Application Security Tools Guide.  
Properties file name  
Description  
More information  
Defines the OpenText SAST configuration "fortify-sca.properties"  
fortify-  
sca.properties  
properties.  
on page 202  
Defines the configuration properties  
applicable for an OpenText SAST quick  
scan.  
"fortify-sca-  
quickscan.properties"  
fortify-sca-  
quickscan.properties  
on page 229  
Defines the configuration properties that "fortify-  
determine rule behavior. rules.properties" on  
page 232  
fortify-  
rules.properties  
Properties file format  
In the properties file, each property consists of a pair of strings: the first string is the property name  
and the second string is the property value.  
Page 200 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Appendix C: Configuration options  
com.fortify.sca.fileextensions.htm=HTML  
As shown above, the property sets the translation to use for .htmfiles. The property name is  
com.fortify.sca.fileextensions.htmand the value is set to HTML.  
Note: When you specify a path for Windows systems as the property value, you must escape any  
backslash character (\) with a backslash (for example:  
com.fortify.sca.ASPVirtualRoots.Library=C:\\WebServer\\CustomerA\\inc).  
Disabled properties are commented out of the properties file. To enable these properties, remove the  
comment symbol (#) and save the properties file. In the following example, the  
com.fortify.sca.LogFileproperty is disabled in the properties file and is not part of the  
configuration:  
# default location for the log file  
#com.fortify.sca.LogFile=${com.fortify.sca.ProjectRoot}/sca/log/sca.log  
Precedence of setting properties  
OpenText SAST uses properties settings in a specific order. You can override any previously set  
properties with the values that you specify. Keep this order in mind when making changes to the  
properties files.  
The following table lists the order of precedence for OpenText SAST properties.  
Property  
Order specification  
Description  
1
Command line Properties specified on the command line have the highest priority  
and you can specify them in any scan.  
with the -D  
option  
2
OpenText  
Note: You can specify either quick scan or a scan precision level.  
Therefore, these property settings both have second priority.  
quick  
SAST  
scan  
configuration  
file  
Properties specified in the quick scan configuration file (fortify-  
sca-quickscan.properties) have the second priority, but only if  
you include the -quickoption to enable quick scan mode.  
OpenText  
SAST scan  
precision  
Properties specified in the scan precision property files have the  
second priority, but only if you include the -scan-precisionoption  
to enable scan precision.  
property files  
Page 201 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix C: Configuration options  
Property  
Order specification  
Description  
3
OpenText  
SAST  
Properties specified in the OpenText SAST configuration file  
(fortify-sca.properties) have the lowest priority. Edit this file to  
configuration  
file  
change the property values on a more permanent basis for all scans.  
OpenText SAST also relies on some properties that have internally defined default values.  
fortify-sca.properties  
The following sections describe the properties available for use in the fortify-sca.properties  
file. See "fortify-sca-quickscan.properties" on page 229 for additional properties that you can use in  
this properties file. Each property description includes the value type, the default value, the  
equivalent command-line option (if applicable), and an example.  
Translation and analysis phase properties  
The properties for the fortify-sca.propertiesfile in the following table are general properties  
that apply to the translation and/or analysis (scan) phase.  
Property name  
Description  
Translation and scan  
Specifies the build ID of the build.  
Value type: String  
com.fortify.sca.  
BuildID  
Default: (none)  
Command-line option: -b  
com.fortify.sca.  
CmdlineOptionsFileEncod  
ing  
Specifies the encoding of the command-line options file provided with @<filename> (see  
"Other options" on page 159). You can use this property, for example, to specify Unicode  
file paths in the options file. Valid encoding names are from the  
java.nio.charset.Charset  
Note: This property is only valid in the fortify-sca.propertiesfile and does not  
work in the fortify-sca-quickscan.properitesfile or with the -Doption.  
Value type: String  
Default: JVM system default encoding  
Example: com.fortify.sca.CmdlineOptionsFileEncoding=UTF-8  
Specifies a colon-separated list of languages to exclude from the translation phase. The  
com.fortify.sca.  
DISabledLanguages  
valid language values are abap, actionscript, apex, cfml, cobol, configuration,  
Page 202 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Appendix C: Configuration options  
Property name  
Description  
cpp, dart, dotnet, golang, objc, php, python, ruby, swift, and vb.  
Value type: String  
Default: (none)  
Command-line option: -disable-language  
Specifies a colon-separated list of languages to translate. The valid language values are  
com.fortify.sca.  
EnabledLanguages  
abap, actionscript, apex, cfml, cobol, configuration, cpp, dart, dotnet, golang,  
objc, php, python, ruby, swift, and vb.  
Value type: String  
Default: All languages in the specified source are translated unless explicitly excluded  
with the com.fortify.sca.DISabledLanguagesproperty.  
Command-line option: -enable-language  
If set to true, OpenText SAST includes build script files that have the same name as a  
build tool (such as gradlew) during translation as source files.  
com.fortify.sca.  
DisableCompilerName  
Value type: Boolean  
Default: false  
Command-line option: -disable-compiler-resolution  
Specifies the directory to store intermediate files generated in the translation and analysis  
phases. OpenText SAST makes extensive use of intermediate files located in this project  
root directory. In some cases, you achieve better performance for analysis by making sure  
this directory is on local storage rather than on a network drive.  
com.fortify.sca.  
ProjectRoot  
Value type: String (path)  
Default (Windows): ${win32.LocalAppdata}/Fortify  
Note: ${win32.LocalAppdata}is a variable that points to the Windows Local  
Application Data shell folder.  
Default (non-Windows): $home/.fortify  
Command-line option: -project-root  
Example: com.fortify.sca.ProjectRoot=  
C:\Users\<username>\AppData\Local\  
Translation  
Specifies how to translate specific file name extensions of languages that do not require  
com.fortify.sca.  
fileextensions.java  
build integration. The valid extension types are ABAP, ACTIONSCRIPT, APEX, APEX_  
OBJECT, APEX_TRIGGER, ARCHIVE, ASPNET, ASP, ASPX, BITCODE, BSP, BYTECODE, CFML,  
COBOL, CSHARP, DART, DOCKERFILE, FLIGHT, GENERIC, GO, HCL, HOCON, HTML, INI, JAVA,  
JAVA_PROPERTIES, JAVASCRIPT, JINJA, JSON, JSP, JSPX, JUPYTER, KOTLIN, MSIL, MXML,  
OBJECT, PHP, PLSQL, PYTHON, RUBY, RUBY_ERB, SCALA, SWIFT, SWC, SWF, TLD, SQL, TSQL,  
TYPESCRIPT, VB, VB6, VBSCRIPT, VISUAL_FORCE, VUE, and XML, and YAML.  
com.fortify.sca.  
fileextensions.cs  
com.fortify.sca.  
fileextensions.js  
com.fortify.sca.  
fileextensions.py  
Value type: String (valid language type)  
Page 203 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
com.fortify.sca.  
fileextensions.rb  
Default: See the fortify-sca.propertiesfile for the complete list.  
Examples:  
com.fortify.sca.  
fileextensions.aspx  
com.fortify.sca.fileextensions.java=JAVA  
com.fortify.sca.fileextensions.cs=CSHARP  
com.fortify.sca.fileextensions.js=TYPESCRIPT  
com.fortify.sca.fileextensions.py=PYTHON  
com.fortify.sca.fileextensions.swift=SWIFT  
com.fortify.sca.fileextensions.razor=ASPNET  
com.fortify.sca.fileextensions.php=PHP  
com.fortify.sca.fileextensions.tf=HCL  
com.fortify.sca.  
fileextensions.php  
Note: This is a partial list.  
For the complete list, see  
the properties file.  
You can also specify a value of oracle:<path_to_script> to programmatically supply  
a language type. Provide a script that accepts one command-line parameter of a file name  
that matches the specified extension. The script must write the valid OpenText SAST file  
type (see previous list) to stdout and exit with a return value of zero. If the script returns a  
non-zero return code or the script does not exist, the file is not translated and OpenText  
SAST writes a warning to the log file.  
Example:  
com.fortify.sca.fileextensions.jsp=  
oracle:<path_to_script>  
Specifies custom-named compilers.  
com.fortify.sca.  
compilers.javac=  
com.fortify.sca.  
util.compilers.JavacCom  
piler  
Value type: String (compiler)  
Default: See the Compilers section in the fortify-sca.propertiesfile for the  
complete list.  
com.fortify.sca.  
compilers.c++=  
com.fortify.sca.  
util.compilers.GppCompi  
ler  
Example:  
To tell OpenText SAST that “my-gcc” is a gcc compiler:  
com.fortify.sca.  
compilers.my-gcc=  
com.fortify.sca.util.compilers.  
GccCompiler  
com.fortify.sca.  
compilers.make=  
com.fortify.sca.  
util.compilers.Touchles  
sCompiler  
Notes:  
l
Compiler names can begin or end with an asterisk (*), which matches zero or more  
com.fortify.sca.  
compilers.mvn=  
com.fortify.sca.  
util.compilers.MavenAda  
pter  
characters.  
l
Execution of clang/clang++ is not supported with the gcc/g++ command names.  
You can specify the following: com.fortify.sca.compilers.g++=  
com.fortify.sca.util.compilers.GppCompiler  
Note: This is a partial list.  
For the complete list,  
see the properties file.  
com.fortify.sca.  
UseAntListener  
If set to true, OpenText SAST includes com.fortify.dev.ant.SCAListenerin the  
compiler options.  
Page 204 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Value type: Boolean  
Default: false  
Specifies one or more files to exclude from translation. Separate multiple files with  
semicolons (Windows) or colons (non-Windows). See "Specifying files and directories" on  
com.fortify.sca.  
exclude  
page 163 for more information on how to use file specifiers.  
Value type: String  
Default: Not enabled  
Command-line option: -exclude  
Example: com.fortify.sca.exclude=file1.x;file2.x  
Specifies the source file encoding type. OpenText SAST allows you to scan a project that  
contains differently encoded source files. To work with a multi-encoded project, you must  
com.fortify.sca.  
InputFileEncoding  
specify the -encodingoption in the translation phase, when OpenText SAST first reads  
the source code file. OpenText SAST remembers this encoding in the build session and  
propagates it into the FVDL file.  
Typically, if you do not specify the encoding type, OpenText SAST uses file.encoding  
from the java.io.InputStreamReaderconstructor with no encoding parameter. In a  
few cases (for example with the ActionScript parser), OpenText SAST defaults to UTF-8.  
Value type: String  
Default: (none)  
Command-line option: -encoding  
Example:  
com.fortify.sca.InputFileEncoding=UTF-16  
com.fortify.sca.  
RegExecutable  
On Windows platforms, specifies the path to the reg.exesystem utility. Specify the paths  
in Windows syntax, not Cygwin syntax, even when you run OpenText SAST from within  
Cygwin. Escape backslashes with an additional backslash.  
Value type: String (path)  
Default: reg  
Example:  
com.fortify.sca.RegExecutable=  
C:\\Windows\\System32\\reg.exe  
Specifies whether the xcodebuild touchless adapter continues translation if the  
xcodebuild subprocess exited with a non-zero exit code. If set to false, translation stops  
after encountering a non-zero xcodebuild exit code and the OpenText SAST touchless  
build halts with the same exit code. If set to true, the OpenText SAST touchless build  
executes translation of the build file identified prior to the xcodebuild exit, and OpenText  
SAST exits with an exit code of zero (unless some other error also occurs).  
com.fortify.sca.  
xcode.TranslateAfterErr  
or  
Regardless of this setting, if xcodebuild exits with a non-zero code, then the xcodebuild  
exit code, stdout, and stderr are written to the log file.  
Value type: Boolean  
Page 205 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Scan  
Description  
Default: false  
If set to true, OpenText SAST generates implied methods when it encounters  
implementation by inheritance.  
com.fortify.sca.  
AddImpliedMethods  
Value type: Boolean  
Default: true  
If set to true, enables alias analysis.  
Value type: Boolean  
com.fortify.sca.  
alias.Enable  
Default: true  
Specifies whether to enable Control Flow Analyzer timeouts.  
com.fortify.sca.  
analyzer.controlflow.En  
ableTimeOut  
Value type: Boolean  
Default: true  
Specifies a subset of source files to scan. Only the source files that were linked in the  
named binary at build time are included in the scan.  
com.fortify.sca.  
BinaryName  
Value type: String (path)  
Default: (none)  
Command-line option: -binor -binary-name  
Specifies a comma- or colon-separated list of the types of analysis to perform. The valid  
com.fortify.sca.  
DefaultAnalyzers  
values for this property are buffer, content, configuration, controlflow,  
dataflow, , nullptr, semantic, and structural.  
Value type: String  
Default: This property is commented out and all analysis types are used in scans.  
Command-line option: -analyzers  
If set to true, disables function pointers during the scan.  
Value type: Boolean  
com.fortify.sca.  
DisableFunctionPointers  
Default: false  
Specifies a comma- or colon-separated list of analyzers to use for a scan in addition to the  
com.fortify.sca.  
EnableAnalyzer  
default analyzers. The valid values for this property are buffer, content,  
configuration, controlflow, dataflow, nullptr, semantic, and structural.  
Value type: String  
Default: (none)  
com.fortify.sca.  
ExitCodeLevel  
Extends the default exit code options. See "Exit codes" on page 183 for a description of  
the exit codes and the valid values for this property.  
Specifies the path to a filter file for the scan. See "Excluding issues with filter files" on  
page 192 for more information.  
com.fortify.sca.  
FilterFile  
Page 206 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Value type: String (path)  
Default: (none)  
Command-line option: -filter  
Specifies a comma-separated list of IIDs to be filtered out using a filter file.  
com.fortify.sca.  
FilteredInstanceIDs  
Value type: String  
Default: (none)  
Example:  
com.fortify.sca.FilteredInstanceIDs=CA4E1623A2424919B98EC19FCA279FFA,  
4418B3DC072647158B3758E6183C14CD  
Specifies a comma- or colon-separated list of languages for which to remove rules. The  
com.fortify.sca.  
FilteredRuleLanguages  
valid language values are abap, actionscript, apex, cfml, cobol, configuration,  
cpp, dart, dotnet, golang, objc, php, python, ruby, swift, and vb  
Value type: String  
Default: (none)  
Example: com.fortify.sca.FileredRuleLanguages=apex:php  
com.fortify.sca.  
MaxPassthroughChainDept  
h
Specifies the length of a taint path between input and output parameters in a function  
call.  
Value type: Integer  
Default: 4  
Specifies whether OpenText SAST runs in parallel analysis mode.  
com.fortify.sca.  
MultithreadedAnalysis  
Value type: Boolean  
Default: true  
Specifies a comma-separated list of languages for which to run higher-order analysis.  
Higher-order analysis improves the ability to track dataflow through higher-order code,  
com.fortify.sca.  
Phase0HigherOrder.Langu  
ages  
which is commonly used in modern dynamic languages. Valid values are python, swift,  
ruby, javascript, and typescript.  
Value type: String  
Default: python,ruby,swift,javascript,typescript  
Specifies the total time (in seconds) for higher-order analysis. When the analyzer reaches  
the hard timeout limit, it exits immediately.  
com.fortify.sca.  
Phase0HigherOrder.Timeo  
ut.Hard  
OpenText recommends this timeout limit in case some issue causes the analysis to run too  
long. OpenText recommends that you set the hard timeout to about 50% longer than the  
soft timeout, so that either the fixpoint pass limiter or the soft timeout occurs first.  
Value type: Number  
Default: 2700  
Specifies the scan precision. Scans with a lower precision level are performed faster. The  
com.fortify.sca.  
Page 207 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
PrecisionLevel  
valid values are 1, 2, 3, and 4.  
Value type: Number  
Default: (none)  
Command-line option: -scan-precision| -p  
Specifies the issue template file to use for the scan. This only affects scans on the local  
com.fortify.sca.  
ProjectTemplate  
machine. If you upload the FPR to Fortify Software Security Center, it uses the issue  
template assigned to the application version.  
Value type: String  
Default: (none)  
Command-line option: -project-template  
Example:  
com.fortify.sca.ProjectTemplate=  
test_issuetemplate.xml  
If set to true, OpenText SAST performs a quick scan. OpenText SAST uses the settings  
com.fortify.sca.  
QuickScanMode  
from fortify-sca-quickscan.properties, instead of the fortify-  
sca.propertiesconfiguration file.  
Value type: Boolean  
Default: (not enabled)  
Command-line option: -quick  
Specifies the scan policy for prioritizing reported vulnerabilities (see "Applying a scan  
com.fortify.sca.  
ScanPolicy  
policy to the analysis" on page 64). The valid scan policy values are classic, security,  
and devops.  
Value type: String  
Default: security  
Command-line option: -scor -scan-policy  
Specifies the number of threads for parallel analysis mode. Add this property only if you  
need to reduce the number of threads used because of a resource constraint. If you  
experience an increase in scan time or problems with your scan, a reduction in the number  
of threads used might solve the problem.  
com.fortify.sca.  
ThreadCount  
Value type: Integer  
Default: (number of available processor cores)  
The amount of time (in seconds) that type inference can spend to analyze a single  
function. Unlimited if set to zero or is not specified.  
com.fortify.sca.  
TypeInferenceFunctionTi  
meout  
Value type: Long  
Default: 60  
Comma- or colon-separated list of languages that use type inference. This setting  
improves the precision of the analysis for dynamically-typed languages.  
com.fortify.sca.  
TypeInferenceLanguages  
Page 208 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Value type: String  
Default: javascript,python,ruby,typescript  
com.fortify.sca.  
TypeInferencePhase0Time  
out  
Specifies the total amount of time (in seconds) that type inference can spend in phase 0  
(the interprocedural analysis). Unlimited if set to zero or is not specified.  
Value type: Long  
Default: 300  
Specifies a colon-separated list of functions to hide from all analyzers.  
com.fortify.sca.  
UniversalBlacklist  
Value type: String  
Default: .*yyparse.*  
Regex analysis properties  
The properties for the fortify-sca.propertiesfile in the following table apply to regular  
expression analysis.  
Property name  
Description  
If set to true, regular expression analysis is enabled.  
com.fortify.sca.  
regex.Enable  
Value type: Boolean  
Default: true  
If set to true, binary files are excluded from a regular expression analysis.  
com.fortify.sca.  
regex.ExcludeBinaries  
Value type: Boolean  
Default: true  
com.fortify.sca.  
regex.MaxSize  
Specifies the maximum size (in megabytes) for files that are scanned in a regular expression  
analysis. Files that exceed this file size maximum are excluded from a regular expression  
analysis.  
Value type: Number  
Default: 10  
See also  
"Regular expression analysis" on page 66  
Page 209 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix C: Configuration options  
LIM license properties  
The properties for the fortify-sca.propertiesfile in the following table apply to licensing with  
the LIM.  
Property name  
Description  
Specifies the LIM server API URL. Do not edit this value directly with a text editor. Use  
the command-line option to change this value.  
com.fortify.sca.  
lim.Url  
Value type: String  
Default: (none)  
Command-line option: -store-license-pool-credentials  
Example: https://<ip_address>:<port>  
com.fortify.sca.  
lim.PoolName  
Specifies the LIM license pool name. Do not edit this value directly with a text editor.  
Use the command-line option to change this value.  
Value type: String  
Default: (none)  
Command-line option: -store-license-pool-credentials  
com.fortify.sca.  
lim.PoolPassword  
Specifies the LIM license pool password (encrypted). Do not edit this value directly  
with a text editor. Use the command-line option to change this value.  
Value type: String  
Default: (none)  
Command-line option: -store-license-pool-credentials  
com.fortify.sca.  
lim.ProxyUrl  
Specifies the proxy server used to connect to the LIM server.  
Value type: String  
Default: (none)  
Examples:  
http://proxy.example.com:8080  
https://proxy.example.com  
Command-line option: -store-license-pool-credentials  
Specifies an encrypted user name for proxy authentication to connect to the LIM  
server. Do not edit this value directly with a text editor. Use the command-line option  
to change this value.  
com.fortify.sca.  
lim.ProxyUsername  
Value type: String  
Default: (none)  
Command-line option: -store-license-pool-credentials  
Specifies an encrypted password for proxy authentication to connect to the LIM  
server. Do not edit this value directly with a text editor. Use the command-line option  
com.fortify.sca.  
lim.ProxyPassword  
Page 210 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix C: Configuration options  
Property name  
Description  
to change this value.  
Value type: String  
Default: (none)  
Command-line option: -store-license-pool-credentials  
If set to true, any attempt to connect to the LIM server without a trusted certificate  
fails. If this property is set to false, a message displays when any attempt to connect to  
com.fortify.sca.  
lim.RequireTrustedSSLCert  
the LIM server without a trusted certificate occurs.  
Value type: Boolean  
Default: true  
If set to true and LIM license pool credentials are stored, OpenText SAST waits for a  
LIM license to become available before starting a translation or scan. If this property is  
set to false, OpenText SAST aborts if it cannot obtain a LIM license.  
com.fortify.sca.  
lim.WaitForInitialLicense  
Value type: Boolean  
Default: true  
See also  
"LIM license directives" on page 162  
Rule properties  
The properties for the fortify-sca.propertiesfile in the following table apply to rules (and  
custom rules) and Rulepacks.  
Property name  
Description  
Sets the directory used to search for the OpenText provided encrypted rules files.  
com.fortify.sca.  
DefaultRulesDir  
Value Type: String (path)  
Default:  
${com.fortify.Core}/config/rules  
Specifies a custom Rulepack or directory. If you specify a directory, all of the files in the  
com.fortify.sca.  
RulesFile  
directory with the .binand .xmlextensions are included.  
Value Type: String (path)  
Default: (none)  
Command-line option: -rules  
Sets the directory used to search for custom rules.  
Value Type: String (path)  
com.fortify.sca.  
CustomRulesDir  
Default:  
${com.fortify.Core}/config/customrules  
Page 211 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix C: Configuration options  
Property name  
Description  
com.fortify.sca.  
Specifies a list of file extensions for rules files. Any files in <sast_install_  
RulesFileExtensions  
dir>/Core/config/rules(or a directory specified with the -rulesoption) whose  
extension is in this list is included. The .binextension is always included, regardless of the  
value of this property. The delimiter for this property is the system path separator.  
Value Type: String  
Default: .xml  
If set to true, rules from the default Rulepacks are not loaded. OpenText SAST processes the  
Rulepacks for description elements and language libraries, but no rules are processed.  
com.fortify.sca.  
NoDefaultRules  
Value Type: Boolean  
Default: (none)  
Command-line option: -no-default-rules  
If set to true, disables rules in default Rulepacks that lead directly to issues. OpenText SAST  
still loads rules that characterize the behavior of functions. This can be helpful when creating  
custom issue rules.  
com.fortify.sca.  
NoDefaultIssueRules  
Value Type: Boolean  
Default: (none)  
Command-line option: -no-default-issue-rules  
If set to true, disables source rules in the default Rulepacks. This can be helpful when  
creating custom source rules.  
com.fortify.sca.  
NoDefaultSourceRules  
Note: Characterization source rules are not disabled.  
Value Type: Boolean  
Default: (none)  
Command-line option: -no-default-source-rules  
If set to true, disables sink rules in the default Rulepacks. This can be helpful when creating  
custom sink rules.  
com.fortity.sca.  
NoDefaultSinkRules  
Note: Characterization sink rules are not disabled.  
Value Type: Boolean  
Default: (none)  
Command-line option: -no-default-sink-rules  
Page 212 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Java and Kotlin properties  
The properties for the fortify-sca.propertiesfile in the following table apply to the translation  
of Java and Kotlin code.  
Property name  
Description  
Specifies the class path used to analyze Java or Kotlin source code. Separate multiple  
paths with semicolons (Windows) or colons (non-Windows).  
com.fortify.sca.  
JavaClasspath  
Value type: String (paths)  
Default: (none)  
Command-line option: -cpor -classpath  
Specifies the Java source code version for Java or Kotlin translation.  
Value type: String  
com.fortify.sca.  
JdkVersion  
Default: 11  
Command-line option: -jdkor -source  
Specifies a directory that contains a JDK version that is not included in the OpenText  
com.fortify.sca.  
CustomJdkDir  
SAST installation (<sast_install_dir>/Core/bootcp/).  
Value type: String (path)  
Default: (none)  
Command-line option: -custom-jdk-dir  
Specifies a semicolon- (Windows) or colon-separated (non-Windows) list of Java or Kotlin  
source file directories that are not included in the scan but are used for name resolution.  
The source path is similar to class path, except it uses source files rather than class files for  
resolution.  
com.fortify.sca.  
JavaSourcepath  
Value type: String (paths)  
Default: (none)  
Command-line option: -sourcepath  
com.fortify.sca.  
Appserver  
Specifies the application server to process JSP files. The valid values are weblogicor  
websphere.  
Value type: String  
Default: (none)  
Command-line option: -appserver  
Specifies the application server's home directory. For WebLogic, this is the path to the  
com.fortify.sca.  
AppserverHome  
directory that contains server/lib. For WebSphere, this is the path to the directory that  
contains the JspBatchCompilerscript.  
Value type: String (path)  
Default: (none)  
Page 213 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Command-line option: -appserver-home  
Specifies the version of the WebLogic or WebSphere application server.  
Value type: String  
com.fortify.sca.  
AppserverVersion  
Default: (none)  
Command-line option: -appserver-version  
Specifies directories to include implicitly on the class path for WebLogic and WebSphere  
application servers.  
com.fortify.sca.  
JavaExtdirs  
Value type: String  
Default: (none)  
Command-line option: -extdirs  
If set to true, OpenText SAST only translates Java source files that are referenced by the  
target file list. Otherwise, OpenText SAST translates all files included in the source path.  
com.fortify.sca.  
JavaSourcepathSearch  
Value type: Boolean  
Default: true  
Specifies semicolon- or colon-separated list of directories of commonly used JAR files. JAR  
com.fortify.sca.  
DefaultJarsDirs  
files located in these directories are appended to the end of the class path option (-cp).  
Value type: String  
Default: default_jars  
If set to true, Java bytecode is decompiled for the translation.  
Value type: Boolean  
com.fortify.sca.  
DecompileBytecode  
Default: false  
If set to true, the JSP parser uses JSP security manager.  
Value type: Boolean  
com.fortify.sca.  
jsp.UseSecurityManager  
Default: true  
Specifies the encoding for JSPs.  
Value type: String (encoding)  
com.fortify.sca.  
jsp.DefaultEncoding  
Default: ISO-8859-1  
If set to true, enables additional filtering on JSP-related dataflow to reduce the amount of  
spurious false positives detected.  
com.fortify.sca.  
jsp.LegacyDataflow  
Value type: Boolean  
Default: false  
Command-line option: -legacy-jsp-dataflow  
com.fortify.sca.  
KotlinJvmDefault  
Specifies the generation of the DefaultImplsclass for methods with bodies in Kotlin  
interfaces. The valid values are:  
Page 214 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
l
l
l
disable—Specifies to generate the DefaultImplsclass for each interface that  
contains methods with bodies.  
all—Specifies to generate the DefaultImplsclass if an interface is annotated with  
@JvmDefaultWithCompatibility.  
all-compatibility—Specifies to generate the DefaultImplsclass unless an  
interface is annotated with @JvmDefaultWithoutCompatibility.  
Value type: String  
Default: disable  
If set to true, displays any unresolved types, fields, and functions referenced in translated  
Java source files at the end of the translation.  
com.fortify.sca.  
ShowUnresolvedSymbols  
Value type: Boolean  
Default: false  
Command-line option: -show-unresolved-symbols  
See also  
"Translating Java code" on page 68  
"Translating Kotlin code" on page 76  
Visual Studio and MSBuild project properties  
The properties for the fortify-sca.propertiesfile in the following table apply to the translation  
of .NET projects and solutions.  
Property name  
Description  
Sets various .NET options.  
Value type: Boolean and String  
Defaults and examples:  
WinForms.  
TransformDataBindings  
WinForms.  
TransformMessageLoops  
WinForms.TransformDataBindings=true  
WinForms.  
TransformChangeNotificationPattern  
WinForms.TransformMessageLoops=true  
WinForms.  
CollectionMutationMonitor.Label  
WinForms.TransformChangeNotificationPattern=true  
WinForms.CollectionMutationMonitor.Label=  
WinFormsDataSource  
WinForms.  
ExtractEventHandlers  
WinForms.ExtractEventHandlers=true  
Specifies a semicolon-separated list of full paths to virtual roots used.  
com.fortify.sca.  
ASPVirtualRoots.<virtual_path>  
Value type: String  
Default: (none)  
Page 215 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Example:  
com.fortify.sca.ASPVirtualRoots.Library=  
c:\\WebServer\\CustomerTwo\\Stuff  
com.fortify.sca.ASPVirtualRoots.Include=  
c:\\WebServer\\CustomerOne\\inc  
If set to true, disables ASP external entries in the scan.  
com.fortify.sca.  
DisableASPExternalEntries  
Value type: Boolean  
Default: false  
See also  
"Translating Visual Studio projects" on page 80  
JavaScript and TypeScript properties  
The properties for the fortify-sca.propertiesfile in the following table apply to the translation  
of JavaScript and TypeScript code.  
Property name  
Description  
If set to true, OpenText SAST generates JavaScript code to model the  
com.fortify.sca.  
EnableDOMModeling  
DOM tree that an HTML file generated during the translation phase and  
identifies DOM-related issues (such as cross-site scripting issues). Enable this  
property if the code you are translating includes HTML files that have  
embedded or referenced JavaScript code.  
Note: Enabling this property can increase the translation time.  
Value type: Boolean  
Default: false  
com.fortify.sca.  
DOMModeling.tags  
If you set the com.fortify.sca.EnableDOMModelingproperty to true, you  
can specify additional coma-separated HTML tags names for OpenText SAST  
to include in the DOM modeling.  
Value type: String  
Default: body, button, div, form, iframe, input, head, html, and p.  
Example:  
com.fortify.sca.DOMModeling.tags=ul,li  
Specifies trusted domain names where OpenText SAST can download  
referenced JavaScript files for the scan. Delimit the URLs with vertical bars.  
com.fortify.sca.  
JavaScript.src.domain.whitelist  
Value type: String  
Default: (none)  
Example: com.fortify.sca.JavaScript.  
src.domain.whitelist=  
Page 216 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix C: Configuration options  
Property name  
Description  
http://www.xyz.com|http://www.123.org  
com.fortify.sca.  
DisableJavascriptExtraction  
If set to true, JavaScript code embedded in JSP, JSPX, PHP, and HTML files is  
not extracted and not scanned.  
Value type: Boolean  
Default: false  
If set to true, enables translation for minified JavaScript files.  
Value type: Boolean  
com.fortify.sca.  
EnableTranslationMinifiedJS  
Default: false  
Specifies a list of comma- or colon-separated JavaScript or TypeScript  
technology library files that are not translated. You can use regular  
com.fortify.sca.  
skip.libraries.ES6  
expressions in the file names. Note that the regular expression '(-  
com.fortify.sca.  
\d\.\d\.\d)?'is automatically inserted before .min.jsor .jsfor each file  
skip.libraries.jQuery  
name included in the com.fortify.sca.skip.libraries.jQueryproperty  
value.  
com.fortify.sca.  
skip.libraries.javascript  
Value type: String  
com.fortify.sca.  
skip.libraries.typescript  
Defaults:  
l
ES6: es6-shim.min.js,system-polyfills.js,  
shims_for_IE.js  
l
jQuery: jquery.js,jquery.min.js,  
jquery-migrate.js,jquery-migrate.min.js,  
jquery-ui.js,jquery-ui.min.js,  
jquery.mobile.js,jquery.mobile.min.js,  
jquery.color.js,jquery.color.min.js,  
jquery.color.svg-names.js,  
jquery.color.svg-names.min.js,  
jquery.color.plus-names.js,  
jquery.color.plus-names.min.js,  
jquery.tools.min.js  
l
javascript: bootstrap.js,  
bootstrap.min.js,  
typescript.js,  
typescriptServices.js  
l
typescript: typescript.d.ts,  
typescriptServices.d.ts  
If set to true, files included with an import statement are included in the  
translation.  
com.fortify.sca.  
follow.imports  
Value type: Boolean  
Default: true  
If set to true, files in a node_modules directory are excluded from the analysis  
phase.  
com.fortify.sca.  
exclude.node.modules  
Value type: Boolean  
Page 217 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Default: true  
Specifies whether to exclude source code in a node_modules directory. If set to  
true, only imported node_modules are included in the translation.  
com.fortify.sca.  
exclude.unimported.node.modules  
Note: This property is only applied if  
com.fortify.sca.exclude.node.modulesis set to false.  
Value type: Boolean  
Default: true  
See also  
"Translating JavaScript and TypeScript code" on page 89  
Python properties  
The properties for the fortify-sca.propertiesfile in the following table apply to the translation  
of Python code.  
Property name  
Description  
Specifies a semicolon-separated (Windows) or colon-separated (non-Windows) list  
of additional import directories. OpenText SAST does not respect PYTHONPATH  
environment variable that the Python runtime system uses to find import files. Use  
this property to specify the additional import directories.  
com.fortify.sca.  
PythonPath  
Value type: String (path)  
Default: (none)  
Command-line option: -python-path  
com.fortify.sca.  
PythonVersion  
Specifies the Python source code version to scan. The valid values are 2and 3.  
Value type: Number  
Default: 3  
Command-line option: -python-version  
If set to true, disables the automatic calculation of a common root directory of all  
project files to use for importing modules and packages For more details, see  
com.fortify.sca.  
PythonNoAutoRootCalculation  
"Including imported modules and packages" on page 98.  
Value type: Boolean  
Default: false  
Command-line option: -python-no-auto-root-calculation  
Specifies semicolon-separated (Windows) or colon-separated (non-Windows) list of  
directories for Django templates. OpenText SAST does not use the TEMPLATE_  
com.fortify.sca.  
DjangoTemplateDirs  
DIRS setting from the Django settings.pyfile.  
Page 218 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Value type: String (paths)  
Default: (none)  
Command-line option: -django-template-dirs  
Specifies that OpenText SAST does not automatically discover Django templates.  
Value type: Boolean  
com.fortify.sca.  
DjangoDisableAutodiscover  
Default: (none)  
Command-line option: -django-disable-autodiscover  
Specifies semicolon-separated (Windows) or colon-separated (non-Windows) list of  
directories for Jinja2 templates.  
com.fortify.sca.  
JinjaTemplateDirs  
Value type: String (paths)  
Default: (none)  
Command-line option: -jinja-template-dirs  
Specifies that OpenText SAST does not automatically discover Django or Jinja2  
templates.  
com.fortify.sca.  
DisableTemplateAutodiscover  
Value type: Boolean  
Default: (none)  
Command-line option: -disable-template-autodiscover  
See also  
"Translating Python code" on page 95  
Go properties  
The properties for the fortify-sca.propertiesfile in the following table apply to the translation  
of Go code.  
Property name  
Description  
com.fortify.sca.  
gotags  
Specifies custom build tags for a Go project. This is equivalent to the -tagsoption for the go  
command.  
Value type: String  
Default: (none)  
Command-line option: -gotags  
Specifies the root directory of your project/workspace.  
com.fortify.sca.  
GOPATH  
Value type: String  
Default: (GOPATH system environment variable)  
Page 219 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Specifies the location of the Go installation.  
Value type: String  
com.fortify.sca.  
GOROOT  
Default: (GOROOT system environment variable)  
com.fortify.sca.  
GOPROXY  
Specifies one or more comma-separated proxy URLs. You can also specify director off.  
Value type: String  
Default: (GOPROXY system environment variable)  
See also  
"Translating Go code" on page 103  
Ruby properties  
The properties for the fortify-sca.propertiesfile in the following table apply to the translation  
of Ruby code.  
Property name  
Description  
Specifies one or more paths to directories that contain Ruby libraries.  
Value type: String (path)  
com.fortify.sca.  
RubyLibraryPaths  
Default: (none)  
Command-line option: -ruby-path  
Specifies one or more paths to RubyGems locations. Set this value if the project has associated  
gems to scan.  
com.fortify.sca.  
RubyGemPaths  
Value type: String (path)  
Default: (none)  
Command-line option: -rubygem-path  
See also  
"Translating Ruby code" on page 117  
COBOL properties  
The properties for the fortify-sca.propertiesfile in the following table apply to the translation  
of COBOL code.  
Property name  
Description  
Specifies one or more semicolon- or colon-separated directories where OpenText SAST  
looks for copybook files.  
com.fortify.sca.  
CobolCopyDirs  
Page 220 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Value type: String (path)  
Default: (none)  
Command-line option: -copydirs  
com.fortify.sca.  
CobolDialect  
Specifies the COBOL dialect. The valid values for dialect are COBOL390or MICROFOCUS.  
The dialect value is case-insensitive.  
Value type: String  
Default: COBOL390  
Command-line option: -dialect  
Specifies one or more semicolon-separated COBOL checker directives.  
com.fortify.sca.  
CobolCheckerDirectives  
Value type: String  
Default: (none)  
Command-line option: -checker-directives  
com.fortify.sca.  
CobolLegacy  
If set to true, enables legacy COBOL translation.  
Value type: Boolean  
Default: false  
Command-line option: -cobol-legacy  
If set to true, specifies fixed-format COBOL to direct OpenText SAST to only look for  
source code between columns 8-72 in all lines of code (legacy COBOL translation only).  
com.fortify.sca.  
CobolFixedFormat  
Value type: Boolean  
Default: false  
Command-line option: -fixed-format  
Specifies one or more semicolon- or colon-separated copybook file extensions (legacy  
COBOL translation only).  
com.fortify.sca.  
CobolCopyExtensions  
Value type: String  
Default: (none)  
Command-line option: -copy-extensions  
See also  
"Translating COBOL code" on page 119  
Page 221 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
PHP properties  
The properties for the fortify-sca.propertiesfile in the following table apply to the translation  
of PHP code.  
Property name  
Description  
com.fortify.sca.  
PHPVersion  
Specifies the PHP version. For a list of valid versions, see "Supported languages" on page 33.  
Value type: String  
Default: 8.2  
Command-line option: -php-version  
Specifies the PHP source root.  
Value type: Boolean  
com.fortify.sca.  
PHPSourceRoot  
Default: (none)  
Command-line option: -php-source-root  
See also  
"Translating PHP code" on page 109  
ABAP properties  
The properties described in the following table apply to the translation of ABAP code.  
Property name  
Description  
If set to true, OpenText SAST adds ABAP statements to debug messages.  
com.fortify.sca.  
AbapDebug  
Value type: Boolean  
Default: (none)  
When OpenText SAST encounters an ABAP 'INCLUDE' directive, it looks in the named directory.  
com.fortify.sca.  
AbapIncludes  
Value type: String (path)  
Default: (none)  
Page 222 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Appendix C: Configuration options  
Flex and ActionScript properties  
The properties for the fortify-sca.propertiesfile in the following table apply to the translation  
of Flex and ActionScript code.  
Property name  
Description  
Specifies a semicolon-separated (Windows) or colon-separated (non-Windows) of libraries to "link"  
com.fortify.sca.  
FlexLibraries  
to. This list must include flex.swc, framework.swc, and playerglobal.swc(which are usually  
located in the frameworks/libsdirectory in your Flex SDK root). Use this property primarily to  
resolve ActionScript.  
Value type: String (path)  
Default: (none)  
Command-line option: -flex-libraries  
Specifies the root location of a valid Flex SDK. The folder must contain a frameworks folder that  
com.fortify.sca.  
FlexSdkRoot  
contains a flex-config.xmlfile. It must also contain a binfolder that contains an mxmlc  
executable.  
Value type: String (path)  
Default: (none)  
Command-line option: -flex-sdk-root  
Specifies any additional source directories for a Flex project. Separate multiple directories with  
semicolons (Windows) or colons (non-Windows).  
com.fortify.sca.  
FlexSourceRoots  
Value type: String (path)  
Default: (none)  
Command-line option: -flex-source-root  
ColdFusion (CFML) properties  
The properties for the fortify-sca.propertiesfile in the following table apply to the translation  
of CFML code.  
Property name  
Description  
If set to true, OpenText SAST treats undefined variables in CFML pages as  
tainted. This serves as a hint to the Dataflow Analyzer to watch out for  
register-globals-style vulnerabilities. However, enabling this property  
interferes with dataflow findings where a variable in an included page is  
initialized to a tainted value in an earlier-occurring included page.  
com.fortify.sca.  
CfmlUndefinedVariablesAreTainted  
Value type: Boolean  
Default: false  
If set to true, make CFML files case-insensitive for applications developed  
com.fortify.sca.  
Page 223 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Appendix C: Configuration options  
Property name  
Description  
using a case-insensitive file system and scanned on case-sensitive file  
systems.  
CaseInsensitiveFiles  
Value type: Boolean  
Default: (not enabled)  
Specifies the base directory for ColdFusion projects.  
Value type: String (path)  
com.fortify.sca.  
SourceBaseDir  
Default: (none)  
Command-line option: -source-base-dir  
See also  
"Translating ColdFusion code" on page 130  
SQL properties  
The properties for the fortify-sca.propertiesfile in the following table apply to the translation  
of SQL code.  
Property name  
Description  
com.fortify.sca.  
SqlLanguage  
Specifies the SQL language variant. The valid SQL language type values are PLSQL(for Oracle  
PL/SQL) and TSQL(for Microsoft T-SQL).  
Value type: String  
Default: TSQL  
Command-line option: -sql-language  
See also  
"Analyzing SQL" on page 131  
Output properties  
The properties for the fortify-sca.propertiesfile in the following table apply to the analysis  
output.  
Property name  
Description  
The file to which results are written.  
Value type: String  
com.fortify.sca.  
ResultsFile  
Default: (none)  
Command-line option: -f  
Page 224 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Example: com.fortify.sca.ResultsFile=MyResults.fpr  
com.fortify.sca.  
Renderer  
Controls the output format. The valid values are fpr, fvdl, text, and auto. The default  
of autoselects the output format based on the extension of the file provided with the -  
foption.  
Value type: String  
Default: auto  
Command-line option: -format  
If set to true, OpenText SAST appends results to an existing results file.  
Value type: Boolean  
com.fortify.sca.  
OutputAppend  
Default: false  
Command-line option: -append  
If set to true, OpenText SAST prints results as they become available. This is helpful if  
you do not specify the -foption (to specify an output file) and print to stdout.  
Value type: Boolean  
com.fortify.sca.  
ResultsAsAvailable  
Default: false  
Specifies a label for the scanned project. OpenText SAST does not use this label but  
includes it in the results.  
com.fortify.sca.  
BuildLabel  
Value type: String  
Default: (none)  
Command-line option: -build-label  
Specifies a name for the scanned project. OpenText SAST does not use this name but  
includes it in the results.  
com.fortify.sca.  
BuildProject  
Value type: String  
Default: (none)  
Command-line option: -build-project  
Specifies a version number for the scanned project. OpenText SAST does not use this  
version number but it is included in the results.  
com.fortify.sca.  
BuildVersion  
Value type: String  
Default: (none)  
Command-line option: -build-version  
Output information in a format that scripts or OpenText SAST tools can use rather than  
printing output interactively. Instead of a single line to display scan progress, a new line  
is printed below the previous one on the console to display updated progress.  
com.fortify.sca.  
MachineOutputMode  
Value type: Boolean  
Default: (not enabled)  
Page 225 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Command-line option: -machine-output  
Sets the number of lines of code to display surrounding an issue. Snippets always  
include the two lines of code on each side of the line where the error occurs. By default,  
five lines of code are displayed.  
com.fortify.sca.  
SnippetContextLines  
Value type: Number  
Default: 2  
If set to true, excludes Fortify security content descriptions from the analysis results file  
(FVDL).  
com.fortify.sca.  
FVDLDisableDescriptions  
Value type: Boolean  
Default: false  
Command-line option: -fvdl-no-descriptions  
If set to true, excludes engine data from the analysis results file (FVDL).  
Value type: Boolean  
com.fortify.sca.  
FVDLDisableEngineData  
Default: false  
Command-line option:-fvdl-no-enginedata  
If set to true, excludes label evidence from the analysis results file (FVDL).  
Value type: Boolean  
com.fortify.sca.  
FVDLDisableLabelEvidence  
Default: false  
com.fortify.sca.  
FVDLDisableProgramData  
If set to true, excludes the ProgramDatasection from the analysis results file (FVDL).  
Value type: Boolean  
Default: false  
Command-line option: -fvdl-no-progdata  
If set to true, excludes code snippets from the analysis results file (FVDL).  
Value type: Boolean  
com.fortify.sca.  
FVDLDisableSnippets  
Default: false  
Command-line option: -fvdl-no-snippets  
Specifies location of the style sheet for the analysis results.  
Value type: String (path)  
com.fortify.sca.  
FVDLStylesheet  
Default:  
${com.fortify.Core}/resources/sca/fvdl2html.xsl  
Page 226 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Mobile build session (MBS) properties  
The properties for the fortify-sca.propertiesfile in the following table apply to MBS files.  
Property name  
Description  
If set to false, OpenText SAST does not copy source files into the build session directory.  
com.fortify.sca.  
MobileBuildSessions  
Value type: Boolean  
Default: true  
If set to true, OpenText SAST extracts the build ID and the OpenText SAST version number  
from the mobile build session.  
com.fortify.sca.  
ExtractMobileInfo  
Note: OpenText SAST does not extract the mobile build with this property.  
Value type: Boolean  
Default: false  
See also  
"Using mobile build sessions" on page 198  
Proxy properties  
The properties for the fortify-sca.propertiesfile in the following table apply to proxy settings.  
Property name  
Description  
Specifies a proxy host name.  
com.fortify.sca.  
https.proxyHost  
Value type: String  
Default: (none)  
Specifies a proxy port number.  
Value type: Number  
com.fortify.sca.  
https.proxyPort  
Default: (none)  
Logging properties  
The properties for the fortify-sca.propertiesfile in the following table apply to log files.  
Property name  
Description  
Specifies the default log file name and location.  
com.fortify.sca.  
LogFile  
Value type: String (path)  
Page 227 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Default:${com.fortify.sca.ProjectRoot}/log/sca.logand  
${com.fortify.sca.ProjectRoot}/log/sca_FortifySupport.log  
Command-line option: -logfile  
com.fortify.sca.  
LogLevel  
Specifies the minimum log level for both log files. The valid values are DEBUG,  
INFO, WARN, ERROR, and FATAL. For more information, see "Locating the log files"  
on page 189 and "Configuring log files" on page 189.  
Value type: String  
Default: INFO  
If set to true, OpenText SAST overwrites the log file for each run of  
sourceanalyzer.  
com.fortify.sca.  
ClobberLogFile  
Value type: Boolean  
Default: false  
Command-line option: -clobber-log  
If set to true, OpenText SAST writes performance-related data to the OpenText  
SAST Support log file after the scan is complete. This value is automatically set to  
true when in debug mode.  
com.fortify.sca.  
PrintPerformanceDataAfterScan  
Value type: Boolean  
Default: false  
See also  
"Configuring log files" on page 189  
Debug properties  
The properties for the fortify-sca.propertiesfile in the following table apply to debug settings.  
Property name  
Description  
Includes debug information in the OpenText SAST Support log file, which is only useful for  
Customer Support to help troubleshoot.  
com.fortify.sca.  
Debug  
Value type: Boolean  
Default: false  
Command-line option: -debug  
com.fortify.sca.  
DebugVerbose  
This is the same as the com.fortify.sca.Debugproperty, but it includes more details,  
specifically for parse errors.  
Value type: Boolean  
Default: (not enabled)  
Command-line option: -debug-verbose  
Page 228 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
If set to true, includes verbose messages in the OpenText SAST Support log file.  
com.fortify.sca.  
Verbose  
Value type: Boolean  
Default: false  
Command-line option: -verbose  
If set to true, additional performance information is written to the OpenText SAST Support  
log.  
com.fortify.sca.  
DebugTrackMem  
Value type: Boolean  
Default: (not enabled)  
Command-line option: -debug-mem  
If set to true, enables additional timers to track performance.  
Value type: Boolean  
com.fortify.sca.  
CollectPerformanceData  
Default: (not enabled)  
If set to true, disables the command-line progress information.  
com.fortify.sca.  
Quiet  
Value type: Boolean  
Default: false  
Command-line option: -quiet  
If set to true, OpenText SAST monitors its memory use and warns when JVM garbage  
collection becomes excessive.  
com.fortify.sca.  
MonitorSca  
Value type: Boolean  
Default: true  
fortify-sca-quickscan.properties  
OpenText SAST offers a less in-depth scan known as a quick scan. This option scans the project in  
quick scan mode, using the property values in the fortify-sca-quickscan.propertiesfile. By  
default, a quick scan reduces the depth of the analysis and applies the Quick View filter set. The Quick  
View filter set provides only critical and high priority issues.  
Note: Properties in this file are only used if you specify the -quickoption on the command line  
for your scan.  
The following table provides two sets of default values: the default value for quick scans and the  
default value for normal scans. If only one default value is shown, the value is the same for both  
normal scans and quick scans.  
Property name  
Description  
Sets the time limit (in milliseconds) for Control Flow analysis on a single  
com.fortify.sca.  
Page 229 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix C: Configuration options  
Property name  
Description  
function.  
CtrlflowMaxFunctionTime  
Value type: Integer  
Quick scan default: 30000  
Default: 600000  
Specifies a comma- or colon-separated list of analyzers to disable during a  
com.fortify.sca.  
DisableAnalyzers  
scan. The valid analyzer names are buffer, content, configuration,  
controlflow, dataflow, nullptr, semantic, and structural.  
Value type: String  
Quick scan default: controlflow:buffer  
Default: (none)  
Specifies the filter set to use. You can use this property with an issue  
template to filter at scan-time instead of post-scan. See  
com.fortify.sca.  
FilterSet  
com.fortify.sca.ProjectTemplatedescribed in "Translation and  
analysis phase properties" on page 202 to specify an issue template that  
contains the filter set to use.  
When set to Quick View, this property runs rules that have a potentially  
high impact and a high likelihood of occurring and rules that have a  
potentially high impact and a low likelihood of occurring. Filtered issues are  
not written to the FPR and therefore this can reduce the size of an FPR. For  
more information about filter sets, see the OpenText™ Fortify Audit  
Workbench User Guide.  
Value type: String  
Quick scan default: Quick View  
Default: (none)  
Disables the creation of the metatable, which includes information for the  
Function view in Fortify Audit Workbench. This metatable enables right-click  
on a variable in the source window to show the declaration. If C/C++ scans  
take an extremely long time, setting this property to true can potentially  
reduce the scan time by hours.  
com.fortify.sca.  
FPRDisableMetatable  
Value type: Boolean  
Quick scan default: true  
Default: false  
Command-line option: -disable-metatable  
Disables source code inclusion in the FPR file. Prevents OpenText SAST from  
generating marked-up source code files during a scan. If you plan to upload  
FPR files that are generated as a result of a quick scan to Fortify Software  
com.fortify.sca.  
FPRDisableSourceBundling  
Security Center, you must set this property to false.  
Value type: Boolean  
Page 230 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Quick scan default: true  
Default: false  
Command-line option: -disable-source-bundling  
Sets the time limit (in milliseconds) for Null Pointer analysis for a single  
function. The standard default is five minutes. If this value is set to a shorter  
limit, the overall scan time decreases.  
com.fortify.sca.  
NullPtrMaxFunctionTime  
Value type: Integer  
Quick scan default: 10000  
Default: 300000  
Disables path tracking for Control Flow analysis. Path tracking provides more  
detailed reporting for issues, but requires more scan time. To disable this for  
com.fortify.sca.  
TrackPaths  
JSP only, set it to NoJSP. Specify Noneto disable all functions.  
Value type: String  
Quick scan default: (none)  
Default: NoJSP  
Specifies the size limit for complex calculations in the Buffer Analyzer. Skips  
calculations that are larger than the specified size value in the Buffer  
Analyzer to improve scan time.  
com.fortify.sca.  
limiters.ConstraintPredicateSize  
Value type: Integer  
Quick scan default: 10000  
Default: 500000  
Controls the maximum call depth through which the Dataflow Analyzer tracks  
tainted data. Increase this value to increase the coverage of dataflow  
analysis, which results in longer scan times.  
com.fortify.sca.  
limiters.MaxChainDepth  
Note: Call depth refers to the maximum call depth on a dataflow path  
between a taint source and sink, rather than call depth from the  
program entry point, such as main().  
Value type: Integer  
Quick scan default: 3  
Default: 5  
Sets the number of times taint propagation analyzer visits functions.  
com.fortify.sca.  
limiters.MaxFunctionVisits  
Value type: Integer  
Quick scan default: 5  
Default: 50  
Controls the maximum number of paths to report for a single dataflow  
com.fortify.sca.  
limiters.MaxPaths  
Page 231 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
vulnerability. Changing this value does not change the results that are found,  
only the number of dataflow paths displayed for an individual result.  
Note: OpenText does not recommend setting this property to a value  
larger than 5because it might increase the scan time.  
Value type: Integer  
Quick scan default: 1  
Default: 5  
Sets a complexity limit for the Dataflow Analyzer. Dataflow incrementally  
decreases precision of analysis on functions that exceed this complexity  
metric for a given precision level. This value controls how much taint is  
tracked for a variable chain.  
com.fortify.sca.  
limiters.MaxTaintDefForVar  
Value type: Integer  
Quick scan default: 250  
Default: 1000  
Sets a hard limit for function complexity. If complexity of a function exceeds  
this limit at the lowest precision level, the analyzer skips analysis of the  
function.  
com.fortify.sca.  
limiters.MaxTaintDefForVarAbort  
Value type: Integer  
Quick scan default: 500  
Default: 4000  
fortify-rules.properties  
This topic describes the properties available for use in the fortify-rules.propertiesfile. Use  
these properties to modify behavior of individual rules or provide information that can improve how  
rules identify weaknesses.  
Property name  
Description  
The regular expression to match password identifiers across all languages unless a  
language-specific rules property is set.  
com.fortify.sca.rules.  
password_regex.global  
Value type: String  
Default: (?i)(s|_)?(user|usr|member|admin|guest|login|default|  
new|current|old|client|server|proxy|sqlserver|  
my|mysql|mongo|mongodb|db|database|ldap|smtp|  
email|email(_)?smtp)?(_|\.)?(pass(wd|word|phrase)|secret)  
Regular expression to match password identifiers in ABAP code. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules  
.password_regex.abap  
Page 232 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in ActionScript code. Setting this  
property overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_  
regex.actionscript  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in Salesforce Apex code. Setting this  
property overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.apex  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in ColdFusion (CFML) code. Setting this  
property overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.cfml  
Value type: String  
Default: (none)  
Regular expression to match password identifiers in COBOL code. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.cobol  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in XML. Setting this property overrides  
the global regex password rules property. Do not use regular expression modifiers. The  
value is case-insensitive.  
com.fortify.sca.rules.  
password_regex.config  
Value type: String  
Default: (s|_)?(user|usr|member|admin|guest|login|default|  
new|current|old|client|server|proxy|sqlserver|  
my|mysql|mongo|mongodb|db|database|ldap|smtp|  
email|email(_)?smtp)?(_|\.)?pass(wd|word|phrase)  
Regular expression to match password identifiers in C and C++ code. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.cpp  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in Dart code. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.dart  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in .NET code. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.dotnet  
Page 233 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in Dockerfiles. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.docker  
Value type: String  
Default: .*pass(wd|word|phrase).*  
Regular expression to match password identifiers in Go code. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.golang  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in Java code. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.java  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in JavaScript and TypeScript code.  
Setting this property overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_  
regex.javascript  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in JSON. Setting this property overrides  
the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.json  
Value type: String  
Default: (?i).*pass(wd|word|phrase).*  
Regular expression used to match password identifiers in JSP code. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.jsp  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in Objective-C and Objective-C++ code.  
Setting this property overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.objc  
Value type: String  
Default: (?i)(s|_)?(user|usr|member|admin|guest|login|default|  
new|current|old|client|server|proxy|sqlserver|  
my|mysql|mongo|mongodb|db|database|ldap|smtp|  
email|email(_)?smtp)?(_|\.)?(token|pin|pass(wd|word|phrase))  
Regular expression to match password identifiers in PHP code. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.php  
Value type: String  
Page 234 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in PowerShell files. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_  
regex.powershell  
Value type: String  
Default: (?i)([a-z_]*|\{.*)(pass(wd|word|phrase)|pwd)(.*\}|[a-z_]*)  
Regular expression to match password identifiers in Properties files. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_  
regex.properties  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in Python code. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.python  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in Ruby code. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.ruby  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in SQL code. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.sql  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in Swift code. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.swift  
Value type: String  
Default: (?i)(s|_)?(user|usr|member|admin|guest|login|default|  
new|current|old|client|server|proxy|sqlserver|  
my|mysql|mongo|mongodb|db|database|ldap|smtp|  
email|email(_)?smtp)?(_|\.)?(token|pin|pass(wd|word|phrase))  
Regular expression to match password identifiers in VB6 code. Setting this property  
overrides the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.vb  
Value type: String  
Default: (value for com.fortify.sca.rules.password_regex.global)  
Regular expression to match password identifiers in YAML. Setting this property overrides  
the global regex password rules property.  
com.fortify.sca.rules.  
password_regex.yaml  
Value type: String  
Default: (?i).*pass(wd|word|phrase).*  
Page 235 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
The regular expression to match key identifiers across all languages unless a language-  
specific regex key rules property is set.  
com.fortify.sca.rules.  
key_regex.global  
Value type: String  
Default: (?i)((enc|dec)(ryption|rypt)?|crypto|secret|private)(_)?key  
Regular expression to match key identifiers in ABAP code. Setting this property overrides  
the global regex key rules property.  
com.fortify.sca.rules.  
key_regex.abap  
Value type: String  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Regular expression to match key identifiers in ActionScript code. Setting this property  
overrides the global regex key rules property.  
com.fortify.sca.rules.  
key_regex.actionscript  
Value type: String  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Regular expression to match key identifiers in CFML code. Setting this property overrides  
the global regex key rules property.  
com.fortify.sca.rules.  
key_regex.cfml  
Value type: String  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Regular expression to match key identifiers in C and C++ code. Setting this property  
overrides the global regex key rules property.  
com.fortify.sca.rules.  
key_regex.cpp  
Value type: String  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Regular expression to match key identifiers in Go code. Setting this property overrides the  
global regex key rules property.  
com.fortify.sca.rules.  
key_regex.golang  
Value type: String  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Regular expression to match key identifiers in Java code. Setting this property overrides  
the global regex key rules property.  
com.fortify.sca.rules.  
key_regex.java  
Value type: String  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Regular expression to match key identifiers in JavaScript and TypeScript code. Setting this  
property overrides the global regex key rules property.  
com.fortify.sca.rules.  
key_regex.javascript  
Value type: String  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Regular expression to match key identifiers in JSP code. Setting this property overrides  
the global regex key rules property.  
com.fortify.sca.rules.  
key_regex.jsp  
Value type: String  
Page 236 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Regular expression used to match key identifiers in Objective-C and Objective-C++ code.  
Setting this property overrides the global regex key rules property.  
com.fortify.sca.rules.  
key_regex.objc  
Value type: String  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Regular expression to match key identifiers in PHP code. Setting this property overrides  
the global regex key rules property.  
com.fortify.sca.rules.  
key_regex.php  
Value type: String  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Regular expression to match key identifiers in Python code. Setting this property  
overrides the global regex key rules property.  
com.fortify.sca.rules.  
key_regex.python  
Value type: String  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Regular expression used to match key identifiers in Ruby code. Setting this property  
overrides the global regex key rules property.  
com.fortify.sca.rules.  
key_regex.ruby  
Value type: String  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Regular expression to match key identifiers in SQL code. Setting this property overrides  
the global regex key rules property.  
com.fortify.sca.rules.  
key_regex.sql  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Regular expression used to match key identifiers in Swift code. Setting this property  
overrides the global regex key rules property.  
com.fortify.sca.rules.  
key_regex.swift  
Value type: String  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Regular expression to match key identifiers in Visual Basic 6 code. Setting this property  
overrides the global regex key rules property.  
com.fortify.sca.rules.  
key_regex.vb  
Value type: String  
Default: (value for com.fortify.sca.rules.key_regex.global)  
Name of the serverless function called when no JSON/YAML cloud build config file exists.  
com.fortify.sca.rules.  
GCPFunctionName  
Value type: String  
Default: (none)  
If set to true, the scanned cloud function is an HTTP trigger.  
com.fortify.sca.rules.  
GCPHttpTrigger  
Value type: Boolean  
Default: false  
Page 237 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
User Guide  
Appendix C: Configuration options  
Property name  
Description  
If set to true and OpenText SAST scans an application with a supported framework,  
produces a results file to be imported into OpenText™ Dynamic Application Security  
Testing to improve results.  
com.fortify.sca.rules.  
enable_wi_correlation  
Value type: Boolean  
Default: false  
Page 238 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
Appendix D: Fortify Java annotations  
OpenText provides two versions of the Fortify Java annotations library.  
l
Annotations with the retention policy set to CLASS (FortifyAnnotations-CLASS.jar).  
With this version of the library, Fortify Java annotations are propagated to the bytecode during  
compilation.  
l
Annotations with the retention policy set to SOURCE (FortifyAnnotations-SOURCE.jar).  
With this version of the library, Fortify Java annotations are not propagated to the bytecode after  
the code that uses them is compiled.  
If you use OpenText Application Security Software products to analyze bytecode of your applications  
(for example, with OpenText™ Core Application Security assessments), then use the version with the  
annotation retention policy set to CLASS. If you use OpenText Application Security Software products  
to analyze the source code of your applications, you can use either version of the library. However,  
OpenText strongly recommends that you use the library with a retention policy set to SOURCE.  
Important! It is a security risk to leave Fortify Java annotations in production code because they  
can leak information about potential security problems in the code. OpenText recommends that  
you use annotations with the retention policy set to CLASS only for internalanalysis, and never  
use them in your application production builds.  
This section outlines the annotations available. A sample application is included in the OpenText_  
SAST_Fortify_Samples_<version>.ziparchive in the advanced/javaAnnotationsdirectory.  
A README.txtfile included in the directory describes the sample application, problems that might  
arise from it, and how to fix these problems using Fortify Java annotations.  
There are two limitations with Fortify Java annotations:  
l
Each annotation can specify only one input and/or one output.  
l
You can apply only one annotation of each type to the same target.  
OpenText provides three main types of annotations:  
l
"Dataflow annotations" on the next page  
l
"Field and variable annotations" on page 242  
l
"Other annotations" on page 243  
You also can write rules to support your own custom annotations. Contact Customer Support for more  
information.  
Page 239 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix D: Fortify Java annotations  
Dataflow annotations  
There are four types of Dataflow annotations, similar to Dataflow rules: Source, Sink, Passthrough, and  
Validate. All are applied to methods and specify the inputs and/or outputs by parameter name or the  
strings thisand return. Additionally, you can apply the Dataflow Source and Sink annotations to  
the function arguments.  
Source annotations  
The acceptable values for the annotation parameter are this, return, or a function parameter name.  
For example, you can assign taint to an output of the target method.  
@FortifyDatabaseSource("return")  
String [] loadUserProfile(String userID) {  
...  
}
For example, you can assign taint to an argument of the target method.  
void retrieveAuthCode(@FortifyPrivateSource String authCode) {  
...  
}
In addition to specific source annotations, OpenText provides a generic untrusted taint source called  
FortifySource.  
The following is a complete list of source annotations:  
l
FortifySource  
l
FortifyDatabaseSource  
l
FortifyFileSystemSource  
l
FortifyNetworkSource  
l
FortifyPCISource  
l
FortifyPrivateSource  
l
FortifyWebSource  
Passthrough annotations  
Passthrough annotations transfer any taint from an input to an output of the target method. It can  
also assign or remove taint from the output, in the case of FortifyNumberPassthroughand  
FortifyNotNumberPassthrough. The acceptable values for the inannotation parameter are this  
Page 240 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
 
User Guide  
Appendix D: Fortify Java annotations  
or a function parameter name. The acceptable values for the outannotation parameter are this,  
return, or a function parameter name.  
@FortifyPassthrough(in="a",out="return")  
String toLowerCase(String a) {  
...  
}
Use FortifyNumberPassthroughto indicate that the data is purely numeric. Numeric data cannot  
cause certain types of issues, such as cross-site scripting, regardless of the source. Using  
FortifyNumberPassthroughcan reduce false positives of this type. If a program decomposes  
character data into a numeric type (int, int[], and so on), you can use FortifyNumberPassthrough.  
If a program concatenates numeric data into character or string data, then use  
FortifyNotNumberPassthrough.  
The following is a complete list of passthrough annotations:  
l
FortifyPassthrough  
l
FortifyNumberPassthrough  
l
FortifyNotNumberPassthrough  
Sink annotations  
Sink annotations report an issue when taint of the appropriate type reaches an input of the target  
method. Acceptable values for the annotation parameter are thisor a function parameter name.  
@FortifyXSSSink("a")  
void printToWebpage(int a) {  
...  
}
You can also apply the annotation to the function argument or the return parameter. In the following  
example, an issue is reported when taint reaches the argument a.  
void printToWebpage(int b, @FortifyXSSSink String a) {  
...  
}
The following is a complete list of the sink annotations:  
l
FortifySink  
l
FortifyCommandInjectionSink  
l
FortifyPCISink  
l
FortifyPrivacySink  
Page 241 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
User Guide  
Appendix D: Fortify Java annotations  
l
FortifySQLSink  
l
FortifySystemInfoSink  
l
FortifyXSSSink  
Validate annotations  
Validate annotations remove taint from an output of the target method. Acceptable values for the  
annotation parameter are this, return, or a function parameter name.  
@FortifyXSSValidate("return")  
String xssCleanse(String a) {  
...  
}
The following is a complete list of validate sink annotations:  
l
FortifyValidate  
l
FortifyCommandInjectionValidate  
l
FortifyPCIValidate  
l
FortifyPrivacyValidate  
l
FortifySQLValidate  
l
FortifySystemInfoValidate  
l
FortifyXSSValidate  
Field and variable annotations  
You can apply these annotations to fields and (in most cases) variables.  
Password and private annotations  
Use password and private annotations to indicate whether the target field or variable is a password or  
private data.  
@FortifyPassword String x;  
@FortifyNotPassword String pass;  
@FortifyPrivate String y;  
@FortifyNotPrivate String cc;  
In the previous example, string x will be identified as a password and checked for privacy violations  
and hardcoded passwords. The string pass will not be identified as a password. Without the  
Page 242 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
User Guide  
Appendix D: Fortify Java annotations  
annotation, it might cause false positives. The FortifyPrivateand FortifyNotPrivate  
annotations work similarly, only they do not cause privacy violation issues.  
Non-negative and non-zero annotations  
Use these annotations to indicate disallowed values for the target field or variable.  
@FortifyNonNegative int index;  
@FortifyNonZero double divisor;  
In the previous example, an issue is reported if a negative value is assigned to indexor zero is  
assigned to divisor.  
Other annotations  
Check return value annotation  
Use the FortifyCheckReturnValueannotation to add a target method to the list of functions that  
require a check of the return values.  
@FortifyCheckReturnValue  
int openFile(String filename) {  
...  
}
Dangerous annotations  
With the FortifyDangerousannotation, any use of the target function, field, variable, or class is  
reported. Acceptable values for the annotation parameter are CRITICAL, HIGH, MEDIUM, or LOW.  
These values indicat how to categorize the issue based on the Fortify Priority Order values).  
@FortifyDangerous{"CRITICAL"}  
public class DangerousClass {  
@FortifyDangerous{"HIGH"}  
String dangerousField;  
@FortifyDangerous{"LOW"}  
int dangerousMethod() {  
...  
}
}
Page 243 of 244  
OpenText™ Static Application Security Testing (25.2.0)  
 
 
Send Documentation Feedback  
If you have comments about this document, you can contact the documentation team by email.  
Note: If you are experiencing a technical issue with our product, do not email the documentation  
team. Instead, contact Customer Support at https://www.microfocus.com/support so they can  
assist you.  
If an email client is configured on this computer, click the link above to contact the documentation  
team and an email window opens with the following information in the subject line:  
Feedback on User Guide (Static Application Security Testing 25.2.0)  
Just add your feedback to the email and click send.  
If no email client is available, copy the information above to a new message in a web mail client, and  
send your feedback to fortifydocteam@opentext.com.  
We appreciate your feedback!  
Page 244 of 244  
OpenText™ Static Application Security Testing (25.2.0)