- Description
- Porte de chambre forte d'une banque, avec ses gros verrous cylindriques et ses volants de manœuvre.
- Source
- auteur non indiqué (architectes York and Sawyer) · page d’origine
- Licence
- PD Domaine public
Sécurité
Ce thème mesure la résistance du logiciel et de sa chaîne de fabrication aux erreurs et aux attaques, du point de vue du développeur : secrets, dépendances, vulnérabilités du code, menaces…
En bref
Ce thème mesure la résistance du logiciel et de sa chaîne de fabrication aux erreurs et aux attaques, du point de vue du développeur : secrets, dépendances, vulnérabilités du code, menaces anticipées dès la conception, composition connue du livrable (SBOM), provenance des artefacts. La sécurité des données (RGPD, confidentialité) relève de la matrice data : 08 — sécurité, confidentialité, conformité.
Niveau : 🟢→🔴 · Code thème : SEC (matrice DL)
Pourquoi ce thème#
Les incidents de sécurité les plus coûteux viennent rarement d'attaques sophistiquées : un secret commité dans l'historique, une dépendance vulnérable jamais mise à jour, un compte de service sur-privilégié, une injection SQL dans une procédure construite par concaténation. La chaîne d'approvisionnement logicielle est devenue une cible à part entière : compromettre un composant en amont atteint tous ses consommateurs. Le coût de l'ignorance est mesuré en délai de réaction : combien d'heures pour savoir si nous sommes exposés à une nouvelle vulnérabilité publique ?
Pour du SQL et des scripts d'administration : requêtes dynamiques paramétrées, principe du moindre privilège pour les comptes de traitement, secrets absents des scripts, chaînes de connexion hors du dépôt. Ces règles sont prosaïques et très rentables.
Ce que mesure le thème#
- Axe : de « on corrige quand ça arrive » à « on anticipe, on détecte et on prouve la provenance ».
- Indicateurs clés : délai de réponse à une vulnérabilité publique (de la publication à la réponse « sommes-nous exposés ? ») ; âge des vulnérabilités ouvertes ; part des composants couverts par un inventaire (SBOM) ; secrets détectés dans l'historique.
- Unité : heures/jours ; % ; nombre.
Tableau des cinq niveaux#
| Niveau | Nom court | Promesse | Indicateur type (ordre de grandeur) |
|---|---|---|---|
| 1 | Confiante | On ne sait pas si l'on est exposé. | Aucun inventaire ; secrets dans les scripts |
| 2 | Hygiénique | Les erreurs les plus évitables (secrets, mots de passe par défaut, droits excessifs) ne sont plus là. | Secrets hors dépôt ; revue des droits annuelle |
| 3 | Détectée | Une vulnérabilité connue dans le code ou une dépendance est signalée avant la livraison. | Analyse de dépendances et de code en CI ; correctif critique < 15 j |
| 4 | Anticipée | Les menaces sont réfléchies avant le code ; on sait en moins d'un jour si une faille publique nous concerne. | Modélisation des menaces ; SBOM ; réponse < 24 h |
| 5 | Prouvée | Chaque artefact livré a une provenance vérifiable, et un compromis d'un composant est contenu. | Provenance signée ; moindre privilège généralisé ; exercices d'attaque réguliers |
Jalons par niveau#
| ID | Jalon | Preuve vérifiable |
|---|---|---|
| DL-SEC-1.1 | Un responsable de la sécurité applicative est identifié | Nom dans l'organigramme |
| DL-SEC-1.2 | Les comptes d'accès aux dépôts et aux serveurs de build sont nominatifs | Revue des comptes |
| DL-SEC-1.3 | Les mots de passe par défaut sont changés ; les postes et serveurs de build sont à jour | Contrôle ponctuel |
| DL-SEC-2.1 | Aucun secret n'est en clair dans le dépôt actuel (chaînes de connexion, clés) | Recherche automatisée vide |
| DL-SEC-2.2 | Un coffre de secrets (ou équivalent maîtrisé) est utilisé | Secrets lus à l'exécution |
| DL-SEC-2.3 | Les accès sont revus au moins annuellement (principe du moindre privilège) | Compte rendu de revue |
| DL-SEC-2.4 | Les requêtes dynamiques sont paramétrées (pas de concaténation de saisies) | Revue d'échantillon de procédures |
| DL-SEC-3.1 | Une analyse des dépendances s'exécute en CI et bloque sur les critiques | Un composant vulnérable volontaire est refusé |
| DL-SEC-3.2 | Une analyse statique orientée sécurité s'exécute sur chaque changement | Rapport joint |
| DL-SEC-3.3 | Les secrets déjà commités sont détectés dans l'historique et révoqués | Rapport d'audit d'historique ; secrets renouvelés |
| DL-SEC-3.4 | Les correctifs critiques sont appliqués en < 15 jours (haute : 30 jours) | Mesure des délais |
| DL-SEC-3.5 | Les journaux d'authentification et d'administration sont conservés | Journaux consultables |
| DL-SEC-4.1 | Une modélisation des menaces (ex. STRIDE) précède les évolutions structurantes | Document daté par chantier majeur |
| DL-SEC-4.2 | Un inventaire des composants (SBOM, format CycloneDX ou SPDX) est généré à chaque livraison | SBOM attaché à l'artefact |
| DL-SEC-4.3 | La réponse « sommes-nous exposés ? » à une vulnérabilité publique prend < 24 h | Exercice chronométré |
| DL-SEC-4.4 | Les exigences de sécurité sont tirées d'un référentiel (type ASVS) et testées | Matrice exigences → tests |
| DL-SEC-4.5 | Les comptes de traitement ont des droits minimaux, par fonction | Revue des droits des comptes de service |
| DL-SEC-5.1 | La provenance des artefacts est attestée et vérifiée avant déploiement (signature, niveau SLSA visé) | Vérification en pipeline |
| DL-SEC-5.2 | La construction est isolée et reproductible, les dépendances sont épinglées et vérifiées par empreinte | Revue de la chaîne |
| DL-SEC-5.3 | Des exercices d'attaque (test d'intrusion, équipe rouge) ont lieu au moins annuellement, avec suivi des constats | Rapports et clôtures |
| DL-SEC-5.4 | Une compromission d'un composant est contenue (segmentation, rotation automatique de secrets) | Exercice de rotation complète < 1 jour |
Lecture détaillée par niveau#
🟢 Niveau 1 — Confiante#
- Signes : « personne n'en veut à nos données » ; chaînes de connexion dans les scripts ; compte administrateur partagé.
- Gain : zéro friction.
- Ne garantit pas : rien, justement. C'est un niveau d'exposition non mesurée.
- Difficulté : 1/5 · Effort : 1/5.
🟢 Niveau 2 — Hygiénique#
- Signes : secrets sortis du code, comptes nominatifs, revue des droits, paramétrage des requêtes dynamiques.
- Gain : élimination de la majorité des incidents évitables.
- Ne garantit pas : la détection de nouvelles failles ; elle est statique.
- Difficulté : 2/5 · Effort : 2/5.
🟡 Niveau 3 — Détectée#
- Signes : la CI signale composants vulnérables, secrets et motifs dangereux. Un secret déjà commité est considéré comme compromis même après suppression : l'historique le contient encore ; il faut le révoquer.
- Gain : le risque connu est traité avant la livraison.
- Ne garantit pas : l'absence de faille inconnue, ni de menaces de conception.
- Difficulté : 3/5 · Effort : 3/5.
🔴 Niveau 4 — Anticipée#
- Signes : on pense aux menaces avant de coder (qui attaque, par où, quel impact ; catégories STRIDE : usurpation, altération, répudiation, divulgation, déni de service, élévation de privilèges). Un SBOM permet de répondre en heures à une alerte publique sur une bibliothèque.
- Gain : réaction rapide et décisions éclairées.
- Ne garantit pas : la prévention des attaques sur la chaîne de fabrication elle-même.
- Difficulté : 4/5 · Effort : 4/5.
🔴 Niveau 5 — Prouvée#
- Signes : chaque artefact est signé avec attestation de provenance ; les dépendances sont épinglées par empreinte ; la rotation des secrets est automatisable ; des attaques simulées éprouvent la défense.
- Gain : confiance vérifiable et blast radius limité.
- Ne garantit pas : l'invulnérabilité — c'est une réduction de risque, pas une preuve d'absence de faille.
- Difficulté : 5/5 · Effort : 5/5.
Atteinte partielle et notation#
Appliquez la règle de notation.
- 0,5 sur DL-SEC-3.1 : l'analyse de dépendances tourne, sans bloquer.
- 0,5 sur DL-SEC-4.2 : SBOM produit pour l'application, pas pour les scripts SQL/PowerShell embarqués dans le kit.
- Un 5 partiel : signature des artefacts en place, vérification au déploiement pas encore obligatoire.
Secret « supprimé ». Symptôme : le fichier ne contient plus la clé. Cause : l'historique la garde. Remède : révoquer et renouveler, nettoyer ensuite l'historique si nécessaire.
Alertes sans responsable. Symptôme : 300 vulnérabilités ouvertes depuis un an. Cause : pas de seuil, pas de propriétaire. Remède : bloquer sur critiques exploitables, traiter par échéance, gérer les faux positifs de façon traçable.
Mesurez le délai de réponse (« sommes-nous exposés ? »), pas le nombre de vulnérabilités : un grand parc avec inventaire à jour répond en une heure ; un petit sans inventaire, en une semaine.
Passer au niveau suivant#
Moyens possibles (facultatifs)
- 1 → 2 : chasse aux secrets, coffre, comptes nominatifs, revue de droits.
- 2 → 3 : analyse de dépendances et statique en CI, détection d'historique, délais de correctifs convenus.
- 3 → 4 : ateliers de modélisation des menaces (1 h par chantier), SBOM automatique, référentiel d'exigences.
- 4 → 5 : signature et attestation, verrouillage par empreinte, exercices d'attaque.
Une bibliothèque de lecture de fichiers est annoncée vulnérable un vendredi. Niveau 1 : on ne sait pas si on l'utilise. Niveau 4 : une requête sur les SBOM des trois dernières versions répond en 20 minutes ; correctif reporté sur les versions supportées dans la journée (04).
Aide à la revue sécurité et à la modélisation de menaces : gain 3/5, risque 4/5 (faux sentiment de sécurité, fuite de code ou de secrets vers un service externe). Garde-fou : jamais de secret ni de données client dans un prompt, usage de services contractuellement maîtrisés.
« Zéro vulnérabilité affichée » se réalise en réglant l'outil pour ne rien voir. Mesurez le délai de réponse et la couverture d'inventaire.
Voir aussi#
- Voisins : 05 CI · 06 Déploiement · 08 Observabilité · 02 Qualité du code.
- Autres matrices : Data — sécurité, confidentialité, conformité · BI — sécurité RLS et accès · Projet — gestion des risques.
- Pratique : CI/CD · Git en profondeur · pièges et bonnes pratiques · IA et outils.
- Glossaire · Notation.
✻ Rédigé par Claude Sonnet 5.5
