# Programme de divulgation coordonnée des vulnérabilités (VDP) — Privamorph

> **Objet** : inviter les chercheurs en sécurité à tester Privamorph et à nous
> signaler leurs découvertes de manière **coordonnée**. Ce programme répond aussi à
> l'obligation **CRA B1** (divulgation coordonnée + point de contact) — voir
> `docs/checklist-conformite-cra-anssi.md`.
>
> Éditeur : **Jean-Michel IZZO (WCIS)**, SIRET 503 935 587 00058.
> Contact sécurité : `security@wcis.fr`.
>
> ⚠️ La clause **Safe Harbor** (§6) et les mentions légales doivent être **validées
> par un juriste** avant publication. Le reste est prêt à publier une fois les
> champs `À COMPLÉTER` renseignés.

## 1. Notre engagement

Nous prenons la sécurité au sérieux et documentons nos limites sans complaisance
(`THREAT-MODEL.md`, `FAILLES-CONNUES.md`). Nous accueillons les signalements de
bonne foi, y répondons, corrigeons, et **créditons** les chercheurs qui le
souhaitent. Ce programme est **sans récompense monétaire** (VDP, pas bug bounty) —
voir §7.

## 2. Périmètre (scope)

### Dans le périmètre
- L'**instance de test dédiée** que nous mettons à disposition : `https://À-COMPLÉTER`
  (⚠️ **ne testez QUE cette instance** — voir hors périmètre).
- Le **client web servi** par cette instance (application React) et son API.
- Le cas échéant, le **code source** fourni sur demande (audit « boîte blanche »).

### Hors du périmètre (ne pas tester)
- **Toute instance appartenant à un client** (Privamorph est on-premise :
  les déploiements clients ne nous appartiennent pas et sont **interdits de test**).
- Nos éventuels sites vitrine, comptes de messagerie, Microsoft Store, et tout
  service **tiers** (leurs propres programmes s'appliquent).
- Les **limites déjà documentées et assumées** (voir §4) : les re-signaler
  n'apporte rien.

## 3. Règles d'engagement

### Autorisé (sur l'instance de test uniquement)
- Tests applicatifs et réseau usuels : reconnaissance, analyse, injection, auth,
  logique métier, crypto, etc.
- Utilisation de comptes de test que vous créez vous-même.
- Preuve de concept **minimale** démontrant l'impact.

### Interdit
- **Déni de service** (volumétrique, épuisement de ressources), spam, envoi massif.
- **Destruction, altération ou exfiltration** de données au-delà du strict minimum
  pour prouver la vulnérabilité. **Ne pas** accéder aux données d'autrui.
- **Ingénierie sociale**, hameçonnage, attaques physiques, tests sur nos employés
  ou prestataires.
- Scans automatisés agressifs dégradant le service (respecter le rate-limit).
- Divulgation publique **avant** correctif coordonné (voir §8).
- Tout test **hors de l'instance dédiée**.

## 4. Connu / déjà documenté (ne pas signaler)

Pour ne pas perdre votre temps ni le nôtre, ces points sont **assumés et
documentés** — lisez `THREAT-MODEL.md` et `FAILLES-CONNUES.md` avant de tester :
- Face à un **administrateur/hôte compromis** (« HbC »/« MS ») : nous visons la
  **détection/imputabilité**, pas l'inviolabilité. Le client étant servi par le
  serveur, un serveur malveillant peut altérer le client (limite architecturale).
- **Métadonnées visibles** du serveur : email, mois, volumétrie, taille des
  fichiers, dates/IP de connexion.
- **Perte de clé/phrase secrète sans sauvegarde = données illisibles** (par
  conception).
- k-anonymat des campagnes **sans attestation d'organisation** (résiduel Sybil,
  documenté).
- Ce qui figure déjà dans `FAILLES-CONNUES.md` §9 (pentest du 13 août 2026).

Une **nouvelle** exploitation qui dépasse ces limites documentées, en revanche,
nous intéresse vivement.

## 5. Comment signaler

- **Email** : `security@wcis.fr` (chiffrement PGP possible — clé publique :
  `À PUBLIER`).
- **Contenu utile** : type de vulnérabilité, composant/URL, **étapes de
  reproduction**, PoC, impact estimé, et votre nom/pseudo pour le crédit.
- **Un rapport = une vulnérabilité** (facilite le suivi).
- Merci de **ne pas** ouvrir d'issue publique ni de divulguer avant coordination.

## 6. Safe Harbor *(à faire valider par un juriste)*

> **Brouillon.** Si vous menez vos recherches **de bonne foi** et **conformément à
> cette politique** (périmètre et règles respectés), nous nous engageons à
> **ne pas engager de poursuites** à votre encontre et à considérer votre action
> comme **autorisée** au regard des dispositions applicables sur l'accès aux
> systèmes de traitement automatisé de données. Cet engagement ne couvre pas les
> actions hors périmètre, malveillantes, ou portant atteinte à des tiers.
> *Rédaction définitive et portée juridique : à valider par un professionnel du
> droit (droit français / UE).*

## 7. Récompenses

Programme **sans prime monétaire**. Nous offrons : accusé de réception,
**remerciements**, et — si vous le souhaitez — une mention dans une page
**« Hall of fame »** (`À CRÉER`). Nous coordonnons volontiers l'attribution d'un
**CVE** pour les vulnérabilités éligibles.

## 8. Divulgation coordonnée (délais)

| Étape | Engagement |
|---|---|
| Accusé de réception | ≤ **72 h ouvrées** |
| Qualification / première évaluation | ≤ **7 jours** |
| Correctif | selon gravité — `SECURITY.md` §3 |
| Divulgation publique | **coordonnée**, après correctif ; délai indicatif **90 jours**, ajustable d'un commun accord |

Si une vulnérabilité s'avérait **activement exploitée**, nous appliquons en outre
la procédure réglementaire de signalement (`SECURITY.md` §4 — ENISA 24 h/72 h/14 j).

## 9. Mise en place opérationnelle (checklist interne)

- [x] Adresse **`security@wcis.fr`** créée. Reste : publier la clé **PGP**.
- [ ] Déployer une **instance de test jetable** (data-dir vierge, pas de vraies
      données) et renseigner son URL en §2.
- [ ] Publier cette politique et un **`security.txt`** (RFC 9116) — modèle fourni
      dans `deploy/security.txt`.
- [ ] (Option) Héberger le VDP sur **YesWeHack** (FR/UE) ou **HackerOne** pour la
      réception/triage.
- [ ] Faire **valider le Safe Harbor** (§6) par un juriste.
- [ ] Désigner le **suppléant** du responsable (cf. `docs/registre-vulnerabilites.md`).