Points clés
- La responsabilité liée aux vulnérabilités applicatives engage l'organisation qui a développé ou déployé l'application — pas seulement celle qui l'exploite.
- Les éditeurs de logiciels sont de plus en plus soumis à des obligations de sécurité : NIS2 impose des exigences sur la sécurité des produits mis sur le marché.
- La notion de "fitness for purpose" en droit des contrats s'étend progressivement à la sécurité : une application vendue comme sécurisée engage la responsabilité de l'éditeur si des vulnérabilités connues n'ont pas été corrigées.
- La traçabilité du cycle de développement (SBOM, journaux de build, résultats des tests) est un actif de conformité et de responsabilité légale.
La responsabilité de l'éditeur et du développeur
La responsabilité liée à une vulnérabilité applicative peut engager plusieurs acteurs selon la nature du développement. Pour une application développée en interne, la responsabilité est partagée entre l'équipe de développement (qui a introduit la vulnérabilité) et la direction (qui a alloué les ressources et défini les priorités). Pour une application achetée ou SaaS, la responsabilité de l'éditeur est engagée selon les termes contractuels (SLA de sécurité, obligations de patch management) et selon les représentations faites sur la sécurité du produit lors de la vente.
La distinction entre "nous n'avons pas pu anticiper cette vulnérabilité" (vulnérabilité zero-day) et "nous avons déployé un produit avec une vulnérabilité connue non corrigée" (CVE publiée, non patchée) est centrale dans l'engagement de responsabilité. La seconde situation est de plus en plus difficile à défendre face aux régulateurs et aux tribunaux.
NIS2 et la sécurité des produits logiciels
La directive NIS2 (Network and Information Security 2), entrée en vigueur en 2023, élargit le périmètre des obligations de cybersécurité à un grand nombre d'entités européennes. Elle impose notamment des exigences sur la sécurité des chaînes d'approvisionnement, ce qui inclut la sécurité des logiciels utilisés. Le Cyber Resilience Act (CRA), adopté par l'UE en 2024, va plus loin en imposant des exigences de sécurité explicites aux éditeurs de logiciels qui mettent des produits sur le marché européen — y compris des obligations de cycle de vie sécurisé, de gestion des vulnérabilités et de reporting.
Ces évolutions réglementaires transforment la sécurité applicative d'une bonne pratique en obligation légale avec des sanctions potentielles pour non-conformité. Elles impactent aussi bien les éditeurs qui vendent des logiciels que les organisations qui développent des applications à usage interne dans des secteurs couverts par NIS2.
La traçabilité du cycle de développement
La traçabilité du cycle de développement — résultats des scans SAST/DAST, SBOM (Software Bill of Materials), journaux des revues de code, rapports de tests d'intrusion, documentation des décisions d'acceptation des risques — constitue un actif de conformité et de responsabilité légale. En cas d'incident, cette traçabilité permet de démontrer que des mesures de sécurité raisonnables ont été prises, que les vulnérabilités connues ont été traitées dans des délais appropriés, et que les choix de sécurité ont fait l'objet de décisions documentées.
L'absence de cette traçabilité crée une présomption défavorable en cas de litige ou d'enquête réglementaire. Un éditeur qui ne peut pas produire les résultats de ses tests de sécurité pour un produit compromis se trouve dans une position de défense significativement plus difficile qu'un éditeur qui peut documenter l'intégralité de son programme de sécurité applicatif.
La responsabilité personnelle des dirigeants
La tendance réglementaire internationale est à l'extension de la responsabilité personnelle des dirigeants pour les défaillances de cybersécurité. La SEC a mis en cause le CISO de SolarWinds à titre personnel. La CISA américaine promeut l'accountability des dirigeants pour la cybersécurité. La directive NIS2 prévoit des sanctions administratives qui peuvent cibler les instances dirigeantes des entités essentielles. Cette évolution crée une pression spécifique sur les RSSI et les directeurs techniques pour documenter non seulement les mesures prises mais aussi les risques identifiés, les recommandations formulées, et les décisions de priorisation ou de déprioritisation prises par la direction.
Pour les développeurs et architectes, cette évolution impose une documentation rigoureuse des décisions d'architecture de sécurité et des risques résiduels acceptés — avec des signataires identifiés pour chaque décision significative.