Bluefield is a provenance and cryptography project: its whole value is that a signed capture (and its optional transparency anchor) means what it claims to mean. We take reports against that guarantee seriously and want researchers to have a clear, safe path to tell us when it doesn't hold.

Please do not open a public issue or pull request for a suspected vulnerability. Public disclosure before a fix puts users at risk.

Use either private channel:

• GitHub private advisory (preferred): the repository Security → Report a vulnerability tab, which opens a private thread with the maintainers.
• Email: security@bluefields-data.com. If you'd like to encrypt the report, say so in a first (contentless) email and we'll share a current public key; we'd rather exchange a fresh key than publish a stale fingerprint here.

A good report includes:

• the affected component and version/commit (e.g. @bluefields/attest@0.2.0, @bluefields/cli@0.2.1, or a commit SHA);
• a description of the impact and the security property you believe is broken;
• a minimal, self-contained proof of concept (a failing verify, a forged bundle that verifies, a URL that reaches an internal address, etc.);
• your environment (OS, Node version) where it matters.

You may report anonymously. If you'd like credit, tell us the name/handle to use.

We are a small team; these are the targets we hold ourselves to for a report that lands through the channels above.

If we go quiet past these windows, escalate by replying on the advisory thread — silence is a bug on our side, not a "no."

We will not pursue or support legal action against you for good-faith security research that respects this policy. Specifically, if you:

• make a good-faith effort to avoid privacy violations, data destruction, and service degradation;
• only interact with accounts, stores, and keys you own or have explicit permission to test — never another user's captures, keys, or data;
• do not run automated scanners, load tests, or brute force against any Bluefield-hosted service, and stop at the first confirmation of a flaw;
• give us reasonable time to remediate before any public disclosure;

then we consider your research authorized, we will work with you, and we will not report you or ask a third party to. If in doubt about whether an action is allowed, ask first via the channels above. This safe harbor is ours to give for Bluefield's own code and services; it does not authorize you to attack third parties (e.g. the public transparency logs, proxy providers, or an LLM API).

Because this is a provenance/crypto project, the interesting boundaries are the ones below. In-scope, high-priority classes:

• Attestation forgery / verification bypass — a manifest or bundle that verifyBundle / verifyManifest / verify.ts accepts but should reject: wrong-key acceptance, unknown-keyId acceptance, algorithm confusion, canonicalization mismatches, or trusting a bundle's embedded key without the explicit --trust-embedded / trust-store opt-in.
• Transparency-anchoring verification bypass — an AnchorRecord that verifyAnchor accepts but that the pinned log did not actually attest: inclusion-proof / checkpoint / SET forgery, unpinned-log acceptance, an OTS record verifying without the explicit acceptOtsConsistencyOnly opt-in, or an anchor that verifies against a manifest it does not commit to.
• SSRF / egress abuse — a URL (scrape target, anchor log/calendar override, sitemap child) that reaches a private, link-local, or cloud-metadata address, or a redirect that smuggles egress to one.
• Key-material disclosure — the local signing private key (~/.bluefield/keys) reaching a log line, error message, stdout, exported bundle, or manifest; or weak/ predictable key generation.
• Secret leakage — any API key, proxy credential, or token written to a log, error body, or committed artifact.
• MCP server — input handling in bf mcp that lets a caller escape the local store, read arbitrary files, or execute commands.

Out of scope (report only if you can show real impact beyond these):

• Attacks that require an already-compromised local machine or an attacker who already has read access to ~/.bluefield/keys (that file is the trust root for a single-user tool — protect it like an SSH key).
• The documented DNS-rebinding window for an operator-overridden anchor log URL when the deployment has not injected a connect-time-revalidating SSRF fetch client (AnchorOptions.fetchImpl / validateUrl). This is a known, documented composition requirement, not a defect in the library; a bypass of the pinned-default logs, or of the built-in gate itself, is in scope.
• Denial of service via absurdly large or deeply nested inputs that are already bounded by the documented caps (unless you defeat a cap).
• Missing hardening headers / TLS config on marketing pages, and findings on third-party services we don't control.

To save everyone time, a Bluefield signature proves this key signed this manifest; a Bluefield anchor proves this (manifest, signature) pair existed in a public log at the attested time. Neither, alone, proves the captured page was authentic content from the origin, nor that the signing key is one you should trust — identity comes from the trust store you verify against, and full assurance requires composing both checks (verifyBundle and verifyAnchor). Reports that a proof "doesn't prove X" where X is outside these claims are welcome as documentation feedback, but aren't vulnerabilities.

Security fixes target the latest published minor of each package. The v1 attestation manifest and v1 anchor-leaf formats are frozen contracts: fixes preserve them, and old proofs are expected to verify indefinitely. Breaking security changes ship as a coexisting versioned format, never an in-place edit.

Thank you for helping keep Bluefield honest.