Thème
05 — Gestion des vulnérabilités (art. 13-14, annexe I partie II)
1. Divulgation coordonnée et point de contact
La politique de divulgation coordonnée et le point de contact sont publiés dans ../SECURITY.md et le fichier security.txt (vue/public/.well-known/security.txt, servi sous /.well-known/security.txt). Point de contact : https://www.desautel.fr/contact.
Le processus documenté prévoit l'accusé de réception d'un signalement, l'évaluation de la vulnérabilité et le traitement coordonné avant divulgation. Le cadrage juridique du rapporteur (protection d'un signalement de bonne foi, absence de poursuites) relève de l'entité qui publie la politique.
2. Nomenclature logicielle (SBOM)
Un SBOM au format CycloneDX est généré à chaque exécution de l'intégration continue, pour les volets .NET et npm, et publié en artefact. Il permet d'identifier rapidement les composants affectés par une vulnérabilité publiée.
3. Surveillance automatisée des dépendances
L'intégration continue (.github/workflows/ci.yml) et .github/dependabot.yml assurent :
dotnet list package --vulnerable --include-transitive(échec du build en cas de vulnérabilité) ;npm audit --audit-level=highsur le frontend ;- alertes Dependabot (NuGet, npm, GitHub Actions), qui ouvrent une PR pour les correctifs de sécurité. Les mises à jour de version, elles, sont conduites à la main :
.github/dependabot.ymlles désactive, une montée majeure non sollicitée rendant l’arbre de dépendances insoluble.
4. Délais de correction (interne)
| Gravité | Objectif de correction |
|---|---|
| Critique / activement exploitée | Correctif ou mesure d'atténuation dans les meilleurs délais, [À COMPLÉTER : ex. 7 jours] |
| Élevée | [À COMPLÉTER : ex. 30 jours] |
| Moyenne / faible | Prochaine version planifiée |
Les correctifs de sécurité sont distribués via un installateur signé et identifiés dans la catégorie Security du ../../CHANGELOG.md.
5. Signalement obligatoire (art. 14) — applicable au 11 septembre 2026
En cas de vulnérabilité activement exploitée ou d'incident grave ayant un impact sur la sécurité du produit, le fabricant notifie l'ENISA (plateforme unique de signalement) et le CSIRT coordinateur selon les délais suivants :
| Échéance | Action |
|---|---|
| 24 heures | Alerte précoce après avoir eu connaissance de la vulnérabilité exploitée / de l'incident. |
| 72 heures | Notification (nature, mesures correctives ou d'atténuation prises ou conseillées). |
| 14 jours (vulnérabilité) | Rapport final : description, gravité, impact, correctif ou mesure disponible. |
Les utilisateurs concernés sont informés sans retard indu de l'incident et des mesures correctives ou d'atténuation qu'ils peuvent appliquer.
Procédure interne
- Réception / détection : via le point de contact (§1), la veille dépendances (§3) ou une source externe.
- Qualification : gravité, exploitation active, périmètre affecté (à l'aide du SBOM).
- Décision de signalement : si vulnérabilité activement exploitée ou incident grave → déclencher les délais 24 h / 72 h / 14 j.
- Correction : développement, test, publication d'une version signée.
- Information des utilisateurs : notice de sécurité + entrée Security au CHANGELOG.
- Clôture : rapport final, archivage au dossier.
- Responsable de la procédure :
[À COMPLÉTER : rôle / personne]. - Coordonnées ENISA / CSIRT coordinateur :
[À COMPLÉTER lors de la mise en œuvre].
6. Tests de sécurité réguliers
- Scan de dépendances continu (§3).
- Revue de sécurité par version majeure, dans la continuité des revues internes existantes.