Sec Model désigne une approche de modélisation de la sécurité qui formalise les exigences, les menaces et les contrôles sous forme de modèles exploitables par les architectes comme par les développeurs. L’objectif est de disposer d’un référentiel structuré et partagé qui traduit les contraintes de sécurité en décisions d’ingénierie concrètes, dès la conception.
Frontières de confiance et surface d’attaque : les fondations d’un sec model
Un sec model repose d’abord sur la cartographie des frontières de confiance (trust boundaries). Ce sont les lignes logiques ou physiques où le niveau de confiance accordé aux données ou aux utilisateurs change. Un appel API qui traverse un réseau public, un fichier uploadé par un utilisateur, un microservice qui interroge une base partagée : chaque franchissement de frontière génère un risque à qualifier.
La surface d’attaque découle directement de cette cartographie. Plus un système expose de points d’entrée (endpoints HTTP, ports réseau, interfaces d’administration), plus la surface est large. Le travail de modélisation consiste à recenser ces points, puis à appliquer un principe de minimisation de la surface d’attaque : supprimer ce qui n’est pas nécessaire avant de sécuriser ce qui reste.
C’est sur cette base que les équipes décident où placer un pare-feu applicatif, où imposer une authentification renforcée, ou encore où segmenter un réseau interne. Sans cette étape, les choix de sécurité restent arbitraires.
Principes secure by design appliqués au développement logiciel
L’ENISA a publié en juillet 2026 un « Secure by Design and Default Playbook » structuré autour de 14 principes secure by design et 8 principes secure by default. Ce document se distingue par son vocabulaire d’ingénierie système, volontairement accessible aux architectes et aux développeurs, pas uniquement aux spécialistes cybersécurité.
Parmi les principes secure by design, trois s’intègrent directement dans un sec model :
- Le moindre privilège : chaque composant du système ne dispose que des droits strictement nécessaires à sa fonction. Un service de notification n’accède pas à la base de paiement.
- La défense en profondeur : la sécurité ne repose jamais sur un contrôle unique. Si le pare-feu est contourné, le chiffrement des données au repos limite l’impact.
- La transparence de posture : le système documente son état de sécurité de façon lisible, ce qui permet aux équipes de détecter un écart entre le modèle et la réalité en production.
Les principes secure by default, eux, concernent la configuration initiale. Un système livré avec le durcissement activé, les mises à jour automatisées et les fonctions non utilisées désactivées réduit le risque lié aux erreurs humaines de déploiement.
NIST SSDF et Cyber Resilience Act : le cadre réglementaire qui impose la modélisation
Le NIST SP 800-218 (Secure Software Development Framework, ou SSDF) formalise un ensemble de pratiques de développement sécurisé. Ce cadre est aujourd’hui explicitement relié à plusieurs réglementations récentes, dont le Cyber Resilience Act européen, via des mappings de pratiques. Concrètement, une organisation qui applique le SSDF peut démontrer sa conformité à plusieurs textes en même temps.
Pour les architectes, cela signifie que la modélisation de sécurité devient une obligation documentaire, pas seulement une bonne pratique. Le sec model sert alors de preuve : il montre quels risques ont été identifiés, quels contrôles ont été sélectionnés, et pourquoi certaines menaces ont été acceptées.
Le NIST 800-171 Rev.2 complète cette approche en insistant sur l’emploi de principes d’ingénierie sécurisée formalisés. L’idée est la même : documenter les choix architecturaux de sécurité dans un format auditable, et relier chaque décision à une exigence traçable.
Threat modeling intégré au cycle de développement
Le sec model prend sa forme opérationnelle lors du threat modeling (modélisation des menaces). Cette activité consiste à identifier les menaces plausibles pour un système donné, à évaluer leur impact et leur probabilité, puis à choisir des contre-mesures adaptées.
La méthode la plus répandue suit quatre étapes :
- Décomposer le système en composants et flux de données, en s’appuyant sur des diagrammes d’architecture existants.
- Identifier les menaces par composant, en utilisant une taxonomie (STRIDE reste le cadre le plus courant dans les équipes Microsoft, mais d’autres existent).
- Évaluer chaque menace en fonction du contexte métier : une fuite de données médicales n’a pas le même impact qu’une indisponibilité temporaire d’un service de notification.
- Documenter les décisions : quels contrôles sont mis en place, quels risques résiduels sont acceptés, et par qui.
L’apport du sec model ici est de fournir un vocabulaire partagé entre architectes et développeurs. Quand un architecte parle de « frontière de confiance », le développeur sait exactement où ajouter une validation d’entrée ou un contrôle d’accès dans le code. Sans ce langage commun, les exigences de sécurité restent des documents PDF que personne n’ouvre après la phase de conception.
Sec model et code applicatif : du diagramme à l’implémentation
Un sec model qui reste sur un tableau blanc ne protège rien. La valeur apparaît quand les décisions de modélisation se traduisent en règles concrètes dans le code et l’infrastructure.
Un contrôle de moindre privilège identifié dans le modèle devient une politique IAM (Identity and Access Management) avec des rôles granulaires. Une frontière de confiance se matérialise par une validation systématique des entrées côté serveur, pas uniquement côté client. Une exigence de chiffrement au repos se traduit par un choix d’algorithme et une gestion de clés documentée.
Le lien entre modèle et code gagne à être automatisé. Certaines approches de type Domain-Specific Language (DSL) permettent de générer des configurations de sécurité directement depuis le modèle architectural. La thèse ICS-Dev-Sec, par exemple, propose des métamodèles fonctionnels et de sécurité qui transforment automatiquement une architecture fonctionnelle en architecture sécurisée via des règles de transformation formelles.
Cette automatisation réduit l’écart entre la décision architecturale et son implémentation, un écart qui est historiquement la première source de vulnérabilités dans les systèmes complexes.
Le sec model ne supprime pas les arbitrages difficiles entre performance, coût et niveau de protection. Il rend ces arbitrages explicites, traçables et compréhensibles par toutes les parties prenantes d’un projet logiciel.
