Risk Appetite DevSecOps

Définition

Le Risk Appetite DevSecOps désigne le niveau de risque de sécurité qu'une organisation est prête à accepter dans ses processus de développement et de déploiement logiciel pour atteindre ses objectifs business. C'est un paramètre fondamental de gouvernance qui traduit la tolérance au risque de l'organisation en politiques concrètes : quels types de vulnérabilités bloquent les déploiements, quelles exceptions sont acceptables, quelles compensations sont requises. Le Risk Appetite est distinct de la Risk Tolerance (la variation acceptable autour de l'appétit), et de la Risk Capacity (le niveau maximum de risque que l'organisation peut supporter). En pratique DevSecOps, l'appétit au risque se traduit par des décisions concrètes : bloquer tous les déploiements contenant des CVEs Critical ? Accepter des High sous conditions ? Permettre des exceptions documentées pour les Low/Medium ? La définition du Risk Appetite DevSecOps implique plusieurs parties prenantes. Le CISO/RSSI définit le cadre global de risque acceptable aligné sur la politique de sécurité de l'organisation. Le DSI traduit cet appétit en exigences techniques pour les pipelines CI/CD. Les équipes produit et engineering formulent leurs besoins en termes de vélocité de déploiement. La conformité réglementaire (RGPD, NIS2, secteur financier ou santé) impose des contraintes non négociables. Ce dialogue itératif produit des politiques de Risk Appetite opérationnellement viables. Les dimensions du Risk Appetite DevSecOps incluent : la tolérance aux vulnérabilités (sévérité maximale acceptable en production selon les systèmes), la tolérance aux dettes de sécurité (délai maximum acceptable pour la remédiation par criticité), la tolérance aux exceptions (processus et critères d'acceptation des dérogations), la tolérance au Security Debt (niveau de dette acceptable avant déclenchement d'un sprint de remédiation), et la tolérance aux changements non validés (fenêtres de changement, revues obligatoires selon l'impact). Le Risk Appetite doit être documenté, communiqué, et réévalué périodiquement (annuellement au minimum, ou lors de changements significatifs du contexte : nouveau règlement, incident majeur, acquisition, changement de business model).