> 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/about-code-security.md).
# About Code security
## What is Code Security
Code Security is the detection layer of Cortex Cloud Application Security, delivered through the Application Security add-on. Code Security analyzes source code, dependency manifests, and IaC templates to identify security issues before the issues reach a protected branch, a build artifact, or a deployed cloud resource. Detecting an issue at code-time rather than at runtime reduces both the cost of the fix and the exposure window.
**Scope:** Code Security performs detection and analysis. Code Security does not define policies, calculate Urgency, or orchestrate remediation. Those functions belong to Application Security Posture Management (ASPM).
### Where Code Security fits
Cortex Cloud Application Security is organized into three pillars. Code Security is the third pillar, and Code Security supplies the native scanner findings that the other two pillars govern and contextualize.
| Pillar | Responsibility |
| -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Application Security Posture Management (ASPM)** | Governance and orchestration — unified policies, Urgency-based prioritization, Code-to-Cloud correlation, coverage, and remediation tracking. See Introduction to ASPM. |
| **Software Supply Chain Security** | Integrity of the components, registries, CI/CD instances, and pipelines used to build and deliver software. |
| **Code Security** | Native scanning of source code, dependency manifests, and IaC templates across the software development lifecycle. |
> **Note:** A pillar classifies the domain of the risk, not the scanner that detected the risk. The Code Security Software Composition Analysis (SCA) scanner produces findings that are classified under Software Supply Chain Security, because the risk originates in a third-party dependency rather than in first-party code.
### Prerequisites
| Requirement | Description |
| ----------- | ------------------------------------------------------------------------------------------------------------------------ |
| License | An active Cortex Cloud license with Application Security add-on entitlements |
| RBAC role | The AppSec Admin, DevSecOps, or Developer role, or an equivalent custom role. The Developer role grants read-only access |
| Data source | At least one Version Control System (GitHub, GitLab, Bitbucket, Azure Repos) integrated as a data source |
> **Note:** Each scanner adds its own prerequisites, such as an enabled scanner configuration and at least one completed scan. For the prerequisites of a specific detection, see the introduction for that finding type.
### Use cases-what Code Security detects
| Detection | Target |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Secrets** | Hardcoded credentials, API keys, tokens, and private keys committed to source code. See Secrets issues. |
| **SCA — CVE vulnerabilities** | Known CVEs in open-source dependencies. See SCA CVE issues. |
| **SCA — License compliance** | Strong copyleft, non-permissive, and unknown licenses that impose obligations your organization cannot meet. See License miscompliance issues. |
| **SCA — Package operational risk** | Deprecated, unmaintained, and low-adoption open-source packages that are unlikely to receive a future fix. See Package operational risk issues. |
| **IaC misconfigurations** | Insecure infrastructure definitions in Terraform, CloudFormation, Kubernetes, Helm, ARM, and Bicep templates, detected before the definitions are applied to a cloud environment. See IaC misconfiguration issues. |
| **IaC drift** | Deltas between the infrastructure definition in the repository and the deployed cloud resource, which indicate changes made outside the reviewed IaC pipeline. See IaC drift issues. |
### Core achievements
Code Security moves the organization from discovering security issues in production to preventing the issues at the point where the issues are introduced.
* **Shifting detection left** — Scanners run at code-time in the IDE, at merge-time in the pull request, at build-time in the pipeline, and continuously through periodic scans. An issue blocked at the earliest stage never reaches the protected branch, the build artifact, or the deployed resource, so the blast radius and the cost of the fix stay at their lowest
* **Consolidating detection into one portfolio** — A single scanner portfolio covers secrets, open-source CVE vulnerabilities, license obligations, package operational risk, IaC misconfigurations, and IaC drift. Consolidation removes the disconnected point tools that each produce a separate, uncorrelated finding stream
* **Preventing credential and dependency compromise** — Detecting a hardcoded credential before the credential reaches a protected branch removes the exposure window that automated scanning bots exploit. Detecting a vulnerable or unmaintained dependency before the dependency ships removes the entry point rather than compensating for the entry point later
* **Enforcing infrastructure integrity** — Scanning IaC templates prevents insecure infrastructure from being provisioned, and drift detection reconciles the reviewed baseline against the deployed cloud state so changes made outside the IaC pipeline do not go unnoticed
* **Establishing an auditable compliance baseline** — Every finding maps to a named detection rule and, where applicable, to a CVE identifier or an SPDX license identifier, which produces the evidence trail that compliance review and legal review require
* **Accelerating remediation** — Every finding carries remediation guidance at the point of detection — a fix version for a CVE, a corrected snippet for an IaC misconfiguration, rotation instructions for a secret — so the developer resolves the issue without external research
***
### Who is responsible for Code Security
Code Security follows a governance-to-execution delegation model. Governance defines what the organization requires; operations and development execute against that direction.
| Persona | Function | Responsibility |
| ----------------------------------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **AppSec Manager** | Governance | Owns Code Security governance. Defines which scanners run against which repositories, sets the detection and enforcement standard, reviews scanner coverage and posture, and holds accountability for remediation compliance against SLA |
| **AppSec Practitioner (DevSecOps)** | Operations | Executes the governance direction. Onboards repositories, enables and configures scanners, triages the resulting issues, and reports coverage gaps back to governance |
| **Developer** | Remediation | Consumes findings at code-time in the IDE and in the pipeline, applies the remediation guidance, and validates the fix through a rescan |
The three functional personas map to the predefined Cortex Cloud roles — AppSec Admin, DevSecOps, and Developer. For the permissions attached to each role, see Introduction to Code Security.
> **Note:** Governance accountability for Code Security sits with the AppSec Manager, but the governance mechanisms — unified policies, Urgency, coverage, and SLA — are ASPM capabilities. Code Security supplies the findings that those mechanisms govern.
---
# 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/about-code-security.md?ask=&goal=
```
`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.