Set up an integration with Fortify
This topic explains how to set up an integration with Fortify, bringing security testing into your development cycle.
This section provides an overview of the Fortify integration and describes its benefits.
What is Fortify?
Fortify is an application security testing service. It performs static code analysis on your application's code, assessing it for potential security vulnerabilities. It can be cloud-based or installed on premises.
Why integrate ALM Octane with Fortify?
Integrate ALM Octane with Fortify to bring security testing into your development cycle:
Identify security vulnerabilities soon after they are introduced into the code and correct them.
Raise developers' awareness, encouraging them to avoid introducing vulnerabilities.
Tip: If you are using a static code analysis tool other than Fortify, you can inject security vulnerability issues detected by the tool into ALM Octane using the ALM Octane REST API. For details, see Add vulnerability issues into ALM Octane.
How does the integration work?
Periodically, during the development cycle, run a pipeline on Jenkins that includes a Fortify on Demand Upload step. After this step uploads the application's code to Fortify on Demand, a security assessment of your code begins.
If the pipeline run is successful, ALM Octane polls the Fortify on Demand server. When the assessment is complete, ALM Octane retrieves the newly found vulnerabilities and displays them in the pipeline run.
To begin, you need to create a script that scans your code for security issues, and generates an .fpr file. Fortify SSC analyzes the .fpr file and generates data on vulnerabilities in your code. After you configure the integration as described below, this data is sent to ALM Octane via Jenkins.
The integration requires two plugins: one to integrate between Jenkins and Fortify SSC, and one to integrate between ALM Octane and Jenkins. After you set up the plugins, run a pipeline in Jenkins that includes a Security Fortify Assessment step, which uploads an .fpr file to SSC for assessment. When the assessment is complete, Jenkins pushes the newly found vulnerabilities to ALM Octane, and they are displayed in the pipeline run.
After reviewing the vulnerabilities, you can create a relevant defect to fix your code, or dismiss and close the issue. For details, see Track security vulnerabilities.
Important privacy note: If your Fortify data contains personally identifiable information (PII), contact your system administrators to check the geographical locations of the Fortify data farm and the ALM Octane server. If the two are located in different geographical locations, verify with your chief information security officer or privacy office that this integration complies with your regional regulations.
This section describes how to set up the integration for Fortify on Demand and the Fortify Software Security Center.
Start by setting up Jenkins to integrate with Fortify on Demand and setting up ALM Octane to integrate with Jenkins:
Set up your Fortify on Demand account. For details, see https://software.microfocus.com/en-us/software/fortify-on-demand.
Define an application whose code you want Fortify on Demand to assess.
We recommend that you run the first security assessment on your code manually and audit it with security experts, before integrating with ALM Octane.
Obtain the URL and API keys required to access the Fortify on Demand server using API. The keys must permit reading vulnerabilities.
Set up Jenkins to upload your code to Fortify on Demand.
Install and configure the Fortify on Demand Uploader plugin on your Jenkins server.
Create a Fortify on Demand Upload step on Jenkins to upload your application's code to Fortify on demand for assessment. In the build step information (BSI) fields, configure the application and release that you used to define your application in your Fortify on Demand account.
Set up ALM Octane integration with your Jenkins server. For details, see Set up CI/CD integration.
Before you begin, you need to have set up the Fortify plugin as described in Fortify Jenkins Plugin (On-Premise). After that, perform the following:
To enable communication between ALM Octane and SSC, obtain an authentication token from SSC as described in the Fortify Software Security Center API documentation > How to Authenticate. This is used by the ALM Octane Jenkins plugin to authenticate to SSC.
Note: The token is created by converting the SSC server login user name and password to Base64 encoding.
Set up the ALM Octane integration with your Jenkins server. For details, see Set up CI/CD integration.
When configuring the Jenkins plugin, in the Parameters section add a parameter called FORTIFY_SSC_TOKEN that contains the SSC authentication token.
For each of the projects you want to scan, create a job in Jenkins that includes a Security Fortify Assessment step to upload the .fpr file to SSC for assessment. Enter the application name and version information as defined for your project in SSC.
This section describes how to set up pipeline that integrates Fortify on Demand and the Fortify Software Security Center.
To set up a pipeline:
In the Pipelines > Pipelines page, add a new pipeline.
In the Type field, select Security.
Depending on your integration, the following then occurs:
Fortify on Demand: After this pipeline runs successfully, ALM Octane polls the Fortify on Demand server, waiting to retrieve the assessment results.
Fortify Software Security Center: The Jenkins plugin checks periodically if there are new scan results in the Software Security Center database. If there are, the new security data is injected to ALM Octane and is displayed on the corresponding pipeline run.
This section describes how to set the configuration options for Fortify on Demand and the Fortify Software Security Center.
By default, ALM Octane checks Fortify on Demand every 2 minutes for 48 hours to see if the scan is finished. If there are more than 100 vulnerabilities, ALM Octane retrieves none.
All these limits can be configured using the following configuration parameters:
By default, the maximum number of vulnerability issues that can be injected for each individual pipeline run is 100. This can be modified using the VULNERABILITIES_PER_PIPELINE_RUN_LIMIT parameter.
For details, see Configuration parameters.