Report vulnerabilities privately through GitHub's private vulnerability reporting: Security → Report a vulnerability. This opens a draft GitHub Security Advisory (GHSA) that only the maintainers and you can see.

Do not open a public issue, pull request or discussion for a suspected vulnerability.

Please include the affected crate(s) and version(s), a description of the impact, and a minimal reproduction if you have one.

id_effect has one maintainer (see GOVERNANCE.md), so these are targets, not a contractual SLA:

If a fix needs longer, we tell you why and agree a new disclosure date with you. We credit reporters in the advisory unless you ask us not to.

Only published crates in the main workspace are covered (crates/*). The unpublished labs/ crates and the examples/ are not.

• The latest minor release line receives all fixes as patch releases.
• The previous minor receives fixes for high and critical vulnerabilities for 90 days after the newer minor is released. Then it is unsupported.
• Older lines are unsupported: upgrade using the migration guides in docs/.

The table above is updated with each minor release. The 1.0 release will define a longer-term support policy (docs/STABILITY.md).

For a confirmed vulnerability:

1. We work on the fix in the private GHSA (with a private fork if needed) and invite you to it.
2. We request a CVE through the GHSA when the issue warrants one.
3. We release patched versions of every supported line affected, then publish the GHSA.
4. We submit the advisory to the RustSec advisory database so cargo audit and cargo deny users are warned, referencing the GHSA (and CVE).
5. The CHANGELOG entry for the patch release names the advisory. Affected versions may be yanked from crates.io if they are dangerous to keep using.

Public history of releases that fix vulnerabilities. Finding ids (H high, M medium, L low) are those of the 2026-10-18 security review; THREAT-MODEL.md tracks every finding and its status (closed with its commit, or accepted with its reason).

Upgrade from 0.10.0 to 0.10.1 (CHANGELOG, "0.10.1 — Security patch"; migration: "0.10.1: stricter security defaults" in docs/MIGRATION-0.10.md). Every node of a mesh cluster must be upgraded together (handshake protocol version 2).

"pending": as of 2026-10-19 no GitHub Security Advisory for 0.10.1 is published (advisories). Each row gets its GHSA id and link when the advisory is published (step 3 of "Advisory publication").

• cargo deny check (deny.toml) runs in CI on every pull request and push to main: RustSec advisories, the license allow-list, banned crates and allowed sources. Every ignored advisory carries a written reason in deny.toml.

• cargo audit runs daily (.github/workflows/audit.yml).

• CI is pinned: every action by full commit SHA, the toolchain by version, Cargo.lock committed and builds --locked; workflows run with read-only default permissions (scripts/check-workflows.sh enforces this). Pull requests need a DCO sign-off (CONTRIBUTING.md).

• A release is a pushed v* tag; the publish workflow (.github/workflows/publish.yml, docs/RELEASING.md) checks that the tag equals every publishable version (it does not check a tag signature). It packages every crate with cargo package --locked, writes one CycloneDX SBOM per crate, and signs SLSA Build L3 provenance over those .crate and .cdx.json files with the slsa-github-generator (keyless, Sigstore). It publishes the same files to crates.io in dependency order with the CARGO_REGISTRY_TOKEN secret of the crates-io GitHub environment (handed to cargo on stdin; the token also creates a new crate on its first publish), checks each upload against its attested sha256, then downloads every crate from crates.io and runs slsa-verifier on it before it creates the GitHub Release. The long-lived token (S3) and the unsigned tag (S6) are accepted risks: the owner kept this flow (#118) on 2026-10-24 instead of the 0.11.0 trusted-publishing and signed-tag flow (THREAT-MODEL.md, "Accepted risks"). The release carries the .crate files, the SBOMs (<crate>-<version>.cdx.json) and the provenance (id_effect-<version>.intoto.jsonl). Verify a crate yourself with:

  curl -fsSLO https://static.crates.io/crates/id_effect/id_effect-<version>.crate
  gh release download v<version> -R Industrial/id_effect -p 'id_effect-<version>.intoto.jsonl'
  slsa-verifier verify-artifact id_effect-<version>.crate \
    --provenance-path id_effect-<version>.intoto.jsonl \
    --source-uri github.com/Industrial/id_effect --source-tag v<version>

  Releases 0.8.0 to 0.10.x carry GitHub build provenance attestations instead (verify those with gh attestation verify <crate>-<version>.crate -R Industrial/id_effect); they attest crates re-downloaded from crates.io, not the files CI built (finding S5, THREAT-MODEL.md).