For the complete documentation index, see llms.txt. This page is also available as Markdown.

CI scans

CI scans are the enforcement point that decides whether a vulnerable artifact gets built and shipped. A CI scan runs when the Cortex CLI executes inside a build pipeline, evaluates the code the pipeline is about to package against every enabled Cortex Cloud Application Security scanner, and fails the build when a finding matches a policy carrying the Block CI/CD action. Use CI scans to answer one question with evidence: is the build stage stopping risk that the pull request gate did not, and is every pipeline that ships to production actually running the check.

CI scans gate a build and produce both a CI status and scan health. CI scans do not establish the posture of the existing codebase — branch periodic scans produce that baseline — and CI scans do not gate a merge, which is the role of Pull request scans. This guide covers CI scans driven by the Cortex CLI in a pipeline. The CI Scans inventory presents scan results; the inventory does not resolve issues and offers no rescan action. CLI invocation, flags, and pipeline examples are documented in Cortex CLI; the blocking decision is configured through Unified Application Security policies.

Terraform run tasks: HCP Terraform and Terraform Enterprise integrations also write results to the CI Scans inventory. This guide notes where their behavior differs.

Prerequisites

Prerequisite
Requirement

Application Security module

The Cortex Cloud Application Security module is active for the tenant.

Cortex CLI in the pipeline

The Cortex CLI is installed and invoked as a pipeline step. See Cortex CLI.

API key with write permission

The CLI authenticates with an API key that carries write permission. Without write permission the CLI falls back to no-upload mode, and the scan produces no inventory row.

Upload mode

The CLI runs in the default upload mode. A scan run with --upload-mode no-upload never appears in the CI Scans inventory.

Blocking policy

To fail a build, an enabled Unified Application Security Policy carries the Block CI/CD action for the CI Scan trigger. Without such a policy, CI scans report findings and never fail a build.

app_sec_scans_ci_cd_view permission

Required to view CI scan results.

Core achievements

  • Stopping the artifact before it exists: Failing the build denies a vulnerable image or package the chance to reach a registry, a deployment, or a runtime environment

  • Catching what the merge gate could not: Detecting risk introduced outside a pull request — a direct push, a dependency resolved at build time, or a branch that no pull request ever covered

  • Making the build gate auditable: Recording which policy failed which build, so a prevention claim rests on evidence rather than on pipeline configuration

  • Separating security failures from tooling failures: Distinguishing a build failed by policy from a build failed by an authentication or network error, so pipeline owners do not disable the scan to restore stability

Shift-left position: CI scans are the second enforcement point in the shift-left lifecycle (IDE → PR → CI → Periodic → Runtime). A finding blocked at the pull request stage never reaches CI. A finding that reaches the CI gate is either risk that entered the branch outside a pull request or risk that the pull request gate was not configured to stop — in both cases, a CI block is a signal to strengthen the pull request policy set, not only to fix the build.

Core concepts

Use these concepts to interpret enforcement results correctly. See Reference A: CI scan concepts for details.

  • CI status — The policy verdict that determines the build outcome

  • Scan health — Whether every enabled scanner completed successfully

  • Exit code — The CLI signal that the pipeline uses to enforce a block

  • Inventory coverage — A row proves reporting, not that every pipeline runs a gate

Workflow

Follow the workflow to embed the CI gate, validate enforcement, and investigate failed builds.

References

Use References for detailed scan information.

Next step

Follow the CI scan workflow to verify coverage, investigate scan results, and strengthen the build gate.

Last updated

Was this helpful?