Skip to content
kix /docs
Install the CLI

How-to guide Policy, CI, and compliance

Run kix check --sarif in CI

Write Kix scorecard findings as SARIF for a CI code-scanning step.

Use kix check --sarif when your CI system accepts SARIF 2.1.0 findings. The command still runs cluster evaluation and the normal checks, but writes SARIF instead of the terminal summary.

This guide assumes the job has Kix and the cluster’s Nix dependencies available.

Redirect stdout to a file:

kix-examples/
❱ kix check 19-scorecards --sarif > kix-results.sarif

Upload kix-results.sarif with your CI provider’s SARIF or code-scanning integration. Preserve the command’s exit status so error-level checks still fail the job, even if the upload step runs after a failure.

The captured example below contains warning and note findings from the checked-in scorecard scenario:

kix-examples/ output excerpt offline capture
❱ kix check 19-scorecards --sarif
Show outputHide output · 59 lines
{
  "version": "2.1.0",
  "runs": [
    {
      "tool": "kix",
      "rules": 4,
      "results": [
        {
          "ruleId": "reliability.boundedResources",
          "level": "warning",
          "message": "container 'nginx' is missing resource settings: requests.cpu, requests.memory, limits.cpu, limits.memory. Set CPU and memory requests and limits. Without a memory limit, a workload can exhaust the node's memory.",
          "location": null
        },
        {
          "ruleId": "reliability.gracefulShutdown",
          "level": "note",
          "message": "terminationGracePeriodSeconds is not set or is 0",
          "location": null
        },
        {
          "ruleId": "reliability.hasResourceLimits",
          "level": "warning",
          "message": "container 'nginx' has no resource limits",
          "location": null
        },
        {
          "ruleId": "reliability.hasResourceRequests",
          "level": "warning",
          "message": "container 'nginx' has no resource requests",
          "location": null
        },
        {
          "ruleId": "reliability.boundedResources",
          "level": "warning",
          "message": "container 'nginx' is missing resource settings: requests.cpu, requests.memory, limits.cpu, limits.memory. Set CPU and memory requests and limits. Without a memory limit, a workload can exhaust the node's memory.",
          "location": null
        },
        {
          "ruleId": "reliability.gracefulShutdown",
          "level": "note",
          "message": "terminationGracePeriodSeconds is not set or is 0",
          "location": null
        },
        {
          "ruleId": "reliability.hasResourceLimits",
          "level": "warning",
          "message": "container 'nginx' has no resource limits",
          "location": null
        },
        {
          "ruleId": "reliability.hasResourceRequests",
          "level": "warning",
          "message": "container 'nginx' has no resource requests",
          "location": null
        }
      ]
    }
  ]
}

Each result includes a rule ID, SARIF level, and message. Kix emits a valid empty SARIF run when the cluster has no scorecard findings, so the upload step can use the same path for clean and failing builds.

An error-severity finding becomes a failed assertion, so evaluation stops before producing a scorecard report. Kix instead writes the evaluation failure as a single error-level SARIF result. When the error message identifies the rule, the result is attributed to that rule. Only one result appears because evaluation stops at the first failed assertion.

Keep this behavior in mind before promoting a rule to error in Override scorecard severity. An error rule stops the build instead of contributing all of its findings to the completed report.

A short validation catches an empty or truncated shell redirect:

kix-examples/
❱ jq -e '.version == "2.1.0" and (.runs | length) > 0' kix-results.sarif

Run the upload step even when kix check exits non-zero, then propagate the original failure. The exact job syntax depends on the CI provider.