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

1.2 bridge/package.json Analysis

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

{
  "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:

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

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:

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

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

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:

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:

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

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:

$(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

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

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

---

8. Recommendations

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.

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.

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.

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

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