Le défi : automatiser un processus lent d’examen de la sécurité des logiciels open source
Salesforce est un éditeur de logiciels mondial qui a développé la première plateforme de gestion de la relation client (CRM) au monde. Cette plateforme permet aux entreprises de réunir leurs données marketing, commerciales, de commerce, de services et informatiques afin d’obtenir une vue à 360 degrés de leurs clients. Salesforce développe également des applications d’entreprise pour l’automatisation du marketing, l’analytique, le développement d’applications et bien plus encore.
En tant qu’entreprise logicielle innovante, Salesforce croit à l’importance de contribuer à la communauté, notamment en proposant des logiciels open source (OSS). Toutefois, lorsqu’un employé ou une équipe souhaite publier son travail en open source, il doit soumettre une demande OSS qui fait l’objet d’examens portant sur la sécurité, les aspects juridiques et de nombreuses autres exigences. Avec une vingtaine de demandes OSS par mois, ce processus manuel d’examen des rapports d’analyse statique et de correction des problèmes détectés créait un goulot d’étranglement dans la publication de ses projets OSS.
« Comme vous le savez, les examens manuels prennent beaucoup de temps », explique Amol Deshpande, ingénieur en sécurité des produits chez Salesforce. « Les ingénieurs en sécurité ont de nombreuses responsabilités, et il devient vraiment difficile d’effectuer plusieurs examens chaque mois, surtout lorsque les demandes sont urgentes. Nous avons pensé pouvoir automatiser ce processus afin de faire gagner du temps aux ingénieurs. »
La solution : mettre en place une analyse de sécurité prête à l’emploi
Pour simplifier son processus d’examen de la sécurité OSS, Salesforce a décidé de créer un cadre de sécurité prêt à l’emploi qui s’appuie sur Snyk pour effectuer des analyses de sécurité et recueillir automatiquement les résultats. Chaque demande d’examen génère un ticket dans sa plateforme interne de suivi des tâches. Un webhook récupère ensuite le ticket et l’ajoute à une file d’attente dans RabbitMQ.
Grâce à son API robuste, Snyk peut ensuite récupérer les éléments de cette file d’attente, analyser les dépôts de code joints à la recherche de vulnérabilités et renvoyer les rapports de résultats dans le ticket d’origine. Les résultats de l’analyse sont directement accessibles aux ingénieurs dans les tickets, sans qu’ils aient à utiliser eux-mêmes des outils d’analyse de sécurité. Les ingénieurs en sécurité peuvent ainsi examiner immédiatement les rapports pour approuver les demandes ou corriger les problèmes en quelques minutes.
« Dès qu’un ingénieur prend en charge une demande, les rapports de vulnérabilités sont déjà joints au ticket », explique Deshpande. « Il peut consulter le rapport et approuver la demande, ou collaborer avec les équipes d’ingénierie pour corriger les problèmes détectés. Cela fait gagner beaucoup de temps aux ingénieurs, qui n’ont pas à lancer les analyses ni à apprendre à utiliser les outils de sécurité. »
Analyse de sécurité avec Snyk Open Source
Lorsqu’un logiciel est publié en open source, l’analyse de sécurité est essentielle pour réduire les risques pour l’organisation elle-même. En effet, des acteurs malveillants peuvent examiner le code accessible au public afin de préparer des attaques contre des applications propriétaires qui dépendent du logiciel OSS. Des projets OSS largement utilisés, comme Apache Struts, Tomcat et OpenSSL, ont déjà été compromis, et le nombre de vulnérabilités OSS continue d’augmenter. Salesforce ne voulait pas risquer sa réputation ni devenir une cible en publiant des logiciels OSS contenant des vulnérabilités.
« Les logiciels open source constituent l’un des vecteurs d’attaque les plus importants : lorsqu’une vulnérabilité est découverte dans un composant OSS, toutes les applications et tous les logiciels qui l’utilisent sont également exposés », explique Deshpande. « En fait, le nombre de vulnérabilités OSS a doublé en 2019 par rapport à l’année précédente. La menace ne cesse donc de croître. »
La solution de gestion de la sécurité open source de Snyk aide les organisations à gérer ce risque en détectant les vulnérabilités dans le code open source qu’elles intègrent, ainsi que dans le code qu’elles prévoient de publier auprès de la communauté. Snyk fournit des conseils concrets pour corriger les problèmes de sécurité détectés. Snyk aide également les développeurs à gagner du temps en hiérarchisant les problèmes selon leur gravité et leur impact potentiel. Salesforce peut désormais s’appuyer sur les résultats des analyses de Snyk, non seulement pour réduire son exposition interne aux menaces de sécurité, mais aussi pour permettre au grand public d’utiliser ses composants OSS en toute confiance.
« Je suis partisan de l’automatisation et du déplacement de la sécurité plus tôt dans le cycle de développement, explique Deshpande, et je pense que Snyk est l’un des outils les plus importants pour déployer les efforts de sécurité à l’échelle d’une organisation. À l’avenir, nous espérons étendre notre mise en œuvre en approuvant automatiquement les demandes lorsque les rapports ne révèlent aucun problème, et en déployant à l’échelle de l’organisation notre nouveau cadre d’analyse, optimisé par Snyk, afin d’unifier notre approche de la sécurité. »
Les résultats : des centaines d’heures de travail manuel économisées
Grâce à son nouveau cadre d’analyse de sécurité optimisé par Snyk, l’équipe de sécurité des produits de Salesforce n’a plus besoin d’examiner manuellement les demandes OSS. Auparavant, le traitement de chaque demande pouvait prendre des heures. Désormais, les résultats des analyses de Snyk sont automatiquement publiés dans les tickets de demande d’examen. Les ingénieurs en sécurité peuvent ainsi consacrer près de 150 heures à d’autres projets de sécurité à fort impact. Salesforce peut donc publier ses logiciels OSS bien plus rapidement qu’avant, sans compromettre la sécurité.
« Auparavant, le traitement de chaque demande pouvait prendre des heures. Désormais, les résultats des analyses de Snyk sont automatiquement publiés dans les tickets de demande d’examen. »