Skip to main content

Élaborer un plan de bataille pour la sécurité des applications : spécial Maman, j’ai raté l’avion

Écrit par
feature home alone

20 décembre 2022

0 minutes de lecture

Les fêtes de fin d’année sont le moment idéal pour revoir quelques films incontournables de la saison ! Certains préfèrent les films de Noël les plus mièvres (Hallmark, on vous voit), tandis que d’autres attendent chaque année avec impatience de voir un garçon de 8 ans se venger de deux malfrats maladroits dans le classique de 1990 Maman, j’ai raté l’avion.

C’est amusant d’imaginer un enfant défendre seul sa maison contre deux cambrioleurs à l’aide de petites voitures, d’un fer à repasser et de plusieurs autres pièges burlesques. En revanche, il est bien plus probable que des entreprises aient à défendre leurs biens (autrement dit, leurs applications) contre des attaquants. Mettre en place les bonnes mesures de sécurité des applications n’est peut-être pas aussi drôle que de brûler la tête d’un malfrat au chalumeau, mais cela peut ressembler à bien des égards au « plan de bataille » de Kevin McCallister.

Alors, dans l’esprit des fêtes de fin d’année, élaborons le meilleur « plan de bataille » pour protéger vos applications des attaquants.

Une personne fait tournoyer une chaussette blanche ou un morceau de tissu au-dessus d’une table en bois encombrée, dans une pièce faiblement éclairée.

Les « étages » de votre application

L’ingénieux plan de Kevin prévoyait des pièges à chaque étage de sa maison : au sous-sol, au rez-de-chaussée et à l’étage. Dans le film, il devait imaginer des stratagèmes ingénieux pour chaque entrée et chaque pièce. Après tout, il ne pouvait pas prévoir comment Harry et Marv (les cambrioleurs) tenteraient d’entrer chez lui, ni ce qu’ils feraient une fois à l’intérieur.

De la même manière, un bon plan de sécurité des applications couvre chaque « étage » de votre application : le code source, la chaîne d’approvisionnement logicielle et l’infrastructure.

Kevin ne s’est pas contenté de placer des pièges ingénieux (et franchement diaboliques) à chaque étage de la maison : il a aussi prévu qu’ils soient interconnectés. Marv a grimpé un escalier recouvert de goudron, ce qui l’a obligé à enlever ses chaussures. Il était alors parfaitement placé pour marcher sur un clou (frissons garantis !). Harry a foncé droit dans du film plastique enduit de colle, puis a trébuché sur un ventilateur qui lui a projeté une bonne quantité de plumes. Elles sont restées collées ! Les farces de Kevin s’enchaînaient à la perfection.

Comme les pièges de Kevin, les éléments de votre plan de sécurité des applications doivent se compléter. Tout ce qui se passe sur un « étage » de votre application doit être lié aux mesures de sécurité des autres « étages ». Aujourd’hui, cela signifie associer les efforts de sécurité dans le code source — propriétaire comme open source — ainsi que dans l’infrastructure cloud et les conteneurs. Voyons à quoi ressemble chacun de ces « étages ».

Étage 1 : code source

Le bon vieux code source développé en interne constitue le niveau le plus élémentaire de votre application. S’il n’est pas écrit en tenant compte de la sécurité, il risque de devenir une porte grande ouverte aux attaquants.

Mais votre équipe de sécurité ne peut pas être partout à la fois. Vous devez donc automatiser certaines parties de votre plan de bataille. Tout comme Kevin a utilisé des fils déclencheurs pour activer automatiquement ses pièges, votre équipe peut recourir aux tests statiques de sécurité des applications (SAST) automatisés pour détecter et corriger le code non sécurisé. La sécurisation de votre code source passe par deux étapes : effectuer régulièrement des tests statiques de sécurité des applications (SAST) et former vos développeurs aux bonnes pratiques, afin de leur donner les moyens d’écrire du code sécurisé dès le départ.

Vue sombre et déformée d’un étroit escalier de sous-sol, en direction d’une petite ouverture où se dessine une silhouette ou un objet.

Étage 2 : chaîne d’approvisionnement logicielle

Le deuxième « étage » de votre application est la chaîne d’approvisionnement logicielle : les éléments assemblés dans votre application, plutôt que développés de toutes pièces, comme les images de base de conteneurs et les composants open source. Toutefois, la correction des problèmes de sécurité de la chaîne d’approvisionnement logicielle nécessite des capacités spécialisées. Vous devez utiliser un outil conçu pour rechercher les vulnérabilités propres aux conteneurs et un autre pour détecter les risques liés à l’open source. Ces deux outils doivent aussi proposer des étapes claires pour corriger les problèmes, par exemple en revenant à la version la plus sécurisée de l’élément concerné.

Un homme dans une cuisine recule tandis qu’une flamme jaillit d’un plafonnier.

Étage 3 : infrastructure

Pour adopter une approche globale de la sécurité des applications, vous devez tenir compte des éléments structurels de votre application, comme votre environnement cloud et votre infrastructure as code (IaC). Quels services cloud utilisez-vous pour le stockage ? Sont-ils correctement configurés, avec les autorisations et les contrôles d’accès appropriés, ou risquent-ils d’exposer votre application ? Et votre IaC est-elle écrite de manière sécurisée, comme votre code source ?

Sécuriser l’infrastructure de votre application nécessite une approche contextuelle. Après tout, votre écosystème cloud n’existe pas en vase clos. Son utilisation dépend plutôt fortement de votre IaC.

Un homme vêtu de sombre est assis près d’une fenêtre aux rideaux transparents et regarde quelque chose qu’il tient dans les mains.

Réunir tous les éléments de votre plan de bataille

Tous ces outils sont utiles individuellement, mais nous parlons d’un « plan », et non de « plans », pour une bonne raison ! Si vous ne définissez pas de stratégie pour coordonner toutes ces mesures de sécurité distinctes, vous risquez de passer à côté du contexte complet des vulnérabilités détectées. Des outils disparates compliquent également la collaboration entre développeurs, professionnels de la sécurité et architectes cloud qui doivent unir leurs efforts pour assurer votre sécurité.

Snyk relève ce défi grâce à une plateforme centralisée couvrant cinq domaines de la sécurité : le code source, l’open source, les conteneurs, le cloud et l’IaC. Nous proposons également des formations destinées aux développeurs, afin de donner les moyens d’agir à ceux qui connaissent le mieux tous ces domaines : les équipes de développement. Découvrez notre plateforme de sécurité pour les développeurs. Mais rassurez-vous : si vous souhaitez faire une pause lecture et regarder _Maman, j’ai raté l’avion_ à la place, nous serons là à votre retour !

Jeune garçon portant un pull rouge, avec des sous-titres jaunes indiquant : « Gardez la monnaie, espèce de sale bête. »

Lancez-vous dans les compétitions Capture The Flag

Apprenez à résoudre des défis Capture The Flag en regardant à la demande notre atelier virtuel d’initiation.

Lire la suite

Blog

Les modèles de pointe ont trouvé les vulnérabilités. Seul l’attaquant a trouvé les chaînes d’exploitation.

L’analyse statique a détecté les failles, mais seuls des tests d’attaque en conditions réelles ont prouvé comment elles pouvaient être enchaînées pour provoquer des compromissions. Comparaison d’Evo COS, de Claude Security et de Claude Code Security.

feature insights context
Blog

Les attaques autonomes sont déjà là. La défense doit suivre leur rythme.

Les attaquants autonomes réduisent la fenêtre de défense. Découvrez comment la découverte, la correction, la validation et la prévention continues peuvent aider les équipes de sécurité à suivre le rythme.

Blog

Pourquoi les agents de codage IA créent-ils sans cesse des failles de contrôle d’accès ?

Les agents de codage IA peuvent générer une logique d’autorisation qui compile et passe la revue, tout en exposant les données d’un tenant à un autre. Découvrez pourquoi les failles de contrôle d’accès sont difficiles à détecter et comment les prévenir.