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

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:

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):

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

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:

3.2 Internal Libraries (Static)

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

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

4.2 Domain Analysis

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

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

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

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