Technologies DevSecOps
Écrit par
0 minutes de lecture
Les technologies permettent à vos équipes de mettre en œuvre efficacement les processus DevSecOps. Quand on pense au DevSecOps et au CI/CD, les outils viennent souvent à l’esprit en premier. La capacité à intégrer et à automatiser différents processus de développement, de sécurité et d’exploitation est au cœur d’une mise en œuvre DevSecOps réussie. Voici un ensemble de technologies que les organisations doivent prendre en compte pour déployer avec succès une méthodologie DevSecOps à l’échelle de l’entreprise.
Dépôt de code source
Le dépôt de code source est au cœur de presque tous les environnements de développement de la planète. Dans une démarche DevSecOps, il s’agit de la technologie essentielle à laquelle s’intègrent la plupart des autres technologies du pipeline. Lorsqu’une organisation évalue sa capacité à adopter le paradigme DevSecOps, elle doit tenir compte de la capacité du dépôt à s’intégrer à d’autres technologies essentielles.
À mesure que de plus en plus d’aspects de l’environnement applicatif sont définis dans le code, la sécurité du dépôt devient primordiale. Il faut mettre en œuvre les bonnes pratiques en matière d’accès utilisateur, de configuration des dépôts, etc. L’exposition du dépôt à des personnes non autorisées ou qui n’en ont pas besoin peut entraîner des risques importants.
À la une des technologies : bonnes pratiques pour les dépôts Bitbucket
Bitbucket est l’un des dépôts les plus populaires au sein des organisations DevSecOps. Son interface web pratique et son intégration à un large éventail d’autres technologies en font un choix idéal pour répondre aux besoins d’automatisation et d’orchestration du DevSecOps. Toutefois, cette popularité s’accompagne d’une hausse des failles de sécurité, le plus souvent causées par des configurations ou une utilisation non sécurisées des dépôts. Pour vous prémunir contre ces problèmes, appliquez les bonnes pratiques suivantes :
Ne stockez jamais d’identifiants sous forme de code ou de configuration dans Bitbucket
Appliquez systématiquement les pratiques de gestion des secrets à tous les dépôts stockés dans Bitbucket. Vous pouvez notamment utiliser git-secrets, réaliser des audits réguliers des secrets et recourir à un gestionnaire de secrets réputé.Supprimez les données sensibles
Si des données sensibles se retrouvent dans un dépôt, invalidez tous les jetons et mots de passe exposés, supprimez les informations et effacez l’historique Git, puis évaluez les conséquences de la fuite des informations privées.Contrôlez strictement les accès
Les failles de sécurité dans les dépôts sont souvent dues à des erreurs humaines. Pour atténuer ce risque, adoptez une gestion rigoureuse des utilisateurs et des mécanismes de contrôle d’accès.Ajoutez un fichier SECURITY.md
Vous devez inclure un fichier SECURITY.md présentant les informations relatives à la sécurité de votre projet. Il doit préciser la politique de divulgation, la politique de mise à jour de sécurité, la configuration liée à la sécurité, les lacunes de sécurité connues et les améliorations prévues.Validez les applications Bitbucket
Ces applications, développées par des tiers, doivent être vérifiées en matière de droits d’accès, de crédibilité de leur auteur ou organisation et de niveau de sécurité global.Intégrez des conseils de sécurité au workflow grâce à Code Insights
Analysez toutes les pull requests ouvertes avec Bitbucket Code Insights. Vous pourrez ainsi détecter les nouvelles vulnérabilités susceptibles d’être introduites par la PR.Ajoutez des tests de sécurité aux PR
Utilisez les hooks Bitbucket pour vérifier que les PR n’introduisent pas de nouvelles vulnérabilités.Ajoutez des tests de sécurité aux pipes Bitbucket
Intégrez des pipes d’analyse de sécurité au flux CI/CD afin de garantir que les pipelines automatisés n’introduisent aucune régression de sécurité.Envisagez Bitbucket Server
Pour réduire considérablement la surface d’attaque d’un dépôt, Bitbucket Server permet de l’héberger sur site.Renouvelez les clés SSH et les jetons d’accès personnels
L’accès à Bitbucket se fait généralement à l’aide de clés SSH ou de jetons utilisateur personnels. Le renouvellement régulier de ces clés peut réduire le risque qu’une fuite permette à des personnes malveillantes d’accéder à votre dépôt.
Pour en savoir plus, consultez notre blog et notre aide-mémoire : https://snyk.io/blog/cheat-sheet-10-bitbucket-security-best-practices/
Gestion de la configuration
La définition et le maintien de configurations cohérentes pour l’infrastructure, les logiciels système et même les applications de support mobilisaient traditionnellement beaucoup de ressources. Pour mettre en place un véritable modèle DevSecOps, cette gestion de la configuration doit être automatisée et intégrée à l’ensemble du cycle de vie du développement. La part croissante des composants définis sous forme de code facilite cette démarche.
L’intégration et l’automatisation de la gestion de la configuration présentent plusieurs avantages importants. Tout d’abord, elles permettent de visualiser facilement les changements apportés à l’environnement et d’en rendre compte. Sans remplacer les pratiques de gestion du changement, elles garantissent un suivi adéquat. Cette automatisation permet également un versionnage précis, qui relie les changements apportés à l’infrastructure et aux logiciels de support aux versions du code correspondantes. Cela aide à éviter les problèmes causés par des configurations incompatibles. Enfin, en automatisant la gestion de la configuration, les organisations assurent également la cohérence de l’environnement. Elles peuvent ainsi plus facilement détecter les menaces et réagir aux incidents de sécurité.
Lorsqu’une organisation se prépare à automatiser la gestion de la configuration, elle doit prendre en compte quelques éléments essentiels.
Orchestration
L’un des grands avantages de l’intégration de la gestion automatisée de la configuration à l’infrastructure as code est la possibilité d’automatiser le déploiement de l’infrastructure selon les besoins. Que l’environnement repose sur des machines virtuelles, le cloud ou des conteneurs, des solutions permettent d’orchestrer dynamiquement le déploiement de l’infrastructure. Dans leur transition vers un modèle DevSecOps, les organisations doivent comprendre la portée de ces déploiements et choisir les outils adaptés à leurs applications.
Dans le rapport 2020 sur l’état de la sécurité de l’open source, 44 % des personnes interrogées ont indiqué utiliser Kubernetes, mais les pratiques de sécurité courantes ne sont pas largement mises en œuvre.
Renforcement de la sécurité des hôtes
Le renforcement de la sécurité des hôtes n’est pas une pratique nouvelle. Pourtant, s’il était plus répandu, moins de services et d’applications seraient inutilement exposés au public. Avec l’apparition d’infrastructures orchestrées très dynamiques, cette pratique devient encore plus essentielle. De nombreux incidents de sécurité sont directement liés à une surface d’attaque générique qui permet aux outils d’attaque automatisés de réussir les attaques les plus élémentaires. Les bonnes pratiques et méthodes de renforcement de la sécurité de la plupart des technologies sont suffisamment éprouvées pour être facilement intégrées à la création de modèles, afin de réduire la surface d’attaque et de renforcer le modèle de confiance. Ce dernier peut être codifié sous forme de métadonnées, puis traité par le pipeline CI et utilisé par d’autres processus, comme l’application des correctifs.
À la une des technologies : sécuriser les images Docker
À mesure que les organisations adoptent des environnements cloud natifs, l’utilisation des conteneurs a connu une croissance exponentielle. Les images Docker sont devenues courantes, tout comme les compromissions liées à des images de conteneurs non sécurisées. Pour garantir la sécurité des images Docker, appliquez les bonnes pratiques suivantes :
Réduisez au minimum la taille des images de conteneurs
Choisissez des images qui contiennent moins de bibliothèques et d’outils système afin de réduire la surface d’attaque globale. Dans la mesure du possible, privilégiez les images basées sur Alpine aux images complètes d’un système d’exploitation.Limitez les privilèges utilisateur
Créez dans l’image un utilisateur et un groupe dédiés, disposant des autorisations minimales nécessaires à l’exécution de l’application, puis utilisez ce même utilisateur pour lancer le processus.Signez et vérifiez les images de conteneurs
Signez numériquement les images lors de leur création, puis vérifiez leur fiabilité et leur authenticité lors de leur récupération auprès d’un éditeur.Surveillez régulièrement les vulnérabilités open source dans les images
Analysez les images Docker à la recherche de vulnérabilités connues et intégrez ces analyses à l’environnement d’intégration continue.Protégez les images contre les fuites d’informations
Des jetons, des clés et d’autres secrets restent souvent exposés dans les images au moment de leur création. Pour éviter ce problème, utilisez des builds à plusieurs étapes et la fonctionnalité Docker secrets afin de monter des fichiers sensibles sans les mettre en cache. Un fichier .dockerignore peut également éviter que des instructions COPY n’intègrent des fichiers sensibles du contexte de build.Utilisez des tags fixes pour garantir l’immutabilité
De nouvelles versions d’images peuvent être publiées avec les mêmes tags, ce qui risque de produire des images incohérentes pendant les builds. Pour éviter cela, utilisez des tags descriptifs qui indiquent la version et le système d’exploitation, ou identifiez l’image à l’aide d’un hachage de son contenu.Utilisez COPY plutôt que ADD
L’instruction ADD peut exposer à plusieurs vecteurs d’attaque, notamment les attaques de l’homme du milieu et Zip Slip. Dans la mesure du possible, utilisez plutôt COPY.Utilisez des étiquettes pour les métadonnées
L’ajout de métadonnées aux étiquettes des images peut fournir des informations utiles aux utilisateurs. Il est également recommandé d’y inclure des informations sur la politique de divulgation responsable.Utilisez des builds à plusieurs étapes pour réduire la taille des images
Utilisez des builds à plusieurs étapes pour créer des images plus petites et plus épurées, et ainsi réduire la surface d’attaque liée aux dépendances intégrées à l’image Docker.Utilisez un linter
Un outil d’analyse statique du code peut faire respecter les bonnes pratiques pour les Dockerfiles et détecter les problèmes potentiels.
Pour en savoir plus, consultez notre blog et notre aide-mémoire : https://snyk.io/blog/10-docker-image-security-best-practices/
Étant donné que ces métadonnées sont définies dans le code et généralement stockées dans un dépôt avec le reste du code de l’application, il convient également de mettre en place des outils automatisés capables de détecter les vulnérabilités dans les configurations ou les écarts par rapport aux bonnes pratiques de renforcement de la sécurité. Cela garantit que la sécurité est intégrée dès la conception et le déploiement de l’infrastructure, sans entraver le développement.
CI/CD pour l’application des correctifs
Une fois les métadonnées associées à chaque ressource, l’organisation peut les exploiter pour appliquer des correctifs au niveau du CI/CD. Les flux de renseignement sur les menaces et de gestion des vulnérabilités peuvent être comparés à la pile logicielle déployée pour repérer les correspondances dans les modèles et mettre les éléments concernés en file d’attente pour le déploiement. Il n’est alors plus nécessaire d’appliquer les correctifs sur les systèmes en production, ce qui limite les interruptions de service. Cette approche permet également d’évaluer l’exposition aux risques presque en temps réel.
Pratiques de codage sécurisé
Toutes les normes de codage sécurisé doivent être régulièrement vérifiées au regard des nouvelles recommandations de sécurité. Chaque modification du code doit être vérifiée et testée selon ces recommandations : aucune modification n’est trop minime pour être ignorée. Cette démarche n’est pas simple, et les avantages de ces pratiques ne doivent pas être sous-estimés : ils ne se limitent pas au nombre de changements effectués au cours du cycle de développement.
L’OWASP Top 10 constitue un excellent point de départ pour cet examen. Transformez les changements de code en tests d’assurance qualité et tirez parti des tests automatisés pour fournir rapidement des retours aux équipes de développement. L’OWASP ASVS et ses 19 domaines de vérification se prêtent également très bien à la conception de logiciels sécurisés.
Face à l’évolution toujours plus rapide des techniques et frameworks de développement logiciel, le développement guidé par les attaques propose une méthode permettant aux développeurs d’apprendre en parallèle les outils, techniques et procédures du développement logiciel et de la sécurité des applications.
Évaluation au niveau applicatif
L’évaluation automatisée des applications pour détecter les vulnérabilités de sécurité est un aspect essentiel du DevSecOps. Elle permet aux entreprises de bien comprendre leur niveau de risque et de corriger les vulnérabilités avant qu’elles ne soient exploitées par des attaquants. Les solutions suivantes peuvent contribuer à renforcer la sécurité d’un environnement DevSecOps :
Analyse du code source
L’analyse du code source doit être assurée par la mise en œuvre d’outils de tests statiques de sécurité des applications (SAST). Le SAST permet d’analyser le dépôt de code source, généralement la branche principale, afin d’identifier les vulnérabilités et d’effectuer une analyse de la composition logicielle. Les outils SAST doivent être intégrés aux processus post-commit afin que tout nouveau code soit analysé de manière proactive à la recherche de vulnérabilités. L’intégration d’un outil SAST permet de corriger les vulnérabilités plus tôt dans le cycle de développement logiciel et de réduire les risques et l’exposition des applications.
Outil d’analyse dynamique des applications (DAST)
Les outils d’analyse dynamique des applications sont conçus pour analyser les sites web de préproduction et de production en cours d’exécution, examiner les champs de saisie, les formulaires et de nombreux autres aspects de l’application web afin d’y détecter des vulnérabilités. Ces outils doivent être intégrés au pipeline au fur et à mesure du déploiement des versions dans les différents environnements.
Intégration du SAST dans l’IDE
L’intégration de plugins d’analyse statique du code dans l’IDE permet aux développeurs de recevoir presque en temps réel des alertes sur les pratiques de programmation non sécurisées, directement dans leur environnement de développement intégré. Ils peuvent ainsi corriger rapidement les vulnérabilités sans quitter leur environnement de développement.
Analyse des binaires
Tous les binaires doivent être analysés pour détecter les problèmes de sécurité répertoriés dans la checklist de codage, puis signés numériquement. La signature numérique est traitée comme une métadonnée. Par exemple, dans le CI, seuls les binaires signés peuvent être utilisés et déployés, ce qui garantit le niveau de validation de sécurité requis sans devoir attendre que l’équipe de sécurité soit disponible.
Audit avant déploiement
L’utilisation d’un modèle prédéfini pour créer les ressources est essentielle pour garantir le niveau de sécurité souhaité, mais elle doit être complétée par des analyses des hôtes. La plupart des scanners de sécurité proposent désormais un module de conformité qui permet d’importer votre modèle.
Audit après déploiement
Une fois instanciés, ces modèles prédéfinis peuvent être comparés aux résultats des analyses préalables au déploiement afin de repérer toute différence susceptible d’introduire des menaces pour la sécurité. Pour automatiser cette opération, il convient de mettre en place une intégration via une API.
Gestion automatisée des vulnérabilités
Les solutions de gestion des vulnérabilités doivent être intégrées via une API aux plateformes d’analyse de l’infrastructure et des applications web. Cette intégration garantit à l’organisation que toutes les vulnérabilités découvertes font l’objet d’un suivi. De plus, dans les environnements DevSecOps matures, elle peut établir en temps réel une corrélation entre les menaces actives et les vulnérabilités identifiées. Cela permet de repérer :
Les ressources exposées à des exploits connus.
Toute nouvelle menace susceptible de représenter un risque immédiat pour l’entreprise.
Les processus de gestion des vulnérabilités doivent également être intégrés au système de suivi des bugs des développeurs. Ainsi, des tickets peuvent être créés dès la découverte de vulnérabilités, ce qui accélère leur correction.
Analyse automatisée de conformité
La conformité peut être assurée grâce à des évaluations automatisées des configurations de sécurité, qui permettent de réduire les risques et de maintenir une conformité continue. Cette approche contribue à réduire les coûts de conformité en diminuant le temps et les efforts nécessaires à l’évaluation des systèmes. Elle permet également de partager les données de conformité avec les outils GRC de l’entreprise et les applications du service d’assistance, afin de donner une visibilité sur l’état de conformité.
Gestion des secrets
Dans le domaine de la sécurité de l’information, les « secrets » désignent toutes les informations confidentielles dont une équipe a besoin, par exemple les identifiants d’une base de données ou d’une API tierce. Pour établir une connexion de confiance, il faut des identifiants, un certificat ou un jeton d’API. Malgré ces précautions, la gestion des secrets peut s’avérer complexe et être source d’erreurs, voire de failles de sécurité.
Pour faciliter la gestion des secrets, on peut notamment définir une constante dans le code source ou stocker les secrets dans un fichier de configuration exclu du contrôle de version. Ces techniques résolvent certains problèmes, mais en créent d’autres, notamment pour la rotation des clés.
L’approche idéale consiste à utiliser un coffre de mots de passe partagé, chiffré et synchronisé, que chaque membre de l’équipe peut déchiffrer individuellement, sans mot de passe partagé. Deux outils permettent d’y parvenir : GPG (The GNU Privacy Guard) et Pass. GPG permet de mettre en œuvre une infrastructure à clés publiques et est souvent utilisé pour le chiffrement des e-mails. Toutefois, GPG peut être complexe à utiliser. Pass, que ses développeurs présentent comme le « gestionnaire de mots de passe Unix standard », offre une interface pratique à GPG. Pass permet de chiffrer des informations secrètes à l’aide d’une ou plusieurs clés privées. Toutes les informations chiffrées sont stockées sous forme de fichiers plats dans un répertoire pouvant être partagé au moyen du contrôle de version. Ces outils permettent de constituer un ensemble d’informations chiffrées et partageables, tout en préservant leur sécurité.
Une gestion efficace des secrets, à l’aide d’outils comme GPG et Pass, est essentielle au DevSecOps. Elle couvre l’ensemble de la chaîne, de la demande à la création et à la distribution, afin d’assurer la sécurité à chaque étape.