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.
Prerequisites
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?
