David Mytton, PDG d’Arcjet – Série d’entretiens

David Mytton, fondateur et PDG d’Arcjet, dirige la startup de sécurité axée sur les développeurs qui aide les équipes à intégrer des protections robustes comme la détection de bots, la limitation de débit, la validation d’e-mail, l’atténuation des attaques et la réduction des données directement dans le code de l’application, ayant pris les rênes en juin 2023. Il a également co-fondé Console, une newsletter et un podcast de devtools très suivis, a occupé des rôles de conseiller tels que Expert en résidence chez Seedcamp et a précédemment dirigé l’ingénierie de produit chez StackPath après que son entreprise de surveillance cloud ait été acquise, tout en maintenant un fort intérêt pour l’informatique durable et en écrivant activement sur les sujets technologiques.

Arcjet est construit autour d’une philosophie de « sécurité dans le code » qui permet aux développeurs de sécuriser les applications avec des intégrations de SDK simples, en plaçant la logique de sécurité aux côtés de la logique métier pour des décisions à faible latence et sensibles au contexte, et en éliminant le besoin d’infrastructures distinctes ; la plateforme prend en charge des protections telles que le blocage de bots, les limites de débit et le filtrage de données sensibles, et continue d’évoluer avec des fonctionnalités telles qu’un modèle de sécurité local basé sur l’IA et un support de framework étendu, reflétant sa mission de rendre la sécurité dans le code la norme pour les applications modernes. (fly.io)

Vous avez fondé Server Density à une époque où l’exécution d’infrastructures à grande échelle était beaucoup moins standardisée qu’aujourd’hui, et vous avez finalement développé et vendu l’entreprise. En regardant en arrière, quels ont été les enseignements les plus importants que vous avez tirés sur la construction pour les développeurs et l’exploitation de systèmes de production, et comment cette expérience a-t-elle façonné votre façon de penser le logiciel aujourd’hui ?

La plupart des outils de développement gagnent la démo et perdent la production. Faire installer quelque chose de nouveau à un développeur est difficile, donc « démarrage rapide » doit être sans friction – mais c’est un minimum. Le véritable mode de défaillance est ce qui se passe après « cela fonctionne » : le produit devient contraint, les équipes sérieuses s’énervent rapidement et le retirent.

C’est pourquoi la sécurité d’application dans le code d’Arcjet est conçue pour deux réalités : vous avez besoin d’une solution immédiate pour le spam d’inscription, la fraude de compte, les attaques de bots, l’abus d’API, etc., et vous avez également besoin d’une issue de secours vers des contrôles avancés – quotas par utilisateur, règles basées sur les risques, décisions sensibles au contexte – sans tout réécrire.

Le produit n’est pas l’interface utilisateur. Le produit, c’est le comportement d’exécution, les cas de bord, les exemples et la documentation de référence que les développeurs peuvent faire confiance.

En sortant de cette expérience, qu’est-ce qui vous a amené à créer Arcjet, et pourquoi avez-vous senti que le prochain grand changement dans la sécurité des applications devait se produire à l’intérieur du code lui-même plutôt qu’au niveau du réseau ou de l’infrastructure ?

La sécurité de périmètre optimise la mauvaise chose. Les développeurs construisent et livrent dans le code, pas dans les tableaux de bord – et les agents de codage IA ne « cliqueront pas » sur une console de sécurité pour protéger une application.

Si votre protection ne peut pas être exprimée en code, examinée dans une demande d’extraction, testée dans un système d’intégration continue et déployée aux côtés de l’application, ce n’est pas une « sécurité axée sur le développeur ».

Arcjet existe parce que la sécurité appartient à la couche d’application : contrôlée par version, testable, observable et proche de la logique métier où réside réellement l’intention.

Arcjet intègre la détection de menaces basée sur l’IA directement dans les gestionnaires de requêtes d’application. D’un point de vue technique, quels avantages cette approche locale et dans le code offre-t-elle par rapport aux outils de sécurité traditionnels basés sur le périmètre ?

À l’intérieur d’un gestionnaire de requêtes, vous avez l’identité, l’état de session, l’historique d’achat, l’âge du compte, les indicateurs de fonctionnalité et la vérité de la base de données. Vous pouvez prendre une décision comme : « Cela semble étrange, mais c’est un client loyal – renforcez la vérification au lieu de bloquer. » Un proxy réseau ne peut pas le faire car il n’a aucune idée de ce qu’est un « client ».

L’objectif n’est pas de bloquer au maximum. L’objectif est de minimiser les faux positifs avec une sécurité sensible au contexte, car l’erreur de sécurité la plus coûteuse est de bloquer une vérification légitime ou de verrouiller un utilisateur réel.

L’IA a dramatiquement changé l’économie de l’abus, des scrapings de bots et des inscriptions de spam aux exploitations d’API automatisées. Quels types d’attaques voyez-vous le plus souvent en production aujourd’hui, et comment évoluent-elles à mesure que les attaquants adoptent des systèmes d’IA plus avancés ?

Les gains de productivité de l’IA aident également les attaquants ! Le grand changement est le volume et la vitesse d’itération : plus de bourrage de mots de passe, plus de spam d’inscription automatisé, plus de scraping de bots, plus de sondage d’API et une « armement » plus rapide des vulnérabilités fraîches.

Nous voyons également les attaquants exécuter des boucles de rétroaction plus serrées : ils testent les défenses, adaptent les invites et les charges utiles, font pivoter les infrastructures et continuent jusqu’à ce qu’ils y parviennent. C’est actuellement tout à propos de la vitesse plutôt que de la sophistication.

Il y a encore trop peu de personnes qui suivent les meilleures pratiques telles que l’utilisation d’un gestionnaire de mots de passe, le déploiement d’une authentification à deux facteurs avec des informations d’identification résistantes à la phishing comme des passkeys ou des clés matérielles, et la mise à jour des dépendances. Avec l’augmentation du volume des attaques, cela va devenir de plus en plus important.

L’une des plus grandes tensions en matière de sécurité est de protéger les applications sans ralentir le développement. Comment les équipes utilisant Arcjet ont-elles pu intégrer la sécurité dans leurs flux de travail tout en maintenant des cycles de publication rapides ?

Arcjet s’exécute dans n’importe quel environnement, y compris dans l’environnement de codage sur un ordinateur portable. Cela signifie que les développeurs peuvent le tester sans même le déployer en production. C’est un avantage significatif car vous pouvez le valider et démontrer l’intégration sans avoir besoin de permissions spéciales et sans risque d’affecter la production. Cela résout le problème classique des équipes de sécurité qui obligent les développeurs à adopter des outils qui entravent leur capacité à faire leur travail.

Arcjet a gagné une traction précoce avec des produits et des plateformes de commerce électronique natifs IA. Qu’est-ce qui rend ces environnements particulièrement vulnérables aux attaques automatisées modernes, et pourquoi les défenses héritées ont-elles tendance à faire défaut ?

Ces deux catégories partagent une similitude où chaque demande abusive a un coût direct.

Les produits IA paient pour les jetons et l’inférence – les attaquants transforment votre marge en leur terrain de jeu via le scraping, l’automatisation et l’exploitation des offres gratuites. Le commerce électronique paie pour la fraude, les rejets de charge, l’abus d’inventaire et la prise de contrôle de compte. Et les deux sont hypersensibles aux faux positifs, car bloquer les utilisateurs réels équivaut à une perte de revenus.

Les défenses héritées protègent principalement la bande passante et l’infrastructure. Les attaquants modernes ciblent la logique métier : les flux d’inscription, les flux de paiement, la logique de promotion, la récupération de compte et les points de terminaison d’API. C’est pourquoi les contrôles de périmètre génériques et « résoudre avec un CAPTCHA » ne suffisent pas de plus en plus.

La construction de logiciels de sécurité comporte des compromis très différents que ceux de l’observabilité ou de la surveillance. Qu’est-ce qui vous a le plus surpris dans le développement d’un produit de sécurité par rapport à votre expérience antérieure avec les outils d’infrastructure ?

Avec l’observabilité, les clients font confiance pour que vous soyez disponible. Avec la sécurité, les clients font confiance pour que vous soyez en sécurité et pour ne pas devenir leur dernière faille de chaîne d’approvisionnement.

Construire un produit de sécurité signifie diriger une entreprise de sécurité. Nous utilisons des cadres tels que SOC 2, minimisons nos dépendances tierces et traitons les ordinateurs portables des développeurs et l’accès aux outils comme des actifs de production. Cela signifie beaucoup de surveillance et de réactions rapides aux problèmes potentiels.

À mesure que les applications s’appuient de plus en plus sur des agents IA agissant au nom des utilisateurs, comment les développeurs devraient-ils repenser les idées d’identité, d’intention et de confiance à la couche d’application ?

Lorsque les agents IA agissent pour les utilisateurs, l’identité cesse d’être un état de connexion binaire et devient un problème de délégation : qui agit, au nom de qui, avec quels permissions, pour combien de temps et avec quels contraintes.

Les développeurs devraient passer à une vérification continue : traiter chaque demande comme ayant besoin d’une décision de confiance fraîche basée sur le contexte – historique de l’utilisateur, signaux de l’appareil, comportement de session et risque d’action. « L’intention » est déduite du comportement au fil du temps, et non revendiquée dans les en-têtes.

Cela signifie construire des moments d’escalade (vérification, limites de débit, friction) autour des actions à haut risque comme la réinitialisation du mot de passe, le paiement et la création de jetons – et faire vivre ces contrôles dans le code, où l’application peut distinguer un client loyal d’un bot avec un cookie volé.

En regardant vers l’avenir, comment voyez-vous l’évolution du rôle de la sécurité dans le code et sensible au contexte au cours des prochaines années, à mesure que le trafic généré par l’IA continue de croître ?

Les outils de périmètre ne disparaîtront pas – mais ils seront le filtre grossier pour les choses les mieux traitées au niveau du réseau comme les attaques DDoS. Les décisions précises se produiront à l’intérieur de l’application, en utilisant un contexte réel.

Si la sécurité intégrée devient le modèle par défaut pour les applications modernes, quelle est l’importance de ce changement pour la façon dont les développeurs testent, déploient et raisonnent sur la sécurité dans les systèmes de production ?

Si la sécurité intégrée devient la norme, les équipes testeront les abus de la même manière qu’elles testent la correction : tests de sécurité unitaires, simulations d’attaque reproductibles et vérifications de points de terminaison à risque en CI.

Le plus grand changement est que les agents de codage IA mettront en œuvre la sécurité en tant que code, et non en tant que configuration de tableau de bord. Les agents ne peuvent proposer, examiner et valider des protections de manière fiable que lorsque les contrôles vivent dans le référentiel : politiques, règles, tests et instrumentation. Si la « couche de sécurité » est une interface utilisateur Web, l’agent ne peut pas tester les changements pour expédier en toute sécurité.

C’est la vraie raison pour laquelle la « sécurité dans le code » gagne – elle correspond à la façon dont le logiciel moderne (et le développement assisté par l’IA moderne) est réellement construit.

Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Arcjet.