Security vulnerability disclosure policy

Diátaxis quadrant: Reference. Audience: security researchers reporting a vulnerability in humanymous Gate, and evaluators performing security due diligence.

This page is a coordinated-disclosure policy for humanymous Gate itself — the reverse-proxy enforcement layer, its detection engine, control plane, admin plane and Ledger. It tells a researcher how to report a suspected vulnerability, what a good report contains, and what testing is and is not authorized.

Reporting a vulnerability in humanymous itself (this project)? Use the project’s own policy — SECURITY.md and the live /.well-known/security.txt (contact [email protected]). The page below is a template you adapt for your own Gate deployment, not the project’s intake.

Important: This page is a template. humanymous Gate is a reference implementation, not a production-hardened build (see Production vs reference). Every operator or vendor who deploys Gate is responsible for filling in the real contact address, PGP key, response commitments and hosted security.txt before pointing researchers at them. Fields marked <placeholder> and lines marked TODO(verify) MUST be completed by the operator; do not treat the sample values below as live.

Scope

This policy governs coordinated (responsible) disclosure of security vulnerabilities in a humanymous Gate deployment that you operate, or one you are explicitly authorized in writing to test.

In scope for a report:

  • The Gate edge and control plane on the public listener (default :8444), including the client-facing /__hmn/ endpoints (/__hmn/session, /__hmn/collect, /__hmn/loader.js, /__hmn/csp-report) and the challenge / proof-of-work interstitial.
  • The separate authenticated admin listener (default 127.0.0.1:8445 (loopback)), the Admin API under /__hmn/admin/, and the Ledger SPA at /__hmn/admin/console.
  • The detection engine (the seven-stage pipeline), the verdict pipeline (ALLOW / CHALLENGE / DENY) and enforcement rules, where a flaw crosses a documented security boundary — for example a control-plane injection, an authentication or role-based access control bypass, an audit-log integrity break, or a verdict-token forgery not already described as an accepted residual.
  • The tamper-evident audit log and its verification logic, key sealing (-keystore / HMN_UNSEAL), and the cryptographic-erasure (crypto-shred) path.

Note: A verdict of ALLOW, CHALLENGE or DENY that you disagree with is not by itself a vulnerability. Detection is heuristic and bounded: client and network signals alone cannot reliably separate coherent browser or human-assisted automation from legitimate traffic, and safe methods on non-strict routes have a documented fail-open residual. These are stated design limits, not defects. See enforcement rules, verdicts and signal reference. If you believe you can bypass an enforcement rule documented as high-confidence, that is in scope — report it.

How to report

Report privately to the security contact and give the operator a chance to remediate before any public disclosure.

  • Security contact: <security-contact> — an email address or intake form the operator publishes.

    TODO(verify): Fill in the real reporting address (for example a dedicated security@<your-domain> mailbox or a hosted intake form URL).

  • Encryption: <pgp-key-fingerprint> — a PGP key or equivalent for sending sensitive details.

    TODO(verify): Publish a PGP key fingerprint and the key itself, or another supported encrypted channel.

The conventional, machine-readable home for these details is a security.txt file served at /.well-known/security.txt (per the security.txt convention). Publish one so researchers can find your contact without guessing.

security.txt template

Serve this at https://<your-domain>/.well-known/security.txt. Replace every placeholder with a real value before publishing.

Contact: <security-contact>
Expires: <YYYY-MM-DDThh:mm:ssZ>
Preferred-Languages: <e.g. en, ko>
Policy: <URL of this published disclosure policy>
Encryption: <URL of your PGP key>
Acknowledgments: <URL of your researcher acknowledgments page, optional>

TODO(verify): Set each field. Expires MUST be a future date and should be refreshed before it lapses; Contact MUST match the address above; Policy should point at your published copy of this page.

What to include in a report

A report that lets the operator reproduce and triage quickly should contain:

  • A clear description of the vulnerability and the security impact you believe it has.
  • The affected component and version — the Go module is github.com/modootoday/humanymous; include the build or commit you tested and the relevant listener (edge :8444 or admin :8445).
  • Exact reproduction steps: the request(s) sent, any required configuration or preset (off / monitor / balanced / strict / attested), and the observed versus expected behavior.
  • Proof-of-concept material — a request you can curl, a script, or a log line to expect — kept minimal and non-destructive.
  • Any prerequisites (an admin token role, a specific route policy, a keystore state) needed to trigger the issue.
  • Your assessment of severity and, if known, a suggested remediation.

Note: Do not include third-party personal data or another operator’s production data in a report. If your proof-of-concept incidentally captures a subject identifier, redact it — Gate stores identifiers only as per-subject pseudonyms by design, and your report should not reintroduce raw ones.

Coordinated-disclosure expectations

  • Report privately first. Send the details to the security contact before any public writeup, and give the operator reasonable time to remediate.

  • Response and remediation timeline. <response-sla> — the operator’s target for acknowledging a report and for a coordinated disclosure window.

    TODO(verify): State the acknowledgment target (for example “within N business days”), the triage and fix timeline, and the coordinated public-disclosure window you commit to.

  • Coordinate the public disclosure date with the operator once a fix is available or a mitigation is in place. Credit for reporters is at the operator’s discretion.

    TODO(verify): State whether the deployment offers acknowledgments, a hall of fame, or any bounty, and the terms.

Good-faith safe harbor

Testing conducted in good faith and in compliance with this policy — against systems you operate, or a deployment you are explicitly authorized in writing to test — is welcomed, and the operator will not pursue or support action against you for such testing.

Warning: This safe harbor is not authorization to test third parties or anyone else’s deployment. humanymous Gate is a defensive product; its red-team and self-validation tooling targets your own deployment only. Testing a Gate instance you neither operate nor have written permission to test is outside this policy, is not authorized, and may be unlawful. See Self-validation and red-team testing.

Good-faith testing means, at a minimum: you stay within scope; you avoid privacy violations, data destruction, and degradation of service to others; you use only the access necessary to demonstrate the issue; and you stop and report as soon as you confirm a vulnerability rather than pivoting deeper.

TODO(verify): The operator should reconcile this safe-harbor language with their own legal terms and jurisdiction before publishing; the wording here is a template, not legal advice.

Out of scope

The following are generally not accepted as vulnerabilities under this policy:

  • Detection outcomes that reflect documented limits: the coherent-automation detection boundary (internally consistent browser automation or human-assisted automation), the accepted fail-open residual for safe Hypertext Transfer Protocol methods on non-strict routes, and the tamper-evident (not tamper-proof) in-window residual for audit records written after the last signed checkpoint.
  • Reports that a verdict was “wrong” without a concrete security impact — false positives and false negatives are handled as tuning and triage, not as disclosures. A privacy browser, extension, or old device being challenged is expected behavior, not a defect.
  • Findings that only apply to the reference build’s explicit production responsibilities rather than a real deployment — for example the self-signed in-memory dev certificate, bearer dev tokens instead of mutual Transport Layer Security/SSO, in-process (single-node) verdict and ban state, or the absence of automated key rotation. These are documented gaps a production deployment is expected to close; see Production vs reference.
  • Volumetric denial-of-service, physical attacks, and social-engineering of the operator’s staff.
  • Reports generated purely by automated scanners with no demonstrated, reproducible impact.
  • Any testing against a deployment you do not operate and are not authorized to test.

TODO(verify): The operator may add deployment-specific out-of-scope items (for example specific hostnames, staging environments, or third-party services fronted by Gate).