Enseignements tirés de l'expérience des entreprises SaaS
Dans une startup SaaS typique, l'équipe de développement est soumise à une forte pression pour fournir de nouvelles fonctionnalités. Vous avez généralement des concurrents qui peuvent être mieux financés, vous avez l'équipe de vente qui demande une dernière fonctionnalité pour conclure l'affaire, l'équipe d'assistance à la clientèle qui demande une correction de bug. Il peut être difficile de donner la priorité à la sécurité, à moins qu'une grande entreprise cliente ne l'exige ou que votre conseil d'administration ne l'impose d'en haut.
Dans la plupart des startups, vous ne disposez pas d'une gamme complète de profils techniques : vous n'avez peut-être pas encore de chef de produit à plein temps, ni de responsable de la sécurité à plein temps au sein de votre équipe de développement. Une équipe de développement sous pression sera obligée de prendre des raccourcis, même en matière de sécurité.
J'ai été le directeur technique de trois start-ups SaaS en phase de démarrage (Teamleader, Officient et Futureproofed). (Teamleader, Officient & Futureproofed) J'ai décrit ci-dessous les enseignements que j'ai tirés de ces expériences passées dans le domaine des SaaS.

Éviter de réinventer la roue
Un bon exemple : ne construisez pas un système de connexion avec des mots de passe. Certes, vous pouvez le construire en quelques jours, mais le coût de sa maintenance et de l'ajout de fonctions de protection avancées à l'avenir sera très élevé. Envisagez d'utiliser un login via Single-sign on tel que Gmail ou utilisez un service tel que Auth0.com. Non seulement vous bénéficierez d'une expérience de connexion plus fluide et plus riche en fonctionnalités, mais vous n'aurez pas non plus à vous préoccuper de toute une série d'aspects de sécurité liés à la connexion (forçage brutal, fuite d'informations d'identification de l'utilisateur dans des services tiers, prévention et détection des attaques par prise de contrôle du compte, validation des adresses de courrier électronique, journalisation...).
En fin de compte, si vous choisissez le bon fournisseur, vous ne réduisez pas seulement votre surface d'attaque, vous gagnez aussi du temps qui peut être consacré à des fonctions plus utiles.
Voici d'autres exemples qui pourraient vous faire gagner des semaines, voire des mois :
- Ne stockez pas de cartes de crédit, utilisez quelque chose comme Stripe, Mollie ou Chargebee.
- N'exécutez pas vous-même des logiciels complexes tels que MySQL, PostgreSQL ou ElasticSearch. Utilisez des services en nuage gérés tels que RDS.
- Ne créez pas vos propres systèmes de journalisation. Utilisez des systèmes tels que 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 construisez pas de serveurs websocket, utilisez des services gérés tels que Pusher.com
- Ne créez pas votre propre système de marquage des caractéristiques, utilisez un service tel que Launchdarkly.
- Ne créez pas votre propre intégration de calendrier, utilisez un outil comme cronofy.com
- Lorsque vous créez des intégrations en général, recherchez des API unifiées dans ce domaine, comme Apideck.
Investir du temps dans un dispositif de communication de crise
Veillez à mettre en place des outils tels qu'une application de chat pour parler à vos clients ou, mieux encore, une page d'état gérée ou un compte Twitter où vous pouvez communiquer les problèmes. En cas de problème, c'est une bonne pratique 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 cas de crise.
Ajouter des garde-fous globaux
Vous êtes probablement en train de passer en revue les Pull Requests de vos développeurs, super ! C'est une tâche considérable que de les examiner du point de vue de la maintenabilité, des performances et des fonctionnalités. Avez-vous le temps de les examiner également du point de vue de la sécurité ? Il est certain que vous serez en mesure de couvrir certains risques, mais il est agréable de pouvoir écarter certains risques en ajoutant des garde-fous et une configuration globale.
Parfois, vous avez de la chance et il existe des solutions globales pour des problèmes spécifiques.
- Si vous utilisez nodeJS et que vous n'aimez pas penser à la pollution des prototypes, vous devriez geler le prototype pour désactiver cette classe d'attaques à l'échelle de l'application. Aikido peut automatiquement construire une Pull Request qui fait cela pour vous.
- Si vous utilisez SQL et craignez les attaques par injection SQL (vous devriez), vous pouvez utiliser un WAF (comme AWS WAF) ou un RASP (comme Datadog's app security) pour une protection à l'échelle de l'application.
- Si vous découvrez un grand nombre d'attaques XSS, vous pouvez probablement en éliminer une grande partie en introduisant une politique CSP très stricte dans le navigateur.
- Si vous effectuez beaucoup de requêtes sortantes basées sur les données des clients, vous pourriez être vulnérable aux attaques SSRF. Bien qu'il soit difficile de bloquer complètement ces attaques, vous pouvez atténuer les dommages en vous assurant qu'elles ne peuvent pas conduire à quelque chose de pire (comme une attaque IMDSv1 sur les informations d'identification IAM dans AWS). Aikido surveille cela dans votre nuage AWS par défaut.
- Lorsqu'il s'agit de stockage d'objets, éviter des types de fonctions spécifiques comme Pickle, XML, (un)serialize en Java et PHP,... et à la place opter pour des options de stockage simples comme JSON peut éviter beaucoup d'exploits typiques liés à la non-sérialisation non sécurisée. Aikido surveille ces types de fonctions dans votre base de code 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 distinctes afin d'éviter toutes sortes d'attaques par empoisonnement du cache (ChatGPT est tombé dans ce piège récemment).
Sensibilisez vos développeurs à l'aide de cette simple astuce
Il existe un moyen simple (jeu de mots) de mettre en œuvre vos processus. Une question rapide à poser à l'équipe de développement pendant la planification du sprint :
Comment la fonctionnalité que nous construisons peut-elle être piratée (et comment l'empêcher) ?
Bien que l'équipe de développement ne puisse pas anticiper tous les scénarios d'abus potentiels, cette méthodologie est très simple à mettre en œuvre. Il s'agit d'une petite étape supplémentaire qui encourage les développeurs à vérifier 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 pirates. Les éléments 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 telles que SMS, voip (pensez à Twilio)
- Réinitialisation du mot de passe, systèmes de connexion, invitations d'utilisateurs
- Les fonctions d'exportation telles que PDF, Excel,... les exportations qui peuvent effectuer des opérations risquées.
- Tout ce qui concerne le téléchargement de fichiers et d'images
- Fonctionnalités qui effectuent des requêtes sortantes par conception, telles que les webhooks
- Toute fonction permettant d'envoyer des courriers électroniques, en particulier avec un contenu personnalisé
PS : Aikido peut vous aider à vous concentrer sur les meilleurs dépôts dans l'univers de votre startup en assignant des niveaux de risque à chaque base de code.
N'oubliez pas l'aspect humain
En tant que directeur technique d'une petite entreprise en démarrage, vous êtes généralement responsable de la sécurité opérationnelle. Donnez à votre équipe les moyens de sécuriser leurs comptes. Assurez-vous qu'ils utilisent des Yubikeys matériels ou des applications logicielles pour le 2FA et, si possible, imposez-le. Des outils comme Gmail permettent de le faire. C'est une excellente première ligne de défense contre les attaques de phishing.
Il est difficile de se tenir au courant des pratiques de sécurité
Il est difficile de s'informer sur les nouveaux types d'attaques contre les logiciels. Il est déjà assez difficile de suivre les mises à jour des langages que vous utilisez (Python, Node, Go,..) ou les correctifs des systèmes d'exploitation ou les exploits populaires dans les paquets open-source. Certaines attaques deviennent de plus en plus populaires au fil du temps et il est donc utile de suivre les tendances. Par exemple, après avoir remarqué une augmentation des attaques par 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 afin de prévenir ce risque et d'automatiser la pratique de la surveillance de ces enregistrements DNS.
Automatiser
Dans mes entreprises précédentes, nous essayions d'atteindre un niveau de sécurité supérieur en demandant à une personne chargée de la sécurité d'établir un calendrier avec des tâches de sécurité récurrentes. Effectuer un examen de l'accès à toutes les applications chaque trimestre. Effectuer une analyse des fuites de secrets sur le code toutes les deux semaines, nettoyer les CVE des paquets open source tous les vendredis, effectuer une analyse SAST de temps en temps, vérifier les enregistrements DNS pour les prises de contrôle de sous-domaines tous les mois,... Les résultats de ces tâches étaient difficiles à trier et à rendre exploitables 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 de nombreuses 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 nuage avec Aikido dès aujourd'hui. Inscrivez-vous ici et commencez à scanner gratuitement.