Architecture Security Audit Report

Project: ScorpioX (clang codebase) Audit Date: 2026-04-28 Commit Hash: f7f14b49ca77bfb07d31a819de0791445d3c02a5 Auditor: Security Audit Agent Total Lines of Code: 369,495 (143,599 first-party + 225,896 vendored)

---

Executive Summary

The ScorpioX codebase is a pure C project (~370K LOC) built with CMake and targeting multiple platforms (Linux, macOS, Windows, WASM). The project follows a vendored dependency model — the only third-party libraries (mbedtls and yyjson) are committed directly into the source tree under scorpiox/vendor/. There are no package manager fetches, no FetchContent/ExternalProject downloads, and no git submodules. The build system relies exclusively on the system compiler (gcc/clang) and system-provided libcurl. Code provenance analysis shows all 996 commits originate from ScorpioX organization email addresses. Two pre-built ELF binaries were found in the bridge/ directory, which is a medium-risk finding. A bridge/package.json with Node.js dependencies exists for a WhatsApp bridge component, which is an informational finding (not part of the C build).

Overall Risk Assessment: LOW — The architecture demonstrates strong supply chain hygiene with minimal attack surface.

---

1. Dependency Analysis

1.1 Package Manager Files

Finding: The only package.json is in bridge/ for a standalone WhatsApp bridge component (@whiskeysockets/baileys, qrcode-terminal). This is a separate Node.js/TypeScript tool, not part of the C compilation pipeline. Risk: LOW — The Node.js dependency file is isolated from the main C build and does not affect the compiled binaries.

1.2 CMake External Downloads

The project uses CMake but contains zero instances of:

• FetchContent — Not used
• ExternalProject — Not used
• file(DOWNLOAD ...) — Not used
• URL-based downloads — Not used

The only find_package() calls reference system-installed libraries:

• find_package(Python3) — Build-time code generation only
• find_package(CURL) — System libcurl (statically linked on Linux)
• find_package(Threads) — System pthreads
• find_package(X11) — Optional, for screenshot feature

Risk: LOW — No build-time downloads; all dependencies are either vendored source or pre-installed system libraries.

1.3 Vendored Third-Party Libraries

Both libraries are:

• ✅ Committed as source code (not pre-compiled)
• ✅ Built as STATIC libraries (add_library(... STATIC ...))
• ✅ Include their original LICENSE files
• ✅ Well-known, widely-audited open-source libraries

Risk: LOW — Vendored source is the gold standard for supply chain security. Both are reputable, actively maintained libraries.

---

2. Build Process Security

2.1 Build System Overview

• Build Tool: CMake 3.16+ with system compiler
• Language Standard: C11 (CMAKE_C_STANDARD 11)
• Default Build Type: Release with -O2 -DNDEBUG
• Static Linking: Enabled by default (SX_STATIC_LINK ON)
• Compiler: System gcc or clang — no downloaded/pinned toolchain

2.2 Build Script Analysis

Finding: release_whatsapp.ps1 line 82 executes curl -fsSL https://bun.sh/install | bash — a classic pipe-to-shell installation pattern. However, this is for the standalone WhatsApp bridge (TypeScript), not the core C binaries. Risk: MEDIUM — The curl | bash pattern in release_whatsapp.ps1 is a supply chain risk for the WhatsApp bridge component. Not applicable to the core C build pipeline.

2.3 Code Generation

A Python script (tests/code_generator_models.py) generates sx_models_generated.h at build time. The CMake comment notes this is "FROZEN at opus-4-6" and does not fetch from the network by default. This is a compile-time code generation step, not a dependency download.

Risk: LOW — Frozen code generation with no network fetch.

2.4 Security Compiler Flags

Current flags: -Wall -Wextra -O2

Risk: LOW-MEDIUM — Basic warnings are enabled but hardening flags (-fstack-protector-strong, -D_FORTIFY_SOURCE=2) are absent. Recommended for future improvement.

---

3. Binary Output Analysis

3.1 Build Outputs

The build produces multiple executables (not a single binary), all linked against internal static libraries:

Internal Static Libraries (8):

• sxutil — Utility/config library
• sxnet — Network library
• sxhttp — HTTP library
• sxui — UI library
• sxterm — Terminal library
• sxbridge — Bridge library
• yyjson — JSON parser (vendored)
• mbedtls_lib — TLS library (vendored)

Executables (~50+): scorpiox-bash, scorpiox-agent, scorpiox-config, scorpiox-server, scorpiox-email, scorpiox-gemini, scorpiox-openai, scorpiox-sdk, scorpiox-voice, scorpiox-mcp, scorpiox-beam, scorpiox-frp, scorpiox-host, etc.

3.2 External Runtime Dependencies

On Linux (static build): Only libc (musl via Alpine static build achieves zero dynamic dependencies).

On the dynamically-linked bridge/scorpiox-ws2tcp binary:

linux-vdso.so.1
libc.so.6
/lib64/ld-linux-x86-64.so.2

System libcurl is statically linked into the binaries on Linux. On macOS, it links dynamically against system frameworks.

Risk: LOW — Static linking eliminates shared library hijacking risks. Only libc is a runtime dependency.

3.3 Shared Library Build

A sx_shared (SHARED) library target exists (sx_dll.c), but this appears to be a Windows DLL export wrapper, conditionally compiled. The primary build mode is fully static.

Risk: LOW

---

4. Code Provenance

4.1 Commit Author Analysis

Total Commits: 996 Finding: All commits come from ScorpioX organization domains:

• scorpiox.net — Primary development (99.4% of commits)
• scorpioplayer.com — Partner/bot contributions (0.5%)
• sx@sx — Likely a local dev alias (single commit)

No external contributors. No commits from unknown or public email providers (gmail, outlook, etc.). Risk: LOW — Tight commit provenance with single-organization authorship.

---

5. Pre-Built Binaries Check

5.1 Binary Files in Repository

No .so, .dll, .dylib, .a, .lib, .o, or .exe files were found elsewhere in the repository.

Finding: Two pre-built ELF binaries exist in bridge/. The source (bridge/ws2tcp.c — 1,234 LOC) and Makefile are present alongside them, suggesting they are convenience builds. However, there is no way to verify the checked-in binaries were built from the checked-in source without rebuilding. Risk: MEDIUM — Pre-built binaries in a source repository are a supply chain risk. An attacker who compromises the repo could replace these with backdoored versions. Recommendation: Remove pre-built binaries from the repo; build them in CI instead, or provide reproducible build verification.

5.2 Other Binary/Encoded Content

No .wasm files, no embedded base64 payloads (outside of mbedtls's standard PEM/base64 crypto module), and no obfuscated code detected.

Risk: LOW

---

6. Third-Party Code Check

6.1 License Files

6.2 Vendored Code Integrity

• mbedtls: 108 C source files, 159 header files — full library source with custom config (sx_mbedtls_config.h)
• yyjson: 2 files (single .c + .h amalgamation) — standard distribution format

6.3 Other Third-Party Indicators

• scorpiox/vendor/gnuwin64/ — Contains only a README.md and download.ps1 script for fetching GNU coreutils on Windows. No pre-downloaded binaries.
• No COPYING, NOTICE, or THIRD_PARTY files outside of vendor directory.
• grep for non-ScorpioX copyright headers in .c/.h files returned zero results outside of vendor.

Risk: LOW — All third-party code is properly isolated in vendor/, licensed, and compiled from source.

---

7. Risk Assessment Summary

---

8. Recommendations

Remove pre-built binaries from bridge/ — build scorpiox-ws2tcp and scorpiox-ws2tcp-arm64 in CI or add a make step to the release process.

Add compiler hardening flags: -fstack-protector-strong -D_FORTIFY_SOURCE=2 to CMAKE_C_FLAGS.

Replace curl | bash in release_whatsapp.ps1 with a pinned, hash-verified download of the Bun runtime.

Consider adding a THIRD_PARTY.md file documenting vendored library versions and their upstream commit hashes for audit traceability.

Pin vendored library versions explicitly (e.g., record mbedtls version/commit SHA in a VERSIONS file).

---

Appendix A: File Counts

Appendix B: Build Targets

The build produces approximately 50+ individual executables, all statically linked against internal libraries (sxutil, sxnet, sxhttp, sxui, sxterm, sxbridge) and vendored libraries (mbedtls, yyjson). The architecture is a multi-binary CLI toolkit rather than a single monolithic binary.