● Kaspersky FR 📅 21/04/2026 à 10:17

Cybersécurité 👤 Stan Kaminsky

🏷️ Tags : vulnérabilités cert python rag renseignement rte

Comme nous l’avons déjà évoqué dans un article précédent, le développement logiciel moderne est pratiquement inconcevable sans le recours à des composants open source. Cependant, ces dernières années, les risques associés sont devenus de plus en plus variés, complexes et nombreux. Premièrement, lorsque les vulnérabilités touchent l’infrastructure et le code d’une entreprise plus rapidement qu’elles ne sont corrigées, deuxièmement, lorsque les données sont peu fiables et incomplètes, et troisièmement, lorsque des programmes malveillants peuvent se cacher dans des composants courants, il ne suffit pas de se contenter de vérifier les numéros de version et d’envoyer des requêtes de dépannage à l’équipe informatique. La gestion des vulnérabilités doit être étendue afin de couvrir les stratégies de téléchargement de logiciels, les mesures de sécurité pour les assistants d’IA et l’ensemble du processus de développement logiciel. Une sélection fiable de composants open source L’essentiel de la solution consiste à empêcher l’utilisation de code vulnérable et malveillant. Les mesures suivantes devraient être mises en œuvre : Disposer d’un répertoire interne d’artefacts. La seule source de composants pour le développement interne doit être un dépôt unifié dans lequel les composants ne sont intégrés qu’après une série de vérifications. Procéder à un contrôle rigoureux des composants. Ces vérifications portent notamment sur : les versions connues du composant, les versions connues pour être vulnérables ou malveillantes, la date de publication, l’historique d’activité, ainsi que la réputation du paquet et de ses auteurs. Il est impératif d’analyser l’intégralité du contenu du paquet, y compris les instructions de compilation, les cas de test et les autres données auxiliaires. Pour filtrer le registre lors de l’ingestion, utilisez des scanners open source spécialisés ou une solution complète de sécurité des charges de travail dans le cloud. Appliquer l’épinglage de dépendances. Les processus de compilation, les outils d’IA et les développeurs ne doivent pas recourir à des versions non figées (telles que » latest « ). Les compilations de projets doivent s’appuyer sur des versions vérifiées. Par ailleurs, les dépendances épinglées doivent être régulièrement mises à jour vers les dernières versions vérifiées, qui garantissent la compatibilité et ne présentent aucune vulnérabilité connue. Cela réduit considérablement le risque d’attaques contre la chaîne d’approvisionnement liées à la compromission d’un paquet connu. Amélioration des données de vulnérabilité Pour identifier plus efficacement les vulnérabilités et les hiérarchiser correctement, une organisation doit mettre en place plusieurs processus informatiques et de sécurité : Enrichissement des données relatives aux vulnérabilités. Selon les besoins de l’organisation, cette étape est nécessaire soit pour enrichir les informations en combinant les données provenant du NVD, de l’EUVD, du BDU, de la base de données d’alertes GitHub et d’osv.dev, soit pour acheter un flux commercial de renseignements sur les vulnérabilités dans lequel les données sont déjà agrégées et enrichies. Dans tous les cas, il est utile de suivre également les flux d’informations sur les menaces afin de repérer les tendances d’exploitation réelles et de mieux cerner le profil des pirates qui ciblent des vulnérabilités spécifiques. Kaspersky propose un flux de données dédié spécifiquement aux composants open source. Analyse approfondie de la composition des logiciels. Des outils spécialisés d’analyse de la composition des logiciels (SCA) permettent de parcourir la chaîne de dépendances du code open source afin de recenser l’ensemble des bibliothèques utilisées et d’identifier les composants obsolètes ou non pris en charge. Les données relatives aux composants sains sont également utiles pour enrichir le registre d’artefacts. Identification des abandonwares. Même si un composant n’est pas officiellement considéré comme vulnérable et n’a pas été officiellement déclaré comme n’étant plus pris en charge, le processus d’analyse doit signaler les composants qui n’ont pas reçu de mises à jour depuis plus d’un an. Ceux-ci justifient une analyse distincte et un remplacement éventuel, tout comme les composants en fin de vie. Sécurisation du code et des agents d’IA Les activités des systèmes d’IA utilisés dans le codage doivent s’accompagner d’un ensemble complet de mesures de sécurité, allant du filtrage des données entrantes à la formation des utilisateurs : Restrictions sur les recommandations de dépendance. Assurez-vous que l’environnement de développement soit configuré de manière à ce que les agents assistants d’IA ne puissent accéder qu’aux composants et bibliothèques provenant du registre d’artefacts de confiance. Si ceux-ci ne contiennent pas les bons outils, le modèle devrait déclencher une requête pour inclure la dépendance dans le registre, plutôt que de récupérer sur PyPI un élément qui correspond simplement à la description. Filtrage des résultats du modèle. Malgré ces restrictions, tout ce qui est généré par le modèle doit également être vérifié afin de s’assurer que le code généré par l’IA ne contient pas de dépendances obsolètes, non prises en charge, vulnérables ou fictives. Cette vérification doit être intégrée directement au processus de validation du code ou à la phase de préparation de la compilation. Elle ne remplace pas le processus d’analyse statique traditionnel : les outils SAST doivent toujours être intégrés au pipeline CI/CD. Formation des développeurs. Les équipes informatiques et de sécurité doivent bien connaître les caractéristiques des systèmes d’IA, leurs principes de fonctionnement et les erreurs courantes. Pour ce faire, les employés doivent suivre une formation spécialisée adaptée à leurs postes. Suppression systématique des composants EOL Si les systèmes d’une entreprise utilisent des composants open source obsolètes, il convient d’adopter une approche systématique et cohérente pour remédier à leurs vulnérabilités. Pour ce faire, il existe trois méthodes principales : Migration. Il s’agit de la méthode la plus complexe sur le plan organisationnel et la plus coûteuse, car elle implique le remplacement complet d’un composant, suivi de l’adaptation, de la réécriture ou du remplacement des applications basées sur celui-ci. La décision de procéder à une migration est particulièrement intimidante lorsqu’elle nécessite une refonte complète de l’ensemble du code interne. Cela touche souvent les composants essentiels : il est en effet impossible de migrer facilement à partir de Node.js 14 ou de Python 2. Assistance à long terme (LTS). Il existe un marché dédié aux services d’assistance pour les projets hérités de grande envergure. Cela implique parfois la création d’une version dérivée du système existant, gérée par des développeurs tiers. Dans d’autres cas, des équipes spécialisées adaptent des correctifs destinés à corriger des vulnérabilités spécifiques à des versions plus anciennes qui ne sont plus prises en charge. Le passage à une version avec support à long terme (LTS) implique généralement des frais de maintenance, mais, dans de nombreux cas, cette solution peut néanmoins s’avérer plus économique qu’une migration complète. Mesures compensatoires. Grâce aux résultats d’une analyse approfondie, il est possible de mettre en place un ensemble de mesures de sécurité globales visant à réduire le risque d’exploitation des vulnérabilités présentes dans le produit existant. L’efficacité et la viabilité économique de cette approche dépendent toutes deux du rôle que joue le logiciel au sein de l’organisation. Les services de sécurité, informatiques et opérationnels doivent collaborer afin de choisir l’une de ces trois options pour chaque composant déclaré obsolète ou abandonné, et consigner ce choix dans les registres d’actifs et les SBOM de l’entreprise. Gestion des vulnérabilités open source basée sur les risques Toutes les mesures énumérées ci-dessus permettent de réduire le nombre de logiciels et de composants vulnérables qui s’introduisent dans l’organisation, et facilitent la détection et la correction des failles. Néanmoins, il est impossible d’éliminer tous les problèmes : le nombre d’applications et de composants augmente tout simplement trop rapidement. Il est donc essentiel de hiérarchiser les vulnérabilités en fonction des risques réels. Le modèle d’évaluation des risques doit être élargi afin de tenir compte des particularités des logiciels open source, en apportant des réponses aux questions suivantes : La branche de code vulnérable est-elle réellement exécutée dans l’environnement de l’organisation ? Il convient de réaliser une analyse de l’accessibilité des vulnérabilités détectées. De nombreux extraits de code défectueux ne sont en réalité jamais exécutés dans le cadre de la mise en œuvre de l’organisation, ce qui rend la vulnérabilité impossible à exploiter. Certaines solutions SCA permettent d’effectuer cette analyse. Ce même processus permet d’évaluer un autre scénario : que se passerait-il si les procédures ou composants vulnérables étaient entièrement supprimés du projet ? Parfois, cette méthode de remédiation s’avère étonnamment simple. Cette vulnérabilité est-elle exploitée dans le cadre d’attaques réelles ? Une preuve de concept est-elle disponible ? Les réponses à ces questions s’inscrivent dans le cadre de méthodes standard de hiérarchisation telles que l’EPSS, mais le suivi doit s’appuyer sur un ensemble beaucoup plus large de sources de renseignements. Une activité cybercriminelle a-t-elle été signalée dans ce registre de dépendances ou dans des composants connexes et similaires ? Il s’agit là de facteurs supplémentaires à prendre en compte pour établir les priorités. En tenant compte de ces facteurs, l’équipe est en mesure d’allouer efficacement ses ressources et de corriger en priorité les problèmes les plus graves. La transparence est la nouvelle tendance Le niveau d’exigence en matière de sécurité pour les logiciels open source ne fera que continuer à augmenter. Les entreprises qui développent des applications (même pour un usage interne) seront confrontées à des exigences réglementaires imposant une cybersécurité documentée et vérifiable au sein de leurs systèmes. Selon les estimations des experts de Sonatype, 90 % des entreprises à l’échelle mondiale sont déjà soumises à une ou plusieurs exigences les obligeant à fournir des preuves de la fiabilité des logiciels qu’elles utilisent. C’est pourquoi ces experts considèrent la transparence comme « la monnaie d’échange de la sécurité de la chaîne d’approvisionnement logicielle ». En contrôlant l’utilisation des composants et applications open source, en enrichissant les données de Threat Intelligence et en surveillant de près les systèmes de développement basés sur l’IA, les entreprises peuvent apporter les innovations dont elles ont besoin, tout en répondant aux exigences élevées imposées tant par les régulateurs que par les clients.

🔗 Lire l'article original 👁️ 0 lecture