Maîtriser la couverture de sécurité et les risques liés aux applications
Écrit par
0 minutes de lecture
Les applications modernes sont des écosystèmes complexes, assemblés à partir de code propriétaire et d’innombrables packages open source. Elles sont livrées sous forme d’images de conteneurs, fournissent et utilisent des API, et sont configurées et déployées à l’aide de modèles d’infrastructure as code. Avec l’influence croissante de l’IA, ce processus devient encore plus complexe et s’accélère. Les organisations sont confrontées à un défi de taille, souvent sous-estimé : la menace omniprésente des « inconnues inconnues » dans leurs portefeuilles applicatifs.
Si cette structure favorise l’innovation et la rapidité, elle transforme aussi fondamentalement les enjeux de sécurité. Comment conserver une visibilité et une maîtrise réelles lorsque les composants de vos applications sont aussi nombreux, dynamiques et interconnectés ? Pour de nombreuses équipes de sécurité, la réponse honnête est qu’il existe d’importantes lacunes.
Cette connaissance incomplète crée des « angles morts » dangereux tout au long du cycle de développement logiciel et parmi les différentes technologies utilisées. S’appuyer uniquement sur les mesures de sécurité traditionnelles, souvent axées sur le traitement des vulnérabilités connues à certaines étapes du cycle de développement, ne suffit de plus en plus. Ces « inconnues inconnues » — par exemple un dépôt non géré contenant des données sensibles ou une image de base vulnérable — représentent des risques non maîtrisés. Pour gérer efficacement la sécurité des applications aujourd’hui, vous devez pouvoir voir, comprendre et sécuriser l’ensemble de votre environnement.
Les angles morts : où se cachent les vulnérabilités inconnues ?
Que sont exactement les « angles morts » en matière de sécurité ? Ce sont les zones de l’écosystème logiciel d’une organisation où le manque de visibilité favorise l’apparition de vulnérabilités non détectées. Ces angles morts peuvent prendre différentes formes.
Applications héritées : systèmes toujours en service, mais qui ne sont plus activement mis à jour ni surveillés. On peut les croire stables, alors qu’ils peuvent dissimuler d’anciennes failles non corrigées ou des bibliothèques qui ne sont plus prises en charge.
Shadow IT : projets ou outils développés sans respecter les procédures de sécurité établies, et pouvant faire appel à des fournisseurs ou à des environnements cloud non approuvés. Ces initiatives ne font généralement pas l’objet d’une surveillance suffisante.
Actifs oubliés : des dépôts de code rarement mis à jour ou des images de conteneurs négligées peuvent encore offrir des vecteurs d’attaque.
En réalité, vous ne pouvez pas sécuriser ce que vous ne voyez pas. Ces actifs inconnus et non gérés deviennent des cibles de choix et permettent aux « inconnues inconnues » de représenter un risque important et non maîtrisé pour l’entreprise.
Les trois piliers d’une couverture complète :
Pour dépasser les mesures réactives et traiter efficacement ces menaces cachées, les organisations doivent développer des capacités fondamentales qui assurent une couverture complète de la sécurité applicative.
1. Obtenir une visibilité globale
Vous ne pouvez pas vous protéger contre ce dont vous ignorez l’existence. La première étape consiste à connaître vos actifs : cartographier et suivre en continu l’ensemble de votre écosystème logiciel. Autrement dit, répertorier tous les actifs applicatifs, notamment les dépôts de code, les fichiers manifestes de packages, les images de conteneurs, les configurations cloud, les API, les instances d’applications en cours d’exécution, et bien plus encore.
Cet inventaire doit répertorier les détails et le contexte de chaque actif, comme son propriétaire, les technologies sous-jacentes et, surtout, son contexte métier et son niveau de criticité. Pour gérer efficacement les risques, il est essentiel de comprendre quelles applications sont critiques ou traitent des données sensibles.
Voyons un exemple :
On constate que, sur les 832 actifs de l’organisation (qui peuvent être des dépôts ou des applications), seuls 376, soit 45 %, sont conformes. Cela signifie que 55 % de mes actifs ne sont pas réellement analysés par les contrôles SAST (tests statiques de sécurité des applications) ou SCA (analyse de la composition logicielle). On observe des chiffres similaires pour l’analyse des secrets et des conteneurs.
Ce niveau de détail est nécessaire pour que les équipes de sécurité comprennent l’étendue de leur couverture. Il est également important de reconnaître que tous les actifs n’ont pas besoin des mêmes contrôles de sécurité. Il est donc essentiel de mettre en place des politiques précises, adaptées aux besoins spécifiques des processus de travail de votre entreprise.
2. Définir des politiques de sécurité intelligentes
Une fois que vous disposez d’une vue claire, vous pouvez dépasser les contrôles de sécurité génériques et uniformes, et définir des politiques adaptées à votre appétence au risque et aux besoins de votre entreprise. Ces politiques doivent garantir la couverture de sécurité en définissant clairement les contrôles requis selon la criticité métier ou le type des différents actifs.
Par exemple, une politique peut imposer des analyses et une surveillance plus strictes pour les actifs de « classe A », critiques pour l’activité, que pour les actifs de « classe D », moins critiques, qui peuvent être utilisés uniquement à des fins de test et ne pas être déployés en production.
Ces politiques jouent également un rôle essentiel dans la détection des lacunes de couverture de sécurité. Elles mettent en évidence les actifs qui ne sont pas encore protégés par les contrôles adaptés et garantissent que les applications critiques bénéficient du niveau d’attention et d’examen approprié.
Prenons cet exemple : nous définissons une politique qui repère d’abord les applications (actifs) critiques en recherchant des tags spécifiques, comme PCI, qui indique que des données client sensibles sont traitées.
On voit que la politique classe ensuite ces actifs dans la catégorie « classe A », ou « critiques », afin qu’ils soient traités et priorisés différemment lors de la résolution des problèmes de sécurité, par rapport aux actifs moins critiques.
À partir des classifications d’actifs définies dans la politique précédente, nous sélectionnons les actifs de « classe A », ou critiques — qui peuvent être des dépôts ou des images de conteneurs — et définissons des contrôles de couverture applicables.
Cela nous permet d’appliquer différentes règles, par exemple en exigeant des analyses SAST quotidiennes pour les dépôts critiques, et en définissant une fréquence d’analyse SCA de 48 heures. Ce niveau de personnalisation nous permet de concentrer nos efforts sur les actifs les plus critiques grâce à des politiques ciblées et d’élaborer une stratégie de couverture de sécurité parfaitement adaptée à notre activité.
3. Hiérarchiser les risques en tenant compte du contexte
Identifier chaque vulnérabilité potentielle peut vite entraîner un backlog ingérable et frustrer les développeurs. Pour réduire efficacement les risques, il est essentiel de prioriser les efforts de correction en fonction des risques réels pour l’entreprise. Pour cela, nous pouvons tenir compte du contexte : quelle est la criticité de l’application concernée ? Est-elle exposée à Internet ? Le code vulnérable est-il réellement accessible, ou est-il chargé à l’exécution ?
Connaître les réponses à ces questions aide les équipes de sécurité à faire le tri et à aligner les efforts de correction sur les risques les plus importants pour l’entreprise. Découvrez dans cet exemple tout ce que le contexte peut apporter.
Prenons cet exemple : nous avions au départ un backlog ouvert de quelque 41 000 vulnérabilités, difficile à gérer. En appliquant des facteurs de risque clés — par exemple, si l’application était « déployée », « exposée au public » ou comportait des « packages chargés » —, nous avons pu ramener ce nombre à une liste plus facile à gérer de 53 vulnérabilités présentant les risques les plus élevés. Cette liste affinée peut ensuite être filtrée davantage à l’aide des classifications d’actifs évoquées plus haut (par exemple, les applications de « classe A » ou « critiques »), ainsi qu’en tenant compte des scores CVSS et d’autres facteurs internes et externes pertinents. Cette approche ciblée permet aux équipes de sécurité de traiter en priorité les risques les plus critiques.
Vers une gestion proactive des risques
La mise en œuvre des piliers que sont la visibilité, les politiques intelligentes et la priorisation tenant compte du contexte peut aider les organisations à faire évoluer leur approche de la posture de sécurité applicative. Au lieu de réagir constamment aux vulnérabilités nouvellement découvertes, les équipes peuvent adopter une démarche proactive et gérer les risques globaux pour l’entreprise avant que les problèmes ne s’aggravent. De plus, lorsque les équipes de développement et de sécurité s’appuient sur une vision claire et commune du paysage applicatif, comprennent les risques selon un contexte métier partagé et disposent de politiques automatisées pour guider la protection, leur collaboration s’améliore naturellement. Elles suivent alors une démarche claire et commune pour corriger efficacement les problèmes, en concentrant leurs efforts sur les risques qui menacent le plus l’entreprise.
Pour lutter véritablement contre les « inconnues inconnues » et éliminer les angles morts en matière de sécurité, un changement de cap s’impose. Il est essentiel de développer des capacités fondamentales : obtenir une visibilité globale sur tous les actifs logiciels, mettre en œuvre des politiques de sécurité intelligentes fondées sur les risques et hiérarchiser les priorités en tenant compte du contexte. Cette approche globale et proactive permet de gérer efficacement la complexité des applications modernes et de réduire considérablement les risques de sécurité dans l’environnement exigeant d’aujourd’hui. Cette transition vers une gestion proactive des risques apporte des avantages concrets à l’entreprise, notamment :
Moins de perturbations pour l’entreprise et une exposition réduite aux risques
Des investissements en sécurité optimisés et une meilleure rentabilité
Une conformité et une posture réglementaire renforcées
Une meilleure collaboration et une culture de la sécurité renforcée
Une résilience accrue de l’entreprise et un avantage concurrentiel renforcé
Une innovation accélérée et une mise sur le marché plus rapide
Votre approche actuelle de la sécurité vous permet-elle réellement de déceler les risques cachés dans l’ensemble de votre environnement applicatif et d’aider vos équipes à se concentrer sur les menaces qui comptent vraiment pour l’entreprise ?
Découvrez comment Snyk Essentials peut aider vos équipes à gérer leur programme AppSec et à prioriser les problèmes critiques pour l’activité afin de réduire les risques.
Protégez ce qui compte le plus pour votre entreprise
Découvrez comment Snyk aide les équipes AppSec à créer, gérer et déployer à grande échelle un programme AppSec moderne avec Snyk AppRisk ASPM