La sécurité des systèmes d’information bancaires et assurantiels ne se limite plus aux applications elles-mêmes. Elle dépend désormais de l’ensemble de la chaîne logicielle : bibliothèques open source, outils de build, pipelines CI/CD, registres de paquets et environnements d’exécution.
Les incidents récents ont montré que des compromissions peuvent être introduites en amont du cycle de développement, puis propagées silencieusement jusqu’en production. Des campagnes d’empoisonnement de dépendances sur des registres publics (npm, PyPI), ainsi que des attaques ciblant des pipelines CI/CD, ont été largement documentées dans les rapports de l’ENISA et dans plusieurs analyses industrielles sur la sécurité de la supply chain logicielle.
Dans ce contexte, la maîtrise de la chaîne de build devient un enjeu central de cybersécurité pour les institutions financières.
Une surface d’attaque étendue et difficilement visible
Les architectures modernes reposent sur une forte réutilisation de composants logiciels. Une application peut intégrer plusieurs centaines, voire milliers de dépendances directes et indirectes.
Selon des travaux publiés par l’ENISA sur les risques liés à la supply chain logicielle, une part significative des vulnérabilités exploitées provient de composants tiers. Par ailleurs, des études industrielles ont mis en évidence que la majorité du code exécuté en production n’est pas développé en interne.
Cette dépendance crée plusieurs vecteurs d’attaque :
- introduction de code malveillant dans une bibliothèque open source,
- compromission d’un compte développeur ou d’un mainteneur,
- injection de dépendances piégées dans un projet (dependency confusion),
- altération d’un pipeline CI/CD ou d’un artefact de build,
- compromission d’un registre de distribution de paquets.
Ces attaques ont en commun leur capacité à contourner les contrôles traditionnels, en exploitant la confiance implicite accordée à la chaîne de développement.
SBOM : un socle pour la visibilité et la traçabilité
Le Software Bill of Materials (SBOM) constitue aujourd’hui un élément structurant pour la maîtrise de la supply chain logicielle.
Un SBOM est un inventaire structuré des composants logiciels utilisés dans une application, incluant leurs versions et leurs dépendances. Il permet :
- d’identifier rapidement l’exposition à une vulnérabilité donnée,
- de cartographier les dépendances critiques,
- de faciliter la réponse à incident,
- de répondre à des exigences réglementaires croissantes en matière de transparence.
Des initiatives internationales, soutenues notamment par des organismes publics et des agences de cybersécurité, encouragent la généralisation des SBOM dans les environnements critiques.
Dans le secteur financier, le SBOM devient un outil clé pour démontrer la maîtrise des composants logiciels, en cohérence avec les exigences de DORA en matière de gestion des risques ICT.
Sécurisation des pipelines CI/CD : un point de contrôle critique
Les pipelines CI/CD sont devenus des cibles prioritaires pour les attaquants. Leur compromission permet d’introduire du code malveillant directement dans les artefacts déployés.
Les bonnes pratiques issues de l’écosystème DevSecOps et des référentiels de sécurité recommandent plusieurs mesures :
- isolation stricte des environnements de build,
- gestion sécurisée des secrets (tokens, clés API),
- limitation des droits des comptes techniques,
- journalisation et traçabilité des actions dans les pipelines,
- contrôle d’intégrité des artefacts générés.
Les travaux autour des standards d’attestation de provenance, notamment dans les approches de type SLSA (Supply-chain Levels for Software Artifacts), visent à garantir que le code produit est conforme à ce qui a été développé et validé.
Ces mécanismes permettent de renforcer la confiance dans les artefacts logiciels, en apportant des preuves vérifiables sur leur origine et leur processus de fabrication.
Contrôle des dépendances et politiques de gestion
La gestion des dépendances ne peut plus être laissée à l’initiative des équipes de développement seules. Elle doit s’inscrire dans une gouvernance globale.
Les pratiques observées dans les environnements matures incluent :
- définition de référentiels de dépendances autorisées,
- validation préalable des nouvelles bibliothèques,
- surveillance continue des vulnérabilités (CVE),
- limitation des dépendances non maintenues ou peu utilisées,
- utilisation de registres internes ou miroirs sécurisés.
Les attaques de type “dependency confusion”, documentées dans plusieurs publications de recherche, ont montré que des dépendances malveillantes peuvent être injectées simplement en exploitant des différences de configuration entre registres publics et privés.
La mise en place de politiques de résolution de dépendances strictes est donc essentielle.
Surveillance des registres et détection d’introduction malveillante
La détection des compromissions dans la supply chain repose sur une capacité à surveiller les sources d’approvisionnement logiciel.
Cela inclut :
- la surveillance des registres publics (npm, PyPI, Maven, etc.),
- la détection de comportements anormaux (publication de versions suspectes, changements de mainteneur),
- l’analyse de code pour identifier des patterns malveillants,
- la corrélation avec des flux de renseignement sur les menaces.
Des campagnes récentes ont montré que des packages malveillants peuvent rester actifs pendant plusieurs semaines avant d’être détectés, ce qui renforce la nécessité d’une surveillance proactive.
Alignement avec les exigences réglementaires
Le cadre réglementaire européen, en particulier DORA, impose aux institutions financières de maîtriser leurs risques liés aux technologies de l’information, y compris ceux provenant de fournisseurs et de composants tiers.
Même si DORA ne prescrit pas explicitement des outils comme le SBOM ou SLSA, les exigences relatives à :
- l’inventaire des actifs,
- la gestion des dépendances,
- la traçabilité,
- la capacité de réponse à incident,
convergent vers l’adoption de ces pratiques.
Par ailleurs, les recommandations de l’ENISA sur la sécurité de la supply chain logicielle soulignent l’importance de mécanismes de contrôle tout au long du cycle de vie logiciel.