How to manage Fortify artifacts in a CI server

Question

How do I manage Fortify artifacts in a CI server?

Answer

Configuring a CI server to manage artifacts produced by a Fortify scan is dependent on the type of CI server in use and the type of artifact. If run in a container, the artifacts must be saved to a location outside the container so they persist after the container is torn down.

The following artifacts must be preserved:

  • Fortify Scan results file (.fpr)
  • Fortify translation logs
  • Fortify scan logs

The Fortify Software Security Center (SSC) may be used to persist the scan results files. The SSC will store and merge the scan results as well as indicate whether the scan triggers the build failure criteria. The scan results file may also be managed locally. If it is managed locally, care must be made to maintain the previously merged scan file so it may be merged into the new scan. Additionally, scans may be large so it may be necessary to move artifacts to a file server that can handle the volume of data.

No similar facility exists for managing Fortify logs, so they must also be managed locally. As with the scan results, the log files may be very large so it may be necessary to move artifacts to a file server that can handle the volume of data. A policy may need to be enforced to limit the number of log files that are maintained.

Fortify Jenkins Plugin

Jenkins may use the Fortify Jenkins Plugin to upload scan files to the SSC. This will enable managing the scan file artifact through the SSC. For log files or scan files managed locally, the Jenkins archiveArtifacts step may be utilized. For example:

post {
    always {
        archiveArtifacts artifacts: 'path/to/logs/*.log', fingerprint: true
    }
}

Fortify Plugin for Bamboo

Bamboo may use the Fortify Plugin for Bamboo to upload scan files to the SSC. This will enable managing the scan file artifact through the SSC.

For log files or scan files managed locally, the artifacts must be defined and the appropriate artifact handler set:

Fortify Azure DevOps Extension

The Fortify Azure DevOps Extension supports uploading scan files to the SSC. This will enable managing the scan file artifact through the SSC.

For log files or scan files managed locally, the log files and scan files, if not managed by the SSC, must be defined as either a build or pipeline artifact. Retention policies should be set to maintain the artifacts appropriately for your system. Artifacts may be collected and published together by either setting the Publish Build Artifacts in the UI or configuring it in the YAML file alongside your code

Docker Container

When running Fortify in a Docker container, artifacts of the scan must be stored outside the container so they persist after the container is torn down. In addition to the ultimate artifacts, intermediate Fortify state must be persisted between the translation and scan phases of the Fortify analysis.

The Docker image must mount a volume or bind mount to store the persisted data. Log file and scan output paths must specify the mounted directory so those artifacts are written to the persistent store.

For example, we will use the -v options to specify a volume to mount in the following examples. The artifacts will be written to the output directory in /scratch_docker.

Translation phase:

docker run -v /scratch_local/:/scratch_docker -v /sources/:/src -it fortify-sca -b <build_id> 
-project-root /scratch_docker 
-fcontainer ["-debug" "-verbose" "-logfile" "/scratch_docker/translate.log"] /src

Scan phase:

docker run -v /scratch_local/:/scratch_docker -it fortify-sca -b <build_id> -project-root /scratch_docker 
-scan -fcontainer ["-debug" "-verbose" "-logfile" "/scratch_docker/scan.log"] 
-f /scratch_docker/results.fpr

The scan results file, results.fpr, and logfiles, translate.log and scan.log file are created in the host’s /scratch_local directory