Policies determine if cloud resources are vulnerable based on scanned metadata.
The following table lists metadata that you can use:
Additional context on the policy
A human readable name for the policy
A unique identifier for a policy, generally in the form of
A URL explaining more details on the configuration, often site documentation
The type of resource(s) to analyze with the policy
A URL to detailed instructions on how to fix the issue
The potential impact of a misconfiguration
Resource Id patterns to ignore in the policy
One or more categorizations of a policy
The following table describes each of the severity levels with an example:
No risk, simply informational
Name formatting, missing tags. General best practices for ops.
Little to no risk if exploited
Non sensitive information leaking such as system time and OS versions.
Moderate risk if exploited
Expired credentials, missing protection against accidental data loss, encryption settings, best practice settings for audit tools.
Very damaging if exploited
Large gaps in visibility, directly vulnerable infrastructure, misconfigurations directly related to data exposure.
Causes extreme damage if exploited
Public data or systems, leaked access keys.
There are two ways to write Policies, in the provided Panther UI and locally with your normal developer workflow. The sections below detail how each work.
To add a new Policy in the Panther UI, click the
Create New button on the List Policies page:
When writing policies locally, you must construct two files: The Python function body, and a JSON or YAML specification file. The body contains logic to determine vulnerable resources, and the specification file contains policy metadata and configuration settings.
Similar to the web UI, the policy body only has only three requirements:
The policy body must be valid python3 code
The policy body must define a
policy function that accepts one argument
policy function must return a
Other than that, the policy body can contain anything you find useful to writing your policies. Helper functions, global variables, comments, etc. are all permitted. By convention, we name the argument to the
resource, so a minimal (and useless) policy body would be such:
def policy(resource):return True
resource will be a map, with keys of type
str. For definitions of these maps, see the Resources documentation.
The policy specification file must be valid JSON or YAML, with a
.yaml file extension as appropriate. The accepted fields for the policy specification file are detailed below.
Indicates whether this specification is defining a policy or a rule
Whether this policy is enabled
The name (with file extension) of the python policy body
The unique identifier of the policy
What resource types this policy will apply to
List of strings
What severity this policy is
One of the following strings:
How long (in seconds) to delay auto-remediations and alerts, if configured
Not used at this time
The unique identifier of the auto-remediation to execute in case of policy failure
What parameters to pass to the auto-remediation, if one is configured
A brief description of the policy
What name to display in the UI and alerts. The
The reason this policy exists, often a link to documentation
The actions to be carried out if this policy fails, often a link to documentation
Tags used to categorize this policy
List of strings
Unit tests for this policy. See Testing for details on how unit tests are formatted.
List of maps