Feature Request: Domain-Specific Language (DSL) for Security Rule Editing

[ZhiXiao-Lin]

Summary

Proposal to add a human-readable Domain-Specific Language (DSL) that enables business personnel and security analysts to author, edit, and version security rules across all three analysis layers (L1/L2/L3) without requiring Python code changes or deep understanding of the internal rule schema.

---

Motivation

Current State

Currently, L1 rules are defined as YAML attack patterns via CS_ATTACK_PATTERNS_PATH, and L2/L3 rules are effectively hardcoded into the SemanticAnalyzer and AgentAnalyzer components. Tunability is limited to environment variables (CS_*).

This creates several problems:

Persona	Pain Point
Security Analyst	Must understand YAML schema + CS internals to add new L1 patterns
Business Analyst	No tooling to propose L2/L3 rule changes — requires dev ticket
Compliance Officer	Cannot audit or version-control rule logic directly
Dev Team	Every rule change = code PR, even for trivial pattern updates

Why a DSL?

A DSL would:

• Decouple rule authorship from code — analysts write rules, not Python
• Enforce constraints per layer — L1 DSL expresses simple patterns; L2 DSL expresses semantic constraints; L3 DSL expresses review policies
• Enable validation & simulation — dry-run rules before deployment, with clear error messages
• Support versioning & review — rules are plain text, naturally git-versionable and PR-reviewable

---

Proposed Design

Layer-Specific DSL Sublanguages

rules/
├── l1/
│   ├── patterns.csl      # ClawSentry L1 Rule Language
│   └── *.csl
├── l2/
│   ├── constraints.csl  # L2 semantic constraints
│   └── *.csl
└── l3/
    ├── policies.csl     # L3 review policies
    └── *.csl

L1 DSL Example (rule-based patterns)

pattern "sql_injection_001" {
  type:    regex
  severity: high
  match:   r"(?i)(union\s+select|insert\s+into|drop\s+table)"
  action:  deny
  tags:    [owasp, injection, sql]
}

pattern "prompt_injection_generic" {
  type:    heuristic
  severity: medium
  match:   heuristic {
    keyword_ratio:  > 0.4   // suspicious keyword density
    length:         > 2000  // unusually long input
    url_count:      > 3     // potential link injection
  }
  action:  flag
  tags:    [prompt-injection]
}

L2 DSL Example (LLM semantic constraints)

constraint "no_financial_advice" {
  description: "Responses must not provide specific investment recommendations"
  deny_if:     {
    intent:  ["investment_recommendation", "stock_ticker_advice"]
    scope:   "personal_finance"
  }
  severity: critical
  tags:    [compliance, financial]
}

constraint "PII_minimization" {
  description: "Generated output must not contain raw PII fields"
  deny_if:     {
    entity_type: ["credit_card", "ssn", "bank_account"]
    raw_format:  true
  }
  severity: high
  tags:    [privacy, PII]
}

L3 DSL Example (human review policies)

policy "executive_decision_review" {
  description: "Flag actions with high business impact for human review"
  trigger: {
    action_category: ["funds_transfer", "contract_creation", "data_deletion"]
    business_impact: high
    confidence:      < 0.85
  }
  review_tier:  mandatory
  sla_minutes:  30
  notify:      ["security-team@company.com", "compliance@company.com"]
}

policy "anomaly_escalation" {
  description: "Escalate to L3 if L2 confidence drops below threshold"
  trigger: {
    l2_confidence: < 0.6
    risk_score:    > 75
  }
  review_tier: conditional
  sla_minutes: 120
}

---

Implementation Considerations

1. Parser/Compiler: Leverage an existing DSL toolkit (e.g., tree-sitter, Lark, or a custom PEG parser) to parse .csl files into intermediate representations understood by each layer's analyzer.

2. Validation & Dry-Run: The DSL runtime should support:

   • Syntax validation on save (IDE integration friendly)
   • Rule simulation against a test corpus
   • Conflict detection (overlapping patterns)

3. Hot Reload: Follow the existing pattern established by CS_ATTACK_PATTERNS_PATH — watch files and recompile rules on change.

4. Backwards Compatibility: YAML-based patterns via CS_ATTACK_PATTERNS_PATH should remain functional; a migration tool could convert existing YAML to the new DSL.

5. Multi-tenancy: The DSL should support per-tenant rule namespaces (for MSSP use cases).

---

Alternatives Considered

Approach	Why Not
JSON Schema for rules	Still too technical for non-developers
Natural language rules parsed by LLM	Non-deterministic, hard to validate, security risk
GUI rule builder	Limits expressiveness, hard to version-control

---

Success Metrics

• Business analyst can add a new L1 pattern without developer assistance
• L2 constraint changes are deployable via a rules PR (no code change)
• Rule authors receive immediate syntax feedback in a supported IDE extension
• Existing YAML-based patterns can be auto-migrated to the DSL

---

Open Questions

1. Should the DSL be interpreted (parsed at runtime) or compiled to bytecode at deploy time?
2. Should rule evaluation order be explicit (priority field) or inferred?
3. What is the migration strategy for existing YAML patterns?

---

Requested by: A3S-Lab / AI45Lab community