Fortify SSC Parser Plugin for GitLab Dependency Scanning

Introduction

This Fortify SSC parser plugin allows for importing scan results produced by GitLab Dependency Scanning (also known as Gemnasium).

Plugin Installation

These sections describe how to install, upgrade and uninstall the plugin.

Install & Upgrade

Obtain the plugin binary jar file
- Either download from Bintray (see Related Links)
- Or by building yourself (see Developers)
If you already have another version of the plugin installed, first uninstall the previously
installed version of the plugin by following the steps under Uninstall below
In Fortify Software Security Center:
- Navigate to Administration->Plugins->Parsers
- Click the NEW button
- Accept the warning
- Upload the plugin jar file
- Enable the plugin by clicking the ENABLE button

Uninstall

In Fortify Software Security Center:
- Navigate to Administration->Plugins->Parsers
- Select the parser plugin that you want to uninstall
- Click the DISABLE button
- Click the REMOVE button

Obtain results

Please see the GitLab documentation for details on generated dependency scanning reports.

Upload results

As a 3rd-party results zip bundle:

Generate a scan.info file containing a single line as follows:
engineType=GEMNASIUM
Generate a zip file containing the following:
- The scan.info file generated in the previous step
- The JSON file containing scan results
Upload the zip file generated in the previous step to SSC
- Using any SSC client, for example FortifyClient or Maven plugin
- Or using the SSC web interface
- Similar to how you would upload an FPR file

As raw scan results:

Navigate to the Artifacts tab of your application version
Click the UPLOAD button
Click the ADD FILES button, and select the JSON file to upload
Enable the 3rd party results check box
Select the GEMNASIUM type

Note that uploading raw scan results is only supported for manual uploads through the SSC web interface, and this functionality was removed in SSC 20.2 so no longer available in recent SSC versions. Please submit a feature request if you'd like to see this easier process for ad-hoc uploading of 3rd-party results restored, referencing Octane id #448174.

Developers

The following sections provide information that may be useful for developers of this utility.

IDE's

This project uses Lombok. In order to have your IDE compile this project without errors, you may need to add Lombok support to your IDE. Please see https://projectlombok.org/setup/overview for more information.

Gradle Wrapper

It is strongly recommended to build this project using the included Gradle Wrapper scripts; using other Gradle versions may result in build errors and other issues.

The Gradle build uses various helper scripts from https://github.com/fortify-ps/gradle-helpers; please refer to the documentation and comments in included scripts for more information.

Common Commands

All commands listed below use Linux/bash notation; adjust accordingly if you are running on a different platform. All commands are to be executed from the main project directory.

./gradlew tasks --all: List all available tasks
Build: (plugin binary will be stored in build/libs)
- ./gradlew clean build: Clean and build the project
- ./gradlew build: Build the project without cleaning
- ./gradlew dist distThirdParty: Build distribution zip and third-party information bundle
./fortify-scan.sh: Run a Fortify scan; requires Fortify SCA to be installed

Automated Builds

This project uses GitHub Actions workflows to perform automated builds for both development and production releases. All pushes to the main branch qualify for building a production release. Commits on the main branch should use Conventional Commit Messages; it is recommended to also use conventional commit messages on any other branches.

User-facing commits (features or fixes) on the main branch will trigger the release-please-action to automatically create a pull request for publishing a release version. This pull request contains an automatically generated CHANGELOG.md together with a version.txt based on the conventional commit messages on the main branch. Merging such a pull request will automatically publish the production binaries and Docker images to the locations described in the Related Links section.

Every push to a branch in the GitHub repository will also automatically trigger a development release to be built. By default, development releases are only published as build job artifacts. However, if a tag named dev_<branch-name> exists, then development releases are also published to the locations described in the Related Links section. The dev_<branch-name> tag will be automatically updated to the commit that triggered the build.