Skip to content

Security: wenathlan/e2ugh

SECURITY.md

Security Policy — e2ugh virtual hardware engine

Supported release line

Security fixes target the maintained 1.x line and later maintained releases.

Scope of the engine

e2ugh is a 100 percent software virtual hardware engine: CPU, memory and GPU identities are spoofed through an LD_PRELOAD interposition layer, a Mesa llvmpipe/lavapipe/rusticl software GL stack and QEMU TCG/MTTCG guest execution. No physical hardware is probed, touched or required. The engine image runs as the non-root vhe user (uid/gid 10000) with no published port; the entrypoint picks a random port in 30000-60000 unless the operator pins VHE_PORT/PORT.

Secrets and credentials

The public repository must not include provider keys, session cookies, database files, captured authorization headers or .env payloads. The web node reads its mesh HMAC key from the E2UGH_MESH_KEY environment variable and its database path from E2UGH_DB; both are operator supplied and never committed. The CI secret-scan gates (TruffleHog with --results=verified over the full git history) and the Trivy filesystem scan (vuln, secret, misconfig) run on every push and pull request.

Reporting a vulnerability

Do not open a public issue containing credentials, session cookies, private URLs or exploit details. Remove sensitive data from logs and send a minimal report through the repository's private security reporting channel at https://github.com/wenathlan/e2ugh/security/advisories/new. Revoke any credential that may have appeared in a local file or public commit before reporting. Security advisories and published fixes are tracked at https://github.com/wenathlan/e2ugh/security/advisories.

Supply chain

  • Security advisories for the npm package line are published at https://github.com/wenathlan/e2ugh/security/advisories and mirrored to the npm audit stream of every release.
  • The threat model of the spoofing surface is documented at https://github.com/wenathlan/e2ugh/blob/main/docs/security.md.
  • npm installs run through npm ci against the committed lockfile in every workflow.
  • Dockerfile base images are digest-pinned (ubuntu:24.04@sha256:..., python:3.14.7-slim@sha256:...); source tarballs (mesa, node setup) are sha256-verified at build time.
  • High-risk third-party actions are pinned by immutable commit SHA (aquasecurity/trivy-action after CVE-2026-33634); the rest are pinned to immutable point-release tags and kept current by the weekly Dependabot schedule.
  • The image build emits provenance (mode=max) and SBOM attestations signed through the job OIDC token; the security pipeline publishes a standalone CycloneDX SBOM artifact.

There aren't any published security advisories