@takk/bayesconsensus is a stable (1.0.0) library that resolves disagreement across a fleet of agents with the Dawid-Skene model. We take security reports seriously and aim to acknowledge each one within two business days.

Each published version follows strict SemVer (see SPEC.md and .github/RELEASING.md). Only the latest minor of the current major receives security patches; an older major receives critical-CVE fixes for 6 months after the next major lands.

Please do not file public GitHub issues for security problems. Send reports to davcavalcante@proton.me (preferred) or say@takk.ag (Takk relay), with the subject line beginning [SECURITY].

Include, at minimum:

• Affected version (npm ls @takk/bayesconsensus).
• Reproduction steps or a minimal proof-of-concept.
• Impact assessment (what an attacker can achieve).
• Any suggested mitigation.

If your report involves a vulnerability in a third-party peer dependency, please also link the upstream advisory (CVE, GHSA, etc.) so we can coordinate the disclosure.

PGP / signed reports are welcome but not required. If you need an out-of-band channel, ask in the first message and we will propose one.

1. Acknowledgement within 2 business days.
2. Triage and severity assignment within 7 days.
3. Fix targeted for the next release; critical issues ship as an out-of-band patch on the affected minor.
4. Coordinated disclosure: the reporter is credited in the changelog and advisory unless they request anonymity.

Findings in any of the following are in scope:

• Input boundary. Any path that lets the adapter or the loaders ingest anything beyond votes (item, agent, label), any way to smuggle a non-string identifier or label past the defensive parser in parseConsensusInput, or any prototype-pollution vector through a crafted vote object.
• Audit integrity. Any way to make verifyChain return valid: true for a chain that was altered after sealing, any hash-chain construction that lets a forged entry pass, or any way to defeat the SHA-256 chaining. The seal is an integrity seal, not a signature: it proves a log was not altered after sealing, not who produced it, and that boundary is documented, not a vulnerability.
• Loaders and snapshots. Path traversal or any way to make the JSON and CSV loaders in @takk/bayesconsensus/node read outside the path you pass them, or any malicious snapshot or votes file that bypasses the loader and fromSnapshot validation and yields an impossible model state, a non-finite parameter, or prototype pollution, so that a later fit runs on corrupted state.
• Numeric integrity. Any way to drive a numerically invalid posterior (NaN or Infinity in a confidence, a confusion-matrix entry, or the class prior) past the Dawid-Skene E-step or M-step, or any edge case in the log-space normalization, the Dirichlet smoothing, the convergence test, or the calibration simulation that produces a confidence outside (0, 1], a distribution that does not sum to one, or a non-terminating fit.
• Supply chain. Tarball contamination, compromised npm scope, or a published artifact whose provenance attestation does not match the source commit.

• The security or correctness of the agents, judges, or models that produced the votes you feed it; BayesConsensus aggregates the votes you bring it, it never sees or processes the prompts, models, or content behind them.
• The correctness of the votes you feed it. Garbage votes produce a garbage consensus; that is a usage concern, not a vulnerability.
• Statistical mis-modeling when the assumptions are violated (agents whose errors are correlated because they share training data, or a uniformly weak fleet with no reliability signal). The library documents these limits and ships measured calibration as a diagnostic; an unhelpful consensus under violated assumptions is expected behavior, not a defect.
• The decision to trust a low-confidence verdict. The confidence is reported on every verdict; acting on a weak one without escalation is a usage decision.
• Theoretical attacks against the cryptographic primitive used for the audit chain (SHA-256) and the Web Crypto implementation of the host runtime; report those upstream.

• Zero required runtime dependencies. The attack surface from transitive dependencies is eliminated. Every @takk sibling is an optional peer dependency you install explicitly.
• Node-free core. The core, including the audit seal, uses the Web Crypto API (globalThis.crypto.subtle) rather than node:crypto. Only the optional @takk/bayesconsensus/node loaders touch the Node standard library, and they only read the files you point them at.
• Provenance. Every release is published with npm publish --provenance (SLSA attestation by GitHub Actions). Verify with npm view @takk/bayesconsensus@<version> --json | jq .dist.attestations.
• Lockfile committed. pnpm-lock.yaml is tracked in git for reproducible installs.