Par souci d'efficacité et de gain de temps, les développeurs utilisent couramment des codes tiers pour créer leurs applications. Toutefois, cette dépendance à l'égard de composants externes, en particulier les logiciels libres, présente des risques importants, notamment des vulnérabilités et des problèmes de licence. Selon une enquête GitHub réalisée en 2023, 31 % des développeurs considèrent la recherche et la correction des failles de sécurité comme leur deuxième tâche la plus importante, juste après l'écriture du code (32 %).
Par conséquent, de nombreuses organisations s'inquiètent de leur dépendance à l'égard des logiciels libres, qui sont fréquemment la cible de pirates informatiques. Les organisations sont confrontées à la vulnérabilité accrue de la chaîne d'approvisionnement des logiciels et à la nécessité de comprendre comment atténuer efficacement les risques à la suite des récentes attaques très médiatisées.
Un rapport de recherche d'ESG révèle que 91 % des organisations ont subi un incident dans la chaîne d'approvisionnement des logiciels au cours des 12 derniers mois. Les incidents les plus courants sont les suivants
Des vulnérabilités importantes telles que Log4J, Curl, Apache Struts et OpenSSL ont toutes conduit à de nombreux cas de dommages opérationnels. Elles mettent en évidence les graves conséquences pour les organisations de l'exploitation d'une seule faiblesse au sein de la chaîne d'approvisionnement en logiciels. En réponse à ces risques croissants, les organismes de réglementation du monde entier mettent l'accent sur la transparence et la sécurité des logiciels. L'adoption d'une Software Bill of Materials (SBOM) devient une stratégie clé pour gérer les risques de la chaîne d'approvisionnement en logiciels.
Le règlement SBOM prend de l'ampleur
Les réglementations SBOM sont de plus en plus répandues. De nombreux gouvernements ont publié des recommandations concernant la mise en œuvre du SBOM. Aux États-Unis, les recommandations du SBOM sont incluses dans plusieurs lignes directrices gouvernementales, notamment :
En 2023, la CISA a publié trois documents clés pour faire progresser l'adoption des SBOM. Ces documents portent sur l'augmentation de l'utilisation du SBOM, l'exploration de nouvelles technologies et applications, et la promotion de la collaboration communautaire.
En Europe, l'Agence européenne pour la cybersécurité (ENISA) a publié un document intitulé "Guidelines for Securing the Supply Chain for the Internet of Things" (Lignes directrices pour la sécurisation de la Supply Chain de l'internet des objets), qui donne aux entreprises des indications précieuses pour améliorer la cybersécurité et gérer les risques liés à la chaîne d'approvisionnement des logiciels.
D'autres pays ont publié des lignes directrices similaires, notamment
conseille aux organisations d'utiliser les SBOM pour évaluer les risques associés aux composants logiciels qu'elles utilisent et pour identifier et traiter les vulnérabilités de ces composants.
Dans le "Manuel de sécurité de l'information : Guidelines for Software Development", l'ACSC recommande d'utiliser les SBOM pour améliorer la transparence de la chaîne d'approvisionnement cybernétique, en facilitant l'identification et la gestion des risques de sécurité liés aux composants logiciels individuels utilisés dans les applications.
Dans ses "Recommandations pour améliorer la résilience de la Supply Chain numérique du Canada", le CST préconise l'utilisation de SBOM pour accroître la transparence et lutter efficacement contre les menaces pesant sur la chaîne d'approvisionnement en logiciels.
Comment la norme PCI DSS rend nécessaire la création d'un SBOM
Reconnaissant l'escalade des risques liés aux données des cartes de paiement, la norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) est devenue une force motrice pour l'adoption des SBOM. La dernière version, PCI DSS 4.0, impose l'utilisation de SBOM, soulignant leur rôle essentiel dans la protection des informations sensibles. En fournissant un inventaire détaillé des composants logiciels, les SBOM permettent aux organisations d'identifier et de traiter les vulnérabilités de manière proactive, réduisant ainsi le risque de violations de données coûteuses et de pertes financières.
Établie en 2004, la norme PCI DSS est une norme de sécurité complète conçue pour protéger les informations relatives aux cartes de crédit. Elle définit un ensemble d'exigences rigoureuses pour les entreprises qui traitent des transactions par carte de crédit, adaptées au volume de transactions traitées chaque année. La version 4.0 de la norme PCI DSS, publiée en 2022, a introduit des changements importants, notamment le mandat SBOM, afin de répondre à l'évolution des menaces. La conformité à la norme PCI DSS v4.0 est obligatoire d'ici avril 2024, avec des exigences spécifiques introduites progressivement d'ici le 31 mars 2025.
Source : PCI DSS V4.0 en bref
En rendant les SBOM obligatoires, la norme PCI DSS permet aux organisations d'acquérir une compréhension globale de leur écosystème logiciel, ce qui leur permet d'identifier les vulnérabilités et d'y remédier de manière proactive. Cette approche réduit considérablement le risque de violations de données coûteuses et de pertes financières.
Une nouvelle version de la norme PCI DSS, la version 4.0.1, a été publiée à la mi-2024. Cela signifie que la version précédente, 4.0, ne sera plus valable après le 31 décembre 2024. Toutefois, la nouvelle version n'ajoute ni ne supprime aucune règle et ne modifie pas les délais. Par conséquent, les informations sur les exigences du SBOM contenues dans ce blog s'appliquent aux versions 4.0 et 4.0.1.
Conformité avec l'exigence 6.3.2 de la norme PCI DSS
L'exigence SBOM de la norme PCI DSS v4.0 fait partie des améliorations plus larges apportées à la norme PCI DSS dans sa dernière itération. Introduite parmi les 64 nouvelles exigences de la version 4.0, l'exigence SBOM répond spécifiquement à la nécessité pour les organisations de maintenir un inventaire des composants logiciels, en se concentrant particulièrement sur les logiciels sur mesure et personnalisés.
Cette exigence est classée dans l'exigence 6 de la norme PCI DSS, qui prévoit la création et le maintien de systèmes et d'applications sécurisés grâce à la mise en œuvre de mesures de sécurité strictes et à la réalisation régulière d'évaluations et de mises à jour des vulnérabilités. Cette exigence est essentielle pour réduire les risques posés par les vulnérabilités des logiciels et protéger les données des titulaires de cartes. La section 6 couvre cinq domaines principaux :
- 6.1 Les processus et les mécanismes de développement et de maintenance de systèmes et de logiciels sûrs sont définis et compris.
- 6.2 Les logiciels sur mesure et personnalisés sont développés en toute sécurité.
- 6.3 Les failles de sécurité sont identifiées et traitées.
- 6.4 Les applications web destinées au public sont protégées contre les attaques.
- 6.5 Les modifications apportées à tous les composants du système sont gérées en toute sécurité.
Plus précisément, l'exigence 6.3.2 est une mise à jour importante qui résulte de plusieurs violations où des vulnérabilités dans des composants tiers, ou des violations de fournisseurs de composants tiers, ont conduit à une compromission des données des titulaires de cartes. L'exigence est libellée comme suit :
6.3.2.b. Examiner la documentation du logiciel, y compris pour les logiciels sur mesure et personnalisés qui intègrent des composants logiciels tiers, et la comparer à l'inventaire pour vérifier que l'inventaire inclut les logiciels sur mesure et personnalisés et les composants logiciels tiers.
Les organisations doivent documenter et gérer de manière exhaustive les composants et services spécifiques utilisés dans leurs applications. Bien que certaines de ces informations aient pu être couvertes par des diagrammes de flux de données, les nouvelles exigences requièrent une documentation beaucoup plus détaillée. Le suivi de ces détails peut s'avérer difficile au fur et à mesure que les composants sont mis à jour et modifiés. Il est conseillé d'utiliser un modèle standard pour capturer ces informations. En outre, certains référentiels de code source, comme GIT, peuvent offrir des outils permettant d'exporter une liste des composants utilisés. Au minimum, votre inventaire devrait inclure
- Composants d'application (généralement des projets de référentiel)
- Liste des composants tiers
- Liste des dépendances de l'application (c'est-à-dire Tomcat, Jboss, .NET, Middleware)
- Liste des scripts autorisés pour les pages de paiement
Comment OPSWAT SBOM peut aider à répondre aux exigences de la norme PCI DSS
Les réglementations exigent de plus en plus souvent des SBOM pour garantir la sécurité de la chaîne d'approvisionnement en logiciels. Cependant, les organisations ont du mal à dresser des inventaires précis de la composition de leurs codes logiciels.
Source : Rapport EGS 2024
La création de SBOM précis et complets représente toutefois un défi de taille pour les organisations. Ces documents exigent un inventaire méticuleux des composants logiciels, nécessitant des informations détaillées sur leurs origines, leurs versions et leurs interdépendances. En l'absence de SBOM précis, les organisations ont du mal à identifier, évaluer et atténuer efficacement les risques inhérents à leur chaîne d'approvisionnement en logiciels.
Lignes directrices pour la création de SBOM
OPSWAT SBOM automatise la génération de SBOM pour le code et les conteneurs, ce qui renforce la sécurité et aide à la conformité dans la chaîne d'approvisionnement des logiciels.
- Identifier tous les composants et dépendances
Identifier avec précision tous les composants logiciels, y compris les logiciels libres et les bibliothèques tierces, avec leurs versions et leurs dépendances. Cela constitue la base d'un SBOM solide. - Évaluer les risques liés aux logiciels libres
Évaluez les risques potentiels associés aux composants OSS. Tenez compte de facteurs tels que la conformité des licences, les failles de sécurité et l'état de la maintenance. Classez les composants par ordre de priorité en fonction de leur criticité pour le logiciel. - Recherche des vulnérabilités des logiciels libres
Utiliser des outils d'analyse des vulnérabilités et de génération de SBOM pour identifier les vulnérabilités connues dans les composants OSS. Classer les vulnérabilités par ordre de priorité en fonction de leur gravité et de leur impact potentiel sur le logiciel.
Utilisation de OPSWAT SBOM
OPSWAT SBOM automatise la génération de SBOM pour le code et les conteneurs, ce qui renforce la sécurité et aide à la conformité dans la chaîne d'approvisionnement des logiciels.
Voici comment vous pouvez utiliser OPSWAT SBOM pour générer des SBOM de manière efficace :
En fournissant un inventaire de toutes les bibliothèques et de tous les composants open-source utilisés dans une application, OPSWAT SBOM aide à gérer les vulnérabilités liées aux dépendances dans la chaîne d'approvisionnement des logiciels, permettant ainsi aux utilisateurs d'identifier et de corriger les vulnérabilités dans les applications de manière efficace.
En plus d'identifier les vulnérabilités, OPSWAT SBOM valide les licences associées à chaque composant logiciel. Cela permet de garantir le respect des conditions de licence et d'éviter les pièges juridiques potentiels. En savoir plus sur le rôle crucial de la détection des licences dans les logiciels libres.
OPSWAT Le SBOM prend en charge plus de 10 langages de programmation, dont Java, JavaScript, Go, PHP et Python. Cette prise en charge étendue garantit une couverture complète du site vulnerability detection dans divers écosystèmes de développement de logiciels.
Sanctions en cas de non-conformité
Les organisations qui ne respectent pas les normes PCI DSS, y compris l'exigence SBOM, peuvent encourir des pénalités financières allant de 5 000 à 100 000 dollars par mois. Ces amendes peuvent augmenter au fil du temps si les problèmes de conformité ne sont pas résolus.
Outre les sanctions financières, la non-conformité à la norme PCI DSS peut entraîner d'importants problèmes juridiques et opérationnels. Les conséquences juridiques peuvent inclure des poursuites judiciaires, des frais de défense et des règlements substantiels. En outre, la non-conformité peut déclencher des audits fédéraux par des agences telles que la Federal Trade Commission (FTC), entraînant des pénalités supplémentaires.
Prochaines étapes de la mise en conformité avec la norme PCI DSS 4.0
L'intégration de SBOM dans le cadre de la norme PCI DSS 4.0 marque un tournant décisif vers une chaîne d'approvisionnement en logiciels plus sûre. En tirant parti d'outils avancés tels que OPSWAT SBOM, les organisations peuvent gérer efficacement les risques liés aux logiciels libres, améliorer la conformité et se protéger contre les violations de données coûteuses.
L'utilisation des SBOM n'est plus une option mais une nécessité. En prenant des mesures proactives pour comprendre et traiter les dépendances logicielles, les organisations peuvent construire une base de sécurité solide qui protège leurs opérations et renforce la confiance des clients.
Améliorez votre sécurité
Posture avec OPSWAT
Commencez à gérer les dépendances de
dès maintenant.
