Retour sur la table ronde : rompre avec les mauvaises habitudes en sécurité avec Corey Quinn

Le 8 décembre, Clinton Herget et Simon Maple, CTO terrain chez Snyk, ont eu l’occasion d’échanger avec Corey Quinn, Chief Cloud Economist chez The Duckbill Group, animateur de podcast, curateur de « Last Week in AWS » et personnalité sarcastique sur Twitter.

Leur conversation a pris des tournures amusantes : ils ont notamment pesté contre l’interminable file d’attente pour prendre un café à AWS re:Invent, et Corey a affirmé que « les SBOM sont une fiction » (il y a un peu plus de contexte… poursuivez votre lecture). Nous revenons dans cet article sur quelques moments forts. Pour entendre toutes les saillies de Corey Quinn au cours de cette conversation, regardez ici la table ronde dans son intégralité.

Les enseignements d’AWS re:Invent 2022

À peine AWS re:Invent 2022 terminé, Corey et Clinton ont pris quelques minutes pour revenir sur les principaux enseignements qu’ils en ont tirés. Corey a souligné qu’il est important de privilégier les rencontres plutôt que les sessions. À AWS re:Invent, les journées ne comptent qu’un nombre limité d’heures, et Corey préfère les consacrer à rencontrer des membres d’AWS plutôt qu’à assister à des sessions. Après tout, les sessions sont disponibles à la demande après la conférence, contrairement aux échanges en personne avec les experts AWS.

Clinton s’est réjoui des détails annoncés par Amazon Web Services concernant son engagement en faveur de l’Open Cybersecurity Schema Framework (OCSF). En normalisant un cadre de sécurité, AWS pose les bases d’un langage interopérable et lisible par machine pour décrire la sécurité des applications. Pour Clinton, c’est une première étape vers un meilleur dialogue à l’échelle du secteur autour des risques partagés.

Retour sur les failles de sécurité AWS de 2022

Corey Quinn et Clinton Herget ont également passé en revue l’année 2022 et évoqué quelques « horreurs » liées à la sécurité AWS qu’il faut absolument corriger au cours de la nouvelle année. Parmi les principales :

Le décalage entre les environnements de développement et de production

Selon Clinton, l’un des problèmes majeurs du développement logiciel aujourd’hui est le fossé entre les environnements de développement et de production. Puisque tout, dans le cloud, est du code, toute mesure corrective liée à des risques de sécurité doit être apportée dans le code. Il explique : « En tant qu’opérateur, je reçois une grosse alerte rouge clignotante et effrayante : “Log4J se trouve dans un pod sur un cluster EKS ; vous devez corriger ça.” Et ensuite ? Il n’existe aucun moyen automatisé et lisible par machine de savoir quel fichier et quel dépôt Git doivent être modifiés à la suite de cette notification. »

Une confiance excessive dans la chaîne d’approvisionnement logicielle

En 2022, les équipes de développement logiciel ont également fait fausse route en accordant une confiance excessive aux composants de leur chaîne d’approvisionnement logicielle. Plutôt que de partir du principe que chaque logiciel open source et ses dépendances sont sécurisés, les équipes doivent vérifier que leurs composants tiers peuvent réellement être utilisés sans risque.

Des SBOM qui ne vont pas assez loin

Corey a également souligné que les nomenclatures logicielles (SBOM) actuelles ne vont pas assez loin. Selon lui, elles ne rendent pas justice à l’interconnexion qui caractérise les applications modernes. On peut suivre les dépendances transitives dans un véritable labyrinthe de « dépendances de dépendances de dépendances », sans jamais comprendre pleinement le niveau de risque lié aux tiers dans son application.

Des solutions aux défis de sécurité actuels

Clinton et Corey ont également abordé la manière dont les entreprises devraient envisager ces « horreurs de 2022 » et y répondre à l’approche de la nouvelle année. Ils ont notamment évoqué :

Compléter les SBOM par d’autres bonnes pratiques

Alors, comment améliorer les pratiques actuelles en matière de SBOM ? Corey Quinn a plaisanté en disant que « pour vraiment régler le problème, il faut corriger les êtres humains ».

Autrement dit, répertorier l’intégralité de votre chaîne d’approvisionnement logicielle ne suffira pas à résoudre les problèmes de sécurité. Il faut plutôt faire évoluer la culture de l’organisation et donner aux personnes les moyens de résoudre les problèmes de sécurité. Pour cela, il est essentiel de réduire les alertes de sécurité et le bruit, afin que votre équipe puisse trier les éléments les plus importants de votre SBOM.

Clinton a également ajouté que les organisations ne devraient pas avoir honte d’utiliser l’open source. Comprendre que l’utilisation de l’open source est acceptable et ne menace pas la réussite de leur entreprise leur permet d’être plus transparentes sur les composants partagés utilisés et leur emplacement.

Bien comprendre les processus existants de votre organisation

Quels liens existent entre votre IaC, votre cloud et votre code source ? Comment votre équipe de sécurité collabore-t-elle avec vos développeurs, et inversement ? Quels éléments ces personnes prennent-elles en compte au quotidien ? Clinton et Corey ont souligné l’importance de prendre du recul et de répondre à ces questions. La façon dont chaque unité de l’entreprise perçoit et gère les risques en dépend.

Corey a également indiqué qu’il était « très réticent à donner des conseils qui vont au-delà de “comprenez le contexte dans lequel vous évoluez et prenez des décisions adaptées à votre situation” ». C’est pourquoi les organisations doivent poser des questions plus approfondies et trouver les bonnes pratiques de sécurité qui leur conviennent.

Composer avec le contexte de votre équipe de développement, plutôt que de le contrarier

La sécurité est souvent une discipline réactive. Corey a expliqué que, bien que nécessaires, les efforts de sécurité ne font pas progresser concrètement l’activité. Ils passent donc souvent au second plan. Puisque la plupart des services sont probablement de cet avis, les équipes doivent rendre les pratiques de sécurité aussi fluides que possible.

Il faut sécuriser le SDLC en réduisant au maximum les interventions manuelles. Pour donner aux développeurs les moyens d’adopter les bonnes pratiques de sécurité, il faut avant tout tenir compte de leur contexte et comprendre ce qu’ils utilisent au quotidien.

Nouvelle année, nouvelles occasions de renforcer la sécurité AWS

Ce n’est qu’un aperçu des sujets abordés par Corey et Clinton. Ils ont évoqué de nombreuses pistes pour renforcer la sécurité AWS en 2023, notamment en mettant davantage l’accent sur la sécurité pensée pour les développeurs et en améliorant la transparence des chaînes d’approvisionnement logicielles.

Ne manquez pas leur conversation dans son intégralité. Découvrez également comment la plateforme de sécurité pour les développeurs de Snyk peut vous aider à développer votre programme de sécurité en 2023.