20.09 Release Notes

This section provides a snapshot of the new features introduced in Prisma™ Cloud Compute Edition version 20.09.

New features

  • Revamps host runtime protection with a node-centric approach. Learning has been replaced with monitoring. The pivot on Radar is now VM-level rather than service-level.
  • Adds support for scoping host rules by distro name and distro version.
  • Adds support for runtime protection for apps running on VMWare Tanzu TAS.
  • Extends Cloud Discovery to detect unprotected VMs in AWS.
  • Adds support for scanning and detecting vulnerable components in git repositories.
  • Adds support for sending alerts ServiceNow Vulnerability Response and Security Incident Response applications.
  • Intoduces cluster awareness to policies and views. You can now inspect, monitor, and select resources by cluster.
  • Adds support for authenticating with OAuth 2.0 and OpenID Connect. OAuth 2.0 is supported for GitHub and OpenShift.
  • Enhances dialogs throughout the product with links to related data so you get full context for the entities in your environment.
  • Adds support for migration from Prisma Cloud Compute Edition (self-hosted) to Prisma Cloud Enterprise Edition (SaaS).
  • Refines the way the scanner detects vulnerable components.
  • [Prisma Cloud Enterprise Edition] Creates credentials for Compute use-cases during the account onboarding process. Credentials can be surfaced and used for registry scanning, cloud discovery, and other third party integrations.
  • Adds Python 3.8, Java 11, and .NET Core 3.1 to the list of supported runtimes for Serverless Defender.
  • Introduces a unified, more powerful filtering component to Console UI views.
  • Fixes an issue where twistcli image scans on podman nodes could only be run as root.
  • [Prisma Cloud Enterprise Edition] Introduces Read-Only user assignment to accounts that are not on-boarded in Prisma Cloud via "Non-onboarded cloud account resources" selection box.
  • Adds custom compliance checks for hosts.

Web-Application and API Security (WAAS)

This release substantianally advances CNAF’s capabilities. CNAF has been renamed to WAAS. WAAS integrates web application and API protection capabilities into a single framework.
  • Adds security enforcement based on API definitions (Swagger, OpenAPI, or manually specified).
  • Adds protection for all OWASP Top 10 attacks.
  • Upgrades protocol and message formats support.
  • Enhances Defender to automatically detect web apps and APIs that require WAAS protection.
  • Enriches WAAS syslog messages.
  • Adds a central repository of named lists of IP addresses that can reused in WAAS rules.

Upgrade considerations

  • PCF Defender — If you’re upgrading from 20.04, you must completely remove the 20.04 tile before installing the 20.09 tile. Previous versions of the tile deployed a single Defender on a single stand-alone VM for blobstore scanning only. The new tile deploys Defender to every Diego cell to protect your apps at runtime. Blobstore scanning is still supported with the new deployment architecture.
  • Windows Defender — The upgrade process uninstalls and then reinstalls the Windows driver. Although unlikely, there’s a potential race condition where the uninstall might run after the install. You’ll know you’re impacted if the status page for your Windows Defender shows a warning icon for process monitoring. To resolve the issue, run the following command, then restart Defender:
    C:\Program Files\Twistlock\defender.exe driver --install
  • Enforcment in CNNF is not supported in 20.09 but will return in the next major release. If you rely on CNNF enforcement, consider skipping 20.09. When the next major release ships, steps will be provided to export rules from 20.04 and import them into it. CNNF rules will be deleted on upgrade.
  • After upgrading from 20.04 to 20.09, App-Embedded Defenders will continue to protect your application as specified by existing runtime and CNAF rules. However, you won’t be able to modify these rules. To do away with this restriction, redeploy your apps with 20.09 App-Embedded Defenders.
  • Defender DaemonSet has been updated to support Istio 1.4 and later. Defenders now request Authorization Policies from
    security.istio.io
    . If your environment supports Istio Authorization Policy, you must manually redeploy the Defender DaemonSet.
  • The behavior for flags passed to
    twistcli scan images
    has been updated. The default value for the
    --publish
    flag is now
    true
    , which means that scan results are published to Console by default (see
    Monitor > Vulnerabilities > Images > CI
    ). To output results to a local file, use the
    --output-file
    option. Use both the
    --output-file
    and
    --publish
    in conjunction to control where results are sent. For example, you might want to get local scan results only without spamming Console’s database. Remember that Console stores a maximum of 1000 scan reports on a FIFO basis.
    If you’re using the
    --ci
    flag, update your scripts to use
    --output-file
    and
    --publish
    instead. The
    --ci
    flag is considered deprecated, although it’s still available as a hidden option However, starting with this release, you won’t be able to depend on support for it.
  • As part of the revamped host runtime protection feature in 20.09, all host models, host audits, and host incidents will be deleted when you upgrade.
  • Audit logs are now subject to the caps documented here. When you upgrade, the oldest audits that exceed these caps will be dropped.

Breaking changes

  • The heading for the image vulnerabilities CSV file has changed from
    Tags
    to
    Vulnerability Tags
    .
  • To control Console resource consumption, limits have been put in place. As part of this change:
    • Container models will be dropped when you upgrade 20.09. New models will be created from scratch using the normal learning process.
    • Vulnerability alerts that arise from registry scans will now trigger for the 50 most recent images only, as sorted by last modified date.

Breaking changes in the API

For more information about our policy on keeping the API stable, see here.
  • Starting in 20.09, all endpoints that take credentials now uniformly reference them by credential ID. Credential details are no longer specified inline with POST requests or returned in GET responses in the
    credential
    object. If you’re configuring registry or serverless scanning via the API, you’ll need to update the way you invoke the following endpoints to reference the credential ID:
    • /api/v1/settings/registry
    • /api/v1/settings/serverless-scan
      The following snippet shows the response from
      GET /api/v1/settings/registry
      in 20.09. Notice that the
      credential
      object now holds null values. The
      credentialID
      is what Primsa Cloud uses to scan the registry.
      { "registry": "gcr.io", "repository": "sandbox/jon/prom/*", "tag": "*", "cap": 5, "os": "linux", "hostname": "", "namespace": "", "useAWSRole": false, "version": "gcr", "credential": { "_id": "", "type": "", "accountID": "", "accountGUID": "", "secret": { "encrypted": "" }, "apiToken": { "encrypted": "" }, "lastModified": "0001-01-01T00:00:00Z", "owner": "", "tokens": null }, "credentialID": "GCR Scanning", "roleArn": "", "scanners": 2, "versionPattern": "" }
  • The method for calling the following Defender-related endpoints has changed from
    GET
    to
    POST
    :
    • /api/v1/scripts/defender.sh
    • /api/v1/scripts/defender.ps1
    • /api/v1/defenders/helm/twistlock-defender-helm.tar.gz
    • /api/v1/defenders/daemonset.yaml
  • The subresource for endpoints that manage serverless autoprotect have changed from from
    serverless-auto-protect
    to
    serverless-auto-deploy
    . The new endpoints in 20.09 are:
    • POST /api/v1/settings/serverless-auto-deploy
    • GET /api/v1/settings/serverless-auto-deploy
    • GET /api/v1/statuses/serverless-auto-deploy
  • For a complete list of deprecated endpoints in 20.09, see the porting guide.

Deprecated this release

  • Prisma Cloud High Availability (HA). For HA, use a container orchestrator, such as Kubernetes, to run and manage the Console container.

Known issues

  • On OpenShift 4 clusters, we do not currently show any image labels or layer information. This is being addressed in our next major release, which will continue our goal of parity for dockerless OpenShift environments.

Upcoming deprecations

  • Support for deploying Prisma Cloud to DC/OS will be deprecated next release.
  • SCAP support will be deprecated in the next release.
  • Scale projects will be deprecated in the next release. Starting in the next release, each Console, including each tenant project Console, will be able to support 10,000 Defenders. For information about how to migrate your scale projects to a supported configuration, see here.

Recommended For You