Third-Party Software Security Review — SCORPIOX CODE

---

1. Executive Summary

This report presents a comprehensive security audit of SCORPIOX CODE, an AI-powered development CLI platform written in pure C. The audit was conducted by 13 specialized automated agents covering supply chain, build provenance, network endpoints, TLS security, credentials, file I/O, buffer safety, memory safety, command injection, privilege/access control, Windows deployment, telemetry, and install script security.

Key Metrics

Overall Risk Rating: MEDIUM

The software demonstrates strong engineering practices across most security domains — particularly in buffer safety (258:1 safe-to-unsafe ratio), supply chain hygiene (zero outdated dependencies, no pre-built binaries), and build hardening (stack protector, FORTIFY_SOURCE, full RELRO, NX, CFI). The primary risk areas are:

Memory Safety (MEDIUM) — 2 critical use-after-free patterns in streaming parsers, 14 high-severity unchecked allocations in network code, and ~80 missing NULL checks

Install Script Integrity (MEDIUM) — SHA256 checksums are published but not verified during installation

TLS Configuration (MEDIUM) — Global TLS verification can be disabled via config; silent downgrade on CA bundle failure

For Windows workstation deployment (the primary corporate use case), the risk is LOW-MEDIUM — most critical findings involve Linux-only code paths (container runtime, MITM proxy, VM manager) that do not compile or ship on Windows.

---

2. Deployment Scope — Windows Workstation

2.1 Windows Binaries (Ship on Windows)

The following binaries compile and deploy on Windows workstations:

Additional Windows binaries: sx.dll, scorpiox-sdk.exe, scorpiox-gemini.exe, scorpiox-openai.exe, scorpiox-server.exe, scorpiox-dns.exe, scorpiox-frp.exe, scorpiox-tmux.exe, scorpiox-multiplexer.exe, scorpiox-voice.exe, scorpiox-agent.exe, scorpiox-tasks.exe, scorpiox-mcp.exe, plus 20+ additional utilities (token fetchers, logging, search, email).

Total Windows binaries: 54

2.2 Linux-Only Binaries (NOT deployed on Windows)

2.3 Windows-Filtered Findings

When filtering findings to Windows-deployed binaries only:

The reduction is significant because the highest-risk components (container runtime, VM manager, MITM proxy, sshpass) are Linux-only.

---

3. Changes Since Last Audit

Previous audit: 2026-04-28 (commit f7f14b4) Analysis: The increase in findings is primarily due to expanded audit scope (13 agents vs. 5), not degraded security. The previous audit used 5 generalized agents; the current audit uses 13 specialized agents with deeper per-domain analysis. Critical findings decreased from 5 to 2, indicating real security improvements. The 80 medium-severity "missing NULL check" findings from the memory-safety agent account for the bulk of the increase — these existed in the prior codebase but were not enumerated. Notable improvements since last audit:

• Bulk migration from system() → fork()+execvp() (14 files) — major command injection reduction
• Commit 089698f specifically targeted shell injection elimination
• Critical findings reduced 60% (5 → 2)

---

4. Supply Chain & Dependencies

Risk: LOW Key findings:

• Zero outdated dependencies
• No remote code execution during build
• Optional npm bridge component (@whiskeysockets/baileys) carries 103 transitive dependencies but is not part of the core C product
• Windows GNU tools download script (download.ps1) does not verify checksums of downloaded packages

---

5. Build System & Code Provenance

Risk: LOW

Security Hardening Flags

Build-Time Code Generation

• Model constants generator is FROZEN by default — requires explicit --fetch to contact network
• Git commit hash embedded at build time (standard practice)
• No code signing of release artifacts (see Section 16)

Missing (recommended):

• -fstack-clash-protection (GCC ≥8)
• -fPIE/-pie (mitigated by static linking)

---

6. Network Endpoints

Risk: LOW

The codebase contains 146 URL references in project code. All production endpoints use HTTPS.

Endpoint Categories

No unauthorized exfiltration endpoints detected. No suspicious domains.

---

7. TLS/SSL Security

Risk: MEDIUM Positive findings:

• Centralized TLS helper (sx_tls.h) enforces verification by default
• TLS 1.2 minimum enforced for mbedTLS paths
• Strong cipher suites configured (ECDHE, AES-GCM, ChaCha20)
• libcurl defaults to system CA bundle

---

8. Hardcoded Credentials

Risk: LOW No actual secret values (API keys, passwords, tokens) are hardcoded. All credential fields use empty placeholder strings populated at runtime.

---

9. File I/O & Data Handling

Risk: LOW-MEDIUM Positive findings:

• Consistent mkstemp() usage for temp files
• Atomic write pattern (write-to-tmp + rename())
• API key redaction in traffic logs
• Path-traversal validation in security-sensitive paths

---

10. Buffer Safety

Risk: LOW

The project demonstrates exemplary buffer safety discipline:

Findings:

• 1 sprintf usage proven safe (fixed-length hex encoding)
• 11 strcat calls in Windows-only code paths — bounded by companion strncat but theoretically overflowable with extreme argument counts
• All large stack buffers (up to 64KB) have proper bounds checking
• No format string vulnerabilities in project code

---

11. Memory Safety

Risk: MEDIUM

This is the highest-risk domain identified.

Critical Findings

CRIT-01: Use-After-Free in OpenAI WASM SSE Parser

• File: sx_provider_openai_wasm.c:412-415
• Latent UAF — dead code path that dereferences freed buffers. Currently unreachable but becomes exploitable if allocation logic is refactored.

CRIT-02: vtable→free followed by data access in Provider Cleanup

• File: sx_provider.c:199-207
• Polymorphic vtable->free(p) may free p->data, which is then accessed. Relies on implicit undocumented convention.

High Findings (Network Code)

• 14 missing NULL checks on malloc in libsxnet/ (HTTP handlers, streaming parsers)
• Could cause crashes under memory pressure during active network connections

Positive findings:

• Realloc patterns consistently use temp variables (no realloc-in-place)
• 91 calloc usages (zero-initialized memory)
• Large buffers use calloc for clarity

---

12. Command Injection

Risk: LOW

The codebase underwent a significant bulk migration (commit 089698f) converting most system() calls to fork()+execvp(), eliminating shell interpretation. Remaining findings:

Post-migration metrics:

• system() calls remaining: 8 (6 Windows-only, 2 Linux)
• popen() calls remaining: 14 (most with controlled inputs)
• fork()+execvp() calls: 45+ (safe argument vector pattern)

---

13. Privilege & Access Control

Risk: MEDIUM Windows impact: Minimal. The high-severity container runtime finding is Linux-only. Windows binaries do not require elevated privileges for normal operation. scorpiox-wsl.exe uses standard Windows APIs (WinInet, CreateProcess).

---

14. Windows Deployment Analysis

Risk: LOW

Windows-Specific Security Findings

Windows Security Architecture

• No Windows services installed — all binaries are user-space CLI tools
• No registry modifications — configuration stored in flat files
• No kernel drivers — pure user-mode operation
• Static linking — no DLL side-loading risk
• No admin rights required — installs to user-writable paths

---

15. Telemetry and Tracking

Risk: LOW Verdict: No tracking by default. Key findings:

• Both telemetry features disabled by default (0) in all config sources
• No phone-home, no heartbeat, no background network activity when disabled
• When enabled, usage tracking collects machine hostname + OS username (PII)
• Session tracking (when enabled) transmits full conversation content — significant data sensitivity
• No unsubscribe/delete mechanism documented

For corporate deployment: Ensure USAGE_TRACKING=0 and EMIT_SESSION_TRACKING=0 remain in deployed configuration.

---

16. Install Script & Distribution Security

Risk: MEDIUM Positive findings:

• HTTPS enforced on both distribution domains (Caddy 308 redirect)
• scorpiox-wsl.exe self-update does verify SHA256 + fails closed ✅
• No auto-update without user consent
• No cron/launchd/systemd persistence

---

17. Consolidated Risk Matrix

---

18. Conclusion & Recommendations

Overall Assessment

SCORPIOX CODE demonstrates a mature security posture for a C-based project of this scale. The codebase shows clear evidence of ongoing security investment:

• Excellent buffer safety (258:1 safe-to-unsafe ratio, zero strcpy/gets)
• Strong build hardening (stack protector, FORTIFY_SOURCE, full RELRO, CFI)
• Clean supply chain (2 current vendored libraries, no pre-built binaries)
• No tracking by default — opt-in telemetry only
• Recent security migration — bulk system() → fork()+execvp() conversion

Priority Recommendations

Immediate (Critical/High):

Fix use-after-free patterns in sx_provider_openai_wasm.c and sx_provider.c

Add SHA256 verification to install scripts (infrastructure exists, just not wired up)

Implement code signing for release artifacts

Add NULL checks to 14 network-code allocations in libsxnet/

Fix temp file leak in emit_session_external()

Short-term (Medium):

Remove or restrict global TLS verification disable

Externalize infrastructure IPs from compiled embedded config

Migrate remaining 2 Linux popen() calls to fork()+execvp()

Add HSTS headers to distribution domains

Migrate Windows sx_system_safe() to CreateProcess

Long-term (Low):

Systematic NULL-check audit across all 80 sites

Error-path memory leak cleanup (30 sites)

Document privacy policy for opt-in telemetry data

Add seccomp profile to container runtime

Windows Deployment Clearance

For Windows workstation deployment, the software presents LOW-MEDIUM risk:

• No admin rights required
• No Windows services or registry modifications
• No DLL dependencies (static linking)
• No kernel drivers
• No tracking by default
• Most high-severity findings are Linux-only code paths
• Primary concern: unsigned binaries (SmartScreen warnings) and missing install-time checksum verification

Recommendation: Approve for Windows workstation deployment with the following conditions:

Ensure telemetry remains disabled in corporate config

Monitor for code signing implementation in future releases

Deploy via managed software distribution (bypasses install script concerns)

---

19. Appendix: Audit Methodology

Agents Deployed

Scope & Limitations

• In scope: All non-vendor C source code (152,747 LOC), build configuration, install scripts, embedded configuration
• Out of scope: Vendor library internals (mbedTLS, yyjson) except for configuration; runtime behavior testing; penetration testing
• Methodology: Automated static analysis with manual finding verification
• False positive rate: Findings verified against code context; theoretical/latent issues marked as such
• Commit analyzed: 3ad7dfcfe0c414abda526ac5c747e0e88cd592f5 (main branch, 2026-04-29)

---

End of Report