Third-Party Software Security Review — ScorpioX Code

Product: ScorpioX Code Website: https://code.scorpiox.net Publisher: ScorpioX Inc Category: AI-Powered Development Tool / CLI Platform Language: Pure C (zero external dependencies) Audit Date: 2026-04-28 Codebase Commit: f7f14b49ca77bfb07d31a819de0791445d3c02a5 Branch: main Classification: CONFIDENTIAL — For Corporate Review Only

---

1. Executive Summary

This report presents the findings of a comprehensive security assessment of ScorpioX Code, an AI-powered development tool and CLI platform published by ScorpioX Inc. The product is built entirely in pure C (~370,000 lines of code) with zero package manager dependencies. All third-party libraries (mbedTLS for cryptography, yyjson for JSON parsing) are vendored as source code and compiled directly into the binary.

Key Security Strengths

• Zero dependency supply chain: No npm, pip, cargo, go modules, or any package manager is used. The C build has no external fetch steps — no FetchContent, no ExternalProject, no git submodules.
• Single static binary: On Linux, the application compiles to a fully statically-linked binary with only libc as a runtime dependency, eliminating shared library hijacking risks.
• Full code provenance: All 996 commits in the repository originate from ScorpioX organization email addresses (scorpiox.net, scorpioplayer.com). No external contributors were found.
• Vendored source code: The only two third-party libraries (mbedTLS ~225K LOC, yyjson ~743KB) are committed as auditable source with their original licenses.
• No classic C vulnerabilities: Zero instances of strcpy, strcat, sprintf, or gets in project-owned code. snprintf is used consistently (2,282 instances).

Key Findings Requiring Attention

Overall Risk Rating: MEDIUM

The core architecture demonstrates exemplary supply chain security — the zero-dependency, single-binary, pure-C approach with full commit provenance is best-in-class. However, the application has a broad attack surface due to its multi-tool nature (HTTP server, email server, DNS server, container runtime, VM hypervisor) and contains several areas where input validation and transport security should be hardened. The critical findings are primarily in peripheral components (WASM config, token fetchers, CGI server) rather than the core AI assistant workflow.

For corporate deployment as an AI coding assistant: The primary user-facing workflow (TUI → AI provider API) uses HTTPS with proper TLS via libcurl and represents low risk. The critical findings affect infrastructure/deployment components that may not be relevant to all deployment scenarios.

---

2. Application Overview

ScorpioX Code (https://code.scorpiox.net) is an AI-powered coding assistant, agent orchestrator, and container runtime platform. It provides:

• AI Chat TUI: Interactive terminal interface supporting multiple AI providers (Anthropic Claude, OpenAI/Codex, Google Gemini) with streaming responses
• Agent Orchestration: SDK for orchestrating AI agents with tool use, file editing, and command execution
• Container Runtime: Linux container engine using user namespaces (scorpiox-unshare) with rootless operation by default
• VM Hypervisor: KVM-based virtual machine support (scorpiox-vm)
• Development Tools: Built-in web server, email server, DNS server, file transfer, voice transcription, and terminal multiplexer

Technical Architecture

---

3. Architecture & Supply Chain

Source: 01-architecture.md

3.1 Dependency Model

ScorpioX Code follows a vendored dependency model — the gold standard for supply chain security:

No package manager files affect the C build. A bridge/package.json exists for a standalone WhatsApp bridge (TypeScript/Bun) which is entirely separate from the C compilation pipeline.

3.2 Build Process Security

• No network downloads during build: Zero instances of FetchContent, ExternalProject, file(DOWNLOAD), or URL-based downloads in CMake
• Static linking: SX_STATIC_LINK ON by default — eliminates shared library hijacking
• Frozen code generation: A Python script generates model definitions at build time but is frozen (no network fetch)
• System compiler: Uses system-installed gcc/clang — no downloaded/pinned toolchain

3.3 Code Provenance

All 996 commits originate from ScorpioX organization email addresses. No external contributors, no public email providers (Gmail, Outlook, etc.).

3.4 Findings

---

4. Network Security

Source: 02-network.md

4.1 Network Activity Overview

ScorpioX Code is a network-active application with ~90+ source files containing network code. Network activity is categorized as:

4.2 TLS Implementation

• Primary: libcurl handles all HTTPS connections with system CA certificates
• Secondary: mbedTLS provides TLS for SMTP, FRP tunneling, and mail queue
• WASM: Browser fetch() API inherits browser TLS

4.3 Critical Network Findings

4.4 Network Mitigations

• All AI provider API calls use HTTPS with proper TLS verification via libcurl
• OAuth refresh flows to anthropic.com and openai.com use HTTPS
• FRP tunneling encrypts payload with AES-128-CFB
• DNS server supports audit logging
• Session telemetry is opt-in (EMIT_SESSION_TRACKING defaults to off)

---

5. Data Handling & Privacy

Source: 03-data-handling.md

5.1 Data Flow Architecture

User Input → sx TUI → libsxnet (API provider) → HTTPS → Remote AI API
                 ↓
        .scorpiox/sessions/<id>/   (conversations, traffic, logs)
        .scorpiox/conversations/   (persistent conversation JSON)
        .scorpiox/traces/          (debug trace JSONL)

5.2 Data Sensitivity by Component

5.3 Configuration & Secrets Management

Configuration uses a cascade model: built-in defaults → exe_dir/scorpiox-env.txt → .scorpiox/scorpiox-env.txt → ~/.config/scorpiox/scorpiox-env.txt. API keys and secrets are stored as plaintext in these config files.

Positive findings:

• Config snapshots at session start redact sensitive keys (masked with **)
• Config system (sx_config_get()) avoids polluting process environment with secrets
• scorpiox-sshpass passes password via PTY write (not environment variable)

Negative findings:

• No encryption at rest for any persistent data
• All credentials stored as plaintext in config files
• Session traffic directory contains full API payloads including headers with API keys
• TOTP secrets and SSH passwords visible in /proc//cmdline

5.4 Encryption Assessment

5.5 Data Retention

• Session retention: configurable via SESSION_RETENTION_DAYS; cleanup at session creation
• Conversation retention: no automatic cleanup; persists indefinitely
• Email retention: Maildir-based; no automatic expiration
• Default: sessions persist indefinitely if retention not configured

5.6 Critical Data Handling Findings

---

6. Code Security Vulnerabilities

Source: 04-vulnerabilities.md

6.1 Vulnerability Overview

The codebase demonstrates generally sound C programming practices:

• ✅ Zero instances of strcpy, strcat, sprintf, or gets
• ✅ Consistent use of snprintf (2,282 instances)
• ✅ malloc/calloc return values generally checked
• ⚠️ system()/popen() used extensively (118+ and 61+ call sites respectively)

6.2 Critical & High Vulnerabilities

6.3 Medium Vulnerabilities

6.4 Positive Security Patterns

The codebase employs several commendable security practices:

• No classic buffer overflows: Complete absence of strcpy/strcat/sprintf/gets
• Consistent bounds checking: snprintf used throughout with proper buffer sizes
• Memory allocation checks: malloc/calloc returns are generally validated
• Static linking: Eliminates DLL/shared library hijacking vectors

---

7. Permissions & System Access

Source: 05-permissions.md

7.1 Permission Model Overview

The ScorpioX platform encompasses components with vastly different privilege requirements:

7.2 Process Spawning

7.3 Sandboxing & Isolation

Container Runtime (scorpiox-unshare):

• ✅ User namespaces by default (rootless containers)
• ✅ Mount namespace isolation with pivot_root
• ✅ PID namespace isolation
• ✅ Network namespace (optional)
• ✅ Cgroup v2 memory limits
• ⚠️ --privileged mode bypasses user namespaces
• ❌ No seccomp filtering
• ❌ No AppArmor/SELinux profiles

No setuid binaries: The codebase does not install any setuid/setgid binaries. It relies on system-provided setuid helpers (newuidmap/newgidmap) for container UID mapping.

7.4 Filesystem Access Patterns

• Configuration: reads from exe_dir, CWD .scorpiox/, and ~/.config/scorpiox/
• Session data: writes to .scorpiox/sessions// in the working directory
• Container images: downloaded to and extracted in working directory
• Temp files: /tmp/sx_post_*, /tmp/sxmux/ (predictable names)
• No access to files outside the working directory tree in normal operation

---

8. Consolidated Risk Matrix

---

9. Conclusion & Recommendations

9.1 Overall Assessment

ScorpioX Code demonstrates a security-conscious architecture that is rare among modern development tools. The pure C implementation with zero package manager dependencies, vendored source-only libraries, static linking, and single-organization commit provenance eliminates entire categories of supply chain attacks that plague tools built on npm, pip, or other package ecosystems.

The codebase shows disciplined C programming with consistent use of snprintf and absence of classic buffer overflow patterns. The vendored dependency approach (mbedTLS + yyjson as source) provides full auditability and eliminates dependency confusion attacks.

However, the application's broad scope — encompassing an AI assistant, HTTP server, email server, DNS server, container runtime, and VM hypervisor — creates a wide attack surface. The most significant findings relate to:

Transport security gaps: Token fetchers and internal services that disable TLS verification or use plaintext protocols

Command injection surfaces: The pervasive system()/popen() pattern with shell interpolation

Secrets management: Plaintext credential storage and process-visible passwords

9.2 Priority Recommendations

Immediate (Critical — fix before production deployment):

Remove hardcoded API keys from WASM embedded configuration

Enable TLS certificate verification on all token fetch and OAuth paths

Migrate token.scorpiox.net endpoints to HTTPS

Replace system() with execve() in network-reachable code paths (CGI server)

Stop passing passwords/secrets via command-line arguments (use stdin/FD)

Short-term (High — address within 30 days):

Implement code signing for auto-update downloads

Migrate email password storage to bcrypt/Argon2 with salts

Add compiler hardening flags (-fstack-protector-strong, -D_FORTIFY_SOURCE=2)

Increase FRP PBKDF2 iterations to ≥600,000; replace MD5 login

Use mkstemp() for all temporary file creation

Medium-term (Medium — address within 90 days):

Create a safe command builder API to gradually replace snprintf + system() patterns

Add seccomp BPF filtering for container workloads

Implement optional at-rest encryption for session data

Extend config masking to cover all sensitive key patterns

Add constant-time comparison for token/key validation

9.3 Suitability for Corporate Use

As an AI coding assistant (primary use case): ScorpioX Code's core workflow — user types a prompt, the TUI sends it to an AI API over HTTPS, and displays the response — is low risk. The HTTPS transport, proper TLS verification on AI provider connections, and absence of telemetry by default make it suitable for corporate environments where:

• The deployment uses API keys from the organization's own AI provider accounts
• The scorpiox-env.txt config file is protected with appropriate filesystem permissions
• Optional infrastructure components (email server, DNS server, container runtime) are evaluated separately if needed
• Session data directories are treated as sensitive and included in backup/retention policies

---

10. Appendix: Audit Methodology

10.1 Scope

This audit covered the complete ScorpioX Code codebase at commit f7f14b49ca77bfb07d31a819de0791445d3c02a5 on the main branch. The audit encompassed 369,495 lines of code across 493 C/H source files.

10.2 Audit Agents

Five specialized security audit agents conducted independent analyses:

10.3 Methodology

Each agent performed:

• Static analysis: Source code review of all non-vendor C files
• Pattern matching: Automated scanning for dangerous functions, hardcoded credentials, and insecure patterns
• Build system review: CMake configuration, compiler flags, linking strategy
• Configuration analysis: Config file formats, cascade model, secret handling
• Git history review: Commit provenance, author analysis, binary file detection

10.4 Limitations

• This is a static code audit — no runtime testing, fuzzing, or penetration testing was performed
• Vendor code (mbedTLS, yyjson) was identified but not audited in depth (these are well-known, independently audited libraries)
• Windows-specific code paths (CreateProcessA, cmd /C) were reviewed statically but not tested on Windows
• WASM build configuration was reviewed but not compiled/tested

10.5 Classification

This report is classified as CONFIDENTIAL — For Corporate Review Only. Distribution should be limited to security teams, IT governance, and authorized decision-makers evaluating ScorpioX Code for corporate deployment.

---

Report compiled on 2026-04-28 by Security Audit Agent ScorpioX Code — https://code.scorpiox.net