# Architecture Security Audit Report

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

---

## Executive Summary

The ScorpioX codebase is a large, predominantly C-language project implementing a TUI-based AI assistant client with supporting tools. The architecture follows a **vendored-dependency model** — all critical third-party code is committed directly into the repository under `scorpiox/vendor/`, eliminating runtime dependency on external package managers for the core C build. The build system uses CMake with a strong preference for fully-static linked binaries on Linux.

**Overall Architecture Risk: LOW** — The project demonstrates disciplined supply chain hygiene for its core C codebase. Two notable findings require acknowledgment: (1) a peripheral `bridge/` component introduces npm dependencies, and (2) two pre-built ELF binaries ship in the repository.

---

## 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 | — | — |
| `Pipfile` | No | — | — |
| `Gemfile` | No | — | — |
| `pom.xml` | No | — | — |
| `build.gradle` | No | — | — |
| CMake `FetchContent` | No | — | — |
| CMake `ExternalProject` | No | — | — |
| CMake `file(DOWNLOAD)` | No | — | — |

### 1.2 bridge/package.json Analysis

The only package manager file is in the `bridge/` subdirectory — a **WhatsApp bridge** component written in TypeScript:

```json
{
  "name": "scorpiox-whatsapp-bridge",
  "version": "1.0.0",
  "private": true,
  "type": "module",
  "dependencies": {
    "@whiskeysockets/baileys": "^7.0.0-rc.9",
    "qrcode-terminal": "^0.12.0"
  }
}
```

- **2 npm dependencies** with transitive dependency tree (lock file: `bun.lock` present, 22KB)
- No `node_modules` directory is checked into the repo
- This component is **peripheral** — not part of the core C build, not referenced by CMakeLists.txt
- The bridge directory also contains `ws2tcp.c` (42KB) — a pure C WebSocket-to-TCP proxy that is compiled separately via its own Makefile

**Risk: MEDIUM** — The npm dependencies introduce supply chain risk for the WhatsApp bridge feature only. The core application is unaffected.

### 1.3 Vendored Dependencies (In-Tree)

The project vendors two third-party C libraries directly in the source tree:

| Library | Location | License | Files | Lines |
|---------|----------|---------|-------|-------|
| **mbedTLS** | `scorpiox/vendor/mbedtls/` | Apache-2.0 OR GPL-2.0+ | 273 files | 206,340 |
| **yyjson** | `scorpiox/vendor/yyjson/` | MIT | 3 files | 19,556 |

Both are compiled as **static libraries** from source during the build (not downloaded):
- `add_library(yyjson STATIC vendor/yyjson/yyjson.c)`
- mbedTLS built via its own `CMakeLists.txt` subdirectory

The mbedTLS vendored copy uses a **custom minimal configuration** (`sx_mbedtls_config.h`) that enables only:
- AES-128-CFB encryption
- TLS 1.2 client/server
- PBKDF2-SHA1 key derivation
- X.509 certificate handling

**Risk: LOW** — Vendored source code is auditable and pinned. No automatic update mechanism. The reduced mbedTLS config limits attack surface.

### 1.4 Zero External Package Manager Dependencies (Core Build) — VERIFIED ✅

The core C build (CMake) has **zero** external package manager dependencies. All third-party code is vendored. System libraries (libcurl, OpenSSL, zlib, etc.) are expected to be pre-installed on the build host — they are found via `find_static_library()` and `pkg-config`, not downloaded.

---

## 2. Build Process Security

### 2.1 Build System Overview

- **Build tool:** CMake 3.16+ (standard, well-audited build system)
- **Language standard:** C11 (`CMAKE_C_STANDARD 11`)
- **Default build type:** Release with `-O2 -DNDEBUG`
- **Compiler:** System `gcc` or `clang` (no downloaded toolchains)
- **Cross-compilation:** ARM64 support via `aarch64-linux-gnu-gcc` (system cross-compiler)

### 2.2 Static Linking Strategy

The build defaults to **fully static linking** (`SX_STATIC_LINK=ON`):

```cmake
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static")
set(CMAKE_FIND_LIBRARY_SUFFIXES ".a")
```

System static libraries linked:
- libcurl (from `/opt/curl-static` or system)
- OpenSSL (libssl, libcrypto)
- zlib, zstd, brotli
- pthread
- nghttp2, nghttp3
- libpsl, libidn2, libunistring
- libX11, libxcb (for screenshot feature)
- libssh, librtmp

**Risk: LOW** — Static linking from system-installed libraries is a sound practice. The `/opt/curl-static` path suggests a pre-built minimal curl is used for Alpine/musl builds, which is a common CI pattern.

### 2.3 Build-Time Code Generation

One build-time code generation step exists:

```cmake
add_custom_command(
    OUTPUT ${MODELS_HEADER}
    COMMAND ${Python3_EXECUTABLE} ${MODELS_GENERATOR} ${MODELS_HEADER}
    ...
)
```

The `code_generator_models.py` script can fetch AI model IDs from a live API, but:
- **Model fetching is FROZEN** (`MODELS_FROZEN = True`) — the script emits pre-existing constants without network calls
- The generated header is already committed to the repo (`sx_models_generated.h`)
- Release builds explicitly disable generation: `-DSX_GENERATE_MODELS=OFF`
- Network fetching requires explicit `--fetch` flag

**Risk: LOW** — The frozen-by-default design prevents unintended network calls during builds.

### 2.4 Windows Build Considerations

- A `gnuwin64/download.ps1` script downloads MSYS2 GNU tool packages from `repo.msys2.org` for Windows builds
- This is a **development tool** for Windows, not part of the core build pipeline
- Windows builds also link against Windows system libraries (ws2_32, crypt32, etc.)

**Risk: LOW** — Standard Windows development practice. The download script is not invoked during CMake build.

### 2.5 Build-Time Validation

A build-time validation target exists (Linux only):
```cmake
add_custom_target(validate_config ALL
    COMMAND ${PWSH_EXE} -ExecutionPolicy Bypass -File .../validate_config_keys.ps1
)
```
This validates configuration key consistency between source files — a positive security practice.

---

## 3. Binary Output Analysis

### 3.1 Primary Binary

The main executable target is `sx` (symlinked as `scorpiox`):
```cmake
add_executable(sx sx.c sx_statusbar.c sx_cache_keepalive.c)
target_link_libraries(sx PRIVATE sxterm sxui sxnet sxutil ${CURL_LINK_LIBS})
```

With static linking enabled, this produces a **single self-contained binary** with no shared library dependencies beyond libc (or fully static on musl/Alpine).

### 3.2 Additional Executables

The build produces **multiple executables** (not a single binary). The install target lists core executables:

```cmake
install(TARGETS
    sx scorpiox-bash scorpiox-config
    scorpiox-conv scorpiox-debug scorpiox-logger
    scorpiox-printlogs scorpiox-systemprompt
    scorpiox-mirror-git scorpiox-vault-git
    RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})
```

Total executable targets identified: **~65 executables** including:
- `sx` — Main TUI client
- `scorpiox-bash` — Shell wrapper
- `scorpiox-server` — Server mode
- `scorpiox-email` / `scorpiox-server-email` — Email functionality
- `scorpiox-tmux` / `scorpiox-multiplexer` — Terminal multiplexer
- Various auth token tools (`scorpiox-claudecode-fetchtoken`, etc.)
- Utility tools (search, fetch, dns, kql, etc.)

### 3.3 Optional Shared Library

An **optional** shared library target exists but is **OFF by default**:
```cmake
option(SX_BUILD_DLL "Build sx.dll shared library for C# P/Invoke" OFF)
```

When enabled, it produces `libsx.so` / `libsx.dylib` / `sx.dll` for C# interop.

### 3.4 Single Binary Assessment

**The project does NOT produce a single binary** — it produces a suite of ~65 statically-linked executables. However, the `sx` executable is the primary deliverable and the majority of functionality is consolidated through shared static libraries (sxutil, sxnet, sxui, sxterm). All executables are built from the same source tree with the same compiler flags.

**Risk: LOW** — Multiple executables is a reasonable design for a tool suite. Each executable is self-contained when statically linked.

---

## 4. Pre-Built Binaries in Repository

### 4.1 Standard Binary Scan

```
find -name '*.so' -o -name '*.dll' -o -name '*.dylib' -o -name '*.a' -o -name '*.lib'
```
**Result: NONE found** ✅

### 4.2 Extended Binary Scan

Two **pre-built ELF executables** were found in `bridge/`:

| File | Architecture | Type | Size |
|------|-------------|------|------|
| `bridge/scorpiox-ws2tcp` | x86-64 | ELF, dynamically linked | 39,760 bytes |
| `bridge/scorpiox-ws2tcp-arm64` | ARM aarch64 | ELF, dynamically linked | 74,024 bytes |

These are compiled versions of `bridge/ws2tcp.c` (42,153 bytes of C source). The source is present alongside the binaries, and the `bridge/Makefile` shows how to rebuild them:

```makefile
$(TARGET): ws2tcp.c
	$(CC) $(CFLAGS) -o $@ $< $(LDFLAGS)
```

**Risk: MEDIUM** — Pre-built binaries in a repository are a supply chain concern. While the source code is co-located and the Makefile allows verification builds, there is no automated mechanism to verify the checked-in binaries match the source. These binaries are dynamically linked (not static), which differs from the project's general static-linking philosophy.

**Recommendation:** Either remove the pre-built binaries and require building from source, or add a CI step that rebuilds and verifies hash consistency.

---

## 5. Code Provenance

### 5.1 Git Author Analysis

| Email | Name | Domain |
|-------|------|--------|
| `dev@scorpiox.net` | scorpioxinc | scorpiox.net |
| `partner@scorpioplayer.com` | ScorpioX | scorpioplayer.com |
| `pico@scorpiox.net` | Pico | scorpiox.net |
| `picobot@scorpioplayer.com` | Pico | scorpioplayer.com |
| `scorpiox@scorpiox.net` | scorpiox | scorpiox.net |
| `sx@sx` | sx | (local) |

**Total commits:** 987

### 5.2 Provenance Assessment

All 6 unique author emails map to two related domains:
- `scorpiox.net` — Primary organization domain (3 addresses)
- `scorpioplayer.com` — Related product domain (2 addresses)
- `sx@sx` — Likely a local/automation identity

**No external contributors detected.** All commits originate from the ScorpioX organization.

**Risk: LOW** — Single-organization provenance with consistent authorship patterns. The `sx@sx` local identity is common for automated commits.

---

## 6. Third-Party Code Check

### 6.1 LICENSE / COPYING Files

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

### 6.2 Vendor Directory Summary

```
scorpiox/vendor/
├── gnuwin64/          # Windows GNU tools download script (not compiled code)
│   ├── README.md
│   └── download.ps1
├── mbedtls/           # Vendored mbedTLS (TLS/crypto library)
│   ├── LICENSE
│   ├── sx_mbedtls_config.h  # Custom minimal config
│   ├── include/       # Headers
│   └── library/       # Source files
└── yyjson/            # Vendored yyjson (JSON parser)
    ├── LICENSE
    ├── yyjson.c
    └── yyjson.h
```

### 6.3 Third-Party Code in Main Source

References to "third party" found in main source files (`sx.c`, `sx_dll.c`, `sx_dll.h`, `scorpiox-busybox.c`, `sxmail_tls.c`, `sxmail_dkim.h`, `libsxnet/sx_frp.c`) relate to the vendored mbedTLS usage and internal documentation — no additional hidden third-party code detected.

**Risk: LOW** — All third-party code is clearly identified, properly licensed, and isolated in the `vendor/` directory.

---

## 7. Risk Assessment Summary

| Finding | Risk Level | Details |
|---------|-----------|---------|
| Core C build — zero package manager deps | **LOW** ✅ | No npm/pip/cargo/go dependencies for core build |
| Vendored mbedTLS & yyjson | **LOW** ✅ | Source committed, auditable, properly licensed |
| Build system (CMake + system compiler) | **LOW** ✅ | No downloaded toolchains, standard build tools |
| Static linking default | **LOW** ✅ | Reduces runtime dependency surface |
| Code provenance (single org) | **LOW** ✅ | All 987 commits from ScorpioX organization |
| Build-time code generation (frozen) | **LOW** ✅ | Network calls disabled by default |
| `bridge/package.json` (npm deps) | **MEDIUM** ⚠️ | 2 npm deps for peripheral WhatsApp bridge only |
| Pre-built ELF binaries in `bridge/` | **MEDIUM** ⚠️ | 2 pre-compiled binaries; source co-located but no hash verification |
| Multiple executables (~65) vs single binary | **LOW** ℹ️ | Design choice; each is self-contained when statically linked |
| System library dependencies (curl, SSL, etc.) | **LOW** ✅ | Standard system libraries, found at build time, not downloaded |

---

## 8. Recommendations

1. **Remove or verify pre-built binaries** — Add a CI step to rebuild `bridge/scorpiox-ws2tcp` and `bridge/scorpiox-ws2tcp-arm64` from source and verify checksums, or remove the pre-built binaries entirely.

2. **Isolate bridge component** — Consider moving `bridge/` to a separate repository or clearly documenting that it has different supply chain properties than the core C codebase.

3. **Pin vendored library versions** — Add a `VENDOR_VERSIONS.md` file documenting the exact versions/commits of mbedTLS and yyjson that are vendored, to facilitate future CVE tracking.

4. **Audit mbedTLS vendor currency** — Verify the vendored mbedTLS version against known CVEs. The 273-file vendored copy should be periodically updated.

5. **Lock npm dependencies** — The `bun.lock` file is present, which is good. Consider adding integrity hashes if not already present.

---

*Report generated by Security Audit Agent — 2026-04-28T13:00 NZST*