Prisma Container Scanning: Comprehensive Vulnerability Management

We introduce an operational approach that integrates a GitHub Action with the Prisma Cloud Console to detect vulnerabilities and enforce compliance early in the pipeline.

Our workflow wraps the official twistcli engine and links to the Console for policy and metadata. For example, builds set IMAGE_NAME to the repo SHA, run a docker build, then invoke the Palo Alto Networks action to evaluate images against Console thresholds.

Results are visible in workflow logs, in the Console Monitor area, and (when SARIF is uploaded) in the repository Security tab. We design gates so the pipeline can block noncompliant builds (for example, High or Critical findings) while keeping delivery predictable.

Our goal is a clear, auditable path from prerequisites and scanning to reporting and governance. This page outlines that journey and sets expectations for the sections that follow.

• We connect GitHub Actions to the Console policy engine to surface risks early.
• Workflows use a twistcli-based wrapper and can upload SARIF for triage.
• Thresholds in the Console enforce gates and support audit-ready compliance.
• Findings appear in workflow logs, the Monitor section, and the Security tab.
• This section previews an end-to-end example and the expected business outcome.
• We partner with engineering and security leadership to maintain effective controls.

We believe early security checks are essential for cloud-native applications. Catching misconfigurations and known CVEs during development reduces time-to-detect and limits impact.

Centralized policy in the prisma cloud console creates a single source of truth. Thresholds defined in the cloud console drive build blocking centrally, so pipelines stay consistent without hardcoding rules.

The official palo alto GitHub Action routes each scan to the Console and surfaces results in both the Console and GitHub. This alignment ensures findings meet enterprise standards for vulnerabilities compliance and auditability.

Embedding scans in CI gives developers immediate feedback. That fast loop shortens remediation time and encourages secure-by-default practices while preserving delivery speed.

• Operational view: dashboards tie risk to developer workflows.
• Executive value: governance, audit trails, and measurable policy adherence.
• Standard gates: prevent drift across teams while allowing project-level flexibility.

A reliable CI setup begins with validating Console endpoints and provisioning least-privileged credentials for automation. We access Compute from the console URL to confirm reachability and API responsiveness.

Locate your prisma cloud console address in the admin UI and validate network egress from runners. Verify the URL responds and that required ports are open to avoid failed jobs.

Create a scoped CI user in Compute with minimal roles. Store pcc_console_url, pcc_user, and pcc_pass as GitHub secrets. In your github workflow, set env IMAGE_NAME: ${{ github.repository }}:${{ github.sha }} to ensure traceability to a commit SHA.

For hosted runners, set DOCKER_ADDRESS (preferred) or DOCKER_HOST when needed. Provide TLS certs using docker_tlscacert, docker_tlscert, and docker_tlskey for secured sockets.

• Include a connectivity test stage to verify Console reach and Docker socket availability.
• Rotate CI secrets and scope the name and permissions per enterprise policy.

The action-based wrapper lets us invoke twistcli from a github workflow and publish structured results.

We show a simple, repeatable pattern that triggers on push and manual dispatch. The workflow sets env IMAGE_NAME: ${{ github.repository }}:${{ github.sha }}, checks out code, builds the image, and calls the Palo Alto Networks action to run an image scan.

Mandatory inputs—pcc_console_url, pcc_user, pcc_pass, and image_name—should be stored as GitHub secrets. Pin the action version (for example @v1.5) to keep behavior stable while tracking upstream fixes.

Optional parameters let teams adapt connectivity and artifacts. Use results_file and sarif_file to save JSON and SARIF outputs. Provide docker_* variables when a custom daemon or TLS certs are required.

• Outputs: JSON results and SARIF path for uploads or archiving.
• Publish: twistcli_publish toggles whether results are forwarded to the Console.
• Traceability: consistent image naming keeps scans reproducible across runs.

Severity thresholds that *alert* or *fail* builds are enforced from the Console policy. That allows governance teams to adjust thresholds without changing pipeline code.

We publish SARIF output so security findings appear where developers work. Uploading a sarif file makes results visible in the repository tab and enables automated lifecycle management for alerts.

Use the official action to upload SARIF:

• uses: github/codeql-action/upload-sarif@v2
• with: sarif_file: ${{ steps.scan.outputs.sarif_file }}
• Include if: ${{ always() }} so the upload runs even when a fail threshold stops the job.

We recommend a consistent step id (for example id: scan) and predictable name patterns so subsequent steps find the SARIF path reliably. Before upload, normalize paths (for example, use sed) so links in GitHub resolve to the correct files.

The table below summarizes where findings appear and how they behave.

We unify quality and security by surfacing scan results in both systems. This dual visibility preserves developer feedback loops and ensures compliance violations are tracked and remediated.

We harden CI by adding practical steps that make workflow runs predictable and resilient. These changes reduce false positives and make developer feedback actionable.

Normalize SARIF paths before upload so links resolve on the repository page. For example, run a sed rewrite: sed -i ‘s/${{ env.IMAGE_NAME }}:/file:/g’ ${{ github.workspace }}/pcc_scan_results.sarif_parse.json.

Validate the results file schema and fail fast if fields are missing. This prevents noisy alerts and preserves signal for triage.

Centralize reusable parsers and policy logic in a shared repository. Check it out in the job with uses: actions/checkout@v3 (repo, ref, token, path) to keep governance code versioned.

We recommend running a PowerShell or Python parser (from the central repo) to map JSON to SARIF and annotate names, branch, and image digest to aid audits.

• Implement step timeouts and retries for network phases.
• Tag builds with consistent name conventions and metadata.
• Align repository-level scripts with Console-enforced policy to preserve predictable behavior.

We walk through a concise, practical setup to get the twistcli tool on a runner, authenticate it, and produce durable scan results.

Sign into the Console and navigate to Compute > Manage > System > Utilities to download the OS-specific binary. Select the correct operating system and set executable permissions:

For automated retrieval, use a bearer token and curl to fetch the latest compatible binary:

curl --progress-bar -L --header "authorization: Bearer <YOUR_API_TOKEN>" https://<CONSOLE_URL>/api/v1/util/osx/twistcli > twistcli

Then make it executable as shown above. We recommend storing tokens in secrets and rotating them regularly.

Scan a local image with credentials and your Console address so the tool pulls policy and metadata:

./twistcli images scan -u <USERNAME> -p <PASSWORD> --address <CONSOLE_URL> <IMAGE_NAME>

For richer output and persistence enable details and write a JSON file:

./twistcli images scan -u <USERNAME> -p <PASSWORD> --address <CONSOLE_URL> --details --output-file scan_results.json <IMAGE_NAME>

Example:

./twistcli images scan -u anshu -p An$hum@@N_2000 --address https://asia-south1.cloud.twistlock.com/india-1131963775 --details --output-file scan_results.json eclipse-temurin:17-jre-alpine

• Name the target image consistently (repo:sha) and ensure it exists on the host or is reachable by the daemon.
• Validate exit codes and parse the JSON file to implement custom gates or dashboards when you do not use the GitHub Action wrapper.
• Persisting the file supports artifact retention, analytics, and ingestion into other tools.

Policy controls in the cloud console govern how image findings affect CI outcomes. Navigate to Compute > Defend > Vulnerabilities > Images > CI to create or edit CI rules. Use Add Rule or modify the Default Rule to define when alerts and fails fire.

Set separate alert and fail thresholds for Low, Medium, High, and Critical severities. Alert thresholds create warnings; fail thresholds stop the build. For example, choosing Medium for alerts omits Low findings from notifications.

We recommend starting with conservative fail thresholds (High and Critical) and tightening them as remediation improves. These central rules change pipeline outcomes immediately without editing workflow files.

Violations surface in workflow logs during runs and in the Console Monitor section for aggregated evidence. Teams cross-reference logs and Monitor entries to speed triage and verify fixes.

• Governance: central policy enforces consistent vulnerabilities compliance across projects.
• Developer experience: threshold changes affect future workflow runs without code changes.
• Tool parity: twistcli and the GitHub Action both honor the same rules for consistent outcomes.

We convert raw outputs into clear evidence so teams can triage fast and measure risk. The Prisma Cloud action emits two default artifacts: pcc_scan_results.json and pcc_scan_results.sarif.json. Storing both gives structured data for automation and a human-friendly view for audits.

The JSON file contains fields for severity, package, CVE identifiers, and remediation details. Use it to filter by severity for dashboards and to feed analytics pipelines.

The SARIF file maps issues to rules, results, and locations. Uploading the sarif file populates the repository tab so developers see issues where they work. This view helps rapid triage and links findings to the Dockerfile or build metadata.

Image context and source code context differ. Expect approximated file locations and tags when the tool maps packages to code. Despite this, most vulnerability and compliance details are preserved for each item.

• Normalize image name, tags, and repository identifiers to correlate a finding to its commit.
• Use JSON fields to build analytics on recurring vulnerabilities and package hotspots.
• Retain both JSON and SARIF artifacts with retention policies for audits and regression detection.

Scoped exceptions help teams accept short-term risk with documented justification and expiration. We recommend a formal process that ties each exception to an owner, a remediation plan, and a firm end date.

To create a CVE exception, open the relevant rule’s advanced settings. Add a new exception, enter the CVE identifier, set Effect to Ignore, record the rationale in the description, and assign an expiration date.

Scope exceptions by navigating to Compute > Manage > Collection & Tags. Create tags (for example, ignored/CVE-2024-xxxx) and map them to Resource Type = Images, specific package scopes, and repository name patterns (wildcards and :latest).

• Apply exceptions by Tag in the rule advanced settings to avoid global impact.
• Use a naming convention to make audits straightforward (for example, ignored/<CVE>).
• Review approaching expirations and notify owners to remediate or rejustifiy.

A predictable troubleshooting path helps teams resolve SARIF, daemon, and tool issues fast.

Place the SARIF upload after the scan step and use if: ${{ always() }} on github/codeql-action/upload-sarif@v2. This ensures the Security tab receives the file even when severity gates fail the run.

Validate the SARIF before upload. Common faults include missing paths, malformed JSON, and schema mismatches. Run a quick JSON lint and schema check to avoid silent drops.

Check DOCKER_ADDRESS first; fallback to DOCKER_HOST if needed. For TLS-protected daemons, set docker_tlscacert, docker_tlscert, and docker_tlskey so runners can authenticate.

On hosted runners confirm socket permissions. On self-hosted hosts verify daemon reachability and restart the service before rerunning the workflow.

• Run twistcli --version and a dry --help or dry-run to confirm the tool is present and compatible.
• Pin the Palo Alto Networks action (for example @v1.5) and review SUPPORT.md for breaking changes.
• Enable verbose logs or twistcli_debug, add retries for network phases, and confirm repository token scopes for code scanning uploads.

To conclude, embedding a policy-driven image analysis into the CI workflow delivers reliable gates and clear audit trails.

We recommend using the Prisma Cloud GitHub Action to run a twistcli-based scan, publish JSON and SARIF artifacts, and honor Console thresholds so failures and alerts are consistent across the cloud estate.

SARIF uploads surface findings in the repository Security tab for developer triage, while JSON artifacts support analytics, audits, and remediation measurement.

Scope exceptions with tags and collections, apply expirations, and standardize naming across repositories and images. Start with critical controls, measure remediation, and raise the bar iteratively to balance velocity and security.

Next step: adopt consistent metadata, monitor remediation metrics, and use policy-driven enforcement to keep vulnerabilities compliance predictable and auditable.