YinkoShield
Brief

security · vulnerability disclosure

If you find a vulnerability, we want to hear about it before anyone else.

YinkoShield is security infrastructure. We take coordinated disclosure seriously. Please do not open a public GitHub issue for an undisclosed vulnerability — use one of the two channels below. We acknowledge within a few business days; disclosure timing is coordinated with the reporter.

how to report

Two channels. The first is preferred.

Please include:

  • A short description of the issue and its impact.
  • The affected component (e.g. verifiers/python, normative text in SPEC.md, the public site).
  • Steps to reproduce or a proof-of-concept where possible.
  • Any disclosure-timeline preference you'd like respected.
in scope

What we'll accept as a report.

  • Reference verifiers

    The four reference verifier implementations — Python, JavaScript, Go, Java — that ship with the YEI-001 specification.

  • Spec normative text

    Anything in `SPEC.md` that affects verification correctness, parsing safety, or token-record binding.

  • Examples and integrators' docs

    Sample code, scripted scenarios, or documentation that could mislead an integrator into an unsafe pattern in production.

  • Public site

    yinkoshield.com itself — content-injection, redirect, or transport-security issues.

out of scope

What we'll route elsewhere — declared, not silently rejected.

Same discipline as our threat model: out-of-scope items are named with the layer that owns them, not deflected.

  • The demo private key

    `keys/demo_private_key.pem` is intentionally public for test vectors and examples. It must never be used in production. Reports of its exposure are not vulnerabilities.

  • Forks and downstream products

    Issues in third-party forks of the verifier code or in operators' downstream products that have diverged from the upstream spec are reported to those maintainers.

  • General support questions

    Integration help, deployment guidance, or operational questions are not vulnerability reports. Use the briefing channel instead.

  • Operator-side infrastructure

    An operator's verifier deployment, key store, or backend security is the operator's domain. The substrate's threat-model boundary is documented in `THREAT_MODEL.md`.

hardening reminders

Operators forking the reference verifier code should run their own penetration testing and dependency audits on the fork, and follow the deployment checklists in the spec's CONFORMANCE.md and the residual-risk discussion in THREAT_MODEL.md.

Production deployments require shared atomic dedup, mutually authenticated key re-fetch, and the JWS header allowlist enforced fail-closed. The reference verifier in-memory dedup store is suitable for development only.

supported versions

Security fixes apply to the latest published spec and reference verifiers on the default branch. Vendoring an older commit? Track upstream and merge fixes.

security@yinkoshield.com Read the threat model