Third-Party Software Security Review — SCORPIOX CODE

---

1. Executive Summary

This report presents the findings of a comprehensive, multi-agent security audit of SCORPIOX CODE, an AI-powered development tool and CLI platform written in pure C. The audit encompassed 14 specialist assessments covering supply chain integrity, build provenance, network security, TLS configuration, credential management, file I/O safety, buffer and memory safety, command injection vectors, privilege and access control, Windows deployment, telemetry practices, install script security, and the WPF desktop launcher.

Key Metrics

Summary of Findings

The codebase demonstrates a mature security posture for a pure-C project of this scale. Highlights include:

• Zero external runtime dependencies — all third-party code is vendored (Mbed TLS 3.6.6 LTS, yyjson 0.12.0), both at current versions
• Exceptional buffer safety — safe-to-unsafe function ratio of 2,849:1; zero strcpy/strcat/gets/scanf in project code
• Complete malloc NULL-check coverage — all 298 malloc() and 99 calloc() sites verified
• Safe realloc pattern — all 111 realloc() sites use temporary-variable idiom
• No hardcoded credentials — all API key and secret fields are empty strings with runtime population
• No telemetry by default — all tracking features are opt-in and disabled in default configuration
• Strong file I/O discipline — centralized sx_fopen() wrapper with FD_CLOEXEC, consistent mkstemp() usage
• SHA256 verification on all distribution downloads with fail-closed behavior

The two critical findings relate to: (1) a hardcoded public IP address for a TCP relay server, and (2) a --privileged container mode that bypasses namespace isolation with insufficient access controls. Both are in Linux-only code paths and do not affect the Windows deployment scope.

For Windows workstation deployment, the effective risk is LOW — the 2 critical and 4 of 6 high-severity findings are in Linux-only binaries (scorpiox-unshare, scorpiox-traffic) that do not compile or ship on Windows.

---

2. Deployment Scope

2.1 Windows Workstation (Primary Deployment Target)

The following binaries compile and ship on Windows:

2.2 Linux-Only Binaries (Not Deployed on Windows)

2.3 Windows-Filtered Findings

Windows-specific risk rating: LOW

---

3. Changes Since Last Audit

The previous audit was conducted on 2026-04-30 against commit 60a9c05.

Key Changes:

• High findings reduced from 8 to 6 — 2 high-severity findings resolved between commits
• Medium increased by 1 — re-audit of command injection (agent 09) on updated commit 6851bc0 identified refined findings; WPF launcher audit (agent 14) added 3 medium findings
• Informational increased by 15 — additional positive findings documented across agents, WPF launcher audit added 4 info findings
• Overall risk rating remains LOW-MEDIUM — no new critical issues; codebase trending positively on high-severity remediation

---

4. Supply Chain & Dependencies

Agent: supply-chain | Risk: LOW | Findings: 0C / 0H / 0M / 3L / 5I

The project maintains a minimal supply chain footprint:

• Vendored Libraries (2):

- Mbed TLS 3.6.6 — Latest LTS release (2026-03-31), all 11 security advisories addressed. Apache-2.0/GPL-2.0+ dual license. 208,584 lines.

- yyjson 0.12.0 — Current release (2025-10-25), no known CVEs. MIT license. 19,556 lines.

• Build Dependencies: CMake with find_package() for system libraries (libcurl, OpenSSL, Threads, X11, Python3). No FetchContent or dynamic download at build time.

• npm Dependencies (optional bridge only): @whiskeysockets/baileys ^7.0.0-rc.9 + qrcode-terminal ^0.12.0 — only used by the optional WhatsApp bridge component, lockfile present.

• No pre-built binaries shipped in the repository
• No git submodules
• No C/C++ package managers (vcpkg, conan, etc.)

---

5. Build System & Code Provenance

Agent: build-provenance | Risk: LOW | Findings: 0C / 0H / 0M / 3L / 5I

Build Security Hardening

• Static linking is the production default (SX_STATIC_LINK=ON), all dependencies resolved as .a archives
• Reproducible build environment via pinned Docker images (Alpine 3.21 by SHA256 digest)
• ARM64 cross-build downloads curl 8.5.0 with SHA256 verification
• Single author domain across all 623 commits — clean provenance chain
• Windows PE version resources generated from CMake template (version.rc.in)
• No binary blobs or pre-compiled objects in repository

Notable Gaps

• PIE/ASLR not enabled for static Linux builds (acceptable for CLI tools)
• bridge/Makefile lacks linker hardening flags (standalone utility)

---

6. Network Endpoints

Agent: network-endpoints | Risk: MEDIUM | Findings: 1C / 3H / 18M / 16L / 55I

The codebase contains 79 unique hardcoded network endpoints across 38 source files:

Critical / High Findings

External API Endpoints (Medium)

6 external AI provider API endpoints are hardcoded as defaults but are configurable:

• api.anthropic.com (Anthropic Claude)
• generativelanguage.googleapis.com (Google Gemini)
• api.openai.com (OpenAI)
• api.z.ai (Z.AI proxy)
• chatgpt.com/backend-api/codex (Codex)
• api.elevenlabs.io (ElevenLabs voice)

All external endpoints use HTTPS. Internal infrastructure endpoints use first-party domains with HTTPS.

Localhost Services

Multiple localhost-bound services (scorpiox-host, scorpiox-pwsh, scorpiox-sdk, fetchtoken services) bind to 127.0.0.1 only, using INADDR_LOOPBACK — correct isolation for local API servers.

---

7. TLS/SSL Security

Agent: tls-security | Risk: MEDIUM | Findings: 0C / 1H / 3M / 3L / 0I

Positive Architecture

• Centralized TLS configuration via sx_tls.h helper — all curl callsites use consistent settings
• TLS 1.2 minimum enforced (CURL_SSLVERSION_TLSv1_2)
• Certificate verification enabled by default
• Mbed TLS 3.6.6 vendored for non-curl TLS (WSL downloads, direct TCP)

Findings

---

8. Hardcoded Credentials

Agent: credential-hardcode | Risk: LOW | Findings: 0C / 0H / 0M / 2L / 4I No actual secrets are hardcoded. All API key and token fields are defined as empty strings with runtime population via environment variables, configuration files, or remote token fetching.

---

9. File I/O & Data Handling

Agent: file-io | Risk: LOW | Findings: 0C / 0H / 3M / 7L / 12I

Strengths

• Centralized sx_fopen() wrapper enforces FD_CLOEXEC (308 call sites)
• Consistent mkstemp() usage (22 call sites) — no insecure temp file functions
• Sensitive data redaction in logs and config snapshots
• O_CLOEXEC on all security-sensitive open() calls (KVM devices, TUN interfaces, namespace files)

Key Findings

---

10. Buffer Safety

Agent: buffer-safety | Risk: LOW | Findings: 0C / 0H / 1M / 2L / 4I

Exceptional Results

Findings

---

11. Memory Safety

Agent: memory-safety | Risk: LOW | Findings: 0C / 0H / 0M / 2L / 5I

Complete Coverage

• Zero use-after-free or double-free vulnerabilities found
• Zero unsafe ptr = realloc(ptr, ...) patterns
• Custom sx_strdup() wrapper aborts on OOM — eliminates NULL-deref class

Findings

---

12. Command Injection

Agent: command-injection | Risk: LOW | Findings: 0C / 0H / 3M / 2L / 1I

The codebase shows a mature, security-conscious approach to command execution:

• Unix paths consistently use fork()+execvp() with argv arrays
• is_safe_shell_arg() validation gates user inputs before shell interpolation
• Deliberate design decisions are documented in comments

Findings

---

13. Privilege & Access Control

Agent: privilege-access | Risk: MEDIUM | Findings: 1C / 2H / 4M / 4L / 5I

Critical / High Findings

Medium Findings

Windows Impact: Only 2 of 16 privilege findings (M-01, M-04) apply to Windows deployments. The critical and both high findings are Linux container runtime code that does not compile on Windows.

---

14. Windows Deployment Analysis

Agent: windows-deployment | Risk: LOW | Findings: 0C / 0H / 0M / 0L / 7I

This agent performed a comprehensive analysis of all 51 binaries that compile on Windows (2 Windows-only + 49 cross-platform). Key findings:

• All Windows binaries use MinGW static linking — no DLL dependencies beyond Windows system libraries
• WinINet used for HTTP/HTTPS in scorpiox-wsl.exe — leverages system certificate store
• SHA256 verification for all download operations (container images, self-updates)
• User-space installation — no admin privileges required ($env:LOCALAPPDATA\scorpiox)
• Windows PE version resources properly embedded via version.rc.in
• No Windows services or scheduled tasks installed
• system() calls on Windows paths (noted in command injection findings)

All 7 findings are informational, documenting architecture and confirming secure defaults.

---

15. Telemetry and Tracking

Agent: telemetry-tracking | Risk: LOW | Findings: 0C / 0H / 0M / 2L / 6I

Key Conclusion: No Tracking By Default

When Enabled (Opt-In)

• Usage tracking sends metadata (token counts, model, hostname, username) to code.scorpiox.net/usage-send — no conversation content
• Session telemetry sends full conversation data to code.scorpiox.net/sessions-send — significant privacy exposure if enabled
• Both use fire-and-forget async HTTP POST with no retry or queue

Findings

---

16. Install Script & Distribution Security

Agent: install-script | Risk: LOW-MEDIUM | Findings: 0C / 0H / 3M / 6L / 11I

Distribution Architecture

Security Strengths

• HTTPS enforced on all distribution domains with HSTS
• SHA256 checksums generated during build, verified during install (fail-closed)
• HTTP→HTTPS redirect via Caddy (308/301)
• TLS 1.2 minimum on Windows installer
• No auto-update daemon or scheduled tasks
• set -e in all bash install scripts

Key Findings

---

17. Consolidated Risk Matrix

---

18. Conclusion & Recommendations

Overall Assessment

SCORPIOX CODE demonstrates a mature security posture for a pure-C project of significant scale (147,742 lines of project code). The codebase exhibits disciplined engineering practices:

Memory safety is exemplary — 100% NULL-check coverage on allocations, safe realloc patterns, no unsafe string functions, OOM-safe wrappers

Supply chain is minimal and current — only 2 vendored libraries, both at latest versions, no dynamic dependency fetching

No telemetry by default — all tracking is opt-in with clear configuration keys

Strong build hardening — stack protectors, FORTIFY_SOURCE, RELRO, non-executable stack

File I/O discipline — centralized CLOEXEC wrapper, consistent mkstemp usage, sensitive data redaction

Priority Recommendations

Immediate (Critical/High — Windows-relevant):

Replace hardcoded IP 20.53.240.54 with DNS hostname for TCP relay — reduces infrastructure coupling and enables rotation

Restrict TLS verification kill-switch — remove ability to globally disable SX_TLS_VERIFY, or limit to debug builds with compile-time guard

Add TLS option for localhost API services — provide optional encryption for scorpiox-host, scorpiox-pwsh, scorpiox-sdk local servers

Short-Term (Medium — Windows-relevant):

Implement Authenticode code signing for Windows binaries — critical for enterprise deployment trust

Sanitize command arguments in slash command execution and Windows system() calls — use CreateProcess with argument arrays on Windows

Encrypt session data at rest or document data-at-rest policy for ~/.scorpiox/sessions/

Add agent recursion depth limits to prevent fork-bomb scenarios

Long-Term (Hardening):

Publish SHA256 checksums via independent channel (transparency log, signed manifest)

Implement reproducible builds for verification

Hash/anonymize PII fields in opt-in telemetry

Add non-root user creation in WSL container setup

Risk Acceptance

For Windows workstation deployment, the effective risk profile is LOW:

• Both critical findings are Linux-only (container runtime)
• 4 of 6 high findings are Linux-only (seccomp, capabilities, traffic proxy)
• Windows-filtered findings: 0 Critical, 2 High, 25 Medium, 40 Low
• The 2 Windows-relevant high findings (TLS kill-switch, plaintext localhost HTTP) require deliberate misconfiguration or are localhost-only

The software is suitable for controlled corporate deployment on Windows workstations with the following conditions:

Ensure SX_TLS_VERIFY is not set to 0 in deployment configuration

Do not enable USAGE_TRACKING or EMIT_SESSION_TRACKING unless data handling is documented

Monitor for future Authenticode signing implementation before broad rollout

---

19. Appendix: Audit Methodology

Agents Deployed

Analysis Methods

• Static analysis — Pattern matching across all source files for known-unsafe functions, hardcoded values, and security anti-patterns
• Control flow analysis — Manual review of flagged items to eliminate false positives from branching, conditional compilation, and loop structures
• Configuration audit — Review of all default configuration values, embedded configs, and environment variable handling
• Dependency audit — Version verification of vendored libraries against upstream releases and CVE databases
• Build system review — Compiler/linker flag verification, Docker image pinning, build reproducibility assessment

Severity Classification

---

Report generated by automated security audit pipeline — 14 specialist agents Classification: CONFIDENTIAL — For Corporate Review Only