This Fortify SSC parser plugin allows for importing scan results from Local PHP Security Checker.

• Downloads: https://github.com/fortify-ps/fortify-ssc-parser-php-security-checker/releases
  • Development releases may be unstable or non-functional. The *-thirdparty.zip file is for informational purposes only and does not need to be downloaded.
• Sample input files: sampleData
• GitHub: https://github.com/fortify-ps/fortify-ssc-parser-php-security-checker
• Automated builds: https://github.com/fortify-ps/fortify-ssc-parser-php-security-checker/actions
• Local PHP Security Checker repository: https://github.com/fabpot/local-php-security-checker

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

• 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

• 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

Please see the Local PHP Security Checker documentation for details on checking applications and generating reports. Note that the SSC parser plugin requires the uploaded reports to be in JSON format.

As a 3^rd-party results zip bundle:

• Generate a scan.info file containing a single line as follows:
  engineType=PHP_SECCHECK
• 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 PHP_SECCHECK 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 3^rd-party results restored, referencing Octane id #448174.

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

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.

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.

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

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.

See LICENSE.TXT