DevSecOps Archives - Le Concept Marketing

Le DevOps est une question d'automatisation. Les processus automatisés d'intégration et de livraison continues permettent aux développeurs de coder davantage et de consacrer moins de temps aux déploiements. Cela permet aux équipes de publier du code plus souvent - parfois plusieurs versions en une seule journée. Si l'adoption de DevOps présente des avantages pour les équipes de développement, ces processus automatisés introduisent également de nouveaux risques. Même si DevOps accélère le développement de logiciels, la sécurité n'a pas encore tout à fait rattrapé son retard. Jusqu'à récemment, la plupart des contrôles de sécurité étaient manuels et intervenaient une fois le développement du logiciel terminé. DevSecOps espère changer cela en automatisant les processus de sécurité et en les rendant aussi rapides que le reste de DevOps. 👉🏼 Lecture complémentaire : QU'EST-CE QUE LE DEVSECOPS ? DevSecOps intègre la sécurité dans les flux de travail DevOps existants en transférant les préoccupations de sécurité à un niveau plus élevé du processus de développement logiciel et en automatisant les contrôles de sécurité. Il s'agit d'un concept relativement nouveau, car la sécurité n'a pas encore tout à fait rattrapé la vitesse de DevOps. Dans le cadre de DevSecOps, les développeurs sont encouragés à s'intéresser aux questions de sécurité tout au long de la durée de vie d'un projet, en commençant par la phase de conception et en continuant jusqu'à la publication du code. "L'autre aspect de DevSecOps, en plus de permettre à la sécurité d'évoluer à la vitesse de DevOps, est de s'assurer que la vitesse de DevOps n'augmente pas la surface d'attaque ou n'a pas un effet négatif sur le paysage des risques", a déclaré Daniel Krivelevich, directeur de la technologie chez Cider Security, qui crée des outils de sécurité pour les processus CI/CD. Selon Ada Lin, ingénieur informatique chez Teleport, société spécialisée dans l'infrastructure cloud à confiance zéro, un bon DevSecOps ne se résume pas à l'ajout d'étapes de sécurité individuelles dans le processus DevOps. Il s'agit plutôt d'un changement d'attitude et d'état d'esprit de la part de toute l'entreprise, mais surtout des développeurs. "Il s'agit de mettre l'accent sur le déplacement vers la gauche, d'encourager les ingénieurs à placer la sécurité au début du processus plutôt que de la traiter comme une réflexion après coup", explique Ada Lin. L'histoire de DevSecOps : Ces dernières années, la sécurité des applications est devenue une préoccupation urgente tant pour le grand public que pour la communauté technologique. Selon M. Krivelevich, les entreprises étaient auparavant beaucoup moins préoccupées par la sécurité, qu'elles considéraient plutôt comme une "nuisance", surtout si on la compare aux investissements qu'elles consacraient à l'accélération du processus de développement des logiciels. La sécurité était considérée comme quelque chose que les entreprises devaient faire pour éviter des conséquences négatives, comme la mauvaise publicité associée au piratage. Mais comme de plus en plus de clients recherchent activement des produits sécurisés, les entreprises ont pris conscience de l'avantage qu'il y a à ne pas se contenter de construire un produit "suffisamment sûr", mais plutôt le produit le plus sûr possible. "Si mon produit est plus sûr que celui de mes concurrents, c'est utile pour mon entreprise", a déclaré M. Krivelevich. "En effet, les gens se soucient de la sécurité des produits qu'ils achètent. Cette évolution a conduit à la création de DevSecOps, qui intègre étroitement les questions de sécurité dans le flux de travail DevOps. Alors que DevOps consiste à créer des processus CI/CD et à libérer les développeurs de logiciels des configurations manuelles, DevSecOps vise à apporter ces mêmes avantages à la sécurité. Au fur et à mesure que les entreprises adoptent ces changements, le rôle des développeurs évolue également. Voici quelques compétences dont les développeurs auront besoin pour aider à transformer les processus DevOps de leurs équipes en processus DevSecOps réussis. Remue-méninges sur les problèmes de sécurité lors de l'idéation d'un projet La réflexion sur la sécurité commence tôt. En général, cela signifie que la phase de conception et d'idéation d'un projet a lieu avant que le moindre code ne soit écrit. Chez Teleport, les équipes suivent un processus connu sous le nom de "demande de discussion" afin d'évaluer les problèmes potentiels que les membres de l'équipe peuvent prévoir pour un projet à venir, a déclaré M. Lin. Les ingénieurs de tous niveaux examinent un document de projet, qui traite de l'objectif et de la portée du projet, et ouvrent la voie à la discussion. "Cela augmente les chances que quelqu'un reconnaisse qu'il y a un problème de sécurité qui devrait être abordé", a déclaré M. Lin. Ces discussions permettent aux développeurs de contribuer aux premières étapes des projets, qui n'impliquaient auparavant que les chefs de projet et les responsables techniques. Pour donner des conseils sur la faisabilité et le travail nécessaire à la sécurisation de nouvelles fonctionnalités potentielles, les développeurs devront s'appuyer sur leur connaissance approfondie des technologies et des produits de l'entreprise. Les points de vue des développeurs sont particulièrement utiles parce qu'ils fournissent des évaluations de bas niveau des questions techniques, y compris des questions de sécurité potentielles qui nécessitent une attention particulière pour que les projets soient couronnés de succès. Par exemple, si un client souhaite ajouter à son produit un contrôle d'accès basé sur les rôles, les développeurs peuvent discuter des avantages et des inconvénients du système de sécurité avec leur équipe afin d'évaluer les différentes options de mise en œuvre. Choisir le bon scanner de code : Les outils d'analyse de code sont un élément important du DevSecOps. Ils fonctionnent automatiquement et peuvent détecter des problèmes de sécurité bien connus dans une base de code. Ces outils, également connus sous le nom d'outils de test statique de la sécurité des applications, sont efficaces pour trouver rapidement de mauvais schémas de codage susceptibles de provoquer des vulnérabilités dans les applications. "Si vous utilisez plus d'outils SAST, vous pourrez détecter un plus grand nombre de problèmes de sécurité avant que le code ne soit mis en production", a déclaré M. Lin. Les développeurs doivent garder à l'esprit que ces outils ne sont pas universels - différents langages de programmation peuvent nécessiter différents outils SAST qui répondent aux variations subtiles entre les besoins de sécurité des langages. "Une partie du grand changement qu'a connu l'écosystème de l'ingénierie est qu'il y a une plus grande diversité en ce qui concerne les technologies utilisées pour le développement", a déclaré M. Krivelevich. "Cela crée un écosystème très dynamique de langages et de cadres utilisés pour le développement. Chacun de ces langages et cadres est susceptible de contenir des failles de sécurité et des vulnérabilités". Les développeurs doivent être impliqués dans le processus de recherche des outils SAST adaptés à la pile technologique de leur entreprise, ainsi que dans le contrôle de l'efficacité de ces outils pour leurs langages et applications. Par exemple, les développeurs peuvent vérifier si un outil signale trop de faux positifs, comme des avertissements sur des vulnérabilités d'injection SQL là où elles n'existent pas. Un nombre excessif de faux positifs fait perdre du temps à l'équipe, car chaque avertissement doit être vérifié. Les développeurs peuvent comparer les outils pour voir lequel est le plus précis avec leur langage de programmation et leurs applications. Corriger rapidement les problèmes de sécurité découverts par DevSecOps : Les développeurs sont responsables du suivi et de la correction des vulnérabilités de sécurité mises au jour par le processus DevSecOps. Même avec l'ancien flux de travail DevOps, les développeurs étaient déjà chargés d'écrire des tests et de corriger le code lorsque les tests échouaient - soit pendant le développement, soit pendant la phase de tests automatisés de DevOps. "La sécurité fait également partie de cette catégorie de tests que les développeurs exécutent sur le code en cours de développement", explique M. Krivelevich. "Les développeurs doivent y remédier avant d'envoyer le code en production. Le suivi des problèmes fait également partie de la boucle de rétroaction qui permet aux développeurs de mieux comprendre si leurs outils d'analyse automatique du code fonctionnent bien et s'ils doivent passer à d'autres outils. Les scanners sont-ils en mesure de détecter de nombreux bogues non détectés ? Ou signalent-ils surtout des problèmes qui n'en sont pas ? Si c'est le cas, ces outils risquent d'empiéter sur le temps de développement. "Il est très important d'intégrer ces scanners dans de manière efficace et efficiente, car nous ne voulons pas que la sécurité ralentisse l'ingénierie", a déclaré M. Krivelevich. "C'est pourquoi nous devons disposer de bons scanners adaptés aux langages et frameworks spécifiques utilisés, qui ne créent pas beaucoup de résultats faussement positifs. Garder un œil sur les dépendances : Selon M. Lin, les développeurs doivent prêter attention à toutes les dépendances nouvellement ajoutées aux projets. En effet, les dépendances tierces peuvent facilement introduire des failles de sécurité dans les bases de code. La vulnérabilité de Log4j, la bibliothèque de journalisation de Java, par exemple, a affecté d'innombrables entreprises et organisations lorsqu'elle a été découverte en novembre dernier et a forcé les développeurs à corriger et à publier rapidement le code pour combler la faille de sécurité. Les développeurs doivent être très prudents lorsqu'ils utilisent des dépendances, car elles offrent aux pirates davantage de possibilités d'attaquer le code. "Cela augmente votre surface d'attaque, essentiellement", a déclaré M. Lin. "Il y a plus de problèmes de sécurité à prendre en compte lorsqu'une nouvelle bibliothèque est ajoutée. Mais les dépendances à l'égard de bibliothèques tierces et open-source font partie de la vie du développement logiciel de nos jours, et la meilleure réponse consiste donc à rester à l'affût des nouvelles concernant les vulnérabilités et à les corriger le plus rapidement possible. Des questions telles que "Tous les éléments dont dépend mon logiciel critique sont-ils des composants durables ?" méritent également notre attention", a déclaré Christoph Gӧrn, responsable de l'ingénierie chez Red Hat. "À mesure que les chaînes d'approvisionnement en logiciels s'approfondissent, les développeurs ont besoin d'une vision plus approfondie de la pile logicielle." Il existe des outils que les développeurs peuvent utiliser pour faciliter le suivi des dépendances. De nombreuses équipes d'ingénieurs utilisent Dependabot, un outil qui cartographie l'arbre de dépendance d'une application et vérifie si des dépendances sont obsolètes. Les développeurs peuvent utiliser des outils de ce type pour suivre les dépendances et mettre à jour la base de code avec la version la plus récente lorsque des failles de sécurité sont détectées. Un état d'esprit axé sur la sécurité exige un apprentissage continu : Le DevSecOps fonctionne mieux lorsque tous les membres de l'équipe d'ingénierie s'intéressent aux nouveaux développements en matière de sécurité. Les développeurs doivent se tenir au courant de l'actualité technologique afin que les équipes puissent connaître les vulnérabilités pertinentes et agir immédiatement. Tout retard important peut conduire les entreprises à laisser leurs portes ouvertes aux attaquants. "En interne, lorsqu'une nouvelle vulnérabilité est découverte, nous entamons toujours une discussion pour nous assurer que le problème est réellement traité", a déclaré M. Lin. Les ingénieurs devraient également développer leur compréhension générale des questions de sécurité en lisant régulièrement des blogs sur la sécurité ou en obtenant des certifications dans ce domaine. Les responsables techniques doivent s'attendre à ce que les membres de l'équipe fassent de la sécurité une priorité et montrent l'exemple, ce qui peut aider les équipes à créer des cultures où les gens sont proactifs dans l'identification d'éventuels problèmes de sécurité. C'est la pratique constante de la prise au sérieux de la sécurité, plus que toute autre chose, qui empêche les contrôles de sécurité d'être relégués à la fin des cycles de développement. "C'est un défi pour tout le monde de reconnaître que la sécurité est la responsabilité de tous et pas seulement celle d'une équipe spécialisée", a déclaré M. Lin. Certaines pratiques de sécurité ne peuvent toutefois pas être automatisées. Les audits internes et externes réguliers devraient toujours faire partie des procédures de sécurité de chaque équipe, même s'ils comprennent des étapes manuelles. Les développeurs peuvent également profiter des ressources de l'entreprise pour en apprendre davantage sur la sécurité. Mme Lin explique que son entreprise propose à ses développeurs des formations qui leur permettent d'acquérir des compétences telles que les tests d'intrusion et la manière de mener des analyses rétrospectives après que des vulnérabilités ont été détectées dans l'environnement de production. Si les développeurs peuvent fournir les compétences techniques nécessaires à la création d'applications sécurisées, c'est toute l'équipe, y compris la direction, qui doit créer un environnement propice aux bonnes pratiques en matière de sécurité. "Pour faire face aux nouveaux défis, il faut également que les managers fournissent un contexte et créent une compréhension commune de l'importance de mettre le 'Sec' dans DevOps", a déclaré Gӧrn. "En fin de compte, il s'agit de changer les pratiques d'une entreprise : dé-siloter Dev et Ops et dé-siloter les attitudes de gatekeeper est un défi sur la dimension humaine, plutôt que technique." À Lire Aussi :

Tag: DevSecOps

DevSecOps rend la cybersécurité plus agile