Skip to main content

Overview

Use cysmiq check in CI/CD to evaluate findings from a Cysmiq scan and fail the job when a severity or count threshold is exceeded. The CLI queries scan results from Cysmiq. It does not replace the repository integration that triggers scans.
Availability depends on your Cysmiq plan.

Prerequisites

  • Connect the repository to Cysmiq and confirm that push or pull request scans run.
  • Create an API key with vulnerabilities:read and scans:read scopes.
  • Store the token in the CI provider’s secret store.
  • Know the Cysmiq workspace slug and repository path.

Choose the revision

Use a commit SHA when the job must wait for and evaluate the scan of the exact revision:
Check a commit
Use a ref when the job should evaluate the latest known scan for a branch or tag:
Check a branch
Application checks evaluate findings across all repositories in an application and do not wait for one repository scan:
Check an application

Configure the policy gate

By default, cysmiq check fails when it finds a critical or high-severity vulnerability. Adjust the gate for the workflow:
Fail only on critical vulnerabilities
Fail when more than ten findings match
Use --severity, --type, --state, and --triaged to focus the evaluation. See the CLI reference for every option.

Add the CI job

GitHub Actions workflow
Configure CYSMIQ_TENANT and CYSMIQ_TOKEN as protected CI/CD variables or secrets in the provider. The examples inherit those values without writing them into the workflow file.

Interpret the result

The most important exit codes for a pipeline are: Use JSON output when the pipeline also needs the structured result:
Emit JSON
Keep exit code 10 distinct from authentication, configuration, and service failures when the pipeline reports the result.