Le quoi, le pourquoi et le comment de la sécurité « shift-left »

Nous vivons à une époque de crise cybersécuritaire, et la sécurité « shift-left » apporte partiellement la solution. Non seulement les attaques augmentent en fréquence – le nombre moyen d’attaques a augmenté de plus de 15 % en 2021, une tendance qui ne montre aucun signe de ralentissement – mais les menaces deviennent également de plus en plus complexes. Les acteurs des menaces tirent parti de méthodes d’attaque plus sophistiquées, telles que les attaques d’ingénierie sociale, qui ont augmenté de 270 % en 2021, et le déploiement de « virus furtifs » conçus pour échapper aux méthodes de détection traditionnelles.

Cela ne signifie pas, cependant, que les entreprises doivent rester les bras croisés face à ces cyberattaques d’une ampleur et d’une intensité record. Elles peuvent riposter en déplaçant la sécurité « shift-left ». Ce faisant, ils peuvent non seulement détecter de manière plus précoce les risques, mais aussi investir moins de temps et de ressources dans l’atténuation des menaces.

Continuez votre lecture pour disposer d'un aperçu complet de ce que signifie la sécurité « shift-left », pourquoi elle est précieuse et savoir comment déplacer la sécurité shift-left dans la pratique.

Qu’est-ce que la sécurité « shift-left » ?

La sécurité shift-left est une approche de la sécurité des applications qui met l’accent sur la détection et l’atténuation des problèmes de sécurité le plus tôt possible dans le cycle de vie du développement logiciel.

Pour comprendre ce que cela signifie, vous devez d’abord comprendre comment les cycles de vie de développement logiciel (parfois appelés cycles de vie de livraison de logiciels ou pipelines de développement logiciel) fonctionnent dans DevOps. En règle générale, chaque nouvelle application ou version d’application développée par une équipe passe par une série d’étapes :

• Le codage, qui consiste à écrire du code pour définir des caractéristiques individuelles ou des unités de fonctionnalités.
• L'intégration, au cours de laquelle les fonctionnalités ou les modifications sont intégrées dans la base de code principale de l’application.
• La construction, c’est-à-dire le processus de compilation du code source et des dépendances en binaires pouvant être exécutés.
• Les tests, lorsque les ingénieurs exécutent des tests pour vérifier que les applications répondent aux exigences de performances.
• Le déploiement ou processus de mise en place de l’application dans un environnement de production.
• Le runtime, qui se produit lorsque l’application s’exécute en production.

Source : https://jfrog.com/fr/blog/shift-left-security-with-golang-in-vs-code/

Traditionnellement, les tests de sécurité avaient lieu pendant la phase de test du cycle de vie de la livraison. Parfois, ils ne se produisaient pas tant qu’une application n’était pas déjà déployée en production. Cependant, dans le cadre d’une méthodologie de sécurité décalée à gauche, les équipes DevOps commencent les tests de sécurité le plus tôt possible – idéalement, dès qu’une nouvelle source est écrite.

Par exemple, dans le cadre d’une approche shift-left, vous pouvez analyser votre code source pour identifier les dépendances d’application avant que le code ne soit compilé et mis en scène. Avec ces informations, vous pouvez déterminer si l’une des dépendances introduit des composants open source vulnérables dans votre base de code. Si elles ne sont pas traitées, ces vulnérabilités deviendront une menace de sécurité active lorsque votre application sera déployée en production.

Autre exemple, une stratégie shift-left peut vous aider à détecter les contrôles d’accès mal configurés, qui constituent un risque de sécurité car ils affaiblissent la posture de sécurité de votre application. Si vous ne mettez pas à jour vos contrôles d’accès avant de déployer l’application en production, vous introduisez les risques de configuration dans votre environnement de production.

Déplacer la sécurité vers la gauche ne signifie pas que vous n’avez plus besoin d’effectuer une surveillance de la sécurité en production. Vous devrez certainement déployer tous les efforts possibles pour détecter les menaces dans les environnements de production. Mais lorsque vous déplacez la sécurité vers la gauche, vous investissez également massivement dans la détection des risques et des menaces plus tôt dans le cycle de vie du développement. Plus les problèmes de sécurité sont résolus tôt dans le cycle de vie du développement, plus l’entreprise est rentable.

Le concept de sécurité shift-left reflète la surveillance et les tests shift-left, qui ont précédé l’émergence de l’idée de sécurité shift-left. Alors que la surveillance et les tests shift-left impliquent l’exécution de tests de performances et de fiabilité le plus tôt possible dans le cycle de vie du développement logiciel, les tests de décalage à gauche mettent l’accent sur les tests de sécurité au début du cycle de vie du développement.

Les principaux avantages de la sécurité shift-left

Les organisations qui adoptent la sécurité « à gauche » en tirent plusieurs avantages de taille :

Détection précoce des risques

Le plus évident est peut-être le fait que la sécurité à gauche aide les équipes à détecter les risques à un stade précoce. Par extension, il donne aux ingénieurs plus de temps pour réagir, tout en réduisant la gravité de la menace posée par un risque ou une vulnérabilité.

Si vous découvrez une vulnérabilité zero-day dans une application en production, vous devez prendre des mesures pour la résoudre immédiatement, car elle peut être exploitée à tout moment. Dans cette situation, la résolution implique souvent de suivre la voie de moindre résistance (par exemple, désactiver votre application jusqu’à ce que vous puissiez la mettre à jour pour corriger la vulnérabilité), plutôt que d’appliquer une atténuation moins perturbatrice. Mais si vous détectez le problème pendant le développement, vous pouvez le résoudre avec un minimum de perturbations pour vos utilisateurs, et sans avoir à le traiter comme une situation de crise.

Minimisez les menaces dans les environnements de production

Par ailleurs, la détection des risques et des menaces plus tôt dans le cycle de vie du développement réduit considérablement les chances que leurs auteurs puissent exploiter un risque ou une vulnérabilité au sein d’une application.

Bien qu’il soit possible pour les attaquants de violer les environnements de pré-production où les applications sont développées et testées (comme ils l’ont fait, par exemple, lors de l’attaque SolarWinds), le risque d’attaque active est beaucoup plus élevé dans les environnements de production. En production, les applications sont exposées aux utilisateurs finaux et, dans la plupart des cas, à Internet, de sorte qu’il est beaucoup plus facile pour les auteurs de menaces de trouver et d’exploiter les vulnérabilités en production que dans un environnement de développement ou de test, qui n’est généralement pas directement accessible depuis Internet.

Corrigez les menaces plus rapidement et à moindre coût

En général, plus tôt vous détectez un risque ou une menace de sécurité, moins il faut de temps et d’efforts pour y faire face.

Par exemple, si vous détectez un problème de sécurité avant que le code n’ait été compilé et passé au test, vous pouvez simplement mettre à jour le code. Vous n’aurez pas perdu de temps à créer et à tester une version d’application que vous finirez par abandonner. En revanche, si vous n’attrapez pas de problème avant la production, vous devrez identifier la cause première de la menace, mettre à jour votre code source, reconstruire votre application, tester la version mise à jour et, enfin, la déployer – un processus qui pourrait prendre des semaines, alors que la mise à jour du code source avant la création de l’application peut ne prendre que quelques minutes, si la vulnérabilité est simple à résoudre.

Et, parce que le temps, c’est de l’argent, une atténuation plus rapide des problèmes permet non seulement d’économiser des efforts aux développeurs, mais aussi de réduire les coûts pour l’entreprise. Lorsque les développeurs passent plus de temps à créer de nouvelles applications et fonctionnalités, et moins de temps à corriger les bogues de sécurité, l’entreprise peut faire plus avec les codeurs disponibles.

Réduire le risque de retards

Plus vous laissez votre code se déplacer avant de détecter un problème de sécurité plus bas dans le pipeline de mise à disposition du logiciel, plus le risque que le problème entraîne un retard dans la publication de votre application est élevé.

Encore une fois, les problèmes de sécurité détectés lorsqu’une mise à jour d’application n’est encore que du code source peuvent souvent être corrigés rapidement et facilement. Mais si vous attendez que la version de l’application ait déjà été créée ou, pire, qu’elle soit en production, la résolution du problème devient un processus beaucoup plus long, ce qui augmente considérablement le risque que votre équipe ne livre pas l’application mise à jour dans les délais promis.

Améliorer la collaboration entre les développeurs et les équipes de sécurité

La détection précoce des risques et des menaces de sécurité, lorsqu’ils sont plus faciles à corriger et ne créent pas de situation de crise, contribue également à faciliter la collaboration entre les développeurs et les équipes de sécurité. Il est facile pour chacun de ces groupes de prendre du recul, d’évaluer un problème et de travailler en collaboration pour le résoudre lorsque le problème est détecté dans le code source.

D’un autre côté, si vous n’attrapez pas de problème de sécurité avant la production, vous risquez davantage de vous retrouver avec des développeurs et des ingénieurs de sécurité qui se pointent du doigt. Les développeurs blâmeront la sécurité de ne pas avoir détecté le problème, tandis que la sécurité blâmera les développeurs de l’avoir introduit. Ce n’est pas une bonne recette pour la collaboration.

Sécurité décalée vers la gauche et DevSecOps

Le fait que la sécurité shift-left facilite la collaboration entre les développeurs et les équipes de sécurité est l’une des raisons pour lesquelles le déplacement de la sécurité vers la gauche est souvent évoqué dans le contexte des conversations sur DevSecOps – un concept qui encourage la collaboration active entre les développeurs, les équipes de sécurité et les équipes d’opérations informatiques.

Cela ne signifie pas, cependant, que la sécurité shift-left et DevSecOps signifient la même chose. DevSecOps est une philosophie ou un objectif que les organisations peuvent utiliser pour guider leur approche de la sécurité. En revanche, la sécurité par décalage à gauche est une stratégie spécifique.

Déplacer la sécurité vers la gauche est un excellent moyen d’aider à opérationnaliser DevSecOps, mais adopter la sécurité décalée vers la gauche ne signifie pas que vous devenez une organisation DevSecOps. DevSecOps nécessite des pratiques supplémentaires, telles que le maintien de canaux de communication actifs entre les équipes de sécurité et les équipes de développement, et la garantie que les développeurs disposent d’une formation adéquate pour comprendre les problèmes de sécurité auxquels sont confrontées les applications modernes.

La sécurité shift-left dans la pratique : Deux exemples

Pour comprendre à quoi ressemble la sécurité shift-left dans la pratique, considérons deux exemples de la façon dont elle peut aider les équipes à éviter les situations à risque dans le monde réel.

Détection de vulnérabilités dans les images de conteneur

Tout d’abord, imaginez un scénario dans lequel votre équipe déploie une image de conteneur basée sur Ubuntu. Le conteneur est construit à l’aide d’un Dockerfile qui ressemble à ceci :

FROM ubuntu:20.04

RUN apt-get update && \

apt-get install -y python3 && \

apt-get clean

CMD ["some-app"]

Comme tous les systèmes d’exploitation, Ubuntu est sujet à une variété de vulnérabilités connues, qu’il divulgue sur son site Web. L’approche traditionnelle, sans décalage à gauche, pour détecter ces vulnérabilités consiste à déployer le conteneur en production, puis à analyser l’environnement de production pour déterminer si un logiciel vulnérable est en cours d’exécution.

Toutefois, dans le cadre d’une stratégie shift-left, vous pouvez déployer des outils qui analyseraient le Dockerfile avant la création de l’image du conteneur. Les outils détecteraient que le Dockerfile utilise Ubuntu 20.04 comme image de base. Ils détermineraient ensuite si Ubuntu 20.04 est sujet à des vulnérabilités connues qui restent non corrigées. Si c’est le cas, vous pouvez traiter les menaces en utilisant une image de base différente, ou en désactivant ou en mettant à jour manuellement les composants vulnérables de votre conteneur et en ajoutant des commandes au Dockerfile pour apporter ces modifications.

Remédier aux contrôles d’accès faibles

Comme deuxième exemple de sécurité shift-left, imaginez que votre équipe envisage de déployer un pod Kubernetes défini comme suit :

Version d’API : extensions/v1beta1

type : Déploiement

métadonnées :

nom : my-app

spéc :

template:

spéc :

containers:

- image: my-image

nom : my-app

...

securityContext:

allowPrivilegeEscalation: faux

runAsUser: 0

La dernière ligne de ce fichier – runAsUser : 0 – indique au pod de s’exécuter en tant qu’utilisateur avec un UID de 0. Si vous en savez beaucoup sur les UID Linux, vous saurez que l’UID 0 est destiné à l’utilisateur root. Ainsi, ce pod fonctionnerait en tant que root, ce qui est risqué du point de vue de la sécurité car certaines vulnérabilités sont plus faciles à exploiter (ou dégénèrent en attaques plus importantes) lorsque les processus à l’intérieur d’un conteneur ont des privilèges root.

Si vous adoptez une approche de sécurité décalée vers la gauche, vous pouvez analyser votre fichier de déploiement d’espace avant de l’exécuter afin de détecter rapidement le problème, puis le résoudre simplement en modifiant la configuration runAsUser. Mais si vous n’analysez pas votre déploiement au début du cycle de vie du développement, vous ne saurez probablement pas que vous exécutez un conteneur en tant que root tant qu’il n’est pas déjà en production. De plus, détecter le problème à ce stade serait beaucoup plus difficile, car il n’y a pas de moyen aisé de déterminer l’UID utilisé à l’intérieur d’un conteneur, de l’extérieur.

Comment déplacer la sécurité vers la gauche

La sécurité shift-left est une stratégie, pas un outil ou une pratique spécifique. Elle peut être mise en œuvre de plusieurs façons.

En général, cependant, la mise en pratique de la sécurité shift-left implique le déploiement d’outils de sécurité capables de tester et de valider la sécurité du code lorsqu’il circule dans le pipeline de mise à disposition d’applications. Voici des exemples d'outils clés :

• Analyse de Composition Logicielle (SCA) : Les outils SCA découvrent des vulnérabilités dans le code source, telles que des dépendances open source non sécurisées.
• Tests statiques de sécurité des applications (SAST, Static Application Security Testing) : Les outils SAST peuvent également identifier certains risques dans le code source, comme le manque de validation des entrées.
• Tests Dynamiques de Sécurité des Applications (DAST, Dynamic Application Security Testing) : Les tests dynamiques sont utiles pour découvrir les risques de sécurité après la compilation et l’exécution des applications dans un environnement de test.

Ces outils peuvent être déployés indépendamment. Mais l’approche la plus simple consiste à tirer parti d’une plate-forme d’automatisation de la sécurité SDLC qui protège automatiquement les applications à chaque étape du cycle de vie, garantissant ainsi que les équipes DevOps peuvent détecter autant de risques que possible, le plus tôt possible.

La détection précoce est essentielle

L’évolution de la sécurité vers la gauche ne protégera pas automatiquement les organisations contre les nombreuses menaces et risques de cybersécurité auxquels elles sont aujourd’hui confrontées. Mais elle facilitera la détection de ces menaces et de ces risques avant qu’ils ne deviennent des vecteurs d’attaques contre les charges de travail de production. De plus, la détection précoce permet également d’atténuer plus rapidement et plus facilement les problèmes de sécurité. C’est une situation gagnant-gagnant-gagnant pour les développeurs, les équipes de sécurité et l’entreprise.