outcome-receipts is an independent personal open-source project (Apache-2.0). The default path is offline, with no network listener, authentication, or durable client database and zero required runtime dependencies. An optional Bedrock extra adds one explicitly authorized model request for prose only. The security posture and current values are in docs/RESPONSIBLE-TECH-AUDITS.md.

outcome-receipts is pre-1.0, so only the latest minor on the latest major receives security fixes. A fix ships forward in a new patch release rather than a re-publish of an existing version.

When a 0.3.0 ships, 0.2.x security support ends and this table is updated in the same release.

Please do not open a public GitHub issue, pull request, or discussion for a security report.

Report privately, by either:

1. GitHub Security Advisory via Security -> Report a vulnerability on the repository (preferred; it keeps the report, fix, and GHSA linked), or
2. Email to ckellyreif@gmail.com with subject SECURITY: outcome-receipts.

Please include, as far as you can:

• the affected version or commit,
• a minimal reproduction or proof-of-concept,
• the impact you believe it has, and
• any suggested remediation.

If you want an encrypted channel, say so in a first low-detail email and we will arrange one.

In scope: the outcome_receipts package and CLI, the eval harness, the report/build/release workflows, and the dependency supply chain. Because the value of the tool is that a number cannot reach an export unless it traces to a receipt, an integrity bypass is in scope: a demonstrated way to export a number that binds to no receipt (defeating the fail-closed grounding gate), or a way to recover a suppressed cell, is a security report, not a normal issue.

Out of scope: the seeded synthetic example data contains no secrets or PII by construction. The correctness of a computed figure, a metric definition, or a report template is an eval, spec, or data issue rather than a vulnerability; file those as normal issues.

Release actions are pinned to commit SHAs, release artifacts carry a Sigstore build-provenance attestation and a CycloneDX SBOM, and publishing to PyPI uses Trusted Publishing (OIDC, no long-lived token). The CI token is least-privilege and does not persist credentials. make security and CI run pip-audit, npm audit, OSV-Scanner, gitleaks, Semgrep, and zizmor. Each is a separate target and every one runs on every commit, whatever the others did: they were once six lines of a single recipe, and make stops a recipe at its first failure, so one unfixable advisory in a development dependency silently cancelled the four scanners after it. Any finding a scanner reports still blocks merge; accepted findings are recorded, dated, owned and expiring, in waivers.yml, and a finding with no live waiver naming its exact advisory id, package, and severity fails the build. CodeQL covers Python and Actions; OpenSSF Scorecard enforces the portfolio score floors on its automatic triggers. release.yml re-runs the full make verify gate at the tagged commit before signing or publishing.

• Keep the default offline run; it has no network, auth, or persistence.
• Treat a report spec as trusted input. A metric is a SQL expression run over your loaded data slice, so run only specs you or a colleague wrote, the same way you would with any query file.
• Provide any future provider credentials by environment only; secrets are never committed.