Rapport 2024 sur les risques liés à la sécurité des produits Red Hat : CVE, XZ Backdoor, SSCA, IA…

Préparez-vous un bon café et plongez-vous dans le Rapport 2024 sur les risques liés à la sécurité des produits Red Hat de Red Hat Product Security En tant que personne cherchant à me tenir informée de l'écosystème open source et de ses défis en matière de sécurité, j'ai trouvé le rapport de cette année nettement plus long. Toutefois, sa profondeur et ses détails n'ont pas déçu. La question de l'IA est d'ailleurs un ajout notable au rapport de cette année. 

Le jeu des chiffres : ça monte, ça monte, et... attendez, quoi ?

Tout d'abord, examinons les chiffres bruts. Les avis de sécurité Red Hat ont atteint un nouveau sommet en 2024, avec 2 975 avis enregistrés.. Une hausse constante est enregistrée depuis ces dernières années. Il est intéressant de noter que les avis Important et  Modéré ont connu une augmentation significative, et que les avis Critique ont légèrement diminué, ce qui favorise l'adoption de pratiques de sécurité plus proactives et une détection plus rapide.

Le nombre de vulnérabilités et d'expositions courantes (CVE) a bondi pour atteindre 4 272, soit une augmentation significative par rapport aux années précédentes, qui étaient relativement stables. Quelle en est la cause ? Le rapport met en évidence que l'organisation Linux Kernel Organization est devenue une CNA (CVE Numbering Authority) en février 2024. L'organisation a commencé à attribuer des CVE à de nombreux problèmes de noyau, dont beaucoup n'avaient pas reçu d'attribution auparavant. Si l'on exclut ces nouvelles CVE kernel.org, la ligne de tendance semble plus familière, avec une légère hausse, qui reflète probablement la gamme croissante de Red Hat, mais rien d'alarmant. 

En approfondissant le sujet, la plupart des nouvelles CVE du noyau sont notées Modéré et  Faible, et seulement 45 % des CVE attribuées par kernel.org en 2024 affectaient les noyaux Red Hat Enterprise Linux (RHEL). En outre, l'attention doit rester concentrée sur ces vulnérabilités Critiques et Importantes qui correspondent aux emplacements où de véritables tentatives d'exploitation sont détectées. Cette approche est validée par la réactivité de Red Hat, qui a traité plus de la moitié des CVE Critiques, en fournissant les premiers correctifs en 7 jours ou moins, et 3 correctifs le jour 0.

Sans le contexte ci-dessus, en examinant ces indicateurs, vous pourriez vous demander ce que fait Red Hat. Le nombre brut de CVE a considérablement augmenté, mais le profil de risque sous-jacent des produits Red Hat n'a pas réellement changé en parallèle. Ces chiffres confirment qu'il ne suffit pas de se baser uniquement sur le nombre de CVE ; vous devez également tenir compte de la sévérité, de la capacité d'exploitation et de la pertinence. L'accent mis par Red Hat sur l'application des correctifs de problèmes Critiques et  Importants est validée par les données, montrant que c'est là que se produit la plupart des exploitations réelles, prouvant qu'une approche basée sur les risques s'avère la plus pertinente.

XZ Backdoor : le sujet tabou

Qui peut parler de sécurité en 2024 sans mentionner l'incident XZ Backdoor ? Il s'agit d'une attaque conçue contre la chaîne logistique qui continue de hanter la communauté open source. Un chargé de maintenance de confiance, qui a passé plus de 2 ans à établir des relations au sein de la communauté, a introduit une porte dérobée sophistiquée dans la bibliothèque XZ. Si Andres Freund n'avait pas remarqué le décalage de performance que cette attaque entraînait, elle aurait pu compromettre l'accès à Secure Shell (SSH) sur d'innombrables systèmes.

Dans ce rapport, Red Hat revient sur la réponse de l'open source, tout en prenant le temps de mettre en évidence les risques inhérents et de présenter les atouts du modèle open source. Cette analyse et ce partage d'informations rapides et collaboratifs ont été possibles, car le code source et les interactions étaient publics. Le rapport aborde également les obstacles au sein de son propre pipeline, comme les tests Fedora et l'ingénierie qualité de RHEL, qui auraient pu le détecter, même s'il est impossible de le dire avec certitude.  

L'incident XZ Backdoor a été un signal d'alarme. Cet incident aura des effets durables sur la confiance et les processus de contribution dans l'open source. Les attaques contre la chaîne logistique se multiplient et se complexifient. Les attaquants trouvent des moyens de cibler des outils courants et du code partagé que les développeurs utilisent quotidiennement, dans l’espoir de causer des problèmes à grande échelle. Ces types d'attaques montrent que les éditeurs de logiciels ont besoin de plusieurs niveaux de protection : vérifier automatiquement la sécurité des éléments de code préconstruits utilisés ; disposer d'une chaîne d'assemblage sécurisée pour la création des logiciels et inspecter minutieusement tout nouvel élément avant de l'ajouter. Il est bon de savoir que Red Hat avait mis en place plusieurs contrôles qui auraient pu détecter le récent problème de sécurité de XZ, soulignant que ces couches de sécurité sont véritablement utiles. La sécurité ne sera jamais une activité ponctuelle.

Problèmes de la chaîne d'approvisionnement

Le nombre croissant d'attaques de la chaîne d'approvisionnement des logiciels (SSCA) et la dépendance aux composants open source sont presque difficiles à croire, pourtant elles sont statistiquement prouvées. L'analyse de Black Duck dresse un tableau troublant : pas moins de 97 % des bases de code commerciales reposent sur des composants open source. Si cette approche augmente la vitesse de l'innovation et du développement, elle constitue également une cible extrêmement attrayante pour les acteurs malveillants, les données montrant qu'ils ne manquent aucune occasion. Le suivi des SSCA publiées par Red Hat a révélé 89 incidents en 2024, soit une augmentation considérable de 68 % d'une année sur l'autre. Le rapport de Sonatype fait écho à cette tendance déroutante. Les chaînes d'approvisionnement des logiciels sont de plus en plus assiégées.

La compromission de XZ Util et les acteurs de menace nord-coréens qui ont eu recours à des stratégies de fraude à l'emploi complexes pour obtenir un accès privilégié ne sont que deux exemples des tactiques évolutives utilisées par les acteurs malveillants. Le problème réside dans le fait que, pour la plupart de ces attaques, le mobile est en grande partie inconnu, et un grand nombre d'attaques demeurent non réclamées. Il est difficile de se défendre efficacement si l'on ne comprend pas parfaitement qui attaque ou pourquoi. Nous savons que certains attaquants cherchent de l'argent ou essaient d'espionner, mais nous ignorons l'objectif de nombreuses attaques. Cette situation complique l'ensemble des cybermenaces et rend la prédiction ou la modélisation difficile. Si le ciblage des développeurs et de leurs points d'accès est parfaitement logique du point de vue d'un attaquant, car ils détiennent les clés du royaume, cela implique aussi que l'élément humain qui participe à la construction de notre monde numérique est une cible de choix.

Ces SSCA démontrent l'exploitation croissante des dépendances open source critiques par des attaquants anonymes qualifiés. Nous ne pouvons pas simplement cesser d'utiliser l'open source, étant donné qu'il constitue la base des logiciels modernes. C'est pourquoi un changement fondamental s'impose. Nous avons besoin de protocoles de sécurité plus proactifs intégrés tout au long du cycle de développement, et pas seulement lorsque nous réagissons en cas de faille. Cela inclut une meilleure vérification des dépendances, des pratiques de sécurité robustes pour les développeurs et, comme le souligne la réponse de XZ, un modèle de responsabilité partagée où les fournisseurs, les communautés et les utilisateurs investissent dans la sécurisation de l'écosystème. La simple ampleur de notre dépendance exige un investissement proportionnel à sa sécurité. Nous essayons toujours de rattraper notre retard face à des adversaires qui ont clairement plusieurs longueurs d'avance sur nous.

Ode à l'IA

Au cours de l'année dernière, l'IA générative (gen AI) a explosé, allant des chatbots aux assistants de codage en passant par les outils de création. La dynamique ne cesse de s'accélérer, l'IA générative devrait augmenter à un taux de 37 % chaque année jusqu'en 2030. Cette projection est pour le moins déroutante. 

Mais, comme pour toute nouvelle technologie, il y a une phase utopique où chacun se concentre sur ce qu'elle peut accomplir. À quelle vitesse peut-elle fonctionner ? Combien peut-elle créer ? Comment pourrait-elle changer notre façon de faire les choses ?

Maintenant que nous percevons la valeur réelle de l'IA, en particulier dans les secteurs très réglementés comme la santé, la finance et les services publics, où les erreurs peuvent avoir des conséquences majeures, il nous faut commencer à réfléchir  sur les sujets sérieux. Comment garantir la sécurité et la fiabilité de l'utilisation de l'IA ? Pouvons-nous avoir confiance qu'elle ne causera pas de problèmes ou ne divulguera pas d'informations privées ? Les décideurs affirment que la protection des données est déjà la principale préoccupation des personnes concernant l'IA cette année. Cela a tout son sens. Personne ne souhaite que ses informations personnelles soient divulguées ni que l'IA prenne de mauvaises décisions parce qu'elle n'a pas été conçue de manière sécurisée. Comme indiqué ci-dessus, nous avons déjà quelques cibles open source à haute visibilité. 

Ce que j'apprécie, c'est que nous ne nous contentons pas de suivre le mouvement de l'IA ; nous cherchons activement à déterminer comment rendre l'IA sécurisée et sûre. Toutefois, cette tâche n'est pas chose aisée. 

L'un des premiers points que Red Hat souligne dans BBuilding Trust: Foundations of Security est la nécessité de séparer une vulnérabilité de sécurité de l'IA d'un problème de sûreté de l'IA :

• Vulnérabilité de la sécurité : un pirate informatique qui cherche le moyen de s'introduire  dans le système d'IA.
• Problème de sûreté : l'IA elle-même qui génère quelque chose d'inexact, de biaisé, voire de dangereux, même si personne ne l'a « hackée ».

Ces problèmes doivent être abordés sous un autre angle, car corriger un bogue n'est pas la même chose qu'apprendre à l'IA à ne pas être toxique ou à ne pas inventer des informations. Ils nécessitent des cadres de référence différents.

Il est rassurant de constater que des entreprises comme Red Hat, des gouvernements comme l'Union européenne et les États-Unis, ainsi que divers groupes industriels travaillent activement à résoudre ces défis. Ils s'efforcent de créer des lignes directrices, des normes et des méthodes pour suivre les différents risques liés à l'IA. Ils cherchent à développer cette technologie de façon responsable, dès la conception, en formant leurs ingénieurs et en créant des architectures sécurisées. Ce qui est significatif, c'est que Red Hat ne se contente pas de parler, nous construisons.

Que signifie tout ceci ? L'essor de l'IA est enthousiasmant et pourrait changer beaucoup de choses. En définitive, tout repose sur la confiance. Comme dans toute bonne relation, la confiance est fondamentale. Notre relation avec l'IA doit être basée sur la confiance pour que nous puissions en tirer le plein potentiel, et cela va bien au-delà des démonstrations tape-à-l'œil. Cela résulte d'un travail acharné en coulisse pour s'assurer que la technologie est sûre, sécurisée et qu'elle se comporte comme prévu. Il semble que les bonnes personnes se concentrent sur cet aspect, ce qui est une bonne nouvelle. Nous devons faire preuve de prudence et mettre en place des garde-fous maintenant, plutôt que d'essayer de résoudre des problèmes majeurs plus tard. Pour que cela fonctionne, nous avons besoin que les gens aient confiance en l'IA !  

Dans les coulisses : le dynamisme du SDLC

En 2024, Red Hat a prouvé que derrière chaque produit fiable se cache un travail acharné pour s'assurer que rien ne passe entre les mailles du filet. Notre approche ne se limite pas au respect des normes de sécurité NIST. Red Hat développe ses propres méthodes uniques pour aider à vérifier que tout ce que nous créons, y compris les technologies d'IA, est fiable et digne de confiance dès le départ.

Le cycle de développement logiciel sécurisé de Red Hat (RHSDLC), qui fournit notre plan pour la création de logiciels axés sur la sécurité, est désormais plus intelligent et encore mieux aligné sur les défis de sécurité actuels du monde réel. Mais nous ne nous contentons pas de cocher toutes les cases. Nous créons nos propres standards, tels que le RHSDLC, pour nous assurer que la chaîne d'approvisionnement logicielle est sécurisée de bout en bout en faisant évoluer la procédure des approbations d'exploitation de la sécurité (SOA). Cela inclut la vérification des outils tiers, l'automatisation des contrôles et le signalement des risques avant qu'ils ne deviennent des problèmes. C'est comme détecter la fuite alors qu'elle n'est encore qu'une goutte, au lieu d'attendre l'inondation. Nous nous efforçons de renforcer la confiance des clients dans nos produits en explorant minutieusement les détails de sécurité et en accordant la priorité à la confiance, à la transparence et à la résilience.

J'ai apprécié la standardisation des révisions d'architecture de sécurité (SAR) au sein du RHSDLC. Ces révisions confirment les principes de sécurité classiques et éprouvés, tels que « n'accordez l'accès qu'au strict nécessaire », « superposez vos défenses » et de s'assurer que la sécurité est intégrée à la conception du produit dès le premier jour. 

Enfin, il y a RapiDAST. Si vous vous intéressez à l'open source ou même au développement d'applications, cet outil est un trésor caché. Il s'agit de l'outil de test dynamique de la sécurité des applications de Red Hat, et en 2024, il a bénéficié de sérieuses mises à niveau. RapiDAST n'est pas seulement devenu plus puissant, il est aussi devenu plus facile à utiliser. Il est par exemple en mesure de prendre en charge les tests des opérateurs Kubernetes, d'offrir une meilleure automatisation et une interface beaucoup plus simple. Désormais, il peut exporter les résultats directement vers Google Cloud Storage, ce qui rend la collaboration plus efficace.

Red Hat intègre tout cela directement dans ses pipelines CI/CD, les systèmes mêmes que les développeurs utilisent quotidiennement pour créer et lancer des produits. Pour ceux qui ont recours à des outils, qu'il s'agisse de développeurs, de professionnels de l'informatique ou d'utilisateurs finaux cherchant à sécuriser leurs systèmes, un engagement envers un développement axé sur la sécurité est primordial. Dans un monde où les cybermenaces sont constantes, il est rassurant de savoir que votre éditeur de logiciels se concentre intensément sur la sécurité, de la phase de conception aux tests et au suivi des composants. Chez Red Hat, la sécurité est considérée comme un élément essentiel de la qualité, et non comme un élément secondaire.

Rendez-vous en 2025

Le rapport de cette année rappelle que la sécurité est en constante évolution. Les utilisateurs doivent prendre en compte de nombreux éléments, tels que les changements dans la manière de signaler les CVE, les risques inhérents à la chaîne logistique, l'impact croissant de l'IA et la hiérarchisation des vulnérabilités.

Il est très important de disposer de rapports transparents comme celui-ci. Ils nous aident tous (des développeurs aux équipes informatiques en passant par les lecteurs curieux comme moi) à voir ce qui se passe, à comprendre les défis et à faire des choix plus éclairés. De mon point de vue,  il ne s'agit pas seulement d'anticiper les problèmes ; la manière dont nous y répondons est tout aussi cruciale. La façon dont la communauté open source s'est unie lors d'incidents comme le XZ Backdoor montre toute la puissance de la collaboration.

Lire le rapport complet Rapport 2024 sur les risques liés à la sécurité des produits Red Hat.