Date
30.03.2022
La sécurité et la fiabilité de nos prestations informatiques sont notre priorité absolue. C’est pourquoi nous utilisons également des outils d’analyse automatisés pour les bibliothèques open source.
La faille de sécurité majeure découverte en décembre dans la bibliothèque Java open source Log4J a montré de manière impressionnante quels dangers pouvaient menacer les bibliothèques open source. Il est donc indispensable d’investir dans l’analyse automatisée et de supprimer le plus rapidement possible les failles de sécurité.
Log4J n’est pas un cas isolé : le rapport Open source security and risk analysis de Synopsys montre que chaque application utilise en moyenne 528 bibliothèques open source et que 60 % des applications comportent des failles de sécurité critiques connues dans les bibliothèques open source utilisées.
Une enquête de Veracode indique en outre que les développeurs de bibliothèques open source remédient rapidement aux failles de sécurité. Près de 15 % des failles de sécurité connues sont ainsi supprimées dans l’heure et 25 % dans les cinq jours. L’enquête révèle aussi que 92 % des failles analysées peuvent être résolues par une mise à jour mais que 79 % des bibliothèques ne sont pas actualisées après leur intégration dans une base de code.
Il est clair pour Bedag qu’une des manières les plus efficaces d’éviter les failles de sécurité est la mise à jour des bibliothèques open source concernées. Afin de faciliter l’identification des bibliothèques nécessitant une mise à jour, nous utilisons chez Bedag le logiciel Blackduck de Synopsis. Ce logiciel analyse automatiquement les dépendances dans le code de projets logiciels.
Quelle est l’action de Blackduck ?
Le logiciel Blackduck soutient le processus d’actualisation en montrant clairement les bibliothèques open source utilisées et leur version.
Nombre de failles de sécurité (1 support) dues aux bibliothèques open source dans le projet.
Le logiciel représente ensuite pour chaque bibliothèque toutes les failles de sécurité connues pondérées par criticité ainsi qu’une recommandation indiquant à quelle version la bibliothèque correspondante doit être mise à jour.
Détails de la faille de sécurité découverte dans le projet avec recommandation de mise à jour vers une version plus sûre.
Grâce à ces données, il est plus facile de planifier la mise à jour des bibliothèques en fonction du risque et de minimiser ainsi les risques pour la sécurité de manière incrémentielle, même pour les applications qui se sont étoffées au fil des années.
Nous optimisons continuellement les processus de développement correspondants et garantissons ainsi qu’aucun logiciel présentant des failles critiques dans les bibliothèques open source ne soit plus en service. Nous espérons par ailleurs que l’intégration de Blackduck dans Jira, notre outil pour la gestion des tâches dans le processus de développement, facilitera encore le travail de nos équipes de développement et celui de nos clients.
Procédure standardisée en cas d’incident
En cas de soupçons d’incident de sécurité dans des applications productives malgré ces mesures préventives, notre Security Operation Center (SOC) est averti. Le SOC analyse toutes les informations disponibles et décide si l’incident de sécurité est confirmé. Les incidents de sécurité avérés sont catégorisés et classés par priorité en fonction de leur degré de gravité. Ils sont traités par une procédure uniforme en quatre phases :
- Endiguement : les premières mesures sont mises en œuvre pour éviter des dégâts supplémentaires. Aucune modification ne doit être apportée sur le système concerné proprement dit avant l’achèvement des étapes nécessaires au relevé des traces exploitables juridiquement.
- Suppression : dans cette phase, la cause de l’incident de sécurité est connue et est supprimée avec tous les artefacts étrangers enregistrés sur le système.
- Restauration : les systèmes concernés nettoyés sont à présent réactivés (si possible directement en mode normal). Dans cette phase, le fonctionnement des systèmes tel qu’attendu est validé par des tests et une surveillance sur une période suffisante.
- Conclusions : une réunion sur les leçons à tirer est organisée avec tous les services concernés. L’incident de sécurité est résumé, les questions en suspens sont éclaircies et l’incident est définitivement clos. Des mesures sont définies pour éviter des incidents similaires à l’avenir ou au moins pour réduire leur impact.
La résolution des incidents de sécurité fait intervenir les spécialistes des services concernés pour lancer les différentes tâches aussi vite que possible. Les incidents de sécurité majeurs sont immédiatement transmis à une workforce ou taskforce.
C’est pourquoi, pendant l’incident avec Log4J, nous avons convoqué immédiatement une taskforce chez Bedag. Les données de Blackduck essentiellement nous ont permis d’identifier rapidement les systèmes touchés et de combler cette faille de sécurité critique dans un délai très court. Nous avons ainsi garanti la disponibilité continue de nos solutions. En combinant des solutions automatisées et les connaissances techniques de nos spécialistes, nos clients peuvent compter sur la sécurité et la fiabilité de leurs solutions et données.
P.S. : vous trouverez de plus amples informations sur Blackduck dans notre article « Grâce aux audits automatisés, nous développons des logiciels plus sûrs pour vous » du 19.6.2020.
2022-03-30 14:31:43