# 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

| Package Manager File | Found? | Location | Notes |
|---|---|---|---|
| `package.json` | **YES** | `bridge/package.json` | WhatsApp bridge (TypeScript/Bun), **not** part of the C build |
| `requirements.txt` | No | — | — |
| `Cargo.toml` | No | — | — |
| `go.mod` / `go.sum` | No | — | — |
| `vcpkg.json` | No | — | — |
| `conanfile.txt` / `.py` | No | — | — |
| `Pipfile` | No | — | — |
| `Gemfile` | No | — | — |
| `pom.xml` | No | — | — |
| `build.gradle` | No | — | — |
| `.gitmodules` | No | — | — |

**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

| Library | Version | License | Location | LOC |
|---|---|---|---|---|
| **mbedtls** | (source) | Apache-2.0 OR GPL-2.0+ | `scorpiox/vendor/mbedtls/` | ~225K (108 .c, 159 .h files) |
| **yyjson** | (source) | MIT | `scorpiox/vendor/yyjson/` | ~743K bytes (2 files: yyjson.c + yyjson.h) |

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

| Script | Purpose | Downloads Anything? |
|---|---|---|
| `CMakeLists.txt` (root) | Main build config | No |
| `scorpiox/CMakeLists.txt` | Library + executable definitions | No |
| `release_macos_native.sh` | macOS release build | No (requires pre-installed Xcode + cmake) |
| `release.ps1` | Linux container build | No (uses pre-installed Alpine packages) |
| `Dockerfile.build-musl` | Alpine musl static build env | `apk add` only (system packages) |
| `Dockerfile.linux-arm64` | ARM64 cross-build env | System packages only |
| `release_whatsapp.ps1` | WhatsApp bridge build | **YES** — downloads Bun runtime via `curl | bash` |

**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`

| Flag | Present? | Notes |
|---|---|---|
| `-Wall -Wextra` | ✅ | Standard warnings enabled |
| `-Wformat=2` | ✅ (mbedtls) | Format string protection (vendor only) |
| `-static` | ✅ (Linux) | Full static linking on Linux |
| `-fstack-protector-strong` | ❌ | Not enabled — **recommended** |
| `-D_FORTIFY_SOURCE=2` | ❌ | Not enabled — **recommended** |
| `-fPIE` / `-pie` | ❌ | Not explicitly set (may be compiler default) |
| `-Wl,-z,relro,-z,now` | ❌ | Not set (N/A for static builds) |

**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

| Author | Email | Commits | Percentage |
|---|---|---|---|
| ScorpioX | `dev@scorpiox.net` | 623 | 62.6% |
| scorpiox | `scorpiox@scorpiox.net` | 366 | 36.7% |
| scorpioxinc | `partner@scorpioplayer.com` | 3 | 0.3% |
| Pico | `picobot@scorpioplayer.com` | 2 | 0.2% |
| sx | `sx@sx` | 1 | 0.1% |
| Pico | `pico@scorpiox.net` | 1 | 0.1% |

**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

| File | Type | Size | Concern |
|---|---|---|---|
| `bridge/scorpiox-ws2tcp` | ELF 64-bit x86-64, dynamically linked | 39,720 bytes | **MEDIUM** |
| `bridge/scorpiox-ws2tcp-arm64` | ELF 64-bit ARM aarch64, dynamically linked | 74,024 bytes | **MEDIUM** |

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

| File | Library | License |
|---|---|---|
| `scorpiox/vendor/mbedtls/LICENSE` | Mbed TLS | Apache-2.0 OR GPL-2.0+ |
| `scorpiox/vendor/yyjson/LICENSE` | yyjson | MIT |

### 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

| Finding | Risk Level | Description |
|---|---|---|
| Zero package manager dependencies in C build | **LOW** ✅ | No npm/pip/cargo/go dependencies for core build |
| Vendored mbedtls + yyjson (source) | **LOW** ✅ | Well-known libraries, committed as source with licenses |
| No FetchContent / ExternalProject / submodules | **LOW** ✅ | Build does not download anything at compile time |
| Static linking by default | **LOW** ✅ | Eliminates shared library hijacking |
| Single-org commit provenance (996 commits) | **LOW** ✅ | All commits from scorpiox.net / scorpioplayer.com |
| System libcurl (find_package) | **LOW** ✅ | Standard system library, statically linked on Linux |
| Pre-built ELF binaries in `bridge/` | **MEDIUM** ⚠️ | 2 pre-compiled binaries checked into repo |
| `curl \| bash` in WhatsApp release script | **MEDIUM** ⚠️ | Supply chain risk for WhatsApp bridge (not core C build) |
| `bridge/package.json` (Node.js deps) | **INFO** ℹ️ | Isolated WhatsApp bridge, not part of C build |
| Missing compiler hardening flags | **LOW-MEDIUM** ⚠️ | No `-fstack-protector-strong`, `-D_FORTIFY_SOURCE=2` |

---

## 8. Recommendations

1. **Remove pre-built binaries** from `bridge/` — build `scorpiox-ws2tcp` and `scorpiox-ws2tcp-arm64` in CI or add a `make` step to the release process.
2. **Add compiler hardening flags:** `-fstack-protector-strong -D_FORTIFY_SOURCE=2` to `CMAKE_C_FLAGS`.
3. **Replace `curl | bash`** in `release_whatsapp.ps1` with a pinned, hash-verified download of the Bun runtime.
4. **Consider adding a `THIRD_PARTY.md`** file documenting vendored library versions and their upstream commit hashes for audit traceability.
5. **Pin vendored library versions** explicitly (e.g., record mbedtls version/commit SHA in a `VERSIONS` file).

---

## Appendix A: File Counts

| Category | C Files | H Files | Total LOC |
|---|---|---|---|
| First-party (scorpiox/) | — | — | 143,599 |
| Vendor: mbedtls | 108 | 159 | ~225K |
| Vendor: yyjson | 1 | 1 | ~743KB |
| Bridge (ws2tcp.c) | 1 | 0 | 1,234 |
| **Total** | — | — | **369,495** |

## 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.