cosmo edge - Moses Yebei

Abstract

Production-grade C++ edge AI engine for video analytics and on-device VLM across Sophon, Rockchip RKNN, and x86, with visual orchestration, real-time OSD, events, and reproducible benchmarks.

The Problem

Deploying AI models to edge devices requires a unified build, runtime, and orchestration layer that works across heterogeneous hardware such as Sophon, Rockchip RKNN, and x86. Existing toolchains scatter model‑import scripts, runtime binaries, and configuration files, making it hard to ship a consistent video‑analytics application to multiple target boards.

What This Does

Engine & Console – The repository contains a production‑grade C++ engine (src/) that runs on all supported platforms, plus a lightweight web console in src/console/.
Model Import & Orchestration – Scripts in tools/ (e.g., tools/import_model.py) convert ONNX/Yolo weights into platform‑specific binaries and generate JSON scene files that the engine reads at runtime.
Video Access & Event Delivery – The engine supports ONVIF and GB28181 discovery (src/video_onvif.cpp, src/video_gb28181.cpp) and emits events through a REST API (src/api/server.cpp).
Benchmarking – docs/benchmarks/ hosts reproducible workloads and a CI workflow (.github/workflows/nightly-build-test-sophon.yml) that builds and tests on each target.

How It Is Wired

Entry Point – The main executable is built from src/main.cpp. The CMakeLists at the root invokes add_executable(cosmo-edge src/main.cpp …) and links against the third‑party libraries in 3rd/.

main.cpp initializes the Engine singleton, which loads configuration from config.yaml (located in config/).
Engine::loadScene() opens the scene JSON and creates Scene objects that own VideoSource and Detector instances.
Each VideoSource (e.g., OnvifSource in src/video_onvif.cpp) opens an RTSP stream, then pushes frames into a FrameQueue.
Detector subclasses (e.g., YoloDetector in src/detector/yolo.cpp) receive frames, run inference via the platform runtime (src/runtime/rknn.cpp or src/runtime/sophon.cpp), and emit DetectionEvent objects.
EventDispatcher serialises events to JSON and writes them to a socket handled by ApiServer in src/api/server.cpp.
The console UI (React/Vue in src/console/) polls the API endpoint /events and updates OSD overlays in real time.

The call graph is linear from main.cpp → Engine → VideoSource/Detector → EventDispatcher. No deep cycles exist; the only hub is the Engine which owns all subsystems. Modifying an event format requires touching src/api/server.cpp and src/engine/engine.h, while adding a new detector only needs a new subclass in src/detector/.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/cosmo-edge
cd cosmo-edge

# Build the engine (C++17, CMake)
mkdir build && cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build

# Run the console (requires node/npm)
cd src/console
npm install
npm run dev

# Start the engine with a scene
./build/cosmo-edge --config config/default.yaml

Setup – The Dockerfile in 3rd/cryptopp-cmake-CRYPTOPP_8_9_0/.devcontainer/ shows the minimal runtime image; the CI workflow (.github/workflows/ci-build-and-test.yml) builds the same image.
Configuration – config/default.yaml contains the RTSP URLs, detector paths, and API port.
Running – The console UI is accessible at http://localhost:3000; the engine logs to logs/engine.log.

Missing: No explicit CLI flags are documented beyond --config; if you need environment variables, refer to the docs/en/guide/configuration.md.

Real-World Use

A security camera on a Rockchip RK3566 can run a YOLO‑v5 detector with 30 fps. Deploy the prebuilt RKNN runtime (rknn/) and point the engine to the device’s RTSP URL. The console will show live bounding boxes and push a POST /api/events to an external SIEM whenever an intruder crosses the zone.

Code Health & Issues

Security – The static scan identified 3 low‑severity secret paths: 3rd/openssl-3.5.3/apps/ca-key.pem, 3rd/openssl-3.5.3/apps/ca-req.pem, 3rd/openssl-3.5.3/apps/cert.pem. These files are test certificates and should be removed from production branches.
Testing – 5,602 test files exist, most under test/. CI is enabled via .github/workflows/ci-build-and-test.yml.
Documentation – 3,475 doc files exist; the README provides quick‑start guidance.
Licensing – Apache‑2.0; third‑party libs are permissively licensed.

The Bottom Line

CosmoEdge delivers a fully integrated C++ edge AI engine that abstracts platform differences and offers a web console for real‑time monitoring. The build process is straightforward with CMake, but the repo contains many third‑party dependencies that inflate the source tree. The main drawback is the presence of test certificates in the public repo; removing them will improve security hygiene. If you need a fast, consistent deployment pipeline across Sophon, Rockchip, and x86, this project is a solid base.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

21,635 files

C3942
C/C++ Header3595
Go1496
Markdown1222
C++619
JavaScript308

ReactVueDjangoExpressDockerTransformersYOLOONNXVector storeCUDA

Dependencies

3 of 7 declared dependencies are a major version behind. Resolved 7 of 7 against the registry.

Package	Declared	Latest	Behind
`cryptography`	==46.0.3	50.0.0	4 major
`websockets`	==15.0.1	17.0.1	2 major
`pytest`	==8.4.2	9.1.1	1 major

Findings

LowSecret-shaped paths present; the code-health audit confirms or clears them 3rd/openssl-3.5.3/apps/ca-key.pem, 3rd/openssl-3.5.3/apps/ca-req.pem, 3rd/openssl-3.5.3/apps/cert.pem

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

critical1

high3

medium4

low1

Upgrade the pinned dependency carrying a critical advisorycritical13 occurrences

cryptography@46.0.3 CVE-2026-39892 (critical) +12 more

The manifest pins the exact version the advisory covers, so this is not a warning about drift: the vulnerable code is what installs, and a critical rating means it is reachable over the network without credentials or user interaction.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Pin third-party GitHub Actions to a commit SHAhigh4 occurrences

.github/workflows

docker/setup-buildx-action@v4, docker/build-push-action@v7, docker/login-action@v4, docker/metadata-action@v6

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Upgrade the pinned dependency carrying a published advisoryhigh6 occurrences

pytest@8.4.2 CVE-2025-71176 (medium) +1 more; filelock@3.20.0 CVE-2026-22701 (medium) +3 more

The pinned version is the one that installs, so a published advisory against it describes this deployment rather than a hypothetical one, and the advisory is also a public description of how to exploit it.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Drop privileged mode and host networkinghigh2 occurrences

docker-compose.sophon.yml

network_mode: host

privileged hands the container every capability including direct device access, which makes escaping to the host a documented one-liner, and host networking removes the network boundary so every port the container opens is open on the host.

Fix: Grant the specific capability the workload needs with cap_add, and publish ports explicitly.

Pin the container base image by digestmedium

3rd/cryptopp-cmake-CRYPTOPP_8_9_0/.devcontainer/Dockerfile

mcr.microsoft.com/vscode/devcontainers/python:0-${VARIANT}

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Move large binaries to Git LFS or out of the repositorymedium23 occurrences

3rd/onnxruntime-linux-x64-1.26.0/lib/libonnxruntime.so.1.26.0

23 blobs over 5MB: libonnxruntime.so.1.26.0 22.0MB, evppkey_slh_dsa_siggen.txt 19.5MB, evppkey_slh_dsa_sigver.txt 19.4MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Set persist-credentials: false on checkoutmedium

.github/workflows/ci-build-contracts.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow

.github/workflows/ci-build-contracts.yml

1 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.