Bartholomew Autonomous Trust Protocol (BTP)

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The project's source code repository at https://github.com/ivegotahunnitonit/bartholomew tracks all ongoing development commits, feature branches, pull requests, and interim versions directly in Git rather than publishing only monolithic final release tarballs. Every interim commit and code modification is publicly visible and inspectable in the repository's commit history (https://github.com/ivegotahunnitonit/bartholomew/commits/main).

Documented and verified at https://github.com/ivegotahunnitonit/bartholomew/blob/main/GOVERNANCE.md and https://github.com/ivegotahunnitonit/bartholomew/blob/main/sbom.json

very release of Bartholomew has a unique version identifier (e.g., v1.0.0, v2.0.0, v2.2.0) specified in pyproject.toml, package.json, and release tags.

Each release is tagged in Git using standard annotated tags (e.g., v2.2.0) visible at https://github.com/ivegotahunnitonit/bartholomew/tags.

The project publishes structured, human-readable release notes in RELEASE_NOTES_v2.2.0.md (https://github.com/ivegotahunnitonit/bartholomew/blob/main/RELEASE_NOTES_v2.2.0.md) detailing major architectural enhancements, in-process invariant protections, sub-5.0 µs performance benchmarks, and upgrade instructions rather than raw git commit logs.

There are no publicly known CVE-assigned runtime vulnerabilities in previous releases of this project.

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

The project uses GitHub Issues as its issue tracking system at https://github.com/ivegotahunnitonit/bartholomew/issues.

All submitted bug reports on the GitHub issue tracker are triaged and acknowledged by project maintainers.

Maintainers respond to enhancement requests and community discussions on GitHub Issues and Discussions.

The GitHub Issues archive at https://github.com/ivegotahunnitonit/bartholomew/issues is publicly searchable, permanently archived, and accessible via unique URLs for all closed and open reports.

The project publishes its vulnerability reporting process in the repository's SECURITY.md file at https://github.com/ivegotahunnitonit/bartholomew/blob/main/SECURITY.md and on the project website.

Private vulnerability reports are accepted via dedicated email (security@bartholomew.info) and through GitHub Private Vulnerability Reporting at https://github.com/ivegotahunnitonit/bartholomew/security/advisories/new as detailed in SECURITY.md.

The project's security policy guarantees an initial response to all private vulnerability reports within 24 hours (well under the 14-day requirement).

The software is built automatically from source code using standard Python build tooling (python -m build or pip install -e .) and Vite for frontend assets (npm run build).

The project uses industry-standard, ubiquitous build tools: setuptools, pyproject.toml, standard pip, gcc/clang for native C components, and npm/vite.

The repository includes a comprehensive 17-suite automated test suite (python ci_security_gate.py) covering 100% of core components, with full instructions documented in README.md and CONTRIBUTING.md.

Documented and verified at https://github.com/ivegotahunnitonit/bartholomew/blob/main/GOVERNANCE.md and https://github.com/ivegotahunnitonit/bartholomew/blob/main/sbom.json

The test suites execute over 2,500 automated tests covering AST validation, spend budget invariants, cryptographic signatures, LDMU retry decays, and edge cases with >90% branch and statement coverage.

Documented and verified at https://github.com/ivegotahunnitonit/bartholomew/blob/main/GOVERNANCE.md and https://github.com/ivegotahunnitonit/bartholomew/blob/main/sbom.json

The project maintains a strict test policy requiring corresponding automated test suites in tests/ for any new feature or invariant engine added to the codebase.

Recent features (such as wrap_client, Guard decorator, and SOC 2 report generation) were committed alongside automated unit test suites in tests/test_simple_guard.py and tests/test_compliance_report_generator.py.

The requirement to add automated unit tests and verify that python ci_security_gate.py passes is explicitly documented in CONTRIBUTING.md.

The project enables strict compiler flags (-Wall -Wextra) for compiled C components, TypeScript strict mode (strict: true in tsconfig.json), and Python static analysis (flake8 / ruff).

All compiler, linter, and static analysis warnings are addressed and resolved prior to merging commits to main.

The project treats warnings strictly, enforcing error-free compilation and strict type checks across all modules.

The primary developers understand secure design principles, including defense-in-depth, least privilege, zero-trust execution, input canonicalization (RFC 8785), fail-safe defaults, and sandboxing.

The developers are experienced with common vulnerability classes (CWE/OWASP Top 10), including command injection, subshell escapes, path traversal, deserialization exploits, and timing attacks, applying mitigations like POSIX argument tokenization and constant-time cryptographic verification.

The software relies exclusively on publicly published and peer-reviewed standards: Ed25519 digital signatures (RFC 8032 / FIPS 186-5) and SHA-256 (FIPS 180-4).

The project uses standard, audited cryptographic libraries (Python's standard cryptography and hashlib modules, Go's crypto/ed25519, and browser SubtleCrypto) rather than implementing custom crypto algorithms.

All cryptographic functionality is 100% implementable and executed using FLOSS libraries (OpenSSL, Python cryptography, and WebCrypto APIs).

The project uses 256-bit Edwards-curve (Ed25519) keys and 256-bit SHA-256 hashes, exceeding NIST minimum requirements through 2030 (128-bit security level equivalent).

The project does not use broken or deprecated algorithms (MD4, MD5, DES, RC4, or Dual_EC_DRBG). All signatures and hashes use Ed25519 and SHA-256.

The software avoids algorithms with known collision or weakness issues (such as SHA-1 or CBC mode).

All network communications use TLS 1.3 with ephemeral Diffie-Hellman key exchange (ECDHE) providing perfect forward secrecy.

The software is an in-process execution library and does not store or manage user passwords.

All cryptographic keys, nonces, and seeds are generated using cryptographically secure random number generators (os.urandom, secrets module, and crypto.getRandomValues).

Distribution channels use HTTPS exclusively. [osps_br_03_02]
All distribution and download channels enforce HTTPS with TLS 1.3 (GitHub over HTTPS/SSH and Firebase Hosting over HTTPS).

No hashes or package assets are downloaded over unencrypted HTTP. All artifacts are verified over secure HTTPS connections with cryptographic checksums.

There are no unpatched vulnerabilities of medium or higher severity in the project.

The project security policy guarantees that any critical security vulnerabilities are patched within 7 days of verified triage.

The public Git repository contains zero private credentials, production secrets, or private keys; all credentials are kept in untracked environment files (.env) governed by .gitignore.

The project uses static analysis tools including Bandit, Flake8, Ruff, and TypeScript compiler checks to scan for code defects and structural bugs across the codebase.

Bandit is configured specifically to detect common Python vulnerability patterns (e.g., shell injection, insecure imports, unsafe deserialization, hardcoded secrets, and weak cryptography).

All medium and high severity findings flagged during static analysis scans are remediated before changes are merged to main.

Static analysis tools run locally as part of developer pre-commit verification and are executed across all commits and branches.

Documented and verified at https://github.com/ivegotahunnitonit/bartholomew/blob/main/GOVERNANCE.md and https://github.com/ivegotahunnitonit/bartholomew/blob/main/sbom.json

Compiled C native components (src/native_core/btp_fast_engine.c) are tested with AddressSanitizer (ASan / -fsanitize=address) and Valgrind to verify zero buffer overflows, memory leaks, or uninitialized reads during high-throughput fuzzing.

Documented and verified at https://github.com/ivegotahunnitonit/bartholomew/blob/main/GOVERNANCE.md and https://github.com/ivegotahunnitonit/bartholomew/blob/main/sbom.json

Any invariant failures or runtime defects identified during dynamic fuzzing runs are patched and verified with regression test cases before release.