# Architecture & Supply Chain Security Audit Report

**Project:** ScorpioX CLI (clang codebase)  
**Audit Date:** 2026-04-28  
**Commit:** `b85fca9891f8ff39fce93868947ce31fe9fed50e`  
**Auditor:** Security Audit Agent  
**Total Lines of Code:** 369,205 (C + H files)  

---

## Executive Summary

The ScorpioX CLI codebase is a C11 project comprising 259 `.c` files and 234 `.h` files across 369,205 lines of code. The project follows a **vendored-dependency model** — all third-party libraries are committed directly into the source tree under `scorpiox/vendor/`, and the build system uses only system-provided compilers (gcc/clang) via CMake. There are **no runtime package manager dependencies** for the core C build. The project produces **multiple static executables** (not a single binary), with approximately 40+ distinct tool binaries.

**Overall Risk Assessment: LOW** — The architecture demonstrates strong supply chain security practices with vendored dependencies, deterministic builds, and minimal external surface area. A few medium-risk findings are noted below.

---

## 1. Dependency Analysis

### 1.1 Package Manager Files Scan

| File | Found | Location | Risk |
|------|-------|----------|------|
| `package.json` | **YES** | `bridge/package.json` | **Medium** |
| `requirements.txt` | No | — | — |
| `Cargo.toml` | No | — | — |
| `go.mod` / `go.sum` | No | — | — |
| `vcpkg.json` | No | — | — |
| `conanfile.txt` / `.py` | No | — | — |
| `setup.py` / `pyproject.toml` | No | — | — |
| `Gemfile` | No | — | — |
| `pom.xml` / `build.gradle` | No | — | — |
| `CMakeLists.txt` with `FetchContent` | No | — | — |

**Finding:** The core C codebase has **zero external package manager dependencies**. The only `package.json` exists in `bridge/`, a secondary Node.js/Bun-based WhatsApp bridge component that depends on `@whiskeysockets/baileys` (^7.0.0-rc.9) and `qrcode-terminal` (^0.12.0). This is a peripheral, non-core component with a `bun.lock` pinning exact versions.

### 1.2 Vendored Libraries

Two third-party libraries are vendored directly into the source tree:

| Library | Location | License | Lines | Purpose |
|---------|----------|---------|-------|---------|
| **yyjson** | `scorpiox/vendor/yyjson/` | MIT | ~15K | Fast JSON parser (pure C99, zero deps) |
| **mbedTLS** | `scorpiox/vendor/mbedtls/` | Apache-2.0 / GPL-2.0+ | ~210K | TLS/crypto (AES-128-CFB, PBKDF2, TLS 1.2) |

**Vendored code:** 225,896 lines (61% of total)  
**Project code:** 143,309 lines (39% of total)

Both libraries are well-known, audited open-source projects. They are compiled from source as static libraries during the build — no pre-built binaries of these libraries exist in the repository.

### 1.3 System Library Dependencies

The build links against the following system-provided libraries (not vendored, obtained from OS package manager or SDK):

| Library | Condition | Purpose |
|---------|-----------|---------|
| `libcurl` | Always (static `.a` preferred) | HTTP client |
| `openssl` / `libssl` + `libcrypto` | Linux static builds | TLS for curl |
| `zlib` | Linux static builds | Compression |
| `zstd` | Linux static builds | Compression |
| `nghttp2` / `nghttp3` | Linux static builds | HTTP/2, HTTP/3 |
| `brotli` | Linux static builds | Compression |
| `c-ares` | Linux static (musl) | Async DNS |
| `libidn2` / `libunistring` | Linux static (musl) | Internationalized DNS |
| `libpsl` | Linux static (musl) | Public suffix list |
| `ncurses` | TUI builds | Terminal UI |
| `libutil` | Linux (non-macOS) | `forkpty()` |
| `libX11` | Linux (optional) | Screenshot feature |
| `pthreads` | Linux | Threading |

For static Linux builds, all of these are linked statically from Alpine system packages (see `Dockerfile.build-musl`). On macOS, dynamic linking is used where full static linking is unsupported.

**Risk: LOW** — All system dependencies are standard OS libraries. The static linking approach on Linux produces standalone executables with no runtime library resolution.

---

## 2. Build Process Security

### 2.1 Build System Overview

- **Build tool:** CMake 3.16+ (standard, no custom build system)
- **Language:** C11 (`CMAKE_C_STANDARD 11`)
- **Compiler:** System gcc or clang (no downloaded toolchains)
- **Default mode:** Static linking (`SX_STATIC_LINK=ON`)
- **Cross-compilation:** ARM64 via `aarch64-linux-gnu-gcc` (system cross-compiler)

### 2.2 Build Flags

```
Release: -O2 -DNDEBUG -Wall -Wextra
Debug:   -g -O0 -DDEBUG -Wall -Wextra
GCC-only: -Wno-format-truncation -Wno-stringop-truncation
```

All warning flags are appropriate. The `-Wformat=2` flag is applied to vendored mbedTLS as well.

### 2.3 Network Activity During Build

The CMake build system does **not** download anything at build time. Specifically:

- **No `FetchContent` or `ExternalProject`** directives
- **No `wget`, `curl`, or `git clone`** in CMakeLists files
- The `find_package(CURL)` call locates the *already-installed* system curl library; it does not download it
- The `find_package(Python3)` call locates the system Python interpreter to run a code generator script (`tests/code_generator_models.py`)

**Code Generation Note:** The build invokes `tests/code_generator_models.py` to generate `sx_models_generated.h` containing AI model constants. The CMake comment explicitly states this is **"FROZEN at opus-4-6"** and does not fetch from network at build time — it reads from a local frozen configuration.

### 2.4 Build Containerization

The project provides `Dockerfile.build-musl` (Alpine-based) for reproducible Linux builds. All dependencies are installed via `apk add` from Alpine's official repository — this is the standard and expected approach for containerized builds.

### 2.5 Release Scripts

| Script | Platform | Security Notes |
|--------|----------|----------------|
| `release_macos_native.sh` | macOS ARM64 | Uses system Xcode clang; only requires `brew install cmake` |
| `release.ps1` | Cross-platform | Clones repo on remote macOS for build (git over SSH) |
| `release_windows.ps1` | Windows | Requires MinGW + curl; pre-installed via `winget` |
| `release_wasm.ps1` | WASM | **Downloads emscripten SDK from GitHub** — see Finding 2.5.1 |
| `release_whatsapp.ps1` | WhatsApp bridge | **Downloads Bun runtime** — see Finding 2.5.2 |

**Finding 2.5.1 (Medium):** `release_wasm.ps1` clones `https://github.com/emscripten-core/emsdk.git` at build time. This introduces a network dependency for WASM builds only. The WASM target is not the primary deployment artifact.

**Finding 2.5.2 (Medium):** `release_whatsapp.ps1` runs `curl -fsSL https://bun.sh/install | bash` to install the Bun runtime. This is a curl-pipe-bash pattern that introduces supply chain risk for the WhatsApp bridge component only.

**Risk: LOW for core builds, MEDIUM for WASM and WhatsApp bridge builds.**

---

## 3. Binary Output Analysis

### 3.1 Build Output

The project produces **approximately 45+ distinct executables**, not a single binary. Key executables include:

| Binary | Purpose | Dependencies |
|--------|---------|--------------|
| `scorpiox-bash` | Shell execution | sxutil |
| `scorpiox-agent` | AI agent mode | sxnet, sxui, sxutil, curl |
| `scorpiox-config` | Configuration | sxutil |
| `scorpiox-server` | HTTP server | sxutil, yyjson |
| `scorpiox-email` | Email (SMTP/IMAP) | sxnet, sxutil, curl, mbedtls |
| `scorpiox-frp` | Reverse proxy client | sxnet, sxutil, curl |
| `scorpiox-dns` | LAN DNS server | sxutil |
| `scorpiox-hook` | Event hooks | Zero deps (standalone) |
| `scorpiox-vault-git` | Git backup | Zero deps (standalone) |
| `scorpiox-sdk` | Headless CLI wrapper | sxutil |
| `sx_shared` (optional) | DLL for C# P/Invoke | sxutil (when `SX_BUILD_DLL=ON`) |

### 3.2 Internal Libraries (Static)

All internal libraries are built as **static libraries** and linked into executables:

| Library | Purpose |
|---------|---------|
| `sxutil` | Base utilities, config, logging, JSON, tools |
| `sxnet` | Network layer, TLS, HTTP, API clients |
| `sxui` | Terminal UI layer |
| `sxhttp` | HTTP helpers |
| `sxbridge` | WhatsApp bridge IPC |
| `sxterm` | Terminal/PTY management |
| `mbedtls_lib` | Vendored mbedTLS (static) |
| `yyjson` | Vendored JSON parser (static) |

### 3.3 Static Linking Verification

On Linux (the primary deployment target):
- `CMAKE_EXE_LINKER_FLAGS` includes `-static`
- `CMAKE_FIND_LIBRARY_SUFFIXES` is set to `.a` only
- The musl-based Alpine build produces fully static executables
- Release mode applies `strip` to all executables

On macOS:
- Full static linking is not possible (Apple limitation)
- The build uses `-Wl,-search_paths_first` to prefer static libraries

### 3.4 Shared Library Target

An optional `SX_BUILD_DLL` target exists (`sx_shared` / `sx.dll`) for C# P/Invoke interop. This is **OFF by default** and produces a shared library only when explicitly requested.

**Risk: LOW** — The build architecture properly segregates static executables from the optional shared library target.

---

## 4. Code Provenance

### 4.1 Git Author Analysis

| Author Email | Commits | Percentage |
|--------------|---------|------------|
| `dev@scorpiox.net` | 623 | 63.4% |
| `scorpiox@scorpiox.net` | 352 | 35.8% |
| `partner@scorpioplayer.com` | 3 | 0.3% |
| `picobot@scorpioplayer.com` | 2 | 0.2% |
| `pico@scorpiox.net` | 1 | 0.1% |
| `sx@sx` | 1 | 0.1% |

### 4.2 Domain Analysis

| Domain | Commits | Percentage |
|--------|---------|------------|
| `scorpiox.net` | 976 | 99.4% |
| `scorpioplayer.com` | 5 | 0.5% |
| `sx` | 1 | 0.1% |

**99.4% of all commits** (976/982) originate from `@scorpiox.net` addresses. The `scorpioplayer.com` domain appears to be a related/partner entity with only 5 commits. The single `sx@sx` commit appears to be a misconfigured local git config.

### 4.3 Repository Timeline

- **First commit:** `231e9e0` — 2026-01-23 — "Initial commit: ScorpioX CLI chat app"
- **Latest commit:** `b85fca9` — 2026-04-21 — "Add SMTP idle connection timeout (120s)"
- **Total commits:** 982
- **Active period:** ~3 months

**Risk: LOW** — Strong single-organization provenance with consistent authorship.

---

## 5. Third-Party Code Check

### 5.1 LICENSE/COPYING Files Found

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

### 5.2 Copyright Analysis

Third-party copyrights are confined exclusively to the `scorpiox/vendor/` directory. No third-party copyright notices were found in non-vendor project code.

### 5.3 gnuwin64 Vendor Directory

The `scorpiox/vendor/gnuwin64/` directory contains only:
- `download.ps1` — Script to download GNU coreutils from MSYS2 (for Windows)
- `README.md` — Documentation

No pre-built binaries are stored. The download script fetches MSYS2 packages at **deployment time** (not build time) for Windows environments that need GNU tools. This is not a build dependency.

**Risk: LOW** — Vendored code is properly attributed and license-compatible.

---

## 6. Pre-Built Binaries Check

### 6.1 Binary Scan Results

| File | Type | Risk |
|------|------|------|
| `bridge/scorpiox-ws2tcp` | ELF 64-bit x86-64, dynamically linked, not stripped | **Medium** |
| `bridge/scorpiox-ws2tcp-arm64` | ELF 64-bit ARM aarch64, dynamically linked, not stripped | **Medium** |

**No** `.so`, `.dll`, `.dylib`, `.a`, `.lib`, `.o`, `.obj`, or `.exe` files were found anywhere in the repository.

### 6.2 Pre-Built Binary Analysis

Two pre-built ELF binaries exist in `bridge/`:
- Both are **dynamically linked** (not static)
- Both are **not stripped** (debug info present)
- Committed by `dev@scorpiox.net` in commit `b74007ab`
- Source code (`bridge/ws2tcp.c`) is present alongside them
- The `bridge/Makefile` can rebuild them from source

**Finding 6.2.1 (Medium):** Pre-built binaries in a source repository present a supply chain risk — there is no guarantee that the committed binaries match the committed source. These should ideally be built from source during the release process rather than committed as blobs.

---

## 7. Risk Assessment Summary

| # | Finding | Severity | Component | Recommendation |
|---|---------|----------|-----------|----------------|
| 1 | Core C build has zero package manager dependencies | ✅ **Positive** | Core | None — excellent practice |
| 2 | All third-party code vendored in-tree | ✅ **Positive** | Core | Periodically update vendored libs for security patches |
| 3 | Build uses only system compiler, no downloaded toolchains | ✅ **Positive** | Core | None |
| 4 | Static linking by default on Linux | ✅ **Positive** | Core | None — reduces runtime attack surface |
| 5 | 99.4% single-org commit provenance | ✅ **Positive** | Core | None |
| 6 | No FetchContent/ExternalProject in CMake | ✅ **Positive** | Core | None |
| 7 | `bridge/package.json` introduces npm/Bun dependencies | ⚠️ **Medium** | Bridge | Isolate bridge build; pin exact versions; audit transitive deps |
| 8 | Pre-built ELF binaries in `bridge/` | ⚠️ **Medium** | Bridge | Remove committed binaries; build from source in CI |
| 9 | `release_wasm.ps1` clones emscripten from GitHub | ⚠️ **Medium** | WASM release | Pin specific commit hash; verify checksum |
| 10 | `release_whatsapp.ps1` uses curl-pipe-bash for Bun | ⚠️ **Medium** | WhatsApp release | Pin Bun version; verify checksum |
| 11 | `gnuwin64/download.ps1` fetches MSYS2 packages at deploy time | ⚠️ **Low** | Windows deploy | Pin package versions; verify checksums |
| 12 | Multiple executables (not single binary) | ℹ️ **Info** | Core | Architecture decision; not a risk |

### Overall Risk Rating: **LOW**

The core ScorpioX C codebase demonstrates exemplary supply chain security practices. All medium-risk findings are confined to peripheral components (WhatsApp bridge, WASM builds, Windows deployment tooling) that do not affect the primary build pipeline. The primary C build is fully deterministic, uses only vendored and system libraries, and produces static executables with strong provenance.

---

*Report generated: 2026-04-28T11:32 NZST*  
*Audit commit: b85fca9891f8ff39fce93868947ce31fe9fed50e*  
*Agent: Security Audit Agent*