ORL overview

What Is ORL?

ORL (Open Remediation Language) is a domain-specific language developed by Gomboc that evaluates policies in your code and acts as the execution engine for enforcing those policies by detecting issues and generating deterministic fixes.

It powers how Gomboc:

• Understands your code and define context (what tech, what risk, what policy intent)

• Finds issues and points to the exact code locations

• Applies automated, deterministic fixes

• Validates outcomes to ensure fixes are safe and repeatable

From a user perspective:

• You don's need to write ORL directly.

• You manage Policies, Frameworks, and Policy Sets.

• ORL is the engine that turns those policies into concrete deterministic code changes.

• Optionally extended by customers with custom rules to enforce internal standards the same way built-in policies are enforced.

---

Why ORL (and the problem it solves)?

ORL was build to bridge two worlds:

• Generative / agentic AI (helpful for reasoning and suggestions, but probabilistic)

• Production code and infrastructure changes (must be predictable, repeatable, and auditable)

ORL provides:

Deterministic remediation

• Provides powerful domain specific abstractions.

• Fixes are repeatable across runs, repos, and teams.

• The same input code produces the same output change set.

Syntax-aware targeting (no brittle regex)

With a flexible data model that supports multiple languages and versions, ORL remediates code by matching syntax trees (via Tree-sitter queries / S-expressions), so it can:

• Locate the exact attribute/block/resource that needs change

• Avoid accidental matches typical of search/replace approaches

• Apply transformations precisely, even in large or complex repos

Separation of concerns

• ORL cleanly separates:

  • Rule logic (what to detect + how to remediate) from

  • Policy hierarchy metadata (how the rule is categorized/exposed via Policies, Frameworks, Policy Sets)

Scales safely across organizations

• ORL rules are designed to support:

  • Multiple tools/providers/code resource types

  • Bulk remediation with ordering and dependency handling

  • Auditable diffs and validation signals (so developers review less and trust more)

• A central, queryable API that Gomboc and (optionally) users can use

---

How ORL fits into Gomboc

Gomboc’s platform is designed to move teams from visibility → action, translating policy violations into auditable, reviewable code changes that fit existing workflows. ORL is the mechanism that makes those fixes:

• predictable (deterministic transformations)

• scalable (bulk application across many repos)

• safe to review (clear diffs, consistent results)

• explainable (metadata + policy mappings)

---

How ORL fits into Policies

ORL is the engine, execution layer, and rule format. Policies are how that logic is organized, the user-facing layer, and are exposed to you across different code tools, resource types, and cloud providers.

In practice, for most users, ORL is behind the scenes. You interact with it through:

Policies & Frameworks

When you browse the Gomboc policy catalog, you’re selecting policies that map to one or more ORL rules.

A single Policy may include multiple ORL rules to cover variations across:

• IaC tools (Terraform, CloudFormation, Kubernetes manifests, Helm, etc.)

• Cloud providers (AWS, Azure, GCP, OCI, Kubernetes, etc.)

• Resource types (e.g., EBS volumes vs. RDS vs. IAM vs. AKS configuration)

Frameworks then group policies into higher-level compliance/architecture lenses (e.g., CIS, internal standards, critical controls).

Policy Sets

When you build a Policy Set, you’re choosing which policies, and therefore which ORL rules, apply to a workspace/repo.

Policy Sets are how you tune enforcement by:

• Environment (dev/stage/prod)

• Team ownership

• Platform type

• Risk tolerance / change controls

Findings and Fixes

When a scan runs, Gomboc resolves:

Workspaces → Policy Sets → Policies → ORL rules

Then ORL executes to produce:

• Findings (where policy intent is violated)

• Fixes (deterministic code changes that remediate the finding)

(Advanced) Custom ORL rules

Advanced users can write custom ORL rules to encode internal standards and have them enforced like built-in policies.

Typical workflow:

1. Author ORL YAML rule files

2. Validate rule behavior (audit matches expected, remediation applies cleanly)

3. Publish into Gomboc

4. Map to your internal policy categories (optional)

5. Include in Policy Sets like any other policy

This allows teams to standardize and automate fixes for:

• Internal platform guardrails

• Org-specific tagging/ownership rules

• Custom encryption/key management patterns

• Networking conventions

• Logging/monitoring defaults

[!NOTE] For details, see: Custom Rules with ORL (Advanced) (upcoming).

---

FAQ

Is ORL only for Terraform?

No! ORL is designed as a remediation spec that can be applied to multiple code types, as long as there’s a supported parser/syntax tree model. ORL currently supports many langauges. The full list can be seen via docker run --rm gombocai/orl language.

How is this different from policy-as-code (OPA/Sentinel)?

Policy-as-code answers: “Is this allowed?” ORL adds: “Exactly how do I fix it, deterministically! and prove it’s fixed?”