Vulnerability disclosure

Reporting

Email security@z4j.com. We do not publish a PGP key. If the details should not travel in plain email, send only a contact request first; we will arrange a private channel and publish its fingerprint before asking you to send the report.

Include:

• Description of the issue.
• Steps to reproduce (minimal repro preferred).
• Affected version(s).
• Your contact info for follow-up.

Please do not

• File a public GitHub issue.
• Post to public mailing lists / chat rooms / social before we've had time to respond.
• Demonstrate the issue against systems you don't own.

Safe harbor

We follow the disclose.io baseline. You may research in good faith - we won't pursue legal action for:

• Testing on your own self-hosted brain.
• Testing against our public demo instance at demo.z4j.com.
• Accidental access to data during good-faith research - with prompt disclosure.

We will not take legal action against researchers who:

• Stop testing on discovery.
• Don't exfiltrate data beyond what's needed to prove the bug.
• Don't disclose publicly before our patch is available.

Response timeline

Event	Target
Acknowledge receipt	48 hours
Initial triage	5 business days
Fix a confirmed critical issue	7 days from confirmation
Fix any other confirmed issue	30 days from confirmation
Coordinated public disclosure	90 days from your first report

For a critical issue under active exploitation, we disclose as soon as a fix is available and you consent. Triage and fix time come out of our 90-day window, not yours.

Credit

With your permission, we credit you by name or pseudonym in the release notes and any published advisory. We do not offer a bug bounty.

Supported versions

Security fixes are issued for the current minor line of the umbrella z4j package. A fix is backported to the previous minor only when the issue is severe enough that operators on that line cannot upgrade promptly; older minors receive none.

Release integrity

What you can check before you install:

• Packages. Every PyPI release of every z4j package has a CycloneDX JSON SBOM of its locked dependency closure (<package>-<version>.cdx.json) attached to the GitHub Release beside the wheel and the sdist.
• Image. z4jdev/z4j is signed keylessly with cosign and carries a build provenance attestation and an SPDX SBOM attestation; the Docker guide has the commands.
• Helm chart. Each published chart digest is signed keylessly; the Kubernetes guide has the verify command.
• Dependencies. The release gate scans the locked dependency sets and the image. An advisory that cannot be fixed yet is recorded as a dated exception with a written reason and an expiry, mirrored in the dependency policy, and a release test fails when one lapses.
• Contributions. Every commit in a pull request carries a Developer Certificate of Origin sign-off (git commit -s), enforced by a check on the repository. There is no CLA.

Scope

In scope:

• The brain (z4j) and every official z4j-* package on PyPI.
• The wire protocol.
• Official z4jdev/* Docker images.
• Our hosted infrastructure at z4j.com, docs.z4j.com, and demo.z4j.com.

Out of scope:

• Third-party queue engines (report to them).
• Third-party infra (Postgres, Redis, etc.) - report upstream.
• Denial of service that requires the attacker to spend excessive resources.

A cheap resource-exhaustion path available to one project or one low-privilege user against a shared brain is in scope. The product enforces per-project ceilings and request throttles; a practical bypass of those boundaries is something we want reported.

Published advisories

Published advisories appear under z4jdev/z4j security advisories with a GHSA ID and, when GitHub's CNA assigns one, a CVE ID. Security fixes shipped without a coordinated advisory remain recorded with their fixed-in versions in the project CHANGELOG.md.

What we know about and have not fixed

Findings we raise ourselves and then decide to defer get no response clock, because nobody is waiting on us. They get a public entry instead, with the mitigation available today and what has to be true before it comes off the list. One is open now: the in-database boundaries do not hold against a role that can write their tables. See threat model and HMAC audit chain.