La plupart des problèmes de sécurité commencent bien avant le premier `git init`. Ils sont intégrés aux décisions d'architecture, aux hypothèses négligées et aux exigences manquantes. La planification est le point de départ du développement sécurisé, non pas parce que c'est amusant, mais parce que c'est économique. Détecter un modèle d'authentification défaillant lors d'une session de brainstorming est plus rapide que de corriger une faille de production deux sprints plus tard. Cette section vous montre comment concevoir en tenant compte de la sécurité dès le départ. Vous apprendrez à réaliser une modélisation des menaces légère et efficace, à rédiger des user stories axées sur la sécurité et à classer les données comme un professionnel. Sans fioritures. Aucun doctorat requis.

Image d'illustration : Description de l'image : Flux de la phase de conception avec des icônes pour la modélisation des menaces, la classification des données et les modèles de user story sécurisées — superposé sur un tableau de planification de sprint.

Modélisation des menaces légère pour les équipes de développement – Pas de doctorat ni d'atelier de trois jours requis

Vous n'avez pas besoin de passer des jours à construire des arbres d'attaque ou à organiser un atelier de modélisation des menaces avec 14 parties prenantes. Il vous suffit de vous arrêter et de poser les bonnes questions au bon moment.

Qu'est-ce qui pourrait mal tourner ?

C'est la question qui compte. Que se passe-t-il si un token fuit ? Si quelqu'un manipule une entrée ? Si un utilisateur contourne un contrôle côté client ? Parcourez les flux de base de votre fonctionnalité et identifiez leurs failles. Vous ne concevez pas pour des utilisateurs idéaux, vous vous défendez contre les abus créatifs. Même 10 minutes de réflexion "et si" peuvent révéler des failles logiques, des validations manquantes ou des limites de confiance évidentes.

Gains rapides : STRIDE-per-Feature, Sessions sur tableau blanc

Vous n'avez pas besoin de modéliser l'intégralité de votre application. Contentez-vous de modéliser les menaces des nouveautés. Essayez la méthode STRIDE par fonctionnalité. Prenez cinq minutes et demandez-vous si la fonctionnalité introduit des risques d'usurpation d'identité, de falsification, de fuites d'informations, de problèmes de privilèges ou de déni de service. Ou prenez un tableau blanc et esquissez le flux de données. Qui communique avec quoi ? Où l'entrée utilisateur est-elle saisie ? Où devriez-vous mettre en place des contrôles ? Vous serez surpris de tout ce que vous détecterez simplement en ralentissant et en traçant des lignes.

Intégrer la sécurité dans les User Stories et les exigences

La sécurité ne peut pas se limiter aux documents d'architecture ou au backlog de l'équipe de sécurité. Elle doit faire partie intégrante du workflow de développement, en commençant par la manière dont vous rédigez les user stories.

"En tant qu'utilisateur, je veux que mes données soient..."

Les user stories sont un excellent moyen d'intégrer les attentes. Ne vous contentez pas d'écrire « En tant qu'utilisateur, je veux réinitialiser mon mot de passe. » Essayez plutôt « En tant qu'utilisateur, je veux que la réinitialisation de mon mot de passe soit sécurisée et protégée contre les attaques par force brute. » Cette seule phrase déclenche des discussions sur la limitation de débit, l'expiration des jetons et la journalisation, avant même que le code ne soit écrit. La sécurité doit faire partie de la définition de « done », et non une réflexion après coup ajoutée à l'assurance qualité.

Classification des données : Savoir ce qui nécessite une sécurité de type Fort Knox ou un simple cadenas

Toutes les données ne sont pas égales. Certains champs, comme les noms d'utilisateur, sont publics. D'autres, comme les numéros de sécurité sociale ou les jetons d'authentification, nécessitent un chiffrement, un contrôle d'accès et une journalisation stricte. Lors de la planification, demandez-vous : quelles données collectons-nous ? Où sont-elles stockées ? Quel est l'impact si elles fuient ? Étiquetez-les en conséquence. Cela vous aide à concevoir des protections adaptées au risque. Vous n'avez pas besoin d'une stratégie de gouvernance des données complète pour commencer, juste un peu d'étiquetage et de bon sens.

Le développement sécurisé ne vise pas à freiner l'innovation. Il s'agit de poser les bonnes questions dès le début, afin de ne pas avoir à résoudre les problèmes complexes plus tard. 

Passons à la phase de codage et parlons de la façon d'écrire une logique sécurisée sans transformer chaque pull request en incident de sécurité.