YinkoShield
Briefing

sécurité · divulgation de vulnérabilités

Si vous trouvez une vulnérabilité, nous voulons l'entendre avant tout le monde.

YinkoShield est une infrastructure de sécurité. Nous prenons la divulgation coordonnée au sérieux. Merci de ne pas ouvrir d'issue GitHub publique pour une vulnérabilité non-divulguée — utilisez l'un des deux canaux ci-dessous. Nous accusons réception sous quelques jours ouvrés ; le timing de divulgation est coordonné avec le rapporteur.

comment rapporter

Deux canaux. Le premier est préféré.

Merci d'inclure :

  • Une courte description du problème et de son impact.
  • Le composant affecté (ex. verifiers/python, le texte normatif dans SPEC.md, le site public).
  • Les étapes pour reproduire ou un proof-of-concept si possible.
  • Toute préférence de calendrier de divulgation que vous souhaitez voir respectée.
dans le périmètre

Ce que nous accepterons comme rapport.

  • Vérificateurs de référence

    Les quatre implémentations de vérificateur de référence — Python, JavaScript, Go, Java — livrées avec la spécification YEI-001.

  • Texte normatif de la spec

    Tout ce qui dans `SPEC.md` affecte la correction de la vérification, la sûreté du parsing, ou le binding token-record.

  • Exemples et docs intégrateur

    Code d'exemple, scénarios scriptés, ou documentation susceptibles d'induire un intégrateur dans un pattern non-sûr en production.

  • Site public

    yinkoshield.com lui-même — content-injection, redirection, ou problèmes de transport-security.

hors périmètre

Ce que nous routons ailleurs — déclaré, pas silencieusement rejeté.

Même discipline que notre threat model : les éléments hors-périmètre sont nommés avec la couche qui les possède, pas déviés.

  • La clé privée de démo

    `keys/demo_private_key.pem` est intentionnellement publique pour les test vectors et les exemples. Elle ne doit jamais être utilisée en production. Les rapports d'exposition ne sont pas des vulnérabilités.

  • Forks et produits aval

    Les problèmes dans des forks tiers du code vérificateur ou dans les produits aval des opérateurs qui ont divergé de la spec amont sont rapportés à ces mainteneurs.

  • Questions support général

    L'aide à l'intégration, le guidage de déploiement, ou les questions opérationnelles ne sont pas des rapports de vulnérabilité. Utilisez le canal briefing à la place.

  • Infrastructure côté opérateur

    Le déploiement de vérificateur d'un opérateur, son key store, ou la sécurité de son backend est le domaine de l'opérateur. La frontière du threat-model du substrat est documentée dans `THREAT_MODEL.md`.

rappels de hardening

Les opérateurs qui forkent le code des vérificateurs de référence doivent faire tourner leur propre penetration testing et leurs audits de dépendances sur le fork, et suivre les checklists de déploiement dans CONFORMANCE.md de la spec et la discussion sur le risque résiduel dans THREAT_MODEL.md.

Les déploiements de production exigent un dedup atomique partagé, un re-fetch de clé mutuellement authentifié, et la allowlist d'header JWS appliquée fail-closed. Le store de dedup en mémoire du vérificateur de référence convient au développement uniquement.

versions supportées

Les correctifs de sécurité s'appliquent à la dernière spec publiée et aux vérificateurs de référence sur la branche par défaut. Vous vendorisez un commit plus ancien ? Suivez l'amont et mergez les correctifs.

security@yinkoshield.com Lire le threat model