Prisma Cloud vulnerability feed
Table of Contents
Self.Hosted 22.06 (EoL)
Expand all | Collapse all
-
- Getting started
- System Requirements
- Prisma Cloud container images
- Onebox
- Kubernetes
- OpenShift v4
- Console on Fargate
- Amazon ECS
- Alibaba Cloud Container Service for Kubernetes (ACK)
- Azure Kubernetes Service (AKS)
- Amazon Elastic Kubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Google Kubernetes Engine (GKE) Autopilot
- IBM Kubernetes Service (IKS)
- Windows
- Defender types
- Cluster Context
-
- Install a single Container Defender
- Automatically Install Container Defender in a Cluster
- App-Embedded Defender
- App-Embedded Defender for Fargate
- Default setting for App-Embedded Defender file system protection
- VMware Tanzu Application Service (TAS) Defender
- Serverless Defender
- Serverless Defender as a Lambda layer
- Auto-defend serverless functions
- Install a single Host Defender
- Auto-defend hosts
- Deploy Prisma Cloud Defender from the GCP Marketplace
- Decommission Defenders
- Redeploy Defenders
- Uninstall Defenders
-
- Rule ordering and pattern matching
- Backup and restore
- Custom feeds
- Configuring Prisma Cloud proxy settings
- Prisma Cloud Compute certificates
- Configure Agentless Scanning
- Agentless Scanning Modes
- Configure scanning
- User certificate validity period
- Enable HTTP access to Console
- Set different paths for Defender and Console (with DaemonSets)
- Authenticate to Console with certificates
- Configure custom certs from a predefined directory
- Customize terminal output
- Collections
- Tags
- Logon settings
- Reconfigure Prisma Cloud
- Subject Alternative Names
- WildFire Settings
- Log Scrubbing
- Clustered-DB
- Permissions by feature
-
- Logging into Prisma Cloud
- Integrating with an IdP
- Integrate with Active Directory
- Integrate with OpenLDAP
- Integrate Prisma Cloud with Open ID Connect
- Integrate with Okta via SAML 2.0 federation
- Integrate Google G Suite via SAML 2.0 federation
- Integrate with Azure Active Directory via SAML 2.0 federation
- Integrate with PingFederate via SAML 2.0 federation
- Integrate with Windows Server 2016 & 2012r2 Active Directory Federation Services (ADFS) via SAML 2.0 federation
- Integrate Prisma Cloud with GitHub
- Integrate Prisma Cloud with OpenShift
- Non-default UPN suffixes
- Compute user roles
- Assign roles
- Credentials store
- Cloud accounts
-
- Prisma Cloud vulnerability feed
- Vulnerability Explorer
- Vulnerability management rules
- Search CVEs
- Scan reports
- Scanning procedure
- Customize image scanning
- Configure Registry Scans
-
- Scan Images in Sonatype Nexus Registry
- Scan images in Alibaba Cloud Container Registry
- Scan images in Amazon EC2 Container Registry (ECR)
- Scan images in Azure Container Registry (ACR)
- Scan images in Docker Registry v2 (including Docker Hub)
- Scan images in Google Artifact Registry
- Scan images in Google Container Registry (GCR)
- Scan images in Harbor Registry
- Scan images in IBM Cloud Container Registry
- Scan images in Artifactory Docker Registry
- Scan images in OpenShift integrated Docker registry
- Trigger registry scans with Webhooks
- Base images
- Configure VM image scanning
- Configure code repository scanning
- Agentless scanning
- Malware scanning
- Vulnerability risk tree
- Vulnerabilities Detection
- CVSS scoring
- Windows container image scanning
- Serverless function scanning
- VMware Tanzu blobstore scanning
- Scan App-Embedded workloads
- Troubleshoot vulnerability detection
-
- Compliance Explorer
- Enforce compliance checks
- CIS Benchmarks
- Prisma Cloud Labs compliance checks
- Serverless functions compliance checks
- Windows compliance checks
- DISA STIG compliance checks
- Custom compliance checks
- Trusted images
- Host scanning
- VM image scanning
- App-Embedded scanning
- Detect secrets
- Cloud discovery
- OSS license management
- API
End-of-Life (EoL)
Prisma Cloud vulnerability feed
Information on threat intelligence and vulnerability data on Prisma Cloud is available through the Prisma Cloud Intelligence Stream(IS) feed.
Pre-filled CVEs
On Prisma Cloud, you may find vulnerabilities with a CVE identifier that neither MITRE nor NVD is reporting or is actively analyzing.
A pre-filled CVE is the result of an analysis conducted by Palo Alto Networks Unit 42 researchers.
The researchers manually review the details of each vulnerability, identify the correct range of affected releases and deliver the data to IS.
Many vulnerabilities in open-source software are assigned with a CVE ID and promptly analyzed by NVD and Linux distribution vendors.
However, some vulnerabilities take a long time to be analyzed, sometimes weeks or even months.
Having a CVE but no analysis means users have no information on the severity, affected releases, or description of the vulnerability and thereby making it impossible to defend against these vulnerabilities.
Let’s examine an example scenario. Security researchers find a vulnerability in an open source project. The vulnerability details are publicly discussed in the project’s bug tracker, e.g. in a GitHub issue. Following the discussion, the issue is fixed and a CVE ID is assigned to the issue. At this stage, NVD analysis takes place, and it may take multiple days for the NVD site to be updated with description and the affected releases range (CPE). Instead of waiting for the official analysis to complete, our researchers evaluate the vulnerability and insert the data into Prisma Cloud feeds quickly, preventing any delay in remediation of the vulnerability. When the NVD entry is fully updated, Prisma Cloud uses the official data from NVD.
PRISMA-* IDs
You may also find vulnerabilities marked with a PRISMA-* identifier. These vulnerabilities lack a CVE ID.
Many vulnerabilities are publicly discussed or patched without a CVE ever being assigned to them. While monitoring open source vulnerabilities, our team identifies vulnerabilities you need to be aware of and assigns PRISMA IDs to them whenever applicable.
For example, let’s review PRISMA-2021-0020.
A user found a bug in the Python package click and opened an issue through its open source repository on GitHub.
Our research team found this issue and determined it explains a valid security vulnerability.
Although no CVE was assigned to this vulnerability, our team promptly assigned it a PRISMA identifier and analyzed the correct range of affected releases.
Affected customers were alerted to this vulnerability despite the lack of any public vulnerability identifier.
If a CVE is ever assigned to the same vulnerability that has a Prisma ID, the CVE takes over and the PRISMA ID entry is fully replaced.
Read more about the correlation between PRISMA IDs and CVEs in this blog post.
The following diagram shows the PRISMA ID and Pre-filled CVEs assignment flow:

PRISMA-* ID Syntax
PRISMA ID syntax consists of the PRISMA prefix, year of release, and a sequence of four digits.
For example, "PRISMA-2020-1234".
This format is intentionally similar to that used by CVE IDs.
There is absolutely no correlation between the sequence used for PRISMA IDs to that of CVEs released the same year.
There is also no grouping of PRISMA IDs.
That is, there is no correlation between adjacent PRISMA ID sequences.
Investigating PRISMA-* Vulnerabilities
The vulnerability description includes the necessary information required to understand the vulnerability.
The severity is carefully determined by our team based on CVSS scoring.
You may also access the ID link to find the original source that resulted in the assignment of the PRISMA ID.
This will likely be an external advisory, a GitHub (or another bug tracker) issue, or it may directly lead you to the fix commit (pull request) when there is no correlating informational page.
Prisma ID FAQs
- Why use PRISMA-IDs?We are committed to ensuring that the Prisma Cloud Intelligence Stream provides the most accurate and up-to-date vulnerability information.Through the Intelligence Stream, Prisma Cloud should be able to alert on any relevant vulnerabilities that exist in scanned environments, regardless of having a CVE or not. Our researchers monitor open-source code repositories continuously to detect publicly discussed but undisclosed vulnerabilities that are not tracked under a CVE record. Upon finding such a vulnerability, the researchers complete a full analysis of the vulnerability including assessing its severity and describing its impact, and finally assign a PRISMA ID. The Intelligence Stream is shortly thereafter updated with the new entry, and users immediately benefit from the detection of the vulnerability by Prisma Cloud.This process allows Prisma Cloud users to be better informed and secure from vulnerabilities that are otherwise not detected by regular vulnerability management tools.
- Why not wait for a CVE-ID?Although most vulnerabilities in open-source are assigned CVEs quickly after being discovered, some vulnerabilities are not assigned a CVE for a variety of reasons. In some cases, maintainers are unaware of the process to assign CVEs, ignorant to the importance of having a CVE, or may even refuse to have CVE IDs assigned to their projects.Prisma Cloud researchers actively encourage all maintainers to assign CVE IDs to security vulnerabilities in their projects. We partner with NVD and MITRE to ensure that information regarding known vulnerabilities is public and available to everyone in the industry. PRISMA IDs are not meant to be a replacement for CVEs – PRISMA IDs are assigned to ensure our users are protected from any known threat regardless of whether a CVE was assigned to it or not.Palo Alto Networks is a CVE Numbering Authorities (CNA); we assign CVE IDs to any zero day vulnerability that we discover. The purpose of PRISMA IDs is to track vulnerabilities that were already public knowledge at the time we identified them, but were not tracked under a CVE ID.
- Why not all PRISMA-IDs get assigned with a CVE ID?As mentioned above, although we do encourage all maintainers to assign CVEs to the vulnerabilities found in their project, we keep seeing a lot of undisclosed vulnerabilities that are publicly discussed. We would be happy to see all PRISMA IDs be replaced with a CVE ID, however, we do have limited resources - and simply cannot assign a CVE for each vulnerability. For zero days found by our research team, we follow the responsible disclosure process and ask the vendor to assign a CVE or offer the assistance of Palo Alto Networks as a CNA.
- Can PRISMA-IDs be found on NVD or MITRE?Public vulnerabilities identified by our researchers, before a CVE is associated with them, are assigned a PRISMA-* identifier. You may access the reference link to get more information about the source through which our researchers discovered the vulnerability.
- Do you have a way to correlate PRISMA-ID to CVE when it is assigned a CVE?Through an ongoing maintenance process, PRISMA-IDs are replaced with a corresponding CVE ID when it is created.
- PRISMA-XXXX disappeared, what happened?When a vulnerability with a Prisma ID is assigned a CVE ID, the PRISMA ID is replaced with the new CVE. Findings will display the official CVE ID instead.
- What is the “Published Date” in Console?The Published date is the date that the CVE was published by the feed source or by NVD. This information is taken from the relevant feed - either the vendor feed or NVD.The date a CVE is published in NVD is not the date it was analyzed. The CVE can be published in NVD and only later updated with the analysis.
- Why do I see a newly added CVE with an old published/fixed date?The Published Date of the CVE is the date when the vendor published it first. The CVE may have been added to the IS after the published date because the feed is constantly updated.When a PRISMA ID or a Pre-Filled CVE is replaced with a CVE entry from NVD or a vendor’s feed, thePublished Dateof the CVE will reflect what was published in the official CVE.
- I have set a grace period and my builds were passing. Now “all of a sudden” they fail on a CVE/PRISMA ID that wasn’t there before. What happened?See the answer above.
- The severity assigned to a vulnerability is different between the IS and NVD, how is that possible?For known vulnerabilities with a CVE, we rely on the most authoritative source. For OS packages (packages that are maintained by the OS vendor, marked as type “package” in Compute), the CVE details are from the specific vendor feed. For other CVEs, the information is from official sources like NVD and vendor-specific security advisories. If the affected package is maintained by an OS vendor, the severity as indicated by the vendor is used and not the severity determined by NVD. Furthermore, for new vulnerabilities missing analysis, or undocumented vulnerabilities (such as PRISMA-IDs), we rely on severity determined by our researchers.
- How do I check if my Intelligence Stream is up to date?
- Navigate toManage > System > Intelligence.
- Verify that the Status isConnected.
- Check theLast streams update.
- How can I know which OS releases are supported?Prisma Cloud can protect containers built on nearly any base layer operating system. We update our feed with the vendor’s data only for supported versions. CVE information is provided for the base layers detailed in the system requirements for all versions except EOL versions. While our feed could still contain vulnerability data for EOL versions, it is not complete and is potentially inaccurate because of missing details on the vulnerability. If there are no vulnerabilities in our feed for a specific distro release, the version will be tagged with the following message:OS not supported and may be missing vulnerability data. Please use a supported version of the OS.
- Does the Intelligence Stream include CVE information for EOL versions?See the answer above.
- I have seen an open CVE/PRISMA vulnerability that I believe has a fix. What should I do?The IS uses the automated maintenance process for any updates to existing vulnerabilities. If you believe new information regarding a vulnerability is missing from our feed, please report it through the support channels.
- Where can I find more information on troubleshooting?See troubleshooting.