Vulnerability Management

Statut : draft. Politique et processus de gestion des vulnérabilités identifiées sur la plateforme (CVE dépendances, container scans, pentest findings, disclosure responsable).

1. Périmètre

Toute vulnérabilité identifiée sur :

• Code applicatif Nex (backend, mobile, web).
• Dépendances open-source consommées.
• Images Docker des services.
• Infrastructure : EKS, Cloudflare, Doppler, Firebase et leurs versions.
• Configuration : K8s, ingress, RDS, security groups AWS.

Hors périmètre direct (mais à suivre) : vulnérabilités des providers externes (Mobile Money, Apentis) — gérées via la communication vendor risk.

2. Sources de détection

Source	Type	Fréquence	Statut
Trivy (scan image Docker)	Container	À chaque build CI	✅ actif
pnpm audit / npm audit	Dépendances JS	À chaque CI [À CONFIRMER systématique]	⚠️
Renovate / Dependabot	Dépendances + alerte CVE	Continu	❌ à intégrer
gitleaks	Secrets fuités	Pre-commit + CI	❌ à intégrer
Pentest externe	Application + infra	Annuel cible	❌ pas encore réalisé
Bug bounty / disclosure responsable	Externe	Continu	❌ programme à lancer
Veille CVE (NVD, GHSA, vendor advisories)	Vendor / framework	Continu	⚠️ manuel
AWS Security Hub / Inspector	Infra cloud	Continu	[À CONFIRMER si activé]
Cloudflare WAF alerts	Edge	Continu	✅

3. Classification (sévérité CVSS)

Sévérité CVSS	Définition	SLA de remédiation
Critical (9.0 – 10.0)	Exploitation triviale + impact majeur (RCE, fuite massive PII, contournement auth)	7 jours
High (7.0 – 8.9)	Exploitation possible avec conditions + impact significatif	30 jours
Medium (4.0 – 6.9)	Exploitation difficile ou impact limité	90 jours
Low (< 4.0)	Impact mineur ou exploitation très improbable	Best-effort (prochaine release)

Les SLA démarrent à la date de découverte ou de publication de l'avis vendor, et non à la date d'investigation interne.

4. Processus

Triage (étape 2)

Critères :

• Vraie vulnérabilité ou faux positif ?
• Exploitabilité dans le contexte Nex (la dépendance vulnérable est-elle vraiment utilisée sur le chemin critique ?).
• Sévérité réelle vs sévérité CVSS publique (peut être inférieure si exploitation impossible dans notre contexte).
• Service / package owner.

Décision d'acceptation du risque

Une vulnérabilité dont le fix est non disponible ou disruptif peut être acceptée temporairement sous conditions :

• Accord écrit du RSSI et du tech lead.
• Compensation par un contrôle alternatif (rate limit, WAF rule, mitigation applicative).
• Date d'ré-évaluation explicite (≤ 90 jours).
• Documenté dans le ticket + ajouté à /security/known-gaps.

5. Patch management

Type	Cadence cible	Notes
Patches sécurité critiques (services Nex)	dans le SLA CVSS	Rebuild image + redeploy
Mises à jour mineures dépendances	Continu via Renovate (cible)	Auto-merge si tests verts
Mises à jour majeures frameworks (Nest, Expo, Nuxt)	Trimestriel	Sprint dédié
OS conteneurs / base images	Mensuel	Rebuild si nouvelle CVE base image
Cluster K8s EKS	Trimestriel ou selon avis AWS	Plan de bascule documenté

6. Disclosure responsable

À mettre en place :

• Email dédié : security@paywithnex.com [À PROVISIONNER].
• Page publique : /security ou .well-known/security.txt (RFC 9116) listant :
  • email de contact
  • politique de disclosure (délai de fix, transparence, hall of fame éventuel)
  • clé PGP (optionnel)
• Délai de réponse : accusé de réception ≤ 24 h, premier diagnostic ≤ 72 h.

À évaluer : programme bug bounty (HackerOne, YesWeHack) une fois la maturité technique atteinte.

7. Pentests

• Cible : 1 pentest externe annuel minimum + pentest avant tout changement majeur d'architecture (ex : nouveau scope card, nouvelle zone géographique).
• Scope V1 : application backend + apps mobiles + infrastructure publique.
• Fournisseurs envisagés : [À CONFIRMER].
• Rapport stocké dans /security/pentest-history/YYYY-MM-pentest-<vendor>.md (à créer).
• Findings tracés en Jira avec SLA selon sévérité.

8. Indicateurs

À suivre dans un board sécurité (revue mensuelle minimum) :

• Nombre de vulnérabilités ouvertes par sévérité.
• Délai moyen de remédiation par sévérité (Mean Time To Remediate, MTTR).
• Taux de vulnérabilités fermées dans le SLA.
• Nombre de dépendances avec CVE connues à corriger.
• Nombre de vulnérabilités acceptées (avec date d'ré-évaluation).

9. Conformité

Cadre	Exigence
PCI-DSS Req 6.2 (si scope card)	Patches sécurité dans les 30 j max
PCI-DSS Req 11.3	Pentest annuel + après changement significatif
ISO 27001 A.5.7, A.5.21, A.5.23	Veille, gestion fournisseurs, gestion incidents liés à des vulnérabilités
OWASP ASVS V10	Defense against malicious code
BEAC / COBAC	Reporting d'incidents impliquant des vulnérabilités exploitées

10. Gaps connus

• Pas de SCA continu (Snyk / Dependabot / Renovate non intégré).
• Pas de gitleaks intégré.
• Pas de SAST en CI.
• Pas de pentest externe réalisé à ce jour.
• Pas d'email security@paywithnex.com provisionné.
• Pas de page .well-known/security.txt publiée.

Suivi : /security/known-gaps.