presidio-hardened-x402

https://github.com/presidio-v/presidio-hardened-x402/blob/main/SECURITY.md#supported-versions states which versions are supported and for how long; REPO/blob/main/SEMVER.md documents the upgrade path and what counts as a breaking change.

GitHub Issues.

https://github.com/presidio-v/presidio-hardened-x402/blob/main/SECURITY.md#reporting-a-vulnerability — reporters are credited by name in the published advisory and the CHANGELOG entry unless they request anonymity.

https://github.com/presidio-v/presidio-hardened-x402/blob/main/SECURITY.md#reporting-a-vulnerability — private GitHub Security Advisory intake, acknowledgement within 5 business days, patch target within 30 days.

https://github.com/presidio-v/presidio-hardened-x402/blob/main/CONTRIBUTING.md#style names ruff as the required style/lint tool; config in pyproject.toml.

ruff check and ruff format --check run in CI on every PR (FLOSS enforcement).

Pure-Python package; no compiler/linker, so CC/CFLAGS/LDFLAGS do not apply.

Pure Python; no compiled artefacts, so there is no separable debug information.

No recursive make/subdirectory build.

Wheels/sdists are built via the standard PEP 517 flow against a fully pinned dependency graph (uv.lock) on GitHub-hosted runners with SHA-pinned Actions. We do not yet claim bit-for-bit reproducible/hermetic builds — that is a stretch target beyond the SLSA L3 baseline we ship — but the build is deterministic from pinned sources.

Standard install from PyPI: pip install presidio-hardened-x402 (also uv).

Standard install from PyPI: pip install presidio-hardened-x402 (also uv).

https://github.com/presidio-v/presidio-hardened-x402/blob/main/CONTRIBUTING.md#local-verification — python -m venv .venv && .venv/bin/pip install -e ".[dev]" installs everything needed to build and test.

Dependencies are listed machine-readably in https://github.com/presidio-v/presidio-hardened-x402/blob/main/pyproject.toml and fully pinned in uv.lock; a CycloneDX SBOM is generated per release in CI.

All reused components are standard PyPI packages installed via pip/uv (no vendored copies); Dependabot tracks updates.

All reused components are standard PyPI packages installed via pip/uv (no vendored copies); Dependabot tracks updates.

Dependencies are kept current (Dependabot + dependency floors), the public API is tracked in SEMVER.md, and the code does not rely on deprecated FLOSS functions where alternatives exist.

GitHub Actions runs the full pytest suite on every push and pull request, across Python 3.10–3.13, plus the partner conformance suite — see https://github.com/presidio-v/presidio-hardened-x402/blob/main/.github/workflows/ci.yml. Each run produces a pass/fail report visible on the commit and PR (Checks tab), and a failure blocks merge via branch protection.

The written contribution policy requires a regression test with every bug fix ("Bug fixes must include a regression test that fails before the fix and passes after it" — https://github.com/presidio-v/presidio-hardened-x402/blob/main/CONTRIBUTING.md#tests). This is applied in practice: e.g. the replay-fingerprint precision collision fix (PR #89) added a TestCanonicalAmount class plus a high-precision collision regression test. Well over 50% of bugs fixed in the last six months have accompanying regression tests.

The FLOSS test suite (pytest + pytest-cov) is run in CI with --cov-fail-under=90, and the same floor is set in pyproject.toml ([tool.coverage.report] fail_under = 90). Statement coverage is therefore held at ≥90%, above the 80% threshold, and a drop below the floor fails the build.

There is a formal written policy that new functionality must ship with tests: "Test policy: any change that adds or modifies functionality must ship with tests in the same pull request" — https://github.com/presidio-v/presidio-hardened-x402/blob/main/CONTRIBUTING.md#tests. It is enforced in review and by the coverage gate.

The policy is in the contribution instructions themselves (CONTRIBUTING.md).

Rule sets E, F, W, I, N, UP, S, B, A, C4, SIM, TCH — well beyond defaults, includes bandit security rules (S). Only S101, S603, S607 are excluded, with rationale.

The library applies established secure design principles:

• Fail-safe defaults / secure by default: the payment pipeline fails closed (any control that raises blocks the payment), and PII redaction is on by default (pii_action="redact").
• Least privilege: the library never holds wallet signing keys — PaymentSigner is an abstract protocol, so key custody stays with the caller; evidence-signing keys are supplied by the deployment, never embedded.
• Complete mediation: every payment is checked against spending policy, replay fingerprinting, and PII filtering before it can leave the process toward the network or chain (pre-execution enforcement).
• Defense in depth: independent controls (policy, replay guard, PII filter, multi-party authorization, HMAC-chained audit log, signed evidence) each mitigate a distinct threat; remote screening keeps a local regex backstop so a remote failure fails safe.
• Least common mechanism / input validation: all payment metadata from the calling agent is treated as untrusted and validated (e.g. canonicalisation byte-stability contracts, action_ref rejecting empty entity sets).
• Economy of mechanism: cryptography uses vetted standard-library / cryptography primitives (SHA-256, HMAC-SHA256, ed25519) rather than bespoke implementations.

See https://github.com/presidio-v/presidio-hardened-x402/blob/main/ARCHITECTURE.md and https://github.com/presidio-v/presidio-hardened-x402/blob/main/SECURITY.md.

No SHA-1 and no CBC-mode dependency in default paths.

The library does not expose a user-facing cryptographic-algorithm negotiation surface; its integrity and signature primitives are pinned to current strong choices (SHA-256 and HMAC-SHA256 for digests/fingerprinting/audit chaining, ed25519 for evidence signatures). Algorithm agility is instead provided at the record-format layer: the emitted evidence and decision records are explicitly versioned (payment-decision@1, evidence-ref@1, capability-grant@1) and the canonicalisation/digest functions are byte-stability contracts, so replacing an algorithm is a versioned format change (bump the record version) rather than a runtime switch. Runtime crypto-suite negotiation does not apply to this library's design.

All keys and secrets are supplied to the library from outside the source tree and can be rotated without any code change. The replay-fingerprint and audit-chain keys are read from environment variables (PRESIDIO_X402_FINGERPRINT_KEY, PRESIDIO_X402_CHAIN_KEY); evidence-signing keys and verification trust stores are provided by the deployment as separate files/config, never embedded in code. None are hard-coded, none live in the config that carries non-secret settings, and the log sink scrubs key and token material (install_log_redaction) so credentials do not leak into logs. Because the library is pure Python configured at runtime, updating or replacing any credential requires no recompilation.

All network communication the library performs uses TLS (HTTPS). The hosted-screening client and the remote audit sinks (S3, Splunk HEC, Datadog) enforce TLS with certificate verification; there is no plaintext HTTP, FTP, telnet, or legacy SSL/TLS path, and none can be enabled by configuration. On a remote-screening failure the library falls back to the local regex backstop rather than to an insecure channel, so it fails safe. The abstract PaymentSigner and the payment rail itself are supplied by the integrator and are out of the library's transport scope.

Where the library uses TLS (hosted-screening client and the remote audit sinks), it relies on the platform TLS stack via the hardened HTTP client reused from presidio-hardened-requests, which negotiates TLS 1.2 or later. No SSLv3/TLS 1.0/1.1 path is offered or configurable.

Where the library uses TLS (hosted-screening client and remote audit sinks), certificate verification is on by default via the hardened HTTP client reused from presidio-hardened-requests; verification is never disabled and there is no verify=False path or configuration option to turn it off.

The library uses the hardened HTTP client (reused from presidio-hardened-requests), which completes the TLS handshake and certificate verification before any request headers or body are transmitted; verification is on by default and cannot be disabled. Authorization/API-key headers to the hosted-screening service and audit sinks are therefore only sent over an already-verified TLS connection. On verification failure the request fails closed and the local regex backstop runs instead, so no private header is sent over an unverified channel.

Releases are cryptographically signed and the process for obtaining/verifying keys is documented at https://github.com/presidio-v/presidio-hardened-x402/blob/main/SECURITY.md#obtaining-the-public-signing-keys: Sigstore build provenance (gh attestation verify), SSH-signed git tags with the public key in https://github.com/presidio-v/presidio-hardened-x402/blob/main/allowed_signers, and PEP 740 attestations on PyPI.

Every release is a git tag, SSH-signed with the org key and shown as Verified on GitHub.

All payment metadata arriving from the calling agent is treated as untrusted and validated before use (e.g. action_ref rejects empty entity-type sets; canonicalisation enforces byte-stability contracts). See ARCHITECTURE.md#trust-boundaries.

TLS enforced on all network egress; bounded audit buffers; import-time log redaction of secrets; SHA-pinned GitHub Actions; digest-pinned Docker base and hash-pinned spaCy model.

The security assurance case is documented at https://github.com/presidio-v/presidio-hardened-x402/blob/main/ASSURANCE.md. It contains all four required parts: (1) the threat model — assets, adversaries (compromised/overspending agent, replay, spoofed SLO trigger, audit tampering, metadata leakage) and their mitigations, with per-version tables in SECURITY.md and full rationale in PRESIDIO-REQ.md; (2) clear identification of trust boundaries (agent→library untrusted input, library→chain irreversible egress, library→screening/audit network egress, out-of-scope signing-key custody); (3) an argument that secure design principles are applied (fail-safe defaults, complete mediation, least privilege, defense in depth, economy of mechanism); and (4) an argument that common implementation weakness classes are countered (input validation/injection, memory safety, crypto misuse, hard-coded secrets, insecure network/SSRF, replay, audit tampering, unsafe deserialization, vulnerable dependencies), each mapped to a control and reinforced by CodeQL, bandit, Scorecard, and an independent v0.8.0 security review.

CodeQL's security query suite and bandit both target common vulnerability classes; ruff's S rule set adds a third layer in-line.

Pure Python; no memory-unsafe language in the codebase.