Bilan du T2 2020 — Rapport sur l’état de la sécurité open source, DevSecOps Hub et plus encore

Hier, nous sommes revenus sur quelques articles publiés en janvier, février et mars 2020. Vous vous souvenez de cette époque où nous pouvions voyager et nous prendre dans les bras, nous retrouver sans souci dans des bars et des bureaux, et passer du temps ensemble sans avoir à utiliser Zoom ! Dans cet article, nous revenons sur les publications d’avril, mai et juin. Commençons par une fiche pratique que tous les développeurs devraient lire et consulter.

À LIRE AUSSI : Bilan du T1 2020 — Rapport sur l’écosystème JVM, analyses DevSecOps et plus encore

Avril 2020 : Revue de code sécurisée : 8 bonnes pratiques pour examiner la sécurité du code

Dans cette fiche pratique, Brian Vermeer et Trisha Gee présentent 8 excellents conseils à garder à l’esprit lorsque nous examinons le code d’une autre personne. En fait, ce sont aussi de très bons conseils à suivre lorsque l’on écrit du code. Alors, avant d’envoyer votre pull request, assurez-vous de vous évaluer vous-même à l’aune de ces critères !

Parmi les bonnes pratiques de cette fiche, je tiens à en souligner trois en particulier : assainir les entrées, tester vos dépendances open source et, bien sûr, rechercher les problèmes de sécurité connus dans votre propre code source. L’assainissement des entrées est essentiel dans votre code, mais nous, les développeurs, le laissons souvent à d’autres ou partons du principe qu’il n’y a pas d’intention malveillante, parce que nous cherchons simplement à faire fonctionner le parcours idéal. Adopter le réflexe de se dire que les utilisateurs tenteront d’injecter du code ou d’attaquer notre application par tous les moyens possibles via leurs entrées est un changement important que de nombreux développeurs doivent opérer.

Tester statiquement votre application ainsi que vos dépendances tierces est essentiel pour repérer les vulnérabilités connues dans les bibliothèques et frameworks existants qui sont exposées par votre application, mais aussi les failles de sécurité introduites par votre code personnalisé. Avec des outils comme Snyk, disponibles gratuitement et capables de tester rapidement votre application depuis votre IDE, vos dépôts et bien d’autres environnements, il n’y a vraiment plus aucune excuse pour ne pas le faire.

Mai 2020 : Snyk lance DevSecOps Hub

En mai, Alyssa Miller a lancé le DevSecOps Hub, un recueil d’articles et de connaissances rassemblés par Alyssa, Patrick Debois et Francois Raynaud autour de certains concepts fondamentaux du mouvement DevSecOps. Il présente ces concepts selon l’approche bien connue « People, Process, Technology », afin d’éviter que le débat sur DevSecOps ne se limite parfois aux outils.

People (les personnes) -De nombreux experts de Snyk auraient pu partager leur point de vue, mais nous voulions aussi inclure de nombreux enseignements issus de la communauté DevSecOps. Dans The Secure Developer Podcast, les participants racontent à notre fondateur, Guy Podjarny, leurs réussites et les leçons tirées du lancement ou du développement de leur approche DevSecOps. Pour vous faire découvrir ces précieuses informations dans DevSecOps Hub, nous avons inclus notre rubrique Share the journey section.

Process (les processus) - Il est toujours important de définir clairement les processus afin que chacun sache quoi faire, quand le faire et qui doit s’en charger. La responsabilité partagée et la reddition de comptes sont des thèmes clés abordés tout au long de cette rubrique.

Technology (la technologie) - Dans cette rubrique, nous nous intéressons aux fonctionnalités clés de tout pipeline et à la manière dont les organisations peuvent adapter les approches standard à leur propre structure. Nous y présentons également des technologies à la loupe. Chacune met en lumière un outil ou une technologie spécifique pouvant contribuer au pipeline DevSecOps. Nous proposons aussi une liste de bonnes pratiques pour ces outils, afin de donner des conseils concrets pour mettre ces technologies en œuvre.

Juin 2020 : L’état de la sécurité open source en 2020

En juin, Alyssa Miller a rédigé notre rapport annuel sur l’état de la sécurité open source. Comme toujours, il met en lumière des observations très intéressantes sur l’adoption et l’utilisation actuelles de l’open source. Le rapport commence par s’intéresser aux personnes responsables de la sécurité : 85 % des utilisateurs estiment que la sécurité open source relève de la responsabilité des développeurs. Ce chiffre confirme la vision de Snyk, selon laquelle les outils de sécurité doivent être conçus en priorité pour les développeurs. C’est une statistique très importante à l’approche de 2021 : de plus en plus de développeurs ne se contentent pas d’écrire du code applicatif, ils doivent aussi gérer et maintenir des fichiers de conteneur et des configurations d’infrastructure sous forme de code. Tous ces artefacts doivent non seulement être écrits et maintenus, mais aussi sécurisés, pour éviter de faire la une à cause d’une brèche dans un bucket Amazon S3 mal configuré. En fait, plus loin dans le rapport, on apprend que plus de 30 % des participants à l’enquête ne vérifient pas si les manifestes Kubernetes contiennent des configurations non sécurisées. Les développeurs responsables de leurs applications cloud natives modernes doivent tenir compte des menaces présentes dans chacun des éléments mentionnés ci-dessus et ont besoin d’une plateforme de sécurité des applications cloud natives pour répondre à leurs besoins.

Fait intéressant, seuls 15 % des répondants à notre enquête ont mis en place des programmes de Security Champions. Ces programmes permettent essentiellement de renforcer les compétences de certains membres des équipes d’ingénierie, appelés Security Champions. Ils sont généralement formés par l’équipe sécurité, ainsi que dans le cadre d’autres programmes de formation internes et externes. Faire monter en compétences les développeurs permet de diffuser largement les connaissances en sécurité, d’améliorer de nombreuses bonnes pratiques de développement et les revues de code, et d’intégrer plus naturellement la sécurité dès la phase de conception. Les personnes et la culture sont toujours les aspects les plus difficiles à faire évoluer lors d’une transformation comme DevOps ou DevSecOps : il est donc important de s’attaquer au problème de front. Après avoir échangé avec de nombreux clients et utilisateurs de Snyk, nous avons toujours constaté que les organisations qui créent des programmes de sécurité au sein de leurs équipes d’ingénierie obtiennent d’excellents résultats dans l’adoption et la mise en œuvre des pratiques de sécurité. Nous vous encourageons donc à y réfléchir !

Une fois encore, quelques autres articles n’ont pas tout à fait trouvé leur place dans la liste, mais méritent tout de même une mention honorable. Citons notamment le plugin Vuln Cost, un excellent outil gratuit de test de sécurité qui s’intègre directement à VS Code et offre une très bonne expérience aux développeurs en indiquant les vulnérabilités directement dans le code ! Nous avons également abordé la divulgation d’une vulnérabilité dans la bibliothèque npm populaire is-promise, avec une analyse rétrospective des causes de l’incident et des enseignements à en tirer. Enfin, c’est en mai que nous avons intégré Snyk au très populaire WebPageTest ! Cette intégration ajoute des tests de sécurité aux excellents résultats de performance déjà fournis par WebPageTest.

Merci de nous avoir lus ! Dans notre prochain article, nous reviendrons sur les publications du troisième trimestre 2020.