Proportionné, ou rien ne se passe
La plupart des programmes de Security by Design s’enlisent parce qu’ils appliquent la même revue lourde à tous les projets, et les métiers les contournent. La version qui fonctionne trie d’abord : un questionnaire court, en langage métier, établit la criticité (données, exposition, dépendances, périmètre réglementaire), et seuls les projets qui le justifient passent par la modélisation des menaces, une analyse de risque comme EBIOS Risk Manager et des jalons de revue formels. Les autres reçoivent une liste de contrôle qu’ils peuvent réellement remplir.
Ce que les réglementations attendent
NIS2 range le développement et l’acquisition sécurisés parmi les mesures de gestion des risques que la direction doit approuver ; le Cyber Resilience Act fait de la sécurité dès la conception et par défaut une exigence légale pour les produits comportant des éléments numériques, avec un traitement des vulnérabilités pendant la période de support du produit. Pour un industriel ou un éditeur, la pratique n’est plus une préférence interne mais la traduction d’une obligation de conformité.
Où cela atterrit dans une plateforme GRC
Un flux Security by Design produit exactement les objets dont un registre des risques a besoin : l’initiative, sa criticité, les événements redoutés, les exigences retenues et la preuve qu’elles ont été tenues. Gardés dans le même système que le registre et le référentiel de contrôles, le risque résiduel de chaque projet remonte dans l’image d’entreprise et ses exigences ouvertes deviennent des actions portées, au lieu de finir dans un support de revue que personne ne rouvre.