Pull request status checks and decoration

Use this article when a pull request shows Cysmiq status checks or comments and you need to understand or configure their behavior.

What to check first

• Confirm that scanning is enabled for the repository.
• Open VCS Status & PR Decoration settings for the workspace, organization, or repository.
• Check whether the current scope has an override or inherits its settings from a broader scope.

What Cysmiq can publish

• VCS status checks post scan and assessment outcomes back to commits and pull requests.
• PR decoration adds pull request comments or check summaries after a terminal pull request evaluation.

Status checks you may see

• Cysmiq Scan: scan execution and terminal scan result.
• Cysmiq PR Assessment: vulnerability assessment for the current pull request head.
• Cysmiq Policies: policy enforcement result for the pull request or commit.

Assessment and policy statuses include an outcome summary. GitHub check runs can also show contributing pull request results and link to the relevant Cysmiq findings or scan view.

Current pull request assessment and policy checks refresh after manual vulnerability status changes, approved or cleared snoozes, and policy exception, exemption, or package decision changes. Updates follow the configured VCS publishing settings.

Choose which finding severities block checks

Block security checks for findings at or above sets the minimum actionable finding severity that blocks Cysmiq Scan and Cysmiq PR Assessment.

• Critical only: only Critical findings block.
• High and Critical: High and Critical findings block.
• Medium and above: Medium, High, and Critical findings block.
• All severities: every known severity blocks. This is the default.

Actionable findings below the threshold appear as warnings and allow both checks to pass. Unknown severities remain blocking. Policy violations continue to follow their policy enforcement settings.

Choose when Cysmiq posts PR comments

When PR decoration is enabled, Post PR comments for offers these choices:

• Blocking issues only: comments for blocking findings or blocking policy violations.
• Blocking issues and warnings: also comments for non-blocking finding warnings and advisory policy warnings.
• All terminal results: comments for every terminal result, including passing results without warnings. This is the default.

Provider naming

Provider UI names vary. GitHub groups check runs and commit statuses under status checks, GitLab shows commit statuses, and Bitbucket can show commit statuses as build statuses. The same Cysmiq concepts apply across providers.

Why checks can disagree

Each status answers a different question. For example, a scan can complete while the policy check fails because a blocking policy violation exists. The configured severity threshold can also allow scan and PR assessment checks to pass while lower-severity actionable findings appear as warnings.

Canonical docs

For provider-specific examples, see Review pull request results. For configuration details, see VCS status updates.

Contact support if

• Cysmiq checks do not appear on a pull request after scanning is enabled.
• A status check appears stuck after the scan has finished in Cysmiq.
• An inherited threshold or comment setting does not behave as shown in the settings page.