alphaspirit - Fotolia
En 2021, le DevSecOps a été mis à rude épreuve
Pour se protéger, maintenir une hygiène de base ne suffit plus : les experts et les analystes intiment aux équipes de développement d’adopter des pratiques de sécurité inscrites dans le triptyque DevSecOps. Oui, mais comment ? Cette question est restée sur de nombreuses lèvres en 2021.
Cette année, LeMagIT s’est fait l’écho des trop nombreuses cyberattaques ayant paralysé les entreprises.
Avec les affaires Kaseya, SolarWind ou Codecov, les éditeurs se sont agités pour accaparer le marché, tandis que le cas Log4j tend à les rassurer dans leur stratégie. Résultat, le DevSecOps prend plusieurs formes, mais pousse les éditeurs à se rassembler ou à améliorer l’intégration de leurs solutions respectives.
Le DevSecOps agite le marché
Les fournisseurs de solutions CI/CD s’intéressent à ajouter des mécanismes visant à améliorer la posture de sécurité dans le cloud (CSPM), suivis dans cette approche par les spécialistes de l’observabilité, un terrain naturellement occupé par les éditeurs de la cybersécurité. Des acteurs comme Progress, Cloudbees, mais aussi Datadog, Sysdig proposent une itération d’Open Policy Agent, le projet open source mené par Styrga. Mais ils ne sont pas seuls. AWS, Google Cloud, Microsoft Azure ou encore JetBrains supportent ce moteur de règles à travers différents services.
Le DevSecOps, un moteur commercial
ReInvent 2021 : AWS relance la compétition autour du DevSecOps
Cloud Security Platform : Datadog unifie son offre de sécurité
CI/CD : CloudBees s'invite sur le marché de la conformité
Avec Chef InSpec, Progress prépare sa stratégie CSPM
Cisco infuse la gestion des vulnérabilités dans AppDynamics
Red Hat acquiert StackRox, spécialiste de la sécurité de Kubernetes
Toutefois en 2021, l’acronyme CSPM n’est pas brandi par tous les éditeurs. Certains préfèrent en rester à la notion de conformité et de surveillance de vulnérabilités dans les pipelines CI/CD et dans les environnements de développement. C’est le cas de JFrog, de Snyk, de Gitlab, SonarQube ou encore de GitHub. Ainsi, JFrog poursuit ses efforts autour de Xray, GitHub a amélioré Dependabot cette année, tandis que GitLab optimise les intégrations de Fuzzit et PeachTech depuis 2020.
Ces outils visent principalement à détecter les vulnérabilités dans le code et les dépendances applicatives, puis d’alerter automatiquement les développeurs. Généralement, ces logiciels s’appuient sur une base de données ouverte rassemblant les vulnérabilités connues, mais plusieurs acteurs, dont Snyk, maintiennent un référentiel propriétaire.
L’ère de l’automatisation et de l’intelligence artificielle
Certains vont plus loin en s’appuyant sur le machine learning pour détecter des failles inconnues ou en proposant d’automatiser la mise à jour des dépendances touchées, de robotiser les tests unitaires (à la manière de Ponicode), des suggestions de correction de code, ou de transmettre le problème à la bonne personne depuis les IDE. GitLab a notamment racheté la jeune startup Stackeer, qui a donné naissance à Unreview, un outil de revue de code « intelligent ». GitHub profite pour sa part des efforts de sa maison mère, Microsoft, auprès d’OpenAI pour pousser CoPilot, un outil de suggestion et de génération de code basé sur le réseau de neurones GPT-3. Copilot rencontrerait déjà une adoption importante : GitHub affirme que 30 % des nouvelles lignes de code dans les dépôts sont écrites à l’aide de son outil et que 50 % des primoadoptants continueraient à l’utiliser.
Mais cet élan vers l’automatisation des pratiques DevSecOps et l’intelligence artificielle appliquée à la génération de code provoque des craintes en matière de sécurité, tandis que les experts de l’approche DevSecOps tempèrent les ardeurs de ceux considérant qu’il faudrait tout automatiser.
L’unification des outils de développement sous une seule « plateforme DevOps », voulue par GitHub, GitLab ou encore CloudBees, l’émergence de nouvelles solutions ne cache pas le désarroi des DSI, de certaines ESN et des éditeurs en 2021 qui constatent le manque de formations et de culture des développeurs en matière de sécurité. Par exemple, la gestion des secrets, résidant encore trop souvent dans le code, demeure un défi de taille pour bon nombre d’équipes. Car la méthodologie DevSecOps repose tout au plus sur les recommandations des agences gouvernementales comme le NIST aux États-Unis ou l’ANSSI, en France, et non sur des standards clairement définis. En la matière, il faut donc se pencher sur les bonnes pratiques « des autres » : le Département de la Défense américain s’est entouré pour le faire et n’hésite pas à partager à la fois sa stratégie DevSecOps et sa manière de traiter avec les éditeurs et les fournisseurs.
Une pression accrue sur les développeurs
Car il ne faut pas non plus céder aveuglément à toutes les tendances du marché. Par exemple, certains acteurs vantent les bienfaits du « Shift Left », c’est-à-dire le fait d’introduire la sécurité (souvent via des tests) dès le début du cycle DevOps. L’intention est bonne, mais les attaquants visent en premier lieu les points saillants du SI d’une entreprise : les services et environnements en production.
Il faut donc également se prémunir contre les attaques en adoptant des stratégies de sécurité parfois considérées plus traditionnelles. D’autant plus que les développeurs font face à des exigences de production importantes, comme le signale une étude de Dynatrace, corroborée par le GitHub Octoverse 2021 (qui dénote une forte réutilisation du code en 2021, avec ses avantages et ses risques).
Les 1 300 responsables DevOps interrogés par Dynatrace affirment que leurs organisations de plus de 1 000 employés se concentrent sur l’accélération de la livraison logicielle : elles veulent augmenter la fréquence de leurs nouvelles solutions logicielles de 58 % dans les deux prochaines années, mais près d’un quart des répondants (22 %) se voient sacrifier la qualité du code produit à cause de cette pression grimpante. Les entreprises investissent en priorité dans l’automatisation des pipelines CI/CD (58 %), les services de tests à la demande (54 %), l’automatisation des tests (43 %) et de l’identification des causes profondes (AIOps : 41 %), moins dans les approches Shift-Left appliquées aux vérifications (28 %) et à la qualité du code (34 %).
En clair, la pensée DevSecOps n’infuse pas aussi vite que les responsables de la sécurité et les acteurs du marché le voudraient et les entreprises n’ont pas terminé leur transition DevOps. Espérons que l’automatisation des pipelines et l’adoption des méthodes les plus populaires permettront aux développeurs de gagner du temps pour mieux sécuriser leur code en 2022.