Security fixes land in the latest published release. Before 1.0.0 that is the latest 0.x release. From 1.0.0 it is the latest release of the current major, and the stability contract defines what a release within that major may change. Wire compatibility is governed by the protocol package's contract-major discipline — this library's releases track it.

The properties a report is measured against (the long form is the security model):

• The library never solicits, processes, or retains private key material — custody lives entirely behind the caller's key-handle callbacks (the contract; a handle that embeds key bytes in its term has chosen that posture itself — see security.md § Trust boundaries).
• Every signature is verified against the handle-resolved public key before success — a wrong-key sign is :signing_failed, never a false success.
• Errors are closed atoms and telemetry metadata is value-free: neither channel can carry key material, message bytes, or report content. A defect that leaks values into either channel is a security defect, not a cosmetic one.
• Key identity (key_id and public_key) comes from one handle call for grants, anchors, key transitions and content assertions; caller-supplied key ids are ignored.
• The library depends only on the public protocol package — never the authority runtime, never a transport, never an HTTP client/server (enforced by the dependency-direction wall).

Report privately through GitHub: open the repository's Security tab and choose Report a vulnerability, or go straight to the private report form (you need to be signed in to GitHub). Only you and the maintainers see the report. Do not open a public issue containing an exploit, credential, private key, or unreleased vulnerability detail.

A report should include:

• the affected version or commit;
• the violated property (the invariant above, in your own words);
• a minimal, VALUE-FREE reproduction (no real keys, no production report content);
• the expected security outcome.

Every v* tag push runs the supply-chain workflow: it builds the exact Hex archive through the full gate battery, records its SHA-256 in SHA256SUMS, and attests build provenance (SLSA) plus a CycloneDX SBOM via GitHub attestations. To verify a published release against that evidence:

# 1. Download the release evidence artifact (the workflow run for the tag)
#    and the tarball, then compare checksums:
sha256sum -c SHA256SUMS

# 2. Verify the attestations against the subject digest (requires the
#    gh CLI and the workflow run's artifact):
gh attestation verify <tarball> --repo baselabs/bounded_authority_report_adapter

# 3. Cross-check against hex.pm's published checksum for the release
#    (hex.pm shows the archive checksum on the version page — it must
#    equal the SHA-256 in SHA256SUMS for the same bytes).

Locally, before any release, mix ci runs the same reproducibility gate the workflow uses: two cache-isolated builds of the exact archive must agree byte for byte.

We will acknowledge reports within 7 days and send status updates at least weekly until resolution, coordinating disclosure through the private advisory. This is a best-effort cadence from a small maintainer team, not a contractual SLA — urgent disclosures are handled faster when marked as such.