Guide complet de la sécurité des applications

Ce guide sur la sécurité des applications vous permettra de bien comprendre les concepts fondamentaux de la sécurité des applications. Vous y trouverez des explications sur les défis qui y sont associés, ainsi que les outils et les meilleures pratiques dont vous avez besoin pour rester en sécurité en 2023.

Pourquoi la sécurité des applications est-elle importante ?

Les applications, et en particulier celles qui sont cloud natives, constituent une passerelle vers les serveurs et les réseaux et présentent un vecteur d’attaque idéal pour les acteurs malveillants. Les personnes malveillantes étant continuellement en train d’affiner leurs méthodes de pénétration des logiciels, il est essentiel que la sécurité soit une activité continue et profondément enracinée dans le processus de développement. Les meilleures pratiques en matière de sécurité des applications permettent de découvrir les vulnérabilités avant que les attaquants ne puissent les utiliser pour pénétrer dans les réseaux et accéder aux données. Il est également important de ne pas négliger la sécurité des données des applications pour s’assurer que les données sensibles, comme les informations client, sont protégées.

Les vulnérabilités proviennent parfois d’une simple erreur de configuration ou de l’utilisation d’un composant logiciel qui contient une vulnérabilité connue. Le problème est répandu : selon le rapport 2021 State of Cloud Native Application Security de Snyk, plus de 56 % des organisations ont connu un incident lié à une erreur de configuration ou à une vulnérabilité connue non corrigée impliquant leurs applications cloud natives. Bien que toutes ces vulnérabilités ne représentent pas un risque de sécurité majeur, les pirates eux-mêmes les évaluent pour trouver celles qui présentent une méthode plausible de pénétration.

Les problèmes les plus fréquents sont les erreurs de configuration et les vulnérabilités connues, mais non corrigées.

Les organisations de toutes tailles doivent également être conscientes du risque que représentent les erreurs de configuration, en particulier celles qui travaillent avec des données très sensibles (comme les institutions financières). La sécurité des applications se développe en tant que marché distinct qui, selon les analystes de Forrester, devrait atteindre 12,9 milliards de dollars d’ici 2025. Pour améliorer la sécurité des applications, les entreprises doivent mettre en œuvre une approche à deux volets :

• Mettre en œuvre les processus requis pour la sécurité, centrés sur une culture de sécurité shift left et une évolution vers l’intégration de la sécurité dans DevOps.

• Adopter les outils nécessaires à une sécurité complète, en particulier des outils d’analyse qui s’intègrent aux outils et aux workflows des développeurs.

En plus de ces outils et processus, les développeurs et les équipes de sécurité peuvent accéder à une variété de ressources pour rester à la pointe de la sécurité des applications, notamment des organisations telles que l’Open Web Application Security Project (OWASP), organisme à but non lucratif qui publie une liste annuelle des principales vulnérabilités de sécurité des applications web. Les ressources de Snyk, notamment son rapport State of Cloud Native Application Security, aident davantage les développeurs à naviguer dans la sécurité des applications à l’ère du cloud native.

Tendances en matière de sécurité des applications en 2023

2022 est une année charnière pour la cybersécurité, car les cybermenaces gagnent en envergure et en complexité. Pour y faire face, les organisations prennent différentes mesures :

• Les CISO font désormais partie intégrante de l’équipe de direction. Aux États-Unis, la cybersécurité est considérée comme une question de sécurité nationale. En février 2022, le président Biden a signé l’Executive Order on America’s Supply Chains (Décret sur les chaînes d’approvisionnement des États-Unis), qui vise à renforcer le soutien à la cybersécurité pour les secteurs critiques de l’industrie des technologies de l’information et des communications (TIC). Le conflit en Ukraine a mis encore davantage la cybersécurité sous les feux de la rampe en raison des inquiétudes suscitées par des cyberattaques potentielles commanditées par la Russie.

• Malgré leur rôle dédié, les CISO sont censés faire plus avec les mêmes ressources. Pour y parvenir, des innovations seront nécessaires dans les domaines du personnel, de la technologie et des processus.

• L’attaque Log4J a mis en évidence l’importance croissante de la sécurité de la chaîne d’approvisionnement des logiciels. Les acteurs malveillants continuent de chercher à compromettre les référentiels de code open source ou d’autres liens de la chaîne d’approvisionnement. Les organisations réagissent en identifiant les maillons faibles et en mettant en œuvre de meilleures mesures de sécurité tout au long de la chaîne d’approvisionnement.

• La prolifération des applications cloud natives oblige à prendre en compte les configurations de l’infrastructure du cloud et de l’infrastructure en tant que code (IaC) dans les considérations de sécurité et de conformité. L’orchestration des tests de sécurité des applications, qui intègre la sécurité tout au long du processus de développement, fait partie de cette posture globale de sécurité du cloud. Vous devez veiller à couvrir tous les niveaux de sécurité des applications, depuis votre propre code jusqu’à la configuration du cloud, en passant par les dépendances.

Quels sont les défis de la sécurité des applications modernes ?

La sécurité des applications modernes est un sujet vaste et complexe. Nous l’avons ramené à cinq défis principaux auxquels les organisations sont couramment confrontées :

1. Vulnérabilités héritées

2. Vulnérabilités tierces et de l’open source

3. Adoption d’une approche DevSecOps

4. Recherche d’experts qualifiés

5. Absence d’un outil de gestion centralisé

Examinons de plus près chacun de ces points :

Vulnérabilités héritées

Si les développeurs doivent être conscients des vulnérabilités qu’ils peuvent introduire pendant le processus de codage, certaines sont toutefois inhérentes aux applications modernes. Ces vulnérabilités héritées existent pour plusieurs raisons :

1. Le caractère entropique des systèmes logiciels : ils changent constamment, augmentent en complexité et ont besoin d’être mis à jour et améliorés.

2. La priorisation des corrections, des mises à jour et des activités de maintenance les plus importantes constitue un effort vital et continu.

3. Le code hérité continue de jouer un rôle important dans l’environnement de nombreuses organisations, et les équipes de sécurité doivent analyser ce code et prioriser les corrections les plus importantes. L’ancien code étant moins attrayant que le nouveau code d’application, les personnes sont moins enclines à l’utiliser. Il nécessite néanmoins une attention particulière en matière de sécurité.

4. Les outils de sécurité les plus récents ne sont souvent pas autorisés à traiter le code hérité. Les problèmes s’accumulent avec le temps si le code n’est pas maintenu et sécurisé.

Vulnérabilités tierces et de l’open source

L’utilisation répandue de bibliothèques tierces et open source en fait un vecteur d’attaque attrayant. Les dépendances transitives (ou indirectes) sont particulièrement préoccupantes, les développeurs étant susceptibles d’utiliser des paquets vulnérables sans s’en rendre compte.

Ce problème a récemment été mis en lumière lorsque Snyk a découvert un cas de sabotage par le mainteneur du célèbre paquet node-ipc. Le mainteneur a ajouté un module appelé peacenotwar qui détecte la géolocalisation d’un système et affiche un symbole de cœur pour les utilisateurs de Russie et de Biélorussie. peacenotwar n’avait pratiquement aucun téléchargement jusqu’à ce qu’il soit ajouté comme dépendance au paquet node-ipc.

Cet incident, ainsi que la corruption intentionnelle similaire du paquet npm colors, montre que les attaquants externes ne sont pas la seule préoccupation concernant les dépendances open source. Les mainteneurs eux-mêmes peuvent publier des paquets contenant du code malveillant ou des vulnérabilités.

Il est impossible de détecter toutes ces vulnérabilités manuellement. Pour sécuriser les dépendances open source, vous avez donc besoin d’outils qui vous permettent de savoir ce qu’il faut mettre à jour (et quand) et de détecter les nouvelles vulnérabilités dès leur apparition. Outre les outils d’analyse, l’application de politiques peut aider à intégrer la sécurité dans les projets dès le départ. Les équipes doivent élaborer des politiques qui suivent les meilleures pratiques et sélectionner des outils qui appliquent ces politiques. Le cadre OpenSSF, par exemple, fixe des règles que les projets de logiciels open source doivent respecter. Si tout le monde utilisait ce cadre, les outils de sécurité ne seraient peut-être pas tant nécessaires, mais il est peu probable que cela arrive de sitôt.

Adoption d’une approche DevSecOps

En plus des outils de sécurité, il est essentiel d’adopter une approche shift left et d’intégrer la sécurité tout au long du processus de développement. Traditionnellement, l’analyse survenait tard dans le cycle de vie du développement logiciel. Les résultats étaient renvoyés aux équipes de développement pour correction, et les équipes de sécurité devenaient ainsi un goulot d’étranglement pour les autres secteurs de l’entreprise. L’outil lui-même contribuait au problème en complexifiant encore la tâche des développeurs : Le nombre élevé de faux positifs imposait aux membres de l’équipe de trier les problèmes, leur faisant ainsi perdre du temps.

Cette approche traditionnelle fonctionnait suffisamment bien pour les organisations utilisant une approche en cascade pour les versions de logiciels, mais le développement de logiciels modernes exige une intégration plus agile et plus étroite entre la sécurité et le développement. Détecter et résoudre les problèmes plus tôt dans le développement rend le processus plus efficace pour les équipes de sécurité et toutes les autres personnes concernées.

Le test shift left intègre les meilleures pratiques de test le plus tôt possible dans le pipeline CI/CD.

Le test shift left intègre les meilleures pratiques de test le plus tôt possible dans le pipeline CI/CD.

Recherche d’experts qualifiés

En plus du shift left, la dimension humaine de la sécurité est déterminante. Trouver des experts en sécurité qualifiés est une priorité absolue, et les équipes de sécurité elles-mêmes doivent améliorer leur formation, développer des processus efficaces et analyser leurs outils. Elles peuvent ensuite s’équiper pour une approche de la sécurité plus intégrée, où les analyses sont conduites en parallèle des pipelines CI/CD afin que les développeurs puissent facilement appliquer les correctifs. Les organisations éprouvent des difficultés à recruter du personnel expérimenté en cybersécurité, avec un rapport entre développeurs et praticiens de la sécurité d’environ 100:1. C’est pourquoi de plus en plus d’organisations se penchent davantage sur la sécurité des développeurs grâce à l’éducation et à l’automatisation.

Absence d’un outil de gestion centralisé

Les professionnels de la sécurité ont pour mission de gérer le risque auquel une organisation est prête à s’exposer. L’idée qu’il est possible de réduire ce risque à zéro est, dans le meilleur des cas, naïve et, dans le pire, contre-productive. L’un des aspects majeurs de la gestion des risques consiste à évaluer les vulnérabilités des applications et de déterminer quelles sont celles à traiter en priorité, quand et comment.

Les équipes chargées de la sécurité des applications ont besoin d’outils pour les aider. Elles doivent en permanence surveiller et évaluer la posture de sécurité d’une application. La posture de sécurité est la combinaison des connaissances en matière de sécurité à tous les niveaux de l’application. Sur la base de ces connaissances, les équipes de sécurité effectuent un tri et établissent un inventaire des problèmes à résoudre dans le cadre de leur processus de sécurité des applications.

Enfin, l’équipe de sécurité surveille et s’assure que les problèmes consignés sont traités rapidement et de manière adéquate. Les meilleurs outils seront en mesure de centraliser tous les rapports nécessaires et de les présenter aux parties prenantes dans un tableau de bord unique.

Top 10 de l’OWASP sur la sécurité des applications 2021 : Points forts

Le Top 10 2021 de l’OWASP fournit une liste diversifiée de vulnérabilités qui sert de référence pour évaluer les outils. Deux points importants à noter :

1. La liste a considérablement changé par rapport à l’année précédente en raison de l’évolution du profil des menaces et d’une nouvelle méthode qui consiste à établir la liste en tenant compte à la fois de l’exploitabilité et de l’impact potentiel d’une vulnérabilité. La défaillance de contrôle d’accès est passée de la cinquième à la première place, tandis que les échecs d’identification et d’authentification sont passés de la deuxième à la septième place, peut-être en raison de la disponibilité de cadres standardisés.

2. Les vulnérabilités sont très variées, allant d’une conception non sécurisée à des défaillances cryptographiques, en passant par l’absence de vérification de l’intégrité des données ou du pipeline. Cela signifie que la sécurité ne doit pas seulement suivre une approche shift left ; elle doit couvrir tous les aspects d’une application.

Le Top 10 2021 de l’OWASP est basé sur les données de plus de 500 000 applications et fournit donc des informations précieuses sur les vulnérabilités courantes et leur profil de risque. En tant que tel, il constitue un bon point de départ pour évaluer l’exhaustivité d’un outil donné.

Dans la version 2021, le risque le plus important est un contrôle d’accès défaillant, problème auquel Snyk Infrastructure as Code (Snyk IaC) s’attaque. Le troisième risque est celui des attaques par injection, que Snyk Code peut révéler au moyen de l’analyse du flux de données. Le sixième point de la liste concerne les composants vulnérables et périmés, que Snyk Open Source peut détecter.

En résumé, Snyk aborde tous les éléments du Top 10 de l’OWASP que les tests de sécurité des applications peuvent évaluer. Consultez notre analyse pour en savoir plus sur le Top 10 de l’OWASP et découvrir la liste complète.

Les trois niveaux de l’architecture de sécurité des applications

L’architecture d’une application moderne comporte trois niveaux. Chaque niveau présente ses propres risques qui doivent être pris en compte. Voici un aperçu de chacun d’eux, de leur composition et de leur profil de risque potentiel.

Niveau supérieur : les clients

Ce niveau supérieur, qui peut être un front-end web, un front-end pour l’internet des objets (IoT) ou un front-end mobile, est l’endroit où les utilisateurs interagissent avec une application. Les développeurs de front-end ont pour priorité première de fournir une expérience performante et de haute qualité à l’utilisateur final, mais chaque type de front-end a son propre profil de menace, et la sécurité ne doit donc pas être négligée. Il existe de nombreuses façons d’attaquer le front-end, notamment par injection et par déni de service.

Niveau intermédiaire : l’application

C’est là que sont traitées les données collectées auprès des utilisateurs. L’architecture hiérarchisée elle-même contribue à la protection contre les exploits en créant une sorte de pare-feu entre les utilisateurs finaux et les données. D’autres outils, tels que des contrôles d’accès précis, peuvent contribuer à sécuriser ce niveau intermédiaire.

Niveau inférieur : le back-end

Il s’agit des systèmes d’exploitation, de l’infrastructure cloud, des conteneurs : tout ce qui est utilisé pour exécuter les applications et stocker les données. L’objectif de la plupart des attaques est d’ouvrir une brèche dans ce niveau, il est donc important d’utiliser des configurations sécurisées, des réseaux correctement configurés et un chiffrement robuste des données pour sécuriser le back-end.

Diagramme de l’architecture d’une application moderne

Le diagramme ci-dessous illustre l’architecture d’une application moderne. Le front-end est alimenté par une logique métier et une couche de données qui expose une API au front-end et s’exécute dans le cloud (comme AWS, Azure ou Google Cloud).

Sur la gauche, le code source définit le client et la logique, les paquets pour vos dépendances, les spécifications du cloud (en utilisant IaC) et les fichiers de conteneur qui donnent la configuration des conteneurs dans lesquels votre application sera exécutée.

Sur le côté droit se trouve la gestion active de la production. Les consoles de gestion du cloud pour la production sont des cibles particulièrement attractives pour les pirates : quelqu’un qui prend le contrôle de votre console de gestion du cloud peut l’utiliser pour prendre le contrôle de machines pour extraire des bitcoins, entre autres utilisations non autorisées.

Diagramme de l’architecture de sécurité des applications

Il est important d’orchestrer la sécurité entre les différents niveaux pour s’assurer qu’elle peut être gérée et opérationnalisée. Cela peut avoir des avantages secondaires supplémentaires, comme la capacité à détecter la fraude au clic, susceptible d’entraîner une sursouscription du cloud.

Les 3 principaux piliers de la sécurité des applications

Une sécurité des applications efficace repose sur trois piliers principaux :

• La technologie, en particulier les processus et les outils de formation.

• Les processus, en particulier les politiques, les principes et les contrôles.

• Les utilisateurs, qui doivent être sensibilisés et formés à la sécurité (par exemple pour prévenir le phishing).

Il est nécessaire de hiérarchiser l’importance de chaque section pour votre entreprise afin d’évaluer vos points faibles et de déterminer les axes d’amélioration. En outre, ces piliers interagissent les uns avec les autres. Par exemple, tous les outils comportent des éléments humains. La qualité d’un outil dépend de celle des personnes formées pour l’utiliser. À leur tour, les humains peuvent penser stratégiquement aux outils, par exemple en utilisant la sécurité physique ainsi que la sécurité des logiciels. Consultez notre liste de 15 meilleures pratiques pour la sécurité des applications pour en savoir plus.

Voici quelques meilleures pratiques autour des trois piliers de la sécurité des applications :

Technologie : révisez votre trousse d’outils

1. Commencez par définir une trousse d’outils complète qui peuvent s’intégrer les uns aux autres et qui correspondent aux capacités de vos ressources et à votre budget. Rappelez-vous que les meilleurs outils donnent des recommandations : ils exigent que les humains appliquent ces recommandations afin d’en tirer le meilleur parti.

2. Explorez les nouveaux outils disponibles et examinez leurs capacités.

3. Planifiez la feuille de route de vos outils. Où vont-ils ? Quelle est votre vision de l’outillage ? Ces outils répondront-ils aux besoins de votre entreprise ?

Processus : soyez clair

1. Commencez par définir vos processus de sécurité des applications. Posez-les par écrit afin d’y voir plus clair.

2. Testez vos processus. Fonctionnent-ils réellement ? Il est préférable d’apprendre des problèmes durant les tests plutôt que dans une situation d’urgence.

3. Maintenez un référentiel de processus. Conservez vos processus en un seul endroit. Cela est utile lors de l’intégration et peut vous aider à repérer les chevauchements dans les processus.

Humains : adoptez leur rôle

1. Les équipes de sécurité et les développeurs sont les références pour vos connaissances. Ils ont besoin d’être « mis à jour », tout comme les logiciels eux-mêmes ont besoin de mises à jour. Le domaine de la sécurité est en constante évolution, mais la communauté des développeurs est riche en informations, en formations et en événements. Formez et investissez dans votre personnel afin qu’il soit au fait de l’évolution des menaces et des pratiques d’atténuation.

2. Investissez dans toutes les couches de sécurité. L’ensemble du personnel doit être sensibilisé à l’importance et aux règles de sécurité, des agents d’entretien aux PDG.

3. Encouragez une culture de la transparence pour les plus petites choses. « VOYEZ-LE, DITES-LE, CLASSEZ-LE » devrait être la devise. Un problème ne peut pas être réglé si personne ne le mentionne.

Six types d’outils d’analyse de la sécurité des applications

Les outils d’analyse sont essentiels à la sécurité des applications car ils permettent aux développeurs de tester les applications avant de les exécuter dans un environnement de production. Ces outils se présentent sous différentes formes, notamment ceux qui analysent directement le code source et d’autres qui évaluent une application en exécutant des entrées à travers elle. Voici six types courants d’outils d’analyse :

• Tests de sécurité des applications statiques (SAST) : le test SAST est une méthode de test boîte blanche avec accès au code source. Au repos, il identifie les faiblesses susceptibles de conduire à une vulnérabilité, puis génère un rapport.

• Tests interactifs de sécurité des applications (IAST) : cette forme de test de sécurité des applications analyse le code source à la recherche de vulnérabilités tout en exécutant l’application et en simulant les façons dont un utilisateur interagirait couramment avec elle.

• Analyse de la composition des logiciels (SCA) : également connue sous le nom d’analyse de l’origine, cette méthode permet d’analyser tous les composants logiciels et les bibliothèques sourcés. Ces outils facilitent l’identification des vulnérabilités connues et informent l’utilisateur de tout correctif ou mise à jour disponible.

• Test de sécurité des applications dynamiques (DAST) : DAST teste la posture de sécurité d’une application en appliquant différents types d’attaques à l’application en cours d’exécution. Il ne nécessite pas d’accès au code source de l’application, ce qui en fait une méthode de test boîte noire.

• Tests de sécurité des applications en tant que service (ASTaaS) : dans ce scénario, l’organisation fait appel à une société externe pour effectuer tous les tests relatifs à ses applications. L’ASTaaS combine généralement des méthodes de sécurité statiques et dynamiques, notamment des tests de pénétration et l’évaluation des interfaces de programmation d’applications (API).

• Fuzzing : le fuzzing consiste à tester une application en entrant des données aléatoires afin de découvrir des bugs potentiels. Le fuzzing complète les tests du type IAST, DAST, SAST et autres formes de tests.

SAST, DAST ou SCA

Comment Snyk contribue à la sécurité des applications

Snyk est une technologie de sécurité des applications incontournable en cela qu’elle fournit des étapes de surveillance et d’atténuation de bout en bout qui s’intègrent aux workflows existants des développeurs. Ses outils comprennent :

1. Snyk Code : outil SAST au service des développeurs conçu pour rendre les corrections faciles et efficaces ;

2. Snyk Open Source : outil d’analyse de la composition des logiciels (SCA) qui révèle et priorise les vulnérabilités open source ;

3. Snyk Container : outil qui aide à sécuriser les conteneurs de l’image de base à l’exécution ;

4. Snyk IaC : outil qui aide les développeurs à écrire des configurations IaC sécurisées.

5. Snyk Cloud : outil conçu pour aider les développeurs à gérer la sécurité du cloud au moyen de politique en tant que code.

Voici une présentation visuelle de la manière dont la boîte à outils de Snyk s’intègre à la sécurité des applications :

Les outils de Snyk constituent l’étape naturelle suivante vers une automatisation maximale de la sécurité des développeurs. L’organisation poursuit son évolution vers la sécurisation des applications au moment de l’exécution à travers son partenariat avec Sysdig et sa récente acquisition de Fugue. Ensemble, ces outils aident les développeurs à assurer la sécurité des applications tout au long de leur cycle de vie.

Exemples en lien avec la sécurité des applications

Consultez nos études de cas pour découvrir comment des organisations ont utilisé Snyk pour améliorer leur processus et posture de sécurité des applications en déployant des workflows pensés pour les développeurs.

« L’équipe de sécurité de Glovo a fait état d’une réduction de 78 % des vulnérabilités critiques dans ses dépendances et dans le code à l’aide de Snyk. En outre, l’équipe est parvenue à réduire de 40 % le temps moyen de correction, prouvant ainsi qu’elle est en mesure de fournir plus rapidement du code plus sécurisé. »
Glovo

Lectures suggérées

15 meilleures pratiques pour la sécurité des applications 2022 | Snyk

Qu’est-ce que la vulnérabilité des applications ? | Snyk

10 principaux acronymes de la sécurité des applications | Snyk

Foire aux questions