Repérer les signes avant-coureurs de DevSecOps et réagir aux échecs

Le mélange parfait de développement, de sécurité et d’opérations (DevSecOps) peut échapper à de nombreuses organisations et entraver les efforts de transformation numérique, même si elles pensent qu’elles sont sur la bonne voie. Le tri des obstacles dans DevSecOps et la gestion des échecs purs et simples du processus ont occupé le devant de la scène dans deux discours liminaires lors de la conférence UNUG Fall 2022 de la semaine dernière à New York.

James Wickett, coprésident de DevSecOps à l’ONUG automne 2022, s’est concentré sur les avertissements que les organisations devraient prêter attention tandis que Vandana Verma Sehgal, présidente du conseil d’administration de l’OWASP, a examiné les échecs et les façons dont les organisations peuvent réagir. L’événement, organisé par l’ONUG (l’Open Networking User Group), a amené la communauté du cloud d’entreprise à résoudre les problèmes.

Wickett a donné un discours liminaire sur « les signes avant-coureurs de DevSecOps et ce qu’il faut faire à leur sujet » et a plongé dans les pannes au sein des entreprises. Il est également fondateur et PDG de DryRun Security.

« Pourquoi DevSecOps ne fonctionne-t-il pas dans de nombreuses organisations ? » a demandé Wicket. Il a déclaré que dans certains cas, la sécurité pourrait ne pas être incluse dans la transformation numérique, peut-être en tant que sous-produit d’une évolution rapide. Les professionnels de la sécurité pourraient également se considérer comme différents des autres membres de l’organisation, a déclaré Wickett, et adopter des perspectives plutôt draconiennes. “De nombreuses équipes de sécurité travaillent avec une vision du monde où leur objectif est d’empêcher le changement autant que possible.”

Un tel sentiment peut évidemment aller trop loin, a déclaré Wickett, surtout si la sécurité met des garde-corps autour des mauvaises choses et entrave la productivité dans le processus. “C’est un endroit où vous ne voulez pas être à l’intérieur d’une organisation”, a-t-il déclaré.

La notion d’opposer la sécurité à l’informatique et à l’entreprise peut tout simplement être contre-productive, a déclaré Wickett. “C’est un faux sentiment de transformation.”

Le principe de DevSecOps, a-t-il dit, est de prendre les pratiques et les principes de DevOps et d’intégrer la sécurité dans le cycle, et non que la sécurité se précipite pour réparer DevOps. Wickett a suggéré aux développeurs de trouver des moyens de rendre la télémétrie pour la sécurité des applications, ainsi que d’effectuer des auto-tests. Les opérations devraient également ajouter la sécurité et la télémétrie à la pile d’observabilité, a-t-il déclaré.

Quand l’échec vient appeler

Même avec des signes avant-coureurs à l’esprit, les organisations peuvent constater que leur stratégie DevSecOps fait plus de mal que de bien. Le discours d’ouverture de Sehgal sur « Échecs dans DevOps et DevSecOps Pipelines » a confronté ce que les organisations doivent faire si DevSecOps stagne. OWASP est l’Open Web Application Security Project, une organisation à but non lucratif qui travaille à améliorer la sécurité des logiciels.

Sehgal a parlé des vulnérabilités rencontrées dans l’industrie et des moyens possibles de les corriger dans un monde open source. “Les organisations de tous types, qu’il s’agisse de petites, moyennes, entreprises ou autres, utilisent davantage l’open source”, a-t-elle déclaré. “Surtout si je parle de licornes, elles utilisent principalement l’open source.”

De nos jours, les développeurs n’écrivent qu’environ 10% à 20% du code, a-t-elle déclaré, se tournant largement vers les ressources open source pour l’essentiel. Cela crée des dépendances vis-à-vis de ces tiers et plates-formes. Cette tendance s’accompagne d’une certaine responsabilité, a-t-elle déclaré, pour les organisations dans la sécurisation de leurs systèmes, en particulier avec une telle dépendance à l’open source. “Nous ne pouvons pas blâmer l’open source”, a déclaré Sehgal. « Nous ne pouvons pas blâmer Apache. Chaque entreprise essaie de se sécuriser.

Ces efforts de sécurité dépendent fortement du fait que les organisations savent avec quoi elles travaillent en termes de logiciels, de données et de plates-formes, a-t-elle déclaré. Vandana a déclaré qu’un manque de connaissances et d’observabilité soulève des questions sur la défense des bibliothèques et des codes sources.

Pourtant, il peut y avoir des problèmes tels que la vulnérabilité du code à distance Log4j et des violations, quels que soient les efforts déployés pour sécuriser les systèmes, a déclaré Sehgal, ce qui augmente la nécessité de redoubler de sécurité. “La sécurité des applications devient de plus en plus importante car nous rencontrons de plus en plus de problèmes.”

La montée en puissance d’un plus grand nombre d’organisations natives du cloud a entraîné la complication de l’association des réseaux et des applications, a-t-elle déclaré. Avoir un pied dans l’open source et l’autre dans l’environnement natif du cloud signifie que la sécurité est mutuellement importante, a-t-elle déclaré.

Dans le monde open source, les attaquants essaient une multitude de tactiques, notamment en tentant de s’attaquer aux individus qui tapent rapidement et font des erreurs qui peuvent être exploitées. Il existe également des attaques de la chaîne d’approvisionnement, telles que celle impliquant SolarWinds, qui peuvent se répercuter sur un grand nombre d’entreprises. Par exemple, si un logiciel emballé est compromis et des logiciels malveillants ajoutés, les utilisateurs du produit peuvent devenir vulnérables, a déclaré Sehgal. Il pourrait également y avoir une mise à jour qui ajoute secrètement un cryptomineur au code, qui est expédié à tout le monde, qui finirait par exécuter le cryptomineur.

Renforcer la sensibilisation et la réponse à la sécurité peut aider. La correction des bogues d’application peut prendre des mois, voire des années, s’ils ne sont pas remarqués par les organisations, a-t-elle déclaré, ce qui peut rendre les organisations vulnérables aux attaquants. “Ce n’est pas seulement ce que nous écrivons”, a déclaré Sehgal. « Il s’agit de bibliothèques open source ; il s’agit de conteneurs ; il s’agit d’infrastructure en tant que code.

Cependant, la sensibilisation humaine ne peut aller que très loin, en particulier dans l’environnement cloud, conduisant à une assistance automatisée lorsque cela est possible. “La mauvaise configuration du cloud est un grand défi, qui concerne tout le monde”, a-t-elle déclaré. Sehgal pense également que le fait d’avoir un « champion de la sécurité » au sein d’une organisation peut également améliorer la situation. “Cela peut être n’importe qui”, a-t-elle déclaré. “Les gens disent que les développeurs sont les seuls à pouvoir être des champions de la sécurité, mais non. « Ça peut être un cadre. Il peut s’agir d’un CISO, d’un CIO ou d’un CTO. » D’autres possibilités incluent un chef de projet ou un architecte de logiciel. “Cette personne doit savoir ce qui se passe”, a déclaré Sehgal.

Que lire ensuite :