L’impératif de sécurité : confiance, rapidité et défense intégrée

La complexité croissante des attaques de chaîne d’approvisionnement logicielle, de plus en plus systémiques, intensifie la tension critique entre rapidité et sécurité.

Le récent rapport « Breaking the Chain » de la Direction nationale israélienne du cyberespace (INCD) confirme que les menaces les plus importantes se situent en dehors de votre code d’origine, mettant en évidence une crise de confiance dans la chaîne d’approvisionnement logicielle open source (OSS).

Bien que les percées émergentes de l’IA agentique en matière de défense constituent une avancée précieuse pour la qualité et la sûreté du code, le rapport de l’INCD rappelle que seule une sécurité couvrant l’ensemble de la chaîne logicielle, native au processus de livraison et focalisée sur les binaires peut véritablement surmonter la tension persistante entre vitesse et sécurité dans les organisations.

La position de JFrog en matière de sécurité : Se bout en bout. Native. Avancée.

La philosophie de JFrog s’articule autour de trois objectifs principaux : garantir la productivité des développeurs, permettre aux équipes de développement de s’assurer que chaque version d’un logiciel est fiable et faciliter le processus global de gestion de la sécurité. Ces résultats répondent efficacement au paradoxe vitesse/sécurité, permettant aux équipes d’atteindre les deux objectifs. Que faut-il donc faire pour y parvenir ?

Les trois piliers de la défense

Tout d’abord, la sécurité doit couvrir l’ensemble de la chaîne d’approvisionnement logicielle, de bout en bout.

Pourquoi ? La sécurité ne se résume pas à des contrôles ponctuels. Elle exige un engagement permanent, depuis la création du code jusqu’à la mise en production de l’artefact. Cela impose de disposer de contexte et de feedback à chaque étape du cycle de vie complet de l’artefact. Une approche de bout en bout (E2E) permet de fournir la source unique de vérité nécessaire pour gérer les risques à l’échelle mondiale, garantir la conformité et assurer le contrôle et la traçabilité nécessaires tout au long de la chaîne de production.

Ensuite, la sécurité doit faire partie intégrante du pipeline de livraison, et non être greffée après coup.

Pourquoi ? Les outils de sécurité externes réactifs introduisent des frictions, ralentissent la mise sur le marché et ne peuvent tout simplement pas fournir la visibilité nécessaire à une gouvernance efficace. En appliquant une politique et en effectuant un scan continu au sein d’une plateforme unique, la conformité et la confiance sont automatiquement établies au fil du pipeline, et non pas vérifiées après coup. De cette manière, la politique s’applique à tous les points de passage automatisés, et la sécurité devient un moteur de vitesse, non une contrainte.

Troisièmement, votre architecture de sécurité doit être axée sur les binaires et s’appuyer sur la recherche.

Pourquoi ? L’artefact compilé – le binaire – est la cible principale des attaquants. Se fier uniquement au scan du code source crée un angle mort critique, laissant passer des vulnérabilités introduites plus tard dans le processus CI/CD via des scripts de build malveillants ou des dépendances corrompues. En appliquant une politique et en analysant continuellement l’artefact binaire, la confiance est automatiquement intégrée dans l’exécution du pipeline. Votre stratégie de sécurité doit également s’appuyer sur des recherches fiables. Par exemple, JFrog dispose d’une équipe d’ingénieurs et de chercheurs en sécurité qui se consacrent exclusivement à l’amélioration de la sécurité des logiciels par la découverte, l’analyse et l’exposition de nouvelles vulnérabilités et méthodes d’attaque.

Les principaux défis sécuritaires d’après l’INCD

Les conclusions du récent rapport de l’INCD, Breaking the Chain : How Supply Chain Attacks Target Package Managers (en français : « Briser la chaîne : de quelle manière les attaques de la chaîne d’approvisionnement ciblent les gestionnaires de packages »), fournit une validation externe cruciale de la nécessité d’une approche intégrale de la sécurité.

Défi 1 : CI/CD : des pipelines qui ouvrent une autoroute automatisée au risque

Les pipelines CI/CD automatisent l’ensemble du cycle de vie logiciel, du développement au déploiement, afin de permettre la livraison rapide d’un code de haute qualité. Toutefois, compte tenu de la relation étroite entre le développement, la gestion des packages et ces processus automatisés, ces pipelines constituent la principale porte d’entrée du risque dans l’organisation. L’analyse de l’INCD souligne que les acteurs malveillants ciblent les composants tiers compromis pour pénétrer et s’implanter dans l’infrastructure des organisations, en contournant souvent les défenses périmétriques traditionnelles.

Défi 2 : La crise de la confiance implicite et des gestionnaires spécifiques à chaque langage

La confiance implicite placée dans les registres de packages et leurs contenus crée un risque systémique, augmentant fortement la surface d’attaque des entreprises. L’échelle est immense : selon le rapport, « les 15 000 premiers PackAGES PyPI sont collectivement téléchargés plus de 83 milliards de fois par mois ». La compromission d’une seule dépendance transitive peut avoir un impact énorme.

Le rapport explique également comment les gestionnaires de packages spécifiques à une langue (tels que npm, pip et Maven), contrairement aux gestionnaires de systèmes d’exploitation plus contrôlés, ne disposent généralement pas de processus de maintenance et d’approbation centraux rigoureux ; les développeurs pouvant envoyer des mises à jour directement à ces écosystèmes sans supervision manuelle. Cette flexibilité accélère l’innovation mais augmente intrinsèquement l’exposition aux risques de sécurité.

Défi 3 : l’angle mort des outils traditionnels en matière de logiciels malveillants

L’incapacité des outils de sécurité traditionnels à détecter les logiciels malveillants est un autre problème majeur identifié dans le paysage de la défense. Les outils existants, tels que les tests statiques de sécurité des applications (SAST) et l’analyse de la composition logicielle (SCA), sont principalement conçus pour détecter les vulnérabilités connues, les schémas de codage dangereux ou les erreurs de logique.

Seuls, ces outils présentent une lacune fonctionnelle en matière d’analyse comportementale : ils ne se concentrent pas sur la détection d’un comportement inhabituel ou d’autres indicateurs qui révéleraient la présence d’un logiciel malveillant. Cette lacune crée une fenêtre critique où peuvent se développer des attaques sophistiquées de la chaîne d’approvisionnement de type « zero day », telles que l’incident de la porte dérobée de XZ Utils.

Tactiques adverses observées

Le rapport de l’INCD détaille également de manière utile les tactiques courantes qui exploitent l’absence de contrôle de bout en bout (E2E) et la dépendance à l’égard de la confiance implicite :

• Compromission des identifiants et des identités : Cette catégorie comprend le détournement de jetons d’accès à des projets et la prise de contrôle de comptes, où les attaquants exploitent une fuite d’informations d’identification ou un hameçonnage pour prendre le contrôle du compte d’un chargé de maintenance et publier un code malveillant. Il s’agit aussi de l’acquisition de droits de contribution à un dépôt : un adversaire parvient à instaurer la confiance avec les mainteneurs au fil du temps, obtient des accès en écriture et introduit du code malveillant ; un scénario illustré par la porte dérobée de XZ Utils.
• Exploitation des noms : cela inclut le typosquatting (imiter des noms de packages légitimes en introduisant de légères fautes de frappe) et le brandjacking (reproduire les caractéristiques de packages de marques reconnues) afin de tromper les développeurs et leur faire installer du code malveillant.
• La menace IA native (slopsquatting) : les attaquants profitent des grands modèles de langage (LLM) en créant des packages malveillants dont les noms proviennent d’hallucinations ou de suggestions générées par ces modèles, correspondant à des packages inexistants, ce qui renforce les risques pour les organisations.
• Configuration et abus de confiance : il s’agit de la confusion des dépendances, où les systèmes de build non sécurisés donnent la priorité à un package public et malveillant (souvent avec un numéro de version plus élevé) plutôt qu’à un package prévu à l’interne. On y trouve également la manifest confusion (npm) : le manifeste, c’est-à-dire les métadonnées visibles publiquement, est envoyé indépendamment de l’archive du package. Les informations et scripts contenus dans le tarball ne sont pas contrôlés contre ce manifeste, ce qui peut tromper aussi bien les utilisateurs que les outils automatiques.

L’INCD recommande une sécurité multicouche de la chaîne d’approvisionnement logicielle

Pour atténuer ces menaces, le rapport de l’INCD recommande de mettre en œuvre une approche à plusieurs niveaux. La plateforme de chaîne d’approvisionnement logicielle de JFrog assure cette défense en s’appuyant sur trois piliers fondamentaux : une approche E2E, une intégration native, et un focus sur les artefacts binaires.

Pilier 1 : Couverture et gouvernance de bout en bout (E2E)

Ce pilier garantit une sécurité et un contrôle continus tout au long du cycle de vie des artefacts, en comblant les lacunes de gouvernance et les mandats de conformité identifiés par l’INCD.

• Curation et politique proactives : JFrog Curation renforce le contrôle E2E en limitant les développeurs à construire avec des dépendances provenant uniquement de registres virtuels approuvés et fiables. Cela permet d’éviter que des menaces, telles que le typosquatting, le slopsquatting et la confusion de dépendance ne pénètrent dans l’environnement, en adhérant aux recommandations de l’INCD concernant la mise en œuvre d’une gestion stricte des changements et le test de chaque nouveau package dans un environnement contrôlé.
• Transparence de la chaîne d’approvisionnement : JFrog Xray prend en charge de manière native la génération de nomenclatures logicielles complètes (SBOM), une recommandation essentielle de l’INCD pour la transparence de la chaîne d’approvisionnement et la réponse rapide aux menaces émergentes.
• Gouvernance des identités et des menaces : JFrog Advanced Security étend la couverture E2E en fournissant une gouvernance essentielle, notamment en s’appuyant sur les directives NIST SP 800-204D. Il s’agit notamment d’utiliser des outils d’analyse des secrets pour surveiller les informations d’identification exposées (afin de contrer les menaces de prise de contrôle des comptes) et d’appliquer les principes de moindre privilège aux utilisateurs humains et aux identités non humaines (NHI), ce qui atténue les risques et limite la propagation des codes malveillants.

Pilier 2 : Sécurité native et intégrée

Atteindre la vitesse sans friction exige une sécurité intégrée structurellement, et non greffée après coup.

• Application native : JFrog Curation constitue la toute première ligne de défense, s’attaquant directement au problème de « confiance implicite » propre aux registres publics. Parce que l’application des règles est native et pleinement intégrée, les packages dangereux ou suspects sont bloqués dès le départ. Cette conception structurelle assure que confiance et conformité se forment naturellement durant le pipeline.
• Outillage intégral : La plateforme JFrog prend en charge les outils essentiels au DevSecOps, en s’appuyant notamment sur les lignes directrices du NIST SP 800-204D pour intégrer la sécurité de la chaîne d’approvisionnement logicielle. Cela inclut l’utilisation recommandée des SAST (disponibles avec Advanced Security) et de la SCA (via Xray).

Pilier 3 : Architecture centrée sur les binaires

Ce pilier garantit que la protection est appliquée à l’artefact lui-même (la cible principale des attaquants) et couvre l’angle mort du code source.

• Analyse continue des artefacts : JFrog Xray assure une sécurité continue en analysant tout ce qui se trouve à l’intérieur de l’artefact compilé. Ce focus sur les binaires fournit des contrôles d’intégrité complets pour la cible de l’attaquant.
• Analyse contextuelle : Xray fournit une analyse contextuelle et transitive afin que les équipes de sécurité concentrent leurs efforts de manière efficace, en priorisant uniquement les vulnérabilités qui sont applicables ou exploitables dans le contexte de la base de code en cours d’exécution, réduisant ainsi le bruit.

Une note sur les scanners de sécurité agentiques : avantages et limites

L’introduction de chercheurs en sécurité dotés de LLM représente une avancée considérable dans le domaine de la sécurité applicative. Ces outils vont au-delà de l’analyse traditionnelle en s’appuyant sur le raisonnement des grands modèles de langage (LLM) pour comprendre le comportement du code comme le ferait un expert humain.

Bien que ces outils agentiques soient un complément nécessaire à la boîte à outils pour améliorer la qualité du code de première partie, leur portée est limitée et ils interviennent trop tôt dans le cycle de développement pour arrêter les risques systémiques de la chaîne d’approvisionnement décrits par l’INCD.

La promesse – ou là où les outils alimentés par les LLM excellent :

• Amélioration de l’analyse du code: les LLM peuvent analyser de grandes quantités de code à une vitesse remarquable, ce qui permet d’identifier des schémas subtils et des vulnérabilités que les outils SAST traditionnels risqueraient de manquer.
• Amélioration de l’expérience des développeurs : en s’intégrant dans les workflows de développement, les LLM peuvent fournir un feedback en temps réel, aidant ainsi les développeurs à écrire un code plus sûr dès le départ. En outre, l’utilisation de l’IA gagne en popularité et les développeurs sont plus enclins à l’adopter que d’autres solutions plus intrusives.
• Augmentation des SAST existants : utilisés parallèlement aux outils SAST existants, les scanners LLM peuvent fournir une couche supplémentaire d’examen et de compréhension, améliorant ainsi la sécurité globale du code. Il est recommandé de les utiliser en parallèle avec des solutions SAST établies jusqu’à ce que leur efficacité et leur fiabilité soient entièrement validées.

Les limites – ou là où le risque systémique persiste :

1. Ils sont centrés sur le code source : les LLM agentiques se concentrent principalement sur le code une fois qu’il est écrit et validé dans un dépôt. Ils ne gèrent pas eux-mêmes les artefacts binaires.
2. Ils passent à côté du point d’ingression : les attaques les plus dangereuses ciblent directement l’entrée principale, à savoir le registre de packages. Si un développeur crée un package malveillant à l’aide d’une technique telle que le typosquattage, ce package se trouve désormais au sein de votre organisation. L’attaque a réussi avant même que le code ne soit prêt à être analysé par un LLM.
3. Ils manquent de gouvernance binaire : ils ne fournissent pas la visibilité de bout en bout nécessaire pour suivre, sécuriser et gouverner l’artefact compilé tout au long de son cycle de distribution et de déploiement ; une capacité essentielle pour une véritable sécurité de la chaîne d’approvisionnement.

Les outils shift left sont nécessaires pour la détection précoce et la réduction des coûts de remédiation, et il est passionnant de voir émerger de nouvelles technologies agentiques dans ce domaine. Nous encourageons les équipes à tirer pleinement parti de ces outils, mais à le faire de manière responsable : les utiliser seuls est extrêmement risqué car vous ignorez une vaste surface d’attaque.

Sécuriser la chaîne d’approvisionnement logicielle grâce à une protection E2E, intégrale et centrée sur les binaires

La voie vers des versions rapides et fiables est claire : pour garantir une intégrité logicielle robuste et résoudre le dilemme entre vitesse et sécurité, les organisations doivent adopter l’architecture fondée sur trois piliers essentiels : une sécurité de bout en bout, native et intégrée, et centrée sur les binaires.

Alors que de nouveaux outils d’IA puissants offrent des perspectives complémentaires précieuses, seule une plateforme centralisée peut fournir la gouvernance, le contrôle et la protection binaire nécessaires pour sécuriser la chaîne d’approvisionnement logicielle moderne.

Prêt à mettre en place une chaîne logistique logicielle véritablement sécurisée sans sacrifier la rapidité ? Pour explorer les capacités de la plateforme JFrog, lancez un essai gratuit ou planifiez une démonstration dès aujourd’hui.