La sécurité dès la conception dans le développement de logiciels d’entreprise

La sécurité se perd rarement en une seule décision spectaculaire. Elle s’érode au fil de petits choix : un point d’accès d’administration sans contrôle d’autorisation, un jeton poussé par erreur dans un dépôt, une ligne de journal qui contient un numéro de carte complet, une dépendance que personne n’a mise à jour depuis deux ans. La sécurité dès la conception (security by design) consiste à faire du choix sûr le choix par défaut à chacun de ces moments, plutôt que d’espérer qu’un test d’intrusion final rattrapera tout ce qui a échappé à la vigilance.

Voici les pratiques que nous jugeons indispensables, et les référentiels reconnus qui les étayent.

Pourquoi la sécurité doit être pensée dès la conception

Un défaut ne coûte jamais aussi peu à corriger que lorsqu’il n’est encore qu’une idée. Un modèle d’autorisation erroné se corrige en une discussion au stade de la conception ; découverte en production, la même faille peut entraîner un incident, une investigation technique et une notification aux clients ou aux autorités. Plusieurs des catégories de vulnérabilités les plus graves, comme le contrôle d’accès défaillant, la conception non sécurisée ou la mauvaise configuration, toutes présentes dans l’OWASP Top 10, relèvent de l’architecture plutôt que du code. Aucun scanner ne les détecte de façon fiable.

Cette approche change aussi l’équation pour l’équipe. Lorsque les bonnes pratiques sont intégrées aux modèles de projet, aux bibliothèques et aux pipelines, nul besoin d’être spécialiste de la sécurité pour produire un logiciel sûr : il suffit d’une voie bien balisée, et de l’habitude de ne pas en sortir.

Modéliser les menaces avec STRIDE

La modélisation des menaces est une manière structurée de se demander ce qui peut mal tourner avant que cela n’arrive. Nul besoin d’outillage lourd : une séance au tableau blanc avec les bonnes personnes suffit souvent. Le cadre en quatre questions popularisé par Adam Shostack, et repris dans le Threat Modeling Manifesto, aide à garder le cap : sur quoi travaillons-nous, que peut-il mal se passer, qu’allons-nous faire, et avons-nous fait du bon travail ?

Commencez par un diagramme de flux de données faisant apparaître processus, stockages, entités externes et frontières de confiance, c’est-à-dire les points où les données changent de niveau de confiance, par exemple entre une application mobile et une API. Appliquez ensuite STRIDE à chaque élément :

Menace	Propriété en jeu	Question à se poser
Usurpation d’identité (Spoofing)	Authentification	Un appelant peut-il se faire passer pour un autre utilisateur ou service ?
Falsification (Tampering)	Intégrité	Des données peuvent-elles être modifiées sans que cela soit détecté ?
Répudiation (Repudiation)	Non-répudiation	Quelqu’un peut-il nier une action faute de trace fiable ?
Divulgation d’informations (Information disclosure)	Confidentialité	Des données peuvent-elles fuiter par les réponses, les erreurs, les journaux ou les sauvegardes ?
Déni de service (Denial of service)	Disponibilité	Un client peut-il épuiser les ressources ou bloquer les autres ?
Élévation de privilèges (Elevation of privilege)	Autorisation	Un utilisateur peut-il obtenir des droits qui ne lui ont jamais été accordés ?

Consignez chaque menace, sa parade et son responsable dans le backlog, aux côtés du travail fonctionnel. Revoyez le modèle à chaque évolution de l’architecture, et pas seulement au démarrage du projet.

Intégrer la sécurité à chaque étape du cycle de vie

Un cycle de développement sécurisé répartit les activités de sécurité sur chaque phase au lieu de les reléguer à la fin. Le Secure Software Development Framework du NIST (SP 800-218) et OWASP SAMM offrent des cadres utiles. En pratique, l’essentiel tient en quelques points :

• Exigences. Définissez les exigences de sécurité à partir de l’OWASP Application Security Verification Standard (ASVS). Ses trois niveaux de vérification permettent de fixer un seuil adapté, les plus élevés convenant aux systèmes qui traitent des paiements, des données d’identité ou de santé.
• Conception. Modélisez les menaces de chaque nouvelle fonctionnalité ou évolution significative, et examinez explicitement l’authentification, l’autorisation et les flux de données.
• Implémentation. Utilisez des frameworks éprouvés pour l’authentification, la cryptographie et l’encodage des sorties plutôt que du code maison. Employez des requêtes paramétrées, validez les entrées selon des schémas stricts et encodez les sorties selon leur contexte.
• Vérification. Lancez analyse statique, analyse des dépendances et détection de secrets sur chaque pull request, tests dynamiques en préproduction et revue manuelle ciblée pour les changements sensibles. Commandez un test d’intrusion indépendant avant chaque version majeure.
• Exploitation. Durcissez les configurations, surveillez en continu et réinjectez les enseignements des incidents dans les exigences.

L’OWASP Top 10 est un outil de sensibilisation pour la formation et la revue de code, pas un cahier des charges complet. Comme le recommande l’OWASP lui-même, l’ASVS est une base plus appropriée pour définir et vérifier les contrôles.

Moindre privilège et gestion des secrets

Le moindre privilège, partout

Chaque identité, humaine, applicative ou d’automatisation, ne doit détenir que les droits dont elle a besoin, et seulement le temps nécessaire.

• Modélisez l’autorisation explicitement, avec des rôles ou attributs définis en un seul endroit et vérifiés à chaque requête au niveau de chaque objet, pas seulement des routes.
• Séparez les fonctions d’administration des fonctions client, et exigez une authentification multifacteur résistante à l’hameçonnage pour les accès privilégiés.
• Donnez à chaque service sa propre identité et des identifiants de base de données restreints. Un service de reporting n’a aucune raison d’écrire dans le schéma des paiements.
• Préférez l’élévation de droits ponctuelle et limitée dans le temps aux droits d’administrateur permanents, et revoyez les accès régulièrement.
• Restreignez strictement les identifiants de la chaîne CI/CD : un pipeline capable de déployer en production est une cible de choix.

Les secrets n’ont rien à faire dans le code

Clés d’API, mots de passe, clés de signature et certificats doivent résider dans un gestionnaire de secrets ou un service de gestion de clés, jamais dans le code source, les images de conteneurs ou des fichiers de configuration en clair.

• Injectez les secrets à l’exécution et accordez les accès par identité de charge de travail.
• Préférez des identifiants éphémères émis automatiquement (fédération d’identité de charge de travail, identifiants de base de données dynamiques) aux clés statiques de longue durée.
• Renouvelez les secrets selon un calendrier défini et dès qu’une exposition est suspectée, et faites en sorte que les applications les rechargent sans redéploiement.
• Activez la détection de secrets dans les dépôts et les pipelines, et considérez tout secret poussé dans un dépôt comme compromis, même après suppression du commit.

Hygiène de la chaîne d’approvisionnement logicielle

Les applications modernes sont en grande partie assemblées à partir de code tiers. Chaque dépendance, outil de build et image de base fait partie de votre surface d’attaque.

• Sachez ce que vous livrez. Produisez pour chaque build une nomenclature logicielle (SBOM) au format CycloneDX ou SPDX, afin de savoir en quelques minutes si une vulnérabilité nouvellement publiée vous concerne.
• Figez et vérifiez. Versionnez les fichiers de verrouillage, figez les versions et contrôlez les empreintes d’intégrité. Référencez actions de CI et images de base par empreinte immuable plutôt que par étiquette modifiable.
• Mettez à jour en continu. Surveillez les vulnérabilités connues et automatisez les mises à jour. De petites mises à jour fréquentes sont bien moins risquées que des mises à niveau rares et massives.
• Choisissez avec discernement. Avant d’adopter un paquet, examinez sa maintenance et ses responsables ; le projet OpenSSF Scorecard automatise une grande partie de ces vérifications. Méfiez-vous du typosquatting et de la confusion entre paquets internes et publics.
• Protégez la chaîne de build. Exécutez les builds dans des environnements isolés et éphémères, signez les artefacts (Sigstore rend la démarche accessible) et prenez le cadre SLSA comme feuille de route vers une provenance vérifiable.

Protéger les données en transit, au repos et dans les journaux

Le chiffrement

• Chiffrez tout le trafic avec TLS 1.2 ou plus, de préférence TLS 1.3, y compris entre services internes, et activez HSTS sur les applications web publiques.
• Chiffrez les données au repos au niveau du stockage, et ajoutez un chiffrement applicatif ou par champ pour les valeurs les plus sensibles, par chiffrement d’enveloppe avec des clés détenues par un service de gestion de clés.
• Hachez les mots de passe avec un algorithme coûteux en mémoire comme Argon2id, ainsi que le recommande l’OWASP Password Storage Cheat Sheet, et jamais avec un chiffrement réversible.
• N’implémentez jamais vous-même de primitives cryptographiques : utilisez des bibliothèques bien maintenues, via leurs interfaces de haut niveau.

Journaliser sans divulguer

Indispensables à la détection et à l’investigation, les journaux sont aussi une source fréquente de fuites, car ils sont copiés dans de nombreux outils et conservés longtemps.

• Utilisez des journaux structurés aux champs explicites, et tenez une liste de ce qui peut être journalisé plutôt que de ce qui est interdit.
• Ne journalisez jamais mots de passe, jetons, identifiants de session, numéros de carte complets ou secrets. Masquez ou remplacez par des jetons les données personnelles comme les numéros de téléphone ou de pièce d’identité.
• Centralisez le masquage dans la bibliothèque ou le pipeline de journalisation, pour ne pas dépendre de la mémoire de chaque développeur.
• Journalisez en revanche les événements de sécurité (tentatives d’authentification, changements de droits, actions d’administration, accès aux données sensibles) en précisant qui, quoi, quand et d’où, au service de la détection comme de la non-répudiation.
• Restreignez l’accès aux journaux, protégez leur intégrité et fixez des durées de conservation conformes aux obligations légales, sans excès.

Exemple de masquage centralisé avec la bibliothèque Pino pour Node.js :

import pino from "pino";

export const logger = pino({
  redact: {
    paths: [
      "req.headers.authorization",
      "req.headers.cookie",
      "*.password",
      "*.token",
      "payment.cardNumber",
    ],
    censor: "[REDACTED]",
  },
});

Se préparer aux incidents

Aucun dispositif n’est parfait : préparez-vous au jour où un contrôle cédera. La publication NIST SP 800-61 est une référence largement utilisée pour la gestion des incidents.

• Détecter. Centralisez les journaux, définissez des alertes sur des signaux pertinents (authentifications inhabituelles, changements de droits, pics d’échecs d’autorisation, trafic sortant inattendu) et désignez clairement qui doit y répondre.
• Préparer. Rédigez un plan de réponse avec des rôles clairs, des circuits d’escalade et des modèles de communication, en précisant qui décide de notifier clients et autorités, et dans quels délais.
• S’entraîner. Organisez des exercices sur table autour de scénarios réalistes, comme la fuite d’un identifiant. Un plan jamais répété fonctionne rarement comme prévu.
• Rétablir. Conservez des sauvegardes chiffrées, restaurées régulièrement lors de tests et isolées des identifiants de production, hors de portée d’un rançongiciel ou d’un compte administrateur compromis.
• Apprendre. Menez des retours d’expérience sans recherche de coupable et traduisez-les en éléments de backlog, en modèles de menaces actualisés et en nouveaux contrôles automatisés.

Un socle pour chaque projet

La sécurité dès la conception ne requiert pas un grand département sécurité, mais un socle appliqué avec constance. Pour chaque nouveau système d’entreprise, nous recommandons de vérifier que :

1. Un modèle de menaces existe, est relié au backlog et suit chaque évolution de l’architecture.
2. Les exigences de sécurité découlent d’un niveau OWASP ASVS adapté.
3. L’autorisation est vérifiée au niveau des objets à chaque requête et couverte par des tests automatisés.
4. Les secrets résident dans un gestionnaire dédié, sont renouvelés et recherchés à chaque commit.
5. Chaque build produit une SBOM, et les dépendances sont figées, analysées et mises à jour régulièrement.
6. Les données sont chiffrées en transit et au repos, et les journaux structurés et masqués par défaut.
7. Les accès privilégiés exigent une authentification multifacteur et une élévation limitée dans le temps.
8. Un plan de réponse aux incidents existe et a été éprouvé lors d’exercices.

Aucune de ces pratiques n’est nouvelle, et c’est tout l’intérêt. La sécurité dès la conception tient moins à des défenses ingénieuses qu’à une ingénierie rigoureuse et reproductible : celle qui permet à une organisation d’adopter de nouvelles technologies avec confiance plutôt qu’avec appréhension.