Security considerations and hardening measures for the WebAssembly Compositional System.

The system implements multiple layers of protection against denial-of-service attacks:

Plan Limits:

• Maximum plan file size: 1MB
• Maximum components per plan: 1,000
• Maximum bindings: 10,000
• Maximum graph depth: 100 levels

Blob Limits:

• Maximum blob size: 100MB
• Total system memory limit: 1GB

See hosts/wasmtime/src/limits.rs for full implementation.

pub struct SystemLimits {
    pub max_plan_size: usize,           // 1MB
    pub max_components: usize,          // 1,000
    pub max_bindings: usize,            // 10,000
    pub max_graph_depth: usize,         // 100 levels
    pub max_blob_size: u64,             // 100MB
    pub max_total_memory: u64,          // 1GB
}

Multi-phase validation pipeline ensures no panic or OOM on invalid input:

1. Schema Validation

   • Version checking
   • Required fields present
   • Type correctness

2. Blob Availability

   • All components present in blob store
   • SHA-256 digest verification

3. Graph Structure

   • Cycle detection
   • Connectivity validation
   • Depth limits

4. Binding Validation

   • References point to valid components
   • Import/export compatibility
   • No dangling bindings

• No capabilities granted by default
• Explicit opt-in required via policy
• Policy-based filtering at runtime
• Capability violations logged to audit trail

• Tenant separation via tenant_id
• Cache isolation per tenant
• Audit log separation
• Metric namespacing

• Secrets never logged or exposed in errors
• Token-based access only
• Backend-specific validation
• Lifetime limits enforced

• Environment variables (dev only)
• HashiCorp Vault
• PKCS#11 hardware tokens
• Custom backends via plugin interface

• SigStore (Cosign)
• PGP/GPG signatures
• X.509 certificates
• Custom verifiers

pub struct ComponentVerification {
    pub digest: Vec<u8>,           // SHA-256 of component
    pub signature: Option<Vec<u8>>,
    pub verifier: Option<String>,  // Which backend verified
}

• Plan validation attempts
• Blob storage operations
• Secret access requests
• Policy enforcement decisions
• Component execution events
• Capability grant/deny decisions

{
  "timestamp": "2024-01-01T12:00:00Z",
  "tenant_id": "tenant-123",
  "event_type": "secret_access",
  "component_id": "comp-abc",
  "details": {
    "secret_id": "api-key",
    "backend": "vault://secrets",
    "result": "granted"
  }
}

• Each tenant has isolated:
  • Blob storage namespace
  • Cache directory
  • Audit logs
  • Metrics namespace
  • Secret access scope

Per-tenant limits can be configured via policy:

pub struct TenantLimits {
    pub max_components: usize,
    pub max_memory_bytes: u64,
    pub max_execution_time_ms: u64,
}

1. Fuzzing Coverage

   • Plan CBOR parser fuzzed via cargo fuzz (libFuzzer), target plan_parse
   • WIT canonicalization still needs fuzzing
   • Status: Plan parser covered (1.25M+ execs clean); WIT canon pending

2. Performance Profiling

   • Criterion benchmarks for the hot plan paths (cargo bench -p compose-core)
   • Cache optimization opportunities remain
   • Status: Benchmark suite in place; broader profiling informal

3. Edge Cases

   • Some resource exhaustion scenarios may exist
   • Complex graph patterns not fully tested
   • Status: Basic coverage complete

• Fuzzing — plan CBOR parser fuzzed via cargo fuzz (libFuzzer): libs/compose-core/fuzz, target plan_parse (cargo fuzz run plan_parse). Remaining: WIT canonicalization fuzzing.
• Performance benchmarking suite — criterion benches for the hot plan paths (encode/decode/digest/validate): cargo bench -p compose-core.
• Advanced DOS protection (rate limiting)
• Side-channel resistance analysis
• Formal verification of critical paths

• ✅ Malicious plans (validated, rejected)
• ✅ Resource exhaustion (limited, bounded)
• ✅ Capability violations (enforced, logged)
• ✅ Secret leakage (protected, never exposed)
• ✅ Unauthorized component execution (policy enforced)

• ⚠️ Side-channel attacks (timing, cache)
• ⚠️ Speculative execution vulnerabilities
• ⚠️ Physical access to blob storage
• ⚠️ Compromised host environment

1. Enable Audit Logging

   let audit_logger = AuditLogger::new(PathBuf::from("/var/log/compositor"))?;

2. Set Conservative Resource Limits

   let limits = SystemLimits {
       max_plan_size: 512 * 1024,      // 512KB
       max_components: 100,             // Lower for production
       max_bindings: 1000,
       ..Default::default()
   };

3. Require Component Signatures

   let policy = HostPolicy {
       require_signatures: true,
       allowed_verifiers: vec!["sigstore".to_string()],
       ..Default::default()
   };

4. Isolate Tenants

   • Use separate blob directories per tenant
   • Configure tenant-specific limits
   • Monitor cross-tenant isolation

5. Monitor Metrics for Anomalies

   • Track execution times
   • Monitor memory usage
   • Alert on policy violations

6. Regular Security Updates

   • Keep Wasmtime updated
   • Update dependencies regularly
   • Review security advisories

To report security vulnerabilities, please email: security@example.com

Do not open public issues for security vulnerabilities.

• ✅ Build provenance tracking
• ✅ Signed attestations (see attest.rs)
• ✅ Reproducible builds (strict determinism mode)

• SLSA: https://slsa.dev/
• WebAssembly Security: https://webassembly.org/docs/security/
• OWASP Top 10: https://owasp.org/www-project-top-ten/
• CWE Top 25: https://cwe.mitre.org/top25/