Comment rester au top de la sécurité en 2023

La sécurité et les performances sont la pierre angulaire de chaque projet, site, application et composant que vous développez. Mais dans ce paysage en constante évolution, il peut être difficile de rester au courant des meilleures pratiques fondamentales, tout en innovant.

Dans cette conversation, écoutez les meilleurs technologues expliquer comment ils restent au top de la sécurité et des performances en 2023.

Haut-parleurs:

• Ramadass Prabhakar, SVP et directeur de la technologie chez WP Engine
• Lawrence Edmondson, CTO chez Barbarian
• Sergi Isasi, vice-président produit, performances des applications chez Cloudflare
• Tim Nash, consultant en sécurité WordPress chez timnash.co.uk
• Jimmy Squires, directeur technique chez space150

Transcription:

RAMADASS : Bonjour à tous. Bienvenue dans la quatrième édition de Decode. Il a été merveilleux de voir la croissance du nombre de participants chaque année. Au cours des deux dernières années, il y a eu un changement significatif dans le paysage de la sécurité à travers l'industrie. Nous avons vu des bulletins d'information réguliers sur les failles de sécurité et la sécurité, car un sujet revient fréquemment dans les discussions avec les clients et les développeurs. Aujourd'hui, nous avons réuni un fabuleux groupe d'experts de l'industrie passionnés par la sécurité et qui sont là pour répondre à nos questions et partager leurs connaissances avec nous. Commençons donc par une brève présentation de nos panélistes. Laurent, à vous.

LAWRENCE EDMONDSON : Merci beaucoup de nous recevoir. Ici Lawrence Edmondson, CTO de Barbarian. Barbarian est une agence numérique à service complet. Nous sommes situés à New York.

RAMADASS : Merci Laurent. À vous, Sergi.

SERGI ISASI : Merci. Je suis vice-président produit chez Cloudflare. Cloudflare, nous créons des produits qui permettent à nos clients et partenaires, comme WPE, de se connecter à Internet de manière plus sûre et plus rapide et je suis à San Francisco.

MODÉRATEUR : Merci, Sergi. Et Tim, à toi.

TIM NASH : Je suis un consultant en sécurité WordPress ici au Royaume-Uni. Et je passe essentiellement ma vie à effrayer les développeurs.

MODÉRATEUR : Merci. Et Jimmy.

JIMMY SQUIRES : Oui, merci. Je suis avec Space 150, également une agence numérique à service complet basée à Minneapolis et CTO là-bas.

MODÉRATEUR : Merci d'avoir accepté de faire partie de notre panel aujourd'hui. J'aimerais donc commencer par parler de quelque chose d'unique que vous faites aujourd'hui dans le domaine de la sécurité au sein de votre organisation ou de vos équipes. Alors peut-être commençons par Sergi.

SERGI ISASI : Ouais, je vais jouer sur l'intro de Tim, où il effraie les développeurs. L'une des choses que nous essayons de faire davantage chez Cloudflare est de donner à nos clients plus d'informations sur leur trafic et de réduire la charge opérationnelle. Donc, historiquement, si vous vouliez trouver ce qui pourrait affecter votre réseau, ce que vous pourriez voir, vous déployiez un WAF, vous le mettiez en mode journal et vous demandiez alors à un analyste de la sécurité d'examiner les journaux et voir ce qu'il a détecté. Et il y a juste beaucoup moins de ressources pour le faire ces jours-ci.

Notre objectif pour cette année est donc de donner à nos clients un aperçu des attaques que nous voyons sur eux, même s'ils n'utilisent pas le produit qui empêcherait cette attaque aujourd'hui. Ainsi, ils peuvent savoir si leur application est attaquée ou en bon état général. Et c'est notre objectif pour le reste de l'année, présenter tous nos produits de sécurité et faire savoir à nos clients ce qui pourrait se passer ou ce qui se passe réellement sur leur réseau et s'ils veulent ou non le bloquer.

MODÉRATEUR : Merveilleux. Cela semble vraiment très puissant. J'ai hâte d'en savoir plus à ce sujet. Alors Tim, et toi ?

TIM NASH : Je travaille donc avec de nombreux clients différents, à la fois des agences, mais aussi des sites Web individuels plus petits. Et je fais beaucoup de revues de code et de revues de sites. Et jusqu'à cette année, je n'ai pas vu la croissance du nombre de personnes vraiment attentionnées au point que les gens soient assez heureux d'obtenir un examen et de faire simplement le travail que vous leur dites de faire. Donc, si vous leur donnez un tas de recommandations, ils ne font que suivre. Mais si je reviens sur le site l'année prochaine, je leur donne juste un autre tas de recommandations. J'ai donc beaucoup vu un changement au cours de cette dernière année de personnes suffisamment attentionnées pour poser des questions. Et donc pour moi, les audits de code ont été jetés dans le grand, long ici la ligne 6, 4, 2 de ce fichier, bof, doit être fait comme ça.

Je me suis débarrassé de tout cela et j'ai vraiment commencé à me concentrer sur l'éducation et j'ai réalisé que, pour être honnête, ce que la plupart des gens veulent, ce n'est pas qu'on leur dise, vous devez corriger cette ligne, mais pour qu'on le dise, voici comment réparer chaque ligne qui s'y trouve. Donc pour moi, le grand changement et le grand changement d'orientation ont été vers l'éducation. Et c'est quelque chose qui concerne l'ensemble de l'industrie. Je pense qu'il y a de plus en plus de gens qui parlent de sécurité cette année que l'année dernière et de plus en plus depuis les années précédentes.

MODÉRATEUR : Non, c'est merveilleux. J'aime vraiment cet objectif de passer de vous donner le poisson à vous apprendre à attraper le poisson. Donc c'est vraiment–

TIM NASH: J'essayais d'éviter cette analogie à tout prix pour être cliché.

MODÉRATEUR : Merci.

TIM NASH : Bravo.

MODÉRATEUR : D'accord, Jimmy.

JIMMY SQUIRES: Ouais, je pense qu'il y a tellement de choses, j'ai décidé de me concentrer sur une chose vraiment spécifique à aborder dans cette réponse. Et cela limite vraiment votre champ d'application lorsque vous traitez avec des jetons d'API et un accès. Je pense que la violation du référentiel Heroku, GitHub l'année dernière a été un très bon rappel que vous ne contrôlez que tant de choses. Ainsi, lorsque nous travaillons avec nos développeurs, rappelons-leur l'importance de cette politique d'accès étendu sur la plate-forme ou le système avec lequel vous travaillez. Souvent, un développeur veut vraiment un accès ouvert assez large au début du développement, juste pour plus de facilité. Et parfois, ces choses que nous sommes probablement - tous honteux de l'admettre - ne sont pas resserrées au niveau qu'elles devraient être avant la production. Donc, commencez tôt en tenant vraiment compte de ces étendues de sécurité.

MODÉRATEUR : Merci, Jimmy. Et Lawrence, je sais que tu travailles aussi beaucoup avec des développeurs. Alors, que cherchez-vous tous sur ce front pour cela ?

LAWRENCE EDMONDSON : Oui, bien sûr. Juste pour continuer sur ce que Jimmy a dit, bien sûr, nous travaillons tous les deux dans la publicité. Je pense donc que nous voyons beaucoup des mêmes défis lorsque vous travaillez dans la publicité par rapport à un environnement de produit. Pour nous, nous touchons à de nombreuses technologies différentes, à de nombreuses piles technologiques différentes. Nous devons être techniquement agnostiques. Donc, ce que nous voyons, c'est que les consommateurs s'engagent de multiples façons maintenant via le mobile et les réseaux sociaux. Il y a quelques années, le bureau était le principal moyen d'accéder aux sites et au contenu. Maintenant, c'est complètement inversé. Il est passé du bureau au mobile pour, maintenant, social.

Par conséquent, vos couches d'API et vos couches d'application doivent être verrouillées de manière à associer un peu de paranoïa saine. Donc, ce que nous constatons, c'est que le spectre des attaques s'élargit, nous recherchons donc constamment de nouvelles façons d'amener les DevOps à penser comme des programmeurs afin qu'ils comprennent les façons possibles de violer les choses. C'est un peu ce que nous faisons aujourd'hui.

MODÉRATEUR : Merci pour cela. Et vous avez mentionné comment le vecteur d'attaque augmente. Et c'est quelque chose que nous avons ici, chez WP Engine, nous avons examiné davantage comment adopter un mécanisme de défense en profondeur. Donc, ne faites confiance à aucune couche pour être sécurisée. Et alors, comment intégrez-vous cela dans votre façon de coder et d'écrire des logiciels. Alors merci pour ça. Comme vous avez tous parlé de l'évolution de la tendance qui se produit là-bas, des violations qui se sont produites au cours de la dernière année. Alors, en ce qui concerne 2023, quels sont les principaux thèmes ou menaces auxquels vous prêtez tous attention ? Et peut-être, Sergi, tu peux nous lancer. Ouais.

SERGI ISASI : Bien sûr. Et cela va sembler idiot parce que nous sommes en 2023 et je vais dire le mot DDOS, mais c'est toujours une chose. Et cela a vraiment été un changement intéressant au cours des neuf ou douze derniers mois dans le monde DDOS. Le volumétrique n'est pas vraiment un vecteur DDOS de nos jours. Il y a beaucoup moins de réflexion. Et du point de vue d'un acteur malveillant, il est à la fois plus facile de lancer un DDOS parce que vous disposez de nombreux outils prêts à l'emploi, n'est-ce pas ? Nous sommes presque revenus à l'époque des scripts TD, mais vous avez également beaucoup moins de systèmes compromis à attaquer. Donc, si vous essayez de réfléchir, il n'y a pas beaucoup d'infrastructures gérées par quelqu'un qui n'a peut-être pas corrigé son système, vous pouvez donc prendre un paquet et le transformer en 10. Ce n'est plus vraiment un problème.

Ils passent donc à la couche 7. Et la couche 7 est à la fois plus chère à lancer dans la mesure où vous avez besoin de beaucoup de CPU pour le faire, mais c'est aussi beaucoup plus cher à atténuer. Donc, si vous avez une sorte de système de protection DDOS, vous devez en fait accepter la connexion, l'examiner, puis commencer à la supprimer par rapport à quelque chose que vous pourriez supprimer à une couche inférieure. Ce que nous avons trouvé et nous avons atténué le plus grand DDOS de couche 7 signalé le mois dernier. Le grand thème de ces attaques est des appareils plus puissants.

Donc, si vous pensez à toutes les choses que nous avons branchées à la maison ces jours-ci, le processeur de cet appareil est nettement meilleur qu'il ne l'était il y a trois ou quatre ans. Votre appareil photo en fait donc beaucoup plus. Il a donc un processeur plus puissant, même vos routeurs sont en fait une machine assez puissante. Et tout compromis sur ces appareils peut permettre une grosse, grosse attaque, d'autant plus que, si vous en compromettez un, vous compromettez maintenant pratiquement tous ceux qui sont connectés.

L'autre chose dont nous parlons un peu ces jours-ci, mais qui est un peu plus calme, c'est que nous sommes passés de périphériques matériels compromis à des comptes compromis sur les services cloud. Les services cloud ont effectivement un processeur illimité. Donc, si je peux accéder à un certain nombre de comptes de particuliers ou d'entreprises et faire tourner ce que je veux dans ce système cloud, je peux alors lancer une attaque extrêmement importante. Et c'est ce que nous voyons sur les attaques record. Alors oui, 2023, toujours DDOS, toujours une chose, mais maintenant à la couche 7 par rapport aux couches inférieures.

MODÉRATEUR : Merci. C'est effrayant, mais en même temps, je pense que cela montre comment nous continuons à améliorer nos protocoles de sécurité et le domaine d'intervention continue de croître. Je sais, Lawrence, vous et moi avons discuté dans le passé de l'IA à la fois comme un boom et une menace. J'aimerais entendre certaines de vos réflexions sur l'IA générative et comment vous voyez que cela a un impact réel sur la surface de la sécurité en 2023.

LAWRENCE EDMONDSON : Je suis donc très excité, très optimiste sur l'IA. On est chez Barbarian, mais en même temps, ça fait très peur. Le potentiel de quelque chose comme un chatGPT utilisé de manière malveillante. Ainsi, par exemple, vous pouvez demander à Chat GPT de commenter votre code. Et il fait en fait un travail assez décent, selon la langue et la confusion de votre code, il fait un très bon travail. Donc, la prochaine chose, je pense, que nous verrons, c'est pour Chat GPT - et cela pourrait déjà être en cours parce que chaque jour, il y a comme, Chat GPT fait ça. Comme aujourd'hui, je viens de voir qu'il est capable de répondre dans Slack et de trouver des réponses dans Slack.

Donc, je pense que la prochaine chose, en termes de sécurité, dans Chat GPT, c'est que Chat GPT trouve des exploits et écrive en fait le code sur un code malveillant pour vraiment exploiter les faiblesses qu'il trouve. Nous voyons donc cela, en particulier le potentiel de cela dans la mémoire. Ainsi, les attaques de mémoire ne laissent pas une signature tout le temps. Alors les virus traditionnels et les scanners de virus, ils travaillent sur la recherche de signatures d'une attaque. Dans les attaques de mémoire, vous attaquez l'application. Vous faites quelque chose comme un débordement de tampon. Vous cherchez à compromettre l'application lors de l'exécution. Je pense que Chat GPT est en fait sur le point de le faire. Et je pense que ce n'est qu'une question de temps avant que nous voyions le premier exploit ChatGPT à grande échelle se produire.

TIM NASH : Comment envisagez-vous que cela se produise ? Parce qu'évidemment ChatGPT, en son cœur, n'est qu'un ensemble de requêtes API à un serveur. Et vous envoyez une requête qui dit, hé, générez-moi du code malveillant. Il le retourne. Je veux dire, il y a beaucoup de gens qui génèrent déjà du code malveillant. Comment feriez-vous alors pour que cela soit pire que le code malveillant qui existe déjà ?

LAWRENCE EDMONDSON : C'est donc exactement cela. Il existe déjà un grand référentiel à partir duquel apprendre. Donc ChatGPT, ce qu'il fait, il regarde réellement - vous devez former le modèle. Ainsi, au fil du temps, les ingénieurs entraînent le modèle à reconnaître quand quelqu'un dit cela, c'est en fait ce qu'il veut dire. Alors comprenez le contexte. C'est donc exactement cela, mais d'une manière différente. Il s'agit de former le modèle à écrire du code et ce que cela signifie réellement. Et certaines langues sont très faciles. Donc PHP, assez facile d'écrire du code en PHP. Ces langages interprétés sont beaucoup plus faciles. C'est beaucoup plus désordonné, mais au lieu de faire quelque chose comme un Java, qui doit être compilé, vous voyez ce que je veux dire ?

Donc, je pense qu'un moyen simple de le faire serait de créer un modèle basé sur chatGPT 3 qui, en fait, vous l'entraînez en fait - vous passez à travers les trucs de syntaxe, vous passez à travers toutes les choses informatiques de base et ensuite vous le prenez un pas en avant et c'est parti, OK, ces packages NPM ont ces exploits. Cherchez-le et allez trouver un moyen de réellement– ils ont ces vulnérabilités, je suis désolé, et cherchez un moyen d'exploiter ces vulnérabilités. Je le garantis, nous ne sommes pas trop loin de voir quelque chose comme ça se produire.

MODÉRATEUR : Merci, Laurent. Je pense que c'est un domaine très naissant. Ce qui est intéressant dans cet espace, c'est à peu près cela avec l'IA, en général, il y a à la fois cet équilibre entre ce pour quoi vous pouvez en tirer parti, qu'il s'agisse d'utiliser réellement ces signatures pour prévenir et en tirer des leçons pour voir comment vous pouvez nous empêcher de écrire du code médiocre ou du code vulnérable. Et en même temps, tout comme nous avons vu que les gens parlent de, hé, j'ai écrit mon premier plug-in en cinq minutes avec Chat GPT, je pense - ouais, c'est plus sur le fait que cela commence à permettre aux gens de créer un peu de malware plus rapide? Mais je pense qu'il y a les deux aspects.

Il s'agit davantage de savoir comment continuer à tirer parti de l'un de ces outils pour simplement améliorer l'écriture de code, mais en écrivant un code plus sécurisé. Et je sais, Tim, que c'est un domaine qui te passionne. Souhaitez-vous parler un peu plus de la façon dont vous voyez Secure Code évoluer en 2023 et de ce que vous faites dans cet espace ?

TIM NASH : Eh bien, je veux dire, à bien des égards, Chat GPT en est un bon exemple. Si je pensais à un vecteur d'attaque, je vais être honnête, je ne pensais pas qu'il ferait un balayage de masse, le nourrissant de beaucoup de choses comme un mauvais acteur. Je pensais à cela comme au développeur de code moyen qui essayait de gagner du temps et introduisait des éléments dans Chat GPT et le jetait et ne comprenait pas nécessairement tout le code qui était écrit, produit, n'avait pas écrit de tests pour allez avec. C'est juste une chose rapide, c'est juste un script rapide, tout va bien. Il entre en production, il ne va pas bien et tout brûle.

Maintenant, c'est exactement la même chose que quelque chose que chaque développeur fait chaque jour, peu importe. Chat GPT ne change pas cela, mais il l'active un peu plus facilement. Cela donne - il y a moins d'obstacles.

SERGI ISASI : Ouais, donc ce n'est pas tout à fait la même chose que copier et coller à partir de Stack Overflow, auquel je pense que vous faites référence, Tim, qui est essentiellement tout ce que je fais pour le code. Mais je pense que c'est une augmentation de l'efficacité à coup sûr, à la fois positive et négative. Mais je pense que cela permet des changements plus subtils et une exploitation plus rapide de quelque chose que le moteur basé sur les signatures ne peut pas vraiment rattraper. Donc, lorsque vous faites de la détection, vous avez vraiment besoin d'un système qui dit, est-ce que cela ressemble à quelque chose que j'ai vu dans le passé, par opposition à une correspondance directe avec quelque chose que j'ai vu dans le passé. Et c'est en fait du côté de la détection également probablement mieux servi avec ML ou AI ou comme vous voulez l'appeler.

Nous avons appris qu'avec le trafic automatisé, vous savez, essentiellement des bots. Le ML est le meilleur moyen de savoir comment ils contournent la détection basée sur les signatures. Mais vous passez maintenant de, je sais absolument que c'est mauvais, à, eh bien, c'est susceptible d'être automatisé, ou susceptible de ressembler à une signature que j'ai déjà vue, mais pas une correspondance exacte.

MODÉRATEUR : Merveilleux. Merci. Merci, Sergi et Tim pour ce contexte supplémentaire. Ainsi, parmi nos participants, nous avons beaucoup de développeurs et d'agences qui sont présents ici aujourd'hui. Et beaucoup de gens pensent à établir des bonnes pratiques, d'autant plus que les scénarios évoluent en termes de vecteurs de menace. Alors, quelles sont les meilleures pratiques que vous recommanderiez lors de la création d'un site, d'une application ou d'une plate-forme, ou tout simplement lorsque vous démarrez un nouveau projet. Alors, quelles sont les choses que les gens devraient surveiller ?

SERGI ISASI : Je peux donc commencer. Ce serait plus du côté opérationnel que du côté du développement. Je pense que l'une des choses que nous prêchons ici est, premièrement, de supposer que quelque chose de mauvais va arriver. Donc une brèche arrive, vous ne pouvez pas vous laisser surprendre. Il est probable que cela se produise à un moment donné. Et notre clé - alors, un, créez un runbook pour cela. Ainsi, lorsque cela se produit, sachez quelles personnes contacter et quelle sera votre réponse, à la fois de la détection et de la réponse, mais également en communiquant avec vos clients si cela les affecte. Et à cette fin, la chose que nous, je pense, faisons très bien chez Cloudflare et cela fait partie de notre marque et je pense que cela nous a très bien servi est d'être franc, ouvert et aussi communicatif que possible sur n'importe quoi cela s'est passé.

L'ouverture a été essentielle pour rétablir la confiance avec les clients lorsque quelque chose se produit, qu'il s'agisse d'une violation de logiciel ou d'une erreur que vous avez commise en termes d'incident. Se cacher derrière n'est jamais la bonne décision.

MODÉRATEUR : Oui.

JIMMY SQUIRES : Je pense que quelque chose d'autre aussi est que nous avons - maintenant que tout le monde est évidemment distant et en particulier dans les équipes de développement, prend en fait le temps au début d'un projet de faire du tableau blanc et de la planification architecturale. Il est si facile de plonger directement dans les exigences et de raconter des histoires de développement, mais passer du temps avec vos pairs pour vous demander comment cela pourrait être exploité ? Exécutez des scénarios. Nous faisons beaucoup de planification de scénarios qui mènent à beaucoup de bonnes conversations avec, comment nous voulons consolider différentes parties de l'application.

LAWRENCE EDMONDSON : Et juste à ce sujet, je ne sais pas si quelqu'un le sait, mais MPM est en fait le plus grand référentiel de partage - c'est le plus grand référentiel de bibliothèques d'applications, mais cela signifie qu'il présente également le plus grand risque. Donc, une chose dont nous sommes très conscients lorsque nous entreprenons un nouveau projet si nous utilisons NPM est de nous assurer que nous examinons les vulnérabilités, que nous verrouillons les versions que nous poussons à la production, avant que nous 'faire une mise à jour, nous nous assurons que c'est quelque chose qui est compatible, mais aussi très sécurisé. Il n'y a pas de menaces ouvertes car nous avons vu de nombreuses vulnérabilités se glisser dans NPM. Donc, c'est juste une chose à surveiller.

TIM NASH : Je pense que nous sommes en train de tout boucler.

JIMMY SQUIRES : Allez-y, Tim.

TIM NASH : Je pense que nous ramenons tout cela à l'idée que, vraiment, la confiance est complètement brisée dans les cycles de développement pendant des années. Les gens commencent juste à s'en rendre compte maintenant. Et si vous êtes un développeur PHP travaillant dans WordPress par exemple, vous restez assis à appeler des actions et des filtres, mais vous ne devriez pas faire confiance à ces actions et filtres. Toutes les données qui arrivent, vous devriez les valider, vous devriez les vérifier. Il devrait être désinfecté. Mais quand il sort de la base de données, vous ne devriez toujours pas lui faire confiance.

Même si vous avez peut-être mis ces données dans la base de données, vous ne devriez pas faire confiance aux données qui sortent. Si nous passons quelque chose à une bibliothèque tierce, que ce soit ce NPM, ce package de composition ou simplement un autre plugin WordPress, immédiatement il a quitté notre contrôle, nous ne lui faisons plus confiance. Mais quand il revient, même si nous l'avons vérifié, nous ne lui faisons toujours pas confiance. Et si vous partez avec cet état d'esprit, en tant que développeur, que chaque élément de données ne doit pas être fiable et doit être isolé tout au long et que vous devez effectuer les vérifications de sécurité à chaque moment donné, vous arriverez avec un système beaucoup plus sécurisé. Vous pourriez sortir avec un système légèrement plus lent. Vous pourriez rencontrer un système légèrement plus frustrant, et qui nécessite beaucoup plus de tests pour vous assurer que ce que vous faites ne cause pas plus de problèmes qu'il n'aide.

MODÉRATEUR : Oui.

TIM NASH : Ajoutez des complications, mais vous vous retrouvez avec un système beaucoup plus sécurisé. Et pour la plupart des gens, c'est ce qu'ils veulent.

LAWRENCE EDMONDSON : Oui.

MODÉRATEUR : Oui. Vous avez absolument raison. Il s'agit de ne faire confiance à aucun autre morceau de code qui passe. Et pour ce dont Jimmy et Sergi ont parlé, il s'agit d'avoir un plan et d'un point de vue architectural, ou d'un point de vue opérationnel, mais de rassembler tout cela dans votre pratique globale, que ce soit comme des mécanismes de codage sécurisés ou que vous ayez un manuel d'incident. Alors Tim, je suis très intéressé à en savoir plus sur vous – vous faites beaucoup de formation, vous faites beaucoup d'enseignement dans le monde entier. Quelles sont les erreurs courantes que vous voyez lorsque les gens commencent à travailler sur des projets, ou des erreurs que vous avez pu commettre, j'en ai commis beaucoup.

TIM NASH : J'allais dire, je suis à peu près sûr d'être coupable de toutes les erreurs dont je vais parler. Et le plus grand et le plus simple est d'être une personne gentille. La plupart des développeurs supposent de bonnes intentions. La plupart des gens supposent que vous allez utiliser leur application comme vous l'avez écrite. Maintenant, très souvent, nous n'écrivons pas de documentation, de sorte que l'utilisateur n'a aucune idée de la façon d'utiliser l'application en premier lieu, mais c'est un problème distinct. Un mauvais acteur entrera et prendra n'importe quel bogue et partira, ce n'est pas un bogue, pour un mauvais acteur, c'est une fonctionnalité. C'est une opportunité. Il fait quelque chose auquel le développeur ne s'attend pas, par conséquent, il existe une voie potentielle vers cela.

Et dans l'ensemble, quelque chose que vous voyez maintes et maintes fois, quand vous dites, oh regardez, vous avez un ensemble de tests unitaires. Oh génial. Mais vous n'avez testé que les choses positives, le résultat que vous vouliez. Vous n'avez pas testé ce qui se passe si nous sortons de ces limites. Vous venez de tester pour vous assurer que la chose fonctionne selon ce que veut votre patron. Donc, ce que vous avez vraiment, ce sont des tests d'acceptation, des tests d'acceptation douteux. Et puis ça revient à toutes les bases. En tant que développeur, c'est reculé, ne faites pas confiance aux choses. Et si vous êtes un développeur WordPress en particulier, WordPress a en fait de très bonnes fonctions d'assistance pour faire toutes les sortes de choses de sécurité standard que nous demandons aux gens de faire.

Et il s'agit d'éduquer et d'apprendre à les utiliser. Lorsque je fais des revues de code, je vois encore et encore les mêmes problèmes. Et si je le vois une fois dans un morceau de code, je le verrai 1 000 fois dans le même ensemble de code. Et ce sera des choses comme, ouais eh bien, nous avons simplement autorisé l'apparition de tout ancien contenu sur la page. Nous n'avons pas pris la peine de vérifier s'il y avait ou non quelque chose dedans. Ouais, nous avons mis des trucs dans la base de données. Oh, regardez, cela pourrait ressembler à une requête SQL, peut-être pas.

Tous ces types de problèmes sont faciles à résoudre et nous avons déjà donné les outils pour les résoudre. Et la raison pour laquelle nous ne les réparons pas n'est souvent même pas que les gens ne savent pas qu'ils ne devraient pas laisser ces choses se produire, c'est juste que nous devenons paresseux, nous faisons les choses rapidement, nous récupérons le code de Stack Overflow, nous demandons à Chat GPT de faire des choses pour nous, nous ne vérifions pas les choses. Et beaucoup de problèmes de sécurité vient de cet état de fait, je dois me précipiter. Je dois me dépêcher. Je dois me dépêcher, je dois faire ça. Je passe à la chose suivante, je passe à la chose suivante.

Bizarrement, pour beaucoup de développeurs, en fait, leur donner le temps et l'espace et dire, c'est bien de prendre le temps de vérifier ce que vous avez fait pour que quand ça tombe - et dans les cas où j'entre en jeu, Je reviens et je dis, eh bien, toutes ces choses et les développeurs ont l'air penauds. Ils vont, ouais, on sait tout ça. Nous n'avions tout simplement pas le temps.

Donc, espérons-le, donner plus de temps aux gens et leur donner les outils, que nous avons déjà en particulier dans WordPress. WordPress a un ensemble vraiment brillant de fonctions d'assistance pour les problèmes de sécurité les plus courants que vous auriez dans un plugin ou un thème WordPress. Il s'agit donc simplement de les apprendre et d'investir du temps pour les mettre en œuvre.

MODÉRATEUR : Oui. Et je pense que c'est vraiment puissant, investir du temps. Le plus souvent, les développeurs savent ce qui doit être corrigé. Donc leur laisser du temps. Donc vraiment j'aime ce message. Et Jimmy, je sais que vous avez intégré cela dans votre propre flux de travail dans votre agence. Vous voulez parler un peu plus des pratiques de workflow sécurisé que vous avez mises en place ?

JIMMY SQUIRES : Oui, absolument. Et vraiment, cela commence par avoir juste quelque chose que Sergi a dit, c'est avoir un plan, avoir en fait des directives et des normes à suivre pour votre équipe de développement. Je sais que cela semble probablement très basique, mais j'ai vu beaucoup d'organisations et j'ai entendu beaucoup d'ingénieurs que nous avons embauchés au fil des ans que cela n'existait pas. Il n'y avait pas d'organisation sur le lieu de travail d'où ils venaient.

Donc, ce que nous aimons faire, c'est que nous avons un ensemble de directives standard, que tous nos nouveaux ingénieurs doivent lire de fond en comble. Ce n'est pas si lourd qu'il n'est pas consommable. Nous aimons le garder dans Markdown, donc tout est dans un référentiel. Nous l'ouvrirons probablement en source ouverte à un moment donné. Il n'y a rien là-dedans qui soit vraiment exclusif, et nous encourageons tout le monde à y contribuer. C'est une demande à tous les ingénieurs.

Donc, même dans nos directives, percez des trous là où nous pouvons ajouter, où nous pouvons être meilleurs, en augmentant continuellement cela. Mais passer du temps avec ça, certaines des choses de base comme OWASP, c'est une très vieille pratique, mais passer par là avec votre application, en tenant compte de ces choses. C'est un peu ce que Tim a dit, c'est vraiment prendre le temps et être d'accord pour prendre le temps avec ça. Je voulais ajouter un point supplémentaire à la conversation sur l'IA. Parler avec quelques-uns de nos ingénieurs la semaine dernière a en fait eu un événement. C'est quelque chose pour lequel nous utilisons Chat GPT, c'est en fait des tests unitaires. En prenant une fonction et en l'explorant de manière intéressante, comment pouvez-vous tirer parti de quelque chose comme Chat GPT pour écrire un test unitaire où vous n'allez pas être le meilleur auteur de ce test unitaire, au point de Tim. C'est là que je pense que nous pouvons exploiter beaucoup plus l'IA de manière préventive.

LAWRENCE EDMONDSON : Oui. Ce que nous faisons de notre côté, je pense que les listes de contrôle et le fait d'avoir un playbook sont super. Nous utilisons des outils automatisés tels que SonarQube et avons vraiment des peluches en place et des choses comme ça, juste pour augmenter la qualité du code avec des peluches, mais aussi en utilisant SonarQube pour nous assurer que le code est plus sécurisé, que nous recherchons pour les vulnérabilités et des choses comme ça. Je pense que certaines langues sont plus faciles que d'autres à trouver des exploits, comme je l'ai déjà mentionné, simplement à cause de la nature de la langue. Et aussi juste certains frameworks où la qualité des codeurs qui contribuent à cette base de code généralement - nous le voyons généralement avec Open Source, où c'est comme - il y a beaucoup de copier-coller Stack Overflow en cours, par rapport aux gens qui ont réellement étudié CS et savent vraiment ce qu'ils font. Donc c'est juste une chose que j'ai vue.

TIM NASH : J'ai l'impression que nous devrions souligner, certainement pour moi, que j'utilise Stack OverFlow presque tous les jours. Et donc nous en sommes tous coupables. C'est bien d'insister là-dessus, mais je ne pense pas… Je veux dire, je me souviens quand j'ai commencé à coder. J'ai reçu un magazine et tapais le code du magazine et j'appuyais sur Entrée. Je ne peux pas imaginer que le Web fonctionne vraiment aujourd'hui si nous continuons à faire cela et n'avons pas Stack Overflow, ou similaire.

Sergi : Non, c'est l'accélérateur. Et j'espère que l'IA en est la prochaine étape. Mais oui, c'est un mème amusant.

MODÉRATEUR : Merci. Donc ça bouge un peu. Il y a beaucoup d'élan qui se passe dans l'industrie autour des implémentations Headless et Headless. Et nous avons également vu dans certaines de nos autres chaînes aujourd'hui ou d'autres sessions parler de Headless. Ainsi, lorsque nous avons commencé à travailler avec Atlas chez WP Engine, nous avons rencontré de nombreux développeurs et la sécurité a toujours été une motivation clé. Alors, comment voyez-vous la sécurité avec Headless ? Et je sais, Jimmy, c'est un domaine où vous avez fait des projets autour de lui. Nous serions ravis d'avoir votre avis là-dessus.

JIMMY SQUIRES : Oui, nous travaillons beaucoup dans Headless. Je pense que presque tous nos projets à ce stade adoptent probablement une approche d'architecture Headless. Je pense qu'il y a quelques points que je veux juste faire valoir à ce sujet, en ce qui concerne la sécurité. Je pense donc que la première est que lorsque vous choisissez une architecture Headless, vous vous placez généralement davantage dans le camp open source au début. Et il y a beaucoup de débats, bien sûr, sur ce qui est le plus sûr, open source ou fermé. J'ai tendance à tomber dans le camp des projets OSS plus sécurisés par nature. Vous choisissez donc des frameworks comme Next, WordPress, où vous avez une communauté géante. Et cela a tendance à se prêter à plus de sécurité grâce à une simple exposition.

Donc je pense que c'en est un. Je pense que le second est quelque chose comme Static Generation. Donc, pour beaucoup de sites Web et de produits qui sont construits, vous n'avez pas besoin de la nature dynamique d'une grande gestion de contenu, d'un système monolithique au sens traditionnel. Vous pouvez tirer parti de quelque chose comme Cloudflare et générer vraiment statiquement de grandes parties de cette application, réduisant ainsi votre empreinte pour les vecteurs et l'exposition. Nous sommes donc de grands fans de cela. Et puis, bien sûr, vous bénéficiez également de tous les avantages en termes de performances. Ce ne sont donc que quelques points que je voulais souligner sur l'architecture Headless. Mais beaucoup plus de raisons du point de vue de la sécurité que nous l'aimons. Mais je pense que ce sont probablement deux des domaines les plus remarquables.

TIM NASH : J'aimerais simplement revenir en arrière et rappeler aux gens qu'il y a toujours un système de gestion de contenu à l'arrière. Et ça j'entends trop souvent, Headless est totalement sécurisé. C'est comme, oui, mais cette instance WordPress exposée qui est toujours là, simplement parce que vous ne l'appelez pas directement depuis le site Web, oui, elle est toujours là sur admin.yoursite.com. Et vous n'avez pas - il y a une certaine croyance que, oh oui, eh bien, nous sommes en sécurité maintenant, nous n'avons donc pas à nous soucier de le maintenir à jour car ce n'est pas le site Web. C'est comme, non, non, tu as toujours besoin de tout ce que tu faisais avant et maintenant nous avons aussi l'autre côté.

Et je veux dire, Headless est un excellent terme qui désigne quelque chose qui existe depuis longtemps et qui prend beaucoup d'ampleur, mais nous le faisions avant que WordPress n'ait une API REST. Nous poussions le contenu de WordPress vers des choses comme Jekyll pour en tirer au moins un site statique. Et le raisonnement initial pour faire cela était de faire varier le système WordPress ou votre système de gestion de contenu à l'intérieur de votre réseau. Vous pouvez donc le verrouiller et le protéger de la grande toile effrayante.

Nous recevons maintenant de nombreuses sociétés d'hébergement qui fournissent des solutions Headless. And that infrastructure is now out in the cloud again. So we've sort of moved the big benefit for Headless. And we're slowly shifting it back into the public domain again, which seems like a very almost backwards move, but it's the only move for widespread adoption. So there's a balancing act we have there. But yeah, just a small little warning into the big space of keep the backend secure still. You can't just rely on it being–

TIM NASH: Just because something's got some HTML files at the front, the back end still needs to stay just as secure as before.

MODERATOR: Yeah, absolutely. I mean, Headless, by default, doesn't mean that everything is secure. It means that you have a different paradigm. And that's what I think I was interested in, looking at what practices that you bring in as you look at Headless infringers. So yeah, I think that's you're very apt in stating that you still have to secure both the CMS part, as well as the web part of it. So as we are wrapping up, what I would love to do is we have had a lot of good topics to talk about in here, but I would love to take like 10 seconds from each one of you to say that if there is one thing that our audience could do in these next two months after the end of the session, what would that be? What's your recommendation?

LAWRENCE EDMONDSON: I guess I'll start off. My recommendation would be very simple. Security should be everyone's business. I think a lot of times, security doesn't become a topic or consideration until there's a problem. If I were a developer, I would make sure that I am being very proactive in terms of taking the necessary steps. It's 2023, we shouldn't be storing anything in clear text.

Everything should be encrypted as much as you can. Use Hashicorp, encrypt your database and make sure that your keys are stored securely, or it's something that's not easily compromised. But that's what I would encourage folks to make sure that security is top of mind all the way throughout.

MODERATOR: Thank you, Lawrence. Sergi, what about you?

SERGIS ISASI: I would say get an inventory of what's exposed. Know what's on the internet and make sure that the proper– at least aware of what's there, if not fully protecting it.

MODERATOR: Thank you. And Jimmy?

JIMMY: Scenario planning. Take the time in your project to do the scenario planning and create those playbooks, both preventative and then reactive once something does happen, to Sergi's point earlier. What are your action steps for that? Take that time and the project will pay off dividends later.

MODERATOR: Wonderful. Merci. And Tim, bring us home.

TIM NASH: Oh, I want to reinforce what Lawrence said. Security is everybody's responsibility. Give people the time and space to actually do their jobs properly and you'll find that you will come out with a much more secure project.

MODERATOR: Thank you. Security is indeed everyone's responsibility. So thank you to our amazing panelists for taking the time today and also to everybody in the audience. Hope you enjoyed this session. Thank you and bye.