🔒 Security
VEOX is built with a security-first architecture. This page provides a technical breakdown of our security layers, container hardening, and current vulnerability scan results.
Security Architecture
Defense in Depth
VEOX implements five independent security layers, each designed to contain threats even if other layers are compromised:
flowchart TD
subgraph L1 [Layer 1: Chainguard Base Image]
subgraph L2 [Layer 2: Dual-Encryption Enclaves]
subgraph L3 [Layer 3: Aegis Worker Sandboxing]
subgraph L4 [Layer 4: Encrypted IPC]
L5[Layer 5: Audit Trail & Risk Scoring]
end
end
end
end
classDef l1 fill:transparent,stroke:#ef4444,stroke-width:2px;
classDef l2 fill:transparent,stroke:#f59e0b,stroke-width:2px;
classDef l3 fill:transparent,stroke:#10b981,stroke-width:2px;
classDef l4 fill:transparent,stroke:#3b82f6,stroke-width:2px;
classDef l5 fill:#8b5cf6,stroke:#8b5cf6,color:#fff;
class L1 l1;
class L2 l2;
class L3 l3;
class L4 l4;
class L5 l5;| Layer | Technology | Protects Against |
|---|---|---|
| Chainguard Image | Minimal, signed, continuously patched base image | Supply chain attacks, known CVEs in OS packages |
| Dual-Encryption | AES-encrypted blobs, decrypted only in-memory at runtime | IP theft from container filesystem inspection |
| Worker Sandboxing | Linux RLIMIT, network namespace isolation | Memory bombs, CPU exhaustion, data exfiltration |
| Encrypted IPC | ChaCha20-Poly1305 over tmpfs Unix sockets | Inter-process eavesdropping, man-in-the-middle |
| Audit Trail | Immutable ledger of all supervisor actions | Forensic analysis, compliance requirements |
Vulnerability Scan Results
We continuously scan the VEOX container image using Trivy by Aqua Security — an industry-standard open-source vulnerability scanner. Below are the latest results.
Note
Scan performed on 2026-03-10 against veox-enclave-server:latest using Trivy.
Summary
| Severity | Count | Risk Assessment |
|---|---|---|
| 🔴 Critical | 2 | Debian OS packages — no fix available upstream |
| 🟠 High | 32 | 31 OS-level (no fix), 3 Python packages (fix available) |
| 🟡 Medium | 101 | OS-level, majority informational |
| ⚪ Low | 704 | OS-level, no exploitable risk in containerized context |
Detailed Findings
Python Package Vulnerabilities (Fix Available)
These are the only vulnerabilities with available patches and are targeted for the next release:
| CVE | Package | Installed | Fixed | Severity | Status |
|---|---|---|---|---|---|
| CVE-2026-23949 | jaraco.context |
5.3.0 | 6.1.0 | 🟠 HIGH | Patch planned |
| CVE-2026-24049 | wheel |
0.45.1 | 0.46.2 | 🟠 HIGH | Patch planned |
OS-Level Vulnerabilities (No Fix Available)
These are in the Debian base packages. No upstream patches exist yet. Risk is mitigated by the container sandboxing architecture:
| CVE | Package | Severity | Mitigation |
|---|---|---|---|
| CVE-2026-0861 | libc-bin |
🟠 HIGH | Workers sandboxed; library not invoked by VEOX workloads |
| CVE-2026-0861 | libc6 |
🟠 HIGH | Workers sandboxed; library not invoked by VEOX workloads |
| CVE-2023-25193 | libharfbuzz0b |
🟠 HIGH | Workers sandboxed; library not invoked by VEOX workloads |
| CVE-2023-2953 | libldap-2.5-0 |
🟠 HIGH | Workers sandboxed; library not invoked by VEOX workloads |
| CVE-2025-13836 | libpython3.11-minimal |
🟠 HIGH | Workers sandboxed; library not invoked by VEOX workloads |
| CVE-2025-15366 | libpython3.11-minimal |
🟠 HIGH | Workers sandboxed; library not invoked by VEOX workloads |
| CVE-2025-15367 | libpython3.11-minimal |
🟠 HIGH | Workers sandboxed; library not invoked by VEOX workloads |
| CVE-2025-69534 | libpython3.11-minimal |
🟠 HIGH | Workers sandboxed; library not invoked by VEOX workloads |
| CVE-2025-8194 | libpython3.11-minimal |
🟠 HIGH | Workers sandboxed; library not invoked by VEOX workloads |
| CVE-2026-1299 | libpython3.11-minimal |
🟠 HIGH | Workers sandboxed; library not invoked by VEOX workloads |
... and 21 additional OS-level HIGH findings.
Tip
All critical/high OS CVEs are in libraries not actively used by VEOX workloads. The worker sandbox prevents any exploitation path from user-submitted code to these libraries.
101 medium-severity findings, primarily in OS packages. These are standard for any Debian Bookworm-based image and are continuously monitored.
Key packages with MEDIUM findings:
| Package | CVE Count | Notes |
|---|---|---|
libpython3.11-minimal |
11 | Standard OS dependency |
libpython3.11-stdlib |
11 | Standard OS dependency |
python3.11 |
11 | Standard OS dependency |
python3.11-minimal |
11 | Standard OS dependency |
libexpat1 |
3 | Standard OS dependency |
libzzip-0-13 |
3 | Standard OS dependency |
dirmngr |
2 | Standard OS dependency |
gnupg |
2 | Standard OS dependency |
gnupg-l10n |
2 | Standard OS dependency |
gnupg-utils |
2 | Standard OS dependency |
gpg |
2 | Standard OS dependency |
gpg-agent |
2 | Standard OS dependency |
Note
Medium findings are reviewed weekly. Packages not used at runtime are candidates for removal in future image slimming efforts.
704 low-severity findings across standard Debian packages. These represent theoretical attack vectors that require local access and specific conditions to exploit — conditions that do not exist within the VEOX container's execution model.
Not actionable in a containerized, network-isolated worker architecture.
Container Hardening
Build-Time Protections
| Protection | Implementation |
|---|---|
| Chainguard builder | cgr.dev/chainguard/python:latest-dev — minimal attack surface |
| Non-root execution | Container runs as nonroot user, not root |
| Multi-stage build | Build tools, compilers, and source code stripped from final image |
| IP leak prevention | Automated audit step — build fails if VIP code leaks into public wheel |
| Encrypted artifacts | All proprietary code encrypted before shipping in image |
Runtime Protections
| Protection | Implementation |
|---|---|
| Worker RLIMIT | Memory (512MB), CPU (300s), file descriptors (256) per worker |
| Network isolation | Each worker runs in isolated network namespace — no outbound traffic |
| Encrypted IPC | ChaCha20-Poly1305 authenticated encryption on all worker channels |
| tmpfs sockets | IPC uses in-memory filesystem — never touches disk |
| Healthcheck | Built-in HTTP healthcheck every 30s with 5s timeout |
| Auto-recovery | Crashed workers auto-replaced; stalled workers killed after 120s |
| Retirement policy | Workers self-retire at 80% cumulative CPU to prevent degradation |
What We Don't Do
Equally important for security review — VEOX explicitly avoids:
| Anti-Pattern | VEOX Approach |
|---|---|
| ❌ Telemetry / phone-home | No outbound network calls, ever |
| ❌ External API dependencies | Fully self-contained, no cloud services |
| ❌ Privileged containers | Runs as nonroot, no --privileged flag |
| ❌ Plaintext source on disk | All proprietary code encrypted at rest |
| ❌ Shared memory between workers | Each worker has dedicated encrypted IPC channel |
| ❌ Persistent state | Stateless container — no databases, no file-based state |
Data Privacy
Your Data Stays Local
flowchart LR
Script[Your Python Client]
Mem[(Container Memory)]
Cloud((External Cloud))
Script -->|✅ Data IN:<br/>Your dataset| Mem
Mem -->|✅ Data OUT:<br/>Best pipeline| Script
Mem -.-x|❌ BLOCKED:<br/>No external sending| Cloud
Mem -.-x|❌ BLOCKED:<br/>No telemetry| Cloud
classDef pass fill:#10b981,stroke:#047857,color:#fff;
classDef blocked fill:#ef4444,stroke:#991b1b,color:#fff;
classDef store fill:#3b82f6,stroke:#1d4ed8,color:#fff;
class Script pass;
class Cloud blocked;
class Mem store;Compliance Considerations
| Requirement | How VEOX Meets It |
|---|---|
| Data residency | Single container, runs on your infrastructure — data never leaves |
| GDPR / CCPA | No personal data collection, no telemetry, no tracking |
| SOC 2 | Audit trail via Aegis ledger, encrypted IPC, sandboxed execution |
| Air-gapped networks | Fully offline-capable — no internet required after image pull |
| HIPAA | No PHI handling — VEOX processes your data in-memory only |
Reproducing the Scan
To run the same scan against your VEOX container:
# Install Trivy
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh
# Scan for HIGH and CRITICAL vulnerabilities
trivy image --severity HIGH,CRITICAL veox-enclave-server:latest
# Full scan (all severities)
trivy image veox-enclave-server:latest
# JSON output for CI/CD integration
trivy image --format json --output scan_results.json veox-enclave-server:latest
Tip
We recommend integrating Trivy into your CI/CD pipeline and scanning on every deployment. VEOX images are continuously updated to address new CVEs.