Antifragile architecture
Rule evolution, feedback loops, and how the system gets stronger over time.
Antifragile Malware Detection Architecture
Overview
This document describes a self-improving security system that:
- Learns from AI detections to evolve static analyzers
- Remediates malware by generating sanitized packages
- Tests safely in hardened sandboxes before deployment
The system becomes stronger with every attack it encounters.
Component 1: Static Analyzer Evolution Engine
Concept
When the LLM detects malware that static analysis missed, the system:
- Analyzes WHY static analysis failed
- Determines if static detection IS POSSIBLE
- Generates new detection rules/patterns
- Tests the new rules against the sample
- Integrates validated rules into static analyzers
Architecture
┌─────────────────────────────────────────────────────────────────┐
│ EVOLUTION ENGINE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌───────────────────┐ ┌──────────────┐ │
│ │ LLM Detection │───▶│ Gap Analysis │───▶│ Rule │ │
│ │ Result │ │ - Why missed? │ │ Generation │ │
│ └──────────────┘ │ - Can static catch?│ └──────────────┘ │
│ └───────────────────┘ │ │
│ ▼ │
│ ┌──────────────┐ ┌───────────────────┐ ┌──────────────┐ │
│ │ Integration │◀───│ Validation │◀───│ Generated │ │
│ │ (if passes) │ │ - Test on sample │ │ Rules │ │
│ └──────────────┘ │ - False positive? │ └──────────────┘ │
│ └───────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
Rule Types That Can Be Generated
| Detection Type | Static Feasibility | Generation Method |
|---|---|---|
| Hex-encoded strings | ✅ YES | Regex + decoder |
| Base64 payloads | ✅ YES | Pattern + decode check |
| Obfuscated variable names | ✅ YES | Naming pattern regex |
| Suspicious file paths | ✅ YES | Path pattern matching |
| Network endpoints | ✅ YES | URL/domain extraction |
| Cross-file data flow | ⚠️ PARTIAL | AST-based taint analysis |
| Semantic intent | ❌ NO | Requires LLM |
| Novel attack patterns | ❌ NO | Requires LLM |
Output: Generated Detection Rule
interface GeneratedRule {
id: string; // Unique rule ID
name: string; // Human-readable name
description: string; // What it detects
category: AlertType; // Which plugin category
// Detection patterns
patterns: {
type: 'regex' | 'ast' | 'literal' | 'function';
value: string | RegExp | ASTPattern;
context?: string; // Where to look (file, line, etc.)
}[];
// Validation
testCases: {
code: string;
shouldMatch: boolean;
}[];
// Metadata
generatedFrom: {
packageName: string;
llmAnalysisId: string;
timestamp: Date;
};
confidence: number; // How confident we are in this rule
falsePositiveRisk: 'low' | 'medium' | 'high';
}
Component 2: Malware Remediation Engine
Concept
Generate patches that neutralize malware while preserving legitimate functionality.
Remediation Strategies
| Strategy | Use When | Risk Level |
|---|---|---|
| Surgical Removal | Malware is isolated, clear boundaries | Low |
| Function Stubbing | Malicious function, needed interface | Medium |
| Feature Poison-Pill | Can't safely remove, disable feature | Medium |
| Dependency Replacement | Malicious dep, alternatives exist | Medium |
| Full Quarantine | Package is fundamentally compromised | High |
Remediation Flow
┌────────────────────────────────────────────────────────────────────┐
│ REMEDIATION ENGINE │
├────────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────┐ │
│ │ LLM Analysis │ │
│ │ (malicious) │ │
│ └───────┬───────┘ │
│ ▼ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ SCOPE ASSESSMENT │ │
│ │ - What % of code is malicious? │ │
│ │ - Is malware isolated or distributed? │ │
│ │ - What functionality would be lost? │ │
│ │ - Are there legitimate use cases for affected code? │ │
│ └───────┬───────────────────────────────────────────────┘ │
│ ▼ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ STRATEGY SELECTION │ │
│ │ │ │
│ │ < 5% malicious ──▶ Surgical Removal │ │
│ │ 5-20% malicious ──▶ Function Stubbing │ │
│ │ 20-50% malicious ──▶ Feature Poison-Pill │ │
│ │ > 50% malicious ──▶ Full Quarantine (reject) │ │
│ └───────┬───────────────────────────────────────────────┘ │
│ ▼ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ PATCH GENERATION │ │
│ │ - Generate unified diff │ │
│ │ - Preserve exports/interfaces │ │
│ │ - Add security stubs where needed │ │
│ │ - Document changes │ │
│ └───────┬───────────────────────────────────────────────┘ │
│ ▼ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ VALIDATION (in sandbox) │ │
│ │ - Apply patch │ │
│ │ - Run package tests │ │
│ │ - Verify malware neutralized │ │
│ │ - Check for regressions │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────┘
Patch Output Format
interface RemediationResult {
packageName: string;
version: string;
assessment: {
maliciousCodePercentage: number;
affectedFiles: string[];
affectedFunctions: string[];
functionalityLoss: string[];
remediationFeasibility: 'high' | 'medium' | 'low' | 'impossible';
};
strategy: 'surgical' | 'stub' | 'poison_pill' | 'quarantine';
patches: {
file: string;
diff: string; // Unified diff format
description: string; // What this patch does
}[];
// Stubs for removed functionality
stubs: {
export: string;
replacement: string; // Safe no-op or error-throwing stub
reason: string;
}[];
// Validation results
validation: {
testsRun: number;
testsPassed: number;
malwareNeutralized: boolean;
functionalityPreserved: boolean;
};
confidence: number;
manualReviewRequired: boolean;
}
Component 3: Hardened Sandbox Architecture
Requirements
- Zero escape - Nothing leaves the sandbox
- Zero persistence - Fresh environment every run
- Zero network - No outbound connections (except to test endpoints)
- Resource limited - CPU, memory, time caps
- Monitored - Full audit trail
AWS Lambda Sandbox Design
Lambda is ideal because:
- Ephemeral - Container destroyed after execution
- Isolated - AWS manages hypervisor isolation
- No persistence - /tmp is wiped
- VPC controlled - Can restrict all network
- Time limited - 15 min max execution
- AWS's problem - They handle escape vulnerabilities
┌─────────────────────────────────────────────────────────────────────┐
│ SANDBOX ARCHITECTURE │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ ORCHESTRATOR │ │
│ │ (runs in your VPC) │ │
│ └─────────────────────────┬───────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ SQS QUEUE │ │
│ │ (test job submission) │ │
│ └─────────────────────────┬───────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ ISOLATED AWS ACCOUNT │ │
│ │ (separate from production) │ │
│ │ ┌───────────────────────────────────────────────────────┐ │ │
│ │ │ PRIVATE VPC │ │ │
│ │ │ (no internet gateway) │ │ │
│ │ │ ┌─────────────────────────────────────────────────┐ │ │ │
│ │ │ │ LAMBDA FUNCTION │ │ │ │
│ │ │ │ │ │ │ │
│ │ │ │ ┌──────────────────────────────────────────┐ │ │ │ │
│ │ │ │ │ EXECUTION ENVIRONMENT │ │ │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ │ │ • Sanitized package code │ │ │ │ │
│ │ │ │ │ • Package's own test suite │ │ │ │ │
│ │ │ │ │ • Minimal Node.js runtime │ │ │ │ │
│ │ │ │ │ • seccomp + AppArmor profiles │ │ │ │ │
│ │ │ │ │ • No AWS credentials │ │ │ │ │
│ │ │ │ │ • Read-only filesystem (mostly) │ │ │ │ │
│ │ │ │ │ • 512MB RAM, 5 min timeout │ │ │ │ │
│ │ │ │ └──────────────────────────────────────────┘ │ │ │ │
│ │ │ │ │ │ │ │
│ │ │ │ IAM Role: ZERO permissions │ │ │ │
│ │ │ │ - No S3, DynamoDB, SQS, etc. │ │ │ │
│ │ │ │ - Only CloudWatch Logs (write-only) │ │ │ │
│ │ │ └─────────────────────────────────────────────────┘ │ │ │
│ │ │ │ │ │
│ │ │ Security Groups: DENY ALL │ │ │
│ │ │ - No inbound │ │ │
│ │ │ - No outbound (not even to AWS services) │ │ │
│ │ └────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ Network ACLs: DENY ALL │ │
│ │ VPC Endpoints: NONE (no AWS service access) │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ │
│ Results returned via: │
│ - CloudWatch Logs (parsed by orchestrator) │
│ - OR S3 presigned URL (one-time write, cross-account) │
│ │
└─────────────────────────────────────────────────────────────────────┘
Multi-Layer Defense
┌────────────────────────────────────────────────────────────────────┐
│ LAYER 1: AWS Account Isolation │
│ - Separate AWS account for sandbox │
│ - No cross-account roles/permissions │
│ - Service Control Policies (SCPs) deny everything except Lambda │
└────────────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────────────┐
│ LAYER 2: VPC Isolation │
│ - Private subnet only (no public) │
│ - No Internet Gateway, NAT Gateway, or VPC Peering │
│ - No VPC Endpoints (blocks AWS service access) │
│ - Network ACLs deny all traffic │
└────────────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────────────┐
│ LAYER 3: Lambda Configuration │
│ - IAM role with ZERO permissions │
│ - Reserved concurrency = 1 (prevent DoS) │
│ - Memory: 512MB max │
│ - Timeout: 5 minutes max │
│ - No environment variables with secrets │
│ - No layers (reduce attack surface) │
└────────────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────────────┐
│ LAYER 4: Runtime Restrictions │
│ - Custom runtime with seccomp profile │
│ - Block: ptrace, mount, setuid, network syscalls │
│ - Read-only /var/task (code) │
│ - Limited /tmp (512MB, wiped after) │
│ - No access to Lambda metadata endpoint │
└────────────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────────────┐
│ LAYER 5: Code-Level Sandboxing │
│ - vm2 or isolated-vm for Node.js │
│ - Timeout per test (30 seconds) │
│ - Memory limit per test (256MB) │
│ - Blocked globals: process.env, require('child_process'), etc. │
│ - Mocked network: all fetch/http return errors │
└────────────────────────────────────────────────────────────────────┘
Alternative: Firecracker microVMs
For even stronger isolation, use Firecracker (what Lambda uses internally):
┌─────────────────────────────────────────────────────────────────────┐
│ FIRECRACKER SANDBOX │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Host Machine (EC2) │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ Firecracker VMM │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ microVM (125ms boot time) │ │ │
│ │ │ ┌─────────────────────────────────────────────────────┐│ │ │
│ │ │ │ Minimal Linux kernel ││ │ │
│ │ │ │ • No network interfaces ││ │ │
│ │ │ │ • Read-only root filesystem ││ │ │
│ │ │ │ • virtio-vsock for host communication only ││ │ │
│ │ │ │ • Memory ballooning (limit RAM) ││ │ │
│ │ │ │ • Rate-limited I/O ││ │ │
│ │ │ └─────────────────────────────────────────────────────┘│ │ │
│ │ │ │ │ │
│ │ │ Destroyed after each test run │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ │
│ Benefits: │
│ - Hardware-level isolation (KVM) │
│ - 125ms cold start │
│ - Complete OS isolation │
│ - No container escape vectors │
│ │
└─────────────────────────────────────────────────────────────────────┘
Integration: JIT Package Sanitization
Full Pipeline
┌────────────────────────────────────────────────────────────────────────┐
│ NPM PROXY SANITIZATION PIPELINE │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ npm install foo@1.0.0 │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ NPM Proxy │ │
│ │ (Verdaccio) │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Cache Check │───▶│ Return cached │ (if sanitized version │
│ │ │ │ sanitized pkg │ exists) │
│ └────────┬────────┘ └─────────────────┘ │
│ │ (cache miss) │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Fetch from npm │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ STATIC ANALYSIS │ │
│ │ (fast, milliseconds) │ │
│ │ │ │
│ │ Clean ─────────────────────────────────▶ Pass through │ │
│ │ Malicious (high confidence) ───────────▶ Block │ │
│ │ Suspicious ────────────────────────────▶ LLM Analysis │ │
│ └─────────────────────────┬───────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ LLM ANALYSIS │ │
│ │ (slower, ~60 seconds) │ │
│ │ │ │
│ │ Clean ─────────────────────────────────▶ Pass through │ │
│ │ Malicious ─────────────────────────────▶ Remediation? │ │
│ └─────────────────────────┬───────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ REMEDIATION ASSESSMENT │ │
│ │ │ │
│ │ Can remediate (high confidence) ──────▶ Generate patch │ │
│ │ Cannot remediate ─────────────────────▶ Block package │ │
│ └─────────────────────────┬───────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ SANDBOX VALIDATION │ │
│ │ (Lambda/Firecracker) │ │
│ │ │ │
│ │ 1. Apply patch to package │ │
│ │ 2. Run package's test suite │ │
│ │ 3. Verify malware neutralized │ │
│ │ 4. Check functionality preserved │ │
│ │ │ │
│ │ All pass ──────────────────────────────▶ Cache & serve │ │
│ │ Tests fail ────────────────────────────▶ Block package │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
Confidence Thresholds for JIT
| Action | Required Confidence | Required Validation |
|---|---|---|
| Pass through | N/A (clean) | Static analysis clean |
| Block package | 95%+ malicious | LLM analysis |
| Auto-remediate | 98%+ remediation confidence | Sandbox tests pass |
| Manual review | <95% any direction | Queue for human |
Implementation Priority
Phase 1: Evolution Engine (Week 1)
- Gap analysis prompt for LLM
- Rule generation prompt
- Rule validation against samples
- Integration with static plugins
Phase 2: Remediation Engine (Week 2)
- Scope assessment prompt
- Patch generation prompt
- Strategy selection logic
- Diff generation
Phase 3: Sandbox (Week 3)
- Lambda function setup
- VPC configuration
- Test runner implementation
- Result reporting
Phase 4: Integration (Week 4)
- NPM proxy integration
- Caching layer
- Monitoring/alerting
- Manual review queue
Security Considerations
Sandbox Escape Mitigations
| Attack Vector | Mitigation |
|---|---|
| Network exfiltration | No network access (VPC isolation) |
| AWS credential theft | No IAM permissions, no metadata access |
| Container escape | Firecracker/Lambda hypervisor isolation |
| Resource exhaustion | Memory/CPU/time limits |
| Persistent backdoor | Ephemeral containers, destroyed after use |
| Side-channel attacks | Separate AWS account, no shared resources |
| Supply chain (sandbox deps) | Minimal runtime, pinned versions |
Trust Model
TRUST LEVELS:
1. UNTRUSTED: All npm packages
- Assume malicious
- Full analysis pipeline
2. LOW TRUST: Sanitized packages
- Passed analysis + remediation
- Cached with validation hash
3. MEDIUM TRUST: Popular packages (>1M weekly downloads)
- Still analyzed, but prioritized
- Historical safety considered
4. HIGH TRUST: Verified publishers
- npm 2FA + verified org
- Still analyzed (supply chain attacks)
NOTHING IS FULLY TRUSTED. VERIFY EVERYTHING.