Self-Evolving IaC Rules — Cymind + PeriDex Learning Loop

Every cloud misconfiguration your platform detects in production automatically becomes a cyscan rule that catches the same issue in code review. This is the closed-loop learning system that makes your security posture improve over time.

How It Works

Detection Sources                    PeriDex Generator              Output
+------------------+                +-------------------+          +------------------+
| CVE Feeds        |----+           |                   |          |                  |
| (NVD/OSV/GHSA)   |    |           | Claude LLM +      |          | cyscan YAML      |
+------------------+    |           | IaC-specific       |  validate | rules in         |
                        +---------->| prompts +          |--------->| rules/auto/      |
+------------------+    |           | cloud resource     |          |                  |
| CSPM Scan        |----+           | context            |          | GitHub PR        |
| (Prowler)        |    |           |                   |          | (auto-publish    |
+------------------+    |           +-------------------+          |  if conf >= 0.9) |
                        |                                          +------------------+
+------------------+    |                                                 |
| K8s Scan         |----+                                                 v
| (cyscan k8s)     |    |                                          Homebrew update
+------------------+    |                                          (all users get
                        |                                           the new rule)
+------------------+    |
| User Feedback    |----+
| (thumbs up/down) |
+------------------+

The Pipeline

Step 1: Detection

When a misconfiguration is found (by CSPM, K8s scan, or manual review), a CymindEvent is created with event_type = "misconfiguration".

Step 2: Rule Generation

PeriDex's generate_iac_rule() uses Claude with:

• IaC-specific prompts tailored to Terraform, CloudFormation, ARM, GCP DM, Kubernetes, Docker
• Cloud resource context -- 50+ AWS/Azure/GCP resource types with their security-relevant fields
• Few-shot examples -- 4 high-quality IaC rule examples for pattern guidance

Step 3: Validation

Generated rules are tested against a corpus:

• Precision >= 0.8 (avoid noisy rules)
• Recall >= 0.5 (catch actual issues)
• Confidence score = F1 metric

Step 4: Publishing

Rules with confidence >= 0.9 are auto-published as GitHub PRs to the cyscan repo. Lower-confidence rules queue for human review.

Step 5: Feedback Loop

Users rate rules as useful or not useful:

• Positive feedback: confidence += 0.05
• Negative feedback: confidence -= 0.15
• Rules below 0.3 confidence are auto-rejected

Automated Schedule

Task	Schedule	What it does
ingest_cve_feed	Every 6 hours	Fetch NVD + OSV + GHSA, generate rules for new CVEs
periodic_rule_generation	Every 12 hours	Find HIGH/CRITICAL findings without rules, generate up to 50
learn_from_cymind_events	Daily 4:00 AM	Scan 24h of misconfig events, generate IaC rules for uncovered patterns
learn_from_feedback	Daily 5:00 AM	Process user feedback, adjust confidence, auto-reject low-quality rules
auto_publish_validated_rules	Daily 3:30 AM	Publish rules with confidence >= 0.9 as GitHub PRs

Consciousness Level Controls

The consciousness level controls how autonomous the rule pipeline is:

Level	Rule generation	Publishing
0-1	Rules generated but require manual approval	Manual merge
2	Rules queued for review	Manual merge
3	Auto-publish below severity threshold	Auto-merge for low/medium
4	Full autonomous generation + publish	Auto-merge all

Why This Is a Moat

1. Shift-left from production -- every real-world misconfig becomes a code review check
2. Cross-tenant intelligence -- anonymized patterns from all tenants improve the shared rule set
3. Zero-day coverage -- CVE feeds ingested every 6 hours, rules generated within hours of publication
4. Self-improving -- feedback loop continuously tunes precision and recall