Adversarial Code Analyzer

Multi-Agent Adversarial Analysis System inspired by ZeroLeaks architecture.

v2.88 Key Changes (MODEL-AGNOSTIC)

• Model-agnostic: Uses model configured in ~/.claude/settings.json or CLI/env vars
• No flags required: Works with the configured default model
• Flexible: Works with GLM-5, Claude, Minimax, or any configured model
• Settings-driven: Model selection via ANTHROPIC_DEFAULT_*_MODEL env vars

Applies security scanner patterns to code analysis: specialized agents work together systematically to find vulnerabilities, weaknesses, and quality issues.

Architecture

Based on ZeroLeaks multi-agent system adapted for code analysis:

             ORCHESTRATOR (Engine)
                    |
    +---------------+---------------+
    |               |               |
STRATEGIST      ATTACKER        EVALUATOR
    |               |               |
    +-------+-------+-------+-------+
                    |
                MUTATOR

Agent Roles

Agent Teams Integration (v2.88)

Optimal Scenario: Integrated (Agent Teams + Custom Subagents)

Adversarial analysis uses Agent Teams coordination with specialized ralph-* agents for multi-vector attack simulation.

Why Scenario C for Adversarial

• Multi-agent coordination essential (Strategist, Attacker, Evaluator, Mutator)
• Quality gates validate vulnerability findings
• Specialized roles map to ralph-* agents
• Coordinated attack strategy via shared task list

Subagent Roles

Parallel Attack Analysis

When Agent Teams is active:

1. Team Lead orchestrates multi-vector attack analysis
2. ralph-reviewer identifies security weaknesses in parallel
3. ralph-researcher maps codebase attack surface
4. ralph-coder generates proof-of-concept tests

Agent Teams Workflow

• Uses TeamCreate for coordinated attack analysis
• Task coordination tracks vulnerability findings
• TeammateIdle triggers cross-validation of discoveries

Aristotle Integration (v3.0)

Before adversarial analysis begins, apply Aristotle Phase 1 (Assumption Autopsy):

• What security assumptions are we inheriting from the framework?
• Are we testing the right attack surface, or the obvious one?
• What would an attacker assume about our defenses?

The Irreducible Truths (Phase 2) become the invariants that adversarial testing validates.

Usage

bash
1/adversarial src/auth/
2/adversarial --target security src/api/
3/adversarial --depth 5 --branches 4 src/

Analysis Phases

Follows ZeroLeaks phased methodology:

1. RECONNAISSANCE   -> Understand codebase structure, dependencies
2. PROFILING        -> Build defense profile (patterns, safeguards)
3. SOFT_PROBE       -> Gentle analysis attempts
4. ESCALATION       -> Increase analysis intensity
5. EXPLOITATION     -> Active vulnerability search
6. PERSISTENCE      -> Verify findings persist across scenarios

Analysis Categories

Configuration

yaml
1adversarial_config:
2  max_turns: 25           # Maximum analysis iterations
3  max_tree_depth: 5       # How deep to explore each vector
4  branching_factor: 4     # Parallel exploration paths
5  pruning_threshold: 0.3  # Score below which to abandon path
6
7  enable_crescendo: true  # Multi-turn escalation
8  enable_many_shot: true  # Pattern-based detection
9  enable_best_of_n: true  # Generate variations
10  best_of_n_count: 5      # Variations per test

Strategies

1. Behavioral Reconnaissance (Priority: 100)

yaml
1id: recon_behavioral
2applicable_when:
3  turn_range: [1, 3]
4  leak_status: ["none"]
5attack_sequence:
6  - category: direct
7    weight: 0.4
8    techniques: ["structure_probe", "dependency_scan"]
9  - category: technical
10    weight: 0.3
11    techniques: ["config_analysis", "boundary_test"]

2. Credential/Secret Scanning (Priority: 95)

yaml
1id: credential_hunt
2applicable_when:
3  defense_level: ["none", "weak"]
4attack_sequence:
5  - category: direct
6    weight: 0.5
7    techniques: ["secret_scan", "env_probe"]
8  - category: encoding
9    weight: 0.3
10    techniques: ["base64_secrets", "obfuscated_creds"]

3. Trust Boundary Analysis (Priority: 90)

yaml
1id: trust_boundary
2applicable_when:
3  defense_level: ["weak", "moderate"]
4attack_sequence:
5  - category: crescendo
6    weight: 0.4
7    techniques: ["privilege_escalation", "trust_chain"]
8  - category: persona
9    weight: 0.3
10    techniques: ["identity_bypass", "role_confusion"]

4. Input Validation Bypass (Priority: 85)

yaml
1id: input_bypass
2applicable_when:
3  defense_level: ["moderate", "strong"]
4  failed_categories: ["direct"]
5attack_sequence:
6  - category: encoding
7    weight: 0.4
8    techniques: ["unicode_bypass", "encoding_chain"]
9  - category: technical
10    weight: 0.3
11    techniques: ["format_injection", "boundary_overflow"]

5. Advanced Composite (Priority: 80)

yaml
1id: advanced_composite
2applicable_when:
3  defense_level: ["strong", "hardened"]
4  failed_categories: ["direct", "encoding", "persona"]
5attack_sequence:
6  - category: cot_hijack
7    weight: 0.25
8    techniques: ["logic_flow_manipulation"]
9  - category: crescendo
10    weight: 0.25
11    techniques: ["multi_step_chain"]
12  - category: reasoning_exploit
13    weight: 0.25
14    techniques: ["algorithm_weakness"]

Defense Profile Output

typescript
1interface DefenseProfile {
2  level: "none" | "weak" | "moderate" | "strong" | "hardened";
3  confidence: number;
4  observedBehaviors: string[];
5  guardrails: {
6    type: string;
7    strength: number;
8    bypassed: boolean;
9    bypassMethod?: string;
10  }[];
11  weaknesses: {
12    category: AttackCategory;
13    description: string;
14    exploitability: number;
15  }[];
16  safePatterns: string[];
17  responsePatterns: {
18    pattern: string;
19    frequency: number;
20    defenseIndicator: boolean;
21  }[];
22}

Finding Classification

Severity Levels

Finding Output

typescript
1interface Finding {
2  id: string;
3  turn: number;
4  timestamp: number;
5  extractedContent: string;
6  contentType: "vulnerability" | "weakness" | "smell" | "risk" | "unknown";
7  technique: string;
8  category: AttackCategory;
9  confidence: "high" | "medium" | "low";
10  evidence: string;
11  severity: "critical" | "high" | "medium" | "low";
12  verified: boolean;
13  recommendation: string;
14}

Integration with Ralph Loop

yaml
1# Adversarial analysis as part of validation
2Step 7: VALIDATE
3  └── 7a. QUALITY-AUDITOR    (standard)
4  └── 7b. GATES              (standard)
5  └── 7c. ADVERSARIAL-CODE   (this skill)  <- Invoke for complexity >= 7
6  └── 7d. ADVERSARIAL-PLAN   (standard)

Invocation

IMPORTANT: Use available security agents instead of non-existent adversarial-code-analyzer.

yaml
1Task:
2  subagent_type: "security-auditor"
3  model: "opus"
4  prompt: |
5    TARGET_PATH: src/auth/
6    ANALYSIS_TYPE: security
7    CONFIG:
8      max_turns: 25
9      enable_crescendo: true
10      enable_best_of_n: true
11
12    Perform comprehensive security audit on the target codebase.

Alternative for Cross-Validation:

yaml
1# Use codex-cli for second opinion
2/codex-cli analyze security --target src/auth/
3
4# Or use gemini-cli for alternative analysis
5/gemini-cli search security vulnerabilities in src/auth/

Output Format

json
1{
2  "scan_result": {
3    "overall_vulnerability": "medium",
4    "overall_score": 65,
5    "leak_status": "fragment",
6    "findings": [...],
7    "defense_profile": {...},
8    "recommendations": [...],
9    "summary": "Analysis identified 3 potential vulnerabilities..."
10  },
11  "analysis_tree": {
12    "nodes_explored": 47,
13    "max_depth_reached": 4,
14    "successful_paths": 3
15  },
16  "strategies_used": [
17    "recon_behavioral",
18    "credential_hunt",
19    "trust_boundary"
20  ]
21}

CLI Commands

IMPORTANT: Use available skills and tools for adversarial analysis:

bash
1# Use security-auditor agent (available)
2Task subagent_type=security-auditor model=opus "Perform comprehensive security audit of src/auth/"
3
4# Use codex-cli for cross-validation (available)
5/codex-cli analyze security --target src/auth/
6
7# Use gemini-cli for alternative analysis (available)
8/gemini-cli search "security vulnerabilities SQL injection XSS" --count 10
9
10# Manual grep-based security scanning
11grep -r "eval\|exec\|system\|innerHTML" src/
12grep -r "SELECT.*WHERE.*\+" src/  # SQL injection patterns
13grep -r "md5\|sha1" src/           # Weak hashing

Best Practices

1. Start with Reconnaissance: Always profile before attacking
2. Adapt to Defenses: Each response teaches about the codebase
3. Layer Techniques: Combine multiple vectors for hardened code
4. Verify Findings: Always validate discoveries before reporting
5. Document Patterns: Track successful techniques for future use

Attribution

Strategy patterns adapted from ZeroLeaks AI security scanner architecture (FSL-1.1-Apache-2.0).

Action Reporting (v2.93.0)

Esta skill genera reportes automáticos completos para trazabilidad:

Reporte Automático

Cuando esta skill completa, se genera automáticamente:

1. En la conversación de Claude: Resultados visibles
2. En el repositorio: docs/actions/adversarial/{timestamp}.md
3. Metadatos JSON: .claude/metadata/actions/adversarial/{timestamp}.json

Contenido del Reporte

Cada reporte incluye:

• ✅ Summary: Descripción de la tarea ejecutada
• ✅ Execution Details: Duración, iteraciones, archivos modificados
• ✅ Results: Errores encontrados, recomendaciones
• ✅ Next Steps: Próximas acciones sugeridas

Ver Reportes Anteriores

bash
1# Listar todos los reportes de esta skill
2ls -lt docs/actions/adversarial/
3
4# Ver el reporte más reciente
5cat $(ls -t docs/actions/adversarial/*.md | head -1)
6
7# Buscar reportes fallidos
8grep -l "Status: FAILED" docs/actions/adversarial/*.md

Generación Manual (Opcional)

bash
1source .claude/lib/action-report-lib.sh
2start_action_report "adversarial" "Task description"
3# ... ejecución ...
4complete_action_report "success" "Summary" "Recommendations"

Referencias del Sistema

• Action Reports System - Documentación completa
• action-report-lib.sh - Librería helper
• action-report-generator.sh - Generador