New in Bridgecrew: YAML-based policy creator and composite custom policies

Industry benchmarks such as those set by the Center for Internet Security (CIS) provide a great starting point for enforcing cloud security and compliance best practices, but they’re not always enough. Enforcing your own industry- or domain-specific requirements is equally important when building a solid cloud security posture. That’s where custom policies come in, helping teams create and enforce guardrails relevant to their unique needs.

Today we’re excited to extend Bridgecrew’s existing custom policy creator with the addition of a YAML-based policy editor and support for custom composite language checks.

YAML-based policy-as-code editor

With Bridgecrew’s YAML-based policy-as-code editor, you can create, share, document, test, and roll back custom policies across all assets no matter which cloud provider or IaC framework you’re using.

To create custom policies, head to the Policies view in your Bridgecrew account and select New Policy. This will open the code editor by default, but you can always switch to the no-code visual editor.

The code editor contains some lightweight IDE capabilities such as comments, auto-formatting, and unique schema autocompletion for accurate policy-as-code composition. If errors in your YAML syntax are identified, the editor will highlight them.

Once syntax errors are resolved, select Test to validate your policy definition structure. When your policy is free of syntax or definition errors, Bridgecrew will scan existing resources against the custom policy. Resources that violate the policy will populate in the panel to the right of the editor, allowing you to verify your custom policy on the fly and ensure it’s achieving your desired goal.

Writing a custom composite check

As part of this update, Bridgecrew now also enables you to write your own composite language checks. Composite checks extend Bridgecrew scanning to support any resource connection state and check whether specific connections between resources exist.

For example, you can write a custom policy that checks for unwanted configurations for two connected resources. Let’s walk through step-by-step what writing that custom policy would look like.

Step 1: Define your policy and add metadata

Once you know the goal of your policy and desired state of your resource, complete the metadata for the custom policy:

  • Name: Policy name, phrased in such a way that it reflects the desired state
  • Guidelines: Policy description and fix details in case of a policy error
  • Category: String for the area of cloud functionality the policy relates to, for example, IAM, Secrets, or Storage.
  • Severity: String for the policy’s associated severity which can be used for filtering and prioritizing.

For our example policy, this what that would look like:

metadata:
 name: "Ensure all EC2s are connected only to encrypted EBS volumes"
 guidelines: "In case of non-compliant resource - change attached EBS volume's attribute to encrypted=true"
 category: "storage"
 severity: "high"

Step 2: Set the scope for your policy

Next, define which CSP you’re planning to check—AWS, Google Cloud, or Azure.

For our example policy, we’ll set it to:

scope:
  provider: "aws"

Step 3: Define your policy

Now comes the fun part—writing the logic that defines the desired state you want to enforce. Resources that do not comply with the logic will be considered a policy violation or error.

Bridgecrew supports three definition blocks which have different conditions and can be strung together with AND/OR logic:

  • Attribute: Indicates that a resource will be non-compliant if a certain configuration attribute does not have a specified value or if it exists/doesn’t exist.
  • Connection: Indicates a type of resource that has/doesn’t have a connection to another type of resource.
  • Filter: Can be used to limit the types of resources relevant to a condition and are most commonly used for Connection blocks.

To define our example policy, we want to:

  1. Ensure “aws_ebs_volume” has an attribute of “encrypted” = “true”
  2. Ensure “aws_ebs_volume” is connected to “aws_instance” through a third resource, “aws_volume_attachment”.

Using AND logic, that policy definition would be:

definition:
    and:
        - cond_type: "attribute"
          resource_types:
          - "aws_ebs_volume"
          attribute: "encrypted"
          operator: "equals"
          value: "true"
        - cond_type: "connection"
          resource_types:
          - "aws_volume_attachment"
          connected_resource_types:
          - "aws_ebs_volume"
          operator: "exists"
        - cond_type: "filter"
          attribute: "resource_type"
          value:
           - "aws_ebs_volume"
          operator: "within"

Once we test and save our custom policy, Bridgecrew will scan existing resources against it and will include it in all future scans.

To learn more about custom policies, feel free to explore our docs:

We hope that these improvements to our policy creation experience not only make it easier to enforce custom policies, but also make it easier to share, edit, and reuse policies.

Happy policy-as-coding!