Third-Party Software Security Review — SCORPIOX CODE

---

1. Executive Summary

This report presents a comprehensive security audit of SCORPIOX CODE, an AI-powered development tool and CLI platform written in pure C with zero external runtime dependencies. The codebase spans 403,876 lines of code (173,858 first-party, 230,018 vendored) across approximately 149 non-vendor source files. Thirteen specialized audit agents analyzed the software across all major security domains.

Key Findings

Overall Risk Rating: LOW-MEDIUM

The software demonstrates mature security engineering practices across the majority of its codebase:

• Zero critical vulnerabilities were identified across all 13 audit domains.
• Buffer safety discipline is exceptional — 99.95% of 2,900+ string operations use bounds-checked functions (snprintf, strncpy). No uses of strcpy, strcat, or gets were found.
• Memory safety is strong — 92%+ of 454 allocation sites have proper NULL checks. All realloc patterns use safe temporary variables. The project's sx_strdup() wrapper aborts on OOM.
• Supply chain is clean — only 2 vendored C libraries (Mbed TLS 3.6.6, yyjson 0.12.0), both well-maintained and properly licensed. No pre-built binaries ship in the repository.
• All telemetry is disabled by default — no network calls at startup, no mandatory data collection. Both tracking subsystems (USAGE_TRACKING, EMIT_SESSION_TRACKING) default to off.
• TLS defaults are strong — certificate verification is enabled by default with centralized configuration across all 9 curl callsites.

The 7 high-severity findings are concentrated in two areas:

Install script integrity (3 findings): Install scripts download archives without checksum verification, get.scorpiox.net accepts HTTP without redirect, and no code signing exists.

Command injection on Windows (2 findings): The HTTP server's Windows CGI path and git deploy handler use shell interpolation with incomplete sanitization.

Memory safety (1 finding): A fragile use-after-free contract in the provider vtable cleanup pattern.

Privilege isolation (1 finding): The --privileged container flag bypasses user namespace isolation.

For Windows workstation deployment (the primary corporate use case), the risk profile is LOW — the most concerning findings (install script integrity, Windows CGI injection) are either mitigable through network controls or limited to server-mode operation not typical of developer workstation use.

---

2. Deployment Scope

Windows Workstation (Primary Deployment Target)

The following binaries compile and deploy on Windows:

Additional Windows-compiled binaries (43 total): scorpiox-agent, scorpiox-askuserquestion, scorpiox-beam, scorpiox-claudecode-fetchtoken, scorpiox-claudecode-models, scorpiox-claudecode-refreshtoken, scorpiox-codex-fetchtoken, scorpiox-codex-refreshtoken, scorpiox-conv, scorpiox-debug, scorpiox-dns, scorpiox-email, scorpiox-emit-session, scorpiox-frp, scorpiox-gemini, scorpiox-gemini-fetchtoken, scorpiox-hook, scorpiox-host, scorpiox-kql, scorpiox-logger, scorpiox-mcp, scorpiox-mirror-git, scorpiox-multiplexer, scorpiox-openai, scorpiox-otp, scorpiox-planmode, scorpiox-printlogs, scorpiox-rewind, scorpiox-sdk, scorpiox-search, scorpiox-server, scorpiox-server-email, scorpiox-server-fetchtoken, scorpiox-server-http2tcp, scorpiox-skills, scorpiox-systemprompt, scorpiox-tasks, scorpiox-tmux, scorpiox-transcript, scorpiox-usage, scorpiox-vault-git, scorpiox-voice.

Linux-Only Binaries (Not Deployed on Windows)

Windows-Filtered Findings

When excluding findings that apply only to Linux-only components:

The reduction is primarily from Linux-specific findings in privilege management (container --privileged flag, thunderbolt4 root requirement, KVM access), file I/O (O_CLOEXEC, PID file TOCTOU), and command injection (Linux-only tool paths).

---

3. Changes Since Last Audit

Findings Delta by Severity

Windows Findings Delta

Summary: Significant improvement across all actionable severity levels. Critical findings dropped from 2 to 0, high findings reduced by 61%, and medium findings reduced by 72%. The increase in informational findings reflects more thorough enumeration of network endpoints and positive security controls (not security defects). The codebase grew by 21,111 lines of project code with a net decrease in vulnerability count — indicating improved code quality practices.

---

4. Supply Chain & Dependencies

Agent Risk Rating: LOW

The project has a minimal and well-controlled supply chain:

Key Positives:

• No FetchContent, ExternalProject, or runtime dependency downloads in the CMake build
• No pre-built binaries in the repository — everything builds from source
• Alpine Docker base image is SHA256 digest-pinned
• Curl source download in ARM64 Dockerfile is integrity-verified
• npm/Bun dependencies are lockfile-pinned with integrity hashes

Findings:

---

5. Build System & Code Provenance

Agent Risk Rating: LOW

The project uses a two-tier CMake build system (C11) with comprehensive security hardening:

Build provenance is maintained via build-info.json files with commit hash, branch, date, and platform. Model header code generation (generate_models) is frozen by default (MODELS_FROZEN = True) and disabled in release builds.

Findings:

---

6. Network Endpoints

Agent Risk Rating: LOW

A total of 364 URL references were found (218 in vendored code, 146+ in project code). All external endpoints serve legitimate purposes:

Findings:

---

7. TLS/SSL Security

Agent Risk Rating: MEDIUM

The codebase has a centralized TLS configuration (sx_tls.h) that ensures consistent certificate verification across all 9 curl callsites. Defaults are strong with verification enabled.

Findings: Positive Controls:

• Defense-in-depth defaults: SX_TLS_VERIFY defaults to true with warning when disabled
• Fail-closed relay TLS: aborts when CA bundles fail to load
• STARTTLS enforcement on port 587 submission
• SNI hostname properly set in all mbedTLS contexts
• All external API endpoints default to HTTPS
• IMAPS (port 993) for IMAP connections

---

8. Hardcoded Credentials

Agent Risk Rating: LOW No actual secrets, API keys, or passwords are hardcoded in the codebase. All credential configuration fields use empty-string placeholders, deferring injection to runtime. Findings:

---

9. File I/O & Data Handling

Agent Risk Rating: LOW-MEDIUM

File I/O practices are generally strong:

• Exclusive use of mkstemp()/mkdtemp() — zero uses of insecure tmpnam()/tempnam()
• Sensitive config files are chmod 0600; directories are 0700
• API keys are redacted from traffic logs
• Atomic file writes via rename pattern in critical paths

Findings:

---

10. Buffer Safety

Agent Risk Rating: LOW

Buffer safety discipline is exceptional across the codebase:

Findings:

---

11. Memory Safety

Agent Risk Rating: LOW

Memory management is well-disciplined:

Findings:

---

12. Command Injection

Agent Risk Rating: MEDIUM

Most code paths use fork()+execvp() (argv-based, no shell) — the safe approach. Where system()/popen() is used, input validation is generally present (is_safe_shell_arg(), SX_SANITIZE_CMD, character whitelisting, single-quote escaping).

Findings:

---

13. Privilege & Access Control

Agent Risk Rating: MEDIUM

No setuid/setgid bits are set on any binary. The container runtime (scorpiox-unshare) implements comprehensive Linux namespace isolation with pivot_root.

Findings: Positive Controls:

• Container runtime implements CLONE_NEWNS | CLONE_NEWPID | CLONE_NEWUTS | CLONE_NEWUSER | CLONE_NEWNET
• Filesystem isolation via pivot_root() with old root unmounted
• Mount hardening: MS_NOSUID | MS_NODEV | MS_NOEXEC on proc, sysfs, devpts
• IPC exclusively via pipes (minimal attack surface)
• No shared memory, Unix domain sockets, or message queues for IPC

---

14. Windows Deployment Analysis

Agent Risk Rating: LOW

The Windows deployment surface is clean and well-structured:

• 53 binaries compile on Windows; 13 are correctly excluded as Linux-only
• Platform-specific code is properly guarded with #ifdef SX_WINDOWS / if(WIN32) CMake guards
• No registry access, service installation, UAC elevation, or DLL injection patterns found
• Standard Win32 API usage: WinINet, CreateProcessA, GDI (screenshot), Winsock2, bcrypt
• Self-update mechanism (scorpiox-wsl) verifies SHA256 checksums of downloaded binaries
• Uses _spawnvp and CreateProcessA (safe) rather than system() for WSL invocation

---

15. Telemetry and Tracking

Agent Risk Rating: LOW Verdict: No tracking by default.

• No network calls at startup in the main sx binary
• No mandatory data collection exists that cannot be disabled
• When tracking is explicitly enabled, data includes: session metadata, token counts, machine fingerprint (hostname, username, OS), and project context
• EMIT_SESSION_TRACKING (when enabled) sends full conversation content — users should be aware of scope

For zero-tracking corporate deployment, no configuration changes are needed — defaults are already off. Findings:

---

16. Install Script & Distribution Security

Agent Risk Rating: MEDIUM

The installation mechanism uses curl|bash / iwr|iex pattern. While internal components (scorpiox-wsl, libsxbridge) implement SHA256 verification, the user-facing install scripts do not.

Findings: Positive Controls:

• SHA256 checksums are generated and published alongside archives during release
• Per-commit build provenance (build-info.json) is published
• dist.scorpiox.net redirects HTTP→HTTPS (308 Permanent Redirect)
• C-level components implement SHA256 verification (WSL: open, Bridge: fail-closed)

---

17. Consolidated Risk Matrix

---

18. Conclusion & Recommendations

Overall Assessment

SCORPIOX CODE demonstrates a mature security posture for a large C codebase. The software exhibits:

• Architectural security awareness: centralized TLS configuration, fork()+execvp() preference over system(), abort-on-OOM wrappers, mkstemp() for all temp files, comprehensive namespace isolation in the container runtime
• Zero critical vulnerabilities across 13 audit domains and 403,876 lines of code
• Significant improvement over the previous audit: critical findings eliminated (2→0), high findings reduced by 61%, medium findings reduced by 72%
• Privacy-respecting defaults: all telemetry disabled by default, no startup network activity

Priority Recommendations

Immediate (High Priority):

Implement checksum verification in install scripts — the infrastructure already generates SHA256 sidecars; install scripts need to consume them

Enforce HTTPS on get.scorpiox.net — add HTTP→HTTPS redirect for the install script server

Migrate Windows cmd /C CGI path to CreateProcess() — eliminate shell interpolation for HTTP-received inputs

Document the provider vtable memory contract — add explicit comment that vtable->free() must not free the provider struct itself, or restructure the cleanup order

Short-Term (Medium Priority):

Add O_CLOEXEC to all open() calls across the codebase

Clamp snprintf return values in accumulation patterns (IMAP, email builders)

Migrate remaining popen()/system() calls on Windows to CreateProcess() with argv arrays

Add mbedtls_ssl_conf_min_tls_version() to all mbedTLS contexts

Replace hardcoded internal IPs with configurable variables

Implement code signing for release artifacts (Sigstore/GPG)

Long-Term (Hardening):

Implement atomic installation with staging directory

Add privilege dropping after binding privileged ports

Consider DANE/TLSA or MTA-STS for outbound mail TLS

Add per-module TLS verification controls instead of global toggle

Provide uninstall mechanism across all platforms

Windows Workstation Risk Rating

For the primary deployment scenario of Windows developer workstations using the CLI tools (not running server components):

Risk: LOW — The software is safe for Windows workstation deployment. The highest-risk findings (install script integrity, Windows CGI injection) are mitigated by:

• Corporate deployment can distribute binaries via internal package management, bypassing the install script entirely
• CGI/server functionality is not part of typical developer workstation use
• No registry modification, UAC elevation, or service installation patterns
• All telemetry disabled by default
• Self-update mechanism (WSL helper) implements SHA256 verification

---

19. Appendix: Audit Methodology

Audit Agents

Tools & Techniques

• Static analysis via grep, awk, and pattern matching across all non-vendor source files
• Manual code review of all flagged patterns with context analysis
• CWE classification for all confirmed findings
• CVSS scoring for command injection findings
• Cross-reference between audit domains (e.g., TLS findings validated against network endpoint inventory)
• Comparison against industry best practices (Homebrew, rustup, nvm for install scripts)

Scope Exclusions

• Vendored library internals (Mbed TLS, yyjson) — assessed at version/CVE level only
• Runtime behavior / dynamic analysis — this is a static source code audit
• Third-party API security (Anthropic, OpenAI, Google) — out of scope
• Infrastructure security of distribution servers — limited to observable behavior

---

Report generated by automated security audit pipeline — 13 agents, unified analysis Classification: CONFIDENTIAL — For Corporate Review Only