Merge remote-tracking branch 'origin/main' into cspm-interim-LA-11-1

docs/en/enterprise-edition/content-collections/application-security/get-started/non-default-branch-scan.adoc

@@ -6,7 +6,7 @@
 
 You can scan branches other than the main or master, such as a feature branch or sprint  branch, to obtain a comprehensive overview of the security issues in those branches before merging them into the main branch. 
 
-NOTE: Non-default branch scanning functionality is available exclusively under the new pricing model. 
+NOTE: This feature is supported only for customers with developer-based billing. Customers on resource-based billing must switch to a developer-based plan to access it. 
 
 === Support for Non-Default Branch Scans
 

docs/en/enterprise-edition/content-collections/governance/custom-build-policies/code-editor.adoc

@@ -3,15 +3,80 @@
 [.task]
 == Code Editor
 
-Prisma Cloud supports Code Editor capability where you can  create a policy rule for custom Configuration policies during Build-time checks. Code Editor is the default view for Build  policy rule and as an example a YAML policy template is always available on the Prisma Cloud console.
+Prisma Cloud supports Code Editor capability where you can create a policy rule for custom Configuration policies during Build-time checks. Code Editor is the default view for Build  policy rule and as an example a YAML policy template is always available on the Prisma Cloud console.
 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.
 
-* *Attribute*
+=== How to Create Custom Policies
+
+[.procedure]
+
+.. Select *Policies > Add Policy > Config > Add Policy Details* and then select *Next*.
+//+
+//image::governance/code-editor.png
 +
-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.
+The Code Editor is as a default view with an example of a YAML template.
 +
-In this example, the attribute defines a back-up configuration for Redshift clusters.
+In this example, you see the YAML template with custom secrets where `secrets` is a `category`.
+//+
+//image::governance/code-editor-7.png
+
+.. Select *More Options* and then select *Clear Editor* to remove the YAML template example.
+//+
+//image::governance/code-editor-1.png
+
+.. Add your custom YAML code.
+
+.. Select *Test* to test your custom code.
+//+
+//image::governance/code-editor-2.png
 +
+For every test, the console displays up to 30 results. Each time you test your code, Prisma Cloud scans all integrated repositories to give you a list of up to 30 resources that match this custom code policy.
+//+
+//image::governance/code-editor-3.png
++
+You can also review the results for more details on the impacted resource and misconfiguration.
+//+
+//In this example you see the contextualized information about an impacted resource from your custom code.
+//+
+//image::governance/code-editor-4.png
++
+If there are errors in your custom code during a test, the console displays a solution.
+//+
+//In this example, you see solution for the errors from your code.
+//+
+//image::governance/code-editor-5.png
+
+.. Select *Validate and Next* to access *Compliance Standards* to complete the custom Build-time check policy.
+//+
+//image::governance/code-editor-6.png
++
+NOTE: 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.
+
+=== 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.
+
 [source]
 definition:
      cond_type: "attribute"
@@ -146,12 +211,12 @@ cond_type: "secrets"
    - "my-super-secret-password-regex"
 ----
 
-* *Connection State*
-+
+==== 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.
-+
+
 [source]
 definition:
        cond_type: "connection"
@@ -206,12 +271,12 @@ The table below provides instructions on how to use Connection State Operators.
 
 |===
 
-* *AND/OR Logic*
-+
+=== 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.
-+
+
 [source]
 metadata:
  name: "Ensure all AWS databases have Backup Policy"
@@ -360,46 +425,3 @@ definition:
     - "my-super-secret-password-regex"
 
 
-[.procedure]
-
-.. Select *Policies > Add Policy > Config > Add Policy Details* and then select *Next*.
-//+
-//image::governance/code-editor.png
-+
-The Code Editor is as a default view with an example of a YAML template.
-+
-In this example, you see the YAML template with custom secrets where `secrets` is a `category`.
-//+
-//image::governance/code-editor-7.png
-
-.. Select *More Options* and then select *Clear Editor* to remove the YAML template example.
-//+
-//image::governance/code-editor-1.png
-
-.. Add your custom YAML code.
-
-.. Select *Test* to test your custom code.
-//+
-//image::governance/code-editor-2.png
-+
-For every test, the console displays up to 30 results. Each time you test your code, Prisma Cloud scans all integrated repositories to give you a list of up to 30 resources that match this custom code policy.
-//+
-//image::governance/code-editor-3.png
-+
-You can also review the results for more details on the impacted resource and misconfiguration.
-//+
-//In this example you see the contextualized information about an impacted resource from your custom code.
-//+
-//image::governance/code-editor-4.png
-+
-If there are errors in your custom code during a test, the console displays a solution.
-//+
-//In this example, you see solution for the errors from your code.
-//+
-//image::governance/code-editor-5.png
-
-.. Select *Validate and Next* to access *Compliance Standards* to complete the custom Build-time check policy.
-//+
-//image::governance/code-editor-6.png
-+
-NOTE: 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.