# Introduction to Gomboc Welcome to Gomboc, your Coding Copilot for automated deterministic code remediation. ### What is Gomboc? Gomboc is an AI-powered coding platform that automatically generates merge-ready code fixes. Instead of generating alerts and findings like traditional scanners, Gomboc delivers deterministic, reviewable pull requests that clear your code issues backlogs and keep your pipelines moving. {% embed url="" fullWidth="false" %} *** ### How Gomboc Works Gomboc's deterministic AI engine operates through a multi-stage process that transforms high-level policies into precise, validated code changes. Unlike generative AI which is probabilistic and can produce inconsistent results, Gomboc uses a deterministic approach for reliable, repeatable code fixes. You’re always in control. #### The Gomboc Workflow ``` Policy Definition → Code Analysis → Deterministic Fix Generation → PR Delivery ``` 1. Understands your environment 2. Turns policies into executable rules 3. Analyzes your code with full context 4. Generates deterministic fixes with [ORL (Open Remediation Language)](https://docs.gomboc.ai/policy-management/orl-overview) 5. Delivers merge-ready PRs *** ### Choose your path #### Community Edition (Free) Community Edition (CE) is the fastest way to try Gomboc in your workflow, ideal for individual and small teams getting hands-on with scanning and fixes through developer-native integrations. Whether you use VS Code, AI editors like Cursor, or need actionable pull request in GitHub, every step is covered to make sure you’re shipping code that’s ready to go live. ➡️ [Get started with CE](/getting-started-ce). #### Gomboc Platform (Pro) Gomboc Platform (Pro) is for teams that need centralized policy, reporting/analytics, broader integrations, and enterprise workflows, so you can operationalize continuous remediation at scale. [Book a demo](https://meetings.hubspot.com/gomboc-demo/one?uuid=02ec3652-7555-49d9-ab35-b01b2dc09cdb&__hstc=239846108.d9abb7a6c8409d9962c467d347a3b69a.1747674668709.1771607018868.1771619176053.93&__hssc=239846108.3.1771619176053&__hsfp=36b799a02b3d61e1a71fb88f8f5d5cb5). # Get started with Gomboc Community Edition ### Introduction This guide will help you quickly get started with Gomboc Community Edition to fix your code issues directly within your favorite development workflows. **New 🎉:** Community Edition now includes Gomboc’s latest remediation engine powered by [**Open Remediation Language (ORL)**](/orl), which generates deterministic, merge-ready fixes. ## Quick Start *** ### Sign up to create a Community account 1. Go to [Gomboc portal](https://app.gomboc.ai/) click "Sign Up". 2. You can choose to sign up with your Email or with GitHub SSO. 1. With Email, fill out your email, name, and organization. 2. With GitHub SSO, click on the "GitHub" option and follow the oauth process to authorize access by selecting "Authorized Gomboc-AI". ### Choose where you would like to start: Whether you use VS Code, AI editors like Cursor, or need an actionable pull request in GitHub
Get Started in VS Code or Cursor #### 0. Prerequisites Before you start, make sure you have: * **VS Code** version 1.63.0 or greater\ * **Docker** is installed and **running** (Docker Desktop or Docker Engine)\ > **Why Docker?** The VS Code extension runs the ORL remediation engine locally inside a Docker container when you scan. If Docker isn’t running, scans/fixes won’t start. #### 1. Generate a personal token * [Here's](/getting-started/generate-a-personal-access-token) how to create a Gomboc personal access token. #### 2. Set up the Gomboc VSCode plugin * Install the Gomboc Plugin via the marketplace or direct in the IDE: * VS Code Marketplace (click "Install") [gomboc-vscode-extension](https://marketplace.visualstudio.com/items?itemName=GombocAI.gomboc-vscode-extension)
* VSCode Extensions tab. Search for "Gomboc" and click "Install":
* When you install the extension, be sure to enable "Auto Update". * Once installed, open the product settings by doing one of the following: * click the gear icon and select "Settings":
* Open Settings > Extensions and search for "Gomboc."
* Paste your Personal Access Token into the Api Key field. Run `Gomboc: Test Api Key` from the command and enable "Scan on File Save".
#### 3. Run your first scan Choose your path before running your scan * **Option 1 (Recommended):** Checkout the [Gomboc Reviewer guide](/integrations/vscode-plugin/gomboc-reviewer-webview) * **Option 2 (Quick):** Problems panel → Apply Fix * Create a project with a **Terraform** file. * In your IDE, create a new folder called "gomboc-quickstart" and create a new file, `main.tf`
* Populate that file with the following content: ``` provider "aws" { region = "us-east-2" } data "aws_region" "current" {} resource "aws_dynamodb_table" "test_table_a" { } resource "aws_lambda_function" "myfunction" { } resource "aws_appsync_graphql_api" "test_api" { authentication_type = "API_KEY" } resource "aws_keyspaces_table" "mykeyspacestable" { } ``` * Alternatively, check out with the following command ``` git clone git@github.com:Gomboc-AI/rattleback.git ``` * Save the file, triggering Gomboc to scan it * Alternatively, click on the search bar and select "Show and Run Commands":
* Type "Gomboc" into the search and select "Gomboc: Scan current file or scenario":
#### 4. Apply the fixes * Review the **Problems** panel → click **Apply Fix** (or **Apply All**). * Save, test, and commit your changes. {% hint style="info" %} Want a realistic repo and a guided workflow? Continue with [**Gomboc Demo Cases**](/getting-started-ce/gomboc-demo-cases). {% endhint %}
Get Started in Claude Code #### 1. Prerequisites Before you start, make sure you have: * **Claude Code terminal client**\
* **Docker** is installed and **running** (Docker Desktop or Docker Engine)\ > **Why Docker?** The Gomboc plugin runs the ORL remediation engine locally inside a Docker container when you scan. If Docker isn’t running, scans/fixes won’t start. #### 2. Generate a personal token * [Here's](/getting-started/generate-a-personal-access-token) how to create a Gomboc personal access token. * Run `export RULE_SERVICE_TOKEN=` in your terminal to set the environment variable for the plugin to authenticate to Gomboc services. #### 3. Install the Claude Code Plugin You can install the Gomboc Community plugin for Claude Code by following these steps: 1. Start Claude Code 2. Run the `/plugin` command
3. Select "Add Marketplace"
4. Enter the url for [gomboc-community-skills](https://github.com/Gomboc-AI/gomboc-community-skills)
``` https://github.com/Gomboc-AI/gomboc-community-skills ```
5. Select the gomboc-community-marketplace:
6. Select "Browse Plugins"
7. Select the Gomboc Community Plugin
#### 4. Create your first fixes * Run the /gomboc-community:fix slash comment and direct Gomboc to fix your code with Claude:
``` /gomboc-community:fix Make sure my RDS database is protected in production ``` . * Push the ORL rules that the plugin creates to your community account for use anywhere you code. {% hint style="info" %} Want a realistic repo and a guided workflow? Continue with [**Gomboc Demo Cases**](/getting-started-ce/gomboc-demo-cases). {% endhint %}
Get Started in GitHub #### 1. Install the Gomboc GitHub App * [Click here to Install.](https://github.com/apps/gomboc-ai-community) * Select the repos you’d like us to monitor (your own or [Gomboc demo example](https://github.com/Gomboc-AI/rattleback)). #### 2. Scan & Generate Fixes * Edit one of your Terraform files and create a pull request in your selected repo. * Gomboc will: * Automatically scan your Terraform code * Open a new PR with: * A clear summary of what was fixed * Suggested secure code fixes #### 3. Review Fixes & Share Feedback * Head to the PR created by Gomboc, review the description, accept the fixes, and merge. * Leave feedback via our [GitHub discussions channel.](https://github.com/Gomboc-AI/gomboc-ai-feedback/discussions/2)
*** **Need help?** Leave feedback via our [Discussions channel.](https://github.com/Gomboc-AI/gomboc-ai-feedback/discussions/2) # Gomboc Demo Cases Gomboc demo cases are community-ready, repeatable scenarios that show how to go from findings to safe, reviewable, and deterministic fixes quickly, using realistic code. Each demo is repeatable and designed to mirror what teams actually deploy. *** ### What you’ll learn * How Gomboc scans and prioritizes issues in real repos * How policies map to findings and generate actionable fixes * How to apply fixes (IDE and/or other dev workflows) and validate results *** ### Choose a demo case #### 1) Terraform with DolphinScheduler **Make an open-source Terraform deployment production-ready.**\ You’ll scan a real deployment, prioritize high-impact cloud issues (public exposure, IAM, encryption, metadata hardening, backups/monitoring), and apply fixes in a repeatable flow.\ ➡️ Go to: [Demo Case: Terraform with DolphinScheduler](/getting-started-ce/gomboc-demo-cases/demo-case-terraform-with-dolphinscheduler) #### 2) Dockerfile Fixes **Eliminate Docker security maintenance toil with automated, PR-ready fixes.**\ You’ll scan Dockerfiles and apply best-practice remediations, like ensuring OS package upgrades happen during builds, pinning base images, running as a non-root user, improving package hygiene, and preventing common secret-handling mistakes.\ ➡️ Go to: Demo Case: Dockerfile Hardening #### 3) Java with DolphinScheduler - Log4Shell **Gomboc expands beyond IaC with ORL: deliver deterministic remediation across cloud and code.**\ You’ll scan a real Java project in your IDE, identify a vulnerable logging dependency chain, then use the Gomboc Webview Reviewer to preview and apply policy-aligned, repeatable dependency fixes.\ ➡️ Go to: [Demo Case: Java with DolphinScheduler - Log4Shell](/getting-started-ce/gomboc-demo-cases/demo-case-java-with-dolphinscheduler-log4shell) *** ### Feedback Found a gap, false positive, or improvement idea? Leave feedback via our [Discussions channel.](https://github.com/Gomboc-AI/gomboc-ai-feedback/discussions/2) * Include: demo case name, repo link/commit, finding ID, expected vs actual, and screenshots/logs where possible. # Demo Case: Terraform with DolphinScheduler Scan and remediate a real Terraform deployment to make an open-source workload production-ready. Show how Gomboc can take a real, actively maintained open-source Terraform deployment and go from “find problems” to “find and fix” directly in your IDE, then package the changes into a clean PR that your team can review and trust. You’ll use a real-world open-source deployment ([Apache Dolphin Scheduler](https://github.com/apache/dolphinscheduler/blob/dev/deploy/terraform/README.md)) with Terraform to demonstrate production-hardening fixes and guardrails. ### Prerequisites * Gomboc IDE plugin installed and configured. See: [VSCode Plugin page](https://docs.gomboc.ai/getting-started-ce/gomboc-demo-cases/pages/XleNum4pRoxI8RQkj5w7#id-0.-prerequisites). * Terraform installed locally (if you plan to run validate/plan/apply) #### Step 0: Prepare the demo repo 1. Clone the demo repo and open it in VS Code: ```bash git clone https://github.com/iac-playground/dolphinscheduler.git ``` 2. Confirm the repo is in a good state: * Run `terraform fmt -recursive` * Run `terraform validate` (or the repo’s documented validate flow) #### Step 1: Run the first scan (the “wow” moment) 1. Open the Command Palette (`Ctrl/Cmd + Shift + P`) 2. Run: Gomboc: Scan current file or scenario (or scan-on-save, if enabled) 3. Keep the repo open: this is a multi-file Terraform project, so it should produce findings across the codebase. {% hint style="info" %} Traditional tools mostly stop at “here are findings.” Gomboc is built to connect findings to fixes in a consistent, reviewable workflow. {% endhint %}
#### Step 2: Review findings In the IDE results list, pick 3-5 high-signal issues to focus on first. Typical categories for this repo include: * Public exposure defaults (public instances / public DB access) * Metadata hardening (IMDSv1 not disabled / metadata settings missing) * Encryption gaps (S3 / RDS / EBS) * Overly permissive IAM (broad actions like `s3:*`) * Monitoring/backup gaps (log export, backup windows, retention) You can also review this through the [Gomboc Reviewer (Webview)](/integrations/vscode-plugin/gomboc-reviewer-webview), which will provide you a single, centralized place to triage the findings, preview deterministic remediations, and apply changes across multiple files. 1. In the Gomboc results list, select **one or more findings** (multi-select if supported). * Example: select several **database-related** fixes (multi-AZ, public access off, deletion protection). 2. Click **Review in Webview** / **Open Webview Reviewer** (wording may vary). * This opens a Gomboc “web view” inside the IDE that’s optimized for reviewing fixes. #### Step 3: Inspect finding details For each selected finding in the Webview Reviewer, review: 1. **Resource reference** (which Terraform resource/module is affected) 2. **Rule / policy driver** (what guardrail triggered this fix) 3. **Description** of what the fix does 4. (Optional) **External mapping** fields if present * Example: IDs or references that align with other scanners (like Checkov)
#### Step 4: Preview fixes 1. In the Webview Reviewer, click **Preview** (or **Preview fixes**). 2. Gomboc will: * apply the changes in the correct order * ensure changes are consistent across dependencies * generate a preview of code diffs you can review before applying 3. Wait for preview generation to complete. **What you should see:** * A preview list showing **exact code changes** per resource/finding. * A concrete diffs, not just recommendations. * A summary of which rules triggered which updates (e.g., enabling metadata service hardening, enabling monitoring, termination protection).
#### Step 5: Review diffs in detail For a selected previewed fix: 1. Click **Open diff** to see the exact Terraform patch. 2. Use **View full resource in context** to understand how the change fits into the resource/module. 3. Confirm the fix is: * logically correct for production hardening * consistent with your organization’s expectations * not introducing unexpected side effects
#### Step 6: Apply fixes from the Webview Reviewer 1. After reviewing preview diffs, click **Apply** (or **Apply fixes**). 2. Gomboc will apply the selected patches to your working tree. #### Step 7: Validate changes locally (recommended) In a terminal at the repo root (or Terraform root): 1. Format: * `terraform fmt -recursive` 2. Validate: * `terraform validate`\ (or run the repo’s documented validation steps if it requires variables/modules) **Checkpoint:** Terraform validation passes (or you can clearly explain any missing inputs required by the repo). #### Step 8: Re-scan to confirm findings are resolved 1. Run the scan again from the IDE: * **Scan** → **Scan current file or scenario** 2. Confirm the previously selected findings are now: * resolved / removed * reduced in severity/count # Demo Case: Java with DolphinScheduler - Log4Shell Scan and remediate a real Java project to migrate away from a vulnerable logging dependency. Show how Gomboc can take a real, actively maintained open-source Java project and go from "find problems" to "find and fix" directly in your IDE, then package the changes into a clean PR that your tea You'll use a real-world open-source project ([Apache DolphinScheduler](https://github.com/apache/dolphinscheduler)) with Maven to demonstrate a Log4j 1.x vulnerability remediation, replacing the `slf4j-log4j12` binding (which pulls in the end-of-life `log4j:log4j` 1.x library) with the patched `slf4j-reload4j` drop-in replacement. #### Prerequisites * Gomboc IDE plugin installed and configured. See: [VSCode Plugin page](https://docs.gomboc.ai/getting-started-ce/gomboc-demo-cases/pages/XleNum4pRoxI8RQkj5w7#id-0.-prerequisites). * Java / Maven installed locally (if you plan to run build validation) #### Step 0: Prepare the demo repo 1. Clone the demo repo and open it in VS Code: ```bash git clone https://github.com/iac-playground/dolphinscheduler.git ``` 2. Confirm the repo contains the vulnerable dependency. Open `pom.xml` and look for: ```xml 1.7.5 ``` and the corresponding dependency: ```xml org.slf4j slf4j-log4j12 ${slf4j.log4j12.version} ``` This dependency transitively pulls in `log4j:log4j` 1.x, which is end-of-life and has critical CVEs (CVE-2019-17571, CVE-2021-4104, CVE-2022-23302/23305/23307). #### Step 1: Run the first scan 1. Open the Command Palette (`Ctrl/Cmd + Shift + P`) 2. Run: Gomboc: Scan current file or scenario (or scan-on-save, if enabled) 3. Keep the repo open: Gomboc will scan all XML files in the project and identify the vulnerable `slf4j-log4j12` dependency. {% hint style="info" %} Traditional tools mostly stop at "here are findings." Gomboc is built to connect findings to fixes in a consistent, reviewable workflow. {% endhint %}
#### Step 2: Review findings In the IDE results list, you should see a finding for the `slf4j-log4j12` dependency. The finding will indicate: * **What:** `org.slf4j:slf4j-log4j12` dependency detected in `pom.xml` * **Why:** Transitively pulls in log4j 1.x (EOL) with critical vulnerabilities * **Fix:** Replace with `org.slf4j:slf4j-reload4j:1.7.36`, a maintained, binary-compatible drop-in replacement You can also review this through the Gomboc Reviewer (Webview), which will provide you a single, centralized place to triage the findings, preview deterministic remediations, and apply changes across multiple files. 1. In the Gomboc results list, select the **slf4j-log4j12** finding. 2. Click **Review in Webview** * This opens a Gomboc "web view" inside the IDE that's optimized for reviewing fixes. #### Step 3: Inspect finding details For the selected finding in the Webview Reviewer, review: 1. **Resource reference** (which `pom.xml` and dependency block is affected) 2. **Rule / policy driver** (the Log4j 1.x migration rule that triggered this fix) 3. **Description** of what the fix does, replaces `slf4j-log4j12` with `slf4j-reload4j` 4. (Optional) **External mapping** fields if present
#### Step 4: Preview fixes 1. In the Webview Reviewer, click **Preview** (or **Preview fixes**). 2. Gomboc will: * apply the changes in the correct order * ensure changes are consistent across dependencies * generate a preview of code diffs you can review before applying 3. Wait for preview generation to complete. **What you should see:** * A preview showing two **exact code changes** in the `` block: * `slf4j-log4j12` → `slf4j-reload4j` * `${slf4j.log4j12.version}` → `1.7.36` * A concrete diff, not just a recommendation.
#### Step 5: Review diffs in detail For the previewed fix: 1. Click **Open diff** to see the exact Maven dependency patch. 2. Use **View full resource in context** to understand how the change fits into the `pom.xml`. 3. Confirm the fix is: * logically correct, `slf4j-reload4j` is a binary-compatible replacement * consistent with your organization's expectations * not introducing unexpected side effects (the orphaned `` property is harmless dead config)
#### Step 6: Apply fixes from the Webview Reviewer 1. After reviewing preview diffs, click **Apply** (or **Apply fixes**). 2. Gomboc will apply the patch to your working tree. #### Step 7: Validate changes locally (recommended) In a terminal at the repo root: 1. Verify the dependency change: * Open `pom.xml` and confirm `slf4j-log4j12` has been replaced with `slf4j-reload4j` at version `1.7.36` 2. (Optional) Build: * `mvn compile` or `mvn validate`\ (the DolphinScheduler build may require additional setup, the dependency change itself is safe regardless) **Checkpoint:** The `pom.xml` now references `slf4j-reload4j:1.7.36` instead of `slf4j-log4j12`. #### Step 8: Re-scan to confirm findings are resolved 1. Run the scan again from the IDE: * **Scan** → **Scan current file or scenario** 2. Confirm the `slf4j-log4j12` finding is now: * resolved / removed * the scan returns zero findings for this rule # Gomboc Portal This guide will help you understand what to expect from the Gomboc Portal and how to get started on your Gomboc journey. {% hint style="info" %} If you already have a Gomboc account, see [Log in to an existing account.](https://auth.app.gomboc.ai/oauth/account/login) {% endhint %} ## Why Gomboc Gomboc AI allows engineering teams to focus on innovation without worrying about configuration drift, cloud infrastructure misconfigurations, or other code issues. This document provides an overview of the platform's key capabilities and how to leverage them effectively. {% hint style="info" %} [Schedule a demo ](https://www.gomboc.ai/book-a-demo)to see Gomboc in action and learn how you can benefit it. {% endhint %} ## Key Benefits
Automated Remediation Gomboc continuously scans your repositories for code misconfigurations and policy violations. When issues are detected, Gomboc automatically generates precise, context-aware fixes as pull requests, eliminating the manual effort of writing remediation code. **How it works:** 1. Connect your code repositories to Gomboc 2. Define your policies 3. Gomboc scans your code and identifies violations 4. Remediation PRs are automatically created with detailed explanations 5. Your team reviews and merges the fixes
Consistent, Reliable Fixes All generated fixes adhere to your organization's policies and code best practices. Because fixes are delivered as pull requests, they integrate seamlessly into your existing code review workflow, ensuring every change is vetted before deployment.
Streamlined Approval Process Each remediation PR includes: * Clear context explaining the code issue * Detailed reasoning for why the fix is necessary * Precise code changes that address the specific violation This allows engineers to quickly understand, approve, or request modifications to suggested fixes without additional research.
Continuous Updates Gomboc doesn't just scan once, it continuously monitors your repositories for: * New code changes that introduce violations * Configuration drift between your IaC and deployed infrastructure * Policy updates that affect existing resources All findings are surfaced promptly with actionable remediation options.
## Policies
Policy Sets Policy Sets are collections of Gomboc policies that define the rules and standards your infrastructure must follow. Gomboc provides flexible policy management: * Organization-wide policies: Apply security standards across all workspace * Workspace-specific policies: Target policies to specific environments, teams, or stages (e.g., production vs. development) * Custom policy combinations: Mix and match policies to create the right enforcement level for each context
One-Click Framework Policies Quickly adopt industry-standard frameworks with pre-built policy templates: * AWS Well-Architected * SOC 2 Type II * NIST CSF 2.0 * CIS Benchmarks * PCI DSS * HIPAA Select a framework, and Gomboc automatically configures the corresponding policy rules, no manual policy authoring required.
Policy Rules Each policy contains granular rules that target specific resource types and configurations. Rules include:
AttributeDescription
Rule NameHuman-readable description of what the rule enforces
Resource TypeThe IaC resource the rule applies to (e.g., aws_db_instance)
Cloud ProviderTarget cloud platform (AWS, Azure, GCP)
IaC ToolSupported infrastructure tools (Terraform, CloudFormation, etc.)
SourceRule origin and identifier (e.g., checkov CKV_AWS_129)
Rules can be individually enabled or disabled within a policy to customize enforcement for your organization's specific requirements.
Version Management & Audit Trail [Coming soon...] Every change to your policy sets is tracked with full audit traceability: * Who made the change * What was modified (policies added/removed, rules enabled/disabled) * When the change occurred This provides complete visibility for compliance audits and security reviews.
## Workspaces
Workspaces Workspaces represent your connected infrastructure projects. Each workspace includes: * Repository connection: Linked code repository and branch * Policy assignment: Which policy sets apply to this workspace * Scan history: Record of all scans, findings, and remediations * Drift status: Current drift detection state Workspaces allow you to organize and manage security enforcement across multiple projects, environments, and teams.
## AI-Powered Intelligence
Daily Model Updates Gomboc's AI model is updated daily with the latest: * Cloud Service Provider (CSP) documentation * Code best practices and guidelines * New resource types and configurations * Emerging threat patterns This ensures remediation recommendations always reflect current cloud provider capabilities and security standards.
Context-Aware Fixes Gomboc doesn't generate generic fixes: it analyzes your specific codebase to produce remediation that: * Follows your existing coding patterns and conventions * Accounts for resource dependencies and relationships * Minimizes blast radius while fully addressing the violation
### Integration & Compatibility
Repository Integration Connect your code repositories from: * GitHub * GitLab * Bitbucket * Azure DevOps Gomboc Projects stay continuously synced with your repositories, monitoring all branches and changes in real-time.
CI/CD Pipeline Integration Gomboc can push Infrastructure as Code (IaC) directly to your Continuous Integration/Continuous Deployment (CI/CD) pipelines, such as GitHub Actions. This ensures that security checks and remediations are part of your automated deployment process. Gomboc integrates directly into your deployment pipelines: * GitHub Actions: Native workflow integration * GitLab CI: Pipeline job support * Jenkins: Plugin available * Custom pipelines: API and CLI access Code checks and remediation become part of your automated deployment process, catching issues before they reach production.
# Access & Log in {% hint style="info" %} If you already have a Gomboc account, you can [log in here.](https://auth.app.gomboc.ai/oauth/account/login) {% endhint %} ## Getting Access To try out Gomboc, sign up for a [free fix](https://www.gomboc.ai/terraform-remediation#wf-form-Contact-Form), and we will set up a Gomboc tenant for you to evaluate. Get started today and see how Gomboc can improve your cloud security. ## Signing In #### Navigate to the Gomboc Portal Open your browser and g to the [Gomboc Portal](https://app.gomboc.ai) and enter your Gomboc Credentials.
#### Magic Code You will see a message indicating that a six digit code has been sent to your email.
#### Check your email Open the email with the verification code from , copy the code and insert it in the login screen #### Access the Portal After clicking "Continue", you will be logged in and redirected to the Gomboc portal. That's it! You are now signed in and can start using Gomboc. # Initial Set up & Remediation To utilize all the features of Gomboc, you must grant Gomboc access to your environment, allowing it to scan your organization. The type of integration required depends on the systems you use and what you need to scan. For more information, see Integrate with Gomboc for details about available integrators. ## Onboarding Process Now that you have met all the prerequisites, we can begin the onboarding process. Gomboc offers an automated onboarding process which will: * Discover and link your infrastructure-as-code (IAC) repositories. * Perform an initial assessment of your IAC code and report any fixes that may be needed. {% hint style="warning" %} You must have a Gomboc **Admin** role to begin onboarding. {% endhint %} ## Step 1: Welcome to the Onboarding Wizard After this first login, you will be guided through a short onboarding wizard to make sure you have the minimal parameters needed. Click **Start** to get started.
## Step 2: Source Code Management Integration Choose your source code management provider from the list and follow the prompts to integrate it with Gomboc. Ensure you have the necessary permissions to complete this step.
## Step 3: All Set You have now successfully completed the onboarding process and are now ready to use Gomboc to scan, and apply fixes. {% @storylane/embed subdomain="app" url="" linkValue="q0iykn8rdogx" %} While you wait for initial scans to complete feel free to explore the Dashboard to get yourself familiarized with some of our other features. # Generate A Personal Access Token Steps to Generate a Gomboc Personal Access Token:
1. In the Portal, select the account drop-down from the upper right and click "Settings".
2. Select "Personal Access Tokens" in the account menu.
3. Click Generate Token, name it (e.g., vscode), choose an expiration timeframe, and click "Create".
4. Copy the token to a secure location for safe keeping to finish IDE plugin setup, then click "Done".
# Gomboc Playbook Gomboc.AI acts as an active participant in your development lifecycle. This guide outlines how engineers can use the platform's features for their daily triage, weekly reporting and implementing fixes ### 1. The Daily Triage: Dashboard & High-Level Metrics *As an Engineer starting my day, I need a quick overview of our infrastructure health to see if any critical vulnerabilities were recently introduced, and to track our overall remediation progress.* The [Dashboard](https://app.gomboc.ai/) is your command center. It provides immediate visibility into your security posture through high-level stats and visualizations: * **Fixes**: The count of unique fixes found over the lifetime of your account. A growing number indicates a growing backlog. * **Time Saved**: An estimated ROI metric calculating the engineering hours saved by Gomboc’s automated code remediation. * **Repositories**: The total number of code repositories scanned during the latest indexing update. #### Key Charts to Monitor: * **Fixes by Top Severity**: Don't look at everything at once. Use this chart to identify if there are any new "Critical" issues: these are your priority targets for the day. * **Fixes by Top Targets**: This chart tells you *where* the bleeding is. It identifies the specific resources, code syntax trees, or policies that are generating the most hits. * **Number of Fixes**: A visual timeline showing the volume of fixes delivered over time, perfect for tracking weekly progress.
*** ### 2. The Weekly Review: Managing Reports *As a Lead preparing for a weekly sync, I need to filter out the noise, identify the most pressing issues from the last sprint, and export a report for the Engineering /* *Leadership team* The [Reports](https://app.gomboc.ai/reports) view is where you drill down into specific findings; to avoid alert fatigue, you must aggressively filter this list. #### Strategic Filtering Navigate to the Reports tab on the left-hand menu and open the advanced filtering sidebar: * **Time Range**: Set this to the "Last 7 days" to focus exclusively on recent drifts and new code changes. * *This is crucial for weekly syncs so you only look at recent drifts and new code changes, rather than historical tech debt.* * **Severity vs. Risk**: * Severity refers to the vulnerability threat level (High, Critical). * Risk Level refers to *operational* risk—such as the potential for data loss, downtime, or complex change control required to apply the fix. * *Note: You can also specify several other filters, such as Origin (e.g. Gomboc default scheduled runs, the* [*IDE Plugin*](https://docs.gomboc.ai/integrations/vscode-plugin)*, specific* [*Policies*](https://docs.gomboc.ai/policy-management) *and more)* * **Exporting Data**: Use the CSV export function to share prioritized findings with stakeholders who do not use the Gomboc platform.
*** ### 3. Continuous Remediation: Reviewing and Delivering Fixes *As an Engineer, I need to review a security finding, validate the proposed Infrastructure-as-Code (IaC) fix, and merge it safely into our repository.* This is where Gomboc moves from "alerting" to "**fixing**." When you find a priority issue in your Reports list, follow this Remediation workflow: 1. **Open the Finding**: Click on a specific fix in the report from your filtered list. 2. **Analyze the Code Diff**: Gomboc will display a remediation report, including all details from the specific finding as well as the code diff to address it (verify that the logic aligns with your architecture) 1. ```
``` 3. **Deliver the Fix**: If the code looks good, click on the workspace name for that fix (at the top, next to the "Remediation report for:"); it will bring you to the workspace where you'll see all the most recent runs and the "Deliver Fixes" button. Gomboc will automatically create a Pull Request (PR) directly in your SCM tool (GitHub, GitLab, etc.). 1. ```
``` 4. **Merge in SCM**: Your team reviews and merges the PR in GitHub/GitLab as usual. Once merged, Gomboc detects the change and marks the issue as resolved. **How to Handle Exceptions**: If an issue is already mitigated by an external tool (like a WAF), you shouldn't apply a code fix. 1. Click Create Exception on the finding (expanding the bottom section "Applied rules"). 2. Select the relevant Policy Set. 3. Provide a clear Reasoning Note for compliance tracking. 1. ```
``` > ⚠️ Pro-Tip : Use caution here. Applying an exception might suppress all instances of that detection globally across that policy set, not just for this specific line of code. *** ### 4. Platform Administration: Workspaces & Governance *As an Engineer, I need to onboard a new microservice repository and ensure it strictly adheres to our production compliance standards (e.g., OWASP Top 10).* #### Managing Workspaces [Workspaces](https://docs.gomboc.ai/workspaces) are the primary scan units in Gomboc, defined by a combination of: Repository + Branch + Path + Language. * **Automatic Detection**: Gomboc's remediation language engine automatically detects the languages and relevant files within a repository (via `pom.xml`, `.tf` files, etc.) to map out workspaces. * **Tags**: You can add custom tags to workspaces for internal grouping, or configure Gomboc to automatically reflect existing tags inherited from GitHub/GitLab.
#### Policies and Policy Sets Gomboc allows for granular, segmented control over code governance through [Policy Mgmt](https://docs.gomboc.ai/policy-management): * [**Policy Library**](https://app.gomboc.ai/policies): Contains the hierarchy of rules anchored to specific security frameworks. * **Custom Classifications**: You can create your own custom policy hierarchies to align with internal company compliance initiatives, while still mapping them to external standards like OWASP. * [**Policy Sets**](https://app.gomboc.ai/policy-sets): Group policies together and apply them to specific workspaces. For example, you can enforce a "Strict Default" set for Production workspaces, and a more lenient "Development" set for lower environments. *** ### 5. Troubleshooting & Operational Status Checks If your automated PRs fail to generate or scans seem delayed, follow this troubleshooting checklist: * [**Run History**](https://app.gomboc.ai/runs): View the execution details of every scan. You can check the status (In Progress, Success, Failed), duration, and access the raw scan logs for deep-dive troubleshooting. * [**Status Page**](https://status.gomboc.ai/): Check `status.gomboc.ai` to verify the operational health of Gomboc's infrastructure and the API connections to your SCM platforms. * **Check Token Permissions** *(reachable through your Profile icon on the top right > Settings)*: * **API Tokens**: Created by admins and accessible at the account level for system-to-system integrations. * **Personal Tokens**: Individual user tokens that carry the same permissions as API tokens but are restricted in scope to the specific user's actions. # Integrations We offer a variety of integrations to expand your use of Gomboc. These integrations allow you to leverage third-party functionality within Gomboc and seamlessly use Gomboc with other tools.
Cover image
Source Code Management/files/cp1aWbtFDCHLVZ0HWOLi/pages/GGM3EkCCtxmYiRSWUccl
Cloud Security Posture Management/files/FsBEzGeZHlqQkSKMStZO
VSCode Plugin/files/TXTYnHurl1bU5FUXfAtt/pages/XleNum4pRoxI8RQkj5w7
Gomboc MCP Server/files/glw15aLDIAY6evzlmxXG/pages/mGwFo94PfiuB9STGXwIa
CI Build Systems/files/9bmkRIKgFB7kfoy9ZMP5/pages/BEsUYhbRZNiLe3GaXLFw
{% hint style="info" %} If you have questions or a request for a service to be supported, please email us at [*support@gomboc.ai*](mailto:support@gomboc.ai)*.* {% endhint %} # Network Configuration {% hint style="danger" %} **WARNING** This list may change at any time, please monitor it for changes. {% endhint %} Performing integrations with Gomboc will require proper network and security configuration to allow API requests from Gomboc to send and receive properly. ## Allow Listing Configuration The following are domains and IPs that you may need to configure to allow traffic through your firewalls if you do Domain or IP based security. ### Domains * app.gomboc.ai * api.app.gomboc.ai * egress.app.gomboc.ai * cspm.app.gomboc.ai * integrations.app.gomboc.ai * rules.app.gomboc.ai * scan.app.gomboc.ai ### IPs Ingress: * `34.49.16.191` * `34.49.39.234` * `34.54.63.132` * `34.54.121.227` * `34.54.140.121` * `34.117.124.50` Egress: * `34.145.145.163` ## Security Controls For SCM integrations, the API endpoints often require use of UUIDs in the requests. This traffic can be detected by a security control such as a Web Application Firewall (WAF) or data loss prevention (DLP) solutions like Atlassian Guard as bot activity due to the high entropy of the requests. To ensure a successful integration with Gomboc, it is helpful to consult with your network or security controls administrator to ensure that there are not controls in place that would hinder product operation. # Gomboc MCP Server The hosted Gomboc [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) server gives AI coding agents access to Gomboc rules, classifications, and channels. The [Gomboc Community Skills](/orl/agent-skills/gomboc-community-skills) and [Gomboc Enterprise Skills](/orl/agent-skills/gomboc-enterprise-skills) use MCP when it is available and fall back to the ORL runtime or local references when it is not. The hosted endpoint is: ``` https://mcp.app.gomboc.ai/mcp ``` ## Capabilities The available tools are discovered by your MCP client and may change over time. Current capabilities include: * Looking up channels and listing the rules in a channel * Searching for and retrieving rules * Looking up and searching policy classifications * Searching channels * Reporting an external ORL run Code remediation, AST walking, rule tests, and publishing rules continue to use the ORL runtime rather than MCP. ## Prerequisites Before configuring the server: 1. Install an MCP-compatible AI coding agent, such as Cursor. 2. [Generate a Gomboc Personal Access Token](/getting-started/generate-a-personal-access-token). 3. Make the token available to the process that launches your agent: ```bash export GOMBOC_PAT="" ``` {% hint style="warning" %} Treat your personal access token as a secret. Do not add it directly to an MCP configuration file, commit it to source control, or print it in logs. {% endhint %} ## Configure Cursor Add the following server definition to your global `~/.cursor/mcp.json` file or your project's MCP configuration: ```json { "mcpServers": { "gomboc": { "url": "https://mcp.app.gomboc.ai/mcp", "headers": { "Authorization": "Bearer ${env:GOMBOC_PAT}" } } } } ``` Restart Cursor after setting the environment variable or changing the configuration. If you install the Gomboc Enterprise Skills plugin, Cursor may offer to add this server definition automatically. ## Verify the connection Use the verification command provided by your Gomboc skills package: | Package | Command | | ------------------------ | ------------------------------ | | Gomboc Community Skills | `/gomboc-community:verify-mcp` | | Gomboc Enterprise Skills | `/gomboc:verify-mcp` | Verification succeeds when the `gomboc` server is ready, its tools can be listed, and a read-only `get_channels` request for the `default` channel completes successfully. You can also verify the connection in your agent's MCP settings. The `gomboc` server should appear as connected with its tools available. ## Troubleshooting If verification fails: * Confirm that `GOMBOC_PAT` is set in the environment that launches your agent. * Confirm that the server URL is exactly `https://mcp.app.gomboc.ai/mcp`. * Check that the authorization header uses `Bearer ${env:GOMBOC_PAT}`. * Confirm that the personal access token is active. * Restart the agent after changing the environment or MCP configuration. An unavailable MCP connection does not block Gomboc skills. They fall back to the Rules Service, Docker-based ORL runtime, or local references as appropriate. # Cloud Security Posture Management (CSPM) # Orca Security ### Integration Setup To configure the Orca Security integration, follow these steps: 1. Within the Gomboc portal, create an access token, either a personal or organization API token will work. Once the token is created, copy it to your clipboard.
2. Go to `Settings > Integrations > Orca`
2. Insert the Gomboc token you just copied and paste it within the 'Gomboc Token' field
3. On a separate tab go to your Orca Security account and create an API token.`Account settings > Users & Permissions > API > Add api token`\ The token should never expire and should have access to the cloud account you would like to remediate.
4. Once the secret is created, copy it and paste it within the 'Orca Token' field on Gomboc.AI. Make sure to select the correct region of your Orca account.
5.Once the integration is complete you will receive an Access token you will need to use to create the webhook on Orca Security.
6. Within you Orca Security account go to`Settings > Connections > Integrations > Webhook`\ When creating the webhook, be sure to include the access token you received from the Gomboc integration and include it within the 'API key' field. The trigger URL should also be set to .
7. Once the webhook is created, you can create an automation with the webhook. Go to the Orca Security automations tab and create a new automation.
8. Create the automation to trigger on Alerts with the open state, and have the Webhook URL to be the one you just created in step 7. You can also send existing alerts through the webhook by checking the 'Apply to Existing Alerts' option.
# Wiz ### Integration Setup To configure the Wiz Security integration, follow these steps: #### Create Wiz Service Account 1. In the the Wiz Application, Search "Service Accounts"
1. Click "Add Service Account"
1. Enter a name, Choose "Custom Integration (GraphQL API)" from the Type drop down.
1. Select Projects you want Gomboc to have access to.
1. Select the following scopes: * Read graph resource * Issues * Issue Comments * Integratons * Automation Rules * Read report * Read cloud configuration rules, list cloud configuration rules * Detections * Issue Status * Comments 2. Click "Add Service Account" and collect Client ID and Client Secret. You will need them in future steps.
#### Create Integration in Gomboc Portal 1. In Wiz click your profile icon and "Tenant Info"
2. Collect API Endpoint URL and Authentication URL for future steps
3. Within the Gomboc portal, create an access token, either a personal or organization API token will work. Once the token is created, copy it to your clipboard.
4. Go to Settings > Integrations > Wiz
5. Insert the Gomboc Token from step 3. Wiz Client ID, Wiz Client Secret from Service Account setup. Wiz API URL, Wiz Auth URL from step 2. Click "Integrate"
6. Once the integration is complete you will receive an Access token you will need to use to create the webhook on Wiz
#### Create Integration in Wiz Application 1. Back on the Wiz Application, search "Integrations"
2. Click "Add Integration"
3. Search "Webhook"
4. Enter a name. Under URL enter "" 5. Select All projects you want to integrate with, It should be the same as the Service Account 6. Under Authentication select Token, Enter the Token received after creating the integraion in Gomboc portal, click "Add Integration"
#### Setup Wiz Webhook Rules 1. Search "Automation Rules"
2. Click "Add Rule"
3. Enter name "Issue Webhook" 4. Select same projects from Service Account setup 5. Under "When" select Issue 6. Under "IF" click Add Filter, select "Severity", then select all the options.
7. Under "THEN" click add Action and select "POST a Webhook" for the created Integration. Click "Continue", then "Add Action"
8. Click "Add Rule"
9. Repeat Steps 2 - 8 changing to "Cloud Configuration Finding" and "Detection" under "WHEN" in step 5
# Source Code Management (SCM) Source Code Management (SCM) is a critical component for managing and tracking changes in your code repositories. SCM tools help teams collaborate on code, maintain version control, and automate workflows. At Gomboc, we currently support the following SCM providers:
GitHub/files/EsYvu9xdwXktEeHiejDc/pages/Wik67BrHL45dosmbxDXs
GitLab/files/L7gsyA6R9sw146B8KMz8/pages/XUi5Qf4Yuq1ZimQDUTOW
BitBucket/files/bdywnBAjDZ5wXY27BySj/pages/Uno2D5jLiDZk3VfNfcqG
Azure Devops/files/yapifhrw8cei47WfRcnt/pages/6bSidLmhYkFWTKkldUhi
## Access Requirements To integrate your SCM provider with Gomboc, you need to grant us access to your repositories. The way you provide access varies by provider:
SCM ProviderAccess Method
GitHubInstall the Gomboc GitHub App.
GitLabProvide a Group Access Token.
BitBucketProvide a Workspace Access Token.
Azure DevOpsProvide an OAuth token.
## Access Scopes We require specific permissions to read and write to your repositories and pull requests. This ensures we can perform necessary operations such as scanning your code and applying remediations. ## Integration Details Each SCM provider has unique terms and structures. Here’s a quick guide to understand the terminology and integration process: ## [**GitHub**](https://github.com/) * Repository: A GitHub Repository. * Repo Owner: A GitHub Organization. * Integration: Installation of the Gomboc GitHub App at the organization level. ## [GitLab](https://about.gitlab.com/free-trial/devsecops/?utm_medium=cpc\&utm_source=google\&utm_campaign=eg_amer_dmp_x_x_en_brand_amer_pr_rsa_br_exact_free-trial\&utm_content=free-trial&_bt=644880459240&_bk=gitlab&_bm=e&_bn=g&_bg=47379220496\&gad_source=1\&gclid=CjwKCAjwtNi0BhA1EiwAWZaANOkJttmZQj15PEUSczOhQwzUbIkV7h2PC7ugYlhQvtF47t2IVstY-hoCFVIQAvD_BwE) * Repository: A GitLab Project. * Repo Owner: A GitLab Group. * Integration: Group Access Token for accessing repositories within the group. ## [BitBucket](https://bitbucket.org/product/) * Repository: A BitBucket Repository. * Repo Owner: A BitBucket Workspace. * Integration: Workspace Access Token for accessing repositories within the workspace. ## [Azure DevOps](https://azure.microsoft.com/en-us/products/devops) * Repository: An Azure Repo. * Repo Owner: An Azure Project within an Azure Organization. * Integration: OAuth token scoped to the organization or project level. # Azure Devops ## Integration Setup To configure the Azure integration, follow these steps (either during the onboarding wizard, or once you have access to the Gomboc platform): 1. In Azure, create a [Personal Access Token](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate) that has a **Code (Read & Write)** permissions and the name of the organization is was scoped to. 1. *Note that we do not currently support the option "All accessible organizations". If you need to provide access to multiple organizations, please create a separate integration for each one.* 2. Go to Settings > Integrations > Azure
2. Insert the token and org name you have created in step 1
3\. Click "Integrate" to complete the initial SCM integration ## Webhooks In order for Gomboc.AI to keep the updated status of any PR's we create for you, you must include a webhook. In order to create a proper webhook, please follow these steps: 1. Go to our portal ([app.gomboc.ai](https://app.gomboc.ai)), click on your account icon on the top right > Settings
2. Create a 'Personal' or 'API' token. 1. Use a **Personal token** when you will be the only one using the token, 2. Use an **API token** with the appropriate roles if the token will be used within the webhook, or expect multiple people to use the token.
3. Be sure to copy the created token, and start to set up the Azure Devops webhook. Within your project settings, create a 'Web Hooks' service.
4. The trigger should be specified 'Pull Request Updated'. No additional filters will be required.
5. Within the 'Actions' settings, you will need the following values 1. URL: 2. HTTP headers: X-Gomboc-Authorization: \
6. Once completed, you can press finish and proceed to creating the pipeline or start to create pull requests through the portal. ## CI/CD See [Azure Devops Pipelines](/integrations/continuous-integration-ci-build-systems/azure-devops-pipelines). # BitBucket ### Integration Setup To configure the BitBucket integration, follow these steps (either during the onboarding wizard, or once you have access to the Gomboc platform): 1. Go to Settings > Integrations > BitBucket
2. Click on your profile drop down in the top right corner and access your Gomboc settings and create a personal or workspace token.
3. Once the Gomboc token is created copy the generated token. 4. Click on the BitBucket integration button to open the form for creating the integration 5. Paste in the generated Gomboc token under the input **Gomboc Access Token** 6. In BitBucket, go to your workspace settings to create an access token [Workspace Access Token](https://support.atlassian.com/bitbucket-cloud/docs/create-a-workspace-access-token/) that has **Repositories (Read & Write)**, **Pull requests (Read & Write)**, and **Webhooks (Read & Write)** permissions. Once generated, copy the workspace access token. Also keep in mind the workspace ID, which can be found within your workspace settings as well. 7. You can now complete the integration form by inputting your Workspace ID and copied workspace access token from BitBucket
3\. Click "Integrate" to complete the initial SCM integration. Review the status notification to ensure that all steps of the integration completed successfully. If the webhook setup failed to automatically complete, follow the steps below to create the webhook. #### Integration without Webhook Setup Please note that we do create a workspace webhook to complete the integration and keep track of PR's that we have opened. In the event that setup cannot execute properly due to errors creating the webhook, follow these steps. 1. Follow Step 1 above to navigate to the Integration setup page for Bitbucket 2. Follow Step 4 to open the integration settings 3. Follow Step 6 to create the BitBucket Workspace Access Token 4. Follow Step 7 to complete the integration form, but only specify the Workspace ID and the BitBucket access token. Leave the Gomboc Access Token blank After you complete the integration, you should see a message that the integration was created successfully, but that the webhook for receiving change request status is not created or active. ### Troubleshooting #### BitBucket Access Token Issues If you see the following message, then the access token that you created does not have all of the required scopes. Go back to the BitBucket admin page and create a new token being sure to give **Repositories (Read & Write)**, **Pull requests (Read & Write)**, and **Webhooks (Read & Write)** permissions.
#### Integration Creation Failures If the integration fails to create properly, it's possible there are some issues where there are repositories in the workspace which cannot be managed by the admin. This will present as a failure to create the webhook during integration setup. In the logs for the error, Gomboc will be able to find "You cannot administer personal accounts of other users." The workaround for this issue is to create the integration following [these instructions](#integration-without-webhook-setup). *** ## CI/CD See [BitBucket Pipelines](/integrations/continuous-integration-ci-build-systems/bitbucket-pipelines). # GitHub ## Connect to GitHub Connecting Gomboc to GitHub enables automated code scanning and surfaces actionable insights with suggested fixes. ### Deployment Scope and Method * Gomboc is deployed to GitHub via a GitHub app which is installed for a GitHub organization. * The app must be installed for each GitHub organization that is part of your enterprise deployment. * This means that if you have multiple organizations in GitHub that you must have permissions to administer that organization and install the app for it. ### Preparation The first step is to identify the GitHub organization for which you want to install the Gomboc application. This organization can be one connected to a personal or enterprise GitHub account.\`\`\` To begin the connection process, you require the following: 1. Access to the Gomboc portal at app.gomboc.ai as an admin, which is necessary to set up integrations. 2. Access to a GitHub.com account 1. Log into your GitHub account with admin / owner permissions for the organization you want to connect. 2. One or more GitHub organizations as an admin / owner. 3. If your GitHub configuration makes use of IP allow lists, then review [Network Configuration](/integrations/domains-ips) to ensure that all necessary IP addresses for Gomboc are added. ### Connection Steps Follow the guide below to install the GitHub app. Click on the demo to advance to the next step. The steps to execute are: 1. Select to install a connection to GitHub. 2. Click the "Install App" button. 3. Select the organization for which you would like to install the app. 4. Select if you would like to give access to "All repositories" or "Only select repositories". 5. Install and authorize the app for your organization. 6. Authenticate with your GitHub account to complete the installation. 7. Review the installation name in the Integrations list in Gomboc Settings. {% @storylane/embed subdomain="app" url="" linkValue="ahegpslgitwx" %} > **Still stuck?**\ > If you run into any issues, please contact us at . We're happy to help! ## CI/CD See [GitHub Actions](/integrations/continuous-integration-ci-build-systems/github-actions). # GitLab ## Webhooks In order for Gomboc.AI to keep the updated status of any MRs we create for you, you must include a webhook. In order to create a proper webhook, please follow these steps: 1. Go to our portal, [app.gomboc.ai](https://app.gomboc.ai), click on your account icon on the top right > Settings > API Tokens and create a 'Personal' or 'API' token. Use a Personal token when you will be the only one using the token, and use an API token with the appropriate roles if the token will be used within the webhook, or expect multiple people to use the token.
2. Be sure to copy the created token, and start to set up the GitLab webhook. Within your project settings, under webhooks, click 'Add new webhook'. You will need the following values to successful finish the webhook. 1. URL: 2. Secret token: \ 3. Trigger checkboxes: Only 'Merge request events' needs to be checked 4. SSL verification: The 'Enable SSL verification' box should be check box should be checked
3. Once complete, you can finish by clicked 'Add webhook' and proceed to creating the CI/CD, or start to create pull requests through the portal. ## CI/CD See [GitLab Runners](/integrations/continuous-integration-ci-build-systems/gitlab-runners). ### Rate Limiting If there are many IAC resources in your projects, Gomboc's scanning processes may encounter rate-limiting imposed either by your custom settings, or the default rate limits for endpoints set by Gitlab on account creation. These may be changed per user in Gitlab's settings. For fastest processing you may raise or remove the rate limits for the Gomboc user for the following endpoints. The process is simple, and is detailed in the documentation below. Relevant endpoints: #### [Projects](https://docs.gitlab.com/ee/administration/settings/rate_limit_on_projects_api.html) #### [Groups](https://docs.gitlab.com/ee/administration/settings/rate_limit_on_groups_api.html) #### [Git HTTP rate limiting](https://docs.gitlab.com/ee/administration/settings/git_http_rate_limits.html) # VSCode Plugin The Gomboc VS Code Plugin delivers real-time, context-aware fixes powered by Gomboc’s deterministic AI. It applies precise remediations with clear explanations, helping you secure new infrastructure and clean up legacy code without slowing down development. #### 0. Prerequisites Before you start, make sure you have: * **VS Code** version 1.63.0 or greater\ * **Docker** is installed and **running** (Docker Desktop or Docker Engine)\ > **Why Docker?** The VS Code extension runs the ORL remediation engine locally inside a Docker container when you scan. If Docker isn’t running, scans/fixes won’t start. #### 1. Generate a personal token * [Here's](/getting-started/generate-a-personal-access-token) how to create a Gomboc personal access token. #### 2. Set up the Gomboc VSCode plugin * Install the Gomboc Plugin via the marketplace or direct in the IDE: * VS Code Marketplace (click "Install") [gomboc-vscode-extension](https://marketplace.visualstudio.com/items?itemName=GombocAI.gomboc-vscode-extension)
* VSCode Extensions tab. Search for "Gomboc" and click "Install":
* When you install the extension, be sure to enable "Auto Update". * Once installed, open the product settings by doing one of the following: * click the gear icon and select "Settings":
* Open Settings > Extensions and search for "Gomboc."
* Paste your Personal Access Token into the Api Key field. Run `Gomboc: Test Api Key` from the command and enable "Scan on File Save".\\
#### 3. Run your first scan Choose your path before running your scan * **Option 1 (Recommended):** Checkout the [Gomboc Reviewer guide](/integrations/vscode-plugin/gomboc-reviewer-webview) * **Option 2 (Quick):** Problems panel → Apply Fix * Create a project with a **Terraform** file. * In your IDE, create a new folder called "gomboc-quickstart" and create a new file, `main.tf`
* Populate that file with the following content: ``` provider "aws" { region = "us-east-2" } data "aws_region" "current" {} resource "aws_dynamodb_table" "test_table_a" { } resource "aws_lambda_function" "myfunction" { } resource "aws_appsync_graphql_api" "test_api" { authentication_type = "API_KEY" } resource "aws_keyspaces_table" "mykeyspacestable" { } ``` * Alternatively, check out with the following command ``` git clone git@github.com:Gomboc-AI/rattleback.git ``` * Save the file, triggering Gomboc to scan it * Alternatively, click on the search bar and select "Show and Run Commands":
* Type "Gomboc" into the search and select "Gomboc: Scan current file or scenario":
#### **4. Apply the fixes** * Review the **Problems** panel → click **Apply Fix** (or **Apply All**). * Save, test, and commit your changes. {% hint style="info" %} Want a realistic repo and a guided workflow? Continue with [**Gomboc Demo Cases**](/getting-started-ce/gomboc-demo-cases). {% endhint %} *** If you have questions or feedback, reach out at -we’re here to help! # Gomboc Reviewer (Webview) Gomboc Reviewer is the global review panel inside the Gomboc VS Code extension. It gives you a single, centralized place to triage findings, preview deterministic remediations, and apply changes across multiple files. *** ### Why use Reviewer? Reviewer is purpose-built for workflows where you want to move fast across your organization: * Bulk review and fixes across multiple files * Multi-select issues (checkboxes) and apply fix pattern across all occurrences * Preview diffs before writing the code * Ingest external findings (e.g., Checkov) and map them to Gomboc’s deterministic fix logic * Fixes with verification * Prove an issue is fixed, identifying false positives from third parties * Generate a Gomboc AI-ready prompt to fix issues found * Verify the fix matches policies and rules {% hint style="info" %} If you want end-to-end guided scenarios, start with [**Gomboc Demo Cases.**](/getting-started-ce/gomboc-demo-cases) {% endhint %} *** ### User Guide: This user guide shows how to turn a “looks production-ready” public IaC repo into an actionable hardening plan using Gomboc Reviewer: #### 1. Clone and open the repo Clone the demo repo and open it in VS Code: ```bash git clone https://github.com/iac-playground/dolphinscheduler.git ``` What you should see: * A Terraform-based AWS deployment with multiple files (a realistic, multi-file scenario). *** #### 2. Run a scenario scan (get findings across the repo) 1. Open the Command Palette (`Ctrl/Cmd + Shift + P`) 2. Run: **Gomboc: Scan current file or scenario**\ (or scan-on-save, if enabled) What you should see: * A set of findings across the scenario (often dozens in a repo like this).
*** #### 3. Open Reviewer (your “global panel” for fixing) 1. Open the Command Palette
2. Run: **Gomboc Reviewer (webview)** What you should see: * A webview with issues grouped by file on the left.
*** #### 4. Triage and select a focused batch In the left pane, pick a cluster to harden first, for example: * **RDS**: Multi-AZ, public accessibility, deletion protection / termination protection * **EC2 / launch templates**: Instance Metadata Service settings (avoid IMDSv1), detailed monitoring 1. Expand the relevant files 2. **Multi-select** findings using the checkboxes What you should see: * Selection spanning multiple files/resources (this is where Reviewer beats the Problems tab).
*** #### 5. Preview the changes (diff-first, safe workflow) 1. Click **Preview** (magnifying glass icon) 2. Wait for the preview to compute 3. Review diffs **per file** in the right pane: * `@@ ... @@` diff hunks * **Keep** / **Undo** per hunk * Optional **Show full resource** to see the enclosing Terraform block/YAML doc/etc. What you should see: * Concrete code changes for the selected resources (e.g., enabling Multi-AZ, disabling public access, enforcing metadata settings).
Tip: * Use **Open diff in editor** for full side-by-side review in VS Code.
*** #### 6. Apply changes (choose your review depth) **Option A: Apply kept changes (recommended)** 1. Keep only the hunks you want 2. Click **Apply kept changes** Guardrail: * If a file changed after preview, apply-kept will refuse, re-run **Preview**. **Option B: Apply selected (fast bulk apply)** 1. Select findings 2. Click **Apply selected** to apply fixes sequentially *** #### 7. Rescan to confirm fixes removed the findings Click **Rescan** (refresh icon) inside Reviewer What you should see: * The issue list updates, and fixed items disappear (or reduce). *** #### 8. Verify with Third Party Compare (Checkov) Click **Third Party Compare** (tool icon) What you should see: * A pass/fail summary toast/status for the targeted Checkov verification. Note: * Checkov favors false positives. If you’ve applied all available Gomboc fixes and a Checkov item still appears, inspect the Checkov report carefully. *** #### 9. Generate an AI prompt Some issues require an architectural or org-specific choice. For those: 1. Apply the remediation guidance (it may add an in-code comment telling you what to do and why) 2. Click Try AI fix to copy a structured Gomboc prompt 3. Paste into your AI tool (e.g., Cursor) and implement the change What you should see: * A code comment added + a copied prompt confirmation, then the issue disappears after you implement and rescan. # Continuous Integration (CI) Build Systems This section provides a guide for configuring integration with different CI build providers. Gomboc integrates with Continuous Integration (CI) systems using our container-based command line API client. This client can generally be integrated into any build pipeline, but we have prepare pre-configured actions and templates for the following systems: * Azure Devops Pipelines * Bitbucket Pipelines * GitHub Actions * GitLab Runners # Azure Devops Pipelines CI Pipeline Definition for Azure Devops To create a Azure Devops Pipeline, you must perform the following steps depending on whether you're starting from scratch or extending an existing pipeline. ### New Azure Devops Project: 1. Log in to your Azure account at [https://portal.azure.com](https://portal.azure.com/). 2. Sign in to your organization (`https://dev.azure.com/{Your_Organization}`). 3. Create and configure a Project - 4. Create and configure a Dev Center - 5. Add a git repository to your project - 6. Create and configure an environment type to be associated with your Dev Center - 7. Create a new pipeline and review your existing pipelines - ### Existing Azure Devops Project Follow these steps for an existing Azure Devops Project: 1. Review your existing pipelines and select which one you would like to integrate the Gomboc YAML into - 2. Follow the Azure Pipeline Editor guide to modify an existing pipeline - When editing an existing pipeline it is important to consider that some of the pipeline definition such as the `trigger` ,`pr` , and `jobs` sections may already exist, including the possibility of a nested structure. In this case, be sure to use appropriate indentation in the YAML file so that the pipeline is configured properly. The Azure tooling should help with the validation, but it is important to pay attention as you can create valid YAML that may not trigger if the indentation is incorrect when editing an existing file. ### Pull request pipeline Azure devops pipeline can use the following yaml to run the Gomboc CLI on every pull request to main. Be sure to replace the {ORGANIZATION\_NAME} fields within the yaml file with your your Azure DevOps organization name. #### Gomboc CLI Client Configuration To configure Gomboc client execution, modify the following line: ``` gomboc submit-for-review on-pull-request --auth-token $(System.AccessToken) --azdo-collection-uri $(System.TeamFoundationCollectionUri) --azdo-organization-name {ORGANIZATION_NAME} --target-directories $target_directories --pull-request 0 --iac terraform ``` The general structure of the command is: ``` gomboc --auth-token $(System.AccessToken) --azdo-collection-uri $(System.TeamFoundationCollectionUri) --azdo-organization-name {ORGANIZATION_NAME} --target-directories $target_directories --pull-request 0 --iac ``` To configure how different types of SCM actions trigger a scan in Gomboc see [CI Pipeline Configuration](/integrations/continuous-integration-ci-build-systems/ci-pipeline-configuration). #### Example Pipeline Definition Let's break down each section of this YAML file: 1. Trigger - here you must include a list of all branches which you want the build to be executed when there is a change on that branch 2. PR - this indicates the branches that should have a build run when a pull request is created. 3. Pool - this is the resource pool definition to specify which type of container should be used to execute the build 4. Jobs - this is where the real work happens in two main parts 1. CheckBranchPattern - this job skips re-running Gomboc analysis on branches that Gomboc created. 2. Gomboc\_CLI - executes the script to run the Gomboc API client. ``` # Example of a pipeline that runs on ever Pull Request trigger: branches: include: - main pr: branches: include: - main pool: vmImage: ubuntu-latest jobs: - job: CheckBranchPattern steps: - bash: | branchName="$(System.PullRequest.SourceBranch)" regexPattern="^refs/heads/[A-Za-z]+-remediated-[0-9A-Fa-f]{8}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{12}-[0-9]+$" echo "Branch: $branchName" if [[ $branchName =~ $regexPattern ]]; then echo "Branch matches the pattern." echo "##vso[task.setvariable variable=branchMatchesPattern;isOutput=true]true" else echo "Branch does not match the pattern." echo "##vso[task.setvariable variable=branchMatchesPattern;isOutput=true]false" fi name: match - job: Gomboc_CLI dependsOn: CheckBranchPattern condition: eq(dependencies.CheckBranchPattern.outputs['match.branchMatchesPattern'], 'false') steps: - checkout: self fetchDepth: 0 - bash: | if [ "$(Build.Reason)" == "PullRequest" ]; then TARGET_BRANCH_NAME=$(echo $(System.PullRequest.TargetBranch) | sed 's/refs\/heads\///') SOURCE_BRANCH_NAME=$(echo $(System.PullRequest.SourceBranch) | sed 's/refs\/heads\///') before=$(git rev-parse origin/$TARGET_BRANCH_NAME) after=$(git rev-parse origin/$SOURCE_BRANCH_NAME) target_directories=$(for i in $(git diff --name-only --diff-filter=ACMRT $before $after) ; do dirname $i ; done | sort -u | xargs) if [ -z "$target_directories" ]; then echo -e "\033[0;31mNo changes detected\033[0m" exit 0 fi docker run --rm --platform=linux/amd64 \ -v $(pwd):/repo \ -w /repo \ -e SYSTEM_ACCESSTOKEN=$(System.AccessToken) \ gombocai/cli:latest \ gomboc submit-for-review on-pull-request \ --auth-token "$(System.AccessToken)" \ --azdo-collection-uri "$(System.TeamFoundationCollectionUri)" \ --azdo-organization-name "GombocAI" \ --pull-request "$(System.PullRequest.PullRequestId)" \ --target-directories "$target_directories" \ --iac terraform exit_code=$? exit $exit_code fi ``` ### Scheduled pipeline The Gomboc pipeline also recognizes scheduled execution to support detecting remediations in code that happen due to changes in IaC modules or improvements in Gomboc remediation coverage. You can view the [Azure DevOps Pipelines documentation](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/scheduled-triggers?view=azure-devops\&tabs=yaml) to setup scheduled pipelines properly. If more flexibility is desired, the Docker image can be used by using `gombocai/cli:{TAG}` for the `image` value in your pipeline yaml file. From the image, you may use the `gomboc` command directly. ``` trigger: branches: include: - main pr: branches: include: - main pool: vmImage: ubuntu-latest # scheduled CI job execution schedules: - cron: '0 0 * * *' # Runs the job at midnight displayName: "test-scheduled-pipeline" branches: include: - main always: false # should be made to true if runs should be started regardless if changes were made to the repo jobs: - job: CheckBranchPattern steps: - bash: | branchName="$(System.PullRequest.SourceBranch)" regexPattern="^refs/heads/[A-Za-z]+-remediated-[0-9A-Fa-f]{8}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{12}-[0-9]+$" echo "Branch: $branchName" if [[ $branchName =~ $regexPattern ]]; then echo "Branch matches the pattern." echo "##vso[task.setvariable variable=branchMatchesPattern;isOutput=true]true" else echo "Branch does not match the pattern." echo "##vso[task.setvariable variable=branchMatchesPattern;isOutput=true]false" fi name: match - job: Gomboc_CLI dependsOn: CheckBranchPattern condition: eq(dependencies.CheckBranchPattern.outputs['match.branchMatchesPattern'], 'false') steps: - checkout: self fetchDepth: 0 - bash: | if [ "$(Build.Reason)" == "PullRequest" ]; then TARGET_BRANCH_NAME=$(echo $(System.PullRequest.TargetBranch) | sed 's/refs\/heads\///') SOURCE_BRANCH_NAME=$(echo $(System.PullRequest.SourceBranch) | sed 's/refs\/heads\///') before=$(git rev-parse origin/$TARGET_BRANCH_NAME) after=$(git rev-parse origin/$SOURCE_BRANCH_NAME) target_directories=$(for i in $(git diff --name-only --diff-filter=ACMRT $before $after) ; do dirname $i ; done | sort -u | xargs) if [ -z "$target_directories" ]; then echo -e "\033[0;31mNo changes detected\033[0m" exit 0 fi docker run --rm --platform=linux/amd64 \ -v $(pwd):/repo \ -w /repo \ -e SYSTEM_ACCESSTOKEN=$(System.AccessToken) \ gombocai/cli:latest \ gomboc submit-for-review on-pull-request \ --auth-token "$(System.AccessToken)" \ --azdo-collection-uri "$(System.TeamFoundationCollectionUri)" \ --azdo-organization-name "GombocAI" \ --pull-request "$(System.PullRequest.PullRequestId)" \ --target-directories "$target_directories" \ --iac terraform exit_code=$? exit $exit_code ``` # BitBucket Pipelines To configure how different types of SCM actions trigger a scan in Gomboc see [CI Pipeline Configuration](/integrations/continuous-integration-ci-build-systems/ci-pipeline-configuration). ### Pull Request Pipeline A BitBucket pipeline can use the following YAML to run the Gomboc CLI on every pull request to main, will only try to remediate directories with code differences. When running the the `Gomboc` cli command you can replace `submit-for-review` argument with `preview` if no pull request is desired. Please note that with `preview`, the pipelines will pass regardless of any remediations that are produced. ``` image: node:18 pipelines: pull-requests: '**': - step: name: "Run Gomboc CLI" oidc: true services: - docker script: - git fetch origin +refs/heads/*:refs/remotes/origin/* - before="$(git rev-parse origin/$BITBUCKET_PR_DESTINATION_BRANCH)" - after="$(git rev-parse origin/$BITBUCKET_BRANCH)" - echo "before $before" - echo "after $after" - target_directories=$(for i in $(git diff --name-only --diff-filter=ACMRT "$before" "$after") ; do dirname $i ; done | sort -u | xargs) - | if [ -z "$target_directories" ]; then echo -e "\033[0;31mNo changes detected\033[0m" exit 0 fi - | docker run --rm --platform=linux/amd64 \ -e FORCE_COLOR=3 \ gombocai/cli:latest \ sh -c "gomboc submit-for-review on-pull-request \ --auth-token $BITBUCKET_STEP_OIDC_TOKEN \ --target-directories \"$target_directories\" \ --pull-request $BITBUCKET_PR_ID \ --iac terraform cloudformation" ``` ### Scheduled Pipeline The Gomboc pipeline can be executed on a schedule to support detecting remediations in code that happen due to changes in IaC modules or improvements in Gomboc remediation coverage. To configure a scheduled pipeline, use the custom pipeline option in Bitbucket pipelines and set up your Gomboc pipeline following the instructions [here](https://support.atlassian.com/bitbucket-cloud/docs/pipeline-triggers/#On-schedule). Note that the values provided for the `target_directories`variable is an example and must be modified to point to the folder in your IaC repository to scan for the pipeline to execute successfully. ``` image: node:18 pipelines: custom: 'gomboc_scheduled': - step: oidc: true name: 'Run Gomboc CLI' script: - | target_directories=("." "tf" "iac") docker run --rm --platform=linux/amd64 \ -e FORCE_COLOR=3 \ gombocai/cli:latest \ sh -c "gomboc submit-for-review on-schedule \ --auth-token $BITBUCKET_STEP_OIDC_TOKEN \ --target-directories \"${target_directories[@]}\" \ --pull-request $BITBUCKET_PR_ID \ --iac terraform cloudformation" ``` # CI Pipeline Configuration You can configure your CI pipeline and the interaction with Gomboc in the following ways: 1. Review type - defines whether a review simply generates comments or if a new pull request is created to address Gomboc code findings. 2. Trigger type - defines when a review is triggered and code is analyzed by Gomboc The following table outlines the configuration parameter options and their meanings:
Configuration OptionOptionsDescription
REVIEW_TYPE
  • submit-for-review
  • preview

This is the type of review that Gomboc will perform on the code.

  • "preview" means that there will be no subsequent pull request created, only a record of the scan in the pipeline logs and in the Gomboc Portal UI.
  • "submit-for-review" means that a pull request (PR) will be created with the fixes that Gomboc discovers are applicable to the code.

Please note that with preview, the pipelines will pass, regardless of any remediations we find.

TRIGGER_TYPE
  • on-pull-request
  • on-commit

This is the type of trigger that was used to initial the Gomboc client.

  • "on-pull-request" means a PR was submitted by a user for review
  • "on-commit" means that the notification came on a commit to a particular branch
IAC_TYPE
  • terraform
  • cloudformation

The IaC types which Gomboc should consider when analyzing the code. If providing multiple values, it must be specified as a comman separated list. For example:

--iac "cloudformation,terraform"
# GitHub Actions Gomboc provides two GitHub Actions that integrate security policy scanning directly into your pull request and scheduled workflows. Both actions scan your infrastructure-as-code files and report policy violations — the difference is in how they run, how they authenticate, and how results are surfaced. For a full overview of how Gomboc interacts with your CI pipeline, see [CI Pipeline Configuration](https://docs.gomboc.ai/integrations/continuous-integration-ci-build-systems/ci-pipeline-configuration). ### Which action should I use?
CLI-based (on-pull-request, on-schedule)ORL Runner (on-pull-request-runner)
How it worksRuns the Gomboc CLI inside the workflowRuns ORL rules in isolated Docker containers
AuthenticationOIDC (no long-lived secrets needed)Personal Access Token (GOMBOC_ACCESS_TOKEN)
Findings outputGomboc Portal + PR status checkInline PR review comments + Gomboc Portal
Auto-remediationOpens a stacked PR with fixesOpens a stacked PR with fixes
Scheduled scansYes (on-schedule action)No
Pipeline blockingVia effect: submit-for-reviewVia fail-on-findings: true
Recommended forMost teams — simpler setup, OIDC authTeams that want inline per-line PR comments
*** ### CLI-based actions The CLI-based actions (`on-pull-request` and `on-schedule`) use the Gomboc CLI to scan your repository. Authentication is handled via OIDC — no long-lived secrets required. #### Pull Request Pipeline The examples below show how to run Gomboc on every pull request. Blocking is the recommended configuration when you want to enforce security policies in CI. **Blocking (default — recommended):** ```yaml name: Gomboc.AI Terraform permissions: id-token: write contents: read on: pull_request: jobs: gomboc: runs-on: ubuntu-latest steps: - name: Gomboc.AI - Terraform Remediate uses: Gomboc-AI/actions/on-pull-request@main with: effect: submit-for-review iac: terraform cloudformation cli-version: 'latest' ``` **Non-blocking (audit only):** ```yaml name: Gomboc.AI Terraform permissions: id-token: write contents: read on: pull_request: jobs: gomboc: runs-on: ubuntu-latest steps: - name: Gomboc.AI - Audit Only uses: Gomboc-AI/actions/on-pull-request@main with: effect: audit iac: terraform cloudformation cli-version: 'latest' ``` #### Blocking vs. non-blocking pipelines Use the `effect` input to control whether Gomboc findings block your CI pipeline. | `effect` | Creates remediation PR | Blocks pipeline when remediable fixes are found | | ----------------------------- | ---------------------- | ----------------------------------------------- | | `submit-for-review` (default) | Yes | Yes — the workflow step fails | | `audit` | No | No — findings are reported, pipeline passes | **How blocking works** When `effect` is `submit-for-review` and Gomboc finds remediable policy violations: 1. Gomboc runs the scan on files changed in the pull request. 2. Gomboc opens a stacked remediation pull request with the proposed fixes. 3. The GitHub Actions step exits with a non-zero status. 4. The workflow job is marked as failed, which blocks the pipeline. To unblock the pipeline, review and merge the remediation PR (or update the original PR so violations are resolved), then re-run the workflow. When `effect` is `audit`, Gomboc still runs the scan and records results in the Gomboc Portal, but the step always succeeds even when findings are present. Use this mode during initial rollout or testing. **Enforce with branch protection (recommended)** To prevent merging until Gomboc passes: 1. Go to **Settings → Branches** in your GitHub repository. 2. Edit or create a branch protection rule for your target branch (e.g. `main`). 3. Enable **Require status checks to pass before merging**. 4. Add your Gomboc job as a required status check (the check name matches the job id, e.g. `gomboc`). #### Scheduled Pipeline The `on-schedule` action supports scheduled scans to detect remediations triggered by changes in IaC modules or improvements in Gomboc remediation coverage. The `cron` value follows standard crontab syntax — use [crontab.guru](https://crontab.guru) to generate one. > **Note:** Replace `target-directory: tf` with the path in your repository that contains IaC files. ```yaml name: Gomboc.AI Terraform Scheduled permissions: id-token: write contents: read on: schedule: - cron: '0 0 * * *' jobs: gomboc: runs-on: ubuntu-latest steps: - name: Gomboc.AI - Terraform Remediate uses: Gomboc-AI/actions/on-schedule@main with: effect: submit-for-review target-directory: tf recurse: false iac: terraform cloudformation cli-version: 'latest' ``` #### Notes * Workflows triggered by `gomboc-ai[bot]` are skipped automatically to avoid remediation loops. * Use `cli-version: 'latest'` to always run with the most recent CLI version. * For the full list of action inputs, see the [Gomboc-AI/actions repository](https://github.com/Gomboc-AI/actions). > **Need more flexibility?** If you need to run the Gomboc CLI directly, Docker images are available on DockerHub under [`gombocai/cli`](https://hub.docker.com/r/gombocai/cli). *** ### ORL Runner (`on-pull-request-runner`) The `on-pull-request-runner` action uses [ORL (Open Remediation Language)](https://github.com/Gomboc-AI/orl) to scan the files changed in a pull request. Unlike the CLI-based action above, it runs ORL rules in isolated Docker containers and surfaces findings as **inline review comments** directly on the changed lines in your PR. > **Authentication:** this action uses a Personal Access Token. Store it as `GOMBOC_ACCESS_TOKEN` in your repository or organisation secrets. #### Audit vs Remediate — feature comparison
FeatureAuditRemediate
Inline review comments on changed linesyesno
Summary PR commentyesno
Stacked remediation PR (with fixes)noyes
Integrations telemetryyesyes
fail-on-findings to block the pipelineyesno
Fork PR pushn/askipped
#### Audit mode Runs ORL on the PR diff and posts findings as inline review comments and a summary PR comment. The job passes by default even when findings are present. ```yaml on: pull_request: types: [opened, synchronize, reopened] permissions: contents: read pull-requests: write packages: read jobs: gomboc-orl-audit: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 with: ref: ${{ github.event.pull_request.head.sha }} fetch-depth: 0 - uses: gomboc-ai/actions/on-pull-request-runner@main with: mode: audit env: GOMBOC_ACCESS_TOKEN: ${{ secrets.GOMBOC_ACCESS_TOKEN }} ``` #### Remediate mode When ORL produces fixes, the action pushes a bot branch and opens a **stacked pull request** with the applied fixes targeting your feature branch. ```yaml on: pull_request: types: [opened, synchronize, reopened] permissions: contents: write pull-requests: write packages: read jobs: gomboc-orl-remediate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 with: ref: ${{ github.event.pull_request.head.sha }} fetch-depth: 0 - uses: gomboc-ai/actions/on-pull-request-runner@main with: mode: remediate env: GOMBOC_ACCESS_TOKEN: ${{ secrets.GOMBOC_ACCESS_TOKEN }} ``` > **Fork PRs:** if the PR originates from a fork (`pull_request.head.repo.full_name != github.repository`), the push step is skipped with a warning. Do not use `pull_request_target` to work around this unless you understand the security tradeoffs. > **No remediation PR opened?** Check the job log for `ORL report totals: findings=…, fixes=…, changes=…`. If `fixes=0` and `changes=0`, ORL found violations but could not auto-remediate them — there is nothing to commit. #### Blocking the pipeline on findings By default, the action exits successfully even when ORL reports findings. Set `fail-on-findings: true` to fail the job and block the pipeline: ```yaml - uses: gomboc-ai/actions/on-pull-request-runner@main with: mode: audit fail-on-findings: true env: GOMBOC_ACCESS_TOKEN: ${{ secrets.GOMBOC_ACCESS_TOKEN }} ``` Then protect your branch in **Settings → Branches → Branch protection rules** by requiring the `gomboc-orl-audit` status check before merging. #### How it works 1. Resolve rules channel from JWT (or `orl-channel` input) 2. Pull ORL rules into a local cache 3. `git diff` PR base..head → list of changed files 4. Detect language and workspaces per changed file 5. Run `orl remediate` in parallel per workspace (default concurrency: 3) 6. POST scan results to Gomboc Integrations 7. **Audit:** post inline review comments + summary comment → upload artifacts 8. **Remediate:** copy fixes → push bot branch → open stacked PR → upload artifacts #### All inputs | Input | Default | Description | | --------------------------- | ------------------------------------ | ------------------------------------------------------------------------ | | `mode` | *(required)* | `audit` or `remediate` | | `fail-on-findings` | `false` | Fail the job when findings or changes are greater than zero (audit only) | | `max-changed-files` | `50` | Maximum PR-changed paths to process | | `orl-channel` | *(from token)* | Rules channel; empty = resolved from `GOMBOC_ACCESS_TOKEN` JWT | | `orl-version` | *(latest)* | ORL Docker image tag | | `orl-image` | `""` | Full Docker image ref — overrides `orl-version` when set | | `rules-service-url` | `https://rules.app.gomboc.ai` | Gomboc Rules Service base URL | | `integrations-service-url` | `https://integrations.app.gomboc.ai` | Gomboc Integrations base URL | | `portal-service-url` | `https://app.gomboc.ai` | Portal base URL for rule links in inline comments | | `integrations-enabled` | `true` | Set `false` to skip posting results to Integrations | | `scan-timeout-seconds` | *(no limit)* | Timeout per ORL remediate run (seconds) | | `orl-timeout` | *(no limit)* | ORL `--timeout` | | `orl-rule-timeout` | `10s` | ORL `--default-rule-timeout` | | `remediation-branch-prefix` | `gomboc/orl-remediation` | Branch prefix for stacked remediation PRs | | `comment-max-per-pr` | `50` | Maximum inline review comments per PR | # GitLab Runners To configure how different types of SCM actions trigger a scan in Gomboc see [CI Pipeline Configuration](/integrations/continuous-integration-ci-build-systems/ci-pipeline-configuration). ### Pull request pipeline GitLab CI/CD can use the following code to use the following job on the Gomboc-AI project. This will trigger a `submit for review` action on the Gomboc CLI for every pull request. You can replace the `effect` input with `preview` if no pull request is wanted. Please note that with `preview`, the pipelines will pass, regardless of any remediations we find. ``` # Example of a pipeline that runs on ever Pull Request include: - 'https://gitlab.com/gomboc-ai/actions/-/raw/main/action/.gitlab-ci.yml' stages: - example variables: EFFECT: submit-for-review setup-job: stage: example extends: .run-scan rules: - if: $CI_PIPELINE_SOURCE == 'merge_request_event' ``` ### Scheduled pipeline The Gomboc CLI command also recognizes scheduled execution to support detecting remediations in code that happen due to changes in IaC modules or improvements in Gomboc remediation coverage. You can view the [GitLab pipeline documentation](https://docs.gitlab.com/ee/ci/pipelines/schedules.html1) to setup scheduled pipelines. If more flexibility is desired, the Docker image can be used by using `gombocai/cli:latest` for the `image` value in your .gitlab-ci.yml file. The implementation of the CI/CD can be viewed [here](https://gitlab.com/gomboc-ai/actions/-/blob/main/terraform/remediate/.gitlab-ci.yml?ref_type=heads). From the image, you may use the `gomboc` command directly. ``` # Example of a pipeline that can be run on a schedule # The 'target_directories' array should be updated to include all directories # that include your IaC that should be scanned image: name: gombocai/cli:latest entrypoint: [""] stages: - build run-scan: id_tokens: GL_ID_TOKEN: aud: https://gomboc.ai stage: build variables: FORCE_COLOR: 3 script: - | target_directories=("." "tf" "terraform") gomboc submit-for-review on-schedule --auth-token $GL_ID_TOKEN --target-directories "${target_directories[@]}" --iac cloudformation terraform ``` # Cloud Orchestration # HCP Terraform ## Terraform Run Task Integration Gomboc AI for Infrastructure as Code automatically fixes misconfigurations in your Terraform code. Gomboc translates cloud policies into production-ready IaC fixes delivered as pull requests, so you can merge confidently and keep pipelines moving without disruption. ## Integration Setup Follow these steps to configure the Terraform Run Task integration: ### Step 1: Access Gomboc Portal Navigate to **Settings > Integrations > HashiCorp** in the Gomboc Portal.
Gomboc Integrations page showing HashiCorp section
### Step 2: Create Integration Enter a name to identify this integration and click **Integrate** to generate credentials.
Integration creation form
### Step 3: Collect Credentials Copy the **HMAC Key** and **Webhook URL** - you’ll need these to configure the Run Task in Terraform Cloud.
Integration credentials display
### Step 4: Access HCP Organization Now that your Gomboc-side integration is ready, let’s switch over to Terraform Cloud to finish setup. In a new tab, go to and select the organization where you want to enable this integration.
HCP organization selection
### Step 5: Navigate to Run Tasks Go to **Settings > Integrations > Run tasks** and click **"Create run task"**.
HCP Run Tasks page with create button
### Step 6: Configure Run Task Paste the Webhook URL and HMAC Key from Step 3 into the respective fields and add a display name.
Run task configuration form
### Step 7: Set Scope and Create Configure the scope for your Run Task and click **Create**.
Run task scope configuration
## Configuration Options ### Scope Selection When setting the scope for your Run Task, you can choose any scope that fits your workflow needs. **Recommendation:** Select any option **except** "post-apply" to ensure Gomboc can remediate issues before changes are applied to your infrastructure. ### Enforcement Levels You'll be prompted to select an enforcement level: * **Advisory:** Shows warnings for detected misconfigurations but **does not block** the Terraform run from proceeding * **Mandatory:** Shows errors for detected misconfigurations and **blocks** the Terraform run until issues are resolved Choose the enforcement level that best matches your organization's policy for infrastructure changes. ### Deployment Options You can configure Run Tasks at two levels: #### Organization-Level Run Tasks * Apply to all workspaces within the selected organization * Ensures consistent policy enforcement across your infrastructure * Recommended for most organizations #### Workspace-Level Run Tasks * Provide more granular control for specific teams or projects * To configure: Skip the global setup in Step 7, then navigate to the desired workspace in HCP Terraform * Go to **Settings > Run Tasks** and add the Gomboc Run Task you created Choose the configuration approach that best fits your workflow and organizational requirements. *** **Need help?** Leave feedback via our [GitHub discussions channel.](https://github.com/Gomboc-AI/gomboc-ai-feedback/discussions/6) # API ## Creating API Credentials 1. Open your user account settings. 2. Select "Personal Access Tokens" 3. Create a personal access token, giving it a name and time to expiry. 4. Copy the token to a safe place. {% @storylane/embed subdomain="app" url="" linkValue="m7gggisrxyam" %} ## GraphQL playground 1. Create a PAT from our Portal (top right corner your name > `Settings` > `Personal Tokens`) 2. Go to to find our API playground 3. In the `Headers` section (bottom center), add: ```json { "Authorization": "Bearer YOUR-TOKEN" } ``` 4. Now you can fetch the schema (lower left corner, `Refresh` button) 5. Next, use the left Explorer tool (top left corner, `Folder` button) to compose Queries or Mutations by selecting the fields that you care for 6. Execute your query (top right corner, `Play` button) ## Examples with `curl` Get all the organization project names for the current user: ```bash curl -X POST https://api.app.gomboc.ai/graphql \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR-TOKEN" \ -d '{ "query": "query MyQuery { organization { ... on Organization { name projects { name } } } }", "variables": {} }' ``` Link a repository to a project: ```bash curl -X POST https://api.app.gomboc.ai/graphql \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR-TOKEN" \ -d '{ "query": "mutation MyMutation { linkRepositories(input: {projectId: \"\", providers: {gitProviderId: \"\", selectedRepositoryIds: \"\"}}) { ... on Link { id createdAt createdBy } ... on GombocError { code message } } }", "variables": {} }' ``` {% hint style="info" %} Something missing? Looking for a particular feature? Please get in touch {% endhint %} # Configuration We provide essential configurations to optimize your experience with Gomboc. Ensuring your settings are correctly configured will help you avoid common issues and enhance your interaction with our application.
Browser Settings/files/cp1aWbtFDCHLVZ0HWOLi/pages/AOO2mG29tmWRZTvpJmxm
Security Settings (Coming Soon)/files/FsBEzGeZHlqQkSKMStZO
User Preferences (Coming Soon)/files/cp1aWbtFDCHLVZ0HWOLi
# Browser Settings ## Overview This section provides guidelines to ensure that your browser settings are optimized for accessing and viewing Gomboc applications. Following these instructions will help you avoid common display issues and ensure a smooth user experience. ## **Browser Configuration for Optimal Access** To ensure that Gomboc applications display correctly in Safari, follow these steps: * Open Safari and go to `Safari > Preferences > Privacy`. * Make sure the option `Prevent cross-site tracking` is **not** checked.
To ensure that Gomboc works properly in Google Chrome, you must either enable third-party cookies or allow just the third-party cookies for Gomboc. To determine your current settings, in Chrome go to in your browser. You can use the link directly or navigate through Settings -> Privacy and Security -> Third Party Cookies.
If “Block Third Party Cookies” is selected, then you will need to either select "Block third-party cookies in Incognito mode" or allow third party cookies for the Gomboc site specifically.
To enable cookies just for the Gomboc site, select the eye icon and select the switch to temporarily enable third-party cookies. This will only last for your current browsing session.
## General Browser Configuration Tips * **Clear Cache and Cookies:** Regularly clear your browser’s cache and cookies to prevent display issues caused by outdated data. * **Update Browser:** Ensure you are using the latest version of your browser for the best performance and compatibility. * **Disable Browser Extensions:** Some browser extensions may interfere with dashboard functionality. Disable extensions if you encounter issues. ## Troubleshooting Dashboard Viewing Issues If you experience any difficulties in viewing the dashboards, follow these troubleshooting steps: * **Check Internet Connection:** Ensure you have a stable internet connection. * **Try a Different Browser:** If issues persist, try accessing the dashboards using a different browser. * **Report the Issue:** Contact our support team with details about your browser, version, and any error messages. ## Contact Support If you encounter any issues or need further assistance, please contact our support team: E-mail: **** # Authentication - Pwdless & SSO ## Overview Gomboc provides 2 different ways for authenticating users:
MethodHow it worksRequirements
Passwordless
  1. Users login with their email address
  2. They will receive an email with a 6-digits code, to insert on Gomboc login page
  1. Invite the users to your Gomboc Org (see /pages/4UOWOlsPORjf034RX81H)
SSO
  1. Users login with their email address
  2. They will be redirected to your IdP (e.g. Okta, Google Workspace)
  3. Upon authentication, they will be redirected to Gomboc
  1. Create a SAML app in your IdP for Gomboc (see below for guidance)
  2. Configure the SSO connection in the Gomboc Portal
*** ## SSO Configuration Gomboc provides an easy to follow configuration wizard for setting up an SSO connection to your Identity Provider. **Note**: the following admin-level permissions are required in your Company's IT systems: * IdP: Creation of a custom SAML application * DNS: Creation of a TXT record When ready, follow these steps to configure SSO for authenticating to Gomboc ### Step 1: Configure your IdP (Create SAML App) 1. Login to app.gomboc.ai (through the Magic Link sent to your email) 2. Click on your account on the top right > Settings
3. Click on SSO on the left sidebar > Setup SSO Connection:
4. Select your IdP and follow the wizard to create a SAML app:
5. On "Create SAML Application": use the following parameters (they are also mentioned in the configuration wizard): 1. ACS URL: 2. Entity ID: gomboc 3. Name ID format: EMAIL 4. Name ID: Primary Email 6. On "Fill Attribute Statements": leave as-is, it's optional (you can configure groups later if needed) 7. Enable the SAML App in your IdP and download the Metadata in xml 8. Upload the Metadata obtained in the previous step from your IdP in the Gomboc SSO configuration wizard 9. Confirm and Continue to next step (claim domain) ### Step 2: Claim Domain 1. Once the IdP configuration is completed, insert your company's domain under "Claim Domain" in the SSO Configuration Wizard and click Proceed:
2. Create a new TXT record in your company's DNS, inserting the Name and Value from the wizard:
### Step 3: Manage Authorization (Default Roles) Once the domain is validated, the next and final step is for managing authz and assigning roles to your new users. 1. By default there are 2 roles - Admin and Read-Only; select the one you want to assign by default to every new user logging in to Gomboc and click Done:
### Step 4: Group Mapping to Roles (Optional) It is possible to automatically assign the Admin or Read-Only role to your IdP Groups. * Note: By default the groups that the user passes from the IdP are being checked only upon user creation / first login via SSO to Gomboc For the mapping to work, follow these steps: 1. Configure the Role Mapping on your IdP SAML Application (here below an example from Google Workspace)
2. In the SSO configuration of the Gomboc Admin portal, map the groups that your users will be passing to corresponding roles in your application:
3. Click "Done" ### Step 5: Turn On SSO Connection 1. Once the SSO Configuration Wizard is completed, make sure to turn on the recently created SSO connection
## Contact Support If you encounter any issues or need further assistance, please contact our support team: E-mail: **** # User Management ### Overview This article explains how to add new users to Gomboc {% hint style="info" %} Remember: if you have configured SSO, everybody in your IdP will be able to login to Gomboc with the default role you have configured * See details in [Authentication - Pwdless & SSO](/configuration/authentication-pwdless-and-sso) {% endhint %} ### Add New User to Gomboc If you want to provide access to Gomboc to other people in your team / company, follow these steps: 1. Login to app.gomboc.ai 2. Click on your account on the top right > Settings
3. Click on Users on the left sidebar > Invite User
4. Fulfill the information (Name, Email and Default Role) and click Invite ## Contact Support If you encounter any issues or need further assistance, please contact our support team: E-mail: **** # Workspaces This topic provides an overview of the workspaces resource in Gomboc. A Workspace is Gomboc’s unit of IaC, a deployable module in your version control system. ## Introduction Workspaces are Gomboc's core organizing concept for managing, scanning, and remediating Infrastructure as Code (IaC) across connected source code repositories. Designed for a seamless developer experience, a Workspace is uniquely defined by: * IaC Tool (e.g., Terraform, CloudFormation) * Repository (e.g., GitHub, GitLab, Bitbucket, Azure Repos) * Branch (default or protected) * Path (directory containing the IaC module) Once created, a Workspace becomes the control plane for tracking posture, running scans, applying rules, and managing remediations, all directly from the Gomboc UI or integrated into your CI pipelines. #### What Is a Workspace? Think of a Workspace as a mirror of a deployable unit of IaC in your version control system. Gomboc Workspaces: * Are created automatically based on connected repositories and supported IaC detections * Track changes, findings, and fixes over time * Power Gomboc’s PR scanning and drift remediation workflows Each Workspace is based on a canonical scenario (repo + branch + path + IaC tool), and only default and protected branches are considered for workspace creation. *** ## Discovery & Indexing When you connect your SCM provider to Gomboc: 1. Gomboc scans your repos to detect repositories possibly containing IaC 2. The repository is scanned and Workspaces are created based on the detected contents the repository 3. Your PRs are mapped to ancestor Workspaces by tracing to the nearest default/protected branch 4. An initial scan is run to establish a baseline and detect misconfigurations 5. Gomboc PR-ready fixes are generated per Workspace ### Example * **Repo:** `infra-network` * **Branches:** `main` (default), `prod` (protected) * **Paths:** `/vpc`, `/eks` **Workspaces created** * `infra-network-main-vpc` * `infra-network-main-eks` * `infra-network-prod-vpc` * `infra-network-prod-eks` ### Workspace Discovery New Workspaces are discovered under the following conditions: 1. A new SCM integration is created, resulting in a workflow discovery of workspaces is triggered 2. On a scheduled basis (hourly by default), repositories are indexed for new workspaces. **Special Cases** If IaC code is submitted to be merged on a new path under a default branch (which would mean it is a new workspace), then it will scanned as part of the change request review but that scan will not be visible in the portal UI under a workspace yet because it has yet to be created. The workspace will be added to the portal UI once the scheduled indexing for workspaces occurs. If needed, you can follow the manual workspace creation process in the interim. *** ## Workspace Creation and Editing Users can create workspaces manually by selecting the “Add Workspace” button in the portal interface and completing the details in the creation dialogue.
You can create a Workspace from **Workspaces → Add Workspace** by providing: * **IaC tool** – Terraform / CloudFormation / (others as supported) * **SCM integration** – the account/org/group to search under * **Repository** – code repo containing the module * **Branch** – default or protected branch to anchor the Workspace * **Path** – folder containing the IaC module ### **Editing a workspace name** * Go to Workspaces and use Search/Filters to open the workspace you need. * Click the edit icon next to the workspace name to change it.
*** ## Scan Triggers & Modes How scans run for a Workspace and the difference between Audit vs PR Mode. ### How scans are triggered * **On demand (Portal):** From a Workspace, click **Run scan** to start an immediate analysis. * **Pull requests (CI):** On PR open/update, Gomboc identifies the **ancestor Workspace** (via branch ancestry + path), runs a scan, and posts results to the PR (checks and/or comments). ### Modes per Workspace Each Workspace operates in one of two modes: | Mode | Behavior | | ----------------- | ------------------------------------------------------------------------------------------------ | | **Audit only** | Reports findings and suggested fixes. No PR is created automatically. | | **Deliver fixes** | Opens a side PR with automated fixes (similar to Dependabot). Developers review, edit, or merge. | *** ## FAQ #### Common Workspaces questions:
Can I delete a Workspace? Workspaces can’t be permanently deleted. Archive them instead, then filter to hide archived items.
Can I manually create a Workspace? Yes. From **Workspaces → Add Workspace**, provide **IaC tool**, **SCM integration**, **Repository**, **Branch** (default/protected), and **Path**. Gomboc validates the path and starts a baseline scan.
Are IDE scans linked to Workspaces? **No. IDE scans are local and not linked to Workspaces.** If your project has a `.git` folder, we may suggest a related Workspace, but IDE findings aren’t added to Workspace posture or PR checks. When you open/update a PR, those changes are scanned against the ancestor Workspace.
Why doesn’t Gomboc create Workspaces for feature branches? To avoid noise. PR scans map to the ancestor Workspace on a default/protected branch. This keeps the inventory clean and focused on deployable IaC.
*** \ Need help? Contact us at \\ # ORL (Open Remediation Language) ## 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't 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 {% hint style="info" %} For details, see: [**ORL Custom Rules Quickstart**](/orl/quickstart). {% endhint %} *** ### 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 languages. 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?”*
# Custom Rules Quickstart ORL Rules are YAML-like files that drive the `orl` engine to modify files within a workspace. ## Step 1. Clone Rattleback [Rattleback](https://github.com/Gomboc-AI/rattleback) includes some sample code that can be used to run checks against. We will use it for this example. ```bash git clone git@github.com:Gomboc-AI/rattleback.git ``` ## Step 2. Create a Rule Next, let's create a simple rule that ensures `aws_s3_bucket` Terraform resources are tagged. Don't worry too much about the details at this point, we'll explain it [below](#the-rule-explained). Create a `./rules` directory and write the following as `./rules/enforce_aws_s3_bucket_tagging.orl`. ```yaml type: Ruleset version: v1 metadata: annotations: purpose: tagging priority: 100 name: ensure-s3-buckets-are-tagged display_name: Ensure S3 Buckets are tagged description: | ## Description All buckets have to be tagged according to the source of truth. spec: template: language: terraform audit_language: ast rules: - name: ensure-tag-exists audit: | {{ aResource("aws_s3_bucket", aMissingAttribute("tags")) }} remediation: - command: insert_after path: body flags: prefix: "\n\n" indent: " " value: | tags = { source = "rattleback" } ``` ## Step 3: Remediate The ORL engine is provided as a Docker container. It can be executed with the appropriate mount points to load the rules and remediate files. ```bash docker run -v ./rules:/rules -v ./rattleback:/workspace gombocai/orl:latest remediate --rulespace /rules /workspace/aws/terraform/s3-default ``` After running the command, `main.tf` is modified to include a `tags` attribute for the `uut` resource with `source = "rattleback"`, just as specified by the rule. The resulting `git diff` would look like this: ```diff diff --git a/aws/terraform/s3-default/main.tf b/aws/terraform/s3-default/main.tf index 892167e..17751a2 100644 --- a/aws/terraform/s3-default/main.tf +++ b/aws/terraform/s3-default/main.tf @@ -22,6 +22,10 @@ resource "aws_s3_bucket" "uut" { bucket = "${local.prefix}-uut" force_destroy = true + + tags = { + source = "rattleback" + } } resource "aws_s3_bucket_ownership_controls" "uut" { bucket = aws_s3_bucket.uut.id ``` {% hint style="info" %} `orl remediate` supports a `--dry-run` option which will write the changed files to the terminal instead of disk. This can help in developing rules as you don't need to run `git restore` to undo the changes and try again. {% endhint %} ## The Rule Explained Here is a fully annotated version of the Rule. ```yaml # There are five ORL types: Rule, Ruleset, Variables, Test, and Report. # Type and version tell ORL how and when to process the file. # "Ruleset" tells ORL it is a collection of rules that have to be executed # as a group. type: Ruleset version: v1 # Metadata defines various details which control how the rule executes # as well as provides context for reports metadata: # Name uniquely identifies the rule, while display_name is copied into the # report and is meant as a more human readable name. name: ensure-s3-buckets-are-tagged display_name: Ensure S3 Buckets are tagged # Description is a markdown string that describes the purpose of the rule. # It is copied into the report. description: | ## Description All buckets have to be tagged according to the source of truth. # Priority defines the order of when rules are run. Rules are run from the # smallest number to the largest. Two rules with the same priority are # run based on sorted names. priority: 100 # Annotations are a map of string key/value pairs. They can be anything, # and are blindly copied into the ORL report. annotations: purpose: tagging # The spec depends on the types. This is the spec for a "Ruleset", which is an # array of Rules. spec: # These settings are shared with each rule below template: # The ORL language can be used to get a list of the languages # Only rules that match `orl remediate --language ` are loaded. language: terraform # This determines what form of parsing ORL uses. Currently only AST is # supported. audit_language: ast # Array of the actual rules rules: # All rules in a ruleset should be uniquely named. This name is included # in the report metadata. - name: ensure-tag-exists # `audit` is the search query to perform. In this case, it uses template # helpers that generate the actual S-expression. The list of helpers can # be seen via `orl language ` audit: | {{ aResource("aws_s3_bucket", aMissingAttribute("tags")) }} # A list of remediation steps to perform on each finding remediation: # The command to run on each finding. `insert_after` sets the cursor # right after the last character of the named match defined by `path`. # The other commands are: # `audit` - Don't change any files, just log a message to the report # `create` - Add value to the bottom of a file only if no named match was found # `insert_before` - Insert value before the named match # `replace` - Replace the contents of the named match # `remove` - Remove the named match - command: insert_after # The `aResource` helper provides many named matches in the AST # structure. "body" is all the text exclusively between the curly # braces. path: body flags: prefix: "\n\n" # Append an empty line before `value` indent: " " # Add in front of every line of `value` value: | tags = { source = "rattleback" } ``` ## Further Reading * [Concepts behind ORL](/orl/concepts) * [ORL Schemas](/orl/schemas) # Core Concepts The following are the core concepts of ORL. * [Audit](/orl/concepts/audit) * [Collections](/orl/concepts/collections) * [Finding](/orl/concepts/finding) * [Languages](/orl/concepts/languages) * [Remediation Steps](/orl/concepts/remediation_steps) * [Rule / Ruleset](/orl/concepts/rules) * [Rule-space](/orl/concepts/rule-space) * [Template](/orl/concepts/template) * [Tests](/orl/concepts/tests) * [Variables](/orl/concepts/variables) * [Workspace](/orl/concepts/workspace) # Audit An ORL audit query is how ORL finds [findings](/orl/concepts/finding) to remediate. They are [templated](/orl/concepts/template) AST patterns in the form of [S-Expressions](https://tree-sitter.github.io/tree-sitter/using-parsers/queries/1-syntax.html) based on the language that the rule remediates. Each positive match is considered a finding and all the capture groups are made available for remediation: For example: The following is an expression to find key value pairs within any object of a YAML file. It will find all key/value pairs - each as a separate finding - regardless of level of nesting. The `@key` and `@value` capture groups are made available to remediation steps as `key`, and `value` respectively. ```lisp (block_node (block_mapping (block_mapping_pair (flow_node) @key (flow_node) @value ) ) ) ``` ## Capture Group Evaluation It is often useful to limit the number of findings based on the value contained within the capture group. This can be done with: * `#eq?` - The capture group must match exactly * `#not-eq?` - The capture group must NOT match * `#any-of?` - The capture group must match one of the provided strings * `#match?` - The capture group must match the provided regex * `#not-match?` - The capture group must NOT match the provided regex For example, say I only want to match key/value pairs if the key starts with "label-". ```lisp (block_node (block_mapping (block_mapping_pair (flow_node) @key (flow_node) @value ) (#match? @key "^label-") ) ) ``` ## Template helpers Audit queries can get very complex. ORL ships with a number of template helpers - based on the language - that help in doing common things in that language. For example `{{ aResource("aws_s3_bucket") }}` will generate the S-expression to find all S3 bucket resources in terraform files. The template helpers can be found via `orl language ` for each supported language. See [Languages](/orl/concepts/languages) for details. # Collections Collections are simple in concept, and open up use cases that cannot be done in any other way; however, their usage can hide intent so use them sparingly. Collections are [audits](/orl/concepts/audit) that run against the entire [workspace](/orl/concepts/workspace) prior to audits for [findings](/orl/concepts/finding). They have the same query behavior as an audit, but are made available in the [template](/orl/concepts/template) context in the `collections` object as named keys. They can then be used in the audit query, to skip findings, or even to provide values to [remediation steps](/orl/concepts/remediation_steps). Here is an example: ```yaml type: Rule version: v1 ... spec: # Collect all azurerm_cosmosdb_account that have a geo_location block. # `collections.geo_locations` will be an array of all named matches of # the below audit query. collect: - name: geo_locations audit: | {{ aResource("azurerm_cosmosdb_account", aBlock("geo_location")) }} # Find all azurerm_cosmosdb_account that have automatic_failover_enabled not set to true audit: | {{ aResource("azurerm_cosmosdb_account", anAttributeValueNotEq("automatic_failover_enabled", "true")) }} # Skip findings where there can be no failover because there is only a single location. # See the section on Templating for more details. skip_finding: | let geo_locations = filter(flatten(collect(collections, "geo_locations.*")), { #.name == finding.name }) ?? []; len(geo_locations) < 2 ``` # Finding A finding is a single instance of a matched [audit](/orl/concepts/audit) query. These are what are loaded into [collections](/orl/concepts/collections) or made available to [remediation steps](/orl/concepts/remediation_steps). They are available in the [template](/orl/concepts/template) as objects of flattened key/value pairs where the name is the named match from the `audit` and the value is the string from the file in that location. ## Example Let's say we have the following YAML file: ```yaml key: value foo: bar bar: baz ``` And we have the following audit: ```yaml (block_node (block_mapping (block_mapping_pair (flow_node) @key (flow_node) @value ) ) ) ``` If used as a collection named `objects`, the object would look like this: ```yaml collections: objects: - key: key value: value - key: foo value: bar - key: bar value: baz ``` `objects` becomes an array of findings. Each finding has the capture group names as keys (i.e., `@key` -> `key`) and the value from the file(s) as strings. For remediation findings (i.e., `spec.audit`) it automatically iterates the findings and sets `findings` and `$` to that object. ```yaml # Loop 1 finding: {key: key, value: value} # Loop 2 finding: {key: foo, value: bar} # Loop 3 finding: {key: bar, value: baz} ``` # Languages An ORL language is what binds a [rule / ruleset](/orl/concepts/rules) to what files are loaded in the [workspace](/orl/concepts/workspace). The language defines the parser that is used to produce the AST. It also defines the helpers that are available in the [template](/orl/concepts/template). For a full list of languages use: `docker run --rm gombocai/orl:latest language` ```bash Supported languages: 1. bash 2. c 3. cloudformation-json 4. cloudformation-yaml ... ``` For details on each language's behavior, including the glob patterns used to load files, and template functions available run `docker run --rm gombocai/orl:latest language ` ```bash $ docker run --rm gombocai/orl:latest language terraform terraform Terraform files. Globs: *.tf *.hcl *.tfvars Template Functions: aBlock - Checks for a block with the given name. 'block_name', 'block_body', and 'block' are captured. aMissingAttribute - Checks for a missing attribute with the given name. 'key', and 'attribute' are captured. aMissingBlock - Checks for a missing block with the given name. 'block_name', and 'block' are captured. aModule - Checks for a module with the given name. The optional second argument is an s-expression that is used to match the module body. 'name', 'body', and 'module' are captured. aModuleWithSource - Checks for a module with the given name and source. The optional second argument is an s-expression that is used to match the module body. 'name', 'source_key', 'source_value', 'body', and 'module' are captured. aResource - Checks for a resource with the given type. The optional second argument is an s-expression that is used to match the resource body. 'type', 'name', 'body', and 'resource' are captured. aSubBlock - Checks for a sub-block with the given name. 'sub_block_name', 'sub_block_body', and 'sub_block' are captured. allResources - Checks for all resources. 'keyword', 'type', 'name', and 'body' are captured. anAttribute - Checks for an attribute with the given name. 'key', 'value', and 'attribute' are captured. anAttributeValue - Checks for an attribute with the given name. The second argument is an s-expression that is used to match the attribute value. 'key', 'value', and 'attribute' are captured. anAttributeValueEq - Checks for an attribute with the given name whose expression equals the given value. 'key', 'value', and 'attribute' are captured. anAttributeValueNotEq - Checks for an attribute with the given name whose expression does not equal the given value. 'key', 'value', and 'attribute' are captured. anEmptyBlock - Checks for an empty block with the given name. 'block_name', 'block_body', and 'block_end' are captured. anStringAttributeValue - Checks for an attribute with the given name whose expression is a string that equals the given value. 'key', 'value', and 'attribute' are captured. collect - Collects all the leaves from a given path. hasSubString - Checks if a string or array of strings contains a substring. semVerBump - Bumps a semantic version based on the location 'major', 'minor', or 'patch'. If no location is provided, 'patch' is used. semVerCmp - Compares two semantic versions. The operator can be '==', '>', '>=', '<', '<=', or '!='. truthy - Checks if a value is truthy. ``` # Remediation Steps Remediation steps tell ORL what to do to findings. They are in this form: ```yaml spec: remediation: - command: audit path: body flags: {} skip: "truthy statement" value: the value ``` ## `command` The commands are: * `audit` - Don't change any files, just log the `value` to the report * `create` - Add `value` to the bottom of a file only if no named match was found * `insert_after` - Insert `value` immediately after the `path` * `insert_before` - Insert `value` immediately before the `path` * `replace` - Replace the contents of the `path` with `value` * `remove` - Remove the `path` ## `flags` The following are global flags: * `indent` - Add this string before every line in `value` * `prefix` - Add this before `value` in the output * `suffix` - Add this after `value` in the output Additional flags are available per command. * `audit` * `level` - The log level. By default is "ERROR" which causes ORL to exit in a failure. "WARN", "INFO", and "DEBUG" can also be used. * `if_under` - Switch the audit from per finding to counting findings. Log a message if the count is strictly under this value. * `if_over` - Switch the audit from per finding to counting findings. Log a message if the count is strictly over this value. * `create` * `file` - The file name of where to put the new content * `insert_after` * `before_newline` - For parsers that include the newline in the capture group this preserves it * `replace` * `pattern` - Look for this substring pattern to replace, instead of replacing the entire string * `count` - Only replace N substrings. Only used if `pattern` is provided. ## `path` Path is the capture group name of a single capture group from the audit query. ## `value` Value is the actual string value to use. It is a [template](/orl/concepts/template). # Rule / Ruleset Rules are the single unit of work for ORL. Rulesets organize multiple rules so they are guaranteed to be executed together. ## Rule A rule performs a single [audit](/orl/concepts/audit), and remediates those findings. ```yaml type: Rule version: v1 metadata: name: my-sample-rule spec: language: terraform audit_language: ast audit: | {{ aResource("aws_s3_bucket" ) }} remediation: - command: remove path: resource ``` ### Ruleset A Ruleset is a collection of rules and an optional rule template. ```yaml type: Ruleset version: v1 metadata: name: my-sample-ruleset spec: template: language: terraform audit_language: ast rules: - name: first rule audit: | {{ aResource("aws_s3_bucket" ) }} remediation: - command: remove path: resource ``` # Rule-space All [rules and rulesets](/orl/concepts/rules) are loaded into a single rule-space which is then executed one rule at a time against the entire [workspace](/orl/concepts/workspace). The following rules apply. 1. All `Rule` and `Ruleset` objects need to have a unique name 2. `Ruleset`s are expanded to `Rule` by appending `_NNN` where `N` is the index of the rule in the ruleset (i.e., "\_000", "\_001", etc...) 3. All rules are executed in priority order (lowest first) 4. Rules that share the same priority are executed in alphabetical order by name 5. All Gomboc published rules have a priority between 1M and 10M # Template Templates can be used in Rules in the following places: 1. `spec.audit` 2. `spec.collect[].audit` 3. `spec.remediation[].skip` 4. `spec.remediation[].value` 5. `spec.skip_finding` The `spec.audit`, `spec.collect[].audit`, and `spec.remediation[].value` use pre-pass inline templating. An inline template is denoted by `{{ }}` and fully expanded and converted to a string value. Once all inline templates are fully expanded and the value is a single string, it is used. The `spec.skip_finding` and `spec.remediation[].skip` are evaluated as a complete template and then converted to a boolean value, as explained below. In these cases the `{{ }}` is optional. If the value evaluates to truthy then the remediation or remediation step is skipped. {% hint style="info" %} The values that can be extracted by a template depends on where in the Rule execution cycle the template is evaluated. For example, you can use collection values in an audit, but you cannot use audit findings in a collection. {% endhint %} ## Example ```yaml ... remediation: - command: "insert_after" path: "block" flags: prefix: "\n\n" skip: "vars.default.STAGE != 'PROD'" value: | resource "aws_s3_bucket_versioning" "{{ vars.default.STAGE }}_{{ vars.default.BUCKET_NAME }}_versioning" { bucket = aws_s3_bucket.{{ vars.default.BUCKET_NAME }}.id versioning_configuration { status = "Enabled" } } ``` In the above example let's say the variable `vars.default.STAGE` is "DEV". In this case the conditional would template to `'DEV' != 'PROD'` which would evaluate to true. This remediation would then be skipped. If `vars.default.STAGE` is `PROD` then it would evaluate to `'PROD' != 'PROD'` and thus be false and the value template would be expanded and then inserted after `block` within the AST. ## Language **Expr** is an expression language that is evaluated within the `{{ }}` blocks. There are a [set of built-in functions](https://expr-lang.org/docs/language-definition) for working with various data structures. And `{{ }}` blocks can span multiple lines. ### Handling Complex Templates Template can be very complex which can have strange results in the real world. Here are some suggestions for handling complex templates: 1. Use the Rule execution lifecycle to reduce template complexity as much as possible 2. Use the audit query's inline logic to reduce the collections and findings as much as possible 3. Don't rely on template logic `spec.remediation[].value`, instead use multiple steps and `spec.remediation[].skip` to skip the unwanted ones. 4. Use the `audit` remediation command with a `level` of `DEBUG` to print all the stages of the template evaluation. These will show up in the remediation report only if the log level is set to "DEBUG" (i.e., `-vvv`). #### Audit `$env` `$env` is a special variable that represents the entire environment of the template. This can be useful in debugging rules. ``` # rule spec: remediation: command: audit flags: level: DEBUG value: | {{ $env | keys() }} Everything: {{ $env }} ``` This will only show up if ORL log level is set to DEBUG. Otherwise nothing is shown, this can allow you to keep debug statements in the rules. ## Access Patterns Within templates, data can be as follows: * Path: `.[.]` - The path element cannot contain special characters, but can be either a key or an index (i.e., `item.0`). `?.` can be used to return nil (instead of error) if the path element is missing (i.e., `this.that?.foo` will still work if `that` is missing). * Index: `[]` - Index is number. This will error if the index is out of bounds * Key: `[""]` - Key can be any string. If the key is missing then `nil` is returned. ### Objects The high-level objects that currently exist: * `vars` - Each variable file is loaded here. See [variables](/orl/concepts/variables) for details. * `collections` - each named audit finding from each [`collect`](/orl/concepts/collections) is here. * `finding` (or `$`) - each named capture group from each [finding](/orl/concepts/finding). ## Skip Truthy Evaluation The `skip*` conditionals are special in that they are evaluated and then converted to a truthy value as follows. | Type | Value | Truthy | Comment | | ------ | --------------------------------- | ------ | ------------------------------------------------------------------------------- | | Array | `[]` | false | Empty array is false | | Bool | `false` | false | Unquoted false is false | | Map | `{}` | false | Empty map is false | | Nil | `nil` | false | Nil is false | | Number | `0` | false | 0 is false | | String | `""`, `"0"`, `"false"`, `""` | false | Empty string is false. Note, use "" because that is the value of `string(nil)`. | | Array | `[1,2,3]` | true | Non-empty array is true | | Bool | `true` | true | Unquoted true is true | | Map | `{1: false}` | true | Non-empty map is true | | Number | `-1` | true | any value not 0 is true | | String | `"true"`, `"this"` | true | Any non-empty string that isn't specifically false is true | ### Examples #### Simple variable expansion `vars.default.STAGE == 'PROD'` In this simple case, first, the variable is expanded. If missing an error is thrown and eval fails. If the value of `STAGE` is comparable to a string then the value is compared and a bool is returned. Otherwise an error is thrown. #### Complex expansion `vars.default.name in collect(collections, 'all_names.*.name')` In this case variable `vars.default.name` is extracted, and the full collection of `all_names` is reduced to an array of names. The `in` operator checks if the variable's value is within the list. That executes as follows: 1. `Jane in ["John", "Jake"]` 2. `false` 3. `false` is `false` #### Lazy Eval Because of the way items are evaluated all the following are equivalent: 1. `collect(collections, "any_names.*")` -> `[]` => `false` 2. `collections.any_names != {}` -> `{} != {}` -> `false` => `false` 3. `len(collections.any_names)` -> `len({})` -> `0` => `false` 4. `len(collections.any_names) > 0` -> `len({}) > 0` -> `0 > 0` -> `false` => `false` ## Custom Functions Expr has a ton of [built-in functions](https://expr-lang.org/docs/language-definition) that can be used. We have added additional global ones as below. Additionally, each [language](/orl/concepts/languages) can add additional functions. ### Collect `{{ collect(root, "path.*.to.collect") }}` -> `["array", "of", "leaves"]` This function takes a root object, and a path construct. It traverses the object looking for root items. `*` can be used to mean "any" key. ### hasSubString `{{ hasSubString("This and that", "This") }}` -> `true` `{{ hasSubString(["This", "that"], "this") }}` -> `false` `{{ ["This", "that"] | hasSubString("This") }}` -> `true` This function takes two arguments. The first argument can be a string or a slice of strings. In the string case it checks if the second argument is a substring of the first. In the case of slices it checks each element for substring. If any have the substring then it returns true. # Tests Rules can get complex, and might have to handle many complex cases. Luckily ORL has a test type for integration level testing and a `test` command that executes all the tests located in a directory. ## Test file The test file is basically a single invocation of `orl remediate` plus 2 possible comparisons: `remediated_workspace`, and `expected_report`. At least one of those comparisons is required per test. ```yaml type: Test version: v1 metadata: name: My Test # Tests are executed in priority order in the same way that rules are priority: 1 spec: # Each test loads a single rule-space from the defined path # relative to the test file rulespace: path/to/the/rules/to/test # Any number of named test cases can be defined. Each loads a # workspace, remediates, and checks the results cases: - name: First Case # Workspace and Rule-space are both filtered by this language language: terraform # Workspaces can be loaded from paths relative to this test file. # or can be defined as a single inline string. Only one is allowed. workspace: path: path/to/workspace/to/test # or # inline: | # my file # (Optional) A workspace to diff with the patched workspace against. # Any diffs = a failure. It can be a relative path, or a single # inline string. remediated_workspace: path: path/to/workspace/after/fix # or # inline: | # my patched file # (Optional) Expectations to test the report against. All fields # from the report can be checked. Omit items you don't care to check. # Everything defined is exact match expected_report: rules_applied: 5 changes: 1 findings: 1 fixes: 1 errors: [] rules: # This is the first rule we care about, not necessarily the first # rule that is in the report. - name: "test-rule" findings: 1 fixes: 1 changes: 1 errors: [] # Ordering is relative. This means that "test_rule" must be before # "third-rule", but there can be any number of rules executed # between these two rules. - name: third-rule findings: 0 ``` ## Recommended Directory Layout The recommended layout is as follows: ``` /my-rules /my-rule1 /workspace main.tf /expected-workspace main.tf terraform-rule.orl /my-rule2 /workspace main.yaml /expected-workspace main.yaml cfn-rule.orl /my-rule3 /workspace main.py /expected-workspace main.py python-rule.orl test1.orl test2.orl test3.orl ``` This directory structure contains 3 rules. Each rule has a workspace to remediate, and the expected results of the remediation for comparison. It also contains the actual ORL rule. Up a level are all the test files so that a single run or `orl test /my-rules` can execute all the tests. # Variables Variables provide useful context in that they allow [rules](/orl/concepts/rules) behavior to be generalized. The Variables objects (type: Variables) are loaded into variables context and namespaced by the `metadata.name`. Multiple files can have the same namespaces, in which case they are merged with the one having the higher priority overwriting the lower priority ones (last one wins). The Variable type object is used to create named variable spaces: ```yaml type: Variables version: v1 metadata: name: config # variable namespace priority: 5 data: # Can be accessed via `{{ vars.config.ENV }}` ENV: staging ``` ## Use in Rules Variables are referenced using the vars context in the `collect`, `audit`, and `remediation[].value` templates of a Rule (i.e., `{{ vars.. }}`). ```yaml type: Rule version: v1 ... spec: ... remediation: - command: replace path: body value: {{ vars.lms_key.arn }} ``` ## Loading variables Variables need to be explicitly loaded via the `--vars` option. # Workspace An ORL workspace is a single directory of files of a given language. ORL will load those files, and parse them based on the `--language` option provided. # Agent Skills Connect Gomboc to your preferred coding agent and use ORL-powered workflows directly from your development environment — scan code for security and compliance issues, apply fixes, author ORL rules, and publish them to the Gomboc Rules Service. Gomboc provides agent skills in two editions: | Edition | Guide | Best for | | -------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | **Community** | [Gomboc Community Skills](/orl/agent-skills/gomboc-community-skills) | Public, self-serve usage with Claude Code | | **Enterprise** | [Gomboc Enterprise Skills](/orl/agent-skills/gomboc-enterprise-skills) | Gomboc Enterprise customers using Claude Code, Gemini CLI, OpenAI Codex, or Cursor | There are also [examples](/orl/agent-skills/examples) for using these skills: * [Inline comment rule](/orl/agent-skills/examples/inline-comment-rule) * [Inline value with comment rule](/orl/agent-skills/examples/inline-value-with-comment-rule) * [Multiple environment rule](/orl/agent-skills/examples/multiple-environment-rule) * [Policy-as-Code](/orl/agent-skills/examples/policy-as-code-rule) * [User variables rule](/orl/agent-skills/examples/user-variables-rule) {% hint style="info" %} **How the Enterprise plugin is distributed:** Gomboc Enterprise customers receive the plugin as a zip package shared via Google Drive (your Gomboc contact will invite you and share the link). Extract the zip once — the same folder works for all four supported agent runtimes. {% endhint %} ## Access levels ### Community The community plugin is public and designed for open self-serve usage. Install it from the public [Gomboc-AI/gomboc-community-skills](https://github.com/Gomboc-AI/gomboc-community-skills) repository. It is appropriate if you want to try Gomboc agent workflows without private enterprise access. ### Enterprise The enterprise plugin is private and designed for Gomboc Enterprise customers. It includes enterprise-focused skills, token-based access to Gomboc services, and workflows for remediation, rule authoring, and rule publishing. The plugin package is shared privately via Google Drive. {% hint style="info" %} Interested in Enterprise access? Contact [Support](/support). {% endhint %} ## Prerequisites Before using Gomboc agent skills, make sure you have: * **Access to the skills** * Community — install the public `Gomboc-AI/gomboc-community-skills` plugin (see [Gomboc Community Skills](/orl/agent-skills/gomboc-community-skills)) * Enterprise — receive the plugin zip from your Gomboc contact via Google Drive (see [Gomboc Enterprise Skills](/orl/agent-skills/gomboc-enterprise-skills) and the per-agent install guides below) * A valid **`GOMBOC_API_TOKEN`** — see [Generate A Personal Access Token](/getting-started/generate-a-personal-access-token) * **Docker** installed and running locally (Docker Desktop or Docker Engine) * Your **target agent** installed and configured: Claude Code, OpenAI Codex, Gemini CLI, or Cursor The skills run [ORL](/orl) through the official Docker container (`gombocai/orl`) when needed. If a local `orl` executable is already on your `PATH`, the agent may use it, but the supported customer path is Docker-based. ## Available guides ### Community * [Gomboc Community Skills](/orl/agent-skills/gomboc-community-skills) — install, commands, and usage for Claude Code ### Enterprise * [Gomboc Enterprise Skills overview](/orl/agent-skills/gomboc-enterprise-skills) — commands, skills, and workflows * [Claude (Enterprise)](/orl/agent-skills/gomboc-enterprise-skills/claude-enterprise) * [Gemini (Enterprise)](/orl/agent-skills/gomboc-enterprise-skills/gemini-enterprise) * [OpenAI Codex (Enterprise)](/orl/agent-skills/gomboc-enterprise-skills/codex-enterprise) * [Cursor (Enterprise)](/orl/agent-skills/gomboc-enterprise-skills/cursor-enterprise) * [Policy Enforcement Loop](/orl/agent-skills/gomboc-enterprise-skills/policy-enforcement-loop) * [CSPM Triage Loop](/orl/agent-skills/gomboc-enterprise-skills/cspm-triage-loop) # Examples Examples of using ORL with [gomboc-community-skills](/orl/agent-skills/gomboc-community-skills) or [gomboc-enterprise-skills](/orl/agent-skills/gomboc-enterprise-skills). Community examples work in Enterprise; Enterprise-only examples are marked. * [Inline comment rule](/orl/agent-skills/examples/inline-comment-rule) * [Inline value with comment rule](/orl/agent-skills/examples/inline-value-with-comment-rule) * [Maintaining rules](/orl/agent-skills/examples/maintaining-rules) (Enterprise-only) * [Multiple environment rule](/orl/agent-skills/examples/multiple-environment-rule) * [Policy-as-Code](/orl/agent-skills/examples/policy-as-code-rule) * [User variables rule](/orl/agent-skills/examples/user-variables-rule) # Inline Comment Insert a comment listing valid values when the correct fix is ambiguous—for example, when several AMIs are acceptable. ## Prompt The following can be used with the [gomboc-enterprise-skills](/orl/agent-skills/gomboc-enterprise-skills). ```markdown /gomboc:fix I want to create an ORL rule that checks that the AMI used for EC2 instances or launch templates is one of the following: - ami-0a1b2c3d4e5f67890 - ami-0987654321fedcba0 - ami-0ff11223344556677 - ami-0abcdef1234567890 - ami-0123456789abcdef0 If the value is not one of those, then add a comment before the AMI attribute listing the valid values. **Important**: The rule should be idempotent. When testing, make sure to run the test on the remediated workspace to ensure it is unchanged on the second run. ``` {% hint style="info" %} Use `/gomboc-community:fix` if you have the [gomboc-community-skills](/orl/agent-skills/gomboc-community-skills) installed. {% endhint %} For this type of rule is important to tell the `fix` that rule needs to be idempotent becuase the fix and check are different. ORL doesn't normally need this flag since it patches what it checks and idempotency is built in; which is not the case with this type of rule. ## Rule Output Example ```yaml --- type: Ruleset version: v1 metadata: name: "ensure-approved-ami-for-ec2-and-launch-template" display_name: "Ensure EC2 instances and launch templates use an approved AMI" description: | ## Description Ensures that aws_instance and aws_launch_template resources reference only approved AMI IDs. When a non-approved AMI is detected, a comment listing the valid AMIs is inserted immediately before the attribute to guide the author. spec: template: language: terraform audit_language: ast rules: - name: ec2-instance-ami-must-be-approved audit: | (block (identifier) @_keyword (#eq? @_keyword "resource") (string_lit (template_literal) @_type (#eq? @_type "aws_instance")) (string_lit (template_literal) @name) (body (attribute (identifier) @_key (#eq? @_key "ami") (expression (literal_value (string_lit (template_literal) @value ) ) ) ) @attribute ) @body ) @resource skip_finding: | ($.value in ["ami-0a1b2c3d4e5f67890", "ami-0987654321fedcba0", "ami-0ff11223344556677", "ami-0abcdef1234567890", "ami-0123456789abcdef0"]) or ($.resource matches "# Valid AMIs:") remediation: - command: insert_before path: attribute flags: suffix: "\n " value: "# Valid AMIs: ami-0a1b2c3d4e5f67890, ami-0987654321fedcba0, ami-0ff11223344556677, ami-0abcdef1234567890, ami-0123456789abcdef0" - name: launch-template-image-id-must-be-approved audit: | (block (identifier) @_keyword (#eq? @_keyword "resource") (string_lit (template_literal) @_type (#eq? @_type "aws_launch_template")) (string_lit (template_literal) @name) (body (attribute (identifier) @_key (#eq? @_key "image_id") (expression (literal_value (string_lit (template_literal) @value ) ) ) ) @attribute ) @body ) @resource skip_finding: | ($.value in ["ami-0a1b2c3d4e5f67890", "ami-0987654321fedcba0", "ami-0ff11223344556677", "ami-0abcdef1234567890", "ami-0123456789abcdef0"]) or ($.resource matches "# Valid AMIs:") remediation: - command: insert_before path: attribute flags: suffix: "\n " value: "# Valid AMIs: ami-0a1b2c3d4e5f67890, ami-0987654321fedcba0, ami-0ff11223344556677, ami-0abcdef1234567890, ami-0123456789abcdef0" ``` Each rule matches one resource type and its AMI attribute. `skip_finding` passes when the value is valid or the comment is already present; otherwise, the comment is inserted before the attribute. # Inline Value with Comment Set the attribute to a default value and add an inline comment listing all valid options. Useful when engineers should see alternatives without leaving the file. ## Prompt The following can be used with the [gomboc-enterprise-skills](/orl/agent-skills/gomboc-enterprise-skills). ```markdown /gomboc:fix I want to create an ORL rule that checks that the AMI used for EC2 instances or launch configurations is one of the following: - ami-0a1b2c3d4e5f67890 - ami-0987654321fedcba0 - ami-0ff11223344556677 - ami-0abcdef1234567890 - ami-0123456789abcdef0 If the value is not one of those, then use the first one listed as the value. Then add an inline comment after the value with all the values pipe-separated (`|`). ``` {% hint style="info" %} Use `/gomboc-community:fix` if you have the [gomboc-community-skills](/orl/agent-skills/gomboc-community-skills) installed. {% endhint %} Specify both the default value and the comment format (pipe-separated list). ## Rule Output Example ```yaml --- type: Ruleset version: v1 metadata: name: enforce-approved-ami description: | Ensures that aws_instance and aws_launch_configuration resources use only approved AMI IDs. spec: template: language: terraform audit_language: ast rules: - name: enforce-approved-ami-aws-instance audit: | {{ aResource("aws_instance", anAttributeValue("ami", "(#not-match? @value \"ami-0a1b2c3d4e5f67890|ami-0987654321fedcba0|ami-0ff11223344556677|ami-0abcdef1234567890|ami-0123456789abcdef0\")")) }} remediation: - command: replace path: value value: '"ami-0a1b2c3d4e5f67890" # ami-0a1b2c3d4e5f67890 | ami-0987654321fedcba0 | ami-0ff11223344556677 | ami-0abcdef1234567890 | ami-0123456789abcdef0' - name: enforce-approved-ami-aws-launch-configuration audit: | {{ aResource("aws_launch_configuration", anAttributeValue("image_id", "(#not-match? @value \"ami-0a1b2c3d4e5f67890|ami-0987654321fedcba0|ami-0ff11223344556677|ami-0abcdef1234567890|ami-0123456789abcdef0\")")) }} remediation: - command: replace path: value value: '"ami-0a1b2c3d4e5f67890" # ami-0a1b2c3d4e5f67890 | ami-0987654321fedcba0 | ami-0ff11223344556677 | ami-0abcdef1234567890 | ami-0123456789abcdef0' ``` Each rule audits one resource type. Invalid AMIs are replaced with the first allowlisted value and an inline comment showing every option. # Maintaining Rules {% hint style="warning" %} This is only supported with [gomboc-enterprise-skills](/orl/agent-skills/gomboc-enterprise-skills). {% endhint %} Keep a rule's allowlist up to date; for example, rotating pre-approved AMIs monthly. Make the base rule easy to patch, create an ORL patch rule driven by a variable, then run a periodic workflow to apply updates. ## Prerequisites One-time setup for the maintenance loop. ### Step 1: Patchable Rule Start from the [policy-as-code](/orl/agent-skills/examples/policy-as-code-rule) example and add this to the prompt so the generated rule is easy to update later: ```markdown **Important**: I will need to update the list of AMIs frequently, so make sure the rule is easy to update later. ```
Modified Rule The modified rule matches the policy-as-code example, with the AMI list centralized in `skip_finding` for easier patching. ```yaml --- type: Ruleset version: v1 metadata: name: "ensure-ami-is-in-approved-allowlist" display_name: "Ensure AMI is from the approved allowlist" description: | ## Description Ensure that EC2 instances, launch configurations, and launch templates use only approved AMIs. Resources referencing an AMI that is not in the allowlist will be flagged with an audit error but will not be automatically remediated. annotations: contributed-by: user provider: AWS resource: aws_instance, aws_launch_configuration, aws_launch_template spec: template: language: terraform audit_language: ast skip_finding: | let approved_amis = ["ami-0a1b2c3d4e5f67890", "ami-0987654321fedcba0", "ami-0ff11223344556677", "ami-0abcdef1234567890", "ami-0123456789abcdef0"]; let ami = trim($.value, "\""); !hasPrefix($.value, "\"") || ami in approved_amis remediation: - command: audit flags: level: ERROR value: "(PaC) The AMI is not in the approved allowlist. Valid AMIs are: ami-0a1b2c3d4e5f67890, ami-0987654321fedcba0, ami-0ff11223344556677, ami-0abcdef1234567890, ami-0123456789abcdef0" rules: - name: ensure-aws_instance-uses-approved-ami audit: | {{ aResource("aws_instance", anAttribute("ami")) }} - name: ensure-aws_launch_template-uses-approved-ami audit: | {{ aResource("aws_launch_template", anAttribute("image_id")) }} - name: ensure-aws_launch_configuration-uses-approved-ami audit: | {{ aResource("aws_launch_configuration", anAttribute("image_id")) }} ```
### Step 2: Generate the Patch Generate a patch rule that updates the allowlist from a variable: ```markdown /gomboc:fix I have an existing rule `ensure-ami-is-in-approved-allowlist` that enforces an AMI allowlist. I want to create a new rule that can update that existing rule using the fact that `orl` is a supported language. The new rule should use the `vars.custom.ami_ids` variable as a comma-separated list of AMIs that should be used. This should replace the AMI list in `skip_finding` as an EXPR-style list (see existing rule format), as well as the remediation value as human-readable text. **Important**: The rule should skip itself (using `skip_expression`) if the variable is not set. If skipped the `skip_reason` should be in the form "Variable 'vars.custom.ami_ids' is not defined. It should be the complete list of valid AMIs". ``` {% hint style="warning" %} This prompt is simplified for demo purposes. Depending on how you set up your update workflow, you may need to add additional protections like only patching rules by name or annotation. {% endhint %} #### Rule Output Example ```yaml --- type: Ruleset version: v1 metadata: name: orl/ensure-ami-allowlist-from-custom-variable display_name: "Sync AMI Allowlist in ORL Rules from vars.custom.ami_ids" description: | ## Description Updates an ORL rule's approved AMI allowlist to use `vars.custom.ami_ids` (a comma-separated list of approved AMI IDs) instead of a hardcoded list. Patches two locations in the target ORL rule file: 1. `spec.template.skip_finding` — rewrites the `let approved_amis = [...]` line as an Expr list derived from vars.custom.ami_ids. 2. `spec.template.remediation[].value` — rewrites the human-readable AMI list at the end of the audit message with the value of vars.custom.ami_ids. The rule skips itself entirely when `vars.custom.ami_ids` is not defined. annotations: contributed-by: in-context gomboc-ai/remediation-assessment: FULL_REMEDIATION gomboc-ai/description-plain: "Replaces hardcoded AMI allowlists in ORL rules with the value from vars.custom.ami_ids." priority: 100 spec: template: language: orl audit_language: ast skip_expression: "vars?.custom?.ami_ids == nil || vars.custom.ami_ids == \"\"" skip_reason: "Variable 'vars.custom.ami_ids' is not defined. It should be the complete list of valid AMIs" rules: - name: ensure-skip-finding-uses-ami-ids-from-variable audit: | (block_mapping_pair key: (flow_node (plain_scalar (string_scalar) @_key)) value: (block_node (block_scalar) @skip_finding_val) (#eq? @_key "skip_finding") (#match? @skip_finding_val "let approved_amis") ) remediation: - command: replace path: skip_finding_val value: |- | let approved_amis = {{ "[\"" + join(map(split(vars.custom.ami_ids, ","), trim(#, " ")), "\", \"") + "\"]" }}; let ami = trim($.value, "\""); !hasPrefix($.value, "\"") || ami in approved_amis - name: ensure-remediation-value-uses-ami-ids-from-variable audit: | (block_mapping_pair key: (flow_node (plain_scalar (string_scalar) @_key)) value: (flow_node (double_quote_scalar) @remediation_val) (#eq? @_key "value") (#match? @remediation_val "ami-[0-9a-f]") ) remediation: - command: replace path: remediation_val value: '"(PaC) The AMI is not in the approved allowlist. Valid AMIs are: {{ vars.custom.ami_ids }}"' ``` ## Update Workflow The update workflow consists of the steps that are run repeatedly when the underlying rule needs to be updated. ### Step 1: Pull updated values Filter to images tagged `Approved=true`. This command returns a comma-separated list of image IDs: ```bash aws ec2 describe-images --owners self --filters "Name=tag:Approved,Values=true" --query "join(',', Images[*].ImageId)" --output text ``` ### Step 2: Write the variable Take the string from the first step and replace `` in the template below. This file should be placed in the same directory as the file you will be patching. We will use `./rules` for this. ```yaml --- type: Variables version: v1 metadata: name: custom description: Custom variables for AMI allowlist management data: ami_ids: "" ``` ### Step 3: Pull Pull both rules from the Rules Service: ```markdown /gomboc:orl rules pull -o rules --search '(eq $.name "ensure-ami-is-in-approved-allowlist")' /gomboc:orl rules pull -o patches --search '(eq $.name "orl/ensure-ami-allowlist-from-custom-variable")' ``` If you store the rules in the workflow repository instead, skip this step. ### Step 4: Patch Now we should have the rule to be patched and the variables in `./rules`, and the patch in `./patches`. To patch the rules, use the following prompt: ```markdown /gomboc:orl-remediation-expert --language orl --rulespace ./patches ./rules ``` This tells ORL to patch rules in `./rules` using rules in `./patches`. Variables are automatically loaded from `./rules`. ### Step 5: Publish With the rule updated, run the following prompt: ```markdown /gomboc:orl publish ./rules ``` This publishes the patched rule to the Rules Service. # Multiple Environments Apply different AMI allowlists per environment in a single rule. This example uses `vars.custom.account_id` to select Prod, Staging, or Dev. ## Prompt The following can be used with the [gomboc-enterprise-skills](/orl/agent-skills/gomboc-enterprise-skills). ```markdown /gomboc:fix I want to create an ORL rule that checks that the AMI used for EC2 instances, launch configurations, or launch templates is one of the following AMIs, based on environment: - Prod (129483756201): - ami-0a1b2c3d4e5f67890 - ami-0987654321fedcba0 - ami-0ff11223344556677 - ami-0abcdef1234567890 - ami-0123456789abcdef0 - Staging (884920193475): - ami-0a1b2c3d4e5f6g7h8 - ami-1234567890abcdef0 - ami-9876543210fedcba9 - ami-z9y8x7w6v5u4t3s2r - ami-f0e1d2c3b4a596877 - Dev (340912837456): - ami-0a1b2c3d4e5f6g7h8 - ami-08e1a47b2c9f3d6a1 - ami-0c5f8d2e1b4a79362 - ami-0fb92e1d7c4b3a850 - ami-0d6a2f4c1e9b7a3d8 Do not remediate. Audit only, using an error message that lists the valid AMIs for the detected environment. **Important**: The account ID SHOULD be provided via `vars.custom.account_id`. If that is not defined then assume `Prod`. ``` {% hint style="info" %} Use `/gomboc-community:fix` if you have the [gomboc-community-skills](/orl/agent-skills/gomboc-community-skills) installed. {% endhint %} Include the full allowlist for each environment and specify a default (Prod here) when `vars.custom.account_id` is unset. ## Rule Output Example ```yaml --- type: Ruleset version: v1 metadata: name: gomboc-ai/terraform/aws/approved-ami-by-environment display_name: "Approved AMI by Environment" description: |- Audits aws_instance, aws_launch_configuration, and aws_launch_template to ensure the AMI ID is from the approved list for the environment determined by vars.custom.account_id. Defaults to Prod (129483756201) when vars.custom.account_id is not set. spec: template: language: terraform audit_language: ast rules: - name: approved-ami-aws-instance audit: | {{ aResource("aws_instance", anAttribute("ami")) }} skip_finding: | let account_id = vars.custom?.account_id; let ami = $.value | trim("\""); (account_id == nil || account_id == "129483756201") && ami in ["ami-0a1b2c3d4e5f67890", "ami-0987654321fedcba0", "ami-0ff11223344556677", "ami-0abcdef1234567890", "ami-0123456789abcdef0"] || account_id == "884920193475" && ami in ["ami-0a1b2c3d4e5f6g7h8", "ami-1234567890abcdef0", "ami-9876543210fedcba9", "ami-z9y8x7w6v5u4t3s2r", "ami-f0e1d2c3b4a596877"] || account_id == "340912837456" && ami in ["ami-0a1b2c3d4e5f6g7h8", "ami-08e1a47b2c9f3d6a1", "ami-0c5f8d2e1b4a79362", "ami-0fb92e1d7c4b3a850", "ami-0d6a2f4c1e9b7a3d8"] remediation: - command: audit flags: level: ERROR value: |- aws_instance "{{ $.name | trim("\"") }}" uses AMI "{{ $.value | trim("\"") }}" which is not approved for the detected environment (account_id: {{ vars.custom?.account_id ?? "129483756201" }}). Approved AMIs for Prod (129483756201): ami-0a1b2c3d4e5f67890, ami-0987654321fedcba0, ami-0ff11223344556677, ami-0abcdef1234567890, ami-0123456789abcdef0 Approved AMIs for Staging (884920193475): ami-0a1b2c3d4e5f6g7h8, ami-1234567890abcdef0, ami-9876543210fedcba9, ami-z9y8x7w6v5u4t3s2r, ami-f0e1d2c3b4a596877 Approved AMIs for Dev (340912837456): ami-0a1b2c3d4e5f6g7h8, ami-08e1a47b2c9f3d6a1, ami-0c5f8d2e1b4a79362, ami-0fb92e1d7c4b3a850, ami-0d6a2f4c1e9b7a3d8 - name: approved-ami-launch-configuration audit: | {{ aResource("aws_launch_configuration", anAttribute("image_id")) }} skip_finding: | let account_id = vars.custom?.account_id; let ami = $.value | trim("\""); (account_id == nil || account_id == "129483756201") && ami in ["ami-0a1b2c3d4e5f67890", "ami-0987654321fedcba0", "ami-0ff11223344556677", "ami-0abcdef1234567890", "ami-0123456789abcdef0"] || account_id == "884920193475" && ami in ["ami-0a1b2c3d4e5f6g7h8", "ami-1234567890abcdef0", "ami-9876543210fedcba9", "ami-z9y8x7w6v5u4t3s2r", "ami-f0e1d2c3b4a596877"] || account_id == "340912837456" && ami in ["ami-0a1b2c3d4e5f6g7h8", "ami-08e1a47b2c9f3d6a1", "ami-0c5f8d2e1b4a79362", "ami-0fb92e1d7c4b3a850", "ami-0d6a2f4c1e9b7a3d8"] remediation: - command: audit flags: level: ERROR value: |- aws_launch_configuration "{{ $.name | trim("\"") }}" uses image_id "{{ $.value | trim("\"") }}" which is not approved for the detected environment (account_id: {{ vars.custom?.account_id ?? "129483756201" }}). Approved AMIs for Prod (129483756201): ami-0a1b2c3d4e5f67890, ami-0987654321fedcba0, ami-0ff11223344556677, ami-0abcdef1234567890, ami-0123456789abcdef0 Approved AMIs for Staging (884920193475): ami-0a1b2c3d4e5f6g7h8, ami-1234567890abcdef0, ami-9876543210fedcba9, ami-z9y8x7w6v5u4t3s2r, ami-f0e1d2c3b4a596877 Approved AMIs for Dev (340912837456): ami-0a1b2c3d4e5f6g7h8, ami-08e1a47b2c9f3d6a1, ami-0c5f8d2e1b4a79362, ami-0fb92e1d7c4b3a850, ami-0d6a2f4c1e9b7a3d8 - name: approved-ami-launch-template audit: | {{ aResource("aws_launch_template", anAttribute("image_id")) }} skip_finding: | let account_id = vars.custom?.account_id; let ami = $.value | trim("\""); (account_id == nil || account_id == "129483756201") && ami in ["ami-0a1b2c3d4e5f67890", "ami-0987654321fedcba0", "ami-0ff11223344556677", "ami-0abcdef1234567890", "ami-0123456789abcdef0"] || account_id == "884920193475" && ami in ["ami-0a1b2c3d4e5f6g7h8", "ami-1234567890abcdef0", "ami-9876543210fedcba9", "ami-z9y8x7w6v5u4t3s2r", "ami-f0e1d2c3b4a596877"] || account_id == "340912837456" && ami in ["ami-0a1b2c3d4e5f6g7h8", "ami-08e1a47b2c9f3d6a1", "ami-0c5f8d2e1b4a79362", "ami-0fb92e1d7c4b3a850", "ami-0d6a2f4c1e9b7a3d8"] remediation: - command: audit flags: level: ERROR value: |- aws_launch_template "{{ $.name | trim("\"") }}" uses image_id "{{ $.value | trim("\"") }}" which is not approved for the detected environment (account_id: {{ vars.custom?.account_id ?? "129483756201" }}). Approved AMIs for Prod (129483756201): ami-0a1b2c3d4e5f67890, ami-0987654321fedcba0, ami-0ff11223344556677, ami-0abcdef1234567890, ami-0123456789abcdef0 Approved AMIs for Staging (884920193475): ami-0a1b2c3d4e5f6g7h8, ami-1234567890abcdef0, ami-9876543210fedcba9, ami-z9y8x7w6v5u4t3s2r, ami-f0e1d2c3b4a596877 Approved AMIs for Dev (340912837456): ami-0a1b2c3d4e5f6g7h8, ami-08e1a47b2c9f3d6a1, ami-0c5f8d2e1b4a79362, ami-0fb92e1d7c4b3a850, ami-0d6a2f4c1e9b7a3d8 ``` The ruleset repeats the same environment logic for each resource type that accepts an AMI. `skip_finding` selects the allowlist from `vars.custom.account_id` (defaulting to Prod). The audit message lists valid AMIs for all environments so reviewers can see every option. # Policy-as-Code Use ORL as Policy-as-Code (PaC) by setting remediation to `audit` with `level: ERROR`. ORL then exits with a non-zero status when a finding is reported. ## Prompt The following can be used with the [gomboc-enterprise-skills](/orl/agent-skills/gomboc-enterprise-skills). ```markdown /gomboc:fix I want to create an ORL rule or ruleset that checks that the AMI used for EC2 instances, launch configurations, or launch templates is one of the following: - ami-0a1b2c3d4e5f67890 - ami-0987654321fedcba0 - ami-0ff11223344556677 - ami-0abcdef1234567890 - ami-0123456789abcdef0 The rule should not attempt to remediate the finding. It should simply audit using an error message that explains what the valid AMIs are. The message should be prefixed with "(PaC)" ``` {% hint style="info" %} Use `/gomboc-community:fix` if you have the [gomboc-community-skills](/orl/agent-skills/gomboc-community-skills) installed. {% endhint %} Tell the agent not to remediate because by default `fix` attempts to create a code change rule ## Rule Output Example ```yaml --- type: Ruleset version: v1 metadata: name: "ensure-ami-is-in-approved-allowlist" display_name: "Ensure AMI is from the approved allowlist" description: | ## Description Ensure that EC2 instances, launch configurations, and launch templates use only approved AMIs. Resources referencing an AMI that is not in the allowlist will be flagged with an audit error but will not be automatically remediated. annotations: contributed-by: user provider: AWS resource: aws_instance, aws_launch_configuration, aws_launch_template spec: template: language: terraform audit_language: ast rules: - name: "ensure-aws_instance-ami-is-in-allowlist" audit: | {{ aResource("aws_instance", anAttribute("ami")) }} skip_finding: | hasSubString($.value, "ami-0a1b2c3d4e5f67890") || hasSubString($.value, "ami-0987654321fedcba0") || hasSubString($.value, "ami-0ff11223344556677") || hasSubString($.value, "ami-0abcdef1234567890") || hasSubString($.value, "ami-0123456789abcdef0") remediation: - command: audit flags: level: ERROR value: "(PaC) The AMI is not in the approved allowlist. Valid AMIs are: ami-0a1b2c3d4e5f67890, ami-0987654321fedcba0, ami-0ff11223344556677, ami-0abcdef1234567890, ami-0123456789abcdef0" - name: "ensure-aws_launch_configuration-image_id-is-in-allowlist" audit: | {{ aResource("aws_launch_configuration", anAttribute("image_id")) }} skip_finding: | hasSubString($.value, "ami-0a1b2c3d4e5f67890") || hasSubString($.value, "ami-0987654321fedcba0") || hasSubString($.value, "ami-0ff11223344556677") || hasSubString($.value, "ami-0abcdef1234567890") || hasSubString($.value, "ami-0123456789abcdef0") remediation: - command: audit flags: level: ERROR value: "(PaC) The AMI is not in the approved allowlist. Valid AMIs are: ami-0a1b2c3d4e5f67890, ami-0987654321fedcba0, ami-0ff11223344556677, ami-0abcdef1234567890, ami-0123456789abcdef0" - name: "ensure-aws_launch_template-image_id-is-in-allowlist" audit: | {{ aResource("aws_launch_template", anAttribute("image_id")) }} skip_finding: | hasSubString($.value, "ami-0a1b2c3d4e5f67890") || hasSubString($.value, "ami-0987654321fedcba0") || hasSubString($.value, "ami-0ff11223344556677") || hasSubString($.value, "ami-0abcdef1234567890") || hasSubString($.value, "ami-0123456789abcdef0") remediation: - command: audit flags: level: ERROR value: "(PaC) The AMI is not in the approved allowlist. Valid AMIs are: ami-0a1b2c3d4e5f67890, ami-0987654321fedcba0, ami-0ff11223344556677, ami-0abcdef1234567890, ami-0123456789abcdef0" ``` `skip_finding` skips compliant values. Non-compliant values trigger an audit error with the valid AMI list. # User Variables Pass variables at remediation time and reference them in audit logic, skip conditions, or remediation values. This example sets the AMI from `vars.custom.ami_id`. ## Prompt The following can be used with the [gomboc-enterprise-skills](/orl/agent-skills/gomboc-enterprise-skills). ```markdown /gomboc:fix I want to create an ORL rule that checks that the AMI used for EC2 instances, launch configurations, or launch templates is one of the following: - ami-0a1b2c3d4e5f67890 - ami-0987654321fedcba0 - ami-0ff11223344556677 - ami-0abcdef1234567890 - ami-0123456789abcdef0 The rule should use the variable `vars.custom.ami_id` to set the value. The rule should skip itself (using `skip_expression`) if the variable is not set. If skipped the `skip_reason` should be in the form "Variable 'vars.custom.ami_id' is not defined. Set it to one of: ". ``` {% hint style="info" %} Use `/gomboc-community:fix` if you have the [gomboc-community-skills](/orl/agent-skills/gomboc-community-skills) installed. {% endhint %} Name the variable and define behavior when it is missing (here, skip the rule with a clear reason). ## Rule Output Example ```yaml # yaml-language-server: $schema=../schema/ruleset.json --- type: Ruleset version: v1 metadata: name: ensure-approved-ami-is-used display_name: Ensure EC2 instances and auto-scaling groups use an approved AMI description: | Ensures that all aws_instance, aws_launch_configuration, and aws_launch_template resources use one of the approved AMI IDs, supplied via vars.custom.ami_id. skip_expression: "vars.custom?.ami_id == nil" skip_reason: "Variable 'vars.custom.ami_id' is not defined. Set it to one of: ami-0a1b2c3d4e5f67890, ami-0987654321fedcba0, ami-0ff11223344556677, ami-0abcdef1234567890, ami-0123456789abcdef0" spec: template: language: terraform audit_language: ast rules: - name: ensure-aws_instance-ami-is-approved audit: | {{ aResource("aws_instance", anAttribute("ami")) }} skip_finding: "trim($.value, \"\\\"\" ) == vars.custom.ami_id" remediation: - command: replace path: value value: "\"{{ vars.custom.ami_id }}\"" - name: ensure-aws_launch_configuration-image_id-is-approved audit: | {{ aResource("aws_launch_configuration", anAttribute("image_id")) }} skip_finding: "trim($.value, \"\\\"\" ) == vars.custom.ami_id" remediation: - command: replace path: value value: "\"{{ vars.custom.ami_id }}\"" - name: ensure-aws_launch_template-image_id-is-approved audit: | {{ aResource("aws_launch_template", anAttribute("image_id")) }} skip_finding: "trim($.value, \"\\\"\" ) == vars.custom.ami_id" remediation: - command: replace path: value value: "\"{{ vars.custom.ami_id }}\"" ``` Each rule audits one resource type. Values that do not match `vars.custom.ami_id` are replaced with the variable value. # Gomboc Community Skills The [Gomboc Community Skills](https://github.com/Gomboc-AI/gomboc-community-skills) plugin brings ORL (Open Remediation Language) workflows into [Claude Code](https://claude.com/claude-code). Use it to scan source code for security and compliance issues, apply deterministic fixes, and create reusable ORL rules — all from your terminal. Supported languages include Terraform, HCL/Terragrunt, CloudFormation (YAML and JSON), Bicep, Dockerfile, Kubernetes, and Python. ## Prerequisites Before installing the plugin, make sure you have: * [Claude Code](https://claude.com/claude-code) CLI installed * [Docker](https://docs.docker.com/get-docker/) installed and running * The ORL Docker image pulled locally: ```bash docker pull gombocai/orl ``` * (Optional) A [Gomboc Personal Access Token](/getting-started/generate-a-personal-access-token) if you plan to push rules to the Gomboc Rules Service ## Installation You can install the plugin from the terminal or through the Claude Code plugin browser. ### CLI ```bash claude plugin marketplace add https://github.com/Gomboc-AI/gomboc-community-skills.git claude plugin install gomboc-community@gomboc-community-marketplace ``` ### Claude Code plugin browser 1. Start Claude Code 2. Run the `/plugin` command
3. Select **Add Marketplace**
4. Enter the URL for [gomboc-community-skills](https://github.com/Gomboc-AI/gomboc-community-skills): ``` https://github.com/Gomboc-AI/gomboc-community-skills ```
5. Select the **gomboc-community-marketplace**
6. Select **Browse Plugins**
7. Select the **Gomboc Community** plugin
### Plugin updates If you have already installed the plugin, turn on auto-updates or manually update the marketplace to get the latest version.
## Commands The plugin exposes three slash commands for common workflows. ### `/fix` — Scan and fix code Scan source code for security anti-patterns and compliance gaps using the ORL classification policy corpus, then apply fixes using existing rules or by generating new ones on the fly. ``` /gomboc-community:fix main.tf — check encryption /gomboc-community:fix ./infrastructure/ — security review /gomboc-community:fix Dockerfile /gomboc-community:fix k8s/ — least privilege /gomboc-community:fix src/api/ — prevent code injection /gomboc-community:fix . — CIS compliance check ``` **Workflow:** diagnose → select issues → apply fixes → optionally save as rules ### `/create-rule` — Create a rule from scratch Define a security or compliance policy and build a complete ORL rule package with tests. ``` /gomboc-community:create-rule Ensure all AWS S3 buckets have server-side encryption enabled using Terraform /gomboc-community:create-rule Ensure Dockerfiles use pinned image digests instead of mutable tags /gomboc-community:create-rule Ensure Kubernetes Deployments set runAsNonRoot in securityContext ``` **Workflow:** plan → build → add metadata → optionally push ### `/convert-sentinel` — Convert a Sentinel policy to ORL Convert a HashiCorp Sentinel policy (from a URL or local file path) into one or more tested ORL rule packages. ``` /gomboc-community:convert-sentinel https://raw.githubusercontent.com/hashicorp/terraform-sentinel-policies/main/aws/restrict-ec2-instance-type.sentinel /gomboc-community:convert-sentinel ./policies/require-most-recent-ami-version.sentinel ``` **Workflow:** analyze → build rules → add metadata → optionally push ## Skills Each command orchestrates one or more underlying skills: | Skill | Description | | ------------------ | --------------------------------------------------------------------------------------------------------------------------- | | `diagnose` | Classification-driven analyzer — detects language, loads matching policies, walks the AST, and reports prioritized findings | | `apply-fix` | Applies a fix using an existing ORL rule or generates a new one, with optional save-as-rule | | `plan-rule` | Analyzes requirements, identifies test cases, and creates a plan for an ORL rule | | `build-rule` | Creates workspace files, writes the ORL rule, and runs tests | | `add-metadata` | Adds metadata (name, description, classifications, provider) to a rule | | `push-rule` | Pushes a completed rule to the Gomboc Rules Service | | `cleanup-rule` | Evaluates a rule package against release standards and produces a remediation checklist | | `convert-sentinel` | Converts a HashiCorp Sentinel policy into tested ORL rule packages | ## Supported languages | Language | ORL language ID | Use case | | ------------------- | --------------------- | ------------------------------------------------- | | Terraform | `terraform` | AWS, Azure, GCP infrastructure | | HCL | `hcl` | Terragrunt, Packer, Consul, Vault configs | | CloudFormation YAML | `cloudformation-yaml` | AWS infrastructure (YAML format) | | CloudFormation JSON | `cloudformation-json` | AWS infrastructure (JSON format) | | Bicep | `bicep` | Azure infrastructure | | Dockerfile | `docker` | Container image definitions | | Kubernetes | `kubernetes` | K8s manifests (Deployments, Pods, Services, etc.) | | Python | `python` | Application code, AWS CDK, Pulumi, SDK usage | ## Publishing rules To push rules to your Gomboc Community Edition account: 1. Set your Personal Access Token: `export RULE_SERVICE_TOKEN=your-pat-here` 2. Run `/gomboc-community:push-rule` from your rule directory, or use the ORL CLI directly: See [Publish](/orl/publish) for more on rule publishing, channels, and classifications. ## Rule package structure Each rule is a self-contained directory: ``` my-rule/ ├── my-rule.orl # Main rule file ├── test.orl # Test definition ├── workspace/ # Source files with violations └── workspace_expected/ # Source files after remediation ``` ## Classification-driven analysis The `/fix` command uses the ORL classification policy corpus as its knowledge base. Each classification YAML defines what security or compliance policy to enforce, which languages and resource types it applies to, impact and risk scores for prioritization, and compliance framework mappings (CIS, NIST CSF, PCI-DSS, AWS Well-Architected, etc.). Adding new classification YAMLs automatically extends what `/fix` can detect — no plugin changes needed. # Gomboc Enterprise Skills The Gomboc Enterprise Skills plugin brings ORL (Open Remediation Language) workflows into your AI coding agent. Use it to scan code for security and compliance violations, deliver in-context fixes, author production-quality ORL rules, manage policy classifications, and publish rules to your organization's rule repository or the Gomboc Rules Service. The plugin supports **Claude Code**, **Gemini CLI**, **OpenAI Codex**, and **Cursor**. It is distributed as a private zip package shared during Gomboc Enterprise onboarding (not published on a public marketplace). ## Plugins | Plugin | Purpose | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | `gomboc` | Core skills: classification, ORL rule creation, in-context remediation, policy enforcement, language experts, and converters | | `policy-fix-workflow` | Generate fix scenarios, run both fix modes, and evaluate accuracy and operational metrics | ## Prerequisites Before installing the plugin, make sure you have: * A valid **Gomboc Enterprise** subscription * Your target agent installed and configured (Claude Code, Gemini CLI, OpenAI Codex, or Cursor) * [Docker](https://docs.docker.com/get-docker/) installed and running — the ORL runtime uses the `gombocai/orl:latest` container image (a local `orl` binary on `PATH` is optional) * A **`GOMBOC_API_TOKEN`** for Gomboc Rules Service access — see [Generate A Personal Access Token](/getting-started/generate-a-personal-access-token) ## Installation The plugin is distributed as a zip package via Google Drive during onboarding. Download it from the link your Gomboc contact provides and extract it to a stable location: ```bash unzip ~/Downloads/gomboc-enterprise-skills.zip -d ~/gomboc/ ``` The same extracted folder works for all four supported agent runtimes. Installation steps differ by agent — follow the guide for yours: | Agent | Install guide | | ------------ | ----------------------------------------------------------------------------------- | | Claude Code | [Claude (Enterprise)](/orl/agent-skills/gomboc-enterprise-skills/claude-enterprise) | | Gemini CLI | [Gemini (Enterprise)](/orl/agent-skills/gomboc-enterprise-skills/gemini-enterprise) | | OpenAI Codex | [Codex (Enterprise)](/orl/agent-skills/gomboc-enterprise-skills/codex-enterprise) | | Cursor | [Cursor (Enterprise)](/orl/agent-skills/gomboc-enterprise-skills/cursor-enterprise) | After installation, configure your token in the environment your agent launches from: ```bash export GOMBOC_API_TOKEN="" ``` Verify the ORL runtime by asking the agent to run the `orl` skill with the `version` subcommand (for example, `/orl version` in Claude Code or Cursor Agent). ## Commands The `gomboc` plugin exposes slash commands as high-level entry points. Each command orchestrates one or more underlying skills. ### `/fix` — Fix a violation in code you are looking at Deliver an accurate fix for a policy violation in your code. Runs `analyze-context` → `build-fix` → `apply-fix`. ``` /fix "SQL queries must use parameterized statements" --files src/db/UserRepository.java /fix "File uploads must validate content type before saving" /fix "Controllers must not contain business logic — delegate to service layer" ``` **Workflow:** fingerprint the violation → build a targeted ORL rule from your real code → present the diff and apply on approval Fixes are saved under `.gomboc/orl-rules/`. Promote a successful fix to a persistent org rule with `/save-rule`. ### `/new-policy` — Create a classification from a policy source Create a classification YAML from a policy document or standard, then generate use cases for target languages. ``` /new-policy https://cwe.mitre.org/data/definitions/89.html --org gomboc-ai/acme --languages java,typescript /new-policy ./docs/internal-auth-policy.md --languages python,go /new-policy CKV_AWS_19 --org gomboc-ai/acme ``` **Workflow:** `manage-classifications` → review → `create-use-cases` ### `/new-rule` — Build a production-quality ORL rule Full rule creation pipeline from an existing classification: build → review → enrich. ``` /new-rule gomboc-ai/acme/cwe/cwe-89-sql-injection --language java /new-rule gomboc-ai/mitre/cwe/cwe-79-xss --language typescript ``` **Workflow:** `build-rule` → `review-rule` → `enrich-rule` Follow with `/release` to promote the rule to your org repository. ### `/new-custom-classifications` — Batch-create org classifications Interactive wizard for creating custom enterprise classifications under your organization namespace and uploading them to the Rules Service. ``` /new-custom-classifications /new-custom-classifications --org acme --file ./acme-policies.csv ``` **Workflow:** `create-custom-classifications` → write YAML → upload via `rules-service` ### `/release` — Promote a rule to the org repository Copy a reviewed, enriched rule package to your org's ORL rule repository and open a PR (or publish directly with `--push`). ``` /release ./workspace/java-spring-ensure-parameterized-sql-queries/ /release ./workspace/ts-express-ensure-helmet-middleware/ --org-rules-path ../acme-orl-rules /release ./workspace/my-rule/ --push ``` **Workflow:** `release-rule` → quality assessment → PR or `orl rules push` ### `/save-rule` — Promote an in-context fix to a persistent rule Promote one or more rules from `.gomboc/orl-rules/` to your org's rule repository. ``` /save-rule --classification gomboc-ai/mitre/cwe/cwe-89-sql-injection /save-rule --rule-path .gomboc/orl-rules/20260418-143022-ensure-parameterized-queries \ --classification gomboc-ai/mitre/cwe/cwe-89-sql-injection \ --generalize ``` **Workflow:** enrich + review in parallel → background release (PR or `--push`) ## Policy enforcement loop For scanning an entire codebase against a policy — diagnosing violations, assessing rule coverage, applying existing rules or building new ones, and verifying compliance — use the **`enforce-policy`** skill or read the full workflow guide: ➡ [Policy Enforcement Loop](/orl/agent-skills/gomboc-enterprise-skills/policy-enforcement-loop) ``` diagnose → assess rule coverage → apply existing rules or build new ones → verify ``` In Cursor, you can invoke `/enforce-policy` directly. In Claude Code, ask the agent to enforce a policy against a target path, or step through individual skills (`diagnose`, `orl-remediation-planner`, `orl-expert`, etc.) for finer control. ## CSPM triage loop For triaging a live cloud security alert from Wiz or another CSPM tool — fetching the observation, tracing it to IaC code, building or reusing an ORL rule, applying the fix, and posting a resolution note back — use the **`cspm-triage`** skill or read the full workflow guide: ➡ [CSPM Triage Loop](https://github.com/Gomboc-AI/gitbook-user-docs/blob/main/orl/agent-skills/gomboc-enterprise-skills/cspm-triage-loop.md) ``` fetch alert → classify → diagnose code → build rule → enrich → review → release → apply → note ``` In Cursor, you can invoke `/cspm-triage` directly. In Claude Code, describe the alert and source path in natural language and the agent activates the skill automatically. ## Key skills Each command orchestrates underlying skills. The most commonly used: | Skill | Description | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------- | | `diagnose` | Classification-driven analyzer — detects language, loads matching policies, walks the AST, and reports prioritized findings | | `analyze-context` | Fingerprints language, framework, and the exact AST violation pattern in code you are looking at | | `build-fix` | Writes a targeted ORL rule using your real code as the workspace | | `apply-fix` | Runs `orl remediate --dry-run`, presents the diff, and applies on approval | | `enforce-policy` | Full diagnose → cover → apply → verify loop | | `build-rule` | Creates workspace files, writes the ORL rule, and runs tests from a classification | | `review-rule` | 12-item robustness checklist and overlap check against existing released rules | | `enrich-rule` | Applies full metadata annotation with org-specific validation | | `release-rule` | Copies to org rules repo, runs quality assessment, opens a PR | | `save-as-rule` | Promotes in-context rules from `.gomboc/orl-rules/` to the org repository | | `manage-classifications` | Routes policy input to the right classification expert and writes YAML | | `rules-service` | Query or publish against the Gomboc Rules Service API | The plugin also includes **40 language expert skills** (`language-*-expert`), **classification experts** for MITRE, OWASP, Prisma Cloud, Wiz, HashiCorp Sentinel, and **converters** for Sentinel and Terraform Policy. ## Supported languages ORL supports 40+ languages across IaC, application code, and configuration formats. Language expert skills are dispatched automatically based on detected language. Common examples: | Category | Languages | | ---------------- | ------------------------------------------------------------------------------------ | | IaC | Terraform, HCL, CloudFormation (YAML/JSON), Bicep, ARM, Kubernetes, Helm, Dockerfile | | Application code | Java, TypeScript, JavaScript, Python, Go, C#, Ruby, Kotlin, Scala, Rust, and more | | Config / data | YAML, JSON, XML, TOML, SQL, Bash, Markdown | See [Languages](https://github.com/Gomboc-AI/gitbook-user-docs/blob/main/orl/agent-skills/concepts/languages.md) for the full list. ## Workspace conventions Skills write outputs to `.gomboc/` in your workspace root: ``` .gomboc/ ├── orl-rules/ in-context rule packages (from /fix → /save-rule) ├── cache/ local rule and classification cache │ └── classifications/ └── audit-findings.md AUDIT_ONLY findings summary ``` Add `.gomboc/` to `.gitignore`, or selectively commit `orl-rules/` to track in-context rules. ## Remediation types When `/fix` or `apply-fix` runs a rule, the outcome depends on the rule's remediation capability: | Type | Result | | ------------------------ | -------------------------------------------------------------------------- | | `FULL_REMEDIATION` | Diff shown and applied on confirmation — all values are deterministic | | `REMEDIATION_WITH_INPUT` | Structural fix applied; you supply values for `USER_INPUT_N` placeholders | | `AUDIT_ONLY` | Violation annotated inline; summary written to `.gomboc/audit-findings.md` | | `UNREMEDIATEABLE` | Violation detected but not actionable via ORL | ## Publishing rules To publish rules directly to the Gomboc Rules Service instead of opening a PR: 1. Set `GOMBOC_API_TOKEN` in your agent environment (or plugin config for Claude Code) 2. Use `--push` with `/release` or `/save-rule` See [Publish](https://github.com/Gomboc-AI/gitbook-user-docs/blob/main/orl/agent-skills/publish/README.md) for more on rule publishing, channels, and classifications. ## Rule package structure Each rule is a self-contained directory: ``` my-rule/ ├── my-rule.orl # Main rule file ├── test.orl # Test definition ├── workspace/ # Source files with violations └── workspace_expected/ # Source files after remediation ``` ## Further reading * [Claude (Enterprise)](/orl/agent-skills/gomboc-enterprise-skills/claude-enterprise) — install guide for Claude Code * [Gemini (Enterprise)](/orl/agent-skills/gomboc-enterprise-skills/gemini-enterprise) — install guide for Gemini CLI * [Codex (Enterprise)](/orl/agent-skills/gomboc-enterprise-skills/codex-enterprise) — install guide for OpenAI Codex * [Cursor (Enterprise)](/orl/agent-skills/gomboc-enterprise-skills/cursor-enterprise) — install guide for Cursor * [Policy Enforcement Loop](/orl/agent-skills/gomboc-enterprise-skills/policy-enforcement-loop) — full loop diagram and stage breakdown * [CSPM Triage Loop](https://github.com/Gomboc-AI/gitbook-user-docs/blob/main/orl/agent-skills/gomboc-enterprise-skills/cspm-triage-loop.md) — trace a Wiz/CSPM alert to a code fix and resolution note * [ORL Quickstart](https://github.com/Gomboc-AI/gitbook-user-docs/blob/main/orl/agent-skills/quickstart.md) — write your first ORL rule * [ORL Core Concepts](https://github.com/Gomboc-AI/gitbook-user-docs/blob/main/orl/agent-skills/concepts.md) — audit, remediation, workspace, rule-space, tests * Enterprise support: # Claude (Enterprise) Use this guide to install the private Gomboc Enterprise skills plugin for Claude Code. {% hint style="info" %} This plugin is distributed only as a private zip package shared via Google Drive during Gomboc Enterprise onboarding. It is not published on any public marketplace. {% endhint %} #### What you will set up By the end of this guide, you will have: * The Gomboc Enterprise plugin package extracted locally on your machine * The Gomboc Enterprise marketplace added to Claude Code * The `gomboc` plugin installed in Claude Code * A valid `GOMBOC_API_TOKEN` configured * Docker available so the ORL container runtime can run * A working Claude Code flow for Gomboc enterprise remediation and rule workflows For background on ORL, see [ORL (Open Remediation Language)](/orl). For Gomboc rule concepts, see [Rules](/policy-management/rules) #### Who this is for This guide is for Gomboc Enterprise customers who: * use Claude Code as their coding agent * have a valid Gomboc Enterprise subscription * need enterprise remediation, rule authoring, or rule publishing workflows If you are using the public community plugin instead, see [Gomboc Community Skills](/orl/agent-skills/gomboc-community-skills) *** #### Prerequisites Before you start, make sure you have the following. **Claude Code** * Claude Code must be installed and authenticated on your machine. * Open Claude Code and confirm the plugin manager is available: `/plugin` **Enterprise Skills Plugin Package** * The plugin is distributed as a zip package via a Google Drive link shared by your Gomboc contact during onboarding. * Download the zip and extract it to a stable location on your machine (for example `~/gomboc/gomboc-enterprise-skills/`). The same extracted folder works for all four supported agent runtimes; you only need to do this once. * To upgrade later, download the new zip your Gomboc contact provides and replace the extracted folder (or extract alongside and re-point the install commands to the new path). {% hint style="info" %} The zip contains the full plugin — every per-agent manifest (`plugin.json`, `gemini-extension.json`, `.codex-plugin/plugin.json`, `.cursor-plugin/plugin.json`) plus all skills, commands, and reference files. {% endhint %} **Gomboc API token** * You need a valid `GOMBOC_API_TOKEN`. See [Generate A Personal Access Token](/getting-started/generate-a-personal-access-token). **Docker (for the ORL runtime)** * The Gomboc Enterprise plugin runs ORL through the public `gombocai/orl:latest` container image, managed automatically by the agent. * Install Docker Desktop or Docker Engine for your operating system and confirm the daemon is running: `docker info` For advanced ORL usage, see [Custom Rules Quickstart](/orl/quickstart) (Advanced) *** #### **Step 1: Download and extract the plugin package** Download the zip file from the Google Drive link your Gomboc contact provided and extract it: ```bash # Example — adjust the zip filename and destination to match your setup unzip ~/Downloads/gomboc-enterprise-skills.zip -d ~/gomboc/ ``` For the rest of this guide, the path `~/gomboc/gomboc-enterprise-skills/` refers to the extracted folder. Adjust it to wherever you extracted the zip. #### **Step 2: Add the Gomboc marketplace and install the plugin** Claude Code reads the marketplace manifest from `.claude-plugin/marketplace.json` at the root of the extracted folder. Add the marketplace from the local path: 1. Start Claude Code and open the plugin manager: `/plugin` 2. Select **Add Marketplace**. 3. When prompted for the marketplace source, enter the **absolute path** to the extracted folder, for example: ``` /Users/you/gomboc/gomboc-enterprise-skills ``` 4. Open the `/plugin` browser → select the Gomboc Enterprise marketplace → install the `gomboc` plugin. 5. Reload plugins if Claude Code prompts you to do so. #### Step 3: Configure your Gomboc token The `gomboc` plugin reads `GOMBOC_API_TOKEN` from the environment Claude Code is launched from. This is the most reliable way to configure it across Claude Code versions. Set the variable in the shell that launches Claude Code: ```bash export GOMBOC_API_TOKEN="" claude ``` To make this persistent, add the `export` line to your shell profile (`~/.zshrc` on macOS, `~/.bashrc` on Linux, or equivalent). On macOS, if you usually launch Claude Code from Finder or Spotlight, launch it once from a terminal after updating your profile so the new value is inherited. {% hint style="info" %} Keep this token private. Do not commit it to source control. {% endhint %} **Alternative: in-app `userConfig` prompt** The plugin manifest also declares `GOMBOC_API_TOKEN` as a `userConfig` field. In Claude Code versions where the `userConfig` prompt is wired up correctly, Claude Code asks for the value at plugin enable time and stores it in your system keychain (or `~/.claude/.credentials.json` as a fallback). If you want to use this path, open `/plugins → Installed → gomboc` and run `Disable plugin`, then re-enable it. If a prompt appears asking for `Gomboc API Token`, paste your token there. If no prompt appears, the in-app configuration flow is affected by a known Claude Code bug ([anthropics/claude-code#39827](https://github.com/anthropics/claude-code/issues/39827)). Use the shell environment variable approach above instead. **Verify the token is in use** Inside Claude Code, run a workflow that needs the token, for example asking the agent to `Pull rules from the default channel using the orl skill`. If the token is correctly configured, the call succeeds; if it is missing or invalid, you will see a `Missing GOMBOC_API_TOKEN` or `401 Unauthorized` error from the Rules Service. #### **Step 4: Confirm the ORL runtime** The `gomboc` plugin's `orl` skill resolves the runtime for you. It uses a local `orl` binary when one is on your `PATH`, and otherwise runs ORL through the `gombocai/orl:latest` Docker container (pulled automatically on first use). You do not invoke the runtime directly. Verify the integration end-to-end by asking the agent to run the `orl` skill with the `version` subcommand. The skill prints the resolved ORL version and reports the execution method (local binary or container image). In the Claude Code chat, type: `/orl version` If the call fails (no version returned, or an error referencing the runtime), see ORL runtime not available under [Troubleshooting](#troubleshooting) below. #### Step 5: Run your first Gomboc workflow Once the plugin, token, and ORL runtime are configured, use the Claude Code commands provided by the plugin. **Fix a concrete issue in code** Use: `/fix` * This workflow helps apply or build a fix for a concrete violation in code. **Create a reusable rule** Use: `/new-rule` * This workflow helps create a reusable ORL rule from a policy, classification, or requirement. **Release or publish a rule** Use: `/release` * This workflow supports enterprise rule release and publishing flows. * For details about publishing ORL rules, see [Publish](/orl/publish) and [Rule Service API](/orl/publish/orl-rule-service-api) *** #### Troubleshooting Use this section to diagnose the most common setup issues. **Plugin package download or extraction issues** If the zip file provided by your Gomboc contact cannot be downloaded or extracted: * Confirm the Google Drive link is still valid and has not expired. Ask your Gomboc contact to re-share if needed. * Confirm the download completed fully before extracting — a partial download will fail silently or produce an empty folder. * On macOS, if unzipping via Finder produces an incomplete result, prefer the terminal: `unzip ~/Downloads/gomboc-enterprise-skills.zip -d ~/gomboc/` * Confirm you have write access to the destination folder. If you are still unable to obtain the package, contact your Gomboc representative. **Marketplace does not appear in Claude Code** If the marketplace was added but does not appear in the plugin browser: * Refresh or update the marketplace from the Claude Code plugin manager. * Restart Claude Code. * Reopen `/plugin` and check the marketplace list again. If the problem persists, remove the marketplace from the Claude Code plugin manager and re-add it using the absolute path to the extracted folder. **Plugin does not appear after adding the marketplace** If the marketplace appears but the `gomboc` plugin is missing: * Confirm that the marketplace source is the absolute path to the extracted folder (the folder that contains `.claude-plugin/marketplace.json` at its root). * Confirm that the extracted folder is still present at that path and has not been moved or deleted. * Refresh the marketplace from the Claude Code plugin manager. * Restart Claude Code and open `/plugin` again. **Token configuration errors** If the plugin reports authentication or token errors: * Confirm that `GOMBOC_API_TOKEN` is set. * Confirm that the token is valid and has not expired. * Generate or rotate your token — see [Generate A Personal Access Token](/getting-started/generate-a-personal-access-token) * Reconfigure the installed `gomboc` plugin with the new token. **ORL runtime not available** If Claude Code or the plugin reports that ORL cannot be executed: * Run `docker info` to confirm Docker is installed and the daemon is running. * Pull the image manually to confirm registry access: `docker pull gombocai/orl:latest` * If you maintain a local `orl` binary, confirm it is on `PATH` with `command -v orl`. * Restart your terminal and Claude Code after fixing Docker or `PATH`. **ORL command runs but remediation fails** If ORL is available but remediation does not complete: * Confirm that you are running the command from the correct project or workspace. * Confirm that the target files are supported by the workflow you are running. * Confirm that your `GOMBOC_API_TOKEN` is valid. * Review the command output for rule, language, or workspace errors. For ORL concepts and supported rule workflows, see [ORL (Open Remediation Language)](/orl) and [Workspace](/orl/concepts/workspace) **Plugin updates do not appear** If a new version of the plugin is available but Claude Code still shows an older version: * Confirm you have downloaded the latest zip from the Google Drive link your Gomboc contact provided. * Replace the contents of the extracted folder (or extract the new zip to the same path). * Update the marketplace from the Claude Code plugin manager so Claude Code re-parses the manifest. * Restart Claude Code. **Still need help?** If you are still blocked, contact the Gomboc team with: * the step where the setup failed * the error message you received * the absolute path to your extracted plugin folder * the output of `docker info` (or `orl --help`, if you use a local binary) See [Support](/support) for support channels. # Codex (Enterprise) Use this guide to install the private Gomboc Enterprise skills plugin for Codex. {% hint style="info" %} This plugin is distributed only as a private zip package shared via Google Drive during Gomboc Enterprise onboarding. It is not published on any public marketplace. {% endhint %} #### What you will set up By the end of this guide, you will have: * The Gomboc Enterprise plugin package extracted locally on your machine * The Gomboc Enterprise marketplace added to OpenAI Codex * The `gomboc` plugin installed and enabled in Codex * A valid `GOMBOC_API_TOKEN` configured * Docker available so the ORL container runtime can run * A working Codex flow for Gomboc enterprise remediation and rule workflows For background on ORL, see [ORL (Open Remediation Language)](/orl). For Gomboc rule concepts, see [Rules](/policy-management/rules) #### Who this is for This guide is for Gomboc Enterprise customers who: * use OpenAI Codex as their coding agent * have a valid Gomboc Enterprise subscription * need enterprise remediation, rule authoring, or rule publishing workflows *** #### Prerequisites Before you start, make sure you have the following: **OpenAI Codex** * OpenAI Codex must be installed and authenticated on your machine. * Open Codex and confirm that the plugin browser is available: `/plugins` **Enterprise Skills Plugin Package** * The plugin is distributed as a zip package via a Google Drive link shared by your Gomboc contact during onboarding. * Download the zip and extract it to a stable location on your machine (for example `~/gomboc/gomboc-enterprise-skills/`). The same extracted folder works for all four supported agent runtimes; you only need to do this once. * To upgrade later, download the new zip your Gomboc contact provides and replace the extracted folder (or extract alongside and re-point the install commands to the new path). {% hint style="info" %} The zip contains the full plugin — every per-agent manifest (`plugin.json`, `gemini-extension.json`, `.codex-plugin/plugin.json`, `.cursor-plugin/plugin.json`) plus all skills, commands, and reference files. {% endhint %} **Gomboc API token** * You need a valid `GOMBOC_API_TOKEN`. See [Generate A Personal Access Token](/getting-started/generate-a-personal-access-token). **Docker (for the ORL runtime)** * The Gomboc Enterprise plugin runs ORL through the public `gombocai/orl:latest` container image, managed automatically by the agent. * Install Docker Desktop or Docker Engine for your operating system and confirm the daemon is running: `docker info` For advanced ORL usage, see [Custom Rules Quickstart](/orl/quickstart) *** #### **Step 1: Download and extract the plugin package** Download the zip file from the Google Drive link your Gomboc contact provided and extract it: ```bash # Example — adjust the zip filename and destination to match your setup unzip ~/Downloads/gomboc-enterprise-skills.zip -d ~/gomboc/ ``` For the rest of this guide, the path `~/gomboc/gomboc-enterprise-skills/` refers to the extracted folder. Adjust it to wherever you extracted the zip. Codex reads the marketplace manifest at the root of the extracted folder. #### **Step 2: Add the Gomboc marketplace and install the plugin** Add the marketplace from the absolute path to the extracted folder, then install the plugin from the plugin browser. ```bash codex plugin marketplace add ~/gomboc/gomboc-enterprise-skills ``` Then in Codex: 1. Open Codex: `codex` and open the plugin browser: `/plugins` 2. Select the Gomboc Enterprise marketplace. 3. Open the `gomboc` plugin. 4. Install the plugin. 5. Make sure the plugin is enabled. 6. Restart Codex if prompted. **Alternative: install from the command line** If you prefer a non-interactive install (for example for scripted setups or CI), skip the plugin browser and install the plugin directly from the terminal: ```bash codex plugin add gomboc@gomboc-enterprise-marketplace \ -c GOMBOC_API_TOKEN="" ``` The `-c GOMBOC_API_TOKEN=...` flag injects the token into the plugin configuration as part of the install. If you use this form, you can skip Step 3 below; otherwise, leave the `-c` flag out and configure the token via `~/.codex/config.toml` as described in Step 3. Restart Codex once the install completes. #### Step 3: Configure your Gomboc token Configure the plugin with your Gomboc API token. Add the token to your Codex configuration file: ```toml [plugins.gomboc] GOMBOC_API_TOKEN = "YOUR_TOKEN" ``` The Codex configuration file is usually located at: `~/.codex/config.toml` {% hint style="info" %} Keep this token private. Do not commit it to source control. {% endhint %} After updating the configuration, restart Codex so the plugin can read the new token. #### **Step 4: Confirm the ORL runtime** The `gomboc` plugin's `orl` skill resolves the runtime for you. It uses a local `orl` binary when one is on your `PATH`, and otherwise runs ORL through the `gombocai/orl:latest` Docker container (pulled automatically on first use). You do not invoke the runtime directly. Verify the integration end-to-end by asking the agent to run the `orl` skill with the `version` subcommand. The skill prints the resolved ORL version and reports the execution method (local binary or container image). In Codex, invoke the orl skill: `$orl version` If the call fails (no version returned, or an error referencing the runtime), see ORL runtime not available under [Troubleshooting](#troubleshooting) below. #### Step 5: Run your first Gomboc workflow Once the plugin, token, and ORL runtime are configured, use the Gomboc skills installed in Codex. Codex uses native skill invocation rather than Claude or Gemini slash commands. You can invoke installed skills with `$skill-name`, use `/skills`, or select the relevant installed skill from the Codex interface. **Diagnose a codebase** Use: `$diagnose` * This workflow helps analyze source code against Gomboc-supported security and policy classifications. **Fix a concrete issue in code** Use the Codex-native fix flow: ``` $analyze-context $build-fix $apply-fix ``` * This workflow helps analyze the violation context, build a targeted ORL rule, and apply the remediation after review. **Enforce a policy end to end** Use: `$enforce-policy` * This workflow helps diagnose a policy, assess rule coverage, apply existing rules, create missing rules when needed, and verify compliance. **Create a reusable rule** Use: `$build-rule` * This workflow helps create a reusable ORL rule from a policy, classification, or requirement. **Release or publish a rule** Use: `$release-rule` * This workflow supports enterprise rule release and publishing flows. * For details about publishing ORL rules, see [Publish](/orl/publish) and [Rule Service API](/orl/publish/orl-rule-service-api) *** #### Troubleshooting Use this section to diagnose the most common setup issues. **Plugin package download or extraction issues** If the zip file provided by your Gomboc contact cannot be downloaded or extracted: * Confirm the Google Drive link is still valid and has not expired. Ask your Gomboc contact to re-share if needed. * Confirm the download completed fully before extracting — a partial download will fail silently or produce an empty folder. * On macOS, if unzipping via Finder produces an incomplete result, prefer the terminal: `unzip ~/Downloads/gomboc-enterprise-skills.zip -d ~/gomboc/` * Confirm you have write access to the destination folder. If you are still unable to obtain the package, contact your Gomboc representative. **Marketplace add fails** If `codex plugin marketplace add ~/gomboc/gomboc-enterprise-skills` fails: * Confirm the path you passed is the absolute path to the extracted folder, not a relative path or a `~`-only fragment. * Confirm the folder exists and contains the marketplace manifest at its root. * Confirm you have read permission on the folder: `ls -la ~/gomboc/gomboc-enterprise-skills` * Retry the command after fixing the path. **Marketplace does not appear in Codex** If the marketplace was added but does not appear in the plugin browser: * Restart Codex. * Reopen `/plugins`. * Check that the marketplace source is the absolute path to the extracted folder. * Upgrade configured marketplaces: `codex plugin marketplace upgrade` If the problem persists, remove and re-add the marketplace: * `codex plugin marketplace remove gomboc-enterprise-marketplace` * `codex plugin marketplace add ~/gomboc/gomboc-enterprise-skills` **Plugin does not appear after adding the marketplace** If the marketplace appears but the `gomboc` plugin is missing: * Confirm the extracted plugin folder is still present at the path you used when adding the marketplace. * Restart Codex. * Reopen `/plugins`. * Upgrade the marketplace: `codex plugin marketplace upgrade gomboc-enterprise-marketplace` **Token configuration errors** If the plugin reports authentication or token errors: * Confirm that `GOMBOC_API_TOKEN` is configured in `~/.codex/config.toml`. * Confirm that the token is valid and has not expired. * Generate or rotate your token — see [Generate A Personal Access Token](/getting-started/generate-a-personal-access-token) * Restart Codex after updating the token. **ORL runtime not available** If Codex or a Gomboc skill reports that ORL cannot be executed: * Run `docker info` to confirm Docker is installed and the daemon is running. * Pull the image manually to confirm registry access: `docker pull gombocai/orl:latest` * If you maintain a local `orl` binary, confirm it is on `PATH` with `command -v orl`. * Restart your terminal and Codex after fixing Docker or `PATH`. **ORL command runs but remediation fails** If ORL is available but remediation does not complete: * Confirm that you are running Codex from the correct project or workspace. * Confirm that the target files are supported by the workflow you are running. * Confirm that your `GOMBOC_API_TOKEN` is valid. * Review the Codex and ORL output for rule, language, workspace, or authentication errors. For ORL concepts and supported rule workflows, see [ORL (Open Remediation Language)](/orl) and [Workspace](/orl/concepts/workspace) **Skills do not appear in Codex** If the plugin is installed but Gomboc skills do not appear: * Confirm that the `gomboc` plugin is installed and enabled in `/plugins`. * Restart Codex. * Open `/skills` and search for Gomboc skills such as `diagnose`, `enforce-policy`, `analyze-context`, `build-fix`, or `apply-fix`. * Upgrade the marketplace and reinstall the plugin if needed. **Plugin updates do not appear** If a new version of the plugin is available but Codex still shows an older version: * Download the latest zip from the Google Drive link your Gomboc contact provided and replace the extracted folder. * Refresh Codex's view of the marketplace: `codex plugin marketplace upgrade gomboc-enterprise-marketplace` * Restart Codex. **Still need help?** If you are still blocked, contact the Gomboc team with: * the step where the setup failed * the error message you received * the absolute path to your extracted plugin folder * the output of `codex --version` * the output of `docker info` (or `orl --help`, if you use a local binary) See [Support](/support) for support channels. # Cursor (Enterprise) {% hint style="info" %} This plugin is distributed only as a private zip package shared via Google Drive during Gomboc Enterprise onboarding. It is not published on any public marketplace. {% endhint %} #### What you will set up By the end of this guide, you will have: * The Gomboc Enterprise plugin package extracted locally on your machine * The `gomboc` plugin installed in Cursor from the extracted plugin folder * A valid `GOMBOC_API_TOKEN` available in the environment Cursor launches from * Docker available so the ORL container runtime can run * A working Cursor Agent flow for Gomboc enterprise remediation and rule workflows For background on ORL, see [ORL (Open Remediation Language)](/orl). For Gomboc rule concepts, see [Rules](/policy-management/rules) #### Who this is for This guide is for Gomboc Enterprise customers who: * use [Cursor](https://cursor.com) as their coding agent * have a valid Gomboc Enterprise subscription * need enterprise remediation, rule authoring, or rule publishing workflows *** #### Prerequisites Before you start, make sure you have the following. **Cursor** * Cursor must be installed and signed in. See cursor.com/docs for installation. * For Cursor plugin internals, see the [Cursor Plugins reference](https://cursor.com/docs/reference/plugins). **Enterprise Skills Plugin Package** * The plugin is distributed as a zip package via a Google Drive link shared by your Gomboc contact during onboarding. * Download the zip and extract it to a stable location on your machine (for example `~/gomboc/gomboc-enterprise-skills/`). The same extracted folder works for all four supported agent runtimes; you only need to do this once. * To upgrade later, download the new zip your Gomboc contact provides and replace the extracted folder (or extract alongside and re-point the install commands to the new path). {% hint style="info" %} The zip contains the full plugin — every per-agent manifest (`plugin.json`, `gemini-extension.json`, `.codex-plugin/plugin.json`, `.cursor-plugin/plugin.json`) plus all skills, commands, and reference files. {% endhint %} **Gomboc API token** * You need a valid `GOMBOC_API_TOKEN`. See [Generate A Personal Access Token](/getting-started/generate-a-personal-access-token). **Docker (for the ORL runtime)** * The Gomboc Enterprise plugin runs ORL through the public `gombocai/orl:latest` container image, managed automatically by the agent. * Install Docker Desktop or Docker Engine for your operating system and confirm the daemon is running: `docker info` For ORL concepts, see [Custom Rules Quickstart](/orl/quickstart) *** #### **Step 1: Download and extract the plugin package** Download the zip file from the Google Drive link your Gomboc contact provided and extract it: ```bash # Example — adjust the zip filename and destination to match your setup unzip ~/Downloads/gomboc-enterprise-skills.zip -d ~/gomboc/ ``` For the rest of this guide, the path `~/gomboc/gomboc-enterprise-skills/` refers to the extracted folder. Adjust it to wherever you extracted the zip. #### Step 2: Symlink the plugin into Cursor's local plugins folder Cursor automatically loads plugins from `~/.cursor/plugins/local`. Create that folder if needed, then link the plugin directory from the extracted zip: ```bash mkdir -p ~/.cursor/plugins/local ln -s ~/gomboc/gomboc-enterprise-skills/plugins/gomboc ~/.cursor/plugins/local/gomboc ``` Optionally, do the same for the evaluation plugin: ```bash ln -s ~/gomboc/gomboc-enterprise-skills/plugins/policy-fix-workflow ~/.cursor/plugins/local/policy-fix-workflow ``` Cursor discovers each plugin from its `.cursor-plugin/plugin.json` manifest inside the linked folder. #### Step 3: Reload Cursor Restart Cursor or run **Developer: Reload Window** so the new plugin is picked up. #### Step 4: Configure your Gomboc token The Gomboc skills read `GOMBOC_API_TOKEN` from the environment Cursor is launched from. Set it in the shell or environment file Cursor inherits: ```bash export GOMBOC_API_TOKEN="" ``` On macOS, when launching Cursor from Finder, set the variable via your login shell profile (for example `~/.zshrc`) and start Cursor from a terminal at least once after the change so the new value is loaded. {% hint style="info" %} Keep this token private. Do not commit it to source control. {% endhint %} #### **Step 5: Confirm the ORL runtime** The `gomboc` plugin's `orl` skill resolves the runtime for you. It uses a local `orl` binary when one is on your `PATH`, and otherwise runs ORL through the `gombocai/orl:latest` Docker container (pulled automatically on first use). You do not invoke the runtime directly. Verify the integration end-to-end by asking the agent to run the `orl` skill with the `version` subcommand. The skill prints the resolved ORL version and reports the execution method (local binary or container image). In Cursor Agent chat, type: `/orl version` If the call fails (no version returned, or an error referencing the runtime), see ORL runtime not available under [Troubleshooting](#troubleshooting) below. #### Step 6: Verify Gomboc skills are loaded 1. Open **Cursor Settings** (Cmd+Shift+J on macOS, Ctrl+Shift+J on Windows/Linux). 2. Navigate to **Rules**. 3. In the **Agent Decides** section, look for Gomboc skills such as `diagnose`, `enforce-policy`, `analyze-context`, `build-fix`, `apply-fix`, `build-rule`, `review-rule`, `enrich-rule`, `release-rule`, and `save-as-rule`. If the skills do not appear, reload Cursor and confirm the symlink at `/.cursor/plugins/local/gomboc` is intact. #### Step 7: Run your first Gomboc workflow In Cursor Agent, you can either let the agent decide when to use a Gomboc skill based on your task description, or invoke a skill explicitly by typing `/` and selecting it. The main entry-point skills exposed by the plugin are: | Invocation | Purpose | | ------------------ | ---------------------------------------------------------------------- | | `/diagnose` | Scan code for violations against Gomboc classifications | | `/analyze-context` | Detect language and fingerprint a specific violation | | `/build-fix` | Build a targeted ORL rule for a real violation | | `/apply-fix` | Run `orl remediate --dry-run`, present the diff, and apply on approval | | `/enforce-policy` | Run the full diagnose → cover → apply → verify loop | | `/build-rule` | Build a production-quality ORL rule from a classification | | `/review-rule` | Run the 12-item robustness checklist on a rule package | | `/enrich-rule` | Apply org-grade metadata to a reviewed rule | | `/release-rule` | Release a reviewed and enriched rule (PR or direct push) | | `/save-as-rule` | Promote an in-context fix into the org rule repository | | `/rules-service` | Query or publish against the Gomboc Rules Service | The full list of skills exposed to Cursor is declared in `plugins/gomboc/.cursor-plugin/plugin.json`. Many other skills (language experts, planners, converters, classification experts) are also loaded and selected automatically by the agent when relevant. For details about publishing ORL rules, see [Publish](/orl/publish) and [Rule Service API](/orl/publish/orl-rule-service-api) *** #### Troubleshooting Use this section to diagnose the most common setup issues. **Plugin package download or extraction issues** If the zip file provided by your Gomboc contact cannot be downloaded or extracted: * Confirm the Google Drive link is still valid and has not expired. Ask your Gomboc contact to re-share if needed. * Confirm the download completed fully before extracting — a partial download will fail silently or produce an empty folder. * On macOS, if unzipping via Finder produces an incomplete result, prefer the terminal: `unzip ~/Downloads/gomboc-enterprise-skills.zip -d ~/gomboc/` * Confirm you have write access to the destination folder. If you are still unable to obtain the package, contact your Gomboc representative. **Local symlink not picked up** If you used the local install path and the plugin does not load: * Confirm the symlink target exists and points at the `plugins/gomboc` directory: `ls -l ~/.cursor/plugins/local/gomboc` * Confirm the manifest is at `plugins/gomboc/.cursor-plugin/plugin.json`. * Run **Developer: Reload Window** in Cursor, or restart the app. **Skills do not appear in Cursor** If the plugin is installed but Gomboc skills are missing from **Settings → Rules → Agent Decides**: * Reload Cursor. * Confirm the symlink at `~/.cursor/plugins/local/gomboc` is intact. * For local installs, confirm the symlink is intact and the plugin manifest is valid JSON. **Token configuration errors** If a Gomboc skill reports authentication or token errors: * Confirm that `GOMBOC_API_TOKEN` is exported in the shell that launches Cursor. * Confirm the token is valid and has not expired. * Generate or rotate your token — see [Generate A Personal Access Token](/getting-started/generate-a-personal-access-token) * Restart Cursor after updating the environment. **ORL runtime not available** If a Gomboc skill reports that ORL cannot be executed: * Run `docker info` to confirm Docker is installed and the daemon is running. * Pull the image manually to confirm registry access: `docker pull gombocai/orl:latest` * If you maintain a local `orl` binary, confirm it is on `PATH` with `command -v orl`. * Restart Cursor after fixing Docker or `PATH`. **ORL command runs but remediation fails** If ORL launches but the workflow does not complete: * Confirm that you are running Cursor from the correct project or workspace. * Confirm that the target files are supported by the workflow you are running. * Confirm that your `GOMBOC_API_TOKEN` is valid. * Review the Cursor Agent and ORL output for rule, language, workspace, or authentication errors. For ORL concepts and supported rule workflows, see [ORL (Open Remediation Language)](/orl) and [Workspace](/orl/concepts/workspace) **Plugin updates do not appear** If a new version of the plugin is available but Cursor still shows an older version: * Download the latest zip from the Google Drive link your Gomboc contact provided and replace the contents of your extracted folder. * Run **Developer: Reload Window** in Cursor, or restart the app. **Still need help?** If you are still blocked, contact the Gomboc team with: * the step where the setup failed * the error message you received * the absolute path to your extracted plugin folder * the output of `docker info` (or `orl --help`, if you use a local binary) See [Support](/support) for support channels. # Gemini (Enterprise) {% hint style="info" %} This plugin is distributed only as a private zip package shared via Google Drive during Gomboc Enterprise onboarding. It is not published on any public marketplace. {% endhint %} #### What you will set up By the end of this guide, you will have: * The Gomboc Enterprise plugin package extracted locally on your machine * The `gomboc` Gemini CLI extension installed locally * A valid `GOMBOC_API_TOKEN` configured for the extension * Docker available so the ORL container runtime can run * A working Gemini CLI flow for Gomboc enterprise remediation and rule workflows For background on ORL, see [ORL (Open Remediation Language)](/orl). For Gomboc rule concepts, see [Rules](/policy-management/rules) #### Who this is for This guide is for Gomboc Enterprise customers who: * use [Gemini CLI](https://github.com/google-gemini/gemini-cli) as their coding agent * have a valid Gomboc Enterprise subscription * need enterprise remediation, rule authoring, or rule publishing workflows *** #### Prerequisites Before you start, make sure you have the following. **Gemini CLI** * Gemini CLI must be installed and authenticated on your machine. * Confirm the extension manager is available: `gemini extensions list` For Gemini CLI extension internals, see the [Gemini CLI Extensions reference](https://google-gemini.github.io/gemini-cli/docs/extensions/). **Enterprise Skills Plugin Package** * The plugin is distributed as a zip package via a Google Drive link shared by your Gomboc contact during onboarding. * Download the zip and extract it to a stable location on your machine (for example `~/gomboc/gomboc-enterprise-skills/`). The same extracted folder works for all four supported agent runtimes; you only need to do this once. * To upgrade later, download the new zip your Gomboc contact provides and replace the extracted folder (or extract alongside and re-point the install commands to the new path). {% hint style="info" %} The zip contains the full plugin — every per-agent manifest (`plugin.json`, `gemini-extension.json`, `.codex-plugin/plugin.json`, `.cursor-plugin/plugin.json`) plus all skills, commands, and reference files. {% endhint %} **Gomboc API token** * You need a valid `GOMBOC_API_TOKEN`. See [Generate A Personal Access Token](/getting-started/generate-a-personal-access-token). **Docker (for the ORL runtime)** * The Gomboc Enterprise extension runs ORL through the public `gombocai/orl:latest` container image, managed automatically by the agent. * Install Docker Desktop or Docker Engine for your operating system and confirm the daemon is running: `docker info` For ORL concepts, see [Custom Rules Quickstart](/orl/quickstart) *** #### **Step 1: Download and extract the plugin package** Download the zip file from the Google Drive link your Gomboc contact provided and extract it: ```bash # Example — adjust the zip filename and destination to match your setup unzip ~/Downloads/gomboc-enterprise-skills.zip -d ~/gomboc/ ``` For the rest of this guide, the path `~/gomboc/gomboc-enterprise-skills/` refers to the extracted folder. Adjust it to wherever you extracted the zip. Gemini CLI reads the extension manifest from `plugins/gomboc/gemini-extension.json` inside this folder. #### **Step 2: Install the Gomboc enterprise extension** Link the extension from the extracted folder into Gemini CLI. Use the absolute path to `plugins/gomboc/` inside the extracted folder: ```bash gemini extensions link ~/gomboc/gomboc-enterprise-skills/plugins/gomboc ``` `link` creates a symbolic link from the Gemini CLI extensions directory to the extracted plugin folder, so when you receive a new zip from your Gomboc contact and replace the folder contents in place, the updates are picked up automatically on the next Gemini CLI session restart — no separate `update` step is needed. Verify the extension is installed: ```bash gemini extensions list ``` You should see `gomboc` in the list. Restart your Gemini CLI session if it was already running. #### Step 3: Configure your Gomboc token The `gomboc` extension declares `GOMBOC_API_TOKEN` as a required setting (defined in `gemini-extension.json`). When you install the extension, Gemini CLI prompts you for it. Paste the token from [Generate A Personal Access Token](/getting-started/generate-a-personal-access-token) when prompted. If you skipped configuration on install, set the token via your shell environment before launching Gemini CLI: ```bash export GOMBOC_API_TOKEN="" ``` {% hint style="info" %} Keep this token private. Do not commit it to source control. {% endhint %} #### **Step 4: Confirm the ORL runtime** The `gomboc` plugin's `orl` skill resolves the runtime for you. It uses a local `orl` binary when one is on your `PATH`, and otherwise runs ORL through the `gombocai/orl:latest` Docker container (pulled automatically on first use). You do not invoke the runtime directly. Verify the integration end-to-end by asking the agent to run the `orl` skill with the `version` subcommand. The skill prints the resolved ORL version and reports the execution method (local binary or container image). In Gemini CLI, run the namespaced command: `/gomboc:orl version` If the call fails (no version returned, or an error referencing the runtime), see ORL runtime not available under [Troubleshooting](#troubleshooting) below. #### Step 5: Run your first Gomboc workflow Once the extension, token, and ORL runtime are in place, launch Gemini CLI in a project directory and use the namespaced slash commands provided by the extension. All commands are registered as `/gomboc:` from `commands/gomboc/*.toml`. **Diagnose a codebase** Use: `/gomboc:diagnose [--policy ]` Scans the target path for security and compliance violations across the loaded Gomboc classifications. **Fix a concrete issue in code** Use: `/gomboc:fix [--files ]` Runs the `analyze-context` → `build-fix` → `apply-fix` pipeline to apply a targeted remediation for a real violation. **Enforce a policy end to end** Use: `/gomboc:enforce [--create-missing] [--publish] [--dry-run]` Runs the full enforcement loop: diagnose, assess rule coverage, apply existing rules, optionally create missing rules, and verify compliance. **Create a classification from a policy document** Use: `/gomboc:new-policy [--org ] [--languages ]` Parses a policy URL, standard ID, or local file and creates a Gomboc classification plus per-language use cases. **Create a reusable rule** Use: `/gomboc:new-rule [--language ] [--use-case-path ]` Builds a production-quality ORL rule from an existing classification, runs the 12-item review, and applies metadata enrichment. **Release or publish a rule** Use: `/gomboc:release [--push]` Releases a reviewed rule package either via PR to the org rule repository or directly to the Gomboc Rules Service. For details about publishing ORL rules, see [Publish](/orl/publish) and [Rule Service API](/orl/publish/orl-rule-service-api) **Save an in-context fix as a persistent rule** Use: `/gomboc:save-rule [--classification ] [--generalize] [--push]` Promotes a `.gomboc/orl-rules/` package created by `/gomboc:fix` into the org's persistent rule repository. *** #### Troubleshooting Use this section to diagnose the most common setup issues. **Plugin package download or extraction issues** If the zip file provided by your Gomboc contact cannot be downloaded or extracted: * Confirm the Google Drive link is still valid and has not expired. Ask your Gomboc contact to re-share if needed. * Confirm the download completed fully before extracting — a partial download will fail silently or produce an empty folder. * On macOS, if unzipping via Finder produces an incomplete result, prefer the terminal: `unzip ~/Downloads/gomboc-enterprise-skills.zip -d ~/gomboc/` * Confirm you have write access to the destination folder. If you are still unable to obtain the package, contact your Gomboc representative. **Gemini extensions install fails** If the install command fails: * Confirm Gemini CLI is up to date. * Confirm you are pointing at the directory that contains `gemini-extension.json`, i.e. `plugins/gomboc` inside the extracted folder, not the extracted folder's root. * Run `gemini extensions list` to check whether a previous install left a stale entry; remove it with `gemini extensions uninstall gomboc` and retry. **Extension installed but commands do not appear** If `gemini extensions list` shows `gomboc` but `/gomboc:diagnose` and the other commands are missing: * Quit and restart Gemini CLI. Extension changes take effect on session restart. * Confirm the extension is enabled: `gemini extensions enable gomboc`. * For install-based setups, replace the extracted folder with the latest zip your Gomboc contact provides and run `gemini extensions update gomboc`. For link-based setups, just restart Gemini CLI — the symlink picks up changes automatically. **Token configuration errors** If the extension reports authentication or token errors: * Confirm that `GOMBOC_API_TOKEN` is configured for the extension or exported in your shell. * Confirm that the token is valid and has not expired. * Generate or rotate your token — see [Generate A Personal Access Token](/getting-started/generate-a-personal-access-token) * Restart Gemini CLI after updating the token. **ORL runtime not available** If a Gomboc command reports that ORL cannot be executed: * Run `docker info` to confirm Docker is installed and the daemon is running. * Pull the image manually to confirm registry access: `docker pull gombocai/orl:latest` * If you maintain a local `orl` binary, confirm it is on `PATH` with `command -v orl`. * Restart your terminal and Gemini CLI after fixing Docker or `PATH`. **ORL command runs but remediation fails** If ORL launches but the workflow does not complete: * Confirm that you are running Gemini CLI from the correct project or workspace. * Confirm that the target files are supported by the workflow you are running. * Confirm that your `GOMBOC_API_TOKEN` is valid. * Review the Gemini CLI output for rule, language, workspace, or authentication errors. For ORL concepts and supported rule workflows, see [ORL (Open Remediation Language)](/orl) and [Workspace](/orl/concepts/workspace) **Extension updates do not appear** If a new version of the extension is available but Gemini CLI still shows an older version: * Replace the extracted folder contents with the latest zip your Gomboc contact provided. * For `install`-based setups: `gemini extensions update gomboc` * For `link`-based setups, the symlink picks up changes automatically; just restart Gemini CLI. **Still need help?** If you are still blocked, contact the Gomboc team with: * the step where the setup failed * the error message you received * the absolute path to your extracted plugin folder * the output of `gemini extensions list` * the output of `docker info` (or `orl --help`, if you use a local binary) See [Support](/support) for support channels. # Policy Enforcement Loop The Policy Enforcement Loop is the end-to-end agentic workflow Gomboc uses to verify a codebase against a security or engineering policy and bring it back into compliance. It is the orchestrated chain of skills exposed by the `gomboc` plugin: diagnose the code, decide whether existing rules cover the violations, apply them or build new ones, and verify the outcome. You can trigger the entire loop with a single skill (`enforce-policy`), or step through it manually using the underlying skills when you want finer control. For installing the plugin in your agent first, see [Gomboc Enterprise Skills](/orl/agent-skills/gomboc-enterprise-skills). *** ### The full loop ``` ┌─────────────────────────────────────────────────────────────────┐ │ enforce-policy │ │ │ │ 1. diagnose ──────────────── Find violations in code │ │ ↓ │ │ 2. orl-existing-rules / rules-service ── Check rule coverage │ │ ↓ ↓ │ │ ┌────────────────┐ ┌──────────────────────────────────────┐ │ │ │ Rules exist │ │ No rule exists — create one │ │ │ │ (path 3A) │ │ (path 3B) │ │ │ │ │ │ │ │ │ │ orl-remediation│ │ orl-planner │ │ │ │ -planner │ │ ↓ │ │ │ │ ↓ │ │ orl-test-planner │ │ │ │ orl-remediation│ │ ↓ │ │ │ │ -expert │ │ orl-expert (build + test) │ │ │ └────────────────┘ │ ↓ │ │ │ ↓ │ orl-reviewer (quality gate) │ │ │ │ ↓ │ │ │ │ orl-metadata-enricher │ │ │ │ ↓ │ │ │ │ rules-service (publish) │ │ │ │ ↓ │ │ │ │ orl-remediation-expert (apply) │ │ │ └──────────────────────────────────────┘ │ │ ↓ ↓ │ │ 4. diagnose ──────────────── Verify compliance │ └─────────────────────────────────────────────────────────────────┘ ``` The four numbered stages are: 1. **Diagnose** — scan the target path against the requested policy and produce a list of violations with file and line locations. 2. **Assess rule coverage** — for every violation, look up whether an ORL rule already exists, either locally (in `.gomboc/cache/`) or in the Gomboc [Rules Service](/orl/publish). 3. **Apply existing rules (3A) or build new rules (3B)** — apply matched rules to fix violations; for uncovered violations, build, review, enrich, publish, and then apply a new rule. 4. **Verify** — re-run the diagnosis to confirm the policy is now satisfied. *** ### Stage breakdown | Stage | Skills involved | What it produces | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | **1. Diagnose** | `diagnose` | Prioritized findings with `file:line`, classification, risk, and existing-rule status | | **2. Assess rule coverage** | `orl-existing-rules`, `rules-service` | Decision: every finding is routed to 3A or 3B | | **3A. Apply existing rules** | `orl-remediation-planner` → `orl-remediation-expert` | Code is modified by running matched ORL rules | | **3B. Build a new rule** | `orl-planner` → `orl-test-planner` → `orl-expert` → `orl-reviewer` → `orl-metadata-enricher` → `rules-service` → `orl-remediation-expert` | A new ORL rule is built, tested, reviewed, enriched, published, and applied | | **4. Verify** | `diagnose` | Confirmation that the violation count for the target policy is zero | For details on what each skill does individually, browse the installed skill catalog in your agent: **Settings → Rules** in Cursor, `/skills` in Codex, `/plugins` in Claude Code, or `gemini extensions list` then `/help` in Gemini CLI. *** ### Common starting points (partial loop) You do not always need the full loop. The right entry point depends on what you already know about the code and the policy: | Starting point | What to run | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | Code with no policy checked yet | `diagnose` → routes you into 3A or 3B | | Violations are known, rule coverage is unknown | `orl-existing-rules` or `rules-service` → routes into 3A or 3B | | Rules already exist and you just want to apply them | `orl-remediation-planner` → `orl-remediation-expert` → `diagnose` (to verify) | | You have a policy gap and need to build a new rule | `orl-planner` → `orl-test-planner` → `orl-expert` → `orl-reviewer` → `orl-metadata-enricher` → `rules-service` | | Code produced by an agent + a policy to enforce | `enforce-policy` (handles everything above automatically) | *** ### How to trigger the loop in each agent The same underlying `enforce-policy` skill is exposed differently in each agent runtime. Use the form your agent supports: | Agent | How to trigger | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Claude Code** | Describe the goal in natural language. Example: *"Enforce the `gomboc-ai/policy/encryption/encryption_at_rest` policy against `./infrastructure` as a dry run."* Claude activates the `enforce-policy` skill automatically. | | **Gemini CLI** | `/gomboc:enforce [--create-missing] [--publish] [--dry-run]` | | **OpenAI Codex** | `$enforce-policy` (Codex native skill invocation) | | **Cursor** | Type `/enforce-policy` in Agent chat, or describe the goal in natural language and let Agent Decides pick the skill. | For more about how each agent exposes Gomboc workflows, see [Gomboc Enterprise Skills](/orl/agent-skills/gomboc-enterprise-skills). *** ### Quick-start examples **Dry run an encryption-at-rest policy against Terraform** In Gemini CLI: ```bash /gomboc:enforce ./infrastructure gomboc-ai/policy/encryption/encryption_at_rest --dry-run ``` In Claude Code or Cursor, type in Agent chat: ``` Enforce the gomboc-ai/policy/encryption/encryption_at_rest policy against ./infrastructure as a dry run. ``` In Codex: ``` $enforce-policy ./infrastructure gomboc-ai/policy/encryption/encryption_at_rest --dry-run ``` **Full loop: diagnose, create missing rules, publish, apply, verify** In Gemini CLI: ```bash /gomboc:enforce ./src gomboc-ai/policy/prevent_code_injection/sql_injection --create-missing --publish ``` In Claude Code or Cursor: ``` Enforce the gomboc-ai/policy/prevent_code_injection/sql_injection policy against ./src. Create any missing rules, publish them to the rules service, then apply and verify. ``` In Codex: ``` $enforce-policy ./src gomboc-ai/policy/prevent_code_injection/sql_injection --create-missing --publish ``` *** ### Flag reference for `enforce-policy` | Flag | Effect | | ------------------ | -------------------------------------------------------------------------------------------------------------------- | | `--dry-run` | Diagnose and plan only. Do not modify code, do not publish rules. | | `--create-missing` | Build new ORL rules for policy gaps (path 3B). Without this flag, uncovered violations are reported but not fixed. | | `--publish` | Push newly built rules to the Gomboc Rules Service. Without this flag, new rules stay local in `.gomboc/orl-rules/`. | When `enforce-policy` is invoked through a slash-command form (Gemini, Cursor), pass these flags as shown above. When invoked through natural language (Claude, Cursor), describe the same intent in plain English — *"dry run"*, *"create missing rules"*, *"publish to the rules service"* — and the agent will set the flags accordingly. *** ### See also * [Gomboc Enterprise Skills](/orl/agent-skills/gomboc-enterprise-skills) — install the plugin in Claude Code, Gemini CLI, OpenAI Codex, or Cursor. * [ORL (Open Remediation Language)](/orl) — the language and engine that backs ORL rules. * [Custom Rules Quickstart](/orl/quickstart) — write your first ORL rule. * [Publish](/orl/publish) — publish ORL rules to the Gomboc Rules Service. * [Rules](/policy-management/rules) — Gomboc rule concepts in the platform. # CSPM Triage Loop The CSPM Triage Loop is the end-to-end agentic workflow Gomboc uses to trace a live cloud security alert through to a released ORL rule and a local code fix. It bridges the gap between a Wiz finding and the infrastructure code that causes it: fetch the alert, identify the affected resource in your IaC, build or reuse an ORL rule, apply the fix, and post a resolution note back to the observation — all in a single skill invocation. You can run the full loop with `cspm-triage`, or fall back to a lighter tier when CSPM service access or local code is unavailable. For installing the plugin in your agent first, see [Gomboc Enterprise Skills](/orl/agent-skills/gomboc-enterprise-skills). *** ### The full loop ``` ┌─────────────────────────────────────────────────────────────────────┐ │ cspm-triage │ │ │ │ Phase 0: collect inputs (observation ID, local source path) │ │ ↓ │ │ Phase 1: parallel validation (env vars, service health, │ │ observation fetch, IaC detection, classification lookup) │ │ ↓ │ │ Phase 2: tier assignment │ │ ↓ │ │ 1. Gather context ─────── Body type, control ID, severity, │ │ ↓ resource type, remediation spec │ │ 2. Classify ──────────── Create gomboc-ai/wiz/ YAML │ │ ↓ (skipped if already exists) │ │ 3. Diagnose local code ─ IaC match + code confidence gate │ │ ↓ │ │ 4. Build ORL rule ─────── build-rule delegates to orl-planner │ │ ↓ → orl-expert → orl-test-planner │ │ 5. Enrich metadata ─────── enrich-rule (risk scores, diff example) │ │ ↓ │ │ 6. Review + release ───── review-rule → release-rule │ │ ↓ │ │ 7. Apply, commit, PR ──── orl remediate + gh pr create │ │ ↓ + write triage artifact (.gomboc/triage/) │ │ 8. Resolution note ─────── add_observation_note.py → Wiz UI │ └─────────────────────────────────────────────────────────────────────┘ ``` The eight numbered steps are organized into two pre-work phases and one output phase: * **Phase 0** — the skill prompts once for everything it needs: observation ID (or auto-ranks via `--top`), local source root, and whether to auto-select the top candidate. * **Phase 1** — all environment and connectivity checks run in parallel before any action is taken. Hard stops halt immediately; soft gates ask for acknowledgment. * **Steps 1–8** — the core triage loop, executed sequentially. *** ### Stage breakdown | Stage | Skills / tools involved | What it produces | | -------------------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------- | | **0. Input collection** | `fetch_observation.py --top` or `--id` | Observation selected; source path confirmed | | **1. Parallel validation** | `curl` health checks, `fetch_observation.py`, `orl detect-language`, `rules-service` | Validation table; tier assigned; hard stops surfaced before any writes | | **2. Tier assignment** | (internal) | Tier 1–4 announced to user; Tier 2 triage brief written | | **1. Gather context** | `fetch_observation.py --summary` | Body type, control ID, effective severity, resource type, remediation spec | | **2. Classify** | `classification-expert-wiz`, `rules-service` | `gomboc-ai/wiz/.yaml` (skipped if classification already exists) | | **3. Diagnose local code** | `diagnose` | Language detection, violation list, code match confidence (HIGH / MEDIUM / LOW) | | **4. Build ORL rule** | `build-rule` | Rule package with `rule.orl`, `test.orl`, workspace files | | **5. Enrich metadata** | `enrich-rule` | Rule annotated with risk/impact scores, classification references, diff example | | **6. Review + release** | `review-rule` → `release-rule` | Rule published to Gomboc Rules Service; release PR opened in org rule repository | | **7. Apply, commit, PR** | `orl remediate`, `git`, `gh pr create`, `write_triage_finding.py` | Fixed files committed; GitHub PR opened; triage artifact at `.gomboc/triage/` | | **8. Resolution note** | `add_observation_note.py` | Timestamped note posted to observation; visible in Wiz UI | For details on what each skill does individually, browse the installed skill catalog in your agent: **Settings → Rules** in Cursor, `/skills` in Codex, `/plugins` in Claude Code, or `gemini extensions list` then `/help` in Gemini CLI. *** ### Tiers The skill adjusts its behavior based on what data is available at runtime. The assigned tier is announced to the user before work begins. | Tier | Condition | What the loop produces | | --------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | **1 — Full loop** | Observation found + local source path + IaC detected | Full pipeline: classification → diagnose → build → enrich → review → release → apply → note | | **2 — Classification only** | Observation found; source path deferred or missing | Classification YAML + triage brief. Deferred steps noted for resumption when a source path is provided. | | **3 — Manual CSPM input** | cspm-service unreachable or observation data incomplete | User pastes fields from Wiz UI; loop continues with a manual-data warning. | | **4 — Identification only** | No observation ID and no CSPM access | Maps a plain-text issue description to the closest existing classification; LOW confidence warning. | A Tier 2 triage brief is written to the conversation when the source path is deferred, tracking which steps have been completed and providing resume instructions. *** ### Code match confidence gate After `diagnose` runs in Step 3, the skill scores how confidently the CSPM alert can be traced to the provided source path. This gate is independent of the alert's severity. | Confidence | Condition | Action | | ---------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------- | | **HIGH** | Resource type found AND violation pattern matched | Proceed automatically | | **MEDIUM** | Resource type found but match uncertain (dynamic blocks, indirect config) | Show warning; require user acknowledgment before continuing | | **LOW** | Resource type not found in provided code | Stop. Confirm to fall to Tier 2 or provide a different source path. | The gate prevents building and releasing rules that would never fire against the actual deployment code. *** ### Caveats #### `exampleObservationId` may be null or stale in unique-observation results When using `fetch_observation.py --top`, the `exampleObservationId` field references a specific observation record. If it is null or the referenced observation has been deleted, the script falls back to using the unique-observation item directly — which contains sufficient context (`policyContextMarkdown`, control ID, severity, resource type) to complete Steps 1–5. Step 8 uses the `example_observation_id` captured in the triage artifact during the run. #### GitHub token and PR creation `gh pr create` requires `GITHUB_TOKEN` (a PAT with `repo` scope) and an authenticated `gh` CLI. If `gh` is unavailable or not authenticated, the branch is still committed locally and the triage artifact is written — the PR must be opened manually from the printed branch name. *** ### Required environment variables These must be present in the container environment before `cspm-triage` runs. Do not ask the user for them at runtime — they are pre-injected during deployment. | Variable | Purpose | | -------------------------- | ----------------------------------------------------------------------------------------------- | | `CSPM_API_URL` | Base URL of the cspm-service (e.g. `https://cspm.internal.example.com`) | | `CSPM_API_TOKEN` | Bearer token for the cspm-service API | | `GOMBOC_API_TOKEN` | Bearer token for the Gomboc Rules Service (used by `rules-service` and scripts) | | `GITHUB_TOKEN` | GitHub PAT with `repo` scope — used by `gh` for branch push and PR creation | | `GOMBOC_RULES_SERVICE_URL` | *(optional)* Override for the rules service base URL; defaults to `https://rules.app.gomboc.ai` | *** ### How to trigger the loop in each agent | Agent | How to trigger | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Claude Code** | Type `/gomboc:cspm-fix` to invoke directly, or describe the goal in natural language — Claude activates the skill automatically. Example: *"Triage the CSPM alert POD-005 against the code in `./infrastructure`."* | | **Gemini CLI** | `/gomboc:cspm-fix` or `/gomboc:cspm-fix ` to skip auto-ranking | | **OpenAI Codex** | `$cspm-fix` (Codex native skill invocation) | | **Cursor** | Type `/gomboc:cspm-fix` in Agent chat, or describe the goal in natural language and let Agent Decides pick the skill. | *** ### Output artifacts The skill writes a structured JSON artifact to `.gomboc/triage/` in the repo root. The file is committed on the fix branch and included in the PR. ``` .gomboc/ └── triage/ └── -.json # full triage record ``` The artifact captures: * Observation metadata (control ID, severity, body type, source URL, occurrence count, last seen) * Triage outcome (tier, confidence, steps completed, steps pending) * Rule details (classification name, rule name, IaC language, files scanned, violations found) * Git attribution (repo URL, branch, commit hash, PR URL) * `alert_comment` — the pre-formatted text posted back to the observation in Step 8; read by the skill via `jq` and passed to `add_observation_note.py` * `resolution_note` — populated after Step 8 with `observation_id`, `posted_at`, and `status` (`posted` / `skipped` / `failed`); records execution outcome without duplicating the note text *** ### Common starting points (partial loop) You do not always need the full loop. The right entry point depends on what you already have: | Starting point | What to run | | ------------------------------------------------- | ----------------------------------------------------------------------------------- | | A Wiz alert ID and local IaC code | `cspm-triage` — full Tier 1 loop handles everything | | An alert ID but no local code yet | `cspm-triage` — completes Tier 2 (classification + brief); resume later with a path | | Classification already exists; need a rule for it | `build-rule` → `enrich-rule` → `review-rule` → `release-rule` | | Rule exists; need to apply it and track the fix | `orl remediate` → `write_triage_finding.py` → `add_observation_note.py` | | No CSPM access; want to map a plain-text issue | `cspm-triage` — Tier 4 produces a classification candidate with confidence warning | *** ### Quick-start examples **Full triage of a specific alert against local Terraform** In Claude Code or Cursor, type in Agent chat: ``` Triage CSPM observation POD-005 against the Kubernetes manifests in ./infrastructure/helm. ``` In Gemini CLI: ```bash /gomboc:cspm-fix POD-005 ``` In Codex: ``` $cspm-fix POD-005 ``` **Auto-rank top alerts and select interactively** In Claude Code or Cursor: ``` Triage the highest-severity CSPM alerts against ./infrastructure. Show me the ranked list and let me pick. ``` In Gemini CLI: ```bash /gomboc:cspm-fix ``` **Dry-run: classification and diagnosis only, no rule creation** In Claude Code or Cursor: ``` Fetch CSPM observation COMPUTE-013 and diagnose ./infra against it. Do not build or release any rules yet. ``` **Resume a deferred Tier 2 triage** In Claude Code or Cursor: ``` Resume the CSPM triage for observation COMPUTE-013 — source path is now ./terraform/prod. ``` *** ### How cspm-triage fits in the broader Gomboc plugin `cspm-triage` is the CSPM-alert entry point into the same underlying rule pipeline used by `enforce-policy`. The key distinction: | Workflow | Entry point | Starts from | | ---------------- | -------------------------------------- | ----------------------------------- | | `enforce-policy` | A codebase + a policy name | Code you control; policy is known | | `cspm-triage` | A live cloud alert + (optionally) code | A runtime finding in deployed infra | Both workflows produce the same outputs — ORL rules released to the Rules Service and code fixes applied locally — but `cspm-triage` adds the CSPM-specific context bridge: it fetches the alert, maps it to a classification, scores the IaC match, and closes the loop by posting a resolution note back to Wiz. Use `enforce-policy` when you are enforcing a known policy against code you are writing. Use `cspm-triage` when you are acting on a cloud security alert and want to trace it back to infrastructure code. *** ### See also * [Gomboc Enterprise Skills](/orl/agent-skills/gomboc-enterprise-skills) — install the plugin in Claude Code, Gemini CLI, OpenAI Codex, or Cursor. * [Policy Enforcement Loop](/orl/agent-skills/gomboc-enterprise-skills/policy-enforcement-loop) — the code-first enforcement workflow. * [ORL (Open Remediation Language)](/orl) — the language and engine that backs ORL rules. * [Custom Rules Quickstart](/orl/quickstart) — write your first ORL rule. * [Publish](/orl/publish) — publish ORL rules to the Gomboc Rules Service. * [Rules](/policy-management/rules) — Gomboc rule concepts in the platform. # Schemas ORL files are yaml-like and validated using JSON schema. The `docker run --rm -v ./schema:/workspace gombocai/orl schema` command will render the schema for that version of ORL. ## Schema validation Most editors that have YAML language server support will validate if you add the following comment to the top of the file: ```yaml # yaml-language-server: $schema=path/to/orl/schema/ruleset.json type: Ruleset version: v1 ... ``` Replace `ruleset.json` with the correct type. # Publish ORL rules can be published to the Rules Service, categorized, and served via channels. ## Channels Channels are pre-canned search [queries](/orl/publish/query-language) that return a set of rules. The Gomboc service uses channels for everything from policy sets to exception handling. ## Classification Classifications are a hierarchical list of categories that can contain rules. They can be children of other classifications. Gomboc uses them for policies as well as security framework mapping. ## Rules Rules in the rules service are just JSON documents with JSON metadata. ORL will only push and pull JSON documents of a type it understands. ### Rule Classifications When pushing rules to the Rules Service the `metadata.classifications` field is used to associate rules with classifications. You can associate rules with any classifications including gomboc managed ones. ```yaml type: Rule version: v1 metadata: name: my-rule classifications: - my/aws/no/dns/ips - gomboc-ai/prismacloud/CKV2_AWS_23 - gomboc-ai/policy/surface_area ``` This will create a rule associated with an internal policy `my/aws/no/dns/ips`, the Checkov rule `CKV2_AWS_23`, as well as the "Surface Area" Policy. ### Publishing Rules (push) Pushing rules will affect scans. So it is important that they are well [tested](/orl/concepts/tests) locally before being pushed. When ready, put all the files (or sym-links to the files) in a single directory and then run `orl rules push ` to upsert the files to the rules service. The following ENVs are needed: * `RULE_SERVICE_URL`: The rule service URL to use (should be `https://rules.app.gomboc.ai`) * `RULE_SERVICE_TOKEN`: The API token ### Caching Rules (pull) Pulling rules requires a channel or a [query string](/orl/publish/query-language), as well as the same ENV variables for pushing rules. All the downloaded rules will be written as `*.orl` files locally to be used in a later `orl remediate` step. * Via direct search `orl rules pull --search '(contains "my/aws" $.name)` * Via a channel `orl rules pull --channel 'my-aws'` ## Example CI Workflows * [Github](/orl/publish/github-workflow) # Query Language The query language used by the rule service is a LISP style language: `( ...)`. ## Operators The following are the operators | Operator | Syntax | Description | | ---------- | ---------------------------- | --------------------------------------- | | `eq` | `(eq left right)` | Equality comparison | | `contains` | `(contains needle haystack)` | Text contains search (case-insensitive) | | `matches` | `(matches pattern target)` | Regex pattern matching | | `any` | `(any needle expr)` | Value search in JSON objects | | `and` | `(and expr1 expr2 ...)` | Logical AND | | `or` | `(or expr1 expr2 ...)` | Logical OR | | `not` | `(not expr)` | Logical NOT | ### Equality (`eq`) Compares two values for exact equality. ```javascript (eq $.name "s3-encryption") (eq $.type "security") (eq $.version "1.0.0") (eq $.annotations.stable true) ``` ### Contains (`contains`) Searches for text within a field (case-insensitive). ```javascript (contains "aws" $.name) (contains "s3" $.resource) (contains "prod" $.metadata.environment) ``` ### Matches (`matches`) Uses regex patterns for matching. ```javascript (matches /aws_.*/i $.resource) (matches /^s3-.*/ $.name) (matches /prod|staging/ $.environment) ``` **Regex Flags:** * `i` - Case insensitive * `g` - Global match * `m` - Multiline ### Any (`any`) Searches for a specific value within JSON data structures. ```javascript (any "prod" $.metadata) (any "CIS" $.classification) (any "encryption" $.body.config) (any "enabled" $.annotations) ``` ### AND (`and`) All conditions must be true. ```javascript (and (eq $.type "security") (contains "aws" $.resource)) (and (eq $.iacLanguage "terraform") (any "prod" $.metadata) (not (contains "deprecated" $.name)) ) ``` ### OR (`or`) At least one condition must be true. ```javascript (or (contains "aws" $.resource) (contains "azure" $.resource)) (or (eq $.name "rule1") (eq $.name "rule2") (eq $.name "rule3")) ``` ### NOT (`not`) Negates a condition. ```javascript (not (contains "test" $.name)) (not (any "deprecated" $.metadata)) (not (eq $.environment "dev")) ``` ## Fields Each object has fields that can be referenced. | Field | Description | Example | | ---------------------------- | -------------------------- | -------------------------------------------------- | | `finding.name` | Rule name | `(eq finding.name "s3-encryption")` | | `finding.shortName` | Rule short name | `(contains "s3" finding.shortName)` | | `finding.type` | Rule type | `(eq finding.type "security")` | | `finding.version` | Rule version | `(eq finding.version "1.0.0")` | | `finding.iacLanguage` | IaC language | `(eq finding.iacLanguage "terraform")` | | `finding.metadata` | Rule metadata | `(any "prod" finding.metadata)` | | `finding.body` | Rule body content | `(contains "aws_s3_bucket" finding.body)` | | `finding.annotations` | Rule annotations | `(eq finding.annotations.stable true)` | | `finding.classification` | Rule classifications | `(any "CIS" finding.classification)` | | `channel.name` | Channel name | `(eq channel.name "security-channel")` | | `channel.query` | Channel query | `(contains "security" channel.query)` | | `channel.filters` | Channel filters | `(contains "prod" channel.filters)` | | `channel.accountId` | Channel account ID | `(eq channel.accountId "account-123")` | | `classification.name` | Classification name | `(eq classification.name "CIS")` | | `classification.parent` | Parent classification | `(eq classification.parent "Security")` | | `classification.shortName` | Classification short name | `(contains "CIS" classification.shortName)` | | `classification.description` | Classification description | `(contains "security" classification.description)` | | `classification.annotations` | Classification annotations | `(eq classification.annotations.stable true)` | Note: There is also a `$` object which represents "this" and changes behavior based on what is being returned. If executed against rules then it is a `finding`, if executed against channels it is a `channel`, and if executed against classifications then it is a `classification`. ## Data Types | Type | Syntax | Example | | ----------- | ----------------- | ----------------- | | **String** | `"text"` | `"aws_s3_bucket"` | | **Number** | `123` or `-42.5` | `1` or `1000.0` | | **Boolean** | `true` or `false` | `true` | | **Null** | `null` | `null` | | **Regex** | `/pattern/flags` | `/aws_.*/i` | ### String Escaping * Use `\"` for quotes: `"He said \"Hello\""` * Use `\\` for backslashes: `"path\\to\\file"` ### Regex Escaping * Use `\/` for forward slashes: `/path\/to\/file/` * Use `\\` for backslashes: `/path\\to\\file/` ## Common Patterns ### Find Rules by Resource Type ```javascript (contains "aws_s3_bucket" $.resource) (matches /aws_.*_bucket/i $.resource) ``` ### Exclude Test/Deprecated Rules ```javascript (not (any "test" $.metadata)) (not (contains "deprecated" $.name)) (not (any "deprecated" $.metadata)) ``` Note: The positive can also be used in a filter. ### Complex Filtering ```javascript (and (eq finding.type "security") (not (any "deprecated" finding.metadata.annotations)) (any "prod" finding.metadata) (contains "aws" finding.metadata.annotations["resource"]) ) ``` ## Troubleshooting ### Common Issues 1. **Query Syntax Errors** * Ensure all parentheses are balanced * Use proper string escaping * Check operator argument counts 2. **Field Not Found** * Unknown fields default to `$.body` search * Use dot notation for nested fields * Check field names in the reference table 3. **Regex Issues** * Use proper escaping for special characters * Add flags like `i` for case-insensitive matching * Test regex patterns separately 4. **`any()` Function Issues** * **Error**: `any() requires exactly 2 args` * **Solution**: Use `(any needle field)` for single values, or use `OR` for multiple values ```javascript // ❌ WRONG: Too many arguments (any "s3" "ec2" "rds" $.services) // Error: requires 2 args // ✅ CORRECT: Single value search (any "prod" $.metadata) // ✅ CORRECT: Multiple values using OR (or (any "prod" $.metadata) (any "staging" $.metadata)) ``` * **Memory Errors**: Complex JSON searches can cause out-of-memory * **Solution**: Break complex queries into smaller parts or use alternatives like `contains` 5. **Performance Considerations** * Use specific field references when possible * Avoid overly complex nested queries * Consider using `contains` over `any` for simple text searches * Be cautious with `any` on very large JSON structures ### Debugging Tips 1. **Start Simple**: Begin with basic queries and add complexity gradually 2. **Test Components**: Test individual parts of complex queries 3. **Use Examples**: Reference the examples in this guide 4. **Check Syntax**: Ensure proper S-Expression syntax # Rule Service API The ORL Rule Service is what stores and serves rules for both Gomboc.AI and local evaluation. Access is controlled via an [API token](/api). This [script](/orl/publish/orl-rule-service-api/script) can be used access the API via a PAT. # Script The following script executes commands against the rules service. Set `RULE_SERVICE_TOKEN` to the PAT before you execute the script: `export RULE_SERVICE_TOKEN="my token"` To delete a object add a `delete-after` annotation that is a date. To the date of execution is after that date then the rule is removed instead of updated. Once the rule is confirmed to have been deleted it can be removed from the file system. ```bash #!/bin/bash RULE_SERVICE_URL=https://rules.app.gomboc.ai if ! which curl > /dev/null; then echo "curl is not installed" exit 1 fi if ! which yq > /dev/null; then echo "yq is not installed" exit 1 fi if [[ -z "$RULE_SERVICE_TOKEN" ]]; then echo "RULE_SERVICE_TOKEN is not set" exit 1 fi list_classifications() { echo "Listing classifications $@" local page=1 while true; do local response=$(curl -s "$RULE_SERVICE_URL/api/v1/classifications/search" \ -G \ -H "Authorization: Bearer $RULE_SERVICE_TOKEN" \ -H "Content-Type: application/json" \ -d "query=(not%20(eq%20%24.name%20%22%22))&page=$page") echo "$response" | jq -r '.data' local classifications=$(echo "$response" | jq -r '.data.classifications') if [[ "$classifications" == "[]" ]]; then break fi page=$((page + 1)) done } list_channels() { echo "Listing channels" local page=1 while true; do local response=$(curl -s "$RULE_SERVICE_URL/api/v1/channels/search" \ -G \ -H "Authorization: Bearer $RULE_SERVICE_TOKEN" \ -H "Content-Type: application/json" \ -d "query=(not%20(eq%20%24.name%20%22%22))&page=$page") echo "$response" | jq -r '.' local channels=$(echo "$response" | jq -r '.data.channels') if [[ "$channels" == "[]" ]]; then break fi page=$((page + 1)) done } list_rules() { echo "Listing rules" local page=1 while true; do local response=$(curl -s "$RULE_SERVICE_URL/api/v1/rules/search" \ -G \ -H "Authorization: Bearer $RULE_SERVICE_TOKEN" \ -H "Content-Type: application/json" \ -d "query=(not%20(eq%20%24.name%20%22%22))&page=$page") echo "$response" | jq -r '.data' local rules=$(echo "$response" | jq -r '.data.rules') if [[ "$rules" == "[]" ]]; then break fi page=$((page + 1)) done } # upsert_raw # can only upsert raw rules service object from yaml files upsert_raw() { local type=$1 shift 1 # List all yaml files in the provided directory, 1 level deep local files=$(find "$1" -maxdepth 1 -type f -name '*.yaml' | sort) # Loop through each file for file in $files; do echo "Upserting $file" # if rule contains "delete-after" annotation then check the date and if it is in the past and ignore the rule if yq -e '.annotations["delete-after"]' "$file" > /dev/null 2>&1; then delete_after=$(yq -e '.annotations["delete-after"]' "$file") if [[ "$(date +%Y-%m-%d)" > "$delete_after" ]]; then echo -e "\tIgnoring $file because it is in the past ($delete_after)" continue fi fi # convert to json json=$(yq -o=json "$file") # Because updates are more common we try to update first, then fall back to create local response=$(curl -w "%{http_code}" -X PUT "$RULE_SERVICE_URL/api/v1/$type/update" \ -H "Authorization: Bearer $RULE_SERVICE_TOKEN" \ -H "Content-Type: application/json" \ -d "$json" -o /dev/null 2>/dev/null) if [[ "$response" -ne 200 ]]; then echo -e "\tcouldn't update, trying create (response: $response)" response=$(curl -w "%{http_code}" -X POST "$RULE_SERVICE_URL/api/v1/$type/create" \ -H "Authorization: Bearer $RULE_SERVICE_TOKEN" \ -H "Content-Type: application/json" \ -d "$json" -o /dev/null 2>/dev/null) if [[ "$response" -ne 200 ]]; then echo -e "\tFailed to create (response: $response)" exit 1 fi fi echo -e "\tSuccessfully upserted $type $file" done # recurse local dirs=$(find "$1" -mindepth 1 -maxdepth 1 -type d | sort) for dir in $dirs; do upsert_raw "$type" "$dir" done } # delete_raw # can only delete raw rules service object from yaml files # if the `delete-after` annotation is in the past delete_raw() { local type=$1 shift 1 echo "Deleting $type" local glob="*.yaml" if [[ "$type" == "rules" ]]; then glob="*.orl" fi local files=$(find "$1" -mindepth 1 -maxdepth 1 -type f,l -name "$glob" | sort) # Loop through each file for file in $files; do echo "Processing $file" # if rule contains "delete-after" annotation then check the date and if it is in the past and ignore the rule delete_after=$(yq -e '.metadata.annotations["delete-after"]' "$file" 2>/dev/null) if [[ "$delete_after" == "null" || "$delete_after" == "" ]]; then echo "No delete-after annotation found in $file, skipping" continue fi if [[ "$delete_after" > "$(date +%Y-%m-%d)" ]]; then echo "Ignoring $file because it should not be deleted until $delete_after" continue fi local name=$(yq -e '.metadata.name' "$file" 2>/dev/null) echo "Name: '$name'" local response=$(curl -w "%{http_code}" "$RULE_SERVICE_URL/api/v1/$type/delete" \ -X DELETE \ -G \ -H "Authorization: Bearer $RULE_SERVICE_TOKEN" \ --data-urlencode "name=$name" -o /dev/null 2>/dev/null) if [[ "$response" -ne 200 && "$response" -ne 404 ]]; then echo -e "\tFailed to delete $name in $file ($response)" exit 1 fi echo -e "\tSuccessfully deleted $type $name in $file" done } main() { local command=$1 local type=$2 shift 2 case "${command} ${type}" in "delete channels") delete_raw "channels" "$@" ;; "delete classifications") delete_raw "classifications" "$@" ;; "delete rules") delete_raw "rules" "$@" ;; "list classifications") list_classifications "$@" ;; "list channels") list_channels "$@" ;; "list rules") list_rules "$@" ;; "upsert channels") upsert_raw "channels" "$@" ;; "upsert classifications") upsert_raw "classifications" "$@" ;; *) echo "Invalid command: ${command} ${type}" echo "Usage: $0 [...]" echo "Valid commands:" echo " delete channels " echo " delete classifications " echo " delete rules " echo " list classifications" echo " list channels" echo " list rules" echo " upsert channels " echo " upsert classifications " echo echo "NOTE: delete and upsert check for the delete-after annotation in the yaml file" echo "upsert will not update an item past the delete-after date" echo "delete will only delete items if the delete-after date is in the past" exit 1 ;; esac } main "$@" ``` # Rules Rule management and versioning ## POST /api/v1/rules/create > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Rules","description":"Rule management and versioning"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/rules/create":{"post":{"operationId":"PostApiV1RulesCreate","tags":["Rules"],"requestBody":{"description":"POST /api/v1/rules/create Request body","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1RulesCreateRequestBody"}}},"required":true},"responses":{"200":{"description":"POST /api/v1/rules/create Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1RulesCreatePositiveResponse"}}}},"400":{"description":"POST /api/v1/rules/create Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1RulesCreateNegativeResponse"}}}}}}}},"components":{"schemas":{"PostApiV1RulesCreateRequestBody":{"type":"object","properties":{"type":{"type":"string"},"version":{"type":"string"},"iacLanguage":{"type":"string"},"name":{"type":"string"},"classificationNames":{"type":"array","items":{"type":"string"}},"classifications":{"type":"array","items":{"type":"object","properties":{"name":{"type":"string"},"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"}},"required":["name"]}},"shortName":{"type":"string"},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"metadata":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"body":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"revisionData":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"active":{"default":false,"type":"boolean"}},"required":["type","version","iacLanguage","name"]},"PostApiV1RulesCreatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"type":{"type":"string"},"version":{"type":"string"},"iacLanguage":{"type":"string"},"name":{"type":"string"},"shortName":{"type":["string","null"]},"revision":{"type":"number"},"revisions":{"type":"array","items":{"type":"number"}},"classificationPaths":{"type":"array","items":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"shortName":{"type":["string","null"]}},"required":["accountId","name","shortName"],"additionalProperties":false}}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"metadata":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"body":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","type","version","iacLanguage","name","shortName","revision","revisions","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"PostApiV1RulesCreateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## GET /api/v1/rules/get > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Rules","description":"Rule management and versioning"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/rules/get":{"get":{"operationId":"GetApiV1RulesGet","tags":["Rules"],"parameters":[{"name":"name","in":"query","required":true,"description":"GET /api/v1/rules/get Parameter","schema":{"$ref":"#/components/schemas/GetApiV1RulesGetParameterName"}},{"name":"includeClassifications","in":"query","required":false,"description":"GET /api/v1/rules/get Parameter","schema":{"$ref":"#/components/schemas/GetApiV1RulesGetParameterIncludeClassifications"}}],"responses":{"200":{"description":"GET /api/v1/rules/get Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetApiV1RulesGetPositiveResponse"}}}},"400":{"description":"GET /api/v1/rules/get Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetApiV1RulesGetNegativeResponse"}}}}}}}},"components":{"schemas":{"GetApiV1RulesGetParameterName":{"type":"string"},"GetApiV1RulesGetParameterIncludeClassifications":{"default":1,"type":"number"},"GetApiV1RulesGetPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"type":{"type":"string"},"version":{"type":"string"},"iacLanguage":{"type":"string"},"name":{"type":"string"},"shortName":{"type":["string","null"]},"revision":{"type":"number"},"revisions":{"type":"array","items":{"type":"number"}},"classificationPaths":{"type":"array","items":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"shortName":{"type":["string","null"]}},"required":["accountId","name","shortName"],"additionalProperties":false}}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"metadata":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"body":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","type","version","iacLanguage","name","shortName","revision","revisions","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"GetApiV1RulesGetNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## HEAD /api/v1/rules/get > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Rules","description":"Rule management and versioning"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/rules/get":{"head":{"operationId":"HeadApiV1RulesGet","tags":["Rules"],"parameters":[{"name":"name","in":"query","required":true,"description":"HEAD /api/v1/rules/get Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1RulesGetParameterName"}},{"name":"includeClassifications","in":"query","required":false,"description":"HEAD /api/v1/rules/get Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1RulesGetParameterIncludeClassifications"}}],"responses":{"200":{"description":"HEAD /api/v1/rules/get Positive response"},"400":{"description":"HEAD /api/v1/rules/get Negative response"}}}}},"components":{"schemas":{"HeadApiV1RulesGetParameterName":{"type":"string"},"HeadApiV1RulesGetParameterIncludeClassifications":{"default":1,"type":"number"}}}} ``` ## PUT /api/v1/rules/update > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Rules","description":"Rule management and versioning"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/rules/update":{"put":{"operationId":"PutApiV1RulesUpdate","tags":["Rules"],"requestBody":{"description":"PUT /api/v1/rules/update Request body","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PutApiV1RulesUpdateRequestBody"}}},"required":true},"responses":{"200":{"description":"PUT /api/v1/rules/update Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PutApiV1RulesUpdatePositiveResponse"}}}},"400":{"description":"PUT /api/v1/rules/update Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PutApiV1RulesUpdateNegativeResponse"}}}}}}}},"components":{"schemas":{"PutApiV1RulesUpdateRequestBody":{"type":"object","properties":{"type":{"type":"string"},"version":{"type":"string"},"iacLanguage":{"type":"string"},"classificationNames":{"type":"array","items":{"type":"string"}},"classifications":{"type":"array","items":{"type":"object","properties":{"name":{"type":"string"},"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"}},"required":["name"]}},"shortName":{"type":"string"},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"metadata":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"body":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"revisionData":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"active":{"default":false,"type":"boolean"},"name":{"type":"string"}},"required":["name"]},"PutApiV1RulesUpdatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"type":{"type":"string"},"version":{"type":"string"},"iacLanguage":{"type":"string"},"name":{"type":"string"},"shortName":{"type":["string","null"]},"revision":{"type":"number"},"revisions":{"type":"array","items":{"type":"number"}},"classificationPaths":{"type":"array","items":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"shortName":{"type":["string","null"]}},"required":["accountId","name","shortName"],"additionalProperties":false}}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"metadata":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"body":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","type","version","iacLanguage","name","shortName","revision","revisions","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"PutApiV1RulesUpdateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## DELETE /api/v1/rules/delete > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Rules","description":"Rule management and versioning"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/rules/delete":{"delete":{"operationId":"DeleteApiV1RulesDelete","tags":["Rules"],"parameters":[{"name":"name","in":"query","required":true,"description":"DELETE /api/v1/rules/delete Parameter","schema":{"$ref":"#/components/schemas/DeleteApiV1RulesDeleteParameterName"}},{"name":"revision","in":"query","required":false,"description":"DELETE /api/v1/rules/delete Parameter","schema":{"$ref":"#/components/schemas/DeleteApiV1RulesDeleteParameterRevision"}},{"name":"all","in":"query","required":false,"description":"DELETE /api/v1/rules/delete Parameter","schema":{"$ref":"#/components/schemas/DeleteApiV1RulesDeleteParameterAll"}}],"responses":{"200":{"description":"DELETE /api/v1/rules/delete Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/DeleteApiV1RulesDeletePositiveResponse"}}}},"400":{"description":"DELETE /api/v1/rules/delete Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/DeleteApiV1RulesDeleteNegativeResponse"}}}}}}}},"components":{"schemas":{"DeleteApiV1RulesDeleteParameterName":{"type":"string"},"DeleteApiV1RulesDeleteParameterRevision":{"type":"number"},"DeleteApiV1RulesDeleteParameterAll":{"type":"boolean"},"DeleteApiV1RulesDeletePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"success":{"type":"boolean"}},"required":["success"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"DeleteApiV1RulesDeleteNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## GET /api/v1/rules/search > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Rules","description":"Rule management and versioning"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/rules/search":{"get":{"operationId":"GetApiV1RulesSearch","tags":["Rules"],"parameters":[{"name":"page","in":"query","required":false,"description":"GET /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1RulesSearchParameterPage"}},{"name":"perPage","in":"query","required":false,"description":"GET /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1RulesSearchParameterPerPage"}},{"name":"query","in":"query","required":false,"description":"GET /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1RulesSearchParameterQuery"}},{"name":"filters","in":"query","required":false,"description":"GET /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1RulesSearchParameterFilters"}},{"name":"filters[]","in":"query","required":false,"description":"GET /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1RulesSearchParameterFilters"}},{"name":"type","in":"query","required":false,"description":"GET /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1RulesSearchParameterType"}},{"name":"iacLanguage","in":"query","required":false,"description":"GET /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1RulesSearchParameterIacLanguage"}},{"name":"includeClassifications","in":"query","required":false,"description":"GET /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1RulesSearchParameterIncludeClassifications"}}],"responses":{"200":{"description":"GET /api/v1/rules/search Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetApiV1RulesSearchPositiveResponse"}}}},"400":{"description":"GET /api/v1/rules/search Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetApiV1RulesSearchNegativeResponse"}}}}}}}},"components":{"schemas":{"GetApiV1RulesSearchParameterPage":{"default":1,"type":"number"},"GetApiV1RulesSearchParameterPerPage":{"default":20,"type":"number"},"GetApiV1RulesSearchParameterQuery":{"type":"string"},"GetApiV1RulesSearchParameterFilters":{"anyOf":[{"type":"string"},{"type":"array","items":{"type":"string"}}]},"GetApiV1RulesSearchParameterType":{"type":"string"},"GetApiV1RulesSearchParameterIacLanguage":{"type":"string"},"GetApiV1RulesSearchParameterIncludeClassifications":{"default":1,"type":"number"},"GetApiV1RulesSearchPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"rules":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"type":{"type":"string"},"version":{"type":"string"},"iacLanguage":{"type":"string"},"name":{"type":"string"},"shortName":{"type":["string","null"]},"revision":{"type":"number"},"revisions":{"type":"array","items":{"type":"number"}},"classificationPaths":{"type":"array","items":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"shortName":{"type":["string","null"]}},"required":["accountId","name","shortName"],"additionalProperties":false}}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"metadata":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"body":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","type","version","iacLanguage","name","shortName","revision","revisions","id","createdAt","updatedAt"],"additionalProperties":false}},"total":{"type":"number"},"page":{"type":"number"},"perPage":{"type":"number"}},"required":["rules","total","page","perPage"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"GetApiV1RulesSearchNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## HEAD /api/v1/rules/search > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Rules","description":"Rule management and versioning"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/rules/search":{"head":{"operationId":"HeadApiV1RulesSearch","tags":["Rules"],"parameters":[{"name":"page","in":"query","required":false,"description":"HEAD /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1RulesSearchParameterPage"}},{"name":"perPage","in":"query","required":false,"description":"HEAD /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1RulesSearchParameterPerPage"}},{"name":"query","in":"query","required":false,"description":"HEAD /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1RulesSearchParameterQuery"}},{"name":"filters","in":"query","required":false,"description":"HEAD /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1RulesSearchParameterFilters"}},{"name":"filters[]","in":"query","required":false,"description":"HEAD /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1RulesSearchParameterFilters"}},{"name":"type","in":"query","required":false,"description":"HEAD /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1RulesSearchParameterType"}},{"name":"iacLanguage","in":"query","required":false,"description":"HEAD /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1RulesSearchParameterIacLanguage"}},{"name":"includeClassifications","in":"query","required":false,"description":"HEAD /api/v1/rules/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1RulesSearchParameterIncludeClassifications"}}],"responses":{"200":{"description":"HEAD /api/v1/rules/search Positive response"},"400":{"description":"HEAD /api/v1/rules/search Negative response"}}}}},"components":{"schemas":{"HeadApiV1RulesSearchParameterPage":{"default":1,"type":"number"},"HeadApiV1RulesSearchParameterPerPage":{"default":20,"type":"number"},"HeadApiV1RulesSearchParameterQuery":{"type":"string"},"HeadApiV1RulesSearchParameterFilters":{"anyOf":[{"type":"string"},{"type":"array","items":{"type":"string"}}]},"HeadApiV1RulesSearchParameterType":{"type":"string"},"HeadApiV1RulesSearchParameterIacLanguage":{"type":"string"},"HeadApiV1RulesSearchParameterIncludeClassifications":{"default":1,"type":"number"}}}} ``` ## PUT /api/v1/rules/activate > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Rules","description":"Rule management and versioning"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/rules/activate":{"put":{"operationId":"PutApiV1RulesActivate","tags":["Rules"],"requestBody":{"description":"PUT /api/v1/rules/activate Request body","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PutApiV1RulesActivateRequestBody"}}},"required":true},"responses":{"200":{"description":"PUT /api/v1/rules/activate Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PutApiV1RulesActivatePositiveResponse"}}}},"400":{"description":"PUT /api/v1/rules/activate Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PutApiV1RulesActivateNegativeResponse"}}}}}}}},"components":{"schemas":{"PutApiV1RulesActivateRequestBody":{"type":"object","properties":{"name":{"type":"string"},"revision":{"type":"number"}},"required":["name","revision"]},"PutApiV1RulesActivatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"success":{"type":"boolean"}},"required":["success"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"PutApiV1RulesActivateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` # Classifications Classification hierarchy management ## POST /api/v1/classifications/create > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Classifications","description":"Classification hierarchy management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/classifications/create":{"post":{"operationId":"PostApiV1ClassificationsCreate","tags":["Classifications"],"requestBody":{"description":"POST /api/v1/classifications/create Request body","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1ClassificationsCreateRequestBody"}}},"required":true},"responses":{"200":{"description":"POST /api/v1/classifications/create Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1ClassificationsCreatePositiveResponse"}}}},"400":{"description":"POST /api/v1/classifications/create Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1ClassificationsCreateNegativeResponse"}}}}}}}},"components":{"schemas":{"PostApiV1ClassificationsCreateRequestBody":{"type":"object","properties":{"name":{"type":"string"},"parent":{"type":"string"},"shortName":{"type":"string"},"description":{"type":"string"},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["name"]},"PostApiV1ClassificationsCreatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"parent":{"type":["string","null"]},"shortName":{"type":["string","null"]},"description":{"type":["string","null"]},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{},"parentPath":{"type":"array","items":{"type":"string"}},"children":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["accountId","name","parent","shortName","description","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"PostApiV1ClassificationsCreateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## GET /api/v1/classifications/get > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Classifications","description":"Classification hierarchy management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/classifications/get":{"get":{"operationId":"GetApiV1ClassificationsGet","tags":["Classifications"],"parameters":[{"name":"name","in":"query","required":true,"description":"GET /api/v1/classifications/get Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ClassificationsGetParameterName"}},{"name":"parents","in":"query","required":false,"description":"GET /api/v1/classifications/get Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ClassificationsGetParameterParents"}},{"name":"children","in":"query","required":false,"description":"GET /api/v1/classifications/get Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ClassificationsGetParameterChildren"}},{"name":"expandChildren","in":"query","required":false,"description":"GET /api/v1/classifications/get Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ClassificationsGetParameterExpandChildren"}}],"responses":{"200":{"description":"GET /api/v1/classifications/get Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetApiV1ClassificationsGetPositiveResponse"}}}},"400":{"description":"GET /api/v1/classifications/get Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetApiV1ClassificationsGetNegativeResponse"}}}}}}}},"components":{"schemas":{"GetApiV1ClassificationsGetParameterName":{"type":"string"},"GetApiV1ClassificationsGetParameterParents":{"default":0,"type":"number"},"GetApiV1ClassificationsGetParameterChildren":{"default":0,"type":"number"},"GetApiV1ClassificationsGetParameterExpandChildren":{"default":false,"type":"boolean"},"GetApiV1ClassificationsGetPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"parent":{"type":["string","null"]},"shortName":{"type":["string","null"]},"description":{"type":["string","null"]},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{},"parentPath":{"type":"array","items":{"type":"string"}},"children":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["accountId","name","parent","shortName","description","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"GetApiV1ClassificationsGetNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## HEAD /api/v1/classifications/get > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Classifications","description":"Classification hierarchy management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/classifications/get":{"head":{"operationId":"HeadApiV1ClassificationsGet","tags":["Classifications"],"parameters":[{"name":"name","in":"query","required":true,"description":"HEAD /api/v1/classifications/get Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ClassificationsGetParameterName"}},{"name":"parents","in":"query","required":false,"description":"HEAD /api/v1/classifications/get Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ClassificationsGetParameterParents"}},{"name":"children","in":"query","required":false,"description":"HEAD /api/v1/classifications/get Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ClassificationsGetParameterChildren"}},{"name":"expandChildren","in":"query","required":false,"description":"HEAD /api/v1/classifications/get Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ClassificationsGetParameterExpandChildren"}}],"responses":{"200":{"description":"HEAD /api/v1/classifications/get Positive response"},"400":{"description":"HEAD /api/v1/classifications/get Negative response"}}}}},"components":{"schemas":{"HeadApiV1ClassificationsGetParameterName":{"type":"string"},"HeadApiV1ClassificationsGetParameterParents":{"default":0,"type":"number"},"HeadApiV1ClassificationsGetParameterChildren":{"default":0,"type":"number"},"HeadApiV1ClassificationsGetParameterExpandChildren":{"default":false,"type":"boolean"}}}} ``` ## PUT /api/v1/classifications/update > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Classifications","description":"Classification hierarchy management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/classifications/update":{"put":{"operationId":"PutApiV1ClassificationsUpdate","tags":["Classifications"],"requestBody":{"description":"PUT /api/v1/classifications/update Request body","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PutApiV1ClassificationsUpdateRequestBody"}}},"required":true},"responses":{"200":{"description":"PUT /api/v1/classifications/update Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PutApiV1ClassificationsUpdatePositiveResponse"}}}},"400":{"description":"PUT /api/v1/classifications/update Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PutApiV1ClassificationsUpdateNegativeResponse"}}}}}}}},"components":{"schemas":{"PutApiV1ClassificationsUpdateRequestBody":{"type":"object","properties":{"name":{"type":"string"},"parent":{"type":"string"},"shortName":{"type":"string"},"description":{"type":"string"},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["name"]},"PutApiV1ClassificationsUpdatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"parent":{"type":["string","null"]},"shortName":{"type":["string","null"]},"description":{"type":["string","null"]},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{},"parentPath":{"type":"array","items":{"type":"string"}},"children":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["accountId","name","parent","shortName","description","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"PutApiV1ClassificationsUpdateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## DELETE /api/v1/classifications/delete > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Classifications","description":"Classification hierarchy management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/classifications/delete":{"delete":{"operationId":"DeleteApiV1ClassificationsDelete","tags":["Classifications"],"parameters":[{"name":"name","in":"query","required":true,"description":"DELETE /api/v1/classifications/delete Parameter","schema":{"$ref":"#/components/schemas/DeleteApiV1ClassificationsDeleteParameterName"}}],"responses":{"200":{"description":"DELETE /api/v1/classifications/delete Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/DeleteApiV1ClassificationsDeletePositiveResponse"}}}},"400":{"description":"DELETE /api/v1/classifications/delete Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/DeleteApiV1ClassificationsDeleteNegativeResponse"}}}}}}}},"components":{"schemas":{"DeleteApiV1ClassificationsDeleteParameterName":{"type":"string"},"DeleteApiV1ClassificationsDeletePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"success":{"type":"boolean"}},"required":["success"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"DeleteApiV1ClassificationsDeleteNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## GET /api/v1/classifications/search > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Classifications","description":"Classification hierarchy management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/classifications/search":{"get":{"operationId":"GetApiV1ClassificationsSearch","tags":["Classifications"],"parameters":[{"name":"page","in":"query","required":false,"description":"GET /api/v1/classifications/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ClassificationsSearchParameterPage"}},{"name":"perPage","in":"query","required":false,"description":"GET /api/v1/classifications/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ClassificationsSearchParameterPerPage"}},{"name":"query","in":"query","required":false,"description":"GET /api/v1/classifications/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ClassificationsSearchParameterQuery"}},{"name":"filters","in":"query","required":false,"description":"GET /api/v1/classifications/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ClassificationsSearchParameterFilters"}},{"name":"filters[]","in":"query","required":false,"description":"GET /api/v1/classifications/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ClassificationsSearchParameterFilters"}}],"responses":{"200":{"description":"GET /api/v1/classifications/search Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetApiV1ClassificationsSearchPositiveResponse"}}}},"400":{"description":"GET /api/v1/classifications/search Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetApiV1ClassificationsSearchNegativeResponse"}}}}}}}},"components":{"schemas":{"GetApiV1ClassificationsSearchParameterPage":{"default":1,"type":"number"},"GetApiV1ClassificationsSearchParameterPerPage":{"default":20,"type":"number"},"GetApiV1ClassificationsSearchParameterQuery":{"type":"string"},"GetApiV1ClassificationsSearchParameterFilters":{"anyOf":[{"type":"string"},{"type":"array","items":{"type":"string"}}]},"GetApiV1ClassificationsSearchPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"classifications":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"parent":{"type":["string","null"]},"shortName":{"type":["string","null"]},"description":{"type":["string","null"]},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{},"parentPath":{"type":"array","items":{"type":"string"}},"children":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["accountId","name","parent","shortName","description","id","createdAt","updatedAt"],"additionalProperties":false}},"total":{"type":"number"},"page":{"type":"number"},"perPage":{"type":"number"}},"required":["classifications","total","page","perPage"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"GetApiV1ClassificationsSearchNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## HEAD /api/v1/classifications/search > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Classifications","description":"Classification hierarchy management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/classifications/search":{"head":{"operationId":"HeadApiV1ClassificationsSearch","tags":["Classifications"],"parameters":[{"name":"page","in":"query","required":false,"description":"HEAD /api/v1/classifications/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ClassificationsSearchParameterPage"}},{"name":"perPage","in":"query","required":false,"description":"HEAD /api/v1/classifications/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ClassificationsSearchParameterPerPage"}},{"name":"query","in":"query","required":false,"description":"HEAD /api/v1/classifications/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ClassificationsSearchParameterQuery"}},{"name":"filters","in":"query","required":false,"description":"HEAD /api/v1/classifications/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ClassificationsSearchParameterFilters"}},{"name":"filters[]","in":"query","required":false,"description":"HEAD /api/v1/classifications/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ClassificationsSearchParameterFilters"}}],"responses":{"200":{"description":"HEAD /api/v1/classifications/search Positive response"},"400":{"description":"HEAD /api/v1/classifications/search Negative response"}}}}},"components":{"schemas":{"HeadApiV1ClassificationsSearchParameterPage":{"default":1,"type":"number"},"HeadApiV1ClassificationsSearchParameterPerPage":{"default":20,"type":"number"},"HeadApiV1ClassificationsSearchParameterQuery":{"type":"string"},"HeadApiV1ClassificationsSearchParameterFilters":{"anyOf":[{"type":"string"},{"type":"array","items":{"type":"string"}}]}}}} ``` # Channels Channel and search management ## POST /api/v1/channels/create > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Channels","description":"Channel and search management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/channels/create":{"post":{"operationId":"PostApiV1ChannelsCreate","tags":["Channels"],"requestBody":{"description":"POST /api/v1/channels/create Request body","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1ChannelsCreateRequestBody"}}},"required":true},"responses":{"200":{"description":"POST /api/v1/channels/create Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1ChannelsCreatePositiveResponse"}}}},"400":{"description":"POST /api/v1/channels/create Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1ChannelsCreateNegativeResponse"}}}}}}}},"components":{"schemas":{"PostApiV1ChannelsCreateRequestBody":{"type":"object","properties":{"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["name"]},"PostApiV1ChannelsCreatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","name","filters","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"PostApiV1ChannelsCreateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## GET /api/v1/channels/get > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Channels","description":"Channel and search management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/channels/get":{"get":{"operationId":"GetApiV1ChannelsGet","tags":["Channels"],"parameters":[{"name":"name","in":"query","required":false,"description":"GET /api/v1/channels/get Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ChannelsGetParameterName"}}],"responses":{"200":{"description":"GET /api/v1/channels/get Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetApiV1ChannelsGetPositiveResponse"}}}},"400":{"description":"GET /api/v1/channels/get Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetApiV1ChannelsGetNegativeResponse"}}}}}}}},"components":{"schemas":{"GetApiV1ChannelsGetParameterName":{"type":"string"},"GetApiV1ChannelsGetPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","name","filters","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"GetApiV1ChannelsGetNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## HEAD /api/v1/channels/get > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Channels","description":"Channel and search management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/channels/get":{"head":{"operationId":"HeadApiV1ChannelsGet","tags":["Channels"],"parameters":[{"name":"name","in":"query","required":false,"description":"HEAD /api/v1/channels/get Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ChannelsGetParameterName"}}],"responses":{"200":{"description":"HEAD /api/v1/channels/get Positive response"},"400":{"description":"HEAD /api/v1/channels/get Negative response"}}}}},"components":{"schemas":{"HeadApiV1ChannelsGetParameterName":{"type":"string"}}}} ``` ## POST /api/v1/channels/batch/create > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Channels","description":"Channel and search management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/channels/batch/create":{"post":{"operationId":"PostApiV1ChannelsBatchCreate","tags":["Channels"],"requestBody":{"description":"POST /api/v1/channels/batch/create Request body","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1ChannelsBatchCreateRequestBody"}}},"required":true},"responses":{"200":{"description":"POST /api/v1/channels/batch/create Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1ChannelsBatchCreatePositiveResponse"}}}},"400":{"description":"POST /api/v1/channels/batch/create Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1ChannelsBatchCreateNegativeResponse"}}}}}}}},"components":{"schemas":{"PostApiV1ChannelsBatchCreateRequestBody":{"type":"object","properties":{"channels":{"maxItems":200,"type":"array","items":{"type":"object","properties":{"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["name"]}},"onConflict":{"default":"error","type":"string","enum":["error","skip"]}},"required":["channels"]},"PostApiV1ChannelsBatchCreatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"results":{"type":"array","items":{"type":"object","properties":{"name":{"type":"string"},"status":{"type":"string","enum":["created","skipped","error"]},"channel":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","name","filters","id","createdAt","updatedAt"],"additionalProperties":false},"error":{"type":"string"}},"required":["name","status"],"additionalProperties":false}}},"required":["results"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"PostApiV1ChannelsBatchCreateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## POST /api/v1/channels/batch/upsert > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Channels","description":"Channel and search management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/channels/batch/upsert":{"post":{"operationId":"PostApiV1ChannelsBatchUpsert","tags":["Channels"],"requestBody":{"description":"POST /api/v1/channels/batch/upsert Request body","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1ChannelsBatchUpsertRequestBody"}}},"required":true},"responses":{"200":{"description":"POST /api/v1/channels/batch/upsert Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1ChannelsBatchUpsertPositiveResponse"}}}},"400":{"description":"POST /api/v1/channels/batch/upsert Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PostApiV1ChannelsBatchUpsertNegativeResponse"}}}}}}}},"components":{"schemas":{"PostApiV1ChannelsBatchUpsertRequestBody":{"type":"object","properties":{"channels":{"maxItems":200,"type":"array","items":{"type":"object","properties":{"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"name":{"type":"string"}},"required":["name"]}}},"required":["channels"]},"PostApiV1ChannelsBatchUpsertPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"results":{"type":"array","items":{"type":"object","properties":{"name":{"type":"string"},"status":{"type":"string","enum":["created","updated","error"]},"channel":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","name","filters","id","createdAt","updatedAt"],"additionalProperties":false},"error":{"type":"string"}},"required":["name","status"],"additionalProperties":false}}},"required":["results"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"PostApiV1ChannelsBatchUpsertNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## PUT /api/v1/channels/update > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Channels","description":"Channel and search management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/channels/update":{"put":{"operationId":"PutApiV1ChannelsUpdate","tags":["Channels"],"requestBody":{"description":"PUT /api/v1/channels/update Request body","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PutApiV1ChannelsUpdateRequestBody"}}},"required":true},"responses":{"200":{"description":"PUT /api/v1/channels/update Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PutApiV1ChannelsUpdatePositiveResponse"}}}},"400":{"description":"PUT /api/v1/channels/update Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PutApiV1ChannelsUpdateNegativeResponse"}}}}}}}},"components":{"schemas":{"PutApiV1ChannelsUpdateRequestBody":{"type":"object","properties":{"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"name":{"type":"string"}},"required":["name"]},"PutApiV1ChannelsUpdatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","name","filters","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"PutApiV1ChannelsUpdateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## DELETE /api/v1/channels/delete > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Channels","description":"Channel and search management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/channels/delete":{"delete":{"operationId":"DeleteApiV1ChannelsDelete","tags":["Channels"],"parameters":[{"name":"name","in":"query","required":true,"description":"DELETE /api/v1/channels/delete Parameter","schema":{"$ref":"#/components/schemas/DeleteApiV1ChannelsDeleteParameterName"}}],"responses":{"200":{"description":"DELETE /api/v1/channels/delete Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/DeleteApiV1ChannelsDeletePositiveResponse"}}}},"400":{"description":"DELETE /api/v1/channels/delete Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/DeleteApiV1ChannelsDeleteNegativeResponse"}}}}}}}},"components":{"schemas":{"DeleteApiV1ChannelsDeleteParameterName":{"type":"string"},"DeleteApiV1ChannelsDeletePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"success":{"type":"boolean"}},"required":["success"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"DeleteApiV1ChannelsDeleteNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## GET /api/v1/channels/rules > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Channels","description":"Channel and search management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/channels/rules":{"get":{"operationId":"GetApiV1ChannelsRules","tags":["Channels"],"parameters":[{"name":"name","in":"query","required":false,"description":"GET /api/v1/channels/rules Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ChannelsRulesParameterName"}},{"name":"filters","in":"query","required":false,"description":"GET /api/v1/channels/rules Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ChannelsRulesParameterFilters"}},{"name":"filters[]","in":"query","required":false,"description":"GET /api/v1/channels/rules Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ChannelsRulesParameterFilters"}},{"name":"page","in":"query","required":false,"description":"GET /api/v1/channels/rules Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ChannelsRulesParameterPage"}},{"name":"perPage","in":"query","required":false,"description":"GET /api/v1/channels/rules Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ChannelsRulesParameterPerPage"}},{"name":"includeClassifications","in":"query","required":false,"description":"GET /api/v1/channels/rules Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ChannelsRulesParameterIncludeClassifications"}}],"responses":{"200":{"description":"GET /api/v1/channels/rules Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetApiV1ChannelsRulesPositiveResponse"}}}},"400":{"description":"GET /api/v1/channels/rules Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetApiV1ChannelsRulesNegativeResponse"}}}}}}}},"components":{"schemas":{"GetApiV1ChannelsRulesParameterName":{"type":"string"},"GetApiV1ChannelsRulesParameterFilters":{"anyOf":[{"type":"string"},{"type":"array","items":{"type":"string"}}]},"GetApiV1ChannelsRulesParameterPage":{"default":1,"type":"number"},"GetApiV1ChannelsRulesParameterPerPage":{"default":20,"type":"number"},"GetApiV1ChannelsRulesParameterIncludeClassifications":{"default":1,"type":"number"},"GetApiV1ChannelsRulesPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"rules":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"type":{"type":"string"},"version":{"type":"string"},"iacLanguage":{"type":"string"},"name":{"type":"string"},"shortName":{"type":["string","null"]},"revision":{"type":"number"},"revisions":{"type":"array","items":{"type":"number"}},"classificationPaths":{"type":"array","items":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"shortName":{"type":["string","null"]}},"required":["accountId","name","shortName"],"additionalProperties":false}}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"metadata":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"body":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","type","version","iacLanguage","name","shortName","revision","revisions","id","createdAt","updatedAt"],"additionalProperties":false}},"total":{"type":"number"},"page":{"type":"number"},"perPage":{"type":"number"}},"required":["rules","total","page","perPage"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"GetApiV1ChannelsRulesNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## HEAD /api/v1/channels/rules > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Channels","description":"Channel and search management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/channels/rules":{"head":{"operationId":"HeadApiV1ChannelsRules","tags":["Channels"],"parameters":[{"name":"name","in":"query","required":false,"description":"HEAD /api/v1/channels/rules Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ChannelsRulesParameterName"}},{"name":"filters","in":"query","required":false,"description":"HEAD /api/v1/channels/rules Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ChannelsRulesParameterFilters"}},{"name":"filters[]","in":"query","required":false,"description":"HEAD /api/v1/channels/rules Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ChannelsRulesParameterFilters"}},{"name":"page","in":"query","required":false,"description":"HEAD /api/v1/channels/rules Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ChannelsRulesParameterPage"}},{"name":"perPage","in":"query","required":false,"description":"HEAD /api/v1/channels/rules Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ChannelsRulesParameterPerPage"}},{"name":"includeClassifications","in":"query","required":false,"description":"HEAD /api/v1/channels/rules Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ChannelsRulesParameterIncludeClassifications"}}],"responses":{"200":{"description":"HEAD /api/v1/channels/rules Positive response"},"400":{"description":"HEAD /api/v1/channels/rules Negative response"}}}}},"components":{"schemas":{"HeadApiV1ChannelsRulesParameterName":{"type":"string"},"HeadApiV1ChannelsRulesParameterFilters":{"anyOf":[{"type":"string"},{"type":"array","items":{"type":"string"}}]},"HeadApiV1ChannelsRulesParameterPage":{"default":1,"type":"number"},"HeadApiV1ChannelsRulesParameterPerPage":{"default":20,"type":"number"},"HeadApiV1ChannelsRulesParameterIncludeClassifications":{"default":1,"type":"number"}}}} ``` ## GET /api/v1/channels/search > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Channels","description":"Channel and search management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/channels/search":{"get":{"operationId":"GetApiV1ChannelsSearch","tags":["Channels"],"parameters":[{"name":"page","in":"query","required":false,"description":"GET /api/v1/channels/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ChannelsSearchParameterPage"}},{"name":"perPage","in":"query","required":false,"description":"GET /api/v1/channels/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ChannelsSearchParameterPerPage"}},{"name":"query","in":"query","required":false,"description":"GET /api/v1/channels/search Parameter","schema":{"$ref":"#/components/schemas/GetApiV1ChannelsSearchParameterQuery"}}],"responses":{"200":{"description":"GET /api/v1/channels/search Positive response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetApiV1ChannelsSearchPositiveResponse"}}}},"400":{"description":"GET /api/v1/channels/search Negative response","content":{"application/json":{"schema":{"$ref":"#/components/schemas/GetApiV1ChannelsSearchNegativeResponse"}}}}}}}},"components":{"schemas":{"GetApiV1ChannelsSearchParameterPage":{"default":1,"type":"number"},"GetApiV1ChannelsSearchParameterPerPage":{"default":20,"type":"number"},"GetApiV1ChannelsSearchParameterQuery":{"type":"string"},"GetApiV1ChannelsSearchPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"channels":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","name","filters","id","createdAt","updatedAt"],"additionalProperties":false}},"total":{"type":"number"},"page":{"type":"number"},"perPage":{"type":"number"}},"required":["channels","total","page","perPage"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false},"GetApiV1ChannelsSearchNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## HEAD /api/v1/channels/search > ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"tags":[{"name":"Channels","description":"Channel and search management"}],"servers":[{"url":"https://rules.app.gomboc.ai"}],"paths":{"/api/v1/channels/search":{"head":{"operationId":"HeadApiV1ChannelsSearch","tags":["Channels"],"parameters":[{"name":"page","in":"query","required":false,"description":"HEAD /api/v1/channels/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ChannelsSearchParameterPage"}},{"name":"perPage","in":"query","required":false,"description":"HEAD /api/v1/channels/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ChannelsSearchParameterPerPage"}},{"name":"query","in":"query","required":false,"description":"HEAD /api/v1/channels/search Parameter","schema":{"$ref":"#/components/schemas/HeadApiV1ChannelsSearchParameterQuery"}}],"responses":{"200":{"description":"HEAD /api/v1/channels/search Positive response"},"400":{"description":"HEAD /api/v1/channels/search Negative response"}}}}},"components":{"schemas":{"HeadApiV1ChannelsSearchParameterPage":{"default":1,"type":"number"},"HeadApiV1ChannelsSearchParameterPerPage":{"default":20,"type":"number"},"HeadApiV1ChannelsSearchParameterQuery":{"type":"string"}}}} ``` # Models ## The GetHealthcheckPositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetHealthcheckPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"status":{"type":"string"},"timestamp":{"type":"string"}},"required":["status","timestamp"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The GetHealthcheckNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetHealthcheckNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The PostApiV1RulesCreatePositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1RulesCreatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"type":{"type":"string"},"version":{"type":"string"},"iacLanguage":{"type":"string"},"name":{"type":"string"},"shortName":{"type":["string","null"]},"revision":{"type":"number"},"revisions":{"type":"array","items":{"type":"number"}},"classificationPaths":{"type":"array","items":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"shortName":{"type":["string","null"]}},"required":["accountId","name","shortName"],"additionalProperties":false}}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"metadata":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"body":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","type","version","iacLanguage","name","shortName","revision","revisions","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The PostApiV1RulesCreateNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1RulesCreateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The PostApiV1RulesCreateRequestBody object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1RulesCreateRequestBody":{"type":"object","properties":{"type":{"type":"string"},"version":{"type":"string"},"iacLanguage":{"type":"string"},"name":{"type":"string"},"classificationNames":{"type":"array","items":{"type":"string"}},"classifications":{"type":"array","items":{"type":"object","properties":{"name":{"type":"string"},"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"}},"required":["name"]}},"shortName":{"type":"string"},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"metadata":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"body":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"revisionData":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"active":{"default":false,"type":"boolean"}},"required":["type","version","iacLanguage","name"]}}}} ``` ## The GetApiV1RulesGetParameterName object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1RulesGetParameterName":{"type":"string"}}}} ``` ## The GetApiV1RulesGetParameterIncludeClassifications object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1RulesGetParameterIncludeClassifications":{"default":1,"type":"number"}}}} ``` ## The GetApiV1RulesGetPositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1RulesGetPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"type":{"type":"string"},"version":{"type":"string"},"iacLanguage":{"type":"string"},"name":{"type":"string"},"shortName":{"type":["string","null"]},"revision":{"type":"number"},"revisions":{"type":"array","items":{"type":"number"}},"classificationPaths":{"type":"array","items":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"shortName":{"type":["string","null"]}},"required":["accountId","name","shortName"],"additionalProperties":false}}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"metadata":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"body":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","type","version","iacLanguage","name","shortName","revision","revisions","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The GetApiV1RulesGetNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1RulesGetNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The HeadApiV1RulesGetParameterName object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1RulesGetParameterName":{"type":"string"}}}} ``` ## The HeadApiV1RulesGetParameterIncludeClassifications object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1RulesGetParameterIncludeClassifications":{"default":1,"type":"number"}}}} ``` ## The PutApiV1RulesUpdatePositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PutApiV1RulesUpdatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"type":{"type":"string"},"version":{"type":"string"},"iacLanguage":{"type":"string"},"name":{"type":"string"},"shortName":{"type":["string","null"]},"revision":{"type":"number"},"revisions":{"type":"array","items":{"type":"number"}},"classificationPaths":{"type":"array","items":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"shortName":{"type":["string","null"]}},"required":["accountId","name","shortName"],"additionalProperties":false}}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"metadata":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"body":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","type","version","iacLanguage","name","shortName","revision","revisions","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The PutApiV1RulesUpdateNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PutApiV1RulesUpdateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The PutApiV1RulesUpdateRequestBody object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PutApiV1RulesUpdateRequestBody":{"type":"object","properties":{"type":{"type":"string"},"version":{"type":"string"},"iacLanguage":{"type":"string"},"classificationNames":{"type":"array","items":{"type":"string"}},"classifications":{"type":"array","items":{"type":"object","properties":{"name":{"type":"string"},"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"}},"required":["name"]}},"shortName":{"type":"string"},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"metadata":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"body":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"revisionData":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"active":{"default":false,"type":"boolean"},"name":{"type":"string"}},"required":["name"]}}}} ``` ## The DeleteApiV1RulesDeleteParameterName object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"DeleteApiV1RulesDeleteParameterName":{"type":"string"}}}} ``` ## The DeleteApiV1RulesDeleteParameterRevision object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"DeleteApiV1RulesDeleteParameterRevision":{"type":"number"}}}} ``` ## The DeleteApiV1RulesDeleteParameterAll object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"DeleteApiV1RulesDeleteParameterAll":{"type":"boolean"}}}} ``` ## The DeleteApiV1RulesDeletePositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"DeleteApiV1RulesDeletePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"success":{"type":"boolean"}},"required":["success"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The DeleteApiV1RulesDeleteNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"DeleteApiV1RulesDeleteNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The GetApiV1RulesSearchParameterPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1RulesSearchParameterPage":{"default":1,"type":"number"}}}} ``` ## The GetApiV1RulesSearchParameterPerPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1RulesSearchParameterPerPage":{"default":20,"type":"number"}}}} ``` ## The GetApiV1RulesSearchParameterQuery object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1RulesSearchParameterQuery":{"type":"string"}}}} ``` ## The GetApiV1RulesSearchParameterFilters object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1RulesSearchParameterFilters":{"anyOf":[{"type":"string"},{"type":"array","items":{"type":"string"}}]}}}} ``` ## The GetApiV1RulesSearchParameterType object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1RulesSearchParameterType":{"type":"string"}}}} ``` ## The GetApiV1RulesSearchParameterIacLanguage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1RulesSearchParameterIacLanguage":{"type":"string"}}}} ``` ## The GetApiV1RulesSearchParameterIncludeClassifications object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1RulesSearchParameterIncludeClassifications":{"default":1,"type":"number"}}}} ``` ## The GetApiV1RulesSearchPositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1RulesSearchPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"rules":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"type":{"type":"string"},"version":{"type":"string"},"iacLanguage":{"type":"string"},"name":{"type":"string"},"shortName":{"type":["string","null"]},"revision":{"type":"number"},"revisions":{"type":"array","items":{"type":"number"}},"classificationPaths":{"type":"array","items":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"shortName":{"type":["string","null"]}},"required":["accountId","name","shortName"],"additionalProperties":false}}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"metadata":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"body":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","type","version","iacLanguage","name","shortName","revision","revisions","id","createdAt","updatedAt"],"additionalProperties":false}},"total":{"type":"number"},"page":{"type":"number"},"perPage":{"type":"number"}},"required":["rules","total","page","perPage"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The GetApiV1RulesSearchNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1RulesSearchNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The HeadApiV1RulesSearchParameterPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1RulesSearchParameterPage":{"default":1,"type":"number"}}}} ``` ## The HeadApiV1RulesSearchParameterPerPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1RulesSearchParameterPerPage":{"default":20,"type":"number"}}}} ``` ## The HeadApiV1RulesSearchParameterQuery object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1RulesSearchParameterQuery":{"type":"string"}}}} ``` ## The HeadApiV1RulesSearchParameterFilters object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1RulesSearchParameterFilters":{"anyOf":[{"type":"string"},{"type":"array","items":{"type":"string"}}]}}}} ``` ## The HeadApiV1RulesSearchParameterType object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1RulesSearchParameterType":{"type":"string"}}}} ``` ## The HeadApiV1RulesSearchParameterIacLanguage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1RulesSearchParameterIacLanguage":{"type":"string"}}}} ``` ## The HeadApiV1RulesSearchParameterIncludeClassifications object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1RulesSearchParameterIncludeClassifications":{"default":1,"type":"number"}}}} ``` ## The PutApiV1RulesActivatePositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PutApiV1RulesActivatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"success":{"type":"boolean"}},"required":["success"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The PutApiV1RulesActivateNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PutApiV1RulesActivateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The PutApiV1RulesActivateRequestBody object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PutApiV1RulesActivateRequestBody":{"type":"object","properties":{"name":{"type":"string"},"revision":{"type":"number"}},"required":["name","revision"]}}}} ``` ## The PostApiV1ClassificationsCreatePositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1ClassificationsCreatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"parent":{"type":["string","null"]},"shortName":{"type":["string","null"]},"description":{"type":["string","null"]},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{},"parentPath":{"type":"array","items":{"type":"string"}},"children":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["accountId","name","parent","shortName","description","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The PostApiV1ClassificationsCreateNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1ClassificationsCreateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The PostApiV1ClassificationsCreateRequestBody object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1ClassificationsCreateRequestBody":{"type":"object","properties":{"name":{"type":"string"},"parent":{"type":"string"},"shortName":{"type":"string"},"description":{"type":"string"},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["name"]}}}} ``` ## The GetApiV1ClassificationsGetParameterName object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ClassificationsGetParameterName":{"type":"string"}}}} ``` ## The GetApiV1ClassificationsGetParameterParents object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ClassificationsGetParameterParents":{"default":0,"type":"number"}}}} ``` ## The GetApiV1ClassificationsGetParameterChildren object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ClassificationsGetParameterChildren":{"default":0,"type":"number"}}}} ``` ## The GetApiV1ClassificationsGetParameterExpandChildren object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ClassificationsGetParameterExpandChildren":{"default":false,"type":"boolean"}}}} ``` ## The GetApiV1ClassificationsGetPositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ClassificationsGetPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"parent":{"type":["string","null"]},"shortName":{"type":["string","null"]},"description":{"type":["string","null"]},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{},"parentPath":{"type":"array","items":{"type":"string"}},"children":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["accountId","name","parent","shortName","description","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The GetApiV1ClassificationsGetNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ClassificationsGetNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The HeadApiV1ClassificationsGetParameterName object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ClassificationsGetParameterName":{"type":"string"}}}} ``` ## The HeadApiV1ClassificationsGetParameterParents object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ClassificationsGetParameterParents":{"default":0,"type":"number"}}}} ``` ## The HeadApiV1ClassificationsGetParameterChildren object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ClassificationsGetParameterChildren":{"default":0,"type":"number"}}}} ``` ## The HeadApiV1ClassificationsGetParameterExpandChildren object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ClassificationsGetParameterExpandChildren":{"default":false,"type":"boolean"}}}} ``` ## The PutApiV1ClassificationsUpdatePositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PutApiV1ClassificationsUpdatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"parent":{"type":["string","null"]},"shortName":{"type":["string","null"]},"description":{"type":["string","null"]},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{},"parentPath":{"type":"array","items":{"type":"string"}},"children":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["accountId","name","parent","shortName","description","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The PutApiV1ClassificationsUpdateNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PutApiV1ClassificationsUpdateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The PutApiV1ClassificationsUpdateRequestBody object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PutApiV1ClassificationsUpdateRequestBody":{"type":"object","properties":{"name":{"type":"string"},"parent":{"type":"string"},"shortName":{"type":"string"},"description":{"type":"string"},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["name"]}}}} ``` ## The DeleteApiV1ClassificationsDeleteParameterName object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"DeleteApiV1ClassificationsDeleteParameterName":{"type":"string"}}}} ``` ## The DeleteApiV1ClassificationsDeletePositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"DeleteApiV1ClassificationsDeletePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"success":{"type":"boolean"}},"required":["success"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The DeleteApiV1ClassificationsDeleteNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"DeleteApiV1ClassificationsDeleteNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The GetApiV1ClassificationsSearchParameterPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ClassificationsSearchParameterPage":{"default":1,"type":"number"}}}} ``` ## The GetApiV1ClassificationsSearchParameterPerPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ClassificationsSearchParameterPerPage":{"default":20,"type":"number"}}}} ``` ## The GetApiV1ClassificationsSearchParameterQuery object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ClassificationsSearchParameterQuery":{"type":"string"}}}} ``` ## The GetApiV1ClassificationsSearchParameterFilters object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ClassificationsSearchParameterFilters":{"anyOf":[{"type":"string"},{"type":"array","items":{"type":"string"}}]}}}} ``` ## The GetApiV1ClassificationsSearchPositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ClassificationsSearchPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"classifications":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"parent":{"type":["string","null"]},"shortName":{"type":["string","null"]},"description":{"type":["string","null"]},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{},"parentPath":{"type":"array","items":{"type":"string"}},"children":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["accountId","name","parent","shortName","description","id","createdAt","updatedAt"],"additionalProperties":false}},"total":{"type":"number"},"page":{"type":"number"},"perPage":{"type":"number"}},"required":["classifications","total","page","perPage"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The GetApiV1ClassificationsSearchNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ClassificationsSearchNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The HeadApiV1ClassificationsSearchParameterPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ClassificationsSearchParameterPage":{"default":1,"type":"number"}}}} ``` ## The HeadApiV1ClassificationsSearchParameterPerPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ClassificationsSearchParameterPerPage":{"default":20,"type":"number"}}}} ``` ## The HeadApiV1ClassificationsSearchParameterQuery object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ClassificationsSearchParameterQuery":{"type":"string"}}}} ``` ## The HeadApiV1ClassificationsSearchParameterFilters object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ClassificationsSearchParameterFilters":{"anyOf":[{"type":"string"},{"type":"array","items":{"type":"string"}}]}}}} ``` ## The PostApiV1ChannelsCreatePositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1ChannelsCreatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","name","filters","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The PostApiV1ChannelsCreateNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1ChannelsCreateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The PostApiV1ChannelsCreateRequestBody object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1ChannelsCreateRequestBody":{"type":"object","properties":{"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["name"]}}}} ``` ## The GetApiV1ChannelsGetParameterName object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsGetParameterName":{"type":"string"}}}} ``` ## The GetApiV1ChannelsGetPositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsGetPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","name","filters","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The GetApiV1ChannelsGetNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsGetNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The HeadApiV1ChannelsGetParameterName object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ChannelsGetParameterName":{"type":"string"}}}} ``` ## The PostApiV1ChannelsBatchCreatePositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1ChannelsBatchCreatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"results":{"type":"array","items":{"type":"object","properties":{"name":{"type":"string"},"status":{"type":"string","enum":["created","skipped","error"]},"channel":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","name","filters","id","createdAt","updatedAt"],"additionalProperties":false},"error":{"type":"string"}},"required":["name","status"],"additionalProperties":false}}},"required":["results"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The PostApiV1ChannelsBatchCreateNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1ChannelsBatchCreateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The PostApiV1ChannelsBatchCreateRequestBody object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1ChannelsBatchCreateRequestBody":{"type":"object","properties":{"channels":{"maxItems":200,"type":"array","items":{"type":"object","properties":{"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}}},"required":["name"]}},"onConflict":{"default":"error","type":"string","enum":["error","skip"]}},"required":["channels"]}}}} ``` ## The PostApiV1ChannelsBatchUpsertPositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1ChannelsBatchUpsertPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"results":{"type":"array","items":{"type":"object","properties":{"name":{"type":"string"},"status":{"type":"string","enum":["created","updated","error"]},"channel":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","name","filters","id","createdAt","updatedAt"],"additionalProperties":false},"error":{"type":"string"}},"required":["name","status"],"additionalProperties":false}}},"required":["results"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The PostApiV1ChannelsBatchUpsertNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1ChannelsBatchUpsertNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The PostApiV1ChannelsBatchUpsertRequestBody object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PostApiV1ChannelsBatchUpsertRequestBody":{"type":"object","properties":{"channels":{"maxItems":200,"type":"array","items":{"type":"object","properties":{"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"name":{"type":"string"}},"required":["name"]}}},"required":["channels"]}}}} ``` ## The PutApiV1ChannelsUpdatePositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PutApiV1ChannelsUpdatePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","name","filters","id","createdAt","updatedAt"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The PutApiV1ChannelsUpdateNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PutApiV1ChannelsUpdateNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The PutApiV1ChannelsUpdateRequestBody object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"PutApiV1ChannelsUpdateRequestBody":{"type":"object","properties":{"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"name":{"type":"string"}},"required":["name"]}}}} ``` ## The DeleteApiV1ChannelsDeleteParameterName object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"DeleteApiV1ChannelsDeleteParameterName":{"type":"string"}}}} ``` ## The DeleteApiV1ChannelsDeletePositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"DeleteApiV1ChannelsDeletePositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"success":{"type":"boolean"}},"required":["success"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The DeleteApiV1ChannelsDeleteNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"DeleteApiV1ChannelsDeleteNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The GetApiV1ChannelsRulesParameterName object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsRulesParameterName":{"type":"string"}}}} ``` ## The GetApiV1ChannelsRulesParameterFilters object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsRulesParameterFilters":{"anyOf":[{"type":"string"},{"type":"array","items":{"type":"string"}}]}}}} ``` ## The GetApiV1ChannelsRulesParameterPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsRulesParameterPage":{"default":1,"type":"number"}}}} ``` ## The GetApiV1ChannelsRulesParameterPerPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsRulesParameterPerPage":{"default":20,"type":"number"}}}} ``` ## The GetApiV1ChannelsRulesParameterIncludeClassifications object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsRulesParameterIncludeClassifications":{"default":1,"type":"number"}}}} ``` ## The GetApiV1ChannelsRulesPositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsRulesPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"rules":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"type":{"type":"string"},"version":{"type":"string"},"iacLanguage":{"type":"string"},"name":{"type":"string"},"shortName":{"type":["string","null"]},"revision":{"type":"number"},"revisions":{"type":"array","items":{"type":"number"}},"classificationPaths":{"type":"array","items":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"shortName":{"type":["string","null"]}},"required":["accountId","name","shortName"],"additionalProperties":false}}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"metadata":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"body":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","type","version","iacLanguage","name","shortName","revision","revisions","id","createdAt","updatedAt"],"additionalProperties":false}},"total":{"type":"number"},"page":{"type":"number"},"perPage":{"type":"number"}},"required":["rules","total","page","perPage"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The GetApiV1ChannelsRulesNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsRulesNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The HeadApiV1ChannelsRulesParameterName object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ChannelsRulesParameterName":{"type":"string"}}}} ``` ## The HeadApiV1ChannelsRulesParameterFilters object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ChannelsRulesParameterFilters":{"anyOf":[{"type":"string"},{"type":"array","items":{"type":"string"}}]}}}} ``` ## The HeadApiV1ChannelsRulesParameterPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ChannelsRulesParameterPage":{"default":1,"type":"number"}}}} ``` ## The HeadApiV1ChannelsRulesParameterPerPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ChannelsRulesParameterPerPage":{"default":20,"type":"number"}}}} ``` ## The HeadApiV1ChannelsRulesParameterIncludeClassifications object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ChannelsRulesParameterIncludeClassifications":{"default":1,"type":"number"}}}} ``` ## The GetApiV1ChannelsSearchParameterPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsSearchParameterPage":{"default":1,"type":"number"}}}} ``` ## The GetApiV1ChannelsSearchParameterPerPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsSearchParameterPerPage":{"default":20,"type":"number"}}}} ``` ## The GetApiV1ChannelsSearchParameterQuery object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsSearchParameterQuery":{"type":"string"}}}} ``` ## The GetApiV1ChannelsSearchPositiveResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsSearchPositiveResponse":{"type":"object","properties":{"status":{"type":"string","const":"success"},"data":{"type":"object","properties":{"channels":{"type":"array","items":{"type":"object","properties":{"accountId":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"name":{"type":"string"},"query":{"type":"string"},"filters":{"type":"array","items":{"type":"string"}},"annotations":{"type":"object","propertyNames":{"type":"string"},"additionalProperties":{}},"id":{"type":"string","format":"uuid","pattern":"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000)$"},"createdAt":{},"updatedAt":{}},"required":["accountId","name","filters","id","createdAt","updatedAt"],"additionalProperties":false}},"total":{"type":"number"},"page":{"type":"number"},"perPage":{"type":"number"}},"required":["channels","total","page","perPage"],"additionalProperties":false}},"required":["status","data"],"additionalProperties":false}}}} ``` ## The GetApiV1ChannelsSearchNegativeResponse object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"GetApiV1ChannelsSearchNegativeResponse":{"type":"object","properties":{"status":{"type":"string","const":"error"},"error":{"type":"object","properties":{"message":{"type":"string"}},"required":["message"],"additionalProperties":false}},"required":["status","error"],"additionalProperties":false}}}} ``` ## The HeadApiV1ChannelsSearchParameterPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ChannelsSearchParameterPage":{"default":1,"type":"number"}}}} ``` ## The HeadApiV1ChannelsSearchParameterPerPage object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ChannelsSearchParameterPerPage":{"default":20,"type":"number"}}}} ``` ## The HeadApiV1ChannelsSearchParameterQuery object ```json {"openapi":"3.1.0","info":{"title":"Rules Service API","version":"1.0.0"},"components":{"schemas":{"HeadApiV1ChannelsSearchParameterQuery":{"type":"string"}}}} ``` # GitHub Workflow Example The following is a sample workflow. It assumes all items to push are in `/final` by object type. It also assumes the [rule service script](/orl/publish/orl-rule-service-api/script) is in the `./bin` directory. ```yaml name: Publish Rules permissions: contents: read on: push: branches: - main pull_request: branches: - main workflow_dispatch: {} env: IMAGE: gombocai/orl:latest RULE_SERVICE_URL: https://rules.app.gomboc.ai RULE_SERVICE_TOKEN: ${{ secrets.RULE_SERVICE_TOKEN}} jobs: push-rules: name: Push Rules to Rules Service runs-on: ubuntu-latest steps: - name: Checkout Code uses: actions/checkout@v4 with: fetch-depth: 0 submodules: true - name: Pull Docker Image run: docker pull ${{ env.IMAGE }} - name: Validate Rulespace run: | docker run --rm \ -v ${{ github.workspace }}:/workspace \ -w /workspace \ ${{ env.IMAGE }} \ walk rulespace ./final/rules - name: Update Channels and Classifications if: github.event_name != 'pull_request' run: | ./bin/rules-service upsert channels ./final/channels ./bin/rules-service upsert classifications ./final/classifications - name: Push Rules to Rules Service if: github.event_name != 'pull_request' env: RULE_SERVICE_URL: ${{ env.RULE_SERVICE_URL }} RULE_SERVICE_TOKEN: ${{ env.RULE_SERVICE_TOKEN }} run: | docker run --rm \ -v ${{ github.workspace }}:/workspace \ -w /workspace \ -e RULE_SERVICE_URL=$RULE_SERVICE_URL \ -e RULE_SERVICE_TOKEN=$RULE_SERVICE_TOKEN \ ${{ env.IMAGE }} \ rules push --url "$RULE_SERVICE_URL" --token "$RULE_SERVICE_TOKEN" ./final/rules - name: Delete Old Channels, Classifications, and Rules if: github.event_name != 'pull_request' run: | ./bin/rules-service delete channels ./final/channels ./bin/rules-service delete classifications ./final/classifications ./bin/rules-service delete rules ./final/rules ``` # Policy Management Gomboc’s **Policy Management** controls which checks and remediations run on each workspace. At a high level: * A **Policy** is a specific control like “Encryption At-Rest with Provider Managed Key”. * A **Framework / Benchmark** is a higher‑level grouping of policies (for example, CIS, NIST, PCI). * A **Policy Set** is a named bundle of policies that you can apply to one or more workspaces. * **ORL (Open Remediation Language)** is a domain specific language developed by Gomboc that evaluates policies on your code and acts as the execution engine for how those policies are enforced by detecting issues and generating deterministic fixes. *** ### How Policy Management Works When you run a scan on a workspace: 1. Choose policies using **simple, high‑level criteria** (categories, severity, frameworks). 2. Gomboc looks at the **Policy Sets** attached to that workspace. 3. It calculates the **effective policies** (the union of policies from those sets). 4. It resolves those policies to the underlying **rules**. 5. ORL runs the rules against your code to: * Detect issues * Apply deterministic fixes *** ### Explore Policy Management Use the guides below to dive into each part of Policy Management. #### **Policy Management Guides**
GuideDescription
Policies LibraryLearn how Gomboc organizes individual policies. Understand the policy catalog, including filtering by severity, cloud provider, resource types, IaC tools, categories, and the individual rules that make up a policy.
Rules
Policy SetsLearn how to bundle policies into named sets (for example, “Org Default Baseline”) and assign multiple Policy Sets per workspace. See how effective policies are computed and how updates to a Policy Set affect future scans.
ORL OverviewUnderstand what ORL (Open Remediation Language) is, how it relates to the Gomboc remediation process, and how ORL rules back the policies you see in the UI across different tools, resource types, and providers.
Custom RulesFor advanced users who need organization‑specific controls. Learn how to author and publish your own ORL rules, map them to policies and frameworks, and surface them in the policy catalog so they can be included in Policy Sets.
# Policy Library The Policy Library provides a centralized view of all available policies for your infrastructure. Each policy defines controls and best practices that can be applied across your code. ### What is a Policy? In Gomboc, a policy is a single, named control that the platform can check and remediate. Each policy represents a set of code issues the platform looks for. It’s backed by one or more internal ORL rules that power detection and a deterministic fix. #### Examples: * “Encryption At-Rest with Provider Managed Key” * “Deletion Protection” * “Immutable Docker Image Tags” ### Each policy has: * **Name and description** – what it checks and why it matters. * **Severity -** describes how impacted your business could be by ignoring the recommendation. * **Risk** – combination operational effort and likelihood of failure by making the change. * **Category** – security, reliability, operations, cost, etc. * **Framework/benchmark mappings** – how it aligns to CIS, NIST CSF, PCI, SOC 2, internal frameworks, and so on. * **Scope over code and platforms** – which code representations and platforms it applies to, including: * **Code resource types** * e.g., storage buckets, databases, load balancers, IAM roles, Kubernetes, etc. * **Tools / IaC formats** * e.g., Terraform, CloudFormation, Kubernetes, Helm, and other supported IaC or config formats. * **Cloud providers / platforms** * e.g., AWS, GCP, Azure, OCI, Kubernetes, and other supported environments. When you activate a policy in the Policy Sets UI, you’re choosing: * What should be enforced (the conceptual control), * Across which tools, code types, and providers (as defined by that policy’s scope). ### Browsing Policies The Policy Library displays all available policies in a searchable table format: * **Search**: Use the search bar to find policies by name, description, or tags * **Tag Filter**: Filter policies by tags such as `terraform`, `AWS`, `kubernetes`, `azure`, `GCP`, `docker` * **Pagination**: Browse through policies with pagination controls # Rules ### What is a Rule? In Gomboc, a **rule** is the executable unit that: * **Finds** issues in the Code * **Applies** a concrete fix to the code Rules are implemented in **ORL** and stored in the Gomboc [**Rules Service**](/orl/publish/orl-rule-service-api). #### The data model has three key objects: 1. **Rule**\ A rule-like object with: * `name` - unique internal identifier * `shortName` - display name * `annotations` - key/value tags (e.g., provider, framework, risk) * `metadata` - extra details (for ORL rules: priority, language, etc.) * `body` / `data` - the ORL rule itself (audit + remediation logic) 2. **Classification**\ Arbitrary groupings of rules (e.g., “Encryption at Rest”)\ Classifications are how we: * Group rules into higher-level concepts (policies & frameworks) * Tag rules with framework mappings and other metadata 3. **Channel**\ A named saved search that returns a set of rules. * Example: `/default`, or `/ruleset/hardening` * Gomboc workspaces/scans refer to channels to decide *which rules to run* ### Publish Rules Learn here how to [publish custom rules](/orl/publish). ### Browsing Rules The Advanced tab displays the individual rules that make up a policy. This is useful for understanding the granular checks that Gomboc performs. #### **Rule Information** Each rule in the Advanced view shows:
FieldDescription
SeverityThe severity level of the rule (Low, Medium, High, Critical)
RiskThe risk level if the rule is violated
RuleThe full rule name and description
Rule IDA unique identifier for the rule (e.g., gomboc-ai/api_key_authentication_for_hashicorp__aws-resources-aws_appsync_graphql_api)
Provider / ResourceThe infrastructure stack this rule applies to
#### **Expanding Rules** Click on any rule row to expand it and view: * **Code Sample**: A fixed code example specific to that rule * **Resource**: The exact resource type the code applies to The expandable rows allow you to quickly review multiple rules and their corresponding remediation code. #### **Example Rule Structure**
# Policy sets ### What is a Policy Set? A **Policy Set** is a named bundle of policies that you can assign to one or more workspaces. Instead of configuring each workspace one policy at a time, you: * Define Policy Sets that represent your security, and operational goals. * Reuse those sets across many workspaces. * Combine multiple sets on the same workspace when needed. *** ### Core Concepts You can: * Attach the same Policy Set to many workspaces. * Attach multiple Policy Sets to a single workspace. For each workspace: * **Effective policies** = union of policies from all attached Policy Sets. *** ### Why Use Policy Sets? Policy Sets help you: * Standardize policy across the organization * Define the “Org Default Baseline” and apply it to all workspaces. * Tailor policy by environment * Use stricter policies for production, and other sets for development. * Align with frameworks and business goals * Create sets like: * “CIS for AWS” * “Cost Optimization” * “High & Critical Security Only” *** ### Policy Set in Gomboc Portal #### Open the Policy Sets Page 1. Go to Policy Sets page in the Gomboc portal. 2. Select the "**Default Policy Set"** (the default policy set is the prebuilt set for first-time setup). 3. See which policies are enabled in the **Active policies"** table. 4. Browse the bottom Gomboc policy library and add the ones you want to the Active policies table to enable this in the Default Policy Set #### Create a New Policy Set 1. Click **Create Policy Set**. 2. Provide: * **Name** * **Description**\ Explain when to use this set and what it is optimized for: * Target environments (prod, staging, dev). * Risk tolerance (e.g., “only high/critical issues” vs “full CIS alignment”). 3. Assign to **Workspaces** #### Add Policies to the Set 1. Use the **policy catalog** to choose which policies to include. You can: * **Search by keyword**\ e.g., “Encryption”, “public access”, “Authentication”. * **Filter by category**\ Security, compliance, reliability, cost optimization, operations, etc. * **Filter by cloud provider / IaC tool/ code resource type**\ e.g., AWS, GCP, Azure, OCI / Terraform, CloudFormation / S3 bucket, kubernetes cluster Select the policies you want and add them to the Policy Set. #### Save the Policy Set 1. Click **Save**. Your new Policy Set is now available to run scans. *** ### How Multiple Policy Sets Interact When you attach **multiple Policy Sets** to a workspace: 1. Gomboc collects the list of policies from each attached set. 2. It merges them into a single effective policy list: * Policies are **de‑duplicated**. 3. At scan time, Gomboc: * Resolves that effective policy list to the underlying rules. * Executes those rules during the scan. *** ### What Happens at Scan Time? When a workspace is scanned: 1. Gomboc calculates the effective policies: * Looks up all Policy Sets attached to the workspace. * Unions their policies. 2. Gomboc’s engine: * Turns those policies into a set of underlying rules. * Runs them against your code. 3. The scan report shows: * Which Policy Sets those policies came from. * Suggested fixes (where applicable). *** ### FAQ
Can I assign multiple Policy Sets to one workspace? Yes. Workspaces support multiple Policy Sets. The effective policy list is the union of all policies in those sets.
What happens if the same policy is in more than one Policy Set? It is applied once. Policy Sets are merged and de‑duplicated at scan time.
If I change a Policy Set, do I affect past scans? No. Past scan results stay as they were. Future scans use the updated Policy Set definition.
# Policy Sets: Backup & Version Control via API Gomboc's Policy Sets can be fully managed through the **Rules Service API**, giving you programmatic access to export, back up, and restore your policy configuration. This is useful for: * **Disaster recovery** — quickly restore your configuration after accidental changes. * **Environment promotion** — copy policy sets from a staging org to production. * **Audit trails** — track every change to your policy configuration in Git history. * **GitOps workflows** — store the desired state of your policy sets in a repository and reconcile it on a schedule. *** ### Prerequisites #### Personal Access Token (PAT) All Rules Service API calls require a Bearer token. Generate one from the Gomboc Portal: 1. Open the account dropdown (top-right corner) → **Settings**. 2. Select **Personal Access Tokens**. 3. Click **Generate Token**, give it a name and an expiry, then click **Create**. 4. Copy the token somewhere safe — it is shown only once. Set it as an environment variable for the examples below: ```bash export GOMBOC_TOKEN="" ``` The scripts on this page also require [`jq`](https://stedolan.github.io/jq/) and `curl`. #### API Base URL All Rules Service endpoints are served at: ``` https://rules.app.gomboc.ai ``` *** ### Concepts In the Gomboc Portal, a **Policy Set** is shown under **Policy Management → Policy Sets**. Internally — and through the API — each policy set is a **Channel**: a named, saved search over the policy library that determines which rules are applied to your workspaces. A channel has the following fields: | Field | Type | Description | | ------------- | ----------------- | --------------------------------------------------------- | | `name` | string | Unique identifier (also used as the human-readable label) | | `query` | string (optional) | ORL search query that selects rules | | `filters` | array of strings | Additional filter expressions | | `annotations` | object (optional) | Arbitrary key/value metadata tags | *** ### Exporting Policy Sets (Backup) Use `GET /api/v1/channels/search` to retrieve all policy sets defined in your account. The endpoint supports pagination — iterate over pages until you have collected every record. #### Shell export script ```bash #!/usr/bin/env bash # export-policy-sets.sh — exports all policy sets to policy-sets-.json set -euo pipefail BASE_URL="https://rules.app.gomboc.ai" PER_PAGE=1 USE_DATE=1 usage() { cat <&2 usage >&2 exit 1 ;; esac done if [ "$USE_DATE" -eq 1 ]; then OUTPUT="policy-sets-$(date +%Y-%m-%d).json" else OUTPUT="policy-sets.json" fi if [ -z "${GOMBOC_TOKEN:-}" ]; then echo "Error: GOMBOC_TOKEN is not set" >&2 exit 1 fi decode_jwt_payload() { local token="$1" local payload padded rem payload=$(printf '%s' "$token" | cut -d. -f2) if [ -z "$payload" ]; then return 1 fi padded="$payload" rem=$((${#padded} % 4)) case "$rem" in 2) padded="${padded}==" ;; 3) padded="${padded}=" ;; esac printf '%s' "$padded" | tr '_-' '/+' | base64 -d 2>/dev/null } ACCOUNT_ID=$(decode_jwt_payload "$GOMBOC_TOKEN" | jq -er '.tenantId // .accountId // empty' 2>/dev/null || true) if [ -z "$ACCOUNT_ID" ]; then echo "Error: could not extract accountId from GOMBOC_TOKEN" >&2 exit 1 fi page=1 echo "[]" > "$OUTPUT" while :; do resp=$(curl -sS "${BASE_URL}/api/v1/channels/search?page=${page}&perPage=${PER_PAGE}" \ -H "Authorization: Bearer ${GOMBOC_TOKEN}") if [ "$(jq -r '.status' <<<"$resp")" != "success" ]; then echo "Error: $resp" >&2 exit 1 fi jq -s --arg accountId "$ACCOUNT_ID" \ '.[0] + (.[1].data.channels | map(select(.accountId == $accountId)))' \ "$OUTPUT" <(echo "$resp") > "${OUTPUT}.tmp" mv "${OUTPUT}.tmp" "$OUTPUT" count=$(jq -r '.data.channels | length' <<<"$resp") [ "$count" -lt "$PER_PAGE" ] && break page=$((page + 1)) done echo "Exported $(jq 'length' "$OUTPUT") policy sets for account $ACCOUNT_ID to $OUTPUT" ``` #### Example output (`policy-sets.json`) ```json [ { "id": "a1b2c3d4-...", "accountId": "f0e1d2c3-...", "name": "default", "query": "", "filters": ["provider:aws", "risk:high"], "annotations": { "env": "production" }, "createdAt": "2025-01-10T14:23:00.000Z", "updatedAt": "2025-04-03T09:01:00.000Z" }, { "id": "e5f6a7b8-...", "accountId": "f0e1d2c3-...", "name": "cis-aws-hardening", "query": "classification:cis-aws", "filters": [], "annotations": { "framework": "CIS", "env": "all" }, "createdAt": "2025-02-18T11:00:00.000Z", "updatedAt": "2025-05-01T16:30:00.000Z" } ] ``` *** ### Restoring Policy Sets Use `POST /api/v1/channels/batch/upsert` to restore from a backup file. This endpoint **creates or updates** up to 200 channels in a single request. > **Note:** Only `name`, `query`, `filters`, and `annotations` are writable. The `id`, `accountId`, `createdAt`, and `updatedAt` fields are read-only and are stripped automatically by the script below. #### Shell restore script ```bash #!/usr/bin/env bash # restore-policy-sets.sh — restores policy sets from a backup file set -euo pipefail BASE_URL="https://rules.app.gomboc.ai" INPUT="${1:-policy-sets.json}" payload=$(jq '{channels: [.[] | {name, query, filters, annotations}]}' "$INPUT") curl -sS -X POST "${BASE_URL}/api/v1/channels/batch/upsert" \ -H "Authorization: Bearer ${GOMBOC_TOKEN}" \ -H "Content-Type: application/json" \ -d "$payload" | jq . ``` If the backup file contains more than 200 policy sets, split it into chunks of 200 and call the script once per chunk. *** ### Version Control with Git Combine the export script with a Git repository to maintain a full history of every change to your policy configuration. #### Recommended repository layout ``` policy-config/ ├── policy-sets.json ← exported channels (policy sets) ├── export.sh ← export script ├── restore.sh ← restore script └── .github/ └── workflows/ └── backup.yml ← automated daily backup ``` #### GitHub Actions: automated daily backup ```yaml name: Backup Gomboc Policy Sets on: schedule: - cron: "0 3 * * *" # every day at 03:00 UTC workflow_dispatch: permissions: contents: write jobs: backup: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Install jq run: sudo apt-get update && sudo apt-get install -y jq - name: Export policy sets env: GOMBOC_TOKEN: ${{ secrets.GOMBOC_TOKEN }} run: bash export.sh - name: Commit if changed run: | git config user.name "github-actions[bot]" git config user.email "github-actions[bot]@users.noreply.github.com" git add policy-sets.json if git diff --cached --quiet; then echo "No changes — policy sets are up to date." else git commit -m "chore: update policy sets backup $(date -u +%Y-%m-%d)" git push fi ``` Add `GOMBOC_TOKEN` as a repository secret in your GitHub repository settings. *** ### Restoring to a Different Environment You can use the same backup file to copy policy sets across Gomboc organizations (e.g., from staging to production): ```bash export GOMBOC_TOKEN="" bash restore.sh policy-sets.json ``` *** ### API Quick Reference All endpoints are on `https://rules.app.gomboc.ai`. Authentication: `Authorization: Bearer `. | Operation | Method | Path | Key parameters | | -------------------------- | -------- | ------------------------------- | ----------------------------------------- | | List all policy sets | `GET` | `/api/v1/channels/search` | `page`, `perPage`, `query` | | Get one policy set | `GET` | `/api/v1/channels/get` | `name` (query param) | | Create a policy set | `POST` | `/api/v1/channels/create` | `name`, `query`, `filters`, `annotations` | | Update a policy set | `PUT` | `/api/v1/channels/update` | `name`, `query`, `filters`, `annotations` | | Batch create | `POST` | `/api/v1/channels/batch/create` | array of channels, `onConflict` | | Batch upsert (restore) | `POST` | `/api/v1/channels/batch/upsert` | array of channels | | Delete a policy set | `DELETE` | `/api/v1/channels/delete` | `name` (query param) | | List rules in a policy set | `GET` | `/api/v1/channels/rules` | `name`, `page`, `perPage` | For the full OpenAPI specification, see the Rule Service API reference. *** ### FAQ **Will restoring a policy set overwrite the existing one?** Yes. `batch/upsert` updates existing channels matched by `name` and creates any that do not exist yet. To add new channels without touching existing ones, use `batch/create` with `"onConflict": "skip"` instead. **Do I need to back up the rules themselves?** Built-in Gomboc rules are managed by Gomboc and do not need to be backed up. If you have published custom ORL rules, those can be exported separately using the `/api/v1/rules/search` endpoint — see the Rule Service API documentation. **What happens to workspaces if I delete and re-create a policy set?** Workspace assignments are stored separately. Deleting and re-creating a policy set with the same `name` may require you to re-assign it to workspaces in the Portal. Use `batch/upsert` (update-in-place) to avoid this. # Exception Handling Gomboc helps teams remediate security and compliance issues directly in code. In some cases, however, applying a code fix is not the right action. For example, a finding may already be mitigated by another control, may not apply to a specific environment, or may require a temporary business exception. Use **Exceptions** to exclude specific Gomboc rules from enforcement in selected Policy Sets, while keeping a clear record of why the exception exists. ### When to Use an Exception Create an exception when a finding is valid but should not be remediated by Gomboc right now. Common examples include: * The risk is already mitigated by another approved control, such as a WAF, network policy, compensating control, or platform guardrail. * The finding is relevant, but the team has accepted the risk for a documented business reason. * The rule does not apply to the architecture or environment covered by the selected Policy Set. * The responsible team is handling the issue through another approved workflow. * The finding is creating noise that prevents teams from focusing on actionable fixes. Do not use exceptions as a shortcut to hide issues that still need remediation. If the underlying code should be fixed, use Gomboc’s remediation workflow instead. ### What an Exception Does An exception excludes one or more **rules** from one or more **Policy Sets**. When a future scan runs, Gomboc resolves the workspace’s Policy Sets, then filters out the rules covered by the exception. Findings and fixes from those excluded rules are not shown in the scan results for the affected Policy Sets. Exceptions are rule-based. This means an exception may suppress all findings from that rule within the selected Policy Set, not only the specific finding or line of code you were viewing when you created it. ### Before You Create an Exception Before creating an exception, review: 1. **The rule**: confirm which Gomboc rule is generating the finding. 2. **The affected Policy Set**: confirm where the exception should apply. 3. **The business reason**: document why remediation is not required or not appropriate. 4. **The impact**: understand that future findings from the same rule may be hidden for the selected Policy Set. 5. **Ownership**: make sure the exception aligns with your organization’s security and compliance process. ### Create an Exception from a Finding 1. Open the relevant finding or remediation report. 2. Expand the section that shows the applied rules. 3. Click **Create Exception** for the rule you want to exclude. 4. Select the Policy Set where the exception should apply. 5. Add a clear reason explaining why the exception is being created. 6. Submit the exception. Use a specific reason that will still make sense during a later audit or review. For example: > This service is protected by an approved external WAF rule. The platform security team has accepted this compensating control for the production workspace. Avoid vague reasons such as: > Not needed.
### Create an Exception from the Exceptions Page If your account has access to the Exceptions page, you can also create exceptions directly from there. 1. Open **Exceptions** from the main navigation. 2. Click **Create an exception**. 3. Enter one or more rule IDs. 4. Select one or more Policy Sets. 5. Add a reason. 6. Submit the exception. The Exceptions page also shows active exceptions, including the requester, creation date, affected rules, affected Policy Sets, and reason.
### Revoke an Exception Revoke an exception when it is no longer needed. 1. Open the **Exceptions** page. 2. Find the relevant exception. 3. Click the delete or trash icon. 4. Confirm the deletion. After the exception is removed, future scans will apply the rule again wherever it is included by the workspace’s Policy Sets. ### Best Practices * Keep exceptions narrow. Apply them only to the Policy Sets where they are needed. * Write audit-friendly reasons that explain the compensating control, risk decision, or business context. * Review exceptions regularly so temporary decisions do not become permanent blind spots. * Prefer remediation when the code can be safely fixed. * Be careful when selecting broad Policy Sets, because the exception may suppress future findings from the same rule across that Policy Set. * Coordinate with Security or Compliance before creating exceptions for high-risk or compliance-mapped policies. ### Example A finding recommends enforcing SSL connections for a database instance. Your team confirms that this environment is protected by another approved control and that changing the IaC right now would break a legacy integration. In this case, you can create an exception for the specific Gomboc rule in the relevant Policy Set and include a reason such as: > Legacy integration requires the current setting until Q3 migration is complete. Risk is tracked in the security exception register and mitigated by network-level access controls. Future scans using that Policy Set will skip findings from the excepted rule until the exception is removed. ### Important Note Exceptions reduce noise, but they also reduce visibility. Use them deliberately, document the reason clearly, and remove them when the exception no longer applies. # Remediation Process Remediation in the context of Gomboc involves identifying security issues within your infrastructure as code (IaC) configurations and applying the necessary changes to resolve these issues. This process ensures that your codebase remains compliant with security policies and reduces potential risks. ## Steps in the Remediation Process ### Identification of Issues * Gomboc scans your code repositories to discover security issues. These issues can include misconfigurations, vulnerabilities, and non-compliance with established security policies. * The scanning process involves analyzing the IaC code to detect any deviations from the security standards set by your organization. ### Generating Remediation Recommendations * Once issues are identified, Gomboc generates recommendations for remediation. These recommendations are based on best practices and predefined security policies. * The recommendations may include specific code changes or configuration adjustments to address the identified issues. ### Applying Remediation * Remediations can be applied automatically or manually, depending on your organization's preferences. * Automatic remediation involves Gomboc making the necessary changes directly in the codebase, while manual remediation allows developers to review and apply changes through pull requests. * For manual remediation, Gomboc helps create and manage pull requests, detailing the recommended changes and ensuring they are applied correctly. # Drift Reconciliation ### What is drift? In Infrastructure as Code (IaC) and cloud operations, **drift** is when the *actual* state of your environment diverges from the *expected* state defined by your intended configuration. Whether that configuration lives in code, policy, or an approved baseline. Drift usually happens when changes occur outside the normal change-management path. Over time, drift increases the risk of surprises, inconsistent environments, failed deployments, and security or compliance gaps because what’s running no longer matches what teams think is running. ### What Gomboc Drift Reconciliation does Gomboc can reconcile drift when it’s notified and provided access to a Terraform plan file. Gomboc will show the exact code changes needed to make your Terraform configuration match what is deployed. This helps you: * Keep your code in sync with manual changes * Preserve “break-glass” updates made during incident response so they don’t get overwritten later * Clearly demonstrate what needs to change back if the drift is unwanted (revert-to-code) *** ### HCP Terraform integration HCP Terraform (Terraform Cloud) can run health assessments on a workspace to determine whether drift exists. When drift is detected, a webhook notification is sent to Gomboc. Gomboc then uses the plan output to determine the exact updates needed in your IaC and provides the deterministic fix to reconcile the drift. ### Integration setup *** #### Step 1: Create an HCP Terraform team token In [HCP Terraform](https://app.terraform.io/app/YOUR_ORG/settings/authentication-tokens), go to Organization Settings → Authentication Tokens and create a Team Token. * Save the token value somewhere secure—you won’t be able to view it again.
*** #### Step 2: Create the integration in the Gomboc portal In the [Gomboc Portal](https://auth.app.gomboc.ai/oauth/account/login), navigate to: Settings → Integrations → Drift Create a new drift integration and paste the HCP Terraform Team Token from Step 1.
*** #### Step 3: Copy the Webhook URL and HMAC token from Gomboc After creating the integration, Gomboc will provide: * A Webhook URL * An HMAC token (shared secret used to sign webhook requests) You’ll paste both into HCP Terraform in the next steps.
*** #### Step 4: Enable health assessments on the HCP Terraform workspace In HCP Terraform, open the target workspace and navigate to: Workspace Settings → Health → Enable Health Assessments → Save This is required for drift detection and drift notifications.
*** #### Step 5: Create the HCP Terraform notification (webhook) In the target workspace, navigate to: Workspace Settings → Notifications → Create a Notification Configure: * Destination: Generic webhook * Webhook URL: paste the Gomboc Webhook URL * Token (optional): paste the Gomboc HMAC token (HCP Terraform uses this token to sign webhook payloads). Under Workspace Events, choose Only certain events, then select: * ✅ Drift detected Under Run Events, select No events (unless you also want run lifecycle notifications). Click Create a notification.
*** ### Reconciliation steps *** #### **Step 1: Find the drift event in the Gomboc Portal** In Gomboc: * Go to **Drift** page * Open the workspace associated with the drift
* Select the most recent drift run from the workspace details page run history
*** #### **Step 2: Review the proposed reconciliation changes** * Click on the drift run and Gomboc will show the exact IaC edits needed to make your Terraform configuration match what’s deployed
*** #### **Step 3: Generate a PR with “Deliver fixes”** * Click **Deliver fixes** to create a side PR containing the reconciliation changes
*** #### **Step 4: Verify drift is resolved** Run Start health assessment again in HCP Terraform and confirm the workspace returns to a healthy/no-drift state # Scan Results Gomboc's Scan Results feature offers robust repository scanning capabilities, providing detailed insights into the security status and compliance of your code repositories. ## Overview The Scan Results page displays the outcomes of your recent scans, giving you visibility into the security posture of your code repositories. You can monitor scan requests, view the status of your repositories, and track the progress of remediation efforts. ### Recent Scan Requests You can view the latest scan requests made at the organizational, project, and repository levels. This feature helps you keep track of ongoing and completed scans, ensuring you are aware of all recent activities and their outcomes. ### Visibility into Projects Gomboc provides detailed access to repositories and branches linked to specific projects. This ensures that all relevant codebases are included in your scans, giving you a comprehensive view of the security status of your projects. ### Remediation Progress Track the progress of remediation efforts for any detected security issues. This feature helps you understand which issues have been resolved and which ones still require attention, providing a clear picture of your remediation status. ### Repository Status Stay updated on the compliance of your repositories with Gomboc's detailed repository status feature. This section categorizes repositories based on their compliance with security policies, helping you quickly identify and prioritize areas that need attention. #### Repository Compliance Status
StatusDescription
Merge RequiredA Pull Request is ready to be merged, indicating that the necessary changes have been reviewed and are ready for integration.
IncompliantViolations were found in the last scan, highlighting areas that need immediate attention to ensure compliance with security policies.
CompliantFully compliant branches with no unresolved violations, confirming that these parts of your repository meet all security standards.
# Troubleshooting Solutions to common issues ### Portal Dashboard Displaying Error on Initial Load On your first login to Gomboc, you may encounter an issue where the dashboard content is blocked, as seen below.
To ensure that Gomboc works properly, you must either enable third-party cookies or allow just the third-party cookies for Gomboc. To determine your current settings for Google Chrome go to in your browser. You can use the link directly or navigate through Settings -> Privacy and Security -> Third Party Cookies.
If “Block Third Party Cookies” is selected, then you will need to either select "Block third-party cookies in Incognito mode", "Allow third-party cookies", or allow third party cookies for the Gomboc site specifically.
To enable cookies just for the Gomboc site, select the eye icon and select the switch to temporarily enable third-party cookies. This will only last for your current browsing session.
Once third-party cookies are allowed, then the Gomboc dashboard loads properly.
> **Still stuck?**\ > If you’ve enabled third-party cookies and are still experiencing issues, please contact us at . We're happy to help! # Data Architecture & Flows This document provides an overview of data movement and storage within the Gomboc system. As Gomboc is a SaaS offering, it is even more important for our customers to understand how their information is handled. ## Overview The following series of diagrams provides a high-level overview of the various components of the Gomboc system and how data moves across it. The primary function Gomboc provides is to analyze your infrastructure source code and provide recommendations to enforce security best practices in that code through diffs and change requests. As such, Gomboc must integrate with your source code management (SCM) system. Each SCM integration operates slightly differently. For instance, the GitHub integration uses a GitHub Application with minimally required access scope, while the GitLab, BitBucket, and Azure DevOps integrations use similarly scoped access tokens to use the respective service APIs. A few things that Gomboc explicitly does not do: * Store copies of customer source code * Use customer source code to train any shared machine learning models * Send data to external generative AI systems to create code recommendations ### High-Level System Architecture The Gomboc application is a software as a service (SaaS) offering hosted in the cloud. System services component are currently spread between AWS us-east-1 and GCP us-east4 regions.
The environment is deployed on a private subnet and all traffic to and from the Gomboc API is encrypted in transit. All data stored in the Gomboc DB (which includes a relational database and a key-value database) is encrypted at rest using AES-256 encryption. Note: A transition from AWS to Google Cloud is scheduled to occur during Q4 2024, which will improve some of the elements of security posture in the cloud. This includes: * All data will be fully encrypted in motion and at rest, including intra-service communication * Encryption keys will be rotated every 90 days ### Source Code Management (SCM) Integration In #2 in the high-level architecture diagram above, Gomboc executes the following data flow to deliver remediations on customer code: 1. On initial configuration of the SCM integration with Gomboc, a customer provides a personal access token and follows the instructions provided by Gomboc [here](https://docs.gomboc.ai/integrations/source-code-management-scm) to complete the integration. 2. After access to the SCM is confirmed, Gomboc pulls a list of repositories accessible with the access token. The user selects which repositories should be linked to Gomboc for scanning. No actions are ever taken on repos that have not been explicitly linked, even if they are within the scope of the access token provided. 3. The next step is for Gomboc to analyze the one or more of the linked code repositories. A user can run an individual repository scan or a bulk scan of multiple repositories. ### Remediation Service Picking up after the SCM Integration and linking of code repositories is complete, the Remediation Service performs an analysis of source code to recommend contextual fixes to the user. 1. Gomboc pulls the source code code for the repository, transmitting it from the customer SCM to temporary storage on a node in our cloud service infrastructure. 2. The source code is analyzed to find recognized IaC types, currently Terraform and Cloudformation. Then, the system proceeds to analyze the infrastructure code. The results of this analysis are either: 1. A set of findings about the code, which include information about the policy statement applied, cloud resource type, cloud resource name, finding type (e.g., remediable), a diff of the changes proposed by Gomboc, and reference to any code change request, if applicable. 2. Both (a) and a code change request created in the customer SCM system. 3. Once the remediation scan performed by Gomboc is complete, any temporary artifacts from the analysis are deleted. If there are any errors executing analysis as part of the Remediation Service, any system logs include references that let us come back to the customer to determine how we can reproduce the error, but we do not log any source code as it is processed. ### Gomboc Dashboard Users may navigate and access results from Gomboc source code analysis using the web UI client (#3 above). The information available in this UI includes remediation observations, performance data tracking the time from issue detection through to resolution, scan activity, and compliance adherence. ### Build System Integration In the case of build system integrations such as in #1 in the architecture diagram above, Gomboc provides a build script which uses a container that holds a command line client application which communicates with the Gomboc APIs. Based on configuration of the pipeline, the build can trigger code analysis by Gomboc on code change request creation. The workflow is as follows: 1. A user with a git client creates a code change request (i.e., a pull request) 2. The code change causes the CI build pipeline to execute, trigging the Gomboc client to execute a static analysis scan. 3. The static analysis scan performed uses the Gomboc client, which triggers a request for the Gomboc remediation service to pull the code under review for analysis and returns any findings. Steps 1 and 2 above from the Remediation Service description are executed. Results of this scan show in the Gomboc UI audit trail as well. 4. If there are findings detected, then merging the changes can be blocked. A new code change request is created and linked to the current changes under review. 5. The user can address the fixes by approving the new change request, after which the original change request can be merged. 6. Based upon user configuration of the pipeline, it can either block the pipeline from completing or simply issue a warning to the user. ## Identity and Access Management As a Gomboc administrator you have the option to let Gomboc manage your digital identities or you can supply your own identity provider (IdP) for single sign-on (SSO) authentication. See [Authentication - Pwdless & SSO](/configuration/authentication-pwdless-and-sso) for more details. We recommend using SAML SSO authentication as user access can be centrally managed and revoked in the case of employee turnover or other security events. ### Authentication and Authorization To access SCM integrations, Gomboc does store the configuration for the integration, including the access token. However, this information can not be revealed by a user once it is entered, so harvesting the token is not possible after entry. It is a best practice that this token should be rotated on a regular basis and updated in the SCM configuration in Gomboc. As for authentication to Gomboc, a user can authenticate with the authentication methods previously mentioned (magic link or SAML SSO) or a user can generate a personal access token to access the API at [api.app.gomboc.ai](http://api.app.gomboc.ai), accessing the public API as noted in #4 above. See [API](/api) for more information. # Glossary ## **A** **Audit** Capabilities allow security and engineering teams to identify non-compliance with security policies in infrastructure as code, including identification by external tools. ## B **Branches (re:Repositories)** Versions of the repository that diverge from the main codebase to work on specific features or fixes. ## C **CI/CD** Continuous integration (CI), continuous delivery (CD), and continuous deployment (CD) together comprise a Software Development Lifecycle (SDLC) model, guiding developers to automate the development and delivery of small, frequent changes. This ensures all team members have access to the latest codebase and can ensure the compatibility of committed code during development. #### CSPM Cloud Security Posture Management (CSPM) is a set of security tools and practices designed to monitor and manage cloud infrastructure security. CSPM solutions continuously assess and visualize an organization’s cloud security posture, identifying and mitigating risks through automated detection and remediation of misconfigurations and vulnerabilities **Code Sources (Provider)** Platforms or services where code is hosted and managed, such as GitHub or GitLab. **Code Repositories** Storage locations within these sources where codebases are kept, categorized as first-party (owned by the organization) or third-party (including open-source software). **Cloud Accounts** Accounts that provide access to cloud services and resources, such as AWS, Azure, or Google Cloud. **Compliance and Best Practice Frameworks** Industry standards and guidelines for security and best practices, such as AWS Well-Architected and SOC2. ## F **Findings (re: Assessment)** Results from scans that highlight areas of non-compliance or security vulnerabilities. **First-party** Repositories owned and maintained by the organization. ## M **Modules (Terraform)** Reusable groups of resources defined by Terraform configurations, which can be used to manage complex infrastructure. ## O **Operations** Implements controls to warn and block product deployments if certain business rules are met. This includes integration into Infrastructure as Code (IaC) platforms to enforce policy within planning and deployment workflows. ## P **Paths (re:Repositories)** Paths refer to the directory structure within a branch where specific code files are located. #### Policy Statements Rules and requirements set by security teams that define acceptable configurations and practices for infrastructure as code. ## ## R #### Remediations Actions generated to address and fix the findings from scans. **Resources (Terraform)** Individual components of infrastructure managed by Terraform, such as AWS S3 buckets or EC2 instances. ## S **Scans (re: Assessment)** Processes that analyze codebases to identify compliance with policy statements and detect security issues. **Scenarios (Terraform or other IaC)** Representations of cohesive units of work within IaC, which include specific configurations and setups to achieve a particular objective. ## T **Third-party** External repositories, including open-source software (OSS). # Support ## Getting Help We're here to assist you! If you encounter any issues, have questions, or want to provide feedback, please use one of the channels below. #### Direct Support For specific problems, private inquiries, or urgent issues, the best way to reach us is by email. * **Email**: #### Community Feedback & Discussions For general questions, feature requests, bug reports, or to engage with the Gomboc team and community, please join our GitHub Discussions. * **GitHub**: [Gomboc-AI Feedback & Discussions](https://github.com/Gomboc-AI/gomboc-ai-feedback) #### **Gomboc Platform (Pro)** Book a fully interactive demo with our team, or even better - get free access to the platform to experience it for yourself! (no commitment, simple 2-step onboarding) * **Meeting**: [Book a demo](https://meetings.hubspot.com/gomboc-demo/one?uuid=02ec3652-7555-49d9-ab35-b01b2dc09cdb&__hstc=239846108.d9abb7a6c8409d9962c467d347a3b69a.1747674668709.1771607018868.1771619176053.93&__hssc=239846108.3.1771619176053&__hsfp=36b799a02b3d61e1a71fb88f8f5d5cb5) We look forward to hearing from you! # Changelog Keep track of new releases and improvements ### Hosted MCP Server, Audit Findings, and Portal Improvements July 20, 2026 `New` A packed couple of weeks across the platform — a new hosted MCP server, end-to-end Audit Findings, and a set of scanning reliability improvements. **Hosted Gomboc MCP Server.** Gomboc now offers a hosted MCP (Model Context Protocol) server, live at `mcp.app.gomboc.ai`. Any MCP-compatible client — such as Claude Code, Cursor, Gemini CLI, or OpenAI Codex — can connect directly to Gomboc without running a local server or managing containers. Authentication uses your existing Gomboc access token, which is passed through securely to the Gomboc Rules Service. The initial release exposes rule search, letting agents query the Gomboc rule library on demand, and establishes the hosted foundation for a growing set of tools. To see how this fits alongside our local skills, see [Agent Skills](https://docs.gomboc.ai/orl/agent-skills). **Audit Findings, end-to-end.** Violations that ORL detects but does not (or cannot) auto-remediate are now surfaced with full context instead of being left out. A new `orl audit` command scans a workspace for rule violations in a non-destructive, dry-run mode and outputs results in a standard linter format (`file:line:column - message`). It never modifies your files and returns a non-zero exit code when violations are found, so it drops cleanly into a [CI pipeline](https://docs.gomboc.ai/integrations/continuous-integration-ci-build-systems) as a gate. In the Portal, the [Scan Results](https://docs.gomboc.ai/scan-results) screen now displays these audit findings alongside remediated ones — each with a severity level, the rule's violation message, precise line-and-column coordinates, and a read-only view of the original source context — giving developers and security engineers a clear way to inspect and triage outstanding issues. **Scanning reliability and consistency.** We shipped a set of improvements to make scans more dependable and results consistent everywhere: * Accurate scan status: scans that fail after retries now correctly report as failed instead of getting stuck showing "In Progress." * No more silent empty scans: a rules-service timeout no longer lets a scan quietly complete with zero rules applied. * Consistent reports across surfaces: ORL reports are now parsed and stored the same way regardless of origin, so results look identical whether a scan comes from the [IDE](https://docs.gomboc.ai/integrations/vscode-plugin), the [GitHub Action](https://docs.gomboc.ai/integrations/continuous-integration-ci-build-systems/github-actions), or [Agent Skills](https://docs.gomboc.ai/orl/agent-skills). * Faster handling of large YAML files during scanning. * [Community Skills](https://docs.gomboc.ai/orl/agent-skills/gomboc-community-skills) (Claude plugin) now write run activity logs to your Gomboc run history. *** ### Agent Skills and Portal: Closed-Loop Reporting July 8, 2026 `Improvement` Gomboc agent skills — running inside Claude Code, Gemini CLI, OpenAI Codex, or Cursor — now report their results directly back to the Gomboc Portal. When an agent completes a remediation run, the Portal run history captures the full ORL report, the duration, and a direct link to the fix PR opened by the agent. This closes the loop between local IDE work and the centralised visibility that security and platform teams need. Alongside this, the plugin installer now includes an OS-aware setup skill that verifies and installs all required dependencies automatically on first run, across macOS, Debian/Ubuntu, Red Hat/Fedora, and Windows (WSL). Getting a coding agent connected to Gomboc no longer requires manual dependency troubleshooting. See the [Agent Skills documentation](https://docs.gomboc.ai/orl/agent-skills) and the [Gomboc Enterprise Skills](https://docs.gomboc.ai/orl/agent-skills/gomboc-enterprise-skills) guide for setup instructions. *** ### New ORL Rules: Python, Django, TypeScript, and Node.js June 30, 2026 `New` Gomboc has expanded its ORL rule library to cover OWASP Top 10 use cases for **Python and Django** and for **TypeScript with Node.js, Express, and NestJS**. These rulesets extend Gomboc's automated remediation capabilities beyond infrastructure-as-code into application code, enabling teams to detect and fix common web application security issues using the same ORL engine already scanning their IaC. This is part of Gomboc's ongoing expansion of coverage across languages and frameworks. For an overview of what ORL can scan and remediate today, see the [Gomboc Playbook](https://docs.gomboc.ai/gomboc-playbook). *** ### Workspace-level Exception Management June 29, 2026 `New` It is now possible to suppress specific findings at the **workspace level**, rather than applying exceptions account-wide. When a finding is not applicable to a particular workspace — for example, a rule that does not fit a specific environment's configuration — teams can now mark it as an exception scoped only to that workspace, leaving other workspaces unaffected. This gives platform and security teams more granular control over what gets reported and acted on in each environment. Exceptions can be managed directly from the workspace view in the Portal. See the [Workspaces documentation](https://docs.gomboc.ai/workspaces) for details. *** ### Community Skills: Full Parity Across All Coding Agents June 16, 2026 `Improvement` The [Gomboc Community Skills](https://docs.gomboc.ai/orl/agent-skills/gomboc-community-skills) plugin now fully supports **Cursor**, **OpenAI Codex**, **Gemini CLI**, and **Claude Code** — all four major coding agent platforms — with verified installation paths and consistent command behaviour across each. Previously, some platforms had gaps or untested configurations; all are now at parity and covered in the documentation. At the same time, the agentic remediation loop has been extended end-to-end: a coding agent can now run a full `diagnose → fix → push PR → publish rule → repeat` cycle autonomously on a codebase, stopping for user input only at key decision points. This is the same loop described in the [Policy Enforcement Loop](https://docs.gomboc.ai/orl/agent-skills/gomboc-enterprise-skills/policy-enforcement-loop) documentation and is available to both Community and Enterprise skill users. *** ### Portal: Selective Fix Delivery by Rule or by Finding June 16, 2026 `New` When reviewing scan results in the Portal, users can now choose **exactly which fixes to apply** before a pull request is generated — either by selecting individual rules or individual findings within a rule. Previously, applying a scan result meant applying all available fixes at once. The new selection model gives developers and security reviewers full control over what goes into each fix PR, making it easier to stage remediation incrementally or to exclude fixes that require additional review. This feature is available directly in the scan results view for all workspace runs. ### GitHub Actions: ORL Runner with Inline PR Comments June 11, 2026 `New` We shipped a new self-contained GitHub Action — `on-pull-request-runner` — that runs ORL directly inside your GitHub runner without requiring repository registration or any manual linking in the Gomboc Portal. The only setup needed is a `GOMBOC_ACCESS_TOKEN` stored as a GitHub Actions secret. The action supports two modes: **audit** (posts inline review comments on every changed line with a finding, plus a PR summary comment) and **remediate** (opens a stacked pull request with the applied fixes targeting your feature branch). You can set `fail-on-findings: true` to block the pipeline when issues are detected, making it straightforward to enforce security policy as a required CI gate. The action works across all 38+ languages supported by ORL, covering IaC, application code, and configuration formats. Setup and YAML examples for both modes are in the [GitHub Actions documentation](https://docs.gomboc.ai/integrations/continuous-integration-ci-build-systems/github-actions). *** ### Agentic CSPM Triage: From Wiz Alert to Code Fix and PR June 9, 2026 `New` The Gomboc CSPM Triage Loop connects live cloud security alerts from Wiz directly to the infrastructure code that caused them, and automates the full remediation cycle in a single skill invocation. A developer passes a Wiz alert ID or permalink to the `/cspm-triage` command in their coding agent (Claude Code, Gemini CLI, Codex, or Cursor) — the skill fetches the alert, matches it to the affected IaC code, builds or reuses an ORL rule, applies the fix, opens a GitHub pull request, and posts a timestamped resolution note back to the Wiz observation so security teams have full traceability. The loop uses a 4-tier fallback model so it degrades gracefully: if local IaC code isn't available yet, it completes the classification and triage brief and lets you resume later when the source path is provided. Code match confidence is scored (HIGH / MEDIUM / LOW) before any rule is built or released, preventing rules from being created for alerts that don't trace to the provided code. Triage findings — including observation metadata, rule details, Git attribution, and PR link — are persisted as structured JSON artifacts in `.gomboc/triage/` and committed on the fix branch. See the full [CSPM Triage Loop documentation](https://docs.gomboc.ai/orl/agent-skills/gomboc-enterprise-skills/cspm-triage-loop) and watch the [walkthrough video](https://www.youtube.com/watch?v=Dm_WxA_LsyQ). The Wiz integration setup is documented at [docs.gomboc.ai/integrations/cloud-security-posture-management-cspm/wiz](https://docs.gomboc.ai/integrations/cloud-security-posture-management-cspm/wiz). *** ### Gomboc Enterprise Skills: All Major Coding Agents Supported June 5, 2026 `New` Gomboc now ships official agent skill packages for [Agent Skills](https://docs.gomboc.ai/orl/agent-skills): [Claude](https://docs.gomboc.ai/orl/agent-skills/gomboc-enterprise-skills/claude-enterprise), [Gemini](https://docs.gomboc.ai/orl/agent-skills/gomboc-enterprise-skills/gemini-enterprise), [Codex](https://docs.gomboc.ai/orl/agent-skills/gomboc-enterprise-skills/codex-enterprise), and [Cursor](https://docs.gomboc.ai/orl/agent-skills/gomboc-enterprise-skills/cursor-enterprise) - giving engineers a unified way to run ORL-powered security and compliance workflows directly inside their coding environment. Each package delivers the full Gomboc enterprise skills suite: * `/fix` (analyze → build → apply a deterministic fix in-context) * `/new-policy` (create a classification from a policy document or standard) * `/new-rule` (full production-quality rule creation pipeline) * `/enforce-policy` (diagnose an entire codebase, cover gaps, apply fixes, and verify) * ...and more! > Enterprise customers receive the plugin as a zip package shared via Google Drive during onboarding. Community users can install the open-source plugin directly from [GitHub](https://github.com/Gomboc-AI/gomboc-community-skills). For an overview of all available skills and the full [Policy Enforcement Loop](https://docs.gomboc.ai/orl/agent-skills/gomboc-enterprise-skills/policy-enforcement-loop), see [Agent Skills](https://docs.gomboc.ai/orl/agent-skills). *** ### Expanded Compliance Coverage: OWASP, ASVS 5.0, Kubernetes, and PCI DSS June 2, 2026 `New` We significantly expanded ORL's compliance rule coverage across four areas this quarter. We released a new ruleset targeting the **Kubernetes OWASP Top 10**, covering misconfiguration patterns in Kubernetes workloads and manifests — extending deterministic remediation beyond cloud IaC into Kubernetes security. We also shipped the full set of **OWASP Application Security Verification Standard (ASVS) 5.0 classifications**, mapped chapter by chapter, section by section, requirement by requirement, so rules and fixes can now map to the latest application security standard. Earlier in the quarter we released **OWASP Top 10** rules for Java and Spring Boot applications, and completed the full **PCI DSS → Gomboc Policy mapping** so teams with PCI compliance requirements can enforce and auto-fix relevant controls. All of these additions are available in the Policy Library and can be enabled in your Policy Sets. To get started, go to Policy Management → Policy Sets in the [Gomboc Portal](https://docs.gomboc.ai/policy-management/policy-sets) and enable the frameworks relevant to your environment. *** ### Policy Sets Backup and Version Control via API May 26, 2026 `New` You can now manage Policy Sets programmatically through the Gomboc Rules Service API, enabling GitOps workflows, automated daily backups, and environment promotion (e.g., copy a policy configuration from staging to production). The API supports export, batch upsert/restore, and per-policy-set CRUD operations — all authenticated via a personal access token from the Portal. This is useful for disaster recovery, audit trails (tracking every change to your policy configuration in Git history), and teams that prefer to store their compliance posture as code. A GitHub Actions workflow for automated daily backups ships ready to use in the documentation. Full guide and scripts at [Policy Sets: Backup and Version Control via API](https://docs.gomboc.ai/policy-management/policy-sets/policy-sets-backup-and-version-control-via-api). *** ### Agentic Rule Generation: End-to-End Pipeline May 19, 2026 `New` Platform engineers can now go from a policy document, CSPM finding, or compliance framework directly to a deployed ORL rule — end-to-end, without writing rule syntax by hand. The agentic rule generation pipeline analyzes policy intent, builds test cases, authors a deterministic ORL rule, validates it against the test suite, enriches metadata (classifications, risk scores, framework mappings), and publishes it to the Gomboc Rules Service — with human review steps built in at every stage. In this release cycle, we completed the full user story for generating ORL rules from Terraform IaC policy documentation, added **Terraform and CloudFormation variable support** in rule generation (so parameterized infrastructure is handled correctly), and converted all **890 HashiCorp Sentinel public policies** into ORL classifications and rules. A new `/convert-sentinel` skill is also available in the [Community Skills](https://docs.gomboc.ai/orl/agent-skills/gomboc-community-skills) plugin, letting any team port existing HCL Sentinel policies directly to ORL. To start generating and enforcing your own rules, see the [ORL Quickstart](https://docs.gomboc.ai/orl/quickstart) and the [Policy Enforcement Loop](https://docs.gomboc.ai/orl/agent-skills/gomboc-enterprise-skills/policy-enforcement-loop). > **Note on HCP Terraform Run Tasks:** As part of this release cycle, the [HCP Terraform Run Task integration](https://docs.gomboc.ai/integrations/cloud-orchestration/hcp-terraform) was migrated from legacy configuration options to native ORL-based policy evaluation, giving it the same deterministic enforcement and fix delivery capabilities as all other Gomboc scan surfaces. *** ### Portal and IDE: Data Library, Open in IDE, Workspace Archival, and More April 29, 2026 `Improvement` We shipped a series of usability improvements across the Portal and IDE extension, released through April: * **Data Library**: A new searchable page in the Portal for browsing rules, channels, and classifications in your account — making it easier to understand what's enforced and why. * **Open in IDE**: Jump from a scan report finding directly to the relevant file in your preferred editor, without leaving the Portal. * **Policy Library search**: A search box in the Policy Library lets you quickly find specific policies by name or keyword. * **Policy rule view**: Each policy now has a dedicated Rule view showing exactly what ORL is checking at the code level. * **Run History filters**: Improved filter UX on the Run History page so you can narrow results by workspace, status, and time range. * **Dashboard CSV export**: Exports now include start and end date columns. * **Configurable remediation timeout**: The IDE plugin now exposes a configurable timeout for fix execution, so long-running remediations don't silently fail. * **Workspace archival**: [Workspaces](https://docs.gomboc.ai/workspaces) that no longer exist in the source code repository are automatically archived, keeping your workspace list accurate without manual cleanup. For an overview of the daily workflows these improvements support, see the [Gomboc Playbook](https://docs.gomboc.ai/gomboc-playbook). *** ### Multi-language Support: ORL and IDE Go Beyond IaC April 10, 2026 `New` Gomboc now scans and fixes code beyond Terraform and CloudFormation. The IDE plugin, ORL engine, and scan workflows all gained multi-language awareness: ORL can recursively discover file types across a repository tree, detect the language for each target, and apply the right ruleset automatically. This release adds support for **Java, TypeScript/JavaScript, Python, Go, Bicep, and Kubernetes YAML** alongside all previously supported IaC formats — laying the foundation for applying deterministic ORL fixes to your full application stack, not just infrastructure. In the VSCode extension, the scan surface now covers any supported code file you open — not just `.tf` files — and Terragrunt is recognized in IDE diagnostics. Under the hood, language detection and report generation were centralized into a shared SDK so results are consistent across the IDE, the Portal, and CI scan workflows. See the [ORL documentation](https://docs.gomboc.ai/orl) for the full list of supported languages, and [Workspaces](https://docs.gomboc.ai/workspaces) for how scans map to your repository structure. *** ### Exception Handling for Policy Sets March 27, 2026 `New` Gomboc now supports Exception Handling in the Portal, giving teams a governed way to exclude specific rules from enforcement within selected Policy Sets when remediation is not the right action. Exceptions help reduce noise while preserving audit context: users can create an exception for one or more rule IDs, attach it to one or more Policy Sets, and provide a clear reason for why the rule should be bypassed. This is useful when a finding is already mitigated by another approved control, does not apply in a specific environment, or needs to be handled through a separate business process. Exceptions can be created from scan results or managed from the Exceptions page. See the [Exception Handling documentation](https://docs.gomboc.ai/policy-management/exception-handling) for setup guidance and best practices. *** ### ORL Custom Rules (turn guardrails into fixes) March 17, 2026 `New` Our custom rules let teams convert existing guardrails into actionable fixes, not just pass/fail checks. You can codify organization-specific policies (including conversions from existing policy investments) into deterministic remediation rules and apply them to the environments that matter, enabling “blocking mode” style enforcement in real pipelines. You can now **create your own deterministic remediation rules** using our **ORL engine,** so your existing internal guardrails (tagging standards, IAM patterns, encryption requirements, etc.) become **repeatable checks + auto-fixes**. Start with the [**Custom Rules Quickstart** guide here](/orl/quickstart). *** ### “Beyond IaC” demo/use cases March 9, 2026 `New` Gomboc now delivers **end-to-end, deterministic remediation across codebases -** not just IaC. The shift is powered by our **ORL-based engine**, which turns remediation intent into precise, repeatable diffs across many file types and languages, so teams can trust and operationalize fixes (reviewable, consistent, and scalable). To see this in action outside Terraform, start with this demo case: [Demo case Java with dolphinscheduler log4shell](/getting-started-ce/gomboc-demo-cases/demo-case-java-with-dolphinscheduler-log4shell) - it walks through scanning a real Java project (Apache DolphinScheduler), flagging a Log4j risk, then using the IDE Reviewer to **preview the diff**, apply the deterministic dependency change (replacing `slf4j-log4j12` with `slf4j-reload4j`), and **verify via re-scan** that the issue is resolved. *** ### Drift Reconciliation February 28, 2026 `New` We shipped drift reconciliation to keep cloud reality aligned with IaC. Gomboc maps IaC resources to live cloud resources, detects drift, and generates the exact deterministic code changes needed to reconcile differences, helping you preserve “break-glass” incident changes and avoid surprises over time. **Get started here:** [Drift Reconciliation (setup + steps).](/drift-reconciliation) *** ### ORL (Open Remediation Language) February 17, 2026 `New` We released ORL (Open Remediation Language) for our enterprise customers and the Gomboc Community Edition. **ORL is our new execution engine** that powers how Gomboc evaluates policies, detects issues, and generates deterministic fixes directly in your code. Instead of alerts or suggestions, ORL generates repeatable, policy-aligned code changes that engineers can safely apply, and it also lays the foundation for Custom Rules so teams can enforce, and deterministically fix, their own organization-specific controls the same way. If you want the full mental model (what ORL is, why it exists, how it maps Policies → Policy Sets → Rules → Findings/Fixes, and the core concepts like determinism + syntax trees + separation of concerns), read the [ORL overview here](/orl). *** ### New Reports and Analytics Page February 10, 2026 `New` **ROI metrics framed as Focus → Progress → Outcomes** The new Reports feature enables customers to easily track their fix burn-down, prioritize results, and report success to management. We added new reporting and analytics centered on the three stakeholder questions: **Where should we focus?** **Are we making progress?** **What did we achieve?** Reports highlight prioritized work, show burndown and trends over time, and summarize measurable impact (like fixes delivered and time saved) to make ROI clear and easy to communicate. Learn from our [case study](https://www.gomboc.ai/case-study/upwork-eliminates-iac-security-debt-with-gomboc) how you can save hours to you team. *** ### IDE Fix Reviewer (webview, diff preview, bulk apply patterns): January 22, 2026 `New` We introduced the Gomboc IDE Fix Reviewer (webview) to bring fixes directly into the developer workflow. It provides an in-IDE review surface with diff previews before changes are applied, plus bulk actions that let you multi-select findings and apply the same fix pattern across multiple files and occurrences—turning remediation into a fast, reviewable flow. **External findings ingest (e.g., Checkov) + verification** The Fix Reviewer can ingest external findings (for example, from Checkov) and map them into Gomboc’s deterministic remediation logic. After applying fixes, verification helps confirm the issue is actually resolved, identify false positives from third-party tools, and ensure the change matches the intended policies and rules. **To try it right now**, follow the [**VSCode Plugin setup**](/integrations/vscode-plugin) (install extension, add your personal token, enable scan-on-save), then run **`“Gomboc: Scan current file or scenario”`** and open **`“Gomboc: Reviewer (webview)”`** from the Command Palette. *** ### **Workspaces Tags** January 10, 2026 `New` We added workspace tagging to strengthen deterministic fix delivery and make remediation operational at scale. Workspace tags help you segment and route work simpler by letting teams group and filter workspaces by dimensions like team, application, environment, business unit, or compliance tier. This improves ownership and reporting! so leaders can quickly answer “what’s running where, who owns it, and what’s the remediation status?” across large numbers of repos and environments. *** ### **Policy Sets Per Environment Or Workspace** January 6, 2026 `New` You can create and apply **Policy Sets** for each environment (e.g., dev, staging, prod) and attach them to specific **workspaces**, so the right guardrails, and the right fixes, apply automatically wherever the code lives. Teams typically start with the **Gomboc default policy set** as a baseline, then tighten standards for production and create targeted sets for high-risk repos or critical services. Because policy is the control plane, fix configuration stays simple and consistent: results and fix reports roll up **by policy**, with **severity and risk-based prioritization**, and you can also align policies to known frameworks (e.g., CIS/NIST) and deliver **custom fixes** only to the environments that matter. *** ### **New Policy Management + Smart Prioritization** December 23, 2025 `New` We are shifting remediation from “a list of findings” to “fixes aligned with intent.” Teams can define what guardrails matter (by category, framework, internal standards, or tool-mapped policies), and Gomboc consistently generates deterministic fixes that match those guardrails. The outcome is higher trust and adoption: engineers see fixes that reflect agreed-upon standards, and security teams get predictable enforcement without repeated manual interpretation. **Smart prioritization** Smart prioritization ranks fixes by severity, risk, and impact so teams tackle what matters first (especially production blockers). The outcome is faster risk reduction, fewer stalled backlogs, and clearer progress over time. *** ### **Gomboc Portal Redesign** December 21, 2025 `New` We shipped a complete Portal overhaul with a refreshed UX/UI and significantly faster navigation and page load performance. The new experience is designed around real remediation workflows, making it easier to move from “what did we find?” to “what do we fix next?” without jumping between disconnected views. Book a fully interactive demo with our team: [Book a demo](https://meetings.hubspot.com/gomboc-demo/one?uuid=02ec3652-7555-49d9-ab35-b01b2dc09cdb&__hstc=239846108.d9abb7a6c8409d9962c467d347a3b69a.1747674668709.1771607018868.1771619176053.93&__hssc=239846108.3.1771619176053&__hsfp=36b799a02b3d61e1a71fb88f8f5d5cb5). *** ### **Workspaces** November 13, 2025 `New` A Workspace is the single unit of IaC: **IaC tool + repository + branch + path**. It mirrors how code is deployed and reviewed and becomes the **control plane** for scans, and fixes. **Why this change** We’re deprecating the **Projects** and **Repositories** views and consolidating them into **Workspaces** to provide: * One coherent view instead of bouncing between pages. * No manual linking of repos/paths. * Clear ownership and reporting per deployable unit. **How it works** * **Auto-discovery:** New repos under your connected SCM scope are discovered and turned into Workspaces; PRs auto-map to their ancestor Workspace. * **Indexer:** An hourly job indexes new repos, new workspaces, and new subgroups and performs an IaC presence check. * **Scans:** Run on demand from the Portal, or automatically on PR open/update. * **Scope:** Workspace creation is limited to default/protected branches for stability. * **Manual setup:** You can Add Workspace manually and edit names if needed. {% hint style="danger" %} Note: The Projects and Repositories views will no longer be available starting November 28, 2025. {% endhint %} *** ### **Fixes for CIS Benchmarks** October 17, 2025 `New` Today we release over 100 new fixes that relate to CIS Benchmarks. This marks a significant advancement supporting multiple cloud providers (AWS, Azure, and Google) across an array of services from data storage, databases, compute, Kubernetes, and general cloud configuration. The following CIS benchmarks were addressed: * AWS * Amazon Web Services Foundations Benchmark v5.0 * AWS Database Service Benchmark v1.0 * AWS End User Compute Services Benchmark - v1.1 * AWS Storage Services Benchmark v1.0 * AWS Compute Services Benchmark v1.1 * AWS Elastic Kubernetes Service Benchmark v1.7 * Azure * Microsoft Azure Foundations Benchmark v4.0 * Microsoft Azure Kubernetes Service Benchmark v1.7 * Microsoft Azure Compute Services Benchmark v2.0 * Microsoft Azure Database Services Benchmark v1.0 * Microsoft Azure Storage Services Benchmark v1.0 * Google Cloud * Google Cloud Platform Foundations Benchmark * Google Kubernetes Engine (GKE) Benchmark * Google Kubernetes Engine (GKE) Autopilot Benchmark * Google Workspace Foundations Benchmark **Why this change** We've been working on scaling our fix generation capabilities and this is a step toward making it possible to gain assurance that your cloud configuration adopts CIS best practices. **How it works** * **Enable policy recommendations**: applying the new rules simply involves turning on the corresponding benchmark in the "Security Policy" view. *** ### **HashiCorp Terraform Run Task Integration** August 6, 2025 `New` We’ve added a new integration with HashiCorp Terraform, a leading IaC platform used to provision and manage any of your cloud environments. With this update, Gomboc can automatically check and fix issues in your infrastructure code before deployment, helping prevent security risks, downtime, and unnecessary costs by delivering ready-to-merge pull requests. Authentication is secured via HMAC, and enforcement can be set to advisory or mandatory. Detailed pass/fail callbacks include severity‑ranked outcomes, resource addresses, and remediation guidance, helping teams focus on the highest‑impact fixes first. Engineers benefit from native workflow integration with no CLI changes or extra tools, plus RFC‑style documentation for knowledge sharing and easy troubleshooting. Setup takes minutes via Settings > Integrations > HashiCorp in the Gomboc Portal. See our [user documentation](https://docs.gomboc.ai/integrations/cloud-orchestration/hcp-terraform) for complete instructions. *** *** ### **Create Custom Rules** June 30, 2025 `New` We’ve introduced the ability to create custom security policies, giving teams control over how Gomboc enforces best practices in their environment. Whether it’s tagging standards, KMS key access, or IAM permissions, users can now define and scope their own policy rules, customized down to the cloud resource and attribute level. * Build from scratch or start with existing rules using our new policy builder interface. * Apply rules globally or scope them to specific projects, repositories, or folders. * Customize policy logic using exact values, value patterns (e.g., starts with), or organizational tags. * Automatically generate rule descriptions and link policies to your security frameworks (e.g., CIS, NIST). *** ### **Gomboc Community Edition** June 24, 2025 `New` We’ve launched **Gomboc Community Edition -** a free, quick-start version of Gomboc deterministic AI platform automating IaC remediation, designed to let developers explore our core functionality. Community Edition delivers: * Merge-ready PRs for Terraform misconfigurations. * Instant onboarding via GitHub. * Real-world policies covering security and compliance best practices for AWS, Azure and Google Cloud. * Deterministic AI that delivers verifiable fixes you can trust. Unlike static scanners or recommendation tools, Gomboc Community Edition actually fixes the problem. This release reflects our commitment to supporting Platform and DevOps teams with tools that work the way they do: fast, reliable, and developer-first.\ Grab it now at and see Gomboc in action. *** ### **Code Validation for Gomboc PRs** May 30, 2025 `Improvement` Gomboc now automatically validates the Terraform code in its generated pull requests for type and configuration accuracy before it ever reaches your repo. What this means: * Every PR from Gomboc now runs `terraform validate` behind the scenes. * This catches syntax and type issues early, before any human review. * We simulate backend and provider authentication to avoid the need for user credentials or setup. * Future phases will include full `terraform plan` validation and state analysis for customers who want deeper trust signals and automation. Time is key, and having to check out a branch, run `init`, and review `plan` output slows developers down. This validation upgrade Gomboc to fully trusted IaC remediation that developers can merge with confidence. *** ### **Gomboc Compliance Companion** April 21, 2025 `New` The Gomboc Compliance Companion is a new feature that helps companies keep their cloud systems secure and compliant automatically, without slowing down developers or rewriting existing code. Automatically scans all your configurations across AWS, Azure, and GCP, and provides: * Instant, auditable security fixes in PRs with one-click approval. * Real-time compliance enforcement in development, CI/CD, and pipelines. * No rewrites required, works with your existing codebase. * $100K+ potential annual savings per workload by eliminating 50+ days of developer toil Compliance Companion shifts teams from periodic audits to automated, continuous compliance, accelerating delivery while reducing risk. *** ### **Automated Onboarding Assessment** April 2, 2025 `Improvement` We’ve streamlined the onboarding experience to make it faster, smarter, and easier to manage. With just a few clicks, Gomboc now automatically discovers your IaC repositories and delivers a comprehensive report with actionable insights in under 5 minutes. What’s better: * Zero manual setup: Automated repo discovery means no team or project gets missed. * Smart impact report: Highlights misconfigurations, team activity, and ROI projections. * Prioritized fixes: Aligned to compliance frameworks like CIS IG1/2/3. * No code stored: All data is processed securely and ephemerally. [Try the improved onboarding flow](https://meetings.hubspot.com/celsinger?uuid=007a6d36-2959-4c04-8ad5-e0c69ef11ce7&__hstc=239846108.d9abb7a6c8409d9962c467d347a3b69a.1747674668709.1752262501325.1752599560527.46&__hssc=239846108.8.1752599560527&__hsfp=1666919083) and see your first value, fast. *** ### **Gomboc Extension for Visual Studio Code** March 13, 2025 `New` We just dropped a VSCode extension that enables developers to get a real-time generated code as they develop cloud infrastructure. The extension applies Gomboc’s deterministic AI to highlight and fix misconfigurations precisely and instantly. Whether you're writing new infra or cleaning up legacy code, it keeps your cloud setup tight, without slowing you down. Install it via the [VSCode Marketplace](https://marketplace.visualstudio.com/items?itemName=GombocAI.gomboc-vscode-extension\&ssr=false#overview), learn about all the features, and start building reliable cloud infrastructure without leaving your editor. *** ### **CSPM Alert to Code Discovery and Fix** March 2, 2025 `New` We’ve closed the loop from cloud alerts to actual code-generated remediations. Gomboc now connects CSPM findings directly to the code that caused them. Here’s what’s new: * When a CSPM alert comes in, Gomboc identifies the code location that caused it and provides a fully described pull request with the fix. * We show full observation detail and lets you dive into context across code resources. * You can now select policy-based remediations, preview the fix, and generate a PR, all in one click. This dramatically reduces investigation time and makes remediating cloud infrastructure feel like a GitHub feature. [Try it from the Observations tab now.](https://meetings.hubspot.com/celsinger?uuid=007a6d36-2959-4c04-8ad5-e0c69ef11ce7&__hstc=239846108.d9abb7a6c8409d9962c467d347a3b69a.1747674668709.1752262501325.1752599560527.46&__hssc=239846108.8.1752599560527&__hsfp=1666919083)