Normes PCI et exigences de sécurité open source : comment s’y conformer ?

Face à l’utilisation croissante de la sécurité open source dans le développement logiciel moderne, il est urgent de veiller à ce que l’open source soit utilisé de manière sécurisée. Pourtant, les pratiques de sécurité open source ne sont pas encore généralisées : selon un récent rapport de Snyk, 37 % des développeurs open source ne réalisent aucun test de sécurité dans le cadre de leur processus d’intégration continue (CI) ! La croissance de l’open source, conjuguée au retard des normes de sécurité, a amené de nombreux organismes de réglementation et acteurs de la veille sectorielle à adopter des règles plus strictes et plus claires pour protéger les applications intégrant du code open source.

Le PCI prend le relais en matière d’open source

En janvier 2019, le Payment Card Industry Security Standards Council a lancé le PCI Software Security Framework (SSF), axé sur la sécurité des applications. La norme Secure Software Lifecycle (SLC) a également été ajoutée. Cette sous-section du PCI Software Security Framework définit les exigences de sécurité et les procédures d’évaluation permettant aux éditeurs de logiciels de valider leur gestion de la sécurité des logiciels de paiement tout au long de leur cycle de vie.

(Remarque : ce nouveau cadre remplace les directives actuelles du PCI Payment Application Data Security Standard [PCI PA-DSS], qui sera retiré au cours des prochaines années.)

Chez Snyk, nous sommes ravis de voir le PCI reconnaître l’importance de sécuriser les composants open source dans le code et encourager les organisations à « décaler vers la gauche » la prise en charge de la sécurité tout au long du cycle de développement logiciel. Plus nous intégrons tôt les bonnes pratiques de sécurité au cycle de vie logiciel, en particulier pour l’open source, plus nos applications sont sécurisées.

Cela dit, comme pour de nombreux autres cadres de conformité, il peut être difficile de comprendre et d’appliquer de nouvelles règles. Nous souhaitons donc vous éclairer sur les nouvelles règles de conformité PCI et vous expliquer comment vous conformer aux exigences de la norme mise à jour qui concernent l’open source.

Qui est concerné par les mises à jour PCI ?

La norme PCI Secure Software Standard (et la norme SLC sous-jacente) s’applique aux logiciels de paiement vendus, distribués ou concédés sous licence à des tiers pour effectuer des transactions de paiement. Le PCI Software Security Framework concerne tout particulièrement les éditeurs qui développent des applications de traitement des paiements et ceux qui vendent ces solutions à d’autres entreprises. La mise à jour souligne que les responsables de la sécurité comme les équipes d’ingénierie doivent assumer la responsabilité du respect des normes de conformité.

Les entreprises qui acceptent des paiements doivent également se conformer à d’autres règles définies dans les directives PCI-DSS. Toutefois, les normes abordées dans cet article concernent directement les développeurs de logiciels.

Fini le « une fois pour toutes » : la continuité est essentielle

L’aspect peut-être le plus important de la nouvelle norme est la notion de « sécurité applicative continue ». Elle impose aux organisations de surveiller en permanence les vulnérabilités et les défenses, et de s’adapter en cas d’évolution des menaces. Elles doivent également tester en continu les contrôles de sécurité des applications et prouver que ceux-ci ne se sont pas affaiblis ni révélés inefficaces au fil du temps. C’est une exigence élevée, et c’est une bonne chose. Elle incite à intégrer la sécurité au processus CI/CD plutôt qu’à la traiter après coup.

Qu’est-ce qui motive les mises à jour PCI ? Pourquoi maintenant ?

Pourquoi ces normes ont-elles été mises à jour ? Comme nous l’avons indiqué en introduction, le développement logiciel a naturellement évolué au fil des ans. Les normes PCI mises à jour répondent de manière réfléchie à cette évolution en faisant également évoluer l’approche de la sécurité logicielle. Plus précisément, les stratégies de développement logiciel s’appuient de plus en plus sur des composants open source. Il était donc nécessaire d’ajouter des exigences et des contrôles qui les concernent. Dans notre rapport State of Open Source Security 2019, nous avons présenté plusieurs statistiques sur le sujet, dont ces chiffres révélateurs :

• Les vulnérabilités dans les bibliothèques applicatives ont augmenté de 88 % en deux ans 81 % des répondants estiment que les développeurs devraient être responsables de la sécurité, mais ne disposent pas des moyens nécessaires Les responsables de projets open source veulent sécuriser leurs logiciels, mais 70 % manquent de compétences

En plus de la généralisation du développement open source, de nombreuses organisations intègrent désormais des outils de sécurité à leur pipeline DevOps. Ces outils sont aussi devenus plus proactifs et plus efficaces au fil du temps. Il est donc à la fois nécessaire et, bonne nouvelle, plus facile que jamais d’assurer une sécurité robuste dans les cycles de développement et d’intégration continus.

La place de l’open source dans les nouvelles mises à jour PCI

Examinons en détail les aspects des nouvelles règles PCI qui s’appliquent aux composants logiciels open source. (Vous pouvez également consulter les normes dans leur intégralité ici.)

1. Responsabilité des responsables de la sécurité

Le texte : Section 1.1 — La haute direction de l’éditeur attribue formellement à une personne ou à une équipe la responsabilité de garantir la sécurité des produits et services de l’éditeur.

Ce que cela signifie pour vous : les responsables de la sécurité des grandes organisations doivent assumer la responsabilité de la sécurité et apporter aux processus de développement et aux outils les changements nécessaires pour satisfaire aux exigences PCI mises à jour.

Comment Snyk peut vous aider : les responsables de la sécurité ont déjà de nombreuses priorités à gérer. Snyk peut simplifier la mise en conformité avec les nouvelles normes PCI en offrant une visibilité sur les dépendances open source et les risques liés aux licences, afin de permettre leur prise en charge en temps utile et de manière appropriée.

2. Le rôle des développeurs

Le texte : Section 1.2.a — Les personnes (y compris le personnel de tiers) participant à la conception, au développement, aux tests et à la maintenance des produits et services de l’éditeur doivent se voir attribuer la responsabilité et l’obligation de rendre compte de la conformité du logiciel à la stratégie de sécurité de l’éditeur et à toutes les exigences de sécurité applicables.

Ce que cela signifie pour vous : les nouvelles exigences mentionnent explicitement la participation et la responsabilité des développeurs (« personnel chargé du développement logiciel »), qui doivent prendre part aux étapes définies pour assurer la conformité.

Comment Snyk peut vous aider : l’approche de Snyk, qui place les développeurs au premier plan, les encourage à adopter facilement les bonnes pratiques de sécurité. Snyk leur permet de détecter et de corriger les vulnérabilités dans le cadre de leur processus de développement logiciel habituel. Snyk facilite également la création d’une demande de pull request de correction en un clic et l’automatisation des corrections dans Git, afin que les développeurs puissent rapidement remédier aux vulnérabilités détectées.

3. Composants open source

Le texte : Section 3.2.b — Lorsque des composants logiciels open source sont utilisés dans un logiciel, l’évaluateur doit examiner les éléments fournis par l’éditeur, notamment la documentation des processus et les résultats des évaluations, afin de confirmer que ces composants sont gérés.

Ce que cela signifie pour vous : l’open source peut être un formidable atout pour le développement logiciel, mais il est essentiel de faire preuve de diligence avant d’intégrer des composants open source à votre application. L’organisation doit :

• tenir un inventaire de tous les composants open source utilisés, y compris les images de conteneurs

• mettre en place un processus mature d’analyse et d’atténuation des vulnérabilités

• surveiller les vulnérabilités des composants open source

• mettre en œuvre une stratégie d’application des correctifs

Comment Snyk peut vous aider : Snyk permet aux clients de cartographier les dépendances de leurs applications, de mettre en évidence les vulnérabilités actuelles et de rechercher en continu les nouvelles vulnérabilités dans une base de données complète. Snyk offre des fonctionnalités complètes de correction et de résolution, avec des demandes de pull request automatisées qui accélèrent le triage et la correction. En somme, Snyk automatise la mise en conformité avec la section 3.2.b, réduit les tâches manuelles et, par conséquent, le temps consacré à la conformité. Avec Snyk, les équipes peuvent démontrer qu’elles ont mis en place des points de contrôle, des mesures correctives et une surveillance des vulnérabilités potentielles des composants open source.

Faire de la conformité PCI un moteur pour « décaler la sécurité vers la gauche »

À mesure que les organisations cherchent à décaler la sécurité vers la gauche, de nouveaux défis et de nouvelles opportunités apparaissent. Les mises à jour des exigences de conformité PCI sont cohérentes avec la réalité des processus de développement logiciel actuels et la généralisation de l’open source. Ces exigences peuvent sembler élevées au premier abord, mais les respecter aidera votre organisation à renforcer sa sécurité et à réduire son niveau de risque global. L’effort en vaut donc la peine, au-delà même des avantages liés à la conformité.

Pour la plupart des organisations, le principal défi consistera à adopter pour la première fois des outils de sécurité dédiés à l’open source, car ces outils ne font généralement pas encore partie de leur arsenal. Intégrer les bonnes pratiques de sécurité open source à votre pipeline CI/CD en fera une composante naturelle du processus de développement, plutôt qu’une contrainte de dernière minute ou une course contre la montre à l’annonce publique de nouvelles vulnérabilités.

Pour découvrir comment Snyk peut vous aider à respecter facilement les normes PCI de conformité open source, les développeurs peuvent commencer à utiliser Snyk gratuitement dès aujourd’hui.