Micro Focus Fortify Static Code Analyzer – Tips and Tricks

Micro Focus Fortify Static Code Analyzer is an automated static code analysis that helps developers eliminate vulnerabilities and build secure software.

This post will have the monthly Fortify Static Code Analyzer Tips and Tricks which will be a consolidation of various common issues in Fortify Static Code Analyzer. Do check out this article for troubleshooting tips and tricks for other tools.

Fortify Static Code Analyzer Tips and Tricks – Jan 2021

Fortify Static Code Analyzer

1. Instruction to solve the translation error on .NET scan

It often happens that after users have upgraded to 20.1 on the .NET scan, they get a translation error. It could be that they have upgraded their Fortify from 19.2 to the recent 20.1 one and when they run a C# scan they get an [error]: 

Translator execution failed. Please consult the Troubleshooting section of the User Manual. DOTNET-Debug: Unhandled exception: Could not load file or assembly 'System.ValueTuple,version=, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' 

Or something similar to one of its dependencies. It happens that the inbuilt assembly manifest definition is not compatible with the assembly reference. There is an exception from HRESULT: 0x80131040

Upgrades are meant to solve all the computer’s small technical problems, Operating System, or any application. If upgrading Fortify from 19.2 to 20.1 results in this error, you need to upgrade something else. You can fix this error while upgrading your .Net  to the latest version, which is 4.72.

2. Tips to easily scan a PHP project which is built with an ANT

Users often find themselves in a problem while scanning a PHP project. Usually, it happens because users are unaware of the various -bt parameters to utilize for ScanCentral on the Command line (-bt). So they usually use ANT, along with build.xml as the specific build file, and then it shows that it is not recognized. You can take the help of some professional tips or tools that help you translate Java source files for specific projects that use an ANT build file.

Users should apply integration on the command line without changing or modifying the ANT build.xml file. Then when the build is activated, the Fortify Static Code Analyzer intercepts all the Java-related task invocations and later translates the input from the Java source files at the time of the compilation.

It is very necessary for you to translate any of the JSP files, configuration files, or even the non-Java source files that are already a part of the application in a different step. While using the ANT integration, the user needs to carefully double-check that the source analyzer executable is on the system PATH. And to prepend your ANT command-line with the source analyzer, you can use the command given below:

Source analyzer -b ant []

3. Solving the error that users get while initiating Fortify Remediation

It often happens with users that when they run Fortify remediation, they come across an error that says:

Error executing Fortify.DownloadlssuesAction

This is a loading issue and the possible causes can be sorted out from the inspection of the database and the logs. Once we are done checking the database and the logs they would find the cause for the error that some kind of corruption caused it in the database or some missing files. This problem can be solved by editing some things and modifying some tables. 

You just need to repeat what is given below in the table, carefully:

Invalid object name 'usersessionstate'.
Invalid object name 'auditcomment'

4. Instructions to fix all the translation errors that occurred while executing the .NET translator

Users have a frequent complaint regarding the translation errors of some of the projects in the solution, often because the way to the location of the translation file is too long. This specific error occurs at the time of the execution of the .NET translator, what actually happens is that it produces an unpredictable exception while the writing of the NST file :


As it is quite evident that the specified path, name of the file, either of them is too lengthy. It is of utmost importance that the qualified file name needs to be less than 260 characters. The users should then note that it is different for the directory name; it should be less than 248 characters.

In the Windows API, definitely, with some exceptions, there is a limit too. For Windows API, the maximum length of a path should be approximately 260 characters (numbers and alphabets), that is MAX_PATH. Usually, a local path is made/created in the order that is given below:

  1. Drive letter
  2. Colon
  3. Backslash
  4. Backslashes are separating various name components.
  5. A terminating null character.

5. Instructions to utilize the Fortify SCA plugin aggregate results accurately

It is necessary to understand the formalities and technical details about ending all of the scan information for the projects or sub-projects that go into the same FPR.

That specific site is using the fortify plugin in the sequence for some projects given below:

<file> <exists>../ias-services-impl</exists> </file>

The project repository holds multiple modules, for example :


This specific project is structured in a way that it is situated at the root. As these are merely submodules, they are made that way so that when it is needed, they can trigger a downstream job of initiating a complete scan at the base\level. The users can see that the logs are that the aggregate flag that is set to true. When checked through the plugin documentation and trying on our own to unset the value, it is proven to be a failure. Even after trying different things, all the sub-projects’ scan information goes directly into the same FPR again.

You can try visiting the following location that is situated in the directory:

Fortify_SCA_and_Apps_(version)\\plugins\\maven, unzip maven-plugin-bin.zip 

You need to go to the docs\\index.html; then, you need to open the file in a particular browser editor. After that, you need to select Usage, then click on Direct Invocation, and then you will be able to find the property:


The same property can easily be changed from true to false, which will surely stop this behavior. 

eg -Dfortify.sca.aggregate=false

6. Fixing the shortage of storage due to lack of use of the swap space

While using the audit workbench for analysis purposes regarding the 660 KLoc of Java code, this error occurs. The said process runs non-stop for around a Fortnite on the device. This experience is of a user with a device that has a CPU of 80 and 750 GB RAM.

The Fortify in that device is using about all of the 80 CPU and 95% of the RAM, 717 GB. It was later taken notice that after 2-3 days, the RAM usage simultaneously increased to 717 GB that is it, and after that, it has not increased at all.

The performance is slow; the progress is almost equal to none. Even though no other application is running on the machine, except for the SSCSTate and the process/resource tracking.

The user’s query arises here as they cannot understand the root cause and if they were unknowingly crossing the memory limit. How to know to set up the run that reminds  Fortify needs to swap space? 

The obvious solution would seem to be through AWB, but instead of running a scan from AWB, you can utilize the source analyzer for this procedure. Using both of them could cause a storage/memory issue that is the malfunctioning root cause.

Users should use this effective procedure to prevent the repetition of the same error. You can then use the source analyzer all the time for such scanning purposes. There are patches available like SCA 19.2.1 patch. It has all the recent upgrades and changes regarding the improvement areas. 

7. Steps for utilizing Fortify to scan Gradle C++ code

While running a simple complete scan on a sample Gradle C++ project, it happens that users encounter an error.


It usually builds accurately without any difficulty, with the command that is given below:

gradle clean buildWe add :sourceanalyzer -b testBuild gradle clean build and it is returning an error: FAILURE: Build failed with an exception.--------------------------------------------------------------------------------------------------------------------------
A problem occurred evaluating root project 'sample-c-project'.> Failed to apply plugin [id 'org.gradle.java'] > Cannot add task 'test' as a task with that name already exists.--------------------------------------------------------------------------------------------------
We are using Gradle version 4.10.2. I have the sca.log file and sample code. I will upload the ticket as soon as it is available.

Usually, the reason behind this error could be that the build.gradle file was made to find the CPP files. Later it is noticed that even when we run it using the original build.gradle, it does not create any output files at all.

After that, you need to update the build.gradle, and that will help you look for .c files, too, then the compilation will be done. Later by adding the source analyzer commands and then the translation runs perfectly. You can check the performance by the “-show-files” parameters, that views all the details such as the “free.c” file.

The build.gradle is usually offered a sample project that is meant to build the C++ applications, that specific sample project merely contains a .c file. That is the main purpose why the Gradle build was executed, after nothing could be found to build, it was successful.

For the translation, when the source analyzer was utilized, that was when the error appeared. The cause, to put it simply, was that SCA was not able to translate the files because there were no Gradle files. When the new-build.gradle.zip is uploaded to the case, it comes with a build.

The Gradle file helps compile the .c file that was previously a part of the sample project. Even while using Source Analyzer, it will translate the .c file accurately without any difficulty.

8. Solving the Fortify Static Code Analyzer Azure Build Pipelines Extension failure issue

The user had often tried to install Fortify SCA, either the 20.1.0 or the 20.1.4 patch again. That helps in verifying PATH variables to check if the MSBuild, devenv, and source analyzer were added to the system variable. Yet, the error remained regarding the Fortify Extension verification of source analyzer. You can solve this issue with the help of the steps given below:

1. You need to try uninstalling the previous Fortify Extension from Azure DevOps UI.

2. Then you need to remove the temp folders, like the ones that are given below:

C:\Users\{Username}\AppData\Local\Microsoft\Team Foundation\{Version}\Cache\{UID Folder}
*{Agent Folder}\_Work\

3. Then, you need to clear all of the browser caches, like the browser that was used for the accession of AzureDevOps UI.

4. After that, you need to install the Fortify Extension for AzureDevOps (Formerly TFS)

5. Then restart the Agent Service carefully.

6. Now you need to run a complete scan task in AzureDevOps.

Once these steps were followed carefully, the problem should be solved and the user should be able to detect the Source Analyzer version from Fortify Extension in Azure DevOps.

9. Instructions to solve the DISA STIG 4.10 Report No Longer Visible error

It often happens that after the installation of the Latest Windows patch, an error appears on the screen, which says: DISA STIG 4.10 Report No Longer Visible. This means that after installing the patch, the patch user would be using version and cannot see the DISA STIG 4.10 as an option while creating a BIRT report.

You can solve this issue by simply copying the line from the ReportTemplates.xml for SCA version 19.2.1 and then paste it into the ReportTemplates.xml for SCA version After this is done you will be able to find all of the files that are under the SCA installation path. It is the same path that you had used earlier while updating the SCA.

10. Instructions to enable the reports in BIRTReportGenerator command on MacOS

It often happens that the users cannot produce a report through the BIRTReportGenerator command on MacOS. 

1. You need to copy the file below:

Fortify_SCA_and_Apps_20.1.0/Auditworkbench.app to the directory


2. Then in the file /opt/Fortify/Fortify_SCA_and_Apps_20.1.0/bin/BIRTReportGenerator

  • You need to comment the following:
for param in "$@"
if [ "$param" = "$DEBUG" ]; then
PARAMS="${PARAMS} -Dcom.fortify.Debug=true"
PARAMS="${PARAMS} ${param} "
for param in "$@"
if [ "$param" = "$DEBUG" ]; then
PARAMS="${PARAMS} -Dcom.fortify.Debug=true"
PARAMS="${PARAMS} ${param} "
  • Then in the following line, you need to change “$PARAMS” to “$@”
"${MACOS_DIR}/eclipse" ${JAVA_VM} -name "Fortify Report Generation" -noSplash --launcher.suppressErrors -application com.hp.fortify.birt.report.generator.console.Application -data "${DATA_DIR}" -configuration "${CONFIG_DIR}" "$PARAMS" -consoleLog -vmargs -Djava.awt.headless=true -Dcom.fortify.InstallRoot="${BASE_DIR}" -Dcom.fortify.awb.cwd="${CWD}" -Xmx1500M
"${MACOS_DIR}/eclipse" ${JAVA_VM} -name "Fortify Report Generation" -noSplash --launcher.suppressErrors -application com.hp.fortify.birt.report.generator.console.Application -data "${DATA_DIR}" -configuration "${CONFIG_DIR}" "$@" -consoleLog -vmargs -Djava.awt.headless=true -Dcom.fortify.InstallRoot="${BASE_DIR}" -Dcom.fortify.awb.cwd="${CWD}" -Xmx1500M
  • Then you need to save the BIRTReportGenerator file.
  • Then you need to run the report; an example is given below:        

BIRTReportGenerator -template “Developer Workbook” -source eightball.fpr -format PDF -output eightball_birtrpt.pdf