Name	Name	Last commit message	Last commit date
Latest commit rsenden Merge pull request #53 from fortify/release-please--branches--main--c… Sep 27, 2024 b69c924 · Sep 27, 2024 History 136 Commits
.github/workflows	.github/workflows	fix: Use proper branch names / versions for sub-action invocations	Nov 28, 2023
doc-resources	doc-resources	chore: Prepare for next release	Sep 25, 2024
fod-export	fod-export	chore: Update action references	Sep 27, 2024
fod-sast-scan	fod-sast-scan	chore: Update action references	Sep 27, 2024
internal	internal	chore: Update action references	Sep 27, 2024
package	package	chore: Update action references	Sep 27, 2024
sc-sast-scan	sc-sast-scan	chore: Update action references	Sep 27, 2024
setup	setup	fix: Update to fcli 2.7.1 to fix FoD job summary exception	Sep 27, 2024
ssc-debricked-scan	ssc-debricked-scan	chore: Update action references	Sep 27, 2024
ssc-export	ssc-export	chore: Update action references	Sep 27, 2024
.gitignore	.gitignore	Initial setup action	Sep 21, 2023
CHANGELOG.md	CHANGELOG.md	chore(main): release 1.3.1	Sep 27, 2024
CODE_OF_CONDUCT.md	CODE_OF_CONDUCT.md	chore: Restructuring, initial documentation	Sep 29, 2023
CONTRIBUTING.md	CONTRIBUTING.md	docs: Add samples	Oct 30, 2023
LICENSE.txt	LICENSE.txt	feat: Add support for updateable/customizable tool definitions	Feb 5, 2024
README.md	README.md	chore: Prepare for next release	Sep 25, 2024
USAGE.md	USAGE.md	chore: Restructuring, initial documentation	Sep 29, 2023
action.yml	action.yml	chore: Update action references	Sep 27, 2024
configure.sh	configure.sh	chore: Prepare for next release	Sep 25, 2024
update-action-refs.sh	update-action-refs.sh	fix: Use proper branch names / versions for sub-action invocations	Nov 28, 2023
version.txt	version.txt	chore(main): release 1.3.1	Sep 27, 2024

fortify/github-action@v1

Fortify Application Security provides your team with solutions to empower DevSecOps practices, enable cloud transformation, and secure your software supply chain. As the sole Code Security solution with over two decades of expertise and acknowledged as a market leader by all major analysts, Fortify delivers the most adaptable, precise, and scalable AppSec platform available, supporting the breadth of tech you use and integrated into your preferred toolchain. We firmly believe that your great code demands great security, and with Fortify, go beyond 'check the box' security to achieve that.

The Fortify github-action repository hosts various Fortify-related GitHub Actions as listed in the sections below.

Fortify on Demand

fortify/github-action
For now, this action provides the same functionality as the fod-sast-scan action listed below. Future versions may add support for running other types of scans or performing other FoD operations.
fortify/github-action/fod-sast-scan
Package source code, submit static application security testing (SAST) scan request to Fortify on Demand, optionally wait for completion and export results back to the GitHub Security dashboard.
fortify/github-action/package
Package source code for running a SAST scan, using the latest version of ScanCentral Client. Optionally resolve dependencies for Software Composition Analysis (SCA) of open source components with integrated Debricked analysis via Fortify on Demand.
fortify/github-action/fod-export
Export SAST vulnerability data from Fortify on Demand to the GitHub Security dashboard.
fortify/github-action/setup
Install various Fortify tools like fcli, ScanCentral Client, FortifyVulnerabilityExporter and FortifyBugTrackerUtility for use in your pipeline

Fortify Sofware Security Center (SSC) / ScanCentral SAST / Debricked

fortify/github-action
Depending on inputs, this action will run either or both a ScanCentral SAST and Debricked Software Composition Analysis (SCA) scan and publish scan results to SSC. Future versions may add support for running other types of scans or performing other SSC / ScanCentral operations.
fortify/github-action/sc-sast-scan
Run a ScanCentral SAST and optionally Debricked Software Composition Analysis scan by packaging source code, submitting ScanCentral SAST scan and optional Debricked scan request, and optionally waiting for completion and exporting SAST results back to the GitHub Security dashboard.
fortify/github-action/ssc-debricked-scan
Run a Debricked Software Composition Analysis scan and publish scan results to SSC, optionally waiting for scan results to be fully processed on SSC.
fortify/github-action/package
Package source code for running a SAST scan, using the latest version of ScanCentral Client.
fortify/github-action/ssc-export
Export SAST vulnerability data from Fortify SSC to the GitHub Security dashboard.
fortify/github-action/setup
Install various Fortify tools like fcli, ScanCentral Client, FortifyVulnerabilityExporter and FortifyBugTrackerUtility for use in your pipeline

fortify/github-action

The primary fortify/github-action action currently allows for running SAST and optional Software Composition Analysis scans on either Fortify on Demand or ScanCentral SAST / Debricked. Which activities to perform is controlled through action inputs, the input for those activities is provided through environment variables.

Based on inputs and environment variables, this action will simply configure and run one of the following sub-actions:

Conditions	Sub-action
`sast-scan: true` `FOD_URL` specified	`fortify/github-action/fod-sast-scan`
`sast-scan: true` `SSC_URL` specified	`fortify/github-action/sc-sast-scan`
`sast-scan: false` `debricked-sca-scan: true` `SSC_URL` specified	`fortify/github-action/ssc-debricked-scan`

If none of the conditions listed above are met, this action will complete without performing any work.

Prerequisites

This action assumes the standard software packages as provided by GitHub-hosted runners to be available. If you are using self-hosted runners, you may need to install some of these software packages in order to successfully use this action. In particular, not having the following software installed is known to cause issues when running fortify/github-action or one of its sub-actions:

Node.js
Visual C++ Redistributable (Windows-based runners only)
Bash shell
If using Windows runners, this must be a Windows-based bash variant, for example as provided by MSYS2. You must make sure that this Windows-based bash variant is used for run steps that specify shell: bash. Actions will fail if the GitHub runner executes bash commands on the WSL-provided bash.exe

Depending on inputs, additional prerequisites may apply as listed in the documentation for the sub-actions listed in the table above.

Action inputs

sast-scan - OPTIONAL
When set to true, the action will run a SAST scan on either Fortify on Demand (if the FOD_URL environment variable has been specified), or on ScanCentral SAST (if the SSC_URL environment variable has been specified). This includes packaging the source code, running the scan, and optionally reporting SAST scan results back into GitHub.

If not specified or when set to false, no SAST scan will be performed. For FoD, this means that the action will complete without doing any work. For SSC, the action could still run a Debricked-only scan based on the debricked-sca-scan input as listed below. Future versions of this action may provide additional inputs, for example allowing you to run a dynamic application security testing (DAST) scan instead of (or in combination with) a SAST scan.

debricked-sca-scan - OPTIONAL
(Not applicable to Fortify on Demand) When set to true, the action will run a Debricked Software Composition Analysis (SCA) scan and publish the results to Fortify SSC. You can either run a Debricked-only scan (sast-scan set to false), or both SAST and Debricked SCA scan if both inputs are set to true.

Action environment variable inputs

Fortify on Demand

FOD_URL - REQUIRED
Fortify on Demand URL, for example https://ams.fortify.com. Note: Using GitHub Secrets to define this URL may cause links back to FoD to be rendered incorrectly, for example in GitHub Action workflow summaries. It is highly recommended to either hard-code the URL in your workflow, or to use GitHub Variables instead of GitHub Secrets.

FOD_CLIENT_ID & FOD_CLIENT_SECRET - REQUIRED*
Required when authenticating with an API key: FoD Client ID (API key) and Secret (API secret).

FOD_TENANT, FOD_USER & FOD_PASSWORD - REQUIRED*
Required when authenticating with user credentials: FoD tenant, user and password. It's recommended to use a Personal Access Token instead of an actual user password.

EXTRA_FOD_LOGIN_OPTS (deprecated), FOD_LOGIN_EXTRA_OPTS - OPTIONAL
Extra FoD login options, for example for disabling SSL checks or changing connection time-outs; see fcli fod session login documentation

FOD_RELEASE - OPTIONAL
Fortify on Demand release to use with this action. This can be specified either as a numeric release id, <app-name>:<release-name> (for non-microservices applications) or <app-name>:<microservice-name>:<release-name> (for microservices applications). Default value is <github.repository>:<github.head_ref || github.ref_name>, for example myOrg/myRepo:myBranch. Note that you'll need to explicitly configure FOD_RELEASE for microservices applications, as the default value lacks a microservice name.

DO_SETUP, SETUP_ACTION, SETUP_EXTRA_OPTS - OPTIONAL
If DO_SETUP is set to true (implied if any of the other two SETUP_* variables are set), this action will set up the FoD release / SSC application version, creating those if they do not yet exist, using the fcli-provided FoD setup-release or SSC setup-appversion action, or, if specified, the custom fcli action specified through SETUP_ACTION. SETUP_ACTION may point to a local file or URL; this custom fcli action must support (at least) the exact same action parameters (including any environment variable based default values for those parameters) as the built-in fcli action. Any extra options for the fcli action can be passed through the SETUP_EXTRA_OPTS environment variable, for example to copy from an existing release/application version, or to allow an unsigned custom action to be used.

Note that if setup is enabled, FOD_RELEASE or SSC_APPVERSION must be configured with a qualified release/version name; you cannot use release/version id.

If FoD Software Composition Analysis has been purchased and configured on the applicable release, you'll need to pass the -oss option through this environment variable to generate and package the additional dependency files required.

Based on the automated build tool detection feature provided by ScanCentral Client, this default scancentral command is often sufficient to properly package application source code. Depending on your build setup, you may however need to configure the PACKAGE_EXTRA_OPTS environment variable to specify additional packaging options.

As an example, if the build file that you want to use for packaging doesn't adhere to common naming conventions, you can configure the -bf <custom build file> option using the PACKAGE_EXTRA_OPTS environment variable. See Command-line options for the package command for more information on available options.

EXTRA_FOD_SAST_SCAN_OPTS (deprecated), FOD_SAST_SCAN_EXTRA_OPTS - OPTIONAL
Extra FoD SAST scan options; see fcli fod sast-scan start documentation

DO_WAIT - OPTIONAL
By default, this action will not wait until scans have been completed. To have the workflow wait until all scans have been completed, set the DO_WAIT environment variable to true. Note that some other environment variables imply DO_WAIT, for example when exporting vulnerability data or generating job summaries. This behavior is documented in the applicable environment variable descriptions.

DO_POLICY_CHECK, CHECK_POLICY_ACTION, CHECK_POLICY_EXTRA_OPTS - OPTIONAL
If DO_POLICY_CHECK is set to true (implied if any of the other two CHECK_POLICY_* variables are set, and implies DO_WAIT), a policy check will be run after scan completion using the fcli-provided FoD check-policy or SSC check-policy action or, if specified, the custom fcli action specified through CHECK_POLICY_ACTION. POLICY_CHECK_ACTION may point to a local file or URL; this custom fcli action must accept at least the --av (for SSC) or --rel (for FoD) option. Any extra options for this custom fcli action can be passed through the CHECK_POLICY_EXTRA_OPTS environment variable, which may include fcli options to allow unsigned custom actions to be used. Note that for FoD, the fcli-provided check-policy action will check the outcome of the FoD security policy. As SSC doesn't provide any similar security policy features, the fcli-provided action executes some sample policy checks that will likely fail in many cases. As security policies are different for every Fortify customer, you should consider implementing your own custom fcli policy check action(s), unless FoD-provided security policy functionality is sufficient.

DO_JOB_SUMMARY, JOB_SUMMARY_ACTION, JOB_SUMMARY_EXTRA_OPTS - OPTIONAL
If DO_JOB_SUMMARY is set to true (implied if any of the other two JOB_SUMMARY_* variables are set, and implies DO_WAIT), this action will generate a job summary listing scan status and issue counts using the fcli-provided FoD release-summary or SSC appversion-summary action, or, if specified, the custom fcli action specified through JOB_SUMMARY_ACTION. JOB_SUMMARY_ACTION may point to a local file or URL; this custom fcli action must support (at least) the exact same action parameters (including any environment variable based default values for those parameters) as the built-in fcli action. Any extra options for the fcli action can be passed through the JOB_SUMMARY_EXTRA_OPTS environment variable, for example to specify the SSC filter sets to be included in the summary, or to allow an unsigned custom action to be used.

DO_EXPORT, EXPORT_ACTION, EXPORT_EXTRA_OPTS - OPTIONAL
If DO_EXPORT is set to true (implied if any of the other two EXPORT_* variables are set, and implies DO_WAIT) or when explicitly invoking the fortify/github-action/fod-export or fortify/github-action/ssc-export actions, this action will will export scan results to the GitHub Security Code Scanning dashboard using the fcli-provided FoD github-sast-report or SSC github-sast-action action or, if specified, the custom fcli action specified through EXPORT_ACTION. EXPORT_ACTION may point to a local file or URL; this custom fcli action must support (at least) the exact same action parameters (including any environment variable based default values for those parameters) as the built-in fcli action. Any extra options for the fcli action can be passed through the EXPORT_EXTRA_OPTS environment variable, for example to specify the SSC filter set from which to load issue data, or to allow an unsigned custom action to be used.

Note that this may require a GitHub Advanced Security subscription, unless you're running this action on a public github.com repository. GitHub only supports importing SAST results; other results will not exported to GitHub.

DO_PR_COMMENT, PR_COMMENT_ACTION, PR_COMMENT_EXTRA_OPTS - OPTIONAL (PREVIEW)
If DO_PR_COMMENT is set to true (implied if any of the other two PR_COMMENT_* variables are set, and implies DO_WAIT), this action will generate a pull request comment listing new, re-introduced and removed issues using the fcli-provided FoD github-pr-comment or SSC github-pr-comment action or, if specified, the custom fcli action specified through PR_COMMENT_ACTION. PR_COMMENT_ACTION may point to a local file or URL; this custom fcli action must support (at least) the exact same action parameters (including any environment variable based default values for those parameters) as the built-in fcli action. Any extra options for the fcli action can be passed through the PR_COMMENT_EXTRA_OPTS environment variable, for example to specify the SSC filter set from which to load issue data, or to allow an unsigned custom action to be used.

Note that pull request comments will only be generated under the following conditions:

Standard GITHUB_REF_NAME environment variable points to a pull request, which is only the case on GitHub pull_request triggers and not for example manual triggers (even if the branch is associated with a current pull request).
All other standard GitHub environment variables like GITHUB_TOKEN, GITHUB_REPOSITORY and GITHUB_SHA are set.

PR comments are generated by comparing scan results from the current GitHub Action run against the previous scan in the same application version/release; it won't detect any new/removed issues from older scans. For best results, you should configure your workflow as follows:

For any branches for which you might want to generate PR comments, have the workflow trigger only on pull_request events. Note that you can have a single workflow that is triggered on both push events for your main branch, and only pull_request events for all other branches.
Don't set FOD_RELEASE or SSC_APPVERSION, to use the default value that corresponds to repository and branch name.
Set DO_RELEASE_SETUP or DO_APPVERSION_SETUP to true, to allow a branch-specific application version/release to be automatically created.
Include --copy-from option in RELEASE_SETUP_EXTRA_OPTS or APPVERSION_SETUP_EXTRA_OPTS to copy state from the version/release that represents the PR target branch into the newly created application version/release.

With a setup like this, whenever a new PR is created, the GitHub Action will:

Create a new application version/release named <repository owner>/<repository name>:<branch name>.
Copy state from the application version/release identified by the --copy-from option to this new application version/release.
Run a new scan of the branch associated with the current PR, and upload results to the application version/release created above.
Generate a PR comment listing new and removed issues, based on comparing the results of the new scan that was run in the previous step against the scan results that were copied from the version/release identified by the --copy-from option.

If any subsequent updates are pushed to the PR and the workflow is also being triggered on PR update events, the GitHub Action will run a new scan of the branch associated with the PR, publish results to the existing branch-specific application version/release, and generate a new PR comment that shows any new/removed issues in the new scan compared to the previous scan for the same branch/PR.

TOOL_DEFINITIONS - OPTIONAL
Fortify tool definitions are used by this GitHub Action to determine available versions, download location and other details of various Fortify-related tools, as required for action execution. By default, the Fortify-provided tool definitions hosted at https://github.com/fortify/tool-definitions/releases/tag/v1 will be used.

This environment variable allows for overriding the default tool definitions, pointing to either a URL or local (workspace) file. For example, if GitHub workflows are not allowed to download tools from their public internet locations, customers may host the tool installation bundles on an internal server, together with a customized tool definitions bundle that lists the alternative download URLs.

ScanCentral SAST with optional Debricked scan

SSC_URL - REQUIRED
Fortify Software Security Center URL, for example https://ssc.customer.fortifyhosted.net/. Note: Using GitHub Secrets to define this URL may cause links back to SSC to be rendered incorrectly, for example in GitHub Action workflow summaries. It is highly recommended to either hard-code the URL in your workflow, or to use GitHub Variables instead of GitHub Secrets.

SSC_TOKEN - REQUIRED*
Required when authenticating with an SSC token (recommended). Most actions should work fine with a CIToken.

SSC_USER & SSC_PASSWORD - REQUIRED*
Required when authenticating with SSC user credentials.

EXTRA_SSC_LOGIN_OPTS (deprecated), SSC_LOGIN_EXTRA_OPTS - OPTIONAL
Extra SSC login options, for example for disabling SSL checks or changing connection time-outs; see fcli ssc session login documentation.

SC_SAST_TOKEN - REQUIRED
Required: ScanCentral SAST Client Authentication Token for authenticating with ScanCentral SAST Controller.

EXTRA_SC_SAST_LOGIN_OPTS (deprecated), SC_SAST_LOGIN_EXTRA_OPTS - OPTIONAL
Extra ScanCentral SAST login options, for example for disabling SSL checks or changing connection time-outs; see fcli sc-sast session login documentation.

DO_DEBRICKED_SCAN - OPTIONAL
If set to true, this action will run both ScanCentral SAST and Debricked Software Composition Analysis (SCA) scans and publish both results to SSC. This is equivalent to setting the debricked-sca-scan input on the top-level fortify/github-action action. Note that this requires the Fortify SSC Parser Plugin for Debricked results to be installed on Fortify SSC, to allow for SSC to accept and process the Debricked scan results submitted by this action.

DEBRICKED_TOKEN - REQUIRED*
Required when performing a Debricked Software Composition Analysis scan; see the Generate access token section in the Debricked documentation for details on how to generate this token.

SSC_APPVERSION - OPTIONAL
Fortify SSC application version to use with this action. This can be specified either as a numeric application version id, or by providing application and version name in the format <app-name>:<version-name>. Default value is <github.repository>:<github.head_ref || github.ref_name>, for example myOrg/myRepo:myBranch.

Note that if setup is enabled, FOD_RELEASE or SSC_APPVERSION must be configured with a qualified release/version name; you cannot use release/version id.

EXTRA_PACKAGE_OPTS (deprecated), PACKAGE_EXTRA_OPTS - OPTIONAL
By default, this action runs scancentral package -o package.zip to package application source code. Based on the automated build tool detection feature provided by ScanCentral Client, this default scancentral command is often sufficient. Depending on your build setup, you may however need to configure the PACKAGE_EXTRA_OPTS environment variable to specify additional packaging options.

SC_SAST_SENSOR_VERSION - REQUIRED
Version of the ScanCentral SAST sensor on which the scan should be performed. See fcli sc-sast scan start documentation for details.

EXTRA_SC_SAST_SCAN_OPTS (deprecated), SC_SAST_SCAN_EXTRA_OPTS - OPTIONAL
Extra ScanCentral SAST scan options; see fcli sc-sast scan start documentation

Note that pull request comments will only be generated under the following conditions:

Standard GITHUB_REF_NAME environment variable points to a pull request, which is only the case on GitHub pull_request triggers and not for example manual triggers (even if the branch is associated with a current pull request).
All other standard GitHub environment variables like GITHUB_TOKEN, GITHUB_REPOSITORY and GITHUB_SHA are set.

For any branches for which you might want to generate PR comments, have the workflow trigger only on pull_request events. Note that you can have a single workflow that is triggered on both push events for your main branch, and only pull_request events for all other branches.
Don't set FOD_RELEASE or SSC_APPVERSION, to use the default value that corresponds to repository and branch name.
Set DO_RELEASE_SETUP or DO_APPVERSION_SETUP to true, to allow a branch-specific application version/release to be automatically created.
Include --copy-from option in RELEASE_SETUP_EXTRA_OPTS or APPVERSION_SETUP_EXTRA_OPTS to copy state from the version/release that represents the PR target branch into the newly created application version/release.

With a setup like this, whenever a new PR is created, the GitHub Action will:

Create a new application version/release named <repository owner>/<repository name>:<branch name>.
Copy state from the application version/release identified by the --copy-from option to this new application version/release.
Run a new scan of the branch associated with the current PR, and upload results to the application version/release created above.
Generate a PR comment listing new and removed issues, based on comparing the results of the new scan that was run in the previous step against the scan results that were copied from the version/release identified by the --copy-from option.

Debricked-only scan and publish to SSC

SSC_TOKEN - REQUIRED*
Required when authenticating with an SSC token (recommended). Most actions should work fine with a CIToken.

SSC_USER & SSC_PASSWORD - REQUIRED*
Required when authenticating with SSC user credentials.

DEBRICKED_TOKEN - REQUIRED
See the Generate access token section in the Debricked documentation for details on how to generate this token.

Note that if setup is enabled, FOD_RELEASE or SSC_APPVERSION must be configured with a qualified release/version name; you cannot use release/version id.

Note that pull request comments will only be generated under the following conditions:

Standard GITHUB_REF_NAME environment variable points to a pull request, which is only the case on GitHub pull_request triggers and not for example manual triggers (even if the branch is associated with a current pull request).
All other standard GitHub environment variables like GITHUB_TOKEN, GITHUB_REPOSITORY and GITHUB_SHA are set.

For any branches for which you might want to generate PR comments, have the workflow trigger only on pull_request events. Note that you can have a single workflow that is triggered on both push events for your main branch, and only pull_request events for all other branches.
Don't set FOD_RELEASE or SSC_APPVERSION, to use the default value that corresponds to repository and branch name.
Set DO_RELEASE_SETUP or DO_APPVERSION_SETUP to true, to allow a branch-specific application version/release to be automatically created.
Include --copy-from option in RELEASE_SETUP_EXTRA_OPTS or APPVERSION_SETUP_EXTRA_OPTS to copy state from the version/release that represents the PR target branch into the newly created application version/release.

With a setup like this, whenever a new PR is created, the GitHub Action will:

Create a new application version/release named <repository owner>/<repository name>:<branch name>.
Copy state from the application version/release identified by the --copy-from option to this new application version/release.
Run a new scan of the branch associated with the current PR, and upload results to the application version/release created above.
Generate a PR comment listing new and removed issues, based on comparing the results of the new scan that was run in the previous step against the scan results that were copied from the version/release identified by the --copy-from option.

Sample workflows

The sample workflows below demonstrate how to configure the action for running a SAST scan on either Fortify on Demand or ScanCentral SAST.

Fortify on Demand

    steps:    
      - name: Check out source code
        uses: actions/checkout@v4  
      - name: Run FoD SAST Scan
        uses: fortify/github-action@v1
        with:
          sast-scan: true
        env:
          FOD_URL: https://ams.fortify.com
          FOD_TENANT: ${{secrets.FOD_TENANT}}
          FOD_USER: ${{secrets.FOD_USER}}
          FOD_PASSWORD: ${{secrets.FOD_PAT}}
          # FOD_LOGIN_EXTRA_OPTS: --socket-timeout=60s
          # FOD_RELEASE: MyApp:MyRelease
          # PACKAGE_EXTRA_OPTS: -oss
          # DO_WAIT: true
          # DO_EXPORT: true
          # TOOL_DEFINITIONS: https://ftfy.mycompany.com/tool-definitions/v1/tool-definitions.yaml.zip

ScanCentral SAST with optional Debricked scan

    steps:    
      - name: Check out source code
        uses: actions/checkout@v4  
      - name: Run ScanCentral SAST Scan
        uses: fortify/github-action@v1
        with:
          sast-scan: true
          # debricked-sca-scan: true
        env:
          SSC_URL: ${{vars.SSC_URL}}
          SSC_TOKEN: ${{secrets.SSC_TOKEN}}
          # SSC_LOGIN_EXTRA_OPTS: --socket-timeout=60s
          SC_SAST_TOKEN: ${{secrets.CLIENT_AUTH_TOKEN}}
          # SC_SAST_LOGIN_EXTRA_OPTS: --socket-timeout=60s
          # SSC_APPVERSION: MyApp:MyVersion
          # PACKAGE_EXTRA_OPTS: -bf custom-pom.xml
          SC_SAST_SENSOR_VERSION: 23.2
          # DO_DEBRICKED_SCAN: true  # Or debricked-sca-scan input on top-level action
          # DEBRICKED_TOKEN: ${{secrets.DEBRICKED_TOKEN}}
          # DO_WAIT: true
          # DO_EXPORT: true
          # TOOL_DEFINITIONS: https://ftfy.mycompany.com/tool-definitions/v1/tool-definitions.yaml.zip

Debricked-only scan and publish to SSC

    steps:    
      - name: Check out source code
        uses: actions/checkout@v4  
      - name: Run Debricked Scan
        uses: fortify/github-action@v1
        with:
          sast-scan: false
          debricked-sca-scan: true
        env:
          SSC_URL: ${{vars.SSC_URL}}
          SSC_TOKEN: ${{secrets.SSC_TOKEN}}
          # SSC_LOGIN_EXTRA_OPTS: --socket-timeout=60s
          # SSC_APPVERSION: MyApp:MyVersion
          DEBRICKED_TOKEN: ${{secrets.DEBRICKED_TOKEN}}
          # DO_WAIT: true
          # TOOL_DEFINITIONS: https://ftfy.mycompany.com/tool-definitions/v1/tool-definitions.yaml.zip

More information

Depending on input, this action delegates to the appropriate sub-action(s). Please refer to the documentation of these actions for a more detailed description of action behavior & requirements:

FoD SAST & optional SCA (open source) scan: fortify/github-action/fod-sast-scan
ScanCentral SAST scan: fortify/github-action/sc-sast-scan

fortify/github-action/setup

This action allows for setting up the Fortify tools listed below. Which tools and which versions to install, and whether to add the tool bin-directories to the system path, is controlled through action inputs as listed in the next section.

Prerequisites

Node.js
Visual C++ Redistributable (Windows-based runners only)
Bash shell
If using Windows runners, this must be a Windows-based bash variant, for example as provided by MSYS2. You must make sure that this Windows-based bash variant is used for run steps that specify shell: bash. Actions will fail if the GitHub runner executes bash commands on the WSL-provided bash.exe

Action inputs

export-path - OPTIONAL
Whether to add the installed tools to the system PATH variable. Allowed values: true (default) or false

tool-definitions - OPTIONAL Allows for overriding the location of the Fortify tool definitions bundle. This can be specified either as an action input or through the TOOL_DEFINITIONS environment variable; see the 'Action environment variable inputs' section below for details.

fcli - OPTIONAL
The fcli version to install. Allowed values: skip (default value, do not install fcli), latest, or specific version number. Supports semantic versioning, for example v2 will install the latest known 2.x.y version. Version may be specified either with or without the v prefix, for example v2.0.0 and 2.0.0 are semantically the same.

sc-client - OPTIONAL
The ScanCentral Client version to install. Allowed values: skip (default value, do not install), latest, or specific version number. Supports semantic versioning, for example 23.1 will install the latest known 23.1.y patch version. Version may be specified either with or without the v prefix, for example v23.1 and 23.1 are semantically the same.

fod-uploader - OPTIONAL
The FoDUploader version to install. Allowed values: skip (default value, do not install), latest, or specific version number. Supports semantic versioning, for example v5 will install the latest known 5.x.y version. Version may be specified either with or without the v prefix, for example v5.4.0 and 5.4.0 are semantically the same.

vuln-exporter - OPTIONAL
The FortifyVulnerabilityExporter version to install. Allowed values: skip (default value, do not install), latest, or specific version number. Supports semantic versioning, for example v2 will install the latest known 2.x.y version. Version may be specified either with or without the v prefix, for example v2.0.4 and 2.0.4 are semantically the same.

bugtracker-utility - OPTIONAL
The FortifyBugTrackerUtility version to install. Allowed values: skip (default value, do not install), latest, or specific version number. Supports semantic versioning, for example v4 will install the latest known 4.x version. Version may be specified either with or without the v prefix, for example v4.12 and 4.12 are semantically the same.

debricked-cli - OPTIONAL
The Debricked CLI version to install. Allowed values: skip (default value, do not install), latest, or specific version number. Supports semantic versioning, for example v1 will install the latest known 1.x version. Version may be specified either with or without the v prefix, for example v1 and 1 are semantically the same.

Action environment variable inputs

Action outputs

For each tool being installed, the action outputs several environment variables for use by later workflow steps.

PATH
If the export-path action input was set to true (default), the bin-directory of the installed tool will be added to the workflow PATH environment variable.

<TOOL_NAME>_INSTALL_DIR
Directory where the corresponding tool was installed. <TOOL_NAME> corresponds to the various action inputs, but converted to uppercase and dashes replaced by underscore, for example FOD_UPLOADER_INSTALL_DIR.

<TOOL_NAME>_BIN_DIR
Bin-directory that holds the executables for the corresponding tool. <TOOL_NAME> corresponds to the various action inputs, but converted to uppercase and dashes replaced by underscore, for example FOD_UPLOADER_BIN_DIR.

<TOOL_NAME>_CMD
Fully qualified path to the (primary) executable/script for the corresponding tool. <TOOL_NAME> corresponds to the various action inputs, but converted to uppercase and dashes replaced by underscore, for example FOD_UPLOADER_CMD.

Sample usage

The sample workflow below demonstrates how to configure the action for installing the various Fortify tools and how to run these tools. Some notes:

The export-path and bugtracker-utility inputs are set to their default values, and thus could have been omitted.
The action supports semantic versioning, so the vuln-exporter input will install the latest known v2.x.y version of FortifyVulnerabilityExporter.

    steps:    
      - name: Setup Fortify tools
        uses: fortify/github-action/setup@v1
        with:
          tool-definitions: https://github.com/fortify/tool-definitions/releases/download/v1/tool-definitions.yaml.zip
          export-path: true
          fcli: latest
          sc-client: 23.1.0
          fod-uploader: latest
          vuln-exporter: v2
          bugtracker-utility: skip
          debricked-cli: skip
      - name: Run fcli from PATH
        run: fcli -V
      - name: Run fcli using FCLI_CMD environment variable
        run: ${FCLI_CMD} -V

fortify/github-action/package

This action packages application source code using ScanCentral Client. The output package is saved as package.zip.

Prerequisites

Node.js
Visual C++ Redistributable (Windows-based runners only)
Bash shell
If using Windows runners, this must be a Windows-based bash variant, for example as provided by MSYS2. You must make sure that this Windows-based bash variant is used for run steps that specify shell: bash. Actions will fail if the GitHub runner executes bash commands on the WSL-provided bash.exe

Action environment variable inputs

Sample usage

The sample workflow below demonstrates how to configure the action for running a SAST scan on FoD.

    steps:  
      - name: Check out source code
        uses: actions/checkout@v4  
      - name: Package source code
        uses: fortify/github-action/package@v1
        env:
          # PACKAGE_EXTRA_OPTS: -bf custom-pom.xml
          # TOOL_DEFINITIONS: https://ftfy.mycompany.com/tool-definitions/v1/tool-definitions.yaml.zip

fortify/github-action/fod-sast-scan

This action performs a SAST scan on Fortify on Demand (FoD). If software composition analysis of open source has been purchased and configured on the applicable release, this action can be used to perform a combined SAST and SCA (open source) scan.

The SAST and optional open source scan performed by this action consists of the following steps:

Login to FoD
Package application source code using ScanCentral Client
Submit the source code package to be scanned to FoD
Optionally wait for the scan to complete
Optionally export scan results to the GitHub Code Scanning dashboard

Prerequisites

Node.js
Visual C++ Redistributable (Windows-based runners only)
Bash shell
If using Windows runners, this must be a Windows-based bash variant, for example as provided by MSYS2. You must make sure that this Windows-based bash variant is used for run steps that specify shell: bash. Actions will fail if the GitHub runner executes bash commands on the WSL-provided bash.exe

Apart from the generic action prerequisites listed above, the following prerequisites apply to this specific action:

The appropriate application release exists on FoD and has been configured for SAST scans. Future versions of this action may add support for automating app/release creation and scan setup.
If open source scanning has been enabled in the FoD SAST scan configuration, be sure to pass the -oss option through the PACKAGE_EXTRA_OPTS environment variable.

Action environment variable inputs

FOD_CLIENT_ID & FOD_CLIENT_SECRET - REQUIRED*
Required when authenticating with an API key: FoD Client ID (API key) and Secret (API secret).

Note that if setup is enabled, FOD_RELEASE or SSC_APPVERSION must be configured with a qualified release/version name; you cannot use release/version id.

EXTRA_FOD_SAST_SCAN_OPTS (deprecated), FOD_SAST_SCAN_EXTRA_OPTS - OPTIONAL
Extra FoD SAST scan options; see fcli fod sast-scan start documentation

Note that pull request comments will only be generated under the following conditions:

Standard GITHUB_REF_NAME environment variable points to a pull request, which is only the case on GitHub pull_request triggers and not for example manual triggers (even if the branch is associated with a current pull request).
All other standard GitHub environment variables like GITHUB_TOKEN, GITHUB_REPOSITORY and GITHUB_SHA are set.

For any branches for which you might want to generate PR comments, have the workflow trigger only on pull_request events. Note that you can have a single workflow that is triggered on both push events for your main branch, and only pull_request events for all other branches.
Don't set FOD_RELEASE or SSC_APPVERSION, to use the default value that corresponds to repository and branch name.
Set DO_RELEASE_SETUP or DO_APPVERSION_SETUP to true, to allow a branch-specific application version/release to be automatically created.
Include --copy-from option in RELEASE_SETUP_EXTRA_OPTS or APPVERSION_SETUP_EXTRA_OPTS to copy state from the version/release that represents the PR target branch into the newly created application version/release.

With a setup like this, whenever a new PR is created, the GitHub Action will:

Create a new application version/release named <repository owner>/<repository name>:<branch name>.
Copy state from the application version/release identified by the --copy-from option to this new application version/release.
Run a new scan of the branch associated with the current PR, and upload results to the application version/release created above.
Generate a PR comment listing new and removed issues, based on comparing the results of the new scan that was run in the previous step against the scan results that were copied from the version/release identified by the --copy-from option.

Sample usage

The sample workflow below demonstrates how to configure the action for running a SAST scan on FoD.

    steps:    
      - name: Check out source code
        uses: actions/checkout@v4  
      - name: Run FoD SAST Scan
        uses: fortify/github-action/fod-sast-scan@v1
        env:
          FOD_URL: https://ams.fortify.com
          FOD_TENANT: ${{secrets.FOD_TENANT}}
          FOD_USER: ${{secrets.FOD_USER}}
          FOD_PASSWORD: ${{secrets.FOD_PAT}}
          # FOD_LOGIN_EXTRA_OPTS: --socket-timeout=60s
          # FOD_RELEASE: MyApp:MyRelease
          # PACKAGE_EXTRA_OPTS: -oss
          # DO_WAIT: true
          # DO_EXPORT: true
          # TOOL_DEFINITIONS: https://ftfy.mycompany.com/tool-definitions/v1/tool-definitions.yaml.zip

fortify/github-action/fod-export

This action exports the latest vulnerability data from an FoD release to the GitHub Code Scanning dashboard. Note that this may require a GitHub Advanced Security subscription, unless you're running this action on a public github.com repository.

Prerequisites

Node.js
Visual C++ Redistributable (Windows-based runners only)
Bash shell
If using Windows runners, this must be a Windows-based bash variant, for example as provided by MSYS2. You must make sure that this Windows-based bash variant is used for run steps that specify shell: bash. Actions will fail if the GitHub runner executes bash commands on the WSL-provided bash.exe

Action environment variable inputs

FOD_CLIENT_ID & FOD_CLIENT_SECRET - REQUIRED*
Required when authenticating with an API key: FoD Client ID (API key) and Secret (API secret).

Sample usage

The sample workflow below demonstrates how to configure the action for exporting FoD SAST vulnerability data to the GitHub Security Code Scanning dashboard.

    steps:    
      - name: Export FoD vulnerability data to GitHub
        uses: fortify/github-action/fod-export@v1
        env:
          FOD_URL: https://ams.fortify.com
          FOD_TENANT: ${{secrets.FOD_TENANT}}
          FOD_USER: ${{secrets.FOD_USER}}
          FOD_PASSWORD: ${{secrets.FOD_PAT}}
          # FOD_RELEASE: MyApp:MyRelease
          # TOOL_DEFINITIONS: https://ftfy.mycompany.com/tool-definitions/v1/tool-definitions.yaml.zip

fortify/github-action/sc-sast-scan

This action performs a SAST scan on ScanCentral SAST, consisting of the following steps:

Login to ScanCentral SAST Controller
Package application source code using ScanCentral Client
Submit the source code package to be scanned to ScanCentral SAST Controller
Optionally run a Debricked Software Composition Analysis scan
Optionally wait for all scans to complete and results having been processed by SSC
Optionally export scan results to the GitHub Code Scanning dashboard

Prerequisites

Node.js
Visual C++ Redistributable (Windows-based runners only)
Bash shell
If using Windows runners, this must be a Windows-based bash variant, for example as provided by MSYS2. You must make sure that this Windows-based bash variant is used for run steps that specify shell: bash. Actions will fail if the GitHub runner executes bash commands on the WSL-provided bash.exe

Apart from the generic action prerequisites listed above, the following prerequisites apply to this specific action:

The appropriate application version must exist on SSC. Future versions of this action may add support for automating application version creation.
If Debricked scanning is enabled, the Fortify SSC Parser Plugin for Debricked results must be installed on Fortify SSC, to allow for SSC to accept and process the Debricked scan results submitted by this action.

Action environment variable inputs

SSC_TOKEN - REQUIRED*
Required when authenticating with an SSC token (recommended). Most actions should work fine with a CIToken.

SSC_USER & SSC_PASSWORD - REQUIRED*
Required when authenticating with SSC user credentials.

SC_SAST_TOKEN - REQUIRED
Required: ScanCentral SAST Client Authentication Token for authenticating with ScanCentral SAST Controller.

Note that if setup is enabled, FOD_RELEASE or SSC_APPVERSION must be configured with a qualified release/version name; you cannot use release/version id.

SC_SAST_SENSOR_VERSION - REQUIRED
Version of the ScanCentral SAST sensor on which the scan should be performed. See fcli sc-sast scan start documentation for details.

EXTRA_SC_SAST_SCAN_OPTS (deprecated), SC_SAST_SCAN_EXTRA_OPTS - OPTIONAL
Extra ScanCentral SAST scan options; see fcli sc-sast scan start documentation

Note that pull request comments will only be generated under the following conditions:

Standard GITHUB_REF_NAME environment variable points to a pull request, which is only the case on GitHub pull_request triggers and not for example manual triggers (even if the branch is associated with a current pull request).
All other standard GitHub environment variables like GITHUB_TOKEN, GITHUB_REPOSITORY and GITHUB_SHA are set.

For any branches for which you might want to generate PR comments, have the workflow trigger only on pull_request events. Note that you can have a single workflow that is triggered on both push events for your main branch, and only pull_request events for all other branches.
Don't set FOD_RELEASE or SSC_APPVERSION, to use the default value that corresponds to repository and branch name.
Set DO_RELEASE_SETUP or DO_APPVERSION_SETUP to true, to allow a branch-specific application version/release to be automatically created.
Include --copy-from option in RELEASE_SETUP_EXTRA_OPTS or APPVERSION_SETUP_EXTRA_OPTS to copy state from the version/release that represents the PR target branch into the newly created application version/release.

With a setup like this, whenever a new PR is created, the GitHub Action will:

Create a new application version/release named <repository owner>/<repository name>:<branch name>.
Copy state from the application version/release identified by the --copy-from option to this new application version/release.
Run a new scan of the branch associated with the current PR, and upload results to the application version/release created above.
Generate a PR comment listing new and removed issues, based on comparing the results of the new scan that was run in the previous step against the scan results that were copied from the version/release identified by the --copy-from option.

Sample usage

The sample workflow below demonstrates how to configure the action for running a SAST scan on ScanCentral SAST.

    steps:    
      - name: Check out source code
        uses: actions/checkout@v4  
      - name: Run ScanCentral SAST Scan
        uses: fortify/github-action/sc-sast-scan@v1
        env:
          SSC_URL: ${{vars.SSC_URL}}
          SSC_TOKEN: ${{secrets.SSC_TOKEN}}
          # SSC_LOGIN_EXTRA_OPTS: --socket-timeout=60s
          SC_SAST_TOKEN: ${{secrets.CLIENT_AUTH_TOKEN}}
          # SC_SAST_LOGIN_EXTRA_OPTS: --socket-timeout=60s
          # SSC_APPVERSION: MyApp:MyVersion
          # PACKAGE_EXTRA_OPTS: -bf custom-pom.xml
          SC_SAST_SENSOR_VERSION: 23.2
          # DO_DEBRICKED_SCAN: true  # Or debricked-sca-scan input on top-level action
          # DEBRICKED_TOKEN: ${{secrets.DEBRICKED_TOKEN}}
          # DO_WAIT: true
          # DO_EXPORT: true
          # TOOL_DEFINITIONS: https://ftfy.mycompany.com/tool-definitions/v1/tool-definitions.yaml.zip

fortify/github-action/ssc-debricked-scan

This action performs a Debricked Software Composition Analysis (SCA) scan, consisting of the following steps:

Login to Fortify SSC
Run Debricked scan
Publish Debricked scan results to Fortify SSC
Optionally wait for SSC artifact processing to complete

Note that this action is explicitly meant for Debricked/SSC integration. If you wish to run a Debricked scan without publishing the results to SSC, please see the Debricked GitHub Integration documentation

Prerequisites

Node.js
Visual C++ Redistributable (Windows-based runners only)
Bash shell
If using Windows runners, this must be a Windows-based bash variant, for example as provided by MSYS2. You must make sure that this Windows-based bash variant is used for run steps that specify shell: bash. Actions will fail if the GitHub runner executes bash commands on the WSL-provided bash.exe

Apart from the generic action prerequisites listed above, the following prerequisites apply to this specific action:

The appropriate application version must exist on SSC. Future versions of this action may add support for automating application version creation.
The Fortify SSC Parser Plugin for Debricked results must be installed on Fortify SSC, to allow for SSC to accept and process the Debricked scan results submitted by this action.

Action environment variable inputs

SSC_TOKEN - REQUIRED*
Required when authenticating with an SSC token (recommended). Most actions should work fine with a CIToken.

SSC_USER & SSC_PASSWORD - REQUIRED*
Required when authenticating with SSC user credentials.

DEBRICKED_TOKEN - REQUIRED
See the Generate access token section in the Debricked documentation for details on how to generate this token.

Note that if setup is enabled, FOD_RELEASE or SSC_APPVERSION must be configured with a qualified release/version name; you cannot use release/version id.

Note that pull request comments will only be generated under the following conditions:

Standard GITHUB_REF_NAME environment variable points to a pull request, which is only the case on GitHub pull_request triggers and not for example manual triggers (even if the branch is associated with a current pull request).
All other standard GitHub environment variables like GITHUB_TOKEN, GITHUB_REPOSITORY and GITHUB_SHA are set.

For any branches for which you might want to generate PR comments, have the workflow trigger only on pull_request events. Note that you can have a single workflow that is triggered on both push events for your main branch, and only pull_request events for all other branches.
Don't set FOD_RELEASE or SSC_APPVERSION, to use the default value that corresponds to repository and branch name.
Set DO_RELEASE_SETUP or DO_APPVERSION_SETUP to true, to allow a branch-specific application version/release to be automatically created.
Include --copy-from option in RELEASE_SETUP_EXTRA_OPTS or APPVERSION_SETUP_EXTRA_OPTS to copy state from the version/release that represents the PR target branch into the newly created application version/release.

With a setup like this, whenever a new PR is created, the GitHub Action will:

Create a new application version/release named <repository owner>/<repository name>:<branch name>.
Copy state from the application version/release identified by the --copy-from option to this new application version/release.
Run a new scan of the branch associated with the current PR, and upload results to the application version/release created above.
Generate a PR comment listing new and removed issues, based on comparing the results of the new scan that was run in the previous step against the scan results that were copied from the version/release identified by the --copy-from option.

Sample usage

The sample workflow below demonstrates how to configure the action for running a Debricked scan and publishing the results to Fortify SSC.

    steps:    
      - name: Check out source code
        uses: actions/checkout@v4  
      - name: Run Debricked Scan
        uses: fortify/github-action/ssc-debricked-scan@v1
        env:
          SSC_URL: ${{vars.SSC_URL}}
          SSC_TOKEN: ${{secrets.SSC_TOKEN}}
          # SSC_LOGIN_EXTRA_OPTS: --socket-timeout=60s
          # SSC_APPVERSION: MyApp:MyVersion
          DEBRICKED_TOKEN: ${{secrets.DEBRICKED_TOKEN}}
          # DO_WAIT: true
          # TOOL_DEFINITIONS: https://ftfy.mycompany.com/tool-definitions/v1/tool-definitions.yaml.zip

fortify/github-action/ssc-export

This action exports the latest vulnerability data from an SSC application version to the GitHub Code Scanning dashboard. Note that this may require a GitHub Advanced Security subscription, unless you're running this action on a public github.com repository.

Prerequisites

Node.js
Visual C++ Redistributable (Windows-based runners only)
Bash shell
If using Windows runners, this must be a Windows-based bash variant, for example as provided by MSYS2. You must make sure that this Windows-based bash variant is used for run steps that specify shell: bash. Actions will fail if the GitHub runner executes bash commands on the WSL-provided bash.exe

Action environment variable inputs

SSC_TOKEN - REQUIRED*
Required when authenticating with an SSC token (recommended). Most actions should work fine with a CIToken.

SSC_USER & SSC_PASSWORD - REQUIRED*
Required when authenticating with SSC user credentials.

Sample usage

The sample workflow below demonstrates how to configure the action for exporting SSC SAST vulnerability data to the GitHub Security Code Scanning dashboard.

    steps:    
      - name: Export SSC vulnerability data to GitHub
        uses: fortify/github-action/ssc-export@v1
        env:
          SSC_URL: ${{vars.SSC_URL}}
          SSC_TOKEN: ${{secrets.SSC_TOKEN}}
          # SSC_APPVERSION: MyApp:MyVersion
          # TOOL_DEFINITIONS: https://ftfy.mycompany.com/tool-definitions/v1/tool-definitions.yaml.zip

Support

The only warranties for products and services of Open Text and its affiliates and licensors (“Open Text”) are as may be set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Open Text shall not be liable for technical or editorial errors or omissions contained herein. The information contained herein is subject to change without notice.

The software is provided "as is" and is not supported through the regular OpenText Support channels. Support requests may be submitted through the GitHub Issues page for this repository. A (free) GitHub account is required to submit new issues or to comment on existing issues.

Support requests created through the GitHub Issues page may include bug reports, enhancement requests and general usage questions. Please avoid creating duplicate issues by checking whether there is any existing issue, either open or closed, that already addresses your question, bug or enhancement request. If an issue already exists, please add a comment to provide additional details if applicable.

Support requests on the GitHub Issues page are handled on a best-effort basis; there is no guaranteed response time, no guarantee that reported bugs will be fixed, and no guarantee that enhancement requests will be implemented. If you require dedicated support for this and other Fortify software, please consider purchasing OpenText Fortify Professional Services. OpenText Fortify Professional Services can assist with general usage questions, integration of the software into your processes, and implementing customizations, bug fixes, and feature requests (subject to feasibility analysis). Please contact your OpenText Sales representative or fill in the Professional Services Contact Form to obtain more information on pricing and the services that OpenText Fortify Professional Services can provide.

This document was auto-generated; do not edit by hand

License

fortify/github-action

Folders and files

Latest commit

History

Repository files navigation

fortify/github-action@v1

fortify/github-action

Prerequisites

Action inputs

Action environment variable inputs

Fortify on Demand

ScanCentral SAST with optional Debricked scan

Debricked-only scan and publish to SSC

Sample workflows

Fortify on Demand

ScanCentral SAST with optional Debricked scan

Debricked-only scan and publish to SSC

More information

fortify/github-action/setup

Prerequisites

Action inputs

Action environment variable inputs

Action outputs

Sample usage

fortify/github-action/package

Prerequisites

Action environment variable inputs

Sample usage

fortify/github-action/fod-sast-scan

Prerequisites

Action environment variable inputs

Sample usage

fortify/github-action/fod-export

Prerequisites

Action environment variable inputs

Sample usage

fortify/github-action/sc-sast-scan

Prerequisites

Action environment variable inputs

Sample usage

fortify/github-action/ssc-debricked-scan

Prerequisites

Action environment variable inputs

Sample usage

fortify/github-action/ssc-export

Prerequisites

Action environment variable inputs

Sample usage

Support

About

Topics

Resources

License

Code of conduct

Stars

Watchers

Forks

Releases 20

Contributors 4

Languages