The Code Security public APIs enable programmatic access to security issues and findings generated by the scan engine. Automate issue triage, verify shift-left enforcement, build posture dashboards, and feed findings into ticketing systems, all through scan-scoped REST endpoints.
API reference: For detailed request/response schemas, field definitions, and parameter specifications, refer to Cortex Cloud platform APIs.
Base URL and authentication
Base URL: https://<your-tenant>.xdr.us.paloaltonetworks.com/public_api/appsec/v1
Replace <your-tenant> with your tenant identifier. The region-specific domain varies by deployment.
Authentication headers
Header | Valus |
|---|---|
| API Key ID |
| API Key Secret |
Generate an API key pair from → → in the Cortex Cloud console. The API key role must grant read access to scan results and application resources in the ASPM module.
Available endpoints
Endpoint | Method | Returns | Granularity |
|---|---|---|---|
| GET | Periodic scan results with issue type breakdowns ( | Scan-level summary |
| GET | PR scan results with blocking policy details and issue type breakdowns ( | Scan-level summary |
| GET | CI/CD scan results with blocking status and issue type breakdowns ( | Scan-level summary |
| GET | Individual issue records found during the specific scan, including severity level, detection method (issue type), resolution status, and assignee | Issue-level detail |
| GET | Raw scanner findings with finding category (issue type), detection method, file path, git user, suppression type, timestamps | Finding-level detail |
| GET | Issue count breakdown by severity for a specific application and issue type | Application-level count |
Issue retrieval pattern
Retrieve issues by scan type
All scan types follow the same two-step pattern: list scans with filters, then retrieve issues or findings by scanId.
Periodic scans
Periodic scans run every 12 hours against the default branch of your onboarded repositories. Use periodic scan issues for compliance reporting, posture trending, and remediation tracking.
Step 1: List periodic scans: GET /scans/periodic with filters for organization, repository, branch, scan health, and time range (days).
```bash curl -X GET "https://<your-tenant>[.xdr.us.paloaltonetworks.com/public_api/appsec/v1/scans/periodic?organizationName=my-org&scanHealth=COMPLETED&days=7&limit=50](https://.xdr.us.paloaltonetworks.com/public_api/appsec/v1/scans/periodic?organizationName=my-org&scanHealth=COMPLETED&days=7&limit=50)" \ -H "x-xdr-auth-id: <KEY_ID>" \ -H "Authorization: <KEY_SECRET>" ```
Step 2 — Retrieve issues: GET /scans/{scanId}/issues with optional severity filter.
Tip
Use the issuesTypesBreakdown and issuesFound fields in the scan list response to identify scans with Critical or High issues before drilling into individual records, thereby reducing API calls.
PR scans
PR scans execute when a pull request is opened or updated. PR scan results indicate whether prevention policies blocked the merge; the primary shift-left enforcement point.
Step 1 - List PR scans: GET /scans/pr with filters for organization, repository, branch, PR ID, PR status, and time range.
Step 2 - Retrieve issues from a blocked PR: Use the scanId from the PR scan result. Key response fields: pullRequestStatus (Blocked or Passed), blockingPoliciesNames, userEmail, commitId.
Note
When blockingPoliciesIds is non-empty, the PR was blocked, preventing vulnerable code from merging into the protected branch.
CI/CD scans
CI/CD scans execute during automated build pipelines. I blocking is the second enforcement point after PR scans.
Step 1 — List CI/CD scans: GET /scans/ci with filters for organization, repository, CI status, scan health, and time range.
Step 2 — Retrieve issues from a blocked build: Use the scanId from the CI scan result. Key response fields: ciStatus (Blocked or Passed), blockingPoliciesNames.
Retrieve findings
Raw findings provide scanner-level detail not available in issue records — git author attribution, suppression status, first/last observed timestamps, and scan source identification. Use findings for false positive investigation, suppression pattern analysis, and detailed forensics.
Endpoint: GET /scans/{scanId}/findings with optional severity filter.
```bash curl -X GET "https://<your-tenant>[.xdr.us.paloaltonetworks.com/public_api/appsec/v1/scans/scan-a1b2c3d4/findings?severity=High&limit=100](https://.xdr.us.paloaltonetworks.com/public_api/appsec/v1/scans/scan-a1b2c3d4/findings?severity=High&limit=100)" \ -H "x-xdr-auth-id: <KEY_ID>" \ -H "Authorization: <KEY_SECRET>" ```
Key fields available in findings but not in issues: git_user, suppression_type, first_observed, last_observed, scan_source, first_hash, platform_id, data_source.
Retrieve issues by type
The issue endpoint (/scans/{scanId}/issues) does not support server-side filtering by issue type or detection method. To retrieve issues of a specific type (for example, all IaC misconfigurations), use the issuesTypesBreakdown field to pre-filter scans, then apply client-side filtering on detection_method.
Note
The severity query parameter is the only server-side filter available on the issue endpoint. Filtering by detection method, resolution status, or assignee requires client-side processing.
Step | Action |
|---|---|
1 | List Scans: Send a |
2 | Inspect Summary: Check the |
3 | Retrieve Issues: For scans with relevant findings, call |
4 | Filter Client-Side: Filter by the |
Mapping issuesTypesBreakdown keys to detection_method values
To filter the results in Step 4, use the table below to match each issuesTypesBreakdown key with its corresponding detection_method value. This mapping lets you isolate the relevant scan results.
issuesTypesBreakdown key (summary type) | detection_method value (issue type) | Scanner category |
|---|---|---|
Vulnerabilities |
| SCA: CVE vulnerability scanner |
Secrets |
| Secrets scanner |
IaC |
| IaC misconfiguration scanner |
Note
License compliance (License Security) and package operational risk (Operational Risk Security) are not represented as separate keys in issuesTypesBreakdown. To retrieve these issue types, filter client-side by detection_method from the full issue set.
All Code Security detection_method values:
Value | Scanner |
|---|---|
| CVEs in open-source dependencies |
| Hardcoded secrets, API keys, tokens, credentials |
| IaC misconfigurations (Terraform, CloudFormation, Kubernetes, ARM, Bicep) |
| Deprecated, unmaintained, or low-adoption packages |
| Non-compliant open-source licenses |
Application-level issue summaries
Application issue summaries provide issue counts by severity for a specific application and issue type, without iterating through individual scans. Use for executive dashboards and application-level posture monitoring.
Endpoint: GET /public_api/appsec/v1/application/{applicationId}/issues/{issueType}/summary.
Supported issue types:
Value | Category |
|---|---|
| CVE — open-source dependency vulnerabilities |
| Hardcoded secrets and credentials |
| IaC misconfigurations |
Note
Application issue summaries return counts only, not individual issue records. To retrieve individual records, list periodic scans for the application's repositories, then use GET /scans/{scanId}/issues.
Operational notes
Issue data is scan-scoped. Each issue belongs to a specific scan execution. Use
issuesFoundandissuesTypesBreakdownin scan list responses to pre-filter before retrieving individual recordsClient-side filtering. The issue endpoint supports only
severityas a server-side filter. Filter by detection method, resolution status, or assignee client-sideIssue lifecycle management. Resolution status updates and assignee changes are managed through the console. The APIs provide read access to current state
Urgency context. Urgency classification is displayed in the console. The API issue response includes severity. For Urgency-based prioritization, use the console issue tables. Refer to Urgency for more details
Pagination. Use
limitandoffsetto paginate. Continue until the response returns fewer results than the requestedlimit