Security updates and vulnerability patches are applied to the active development branch and the latest tagged releases.
| Version | Supported | Status |
|---|---|---|
| 0.6.x | ✅ | Active Development (Phase 6 — Native eBPF Sensor) |
| 0.5.x | ✅ | Maintained (Phase 5 — External Sensor Adapters) |
| 0.4.x | ✅ | Maintained (Phase 4 — Capability Policy & Containment) |
| 0.3.x | ✅ | Maintained (Phase 3 — Identity Resolution & Correlation) |
| 0.2.x | ✅ | Maintained (Phase 2 — Detection Engine & Hot State) |
| 0.1.x | ✅ | Maintained (Phase 1 — Core Architecture) |
| < 0.1 | ❌ | Unsupported |
The maintainers of the Distributed Security Control Plane take the security of this platform seriously. Because this software coordinates threat containment and policy enforcement across multiple enterprise applications, vulnerabilities within the control plane are treated with the highest severity.
If you discover a security vulnerability, architectural weakness, or potential bypass:
- Do NOT disclose the issue publicly via GitHub issues, discussions, pull requests, or social media.
- Use GitHub's private vulnerability reporting:
- Navigate to the repository's Security tab → Advisories → Report a vulnerability.
- This creates a private, confidential thread visible only to maintainers.
- Alternatively, send a detailed report via email to the project maintainers.
| Field | Details |
|---|---|
| Component Affected | Specify the crate or module (e.g., crates/sensor-native, crates/engine, crates/correlator, crates/control-plane, crates/agent-sdk, crates/common). |
| Severity Estimate | Your assessment: Critical / High / Medium / Low. |
| Reproduction Steps | Step-by-step instructions or a proof-of-concept payload. |
| Impact Assessment | Potential impact on application availability, containment integrity, data confidentiality, or trust boundaries. |
| Affected Versions | Which version(s) are affected, if known. |
| Suggested Fix | Optional: your recommended remediation approach. |
The system is designed with explicit trust boundaries to ensure that a compromise of any single sensor, application, or model cannot compromise the control plane:
UNTRUSTED INPUTS ROOT OF TRUST CONSUMERS
┌─────────────────────────┐ ┌─────────────────────────┐ ┌──────────────┐
│ Application Telemetry │ ──► │ │ ──► │ Dashboard │
├─────────────────────────┤ │ Deterministic Rust │ └──────────────┘
│ Native eBPF Sensor │ ──► │ Policy Engine │ ┌──────────────┐
│ (execve, connect, bind) │ │ │ ──► │ Local Agents │
├─────────────────────────┤ │ (Validates, Authorizes,│ │ (Containment)│
│ External Sensors │ ──► │ Signs All Commands) │ └──────────────┘
│ (Tetragon/Falco/Hubble) │ │ │ ┌──────────────┐
└─────────────────────────┘ └────────────┬────────────┘ ──► │ OS Enforcers │
│ │(nftables/XDP)│
Strict Schema & Policy Gate └──────────────┘
│
┌────────────▼────────────┐
│ Off-Path LLM Worker │
│ (Advisory Only, Mode B)│
└─────────────────────────┘
-
Zero Request-Path Coupling: Normal application requests (
Client -> App -> Response) must never synchronously wait for security ingestion, correlation, detection, or policy evaluation. -
Deterministic Core as Root of Trust: The deterministic Rust capability policy engine alone makes binding containment decisions. LLM/AI workers have zero direct execution authority.
-
Cryptographically Signed Containment: All containment commands are Ed25519-signed with mandatory TTLs, sequence IDs, and replay protection.
-
Universal Normalization: Every sensor (native eBPF, external adapters, application emitters) normalizes to canonical
SecurityEvent. -
Absolute DENY Precedence: In the capability policy engine,
DENYstrictly takes precedence overALLOW. -
Graceful Fallback Resilience: The control plane must survive Redis/PostgreSQL outages;
MemoryHotStateand in-memory streams serve as resilient fallbacks. -
No Panic in Production: Zero
unwrap()in production execution paths; errors must be handled gracefully with?,match, or structured error types. -
Structured Observability: Tracing only (
tracing::info!,warn!,error!); no rawprintln!in production code. -
Separated eBPF Compilation: Standard
cargo buildproduces a working binary on any platform without requiring an eBPF toolchain. -
Non-Privileged Testability: Every phase includes unit tests and integration tests that run without root privileges.timestamp (TTL) and rollback recipe.
-
Out-of-Band Application Resilience: Normal application traffic (
Client -> App -> Response) never synchronously blocks on the control plane. In the event of a security controller outage, protected applications continue serving normal requests uninterrupted. -
Identity Isolation: The Identity Resolution and Correlation Engine operates on derived canonical identifiers. Raw PII is never stored in the correlation graph — only hashed or tokenized entity references are maintained.
-
Capability Least-Privilege: Inferred capabilities follow a Deno-style model — each entity's effective permissions are dynamically computed from observed behavior, never statically granted.
This project is licensed under the GNU Affero General Public License v3.0 specifically because:
- The control plane is designed to operate as a network service. The AGPL's Section 13 ensures that organizations running modified versions as a service must make corresponding source code available — preventing proprietary forks from fragmenting the security community's collective defense.
- Strong copyleft ensures all improvements to detection rules, correlation logic, and containment strategies remain available to the community.
- Minimal Dependencies: The core engine crates (
engine,correlator,common) minimize external dependencies to reduce supply chain attack surface. - Cargo Audit: Run
cargo auditregularly to check for known vulnerabilities in dependencies. - Lockfile Committed:
Cargo.lockis committed to the repository for reproducible builds.
When deploying this control plane in production:
- Network Isolation: The control plane API should be accessible only from trusted application agents and the operations dashboard, not the public internet.
- TLS Everywhere: All telemetry ingestion and command channels should use TLS 1.3.
- Principle of Least Privilege: The control plane process should run with minimal OS privileges; it does not require root access.
- Audit Logging: Enable durable PostgreSQL audit logging for all containment actions and incident lifecycle transitions.
- Key Management: Ed25519 signing keys for containment commands should be stored in a hardware security module (HSM) or secure key vault in production deployments.
We gratefully acknowledge security researchers who responsibly disclose vulnerabilities. Unless anonymity is requested, reporters will be credited in the security advisory and the project's release notes.
Thank you for helping keep the Distributed Security Control Plane secure. 🛡️