> For the complete documentation index, see [llms.txt](https://docs.prismacloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prismacloud.io/content-collections/governance/custom-build-policies/code-editor.md). # Code Editor Prisma Cloud’s Code Editor allows you to define advanced custom policies for build-time checks. Users can leverage YAML templates, logic operators, and framework support to create complex policies tailored to specific compliance or security requirements. The Code Editor is a suitable option when you want to create complex custom policies that include both Attribute and Connection-State with a support of AND/OR logic. However, for custom secrets Code Editor supports only an OR logic. ## How to Create Custom Policies 1. Select **Governance** > Add Policy > Config > Add Policy Details\* and then select **Next**. The Code Editor provides a default view with an example of a YAML template. See [YAML Policy Attribute](#yml_attr) below for details of the YAML file attributes. 2. Select **More Options** and then select **Clear Editor** to remove the YAML template example. 3. Add your custom YAML code. 4. Select **Test** to test your custom code. Each test displays up to 30 results. Prisma Cloud scans all integrated repositories to identify resources that match your custom policy, providing a maximum of 30 results per test. You can review these results for detailed information about impacted resources and misconfigurations. If your custom code contains errors, the console will display suggested solutions. 5. Select **Validate and Next** to access **Compliance Standards** to complete the custom Build-time check policy. You are in **Step 2** of Create Custom Policies for Build-Time Checks. You are required to complete the rest of the steps to see your new custom Build-time check policy on the Prisma Cloud console. ## YAML Policy Attributes The Yaml file includes the following arguments: * **guidelines**: Sets general rules for policy creation * **category**: Specifies the type of policy * **frameworks**: Identifies the applicable framework. If no framework is specified, the policy applies to all frameworks. If a framework is specified, the policy applies only to the selected framework * **scope**: Defines the level of applicability for the policy * **provider**: Specifies the cloud provider or source for the resources * **definition**: Contains the logic and conditions for the policy, including attributes, operators, and resource connections ## Limitation Nesting connection condition types within a 'NOT' block is not currently supported. EXAMPLE ``` definition: not: cond_type: "connection" resource_types: - "aws_elb" connected_resource_types: - "aws_security_group" operator: "exists" ``` ## Key Capabilities of the Code Editor ### Attribute-Based Policies Attribute when defined in a policy describes attribute configurations for resources. Each resource must contain values the attribute configuration has specified or display the presence or absence of the attribute configuration. The syntax and attribute configurations used in YAML templates is similar to Terraform. In this example, the attribute defines a back-up configuration for Redshift clusters. ``` definition: cond_type: "attribute" resource_types: - "aws_redshift_cluster" attribute: "automated_snapshot_retention_period" operator: "not_equals" value: "0" ``` The table below provides instructions on how to use Attributes with matching keys and values. | Key | Type | Values | | --------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | cond\_type | string | Must be attribute | | resource\_type | collection of strings | Use either `all` or `[resource types from list]` | | attribute | string | Attribute of defined resource types. For example, `automated_snapshot_retention_period` | | operator | string | `equals`, `not_equals`, `regex_match`, `not_regex_match`, `exists`, `not exists`, `any`, `contains`, `not_contains`, `within`, `starting_with`, `not_starting_with`, `ending_with`, `not_ending_with`, `greater_than`, `greater_than_or_equal`, `less_than`, `less_than_or_equal`, `jsonpath_equals`, `jsonpath_exists`, `intersects`, `not_intersects` | | Value (not relevant for operator: `exists`, `not_exists`) | string | User input | The table below provides instructions on how to use Attribute Operators. | Attribute Operators | YAML values | | --------------------- | ----------------------- | | Equals | `equals` | | Not Equals | `not_equals` | | Regex Match | `regex_match` | | Not Regex Match | `not_regex_match` | | Exists | `exists` | | Not Exists | `not_exists` | | One Exists | `one_exists` | | Any | `any` | | Contains | `contains` | | Not Contains | `not_contains` | | Within | `within` | | Starts With | `starting_with` | | Not Starts With | `not_starting_with` | | Ends With | `ending_with` | | Not Ends With | `not_ending_with` | | Greater Than | `greater_than` | | Greater Than Or Equal | `greater_than_or_equal` | | Less Than | `less_than` | | Less Than Or Equal | `less_than_or_equal` | | Subset | `subset` | | Not Subset | `not_subset` | | Json Path Equals | `jsonpath_equals` | | Json Path Exists | `jsonpath_exists` | | Intersects | `intersects` | | Not Intersects | `not_intersects` | Attribute Operators support IaC scans. The regex operator can be implicitly used for Secrets. As seen in this example, there is no "regex" explicitly defined. It’s implicit when creating a secret policy. ```yaml cond_type: "secrets" value: - "[A-Za-z0-9]{8,20}" - "my-super-secret-password-regex" ``` ### Connection-Based Policies Connection State when defined in a policy specifies a connect or disconnect between resources of different types. In this example, `aws_lb` and `aws_elb` must have connection with `aws_security_group` or `aws_default_secuirty_group` to be compliant. ``` definition: cond_type: "connection" resource_types: - "aws_elb" - "aws_lb" connected_resource_types: - "aws_security_group" - "aws_default_security_group" operator: "exists" ``` The table below provides instructions on how to use Connection State types. | Key | Type | Values | | -------------------------- | --------------------- | -------------------------------------------------------- | | cond\_type | string | Must be connection | | resource\_types | | Use either `all` or `[included resource type from list]` | | connected\_resource\_types | collection of strings | Use either `all` or `[included resource type from list]` | | operator | string | `exists`/`not exists` | The table below provides instructions on how to use Connection State Operators. | Connection State Operators | YAML values | | -------------------------- | ------------ | | Exists | `exists` | | Not Exists | `not_exists` | ## Logical (AND/OR) Operators A policy may include layers of defined Attributes and Connection State, or both. To define the connection between the two AND/OR logic is used. Using Code Editor you can customize the Attribute, Connection State or both at multiple layers. In this example, you see the both AND/OR logic applied to Attribute. ``` metadata: name: "Ensure all AWS databases have Backup Policy" guidelines: "In case of non-compliant resource - add a backup policy configuration for the resource" category: "storage" severity: "medium" scope: provider: "aws" definition: or: - cond_type: "attribute" resource_types: - "aws_rds_cluster" - "aws_db_instance" attribute: "backup_retention_period" operator: "not_exists" - cond_type: "attribute" resource_types: - "aws_rds_cluster" - "aws_db_instance" attribute: "backup_retention_period" operator: "not_equals" value: "0" - cond_type: "attribute" resource_types: - "aws_redshift_cluster" attribute: "automated_snapshot_retention_period" operator: "not_equals" value: "0" - cond_type: "attribute" resource_types: - "aws_dynamodb_table" attribute: "point_in_time_recovery" operator: "not_equals" value: "false" - cond_type: "attribute" resource_types: - "aws_dynamodb_table" attribute: "point_in_time_recovery" operator: "exists" ``` In this example, you see the AND/OR logic applied to both Attribute and the Connection State. ``` metadata: name: "Ensure all ALBs are connected only to HTTPS listeners" guidelines: "In case of non-compliant resource - change the definition of the listener/listener_rul protocol value into HTTPS" category: "networking" severity: "high" scope: provider: "aws" definition: and: - cond_type: "filter" value: - "aws_lb" attribute: "resource_type" operator: "within" - cond_type: "attribute" resource_types: - "aws_lb" attribute: "load_balancer_type" operator: "equals" value: "application" - or: - cond_type: "connection" resource_types: - "aws_lb" connected_resource_types: - "aws_lb_listener" operator: "not_exists" - and: - cond_type: "connection" resource_types: - "aws_lb" connected_resource_types: - "aws_lb_listener" operator: "exists" - cond_type: "attribute" resource_types: - "aws_lb_listener" attribute: "certificate_arn" operator: "exists" - cond_type: "attribute" resource_types: - "aws_lb_listener" attribute: "ssl_policy" operator: "exists" - cond_type: "attribute" resource_types: - "aws_lb_listener" attribute: "protocol" operator: "equals" value: "HTTPS" - or: - cond_type: "attribute" resource_types: - "aws_lb_listener" attribute: "default_action.redirect.protocol" operator: "equals" value: "HTTPS" - cond_type: "attribute" resource_types: - "aws_lb_listener" attribute: "default_action.redirect.protocol" operator: "not_exists" - or: - cond_type: "connection" resource_types: - "aws_lb_listener_rule" connected_resource_types: - "aws_lb_listener" operator: "not_exists" - and: - cond_type: "connection" resource_types: - "aws_lb_listener_rule" connected_resource_types: - "aws_lb_listener" operator: "exists" - or: - cond_type: "attribute" resource_types: - "aws_lb_listener_rule" attribute: "default_action.redirect.protocol" operator: "equals" value: "HTTPS" - cond_type: "attribute" resource_types: - "aws_lb_listener_rule" attribute: "default_action.redirect.protocol" operator: "not_exists" ``` In this example, you see the OR logic applied to Custom Secrets. ``` metadata: name: "My Secret" guidelines: "Don't add secrets" category: "secrets" severity: "high" definition: cond_type: "secrets" value: - "[A-Za-z0-9]{8,}" - "my-super-secret-password-regex" ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.prismacloud.io/content-collections/governance/custom-build-policies/code-editor.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.