> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/ci-scans.md).

# 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](https://cortex-docs.paloaltonetworks.com/cortex-cli/); the blocking decision is configured through [Unified Application Security policies](/application-security/application-security-posture-management-aspm/unified-application-security-policies.md).

{% hint style="info" %}
**Terraform run tasks:** HCP Terraform and Terraform Enterprise integrations also write results to the CI Scans inventory. This guide notes where their behavior differs.
{% endhint %}

## 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](/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/ci-scans/references/reference-a-ci-scan-concepts.md) 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.

[Open the CI scan workflow](/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/ci-scans/ci-scan-workflow.md).

## References

Use [References](/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/ci-scans/references.md) for detailed scan information.

## Next step

Follow the [CI scan workflow](/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/ci-scans/ci-scan-workflow.md) to verify coverage, investigate scan results, and strengthen the build gate.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/application-security/code-security/application-security-scans-management/manage-scans-through-the-tenant-ui/ci-scans.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.