GitHub Actions

Last updated: Oct 26, 2026

Fluid Attacks has dedicated GitHub Actions for automated security testing directly in your CI/CD pipeline.

How it works

The SAST, SCA, and Secret Scan actions have the same main workflow structure: a checkout step, the scanner action, and an optional SARIF upload to GitHub's Security tab.

The SAST and Secret Scan actions automatically use the full scan or the differential scan mode. The mode depends on the Git event that started the workflow:

• Push to the default branch → full scan of all configured paths.
• Push to a feature branch or pull request → differential scan of only the changed files.

The differential mode keeps CI fast and makes sure that the action finds new vulnerabilities before they get to the default branch.

By default, the SCA action always runs a full scan, for all triggers. To use differential scanning, set the scanner_mode: diff action input.

Authenticate (optional)

When you authenticate, the Fluid Attacks platform attributes each scan to your Fluid Attacks group with a Group token. On GitHub Actions, if the workflow has the id-token: write permission, OIDC gives a short-lived token automatically, and the run authenticates without a secret. As an alternative, keep a long-lived INTEGRATES_API_TOKEN as a secret.

For the setup, read Authentication and OIDC federation.

What it looks like in GitHub

Job steps

After a push or pull request, the workflow appears in the Actions tab with each step: checkout, scan, and upload.

Scanner logs

When you expand the scan step, you see the scanner output: the files or dependency manifests that the scanner found, the vulnerabilities that it detected, and if the run was a full or differential scan.

Security tab results

After the SARIF file uploads, the findings appear in the Security → Code scanning panel of the repository, with the severity, file location, and description of each vulnerability.

GitHub Advanced Security

To upload scan results to the GitHub Security tab, you must have GitHub Advanced Security. It is available on all public repositories and on private repositories with a GitHub Advanced Security license. On private repositories without that license, the upload step fails.

Always use if: always() in the upload step. Thus, the step uploads the results each time, also when the scan step exits with a non-zero code (for example, when strict: true is set):

- name: Upload SARIF
  if: always()
  uses: github/codeql-action/upload-sarif@v4
  with:
    sarif_file: ${{ steps.scan.outputs.sarif_file }}

Common scenarios

Strict mode: block merges with vulnerabilities

Set strict: true in your configuration file:

strict: true

Then, in the branch protection settings of your repository, enable Require status checks to pass before merging.

To break the build only for vulnerabilities above a severity threshold that you set, use strictness_threshold instead of strict: true:

strictness_threshold: high

Export results as CSV or SARIF

Use output.file_path and output.format in your configuration file to write results to a file:

output:
  file_path: results.sarif
  format: SARIF

The correct values for format are SARIF, CSV, and ALL (generates the two formats at the same time). The action sets the sarif_file output only when the format is SARIF or ALL.

Troubleshooting

The pipeline fails unexpectedly

If strict: true is set in your configuration file, the pipeline fails each time that the scanner finds vulnerabilities. Set strict: false to report findings without a pipeline failure.

The job fails with "not found in repository"

The path in scan_config_path does not exist in the repository. Make sure that the path is correct and relative to the repository root.

No results appear in the Security tab

Make sure that the upload step uses if: always(). Thus, it runs also when the scan finds vulnerabilities with strict: true. Also make sure that your repository has GitHub Advanced Security enabled. For more information, read GitHub Advanced Security.

Differential scan analyzes all files instead of just changes

Make sure that fetch-depth: 0 is set in the actions/checkout step. Without the full git history, the action cannot find which files changed relative to the default branch.