Skip to main content

Reporting a Vulnerability

Do not open a public GitHub issue for security vulnerabilities

Use whichever of these two channels fits your workflow. Both are monitored.

  1. Email — hello@dgverse.in
  2. GitHub Security Advisory — the "Report a vulnerability" button under the Security tab of the HelixID repository. This opens a private advisory visible only to maintainers.

If you prefer encrypted reports, request the PGP public key in your initial email. There is no long-lived published key — for a small team, key rotation hygiene is worse than on-demand exchange.

What to include​

  • Affected component and version(s) — SDK, a specific package, a middleware, a policy
  • Reproduction steps with a minimal, self-contained example
  • Expected vs. observed behavior
  • Impact assessment — what can an attacker achieve?
  • Any suggested mitigation
  • Your name or handle as you'd like it credited (or "anonymous")

Redact cryptographic material, environment variables, and private network paths, or share them out-of-band.

What to expect​

StageTarget
Acknowledgement of your reportWithin 48 hours
Initial triage and assessmentWithin 7 business days
Mitigation plan for confirmed critical issuesWithin 7 days of triage
Security advisory and patch releaseCoordinated with the reporter
Public disclosureDefault 90 days from triage, or sooner if a fix ships

These are targets, not SLAs. If they can't be met, you'll hear about it rather than getting silence.

Coordinated disclosure​

After confirmed triage, maintainers work with you on a fix and a timeline. The default embargo is 90 days from triage confirmation — shortened if a fix ships and patched releases are available, or extended by mutual agreement for unusually complex issues such as protocol-level flaws requiring ecosystem coordination.

CVE assignment is requested where appropriate, and a GitHub Security Advisory is published with full details, workarounds, and patched versions. You are credited under your preferred name unless you ask otherwise.

If a vulnerability is already publicly known — disclosed elsewhere, under active exploitation, or accidentally leaked — email immediately so mitigation and communication can be expedited.

Scope​

In scope​

Vulnerabilities in any code in the repository, with priority for:

  • Credential verification — VC signature validation, proof formats, JWS/Ed25519 handling, JSON-LD canonicalization edge cases
  • Delegation chain validation — chain walking, depth enforcement, scope subset checking, delegation attack vectors
  • Revocation — status list bitstring handling, cache staleness leading to use-after-revocation, mirror node falsification
  • Key handling — generation, storage recommendations, serialization, constant-time violations, side-channel leakage
  • Policy integration — evaluation sandbox escape, input sanitization, policy bypass
  • Framework middleware — credential extraction, injection vectors, enforcement bypass in the LangChain and MCP integrations
  • Supply-chain concerns — tampered npm artifacts, typosquat risk on @helixid/* packages, release signing integrity
No proof-of-concept required for crypto-layer issues

Cryptographic and protocol-level flaws are explicitly in scope even without a working exploit. Timing-channel violations, constant-time lapses, incorrect proof format handling, or deviations from W3C VC 2.0 / DID 1.0 / StatusList specifications are all valid reports.

Out of scope​

  • Vulnerabilities in upstream dependencies — report to the upstream project. If the upstream refuses or is unresponsive and HelixID users are at material risk, get in touch and maintainers will help triage.
  • Issues in examples/ code that would not affect SDK users following documented patterns
  • DoS via unbounded policy input, unbounded delegation depth beyond sane configuration, or resource exhaustion from attacker-controlled cache keys at the edge — unless a default configuration enables the attack
  • Social engineering, physical attacks, or attacks on maintainers' personal infrastructure
  • Findings in forks, unreleased branches, or unsupported versions
  • Missing security headers, informational TLS weaknesses, or SPF/DKIM findings on marketing infrastructure
  • Automated scanner output with no demonstrated or credibly theorized impact

Recognition​

There is no monetary bug bounty. Program terms will be published when a budget makes one credible — not before.

What is offered:

  • CVE and GitHub Security Advisory credit under your preferred name
  • Hall of Fame listing for valid, impactful reports
  • Direct acknowledgement in the patched release's notes