Write and test policies

Visual Builder

The Visual Builder provides a graphical interface to create policies without writing code.

Policy Configuration

Policy Sidebar contains:

• Policy Name: Descriptive name for identification
• Enabled Toggle: Activate or deactivate the policy
• Scope: Define what the policy evaluates (e.g., Components)
• Priority: Set evaluation order for multiple policies
• Description: Explain the policy's purpose

Building Rules

Rule Builder lets you define conditions:

1. Rule Name: Label for the rule
2. Violation Message: Custom message displayed when violated
3. Violation Severity: Impact level (Low, Medium, High, Critical)

Adding Conditions:

• Property Dropdown: Select property (e.g., component.type, vulnerability.severity)
• Operator Dropdown: Choose comparison (equals, greater than, etc.)
• Value Field: Set comparison value

Combining Conditions:

• Multiple statements in one rule = AND logic (all must match)
• Multiple rules in one policy = OR logic (any can match)

Action Buttons

• Cancel: Discard changes
• Preview: Test policy without saving
• Save: Apply changes to policy
• Convert to Rego: Transform to code-based policy
• Save a Copy: Duplicate policy configuration

Rego Policies

Rego is a declarative language from Open Policy Agent (OPA) designed for policy evaluation over structured data.

Why Use Rego?

• Version Control: Track policy changes in Git
• Advanced Logic: Complex conditions beyond visual builder
• Consistency: Same policy across all environments
• Industry Standard: Used by Kubernetes, Terraform, cloud platforms

Input Data Structure

Policies receive input data with:

Component properties:

• id, name, version, type
• packageUrl (PURL format)
• licenses array
• internal flag (true for first-party code)

Vulnerability properties:

• severity (0-10 CVSS score)
• vendorId (CVE identifier)
• epss (Exploit Prediction Scoring System)
• vex (Vulnerability Exploitability eXchange status)

VEX States:

• not_affected — Component not impacted
• false_positive — Incorrectly flagged
• resolved — Fixed in current version
• resolved_with_pedigree — Fixed with verification

Rego Example

This policy flags libraries with high-severity vulnerabilities and high EPSS scores that don't have VEX resolutions:

package observer

import future.keywords.in

violation[v] {
	input.component.type == "library"

	some vulnerability in input.vulnerabilities
	vulnerability.severity > 7
	vulnerability.epss > 0.5

	# Exclude VEX-resolved vulnerabilities
	not vulnerability.vex.state == "not_affected"
	not vulnerability.vex.state == "false_positive"
	not vulnerability.vex.state == "resolved"
	not vulnerability.vex.state == "resolved_with_pedigree"

	v := {
		"severity": vulnerability.severity,
		"message": sprintf(
			"%s with severity>7 (%v) and EPSS>0.5 (%0.2f) is not tolerated",
			[
				vulnerability.vendorId,
				vulnerability.severity,
				vulnerability.epss,
			],
		),
	}
}

Notice how the policy accesses input.component.type, input.vulnerabilities, and vulnerability.vex.state — these correspond to the input data structure described above.

Test in Playground

Use the Rego Playground to test policies interactively:

1. Paste the policy code into the editor
2. In the input section, paste the sample input data
3. Click Evaluate to run the policy
4. Review the violation output

The playground provides instant feedback, making it ideal for both learning Rego and debugging complex policies.

JavaScript Policies

JavaScript policies offer flexibility with a familiar language. Define a Policy function that returns violations.

Input Data Structure

Policies receive input data with:

Component properties:

• id, name, version, type
• packageUrl (PURL format)
• licenses array
• internal flag (true for first-party code)

Vulnerability properties:

• severity (0-10 CVSS score)
• vendorId (CVE identifier)
• epss (Exploit Prediction Scoring System)
• vex (Vulnerability Exploitability eXchange status)

VEX States:

• not_affected — Component not impacted
• false_positive — Incorrectly flagged
• resolved — Fixed in current version
• resolved_with_pedigree — Fixed with verification

Policy Function Structure

The Policy function:

1. Accepts parameters: { component, vulnerabilities, namespace }
2. Processes logic: Evaluate conditions using JavaScript
3. Returns violations: Array of violation objects
4. Returns null: When no violations found

JavaScript Example

This policy flags components with vulnerabilities above severity threshold:

function Policy({ component, vulnerabilities }) {
  const SEVERITY_THRESHOLD = 7;

  if (vulnerabilities && vulnerabilities.length > 0) {
    return vulnerabilities
      .filter((vulnerability) => vulnerability.severity > SEVERITY_THRESHOLD)
      .map((vulnerability) => ({
        severity: vulnerability.severity,
        message: `${component.name} has a high-severity vulnerability (ID: ${vulnerability.vendorId}, Severity: ${vulnerability.severity}). Immediate attention required.`,
      }));
  }

  return null;
}

Notice how the function accesses component.name, vulnerability.severity, and vulnerability.vendorId — these correspond to the input data structure described above.

Benefits of JavaScript

• Familiar syntax for most developers
• Standard library access for string manipulation, dates, etc.
• Flexible logic with loops, conditionals, functions
• Easy debugging with conventional tools