Cross-Border Stablecoin Register (CBSR)

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.

Development happens as incremental commits on the default branch and in pull
requests, not as periodic dumps of final releases. The repository's build
notes (BUILD_NOTE_v0.*.md) and CHANGELOG.md document the interim states
between tagged releases, and every change is reviewable in git history before
it is released.

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

Every release carries a unique version identifier, declared in one place
(pyproject.toml version) and propagated into dataset.json meta.version,
RELEASE_MANIFEST.json, CITATION.cff and the generated API projections. The
build fails if these diverge (tools/check_identifiers.py). The current
release is 0.11.0.

Each release is identified in version control by a git tag, and each tagged
release is archived to Zenodo for a DOI (see CITATION.cff). RELEASE_CHECKLIST.md
gates tagging behind the canonical verifier.

Non-trivial release notes file in repository: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/main/CHANGELOG.md.

N/A: the project has had no publicly known vulnerability with a CVE assignment or similar at the time any release was created, so there is nothing for the release notes to identify. pip-audit runs as a release gate and a known unreviewed vulnerability is an explicit release hard stop (SECURITY.md).

Users submit bug reports through the public GitHub issue tracker:
https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/issues
Vulnerabilities follow a separate private process in SECURITY.md.

The project uses the GitHub issue tracker for individual issues, with issue
templates configured in .github/ISSUE_TEMPLATE/.
https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/issues

No externally submitted bug reports have been received in the last 2-12 months, so there are none outstanding without acknowledgement. The tracker is public and monitored by the maintainer; GOVERNANCE.md records the correction and response process that applies when a report arrives.

No externally submitted bug reports have been received in the last 2-12 months, so there are none outstanding without acknowledgement. The tracker is public and monitored by the maintainer; GOVERNANCE.md records the correction and response process that applies when a report arrives.

All reports and responses are publicly archived and searchable in the GitHub
issue tracker, including closed issues:
https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/issues?q=is%3Aissue

SECURITY.md publishes the vulnerability reporting process, including
acknowledgement targets (3 business days), triage targets (7 business days), a
90-day default coordinated-disclosure window, good-faith research safe
harbour, and the project's trust boundary.
https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/main/SECURITY.md

SECURITY.md directs reporters to GitHub private vulnerability reporting for
this repository and explicitly forbids disclosing an exploitable issue in a
public issue. It also states that secrets and sensitive payloads must not be
sent before a protected channel is agreed.
https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/main/SECURITY.md

N/A: no vulnerability report has been received in the last 6 months, so there is no response time to report. SECURITY.md commits to acknowledging a complete private report within 3 business days.

Non-trivial build file in repository: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/main/Makefile.

Non-trivial build file in repository: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/main/Makefile.

The project builds using only FLOSS tools: CPython, pip, hatchling, and GNU
Make. The full dependency graph is pinned in constraints/ and inventoried by
tools/license_report.py, and a CycloneDX SBOM is emitted on every canonical
verification run (dist/cbsr-0.11.0.cdx.json).

The project ships an automated test suite in tests/, released as FLOSS under
Apache-2.0 with the rest of the tooling: test_agenticfi_scenarios.py (31
table-driven policy scenarios), test_receipt_mutations.py (13 receipt
mutations), test_freshness_policy_receipts.py and test_architecture_review.py.
Additional negative gates run through tools/run_negative_tests.py. How to run
them is documented in CONTRIBUTING.md and README.md: python -m tools.verify,
which executes the full suite plus the build, schema, semantic and packaging
gates. CI runs the same command.
https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/main/CONTRIBUTING.md

The suite is invocable in the standard way for Python (pytest), and the
project wraps it in one canonical aggregate command, python -m tools.verify
(also make verify), which CONTRIBUTING.md states must not be replaced by a
hand-picked subset.

.github/workflows/build.yml runs the canonical verifier on every push and
pull request across a Linux Python 3.10-3.13 matrix plus a Windows
clean-room job, and uploads machine-readable evidence as artifacts.
CodeQL, dependency review, secret scanning and OpenSSF Scorecard run as
separate PR workflows.
https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/main/.github/workflows/build.yml

CONTRIBUTING.md, section "Tests for new functionality", states the policy that decision-affecting changes must ship with a failing-then- passing test.

the most recent major changes carry their tests. The v0.11.0
AgenticFi policy engine shipped with 31 scenario cases and 13 receipt-mutation
cases; the evidence-axis and freshness work shipped with
tests/test_freshness_policy_receipts.py. See
research/AGENTICFI_EVALUATION_REPORT.md for the enumerated coverage.

the policy is documented in CONTRIBUTING.md, which is the instructions file for change proposals.

The project runs ruff as a linter over the entire codebase as part
of the single canonical gate python -m tools.verify, which CI executes on
every push and pull request. Separately, the clean-install packaging smoke
test sets warnings.simplefilter("error"), so any import-time warning fails
the build, and CodeQL runs on every push, pull request and weekly schedule.

The verifier fails on any ruff finding, so a warning cannot be carried on the default branch. CI enforces this as a merge gate.

The primary developer applies the criterion's design principles and has
documented them for this system in docs/security/THREAT_MODEL.md, which
enumerates assets, trust boundaries, threats, controls and residual risks.
The applied principles are visible in the design: least privilege (CI
workflows declare permissions: contents: read); fail-safe defaults (the
policy engine returns review_required or insufficient_evidence rather than a
verdict when the evidence chain is incomplete); complete mediation (every
decision re-reads the evidence rather than trusting a cached verdict);
economy of mechanism (server.py is a thin composition root; the policy core
is deterministic and side-effect-free); and an explicit, minimal trust
boundary (the system holds no keys, submits no transactions, and
evaluate_action always returns execution_authorized=false).
https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/main/docs/security/THREAT_MODEL.md

The primary developer knows the common error classes for this kind of
software and the counters applied here. The system is a Python data-processing
and MCP server with no database and no user authentication, so the dominant
classes are injection and untrusted-input handling, dependency/supply-chain
compromise, secret leakage, and incorrect trust in unvalidated data.
Counters in place: all caller input is schema-validated and treated as
untrusted (policy.py returns insufficient_evidence on malformed or unknown
input rather than proceeding); dependencies are fully pinned in constraints/
with pip-audit, dependency review and a CycloneDX SBOM as release gates;
gitleaks plus tools/secret_scan.py gate on secrets; and CodeQL runs on every
push and pull request. THREAT_MODEL.md records the residual risks.

The only cryptographic mechanism used is SHA-256 (FIPS 180-4), a publicly published and expert-reviewed hash function, applied to canonical JSON for artifact checksums and tamper-evident decision receipts.

The project does not implement cryptography. It calls Python's standard-library hashlib. No cryptographic primitive is reimplemented.

SHA-256 via CPython's hashlib is fully implementable with FLOSS; no proprietary cryptographic component is required.

N/A: the project generates no cryptographic keys and performs no key agreement. SHA-256 has no keylength parameter.

SHA-256 is not a broken algorithm and no cipher mode is used. MD4, MD5, single DES, RC4 and Dual_EC_DRBG do not appear in the codebase.

SHA-1 is not used anywhere; SHA-256 is the sole hash. No SSH CBC mode or comparable weak construction is present.

N/A: the project implements no key agreement protocol. It is offline decision support with no network protocol of its own.

N/A: the project stores no passwords and authenticates no external users. SECURITY.md records that the asserted audit identity in a receipt is not authenticated by CBSR.

N/A: the project generates no cryptographic keys or nonces. Receipt identifiers are derived deterministically from a SHA-256 digest of the canonical payload, by design: identical inputs must produce byte-identical receipts on replay.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Distribution is over HTTPS exclusively (GitHub, GitHub Pages, PyPI). Release
artifact digests are recorded in SHA256SUMS and RELEASE_MANIFEST.json inside
the version-controlled repository and are verified by the canonical verifier;
no hash is fetched over plain http. Release workflows generate GitHub build
provenance attestations (.github/workflows/release-provenance.yml).

There are no known unpatched vulnerabilities of medium or higher severity. pip-audit runs as part of the canonical verifier on every push and pull request across the Python 3.10-3.13 matrix, its result is committed as dist/pip-audit.json, and SECURITY.md makes a known unreviewed vulnerability an explicit release hard stop.

SECURITY.md commits to acknowledging a complete private report within 3 business days and triaging within 7, and blocks any release on a known unreviewed vulnerability. No critical vulnerability has been reported to date.

The repository contains no credentials. Two independent gates enforce this:
gitleaks runs on pull requests (.github/workflows/security.yml) and
tools/secret_scan.py runs inside the canonical verifier, so a detected secret
fails the build locally and in CI. SECURITY.md makes a detected secret a
release hard stop. The system holds no keys by design and custodies nothing.

CodeQL analyses the Python codebase on every push, every pull request, and on
a weekly schedule (.github/workflows/codeql.yml), so it is applied before any
proposed release. Results are uploaded to GitHub code scanning. Dependency
review and OpenSSF Scorecard run alongside it.
https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/main/.github/workflows/codeql.yml

CodeQL's default Python query suite includes rules for common vulnerability classes in the language and environment, including injection, path traversal and unsafe deserialization.

CodeQL runs on every pull request, so a medium-or-higher finding surfaces before merge and is fixed before release. SECURITY.md makes a known unreviewed vulnerability a release hard stop. No such finding is currently outstanding.

CodeQL runs on every push and every pull request, plus a weekly scheduled scan.

The canonical verifier exercises the built software dynamically before any
release: it builds the wheel twice, installs it into a clean environment
outside the repository, imports it with warnings raised as errors, and calls
all six AgenticFi capabilities. On top of that it runs 31 table-driven policy
scenarios, 13 receipt-mutation tamper tests, an explicit negative-test harness
(tools/run_negative_tests.py), and two end-to-end pilots that must replay
byte-identically.

N/A: the project produces no software written in a memory-unsafe language. The implementation is pure Python.

The packaging smoke test sets warnings.simplefilter("error"), turning every runtime warning into a failure during dynamic analysis, and the negative-test harness asserts that malformed, unknown and out-of-mandate inputs produce the correct refusal rather than a verdict. These checks run in the verifier and in CI, not in a production build.

Any failure in the canonical verifier including every dynamic gate above
blocks the build and therefore the release. RELEASE_CHECKLIST.md and
SECURITY.md make this explicit.