Vous êtes Security Champion chez un fournisseur SaaS qui utilise un environnement de développement intégré (IDE) pour concevoir et tester le code de son service Cloud. Vous avez récemment découvert que des développeurs utilisaient des bibliothèques open-source non vérifiées, ce qui pourrait entrainer des vulnérabilités dans le service SaaS et impacter ses utilisateurs. Vous avez décidé d’implémenter des mesures de sécurité pour minimiser les risques liés à l’utilisation de composants tiers tout en maintenant l’efficacité de l’équipe de développement.
Quelle serait la meilleure solution pour répondre à cette problématique ?
[A] Interdire l’utilisation de toute bibliothèque tierces ou open-source
[B] Mettre en place un processus de validation des bibliothèques tierces et open-source
[C] Responsabiliser les développeurs pour qu’ils vérifient systématiquement la sécurité des bibliothèques qu’ils utilisent
[D] Appliquer systématiquement les mises à jour de sécurité aux bibliothèques utilisées
Proposition [A] : Interdire complètement l’utilisation de bibliothèques open-source est une approche drastique qui limiterait la flexibilité et l’efficacité des développeurs. Les bibliothèques open-source sont souvent nécessaires pour accélérer le développement et offrir de nouvelles fonctionnalités. Au lieu de les interdire, il est préférable de les utiliser de façon sécurisée.
Proposition [B] : Mettre en place un processus de validation des bibliothèques open-source est la meilleure approche. Cela inclut l’utilisation d’outils pour analyser les vulnérabilités de sécurité, des processus d’approbation par l’équipe de sécurité, et des audits réguliers pour s’assurer que seules des bibliothèques sûres et mises à jour sont utilisées. Cela permet de bénéficier des avantages des bibliothèques open-source tout en minimisant les risques de sécurité. Pour cela il convient d’établir le SBOM (Software Bill of Materials) c’est-à-dire une liste détaillée de tous les composants, bibliothèques, dépendances et éléments du service SaaS ainsi que leurs versions respectives. Le processus devra alors procéder à la validation de tous les composants tiers de la liste. Ce process appelé SCA (Software Composition Analysis) consiste à identifier et analyser les composants open source et tiers dans une application afin de détecter des vulnérabilités, des risques de conformité de licence et d’autres problèmes potentiels de sécurité. Le SCA utilise des outils automatisés pour scanner le code et détecter les composants logiciels, en les comparant à des bases de données de vulnérabilités et de licences. Ces outils offrent des rapports détaillés sur les vulnérabilités trouvées, la conformité des licences et les risques potentiels. Exemple d’outils SCA : Sonatype Nexus IQ, Black Duck, Snyk, WhiteSource,…
Proposition [C] : Confier aux développeurs la responsabilité de vérifier eux-mêmes la sécurité des bibliothèques n’est pas la solution ils ne possèdent pas toujours les compétences ou l’outillage nécessaire pour évaluer correctement les vulnérabilités des bibliothèques utilisées.
Proposition [D] : L’application des mises à jour de sécurité ne représente qu’une seule étape du processus global présentée dans la proposition [B]. C’est donc une réponse partielle au problème.
La bonne réponse est la proposition [B]
Pour en savoir plus sur la sécurité dans les développements logiciels nous vous recommandons de suivre le module n°20 de la formation CISSP de VERISAFE.
Questions et réponses rédigées par VERISAFE selon le programme officiel du CISSP actuellement en vigueur
© VERISAFE – Utilisation ou reproduction (même partielle) strictement interdite sans l’accord écrit de VERISAFE
