Comment un CTO de startup SaaS équilibre-t-il vitesse de développement et sécurité ?

Leçons tirées d'anciennes entreprises SaaS

Dans une startup SaaS typique, l'équipe de développement est soumise à une forte pression pour livrer de nouvelles fonctionnalités. Vous avez généralement des concurrents potentiellement mieux financés, l'équipe commerciale qui demande une dernière fonctionnalité pour conclure une affaire, et l'équipe de support client qui réclame un correctif. Il peut être difficile de prioriser la sécurité, à moins qu'un client d'entreprise majeur ne l'exige ou que votre conseil d'administration ne l'impose.

Dans la plupart des startups, vous pourriez ne pas disposer d'une gamme complète de profils techniques : vous n'avez peut-être pas encore de product manager à temps plein, vous n'avez probablement pas de responsable de la sécurité à temps plein au sein de votre équipe de développement. Une équipe de développement sous pression pour livrer sera contrainte de faire des compromis, même en matière de sécurité.

J'ai été CTO de 3 startups SaaS en phase de démarrage (Teamleader, Officient & Futureproofed). Ci-dessous, j'ai résumé mes apprentissages tirés de ces expériences passées dans des entreprises SaaS.

Évitez de réinventer la roue

Un excellent exemple : ne construisez pas de système de connexion avec mots de passe. Oui, vous pourriez le construire en quelques jours, mais le coût de maintenance et d'ajout de fonctionnalités de protection avancées à l'avenir sera très élevé. Envisagez d'utiliser une connexion via Single Sign-On (SSO) comme Gmail ou d'utiliser un service tel que Auth0.com. Vous aurez non seulement une expérience de connexion plus fluide et plus riche en fonctionnalités, mais vous n'aurez pas non plus à vous soucier de toute une catégorie d'aspects de sécurité liés à la connexion (attaques par force brute, identifiants d'utilisateur divulgués dans des services tiers, prévention et détection des attaques de prise de contrôle de compte, validation des adresses e-mail, journalisation...).

Au final, en choisissant le bon fournisseur, vous ne faites pas que réduire votre surface d'attaque, vous gagnez également du temps qui peut être alloué à des fonctionnalités à plus forte valeur ajoutée.

D'autres excellents exemples qui pourraient vous faire gagner des semaines, voire des mois, sont :

• Ne stockez pas de cartes de crédit, utilisez des services comme Stripe, Mollie ou Chargebee
• Ne gérez pas vous-même des logiciels complexes comme MySQL, PostgreSQL ou ElasticSearch. Utilisez des services cloud gérés tels que RDS.
• Ne développez pas vos propres systèmes de logging. Utilisez des systèmes comme Sentry ou Papertrail (et n'y enregistrez aucune donnée sensible).
• Ne gérez pas vos propres serveurs de messagerie (SMTP), utilisez un service géré comme Sendgrid ou Mailgun
• Ne développez pas de serveurs websocket, utilisez des services gérés tels que Pusher.com
• Ne développez pas votre propre système de feature flagging, utilisez un service tel que Launchdarkly
• Ne développez pas votre propre intégration de calendrier, utilisez un outil comme cronofy.com
• Lors de la création d'intégrations en général, recherchez des API unifiées dans cet espace, telles qu'Apideck.

Consacrer du temps à la mise en place d'une communication de crise

Assurez-vous d'avoir mis en place des outils tels qu'une application de chat pour communiquer avec vos clients, ou mieux encore, une page de statut gérée ou un compte Twitter où vous pouvez signaler les problèmes. En cas d'incident, il est fortement recommandé de permettre au reste de votre entreprise de communiquer avec vos clients pendant que vous vous concentrez sur la résolution du problème en période de crise.

Ajouter des garde-fous globaux

Vous examinez probablement les Pull Requests de vos développeurs, c'est excellent ! C'est une tâche considérable de les examiner pour la maintenabilité, la performance, la fonctionnalité. Avez-vous le temps de les examiner également pour la sécurité ? Bien sûr, vous pourrez couvrir certains risques, mais il est appréciable de pouvoir en écarter d'autres en ajoutant des garde-fous et une configuration globale.

Parfois, il est possible d'avoir de la chance et de trouver des correctifs globaux pour des problèmes spécifiques.

• Si vous utilisez nodeJS et que vous ne voulez pas vous soucier de la pollution de prototype, vous devriez geler le prototype pour désactiver cette classe d'attaques à l'échelle de l'application. Aikido peut automatiquement créer une Pull Request qui le fait pour vous.
• Si vous utilisez SQL et que vous craignez les attaques par injection SQL (ce qui est recommandé), vous pouvez utiliser un WAF (comme AWS WAF) ou un RASP (comme la sécurité des applications de Datadog) pour une protection à l'échelle de l'application.
• Si vous découvrez de nombreuses attaques XSS, vous pouvez probablement en éliminer une grande partie en introduisant une politique CSP très stricte dans le navigateur.
• Si vous effectuez de nombreuses requêtes sortantes basées sur les entrées client, vous pourriez être vulnérable aux attaques SSRF. Bien qu'il puisse être difficile de bloquer cela complètement, vous pourriez atténuer les dommages en vous assurant que cela ne peut pas mener à quelque chose de pire (comme une attaque IMDSv1 sur les identifiants IAM dans AWS). Aikido surveille cela dans votre cloud AWS par défaut.
• Lorsque vous traitez le stockage d'objets, éviter certains types de fonctions comme Pickle, XML, (dé)sérialisation en Java et PHP, et opter plutôt pour des options de stockage simples comme JSON peut éviter de nombreux exploits typiques liés à la désérialisation non sécurisée. Aikido surveille ce type de fonctions dans votre codebase par défaut.
• Si vous utilisez un CDN ou des mécanismes de mise en cache, utilisez des domaines distincts pour vos actifs statiques avec des configurations CDN séparées afin d'éviter toutes sortes d'attaques par empoisonnement de cache (ChatGPT est tombé dans ce piège récemment)

Formez vos développeurs avec cette astuce simple

Il existe une astuce simple (jeu de mots inclus) que vous pouvez mettre en œuvre dans vos processus. Une question rapide à poser à l'équipe de développement lors de la planification de sprint :

Comment la fonctionnalité que nous développons peut-elle être piratée ? (& comment pouvons-nous empêcher que cela se produise)

Bien que l'équipe de développement ne puisse pas anticiper tous les scénarios d'abus potentiels, cette méthodologie est extrêmement simple à mettre à l'échelle. C'est une petite étape supplémentaire qui encourage les développeurs à prendre en compte les considérations de sécurité avant d'entreprendre tout travail de développement.

Attribuer des priorités aux différentes parties de votre base de code

Tout ne sera pas une cible aussi importante pour les hackers. Les composants clés qu'ils aiment cibler sont :

• Systèmes de paiement, portefeuilles, systèmes de crédit
• Fonctionnalité qui se connecte à des API coûteuses comme les SMS, la VoIP (pensez à Twilio)
• Réinitialisation de mot de passe, systèmes de connexion, invitations d'utilisateurs
• Des fonctionnalités d'exportation (PDF, Excel, etc.) qui pourraient effectuer des opérations risquées.
• Tout ce qui concerne les téléchargements de fichiers, d'images
• Fonctionnalités qui effectuent des requêtes sortantes par conception, telles que les webhooks
• Toute fonctionnalité qui envoie des e-mails, surtout avec du contenu personnalisé

PS : Aikido peut vous aider à vous concentrer uniquement sur les principaux dépôts de l'univers de votre startup en attribuant des niveaux de risque à chaque codebase.

N'oubliez pas l'aspect humain

En tant que CTO dans une petite startup, vous êtes généralement aussi le responsable de la sécurité opérationnelle. Fournissez à votre équipe les moyens de sécuriser leurs comptes. Assurez-vous qu'ils utilisent des Yubikeys matérielles ou des applications logicielles pour la 2FA et, si possible, imposez-la. Des outils comme Gmail permettent de l'appliquer. C'est une excellente première ligne de défense contre les attaques de phishing.

Rester à jour avec les pratiques de sécurité est difficile

Apprendre les nouveaux types d'attaques logicielles est difficile. Il est déjà assez difficile de suivre les mises à jour des langages que vous utilisez (Python, Node, Go,..) ou le patching des OS ou les exploits populaires dans les packages open source. Les attaques spécifiques deviennent plus populaires avec le temps, il est donc rentable de suivre les tendances. Par exemple, après avoir constaté une augmentation des attaques de prise de contrôle de sous-domaines l'année dernière, Aikido a introduit un outil de surveillance de prise de contrôle de sous-domaines pour prévenir ce risque et automatiser la pratique de surveillance de ces enregistrements DNS.

Automatisez

Dans mes entreprises précédentes, nous essayions d'atteindre un niveau de sécurité supérieur en demandant à une personne dédiée à la sécurité de créer un calendrier avec des tâches de sécurité récurrentes. Effectuer une revue d'accès pour toutes les applications chaque trimestre. Effectuer un scan des secrets divulgués sur le code toutes les deux semaines, nettoyer les CVEs des packages open source chaque vendredi, effectuer un scan SAST de temps en temps, vérifier les enregistrements DNS pour les prises de contrôle de sous-domaines chaque mois,... Le résultat de ces tâches était difficile à trier et à rendre exploitable pour les développeurs. Pire encore, lorsque cette personne quittait l'entreprise, il était difficile pour quiconque de reprendre ces tâches car elles nécessitaient beaucoup de connaissances spécifiques.

C'est là que l'idée d'Aikido a commencé à germer. Nous avions besoin d'une solution pour automatiser tout ce qui précède, filtrer le bruit et présenter les tâches à vos développeurs dans Slack ou Jira.

Commencez à scanner votre code et votre cloud avec Aikido dès aujourd'hui. Inscrivez-vous ici et commencez à scanner gratuitement.