Subumbra

The repository is publicly hosted on GitHub at https://github.com/polysemic/Subumbra and is readable by anyone without authentication.

The project uses Git for version control and is hosted on GitHub. Every commit tracks the exact line-by-line diffs, the author's name and email, and the timestamp of when the change was committed.

Collaborative development is carried out via active branch management, pull requests, and detailed internal review. Interim versions, development branches, and alpha pre-releases are tracked publicly rather than releasing only final monolithic versions.

Repository on GitHub, which uses git. git is distributed.

Every release intended for user or operator consumption is assigned a unique version identifier (e.g. 1.0.0-alpha), which is tracked in the VERSION file and through VCS tags.

Every release is identified and tagged inside the version control system using Git tags matching the version format (e.g., v1.0.0-alpha).

No release notes file found.The project provides human-readable release summaries of major changes, installation requirements, and upgrade paths for each release on its GitHub Releases page (https://github.com/polysemic/Subumbra/releases), rather than simply dumping raw git logs.

There have been no publicly known run-time vulnerabilities with CVE assignments for Subumbra, so this criterion is not applicable at this stage. All security updates are integrated directly into the release process.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/polysemic/Subumbra/blob/main/SECURITY.md. [osps_do_02_01]

https://github.com/polysemic/Subumbra/issues

https://github.com/polysemic/Subumbra/issues

https://github.com/polysemic/Subumbra/issues

https://github.com/polysemic/Subumbra/security/advisories

https://github.com/polysemic/Subumbra/security/policy

Nothing reported. Repo is less than 6 months old.

https://github.com/polysemic/Subumbra/blob/main/docs/subumbra-developer.md

https://github.com/polysemic/Subumbra/blob/main/docs/subumbra-install.md

Subumbra is built and orchestrated entirely using Free/Libre and Open Source Software (FLOSS) tools, specifically Docker (Apache 2.0), Python (PSF License), and standard GNU Bash (GPL). URL: https://github.com/polysemic/Subumbra/blob/main/docs/subumbra-install.md

Subumbra uses automated bash and python-based integration testing harnesses (scripts/council/verify-round.sh and scripts/subumbra-verify) that are released as open source alongside the project. Instructions for running the test suite are documented in the developer guide. URL: https://github.com/polysemic/Subumbra/blob/main/docs/subumbra-developer.md (See "Isolated Deployment Testing (Clean Run Harness)")

The test suite is invocable via standard bash execution paths documented in the developer guidelines (./scripts/council/clean-run.sh and ./scripts/subumbra-verify). URL: https://github.com/polysemic/Subumbra/blob/main/docs/subumbra-developer.md

The automated integration testing harness provisions a clean environment, dynamically builds the containers, generates mock API keys, deploys the stack, and verifies transparent routing, vault isolation, and policy enforcement across the core system functionality. URL: https://github.com/polysemic/Subumbra/blob/main/docs/subumbra-developer.md

Subumbra uses GitHub Actions to run continuous integration on pushes and pull requests to the main branch. The CI pipelines automatically execute static analysis, secret scanning (Gitleaks), python linters (Bandit), filesystem vulnerability scans (Trivy), and dependency checks (pip-audit). URL: https://github.com/polysemic/Subumbra/blob/main/.github/workflows/security.yml

The project maintains a formal policy requiring automated tests to be added and verified when major new functionality (e.g., routing, vault cryptography, edge policies) is implemented. URL: https://github.com/polysemic/Subumbra/blob/main/docs/subumbra-developer.md (See "Testing Policy for New Functionality")

The project adheres to its testing policy by ensuring that recent major architectural additions (such as the integration of the source-trust verifier and probe capabilities) are actively covered by the automated continuous integration pipelines. Evidence of this is visible in the GitHub Actions workflows, where static analysis, vulnerability scanning, and linter tests dynamically target newly added modules. Additionally, the recent implementation of the standalone subumbra-verify test suite demonstrates functional testing coverage for major new edge drift features. URL: https://github.com/polysemic/Subumbra/blob/main/.github/workflows/security.yml

The requirement to add and verify tests for new functionality is explicitly documented as a formal project policy within the project's developer guidelines (docs/subumbra-developer.md). It is listed directly as a prerequisite for submitting a Pull Request (change proposal). URL: https://github.com/polysemic/Subumbra/blob/main/docs/subumbra-developer.md

Subumbra uses multiple static analysis and code quality linters, including Bandit for Python AST security analysis, CodeQL for language-agnostic code quality errors, and Trivy for infrastructure/configuration misconfigurations. URL: https://github.com/polysemic/Subumbra/blob/main/.github/workflows/security.yml

The continuous integration pipeline is configured to enforce compliance. For example, Trivy is configured with exit-code: "1", and the Bandit AST scanner asserts a hard failure if any High-severity code quality warnings are detected. Pull requests cannot pass CI without addressing these warnings. URL: https://github.com/polysemic/Subumbra/blob/main/.github/workflows/security.yml

Subumbra applies strict warnings and exit codes (exit-zero: false or manual exit 1 scripts) for High/Critical SAST and vulnerability findings. In addition, the bash test harnesses use strict modes (set -euo pipefail). URL: https://github.com/polysemic/Subumbra/blob/main/.github/workflows/security.yml

Subumbra exclusively uses standard, publicly published, and expert-reviewed cryptographic algorithms: specifically AES-256 in Galois/Counter Mode (AES-GCM) for symmetric encryption and RSA-OAEP for asymmetric envelope encryption.

The project does not "roll its own crypto." All cryptographic operations are delegated to highly scrutinized, specialized standard libraries: the Python cryptography package (specifically the hazmat primitives) on the host, and the standard Web Crypto API (crypto.subtle) on the Cloudflare Worker edge.

All cryptographic dependencies are FLOSS. The Python cryptography library is dual-licensed under Apache 2.0/BSD, and the Web Crypto API is an open W3C standard implemented by the open-source V8 engine.

Subumbra enforces key lengths that exceed NIST requirements through 2030. Symmetric encryption uses AES-256 (256-bit keys), and asymmetric key pairs use RSA-4096 (4096-bit keys). Smaller key lengths are hardcoded out of the application and cannot be configured or downgraded.

The project strictly forbids broken algorithms. No MD5, RC4, DES, or SHA-1 are used anywhere in the cryptography or hashing pipelines. Fingerprinting and hashing rely strictly on SHA-256.

No known weak algorithms or cipher modes are permitted. The project explicitly uses AES-GCM (an authenticated encryption mode) rather than vulnerable modes like AES-CBC or ECB.

Subumbra relies on standard Cloudflare-managed HTTPS/TLS 1.3 connections for all transit, which inherently enforces Perfect Forward Secrecy (PFS). The application layer itself performs envelope encryption of static credentials, rather than negotiating its own long-term key agreement sessions.

The project strictly uses Cryptographically Secure Pseudo-Random Number Generators (CSPRNGs). Python components use the secrets module (which hooks into urandom), and the Worker components use crypto.getRandomValues() for all nonces, IVs, and key generation.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

The project does not fetch executable binaries or scripts over unverified HTTP. All codebase distribution occurs over HTTPS via git clone from GitHub. Docker images and package dependencies are pulled exclusively via HTTPS registry channels with strict hash-pinning requirements (e.g., --require-hashes in pip).

Subumbra actively uses Dependabot, pip-audit, and Trivy in its GitHub Actions pipelines to identify and fail builds if unpatched medium/high-severity vulnerabilities exist in dependencies, preventing them from persisting or reaching production.

The project has automated pipelines explicitly designed to block PRs and fail builds on any Critical or High SAST/dependency findings, forcing immediate remediation of critical vulnerabilities prior to merging.

The project maintains a zero-leak policy enforced by an automated GitHub Action running gitleaks on all commits and pull requests, completely scanning the entire git history to ensure no valid private credentials are ever published to the repository. URL: https://github.com/polysemic/Subumbra/blob/main/.github/workflows/security.yml

Subumbra integrates Semgrep and Bandit for static code analysis. Before any major release, a security scan suite is executed on the VPS staging environment using run-public-report-suite-vps.sh. This clones a clean copy of the codebase and runs the analysis tools, publishing sanitized markdown reports (e.g., semgrep-baseline.md and bandit.md) to the security/reports/ directory.

The static analysis tools are configured to look for common vulnerabilities in Javascript, Dockerfiles, and Python. Semgrep uses its baseline registry rules covering OWASP Top 10, CWE-269 (Improper Privilege Management), and CWE-939 (Improper Authorization in Custom URL Schemes). Bandit acts as a specialized Python linter searching for common security mistakes like hardcoded secrets, shell injections, and insecure protocol uses.

The Subumbra project enforces that all medium and higher severity vulnerabilities identified by static analysis are addressed. The automated verification suite exits non-zero if security scan scripts fail. Any confirmed security issue is tracked by the council and patched in a dedicated remediation round

Static analysis can be executed locally on every commit or daily using the helper script scripts/security/scan-all.sh, and is run on the remote VPS staging branch whenever the three-LLM council verifies a code proposal.

Dynamic analysis is applied to proposed releases before deployment. Subumbra runs OWASP ZAP (Zed Attack Proxy) and Nuclei against the live Worker API endpoint deployed to staging. The baseline scans (run-zap-vps.sh and run-nuclei-vps.sh) run passive and active web vulnerability scans. Sanitized reports are saved under security/reports/ (e.g., zap-baseline.md).

Subumbra is written entirely in memory-safe languages: JavaScript/Node.js for the Cloudflare Worker/UI, and Python for the proxy/keys services. It does not use memory-unsafe languages like C or C++.

The test suites and verification harness (verify-round.sh) run in the staging environment with strict validation checks and detailed logging enabled. Decryption failure codes, signature validation exceptions, and policy validation assertions are fully active in staging, ensuring that dynamic runs fail loudly and immediately if invariants are breached.

All vulnerabilities discovered through dynamic scans or manual penetration tests are triaged by the review council (Claude, Codex, Gemini), addressed in remediation rounds, and verified before merging to main.