Pourquoi DevOps mais pas DevSecOps ?

Pourquoi DevOps mais pas DevSecOps ?

DevOps est une pratique qui vise principalement à accompagner les méthodologies agiles pour le cycle de vie du développement logiciel (SDLC). L’objectif principal est de fournir des logiciels dans des cycles de publication courts et efficaces, ainsi que de rationaliser et d’automatiser autant que possible le processus de développement et le processus de livraison de logiciels. Il est difficile d’imaginer un flux de travail de développement logiciel agile sans une automatisation poussée des processus de construction et de test, c’est-à-dire sans les pipelines d’intégration continue/livraison continue (CI/CD) qui constituent la base de DevSecOps.

Il ne serait pas possible d’avoir DevOps si les processus de construction et de test qui font partie du cycle de développement restaient manuels. Cependant, dans l’approche originale de DevOps, personne ne semble avoir pensé à l’intégration de la sécurité. Quelle pourrait être la raison?

Un pipeline DevOps CI/CD typique comprend les étapes suivantes :

Fournir un environnement préconfiguré (par exemple, un conteneur Docker via Kubernetes)
Construire l’application (ou une API/microservice)
Déploiement de l’application dans l’environnement préconfiguré
Exécution de tests automatisés sur l’application compilée pour s’assurer que sa fonctionnalité répond aux exigences (par exemple, tests Selenium UI)
Il semble logique d’ajouter une étape supplémentaire à ce pipeline :

Exécution de tests de sécurité automatisés sur l’application compilée pour s’assurer qu’elle répond aux exigences de sécurité.
Mais ce n’est pas le cas dans la plupart des environnements DevOps – c’est pourquoi ce ne sont pas des processus DevSecOps

Raison 1. Manque de sensibilisation à la sécurité


C’est une pensée effrayante, mais nous pensons que de nombreuses organisations n’incluent pas de contrôles de sécurité dans leurs processus DevOps simplement parce qu’elles ne pensent pas que la fourniture de logiciels sécurisés soit suffisamment importante.

Même dans le monde de la transformation numérique, de nombreuses organisations ont une connaissance limitée de la cybersécurité et la perçoivent sous l’angle du battage médiatique autour des ransomwares et du phishing. S’il est vrai que les ransomwares et le phishing sont des menaces de sécurité majeures et que vous ne pouvez rien faire dans les pipelines de développement pour atténuer ces risques de sécurité, ce n’est pas tout ce qui concerne la sécurité.

Les organisations ne se rendent parfois pas compte qu’en plus de l’ingénierie sociale, les hackers black-hat peuvent très facilement exploiter une vulnérabilité dans une application pour accéder à des données sensibles ou même prendre le contrôle de l’application ou de l’ensemble du serveur. Cela peut conduire à d’autres attaques, y compris le redoutable ransomware. Si un pirate informatique est capable, par exemple, d’exécuter du code à distance à l’aide de votre application Web native du cloud et d’installer un shell inversé, il est capable d’exécuter des commandes sur un serveur et, disons, de déployer un rançongiciel qui se propagera à votre tout l’environnement et faire des ravages. Et dans un tel cas, la cause principale est un manque de sécurité des applications et aucune protection contre les ransomwares et le phishing ne vous aidera.

Par conséquent, la première et la plus importante étape vers DevSecOps consiste à embarquer tout le monde et à promouvoir la responsabilité partagée, en particulier parmi les décideurs. Ils doivent réaliser que le code sécurisé est de la plus haute importance. Ils doivent vous accompagner dans votre parcours DevSecOps.

Raison 2. Manque de compréhension de la sécurité


Les équipes de sécurité travaillent souvent en silos simplement parce que leur travail n’est pas compris du tout. Le terme sécurité englobe une portée incroyablement large. Sécuriser votre organisation en mettant en œuvre des procédures de surveillance de la conformité et en sensibilisant les gens est très différent de la sécurisation de vos applications via des tests de pénétration approfondis. Cela demande des compétences complètement différentes. Et même des domaines apparemment liés tels que la sécurité du réseau et la sécurité des applications sont complètement différents, exigent des compétences et des outils différents et une approche différente des politiques de sécurité.

Le manque de compréhension conduit à ce que les tâches de sécurité soient perçues comme « cette chose que nous vérifions à la fin » au lieu de « cette chose que nous vérifions au fur et à mesure que nous développons et livrons ». De nombreux professionnels de la sécurité dans les organisations actuelles ont une formation en sécurité réseau et ne comprennent pas vraiment le concept de sécurité des applications. Ils ne considèrent pas DevSecOps comme réalisable simplement parce qu’ils pensent principalement à la sécurité du réseau – pas quelque chose que vous devez prendre en compte lors du développement d’applications.

Encore une fois, c’est une pensée effrayante que de nombreuses organisations préfèrent rester dans l’ignorance en matière de sécurité, sans penser à la cause principale de tant de failles de sécurité majeures. Prenons l’exemple du célèbre piratage Capital One 2019.

Raison 3. Manque de connaissances en automatisation de la sécurité


La sécurité de l’information est encore souvent perçue comme un processus manuel. De nombreuses organisations pensent que la partie essentielle du test de sécurité d’une application est le test d’intrusion manuel. Le travail des testeurs d’intrusion est souvent associé à des outils purement manuels qui les aident, par exemple, à mettre en cache les requêtes et à envoyer des charges utiles.

Cependant, les services de sécurité logicielle sont allés bien au-delà des tests manuels. Tout comme les ingénieurs en sécurité réseau n’envoient pas de commandes manuelles via Telnet mais utilisent des scanners automatisés, les ingénieurs en sécurité des applications modernes utilisent des outils automatisés pour découvrir les problèmes les plus courants. C’est le choix logique pour eux, car ils peuvent alors se concentrer sur l’exploration plus approfondie des vulnérabilités avancées, ce qui, pour la plupart des ingénieurs en sécurité, est également beaucoup plus satisfaisant que de rechercher une autre injection SQL de base.

Tout comme les tests automatisés de l’interface utilisateur ont presque complètement remplacé les tests manuels, sauf dans des cas particuliers, l’analyse automatisée des vulnérabilités a remplacé la majorité des tests de pénétration manuels – mais les tests de pénétration sont toujours effectués pour les problèmes qui ne peuvent pas être découverts automatiquement. Tester manuellement la posture de sécurité dans un silo est à peu près aussi moderne que de cliquer manuellement sur l’interface utilisateur de l’application au lieu d’utiliser Selenium.

Raison 4. Manque de confiance dans les outils de sécurité


Même si une organisation apprécie l’importance de la sécurité des applications et que les décideurs sont pleinement intégrés, il reste un problème qui entrave DevSecOps : les capacités limitées de certains des outils.

Imaginez un pipeline DevOps avec des tests automatisés qui échouent souvent même si l’application testée est en fait correcte. Imaginez combien de temps il faudrait aux développeurs pour retourner dans l’environnement de développement, revoir le code de l’application, s’assurer que tout va bien, puis contacter l’équipe de développement des tests pour corriger les tests automatisés afin qu’ils n’échouent pas (ou simplement, si possible, marquez manuellement les tests comme réussis). Et imaginez la frustration si cela continue à se produire.

Pour les tests unitaires automatisés, ce n’est pas une situation courante. Cependant, dans le monde de la sécurité des applications, où les tests sont souvent effectués à l’aide d’outils d’analyse de code (SAST – test de sécurité des applications statiques), ce genre de chose se produit tous les jours. Et le développeur aux prises avec un faux positif ne peut pas simplement demander que l’outil soit corrigé par l’équipe de développement du test car l’outil est généralement une application tierce.

C’est pourquoi les tentatives d’introduction des pratiques DevSecOps ont tendance à échouer si souvent. Les membres de l’équipe DevOps peuvent initialement être enthousiastes à l’idée d’introduire des tests de sécurité automatisés dans les pipelines, mais ils les implémentent ensuite à l’aide de l’un des nombreux outils d’analyse statique commercialisés comme le meilleur choix pour DevSecOps et découvrent que cela ne fonctionne pas car le nombre de faux positifs n’est tout simplement pas tolérable. Et plus l’organisation est grande, plus la déception est grande – et plus le risque que DevSecOps ne soit plus envisagé est grand.

Raison 5. Manque de compréhension des outils


En partie par manque de sensibilisation (voir Raison 3), les équipes DevOps se concentrent souvent sur SAST comme outil DevSecOps de choix et ne considèrent même pas DAST comme quelque chose qui peut être inclus dans les pipelines CI/CD. Et la raison en est simple : la plupart des outils DAST ne sont pas adaptés à DevSecOps simplement parce qu’ils n’offrent pas suffisamment d’automatisation.

Les outils DAST sont encore perçus comme les simples scanners à exécution unique qu’ils étaient il y a quelques années à peine et qui sont encore souvent développés dans l’écosystème open source. L’utilisation traditionnelle d’un outil DAST consistait à exécuter une analyse de sécurité sur une application d’exécution qui a été déployée dans un environnement intermédiaire ou un environnement de production – et qui n’est évidemment pas agile du tout. Imaginez simplement ce qui se passe lorsque l’analyse trouve une faille de sécurité critique – pour poursuivre la correction, l’application doit retourner à la planche à dessin et tout le cycle agile qu’elle a traversé doit être répété.

Un ensemble de solutions métiers, des services et de l’innovation pour optimiser votre entreprise Webblue_heart,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur  and Mobileyellow_heart,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur

,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur
,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur
,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur
,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur
,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur
,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur ,  Solution ERP, website ecommerce, mobile developpeur

 515 total views,  2 views today

Add a Comment

Your email address will not be published.