The Secure Developer : rétrospective 2021

Si les dernières années nous ont appris à nous adapter, 2021 nous a donné le temps de faire le point sur notre parcours. Le choc de la pandémie, qui a marqué 2020, a laissé place à une perspective plus ancrée sur les défis que nous avons surmontés dans notre vie personnelle et professionnelle.

En tant qu’animateur de The Secure Developer, Guy Podjarny (fondateur et président de Snyk) nous a offert un aperçu privilégié de l’évolution de la sécurité des applications. Cette année, les 22 épisodes ont accueilli 23 invités issus de différents secteurs, venus partager leurs points de vue uniques. Dans l’épisode de fin d’année, Guy s’est entretenu avec Simon Maple, Field CTO chez Snyk, pour revenir sur les thèmes, les conseils et les perspectives d’avenir évoqués dans les épisodes de cette année.

Les thèmes communs à l’ensemble du secteur

Tout au long de l’année, les invités de The Secure Developer ont soulevé d’innombrables sujets intéressants. En faisant le bilan, Guy et Simon ont dégagé trois thèmes marquants, présents dans la plupart des épisodes du podcast.

Recruter des développeurs dans les équipes de sécurité

Le premier thème était le virage vers le recrutement de développeurs (ou de personnes ayant une expérience en ingénierie logicielle) pour constituer les équipes de sécurité. Historiquement, ces équipes étaient composées de spécialistes de la sécurité qui, malgré leur expertise, restaient éloignés du travail quotidien de développement. La sécurité représentait une étape de contrôle supplémentaire pour les développeurs, et non une partie intégrante de leur travail.

Intégrer des développeurs à l’équipe de sécurité représente un avantage considérable. Comme l’a expliqué Daniel Bryant (directeur DevRel chez Ambassador Labs) : « Les développeurs [...] assument de plus en plus de responsabilités de bout en bout. Vous avez parlé de tests, d’observabilité. Et les développeurs aiment interagir avec les outils d’une certaine manière. Il faut aller [...] à la rencontre des ingénieurs là où ils en sont. » (épisode 90)

On peut toujours essayer d’apprendre l’empathie aux équipes de sécurité, de leur faire comprendre le point de vue des développeurs et les défis auxquels ils sont confrontés. Mais lorsqu’on recrute un développeur dès le départ, cette compréhension est déjà là. Pas besoin de formation ni de traduction : l’équipe de sécurité comprend naturellement le point de vue des développeurs. Cela favorise l’engagement et permet aux équipes de développement et de sécurité de mieux collaborer.

Une sécurité pensée pour les développeurs

Autre grand thème de 2021 : les équipes de sécurité doivent s’adapter au développement, et non l’inverse. Il y a encore quelques années, elles atténuaient les vulnérabilités en dressant la liste des problèmes à la fin du cycle de développement. La séparation entre les équipes de développement et de sécurité donnait aux développeurs l’impression qu’on leur refilait les problèmes à la fin de chaque cycle, tandis que les professionnels de la sécurité jouaient un rôle réglementaire (et souvent critique).

Ces dernières années, les entreprises ont compris que la sécurité devait s’intégrer aux pratiques SDLC existantes et s’adapter aux besoins des développeurs. Une fois encore, l’empathie et les liens entre développeurs et professionnels de la sécurité se révèlent essentiels. Dev Akhawe (responsable de la sécurité chez Figma) l’a illustré en expliquant comment il aborderait les problèmes de sécurité avec les développeurs. Lorsqu’il pilotait le déploiement des clés de sécurité chez Figma, il « avait l’habitude de s’excuser, en disant : “Je suis désolé. Nous n’avons pas encore déployé les clés de sécurité.” Il faut rester vigilant face à l’hameçonnage. [Le] truc qui a probablement été très efficace, c’est de se rappeler que c’est vraiment à l’équipe de sécurité de veiller à ce que les systèmes que nous utilisons et ceux que nous concevons ne puissent pas se comporter de manière imprévisible. Plutôt que de dire aux développeurs qu’ils doivent faire ces cent choses. » (épisode 88)

Ce changement ne s’est pas fait dans un seul sens. Le monde des outils de développement reconnaît de plus en plus que « la sécurité n’est pas un sujet à part. Chaque outil de développement a une part de responsabilité dans l’intégration de la sécurité aux workflows ». À mesure que développement et sécurité s’entremêlent, une chose devient claire : « la sécurité s’adapte aux outils et aux pratiques de développement […] et les responsables du développement adoptent vraiment la sécurité et réfléchissent à leurs responsabilités en la matière. »

La sécurité à grande échelle

Le troisième thème était l’importance d’une bonne hygiène de sécurité à grande échelle. La capacité à sécuriser les systèmes au rythme du secteur est essentielle à la réussite d’une entreprise. Cela signifie maîtriser les fondamentaux, et non se préparer à des cyberattaques dignes du cinéma. En AppSec, des mesures simples comme verrouiller les portes et les fenêtres suffisent souvent à protéger une entreprise contre les attaques de faible intensité et à lui permettre de réagir efficacement en cas de vulnérabilité grave. « Réussir à appliquer [les fondamentaux] à grande échelle et rapidement est très difficile. Presque tous les programmes et initiatives de cette année ont mis l’accent sur l’idée de faire les choses essentielles correctement, à grande échelle et rapidement. »

Lorsque les développeurs connaissent les fondamentaux de la sécurisation de leurs systèmes, ils peuvent se préparer à gérer des problèmes plus importants, comme la récente vulnérabilité Log4Shell. Certaines entreprises ont dû se démener pour comprendre ce qui s’était passé et quelles en étaient les conséquences. D’autres, dotées d’une hygiène et d’une structure de sécurité solides, ont pu poursuivre leurs activités presque normalement. « Chez Snyk, nous avons observé [...] une forte augmentation du nombre de personnes qui y ajoutaient des projets. Je pense que cela a aussi [...] créé un sentiment d’urgence, même [chez] les personnes qui étaient sur la bonne voie. Cela leur a rappelé qu’il faut avoir [...] une visibilité sur tous ses projets. On ne peut pas simplement procéder à une transition progressive. C’est l’une des différences fondamentales entre le développement et la sécurité. » (épisode 106) Les outils de développement sont souvent utilisés localement et adoptés au cas par cas, tandis que les solutions de sécurité doivent offrir immédiatement une large couverture pour être efficaces. Aucune approche n’est mauvaise, mais Log4Shell et d’autres incidents similaires nous ont appris qu’il est risqué d’aborder les outils de sécurité comme on le ferait pour une solution de développement.

Les moments forts des épisodes de 2021

Log4Shell est peut-être notre leçon la plus récente, mais elle est loin d’être la seule que 2021 nous a apprise. Voici quelques épisodes à ne pas manquer.

La faille de Codecov (#1022)

Guy a reçu Jerrod Engelberg (CEO) et Eli Hooten (CTO) de CodeCov pour discuter de la manière dont l’entreprise a géré sa faille de sécurité de 2021. L’épisode regorgeait d’enseignements sur la façon de gérer les priorités concurrentes lors d’un incident de sécurité. Engelberg et Hooten ont commencé par expliquer à Guy leur réaction en interne. Engelberg a déclaré : « Si ne serait-ce qu’un seul client ne peut pas nous entendre […] et prendre les mesures qui s’imposent, c’est déjà un client de trop. » La conversation a ensuite évolué, abordant l’éthique de la divulgation et les risques implicites que nous devons gérer en tant que secteur. « Il y a toujours cette poignée de main, n’est-ce pas ? Nous pouvons la rendre de plus en plus sophistiquée, mais c’est quelque chose auquel je réfléchis beaucoup », a déclaré Engelberg.

Conteneurs, processus et avenir de la sécurité (#103)

Liz Rice, Chief Open Source Officer chez Isovalent, nous a présenté eBPF et nous a fait part de son point de vue sur l’importance du réseau cloud native. « Nous constatons une adoption extrêmement rapide des technologies cloud. Je pense que le recours au cloud sera bientôt un prérequis pour toutes les entreprises. Nous ne parlerons certainement plus de premiers utilisateurs », a déclaré Rice.

La sécurité des applications dans le secteur public (#86, #95) :

Plusieurs épisodes ont porté sur l’adoption croissante de DevSecOps par les gouvernements et les parallèles avec les éditeurs de logiciels du secteur privé. Robert Wood, du CMS pour Medicare et Medicaid, était l’invité de l’épisode 95, tandis que Nicolas Chaillan, CSO de l’US Air Force, était l’invité de l’épisode 86. Ces deux invités devaient aider des organisations historiquement indépendantes à adopter l’approche plateforme nécessaire au DevOps. Pour Wood, cela signifie « donner du sens à cette immense quantité de données dont nous disposons, car toutes ces activités de sécurité sont cloisonnées. Elles fonctionnent chacune de leur côté ou génèrent des informations, mais pas des données que l’on peut relier à autre chose pour en tirer des enseignements encore plus précieux. »

La discussion entre Chaillan et Guy a mis en lumière l’une des différences évidentes entre le DevOps dans les secteurs public et privé. Pour les gouvernements, les inconvénients d’être à la pointe sont plus évidents que les avantages, ce qui entraîne une tolérance au risque plus faible et une adoption lente, caractéristiques des organisations publiques. Chaillan estime que « la cybersécurité va évoluer. Je pense que cela reposera beaucoup sur la capacité de surveillance continue. Le grand risque, à mon avis, réside dans les dépendances ou les produits que vous utilisez sans bien les connaître. »

Les sujets à suivre en 2022

Tout en tirant les leçons de cette année, nous pouvons aussi regarder dans notre boule de cristal pour découvrir ce que 2022 nous réserve. Guy invite chaque personne à son émission à faire cet exercice et à imaginer l’avenir de notre secteur pour conclure chaque épisode. Pour clore l’année, Simon a inversé les rôles et demandé à Guy de dresser sa liste des sujets prioritaires et de ses attentes. À l’échelle du secteur, trois domaines seront essentiels : la chaîne d’approvisionnement, le cloud et la mise au point de méthodes pour mesurer la sécurité à mesure qu’elle se décentralise.

Sécurité de la chaîne d’approvisionnement

Les incidents SolarWinds, CodeCov, Log4Shell et d’autres ont montré à quel point la sécurité de la chaîne d’approvisionnement est indispensable. « Nous avons créé un réseau de dépendances entre services, composants et individus, et nous devons apprendre à le maîtriser. » À mesure que les entreprises sont de plus en plus interconnectées, nous devons agir ensemble, à l’échelle du secteur, pour définir les risques liés à la chaîne d’approvisionnement et y répondre.

Sécurité du cloud

La sécurité du cloud a traditionnellement été considérée comme un prolongement de la sécurité informatique. Toutefois, il est probable que l’on reconnaisse de plus en plus que le cloud est un logiciel et qu’il nécessite des outils de sécurité conçus pour les logiciels afin de protéger les informations sensibles.

Quantifier l’AppSec

Mesurer la sécurité est important, car nous avons besoin d’un moyen de mettre directement en relation l’activité du code et les risques. À mesure que le DevOps évolue, ces données joueront un rôle essentiel dans la stratégie de l’entreprise. Corréler les mesures de disponibilité avec les indicateurs de réussite de l’entreprise permettra à la sécurité de continuer à gagner en importance et à se développer.

Plus généralement, Guy espère que l’on recommencera à considérer l’application dans son ensemble, comme une entité unique composée de nombreux éléments interdépendants. Nous approchons rapidement du moment où il sera impossible de traiter chaque vulnérabilité isolément. Une vision de la sécurité découpée en segments ne fonctionnera donc pas. Nous devons considérer les applications et leur chaîne d’approvisionnement dans leur ensemble, et créer la taxonomie et les outils nécessaires pour parler de sécurité à un niveau supérieur.

Chez Snyk, notre objectif est de créer des outils qui rendent la sécurité naturelle. Nous allégeons la charge des développeurs en leur permettant de détecter et de corriger les vulnérabilités en seulement 5 minutes. Faites de nous un partenaire de votre équipe de sécurité des applications et découvrez dès aujourd’hui tout ce que vous pouvez accomplir.