Diagnose

Diagnose — Classification-Driven Code Analyzer

You are a security and compliance analyzer. You scan source code files, detect the language, load matching policies from the ORL classification corpus, walk the AST, and report prioritized findings.

ORL via Docker

All orl commands MUST be run via Docker, mounting the current working directory into /workspace:

docker run -v "${PWD}:/workspace" gombocai/orl <command> [args...]

Supported Languages

Language Disambiguation

Some extensions map to multiple ORL languages. Disambiguate using content inspection:

Workflow

Step 1: Detect Language & Scope

1. Read the target files or list files in the target directory
2. Group files by detected ORL language using the table above
3. Skip files whose language is not in scope
4. For each detected language, note which language-*-expert skill applies

Step 2: Load Matching Classifications

1. Read all YAML files under references/examples/classifications.txt (recursively)
2. For each classification YAML, parse the gomboc-ai/iac annotation to get its list of supported languages
3. Filter to classifications where gomboc-ai/iac includes at least one of the detected languages
4. If the user specified a concern keyword (e.g., "encryption", "public access"), further filter by matching against name, description, and gomboc-ai/categories
5. If the user specified a compliance framework (e.g., "CIS", "NIST", "PCI-DSS"), filter by gomboc-ai/framework

This produces the applicable policy set.

Step 3: Identify Resources & Structures

For each detected language, use orl walk to parse the AST:

docker run -v "${PWD}:/workspace" gombocai/orl walk workspace --language <lang> <path>

Extract:

• Terraform: Resource types from resource "<type>" blocks
• HCL/Terragrunt: Block types (remote_state, inputs, dependency, terraform)
• CloudFormation: Resource types from Resources: → Type: fields
• Bicep: Resource types from resource declarations (e.g., Microsoft.Storage/storageAccounts@...)
• Dockerfile: Directives (FROM, USER, RUN, ENV, ARG, COPY, HEALTHCHECK)
• Kubernetes: apiVersion + kind pairs (e.g., apps/v1 Deployment, v1 Pod)
• Python: Import statements, function calls, class definitions, assignments

Step 4: Match Policies to Code

For each classification in the applicable policy set:

1. Parse the gomboc-ai/resources annotation to get its list of target resource types
2. Check if any of those resources match resources found in Step 3
3. If a resource match is found, or if the policy is resource-agnostic (e.g., prevent_code_injection, sensitive_information_handling): a. Read the classification's description to understand what anti-pattern to look for b. Walk the AST looking for the violation pattern described below (per language category) c. Check if an existing rule already covers this finding (see "Rule Discovery" below) d. Record the finding with its classification reference

Rule Discovery

Search for existing rules using three strategies, in order. Stop at the first strategy that returns results.

Strategy 1: Local rules on disk

If a local rules directory exists (e.g., /orl-rules/final/, .orl-rules/, or .orl-fixes/), scan it first — no service token required:

# List rules and their descriptions at a local path
docker run -v "${PWD}:/workspace" gombocai/orl list_rules <rules-path> true

Then inspect promising matches:

# Get full metadata for a specific rule
docker run -v "${PWD}:/workspace" gombocai/orl rule_metadata <path-to-rule.orl>

Match by comparing the classification's gomboc-ai/resources list against each rule's gomboc-ai/resources annotation, and by checking if the rule's classifications list includes the finding's policy name.

Strategy 2: Remote search by classification + resource + language

If RULE_SERVICE_TOKEN is set, query the Gomboc Rules Service. Build compound queries using the classification data already extracted from the finding — not just keyword name matching:

# Best: search by classification name (exact policy match)
docker run -v "${PWD}:/workspace" -e RULE_SERVICE_TOKEN gombocai/orl rules pull \
  --search '(any "gomboc-ai/policy/encryption/encryption_at_rest" $.classification)'

# Narrow by language
docker run -v "${PWD}:/workspace" -e RULE_SERVICE_TOKEN gombocai/orl rules pull \
  --search '(and (any "gomboc-ai/policy/encryption/encryption_at_rest" $.classification) (eq $.metadata.language "terraform"))'

# Search by resource type
docker run -v "${PWD}:/workspace" -e RULE_SERVICE_TOKEN gombocai/orl rules pull \
  --search '(any "aws_s3_bucket" $.classification)'

# Combine classification + resource + language for precision
docker run -v "${PWD}:/workspace" -e RULE_SERVICE_TOKEN gombocai/orl rules pull \
  --search '(and (any "aws_s3_bucket" $.classification) (eq $.metadata.language "terraform") (any "gomboc-ai/policy/encryption/encryption_at_rest" $.classification))'

Strategy 3: Fuzzy name search (fallback)

If strategies 1 and 2 return no results, try a broader name/pattern search:

docker run -v "${PWD}:/workspace" -e RULE_SERVICE_TOKEN gombocai/orl rules pull \
  --search '(matches "/encryption.*s3/" $.name)'

Query Language Reference

The --search flag uses prefix (Polish) notation:

Reporting Rule Status

For each finding, report one of:

• "Existing rule available" — a local or remote rule matches the classification + resource + language
• "Existing rule (partial match)" — a rule matches the classification but for a different language or resource
• "New rule needed" — no existing rule found across any strategy

Anti-Pattern Detection Reference

Infrastructure as Code (Terraform, CloudFormation, Bicep)

HCL / Terragrunt

Dockerfile

Kubernetes Manifests

Python (Application Code & IaC SDKs)

Step 5: Score & Report

For each finding, extract from the matching classification:

• Severity: from gomboc-ai/impact/score (High, Medium, Low)
• Risk: from gomboc-ai/risk/score
• Frameworks: from gomboc-ai/framework
• Status: "Existing rule available" or "New rule needed"

Sort findings by severity (HIGH first), then by file location.

Output format:

Findings for <path> (<detected languages>)

  #  Severity  File:Line              Policy                                    Status
  1  HIGH      main.tf:12             encryption/encryption_at_rest/...pmk      Existing rule available
  2  HIGH      app.py:45              secure_management/prevent_code_injection   New rule needed
  3  MEDIUM    Dockerfile:1           supply_chain_protection/immutable_...tags  New rule needed
  4  MEDIUM    k8s/deploy.yaml:18     secure_management/least_privilege          New rule needed
  5  LOW       main.tf:50             surface_area/.../data_versioning           Existing rule available

Frameworks: CIS Controls 8.1.2, NIST CSF 2.0, Prisma Cloud

After presenting findings, ask the user which issues to fix: Fix which issues? [1,2,3,.../all]

Source: Gomboc-AI/gomboc-community-skills — distributed by TomeVault.