DevSecOps : Harness infuse un « pare-feu » dédié aux dépendances logicielles

L’attrait d’un guichet unique

L’un de ces clients est Drax Group, une entreprise britannique spécialisée dans les énergies renouvelables. Elle avait déjà commencé à consolider ses outils de pipeline de livraison de logiciels sur Harness il y a trois ans. Le groupe continue de consolider ses pipelines sur Harness et devrait également regrouper ses différents outils de gestion des artefacts dans le nouveau module Artifact Registry, selon Jasper van Rijn, responsable de la conception et de l’ingénierie logicielles chez Drax.

« Nous avons un paysage assez hétérogène de plateformes héritées, et de nombreux ingénieurs tentent donc de résoudre [la gestion des artefacts] à l’aide d’outils légèrement inadaptés », explique Jasper van Rijn. « Nous avions donc des ressources qui restaient en quelque sorte en suspens à la fin des pipelines, d’où elles étaient ensuite extraites et transférées plus loin dans le processus, ainsi que des partages de fichiers. Nous avions des zones du réseau où les builds étaient stockés, ce qui présentait évidemment toutes sortes de risques », poursuit-il. « Nous devons consolider tout cela en quelque chose de plus gérable […] et cette fonctionnalité sur plateforme [signifie] un ensemble d’identifiants, de rôles de gestion des identités et des accès en moins ».

Harness dit étendre les fonctionnalités d’Artifact Registry, notamment la prise en charge d’un plus grand nombre d’écosystèmes de paquets, la gestion avancée du cycle de vie, l’immuabilité, l’audit et l’automatisation par l’IA pour les artefacts sur l’ensemble de la plateforme.

Et pour cause, Harness Artifact Registry n’est pas un produit aussi mature que ses concurrents spécialisés dans la gestion des artefacts, selon Andrew Cornwall, analyste chez Forrester Research. C’est toutefois un danger pour les éditeurs concurrents qui ont des clients communs avec Harness.

« Il est évident que [Harness] souhaite remplacer JFrog ou Cloudsmith parmi ses clients [et] favorise une meilleure intégration dans le cycle de vie de la livraison logicielle », déclare Andrew Cornwall. « Si vous utilisez Harness pour tout le reste, vous pouvez utiliser le même mécanisme de politique pour les artefacts que pour le CI/CD. L’intégration pourrait être intéressante si vous faites déjà partie de l’écosystème Harness ».

Le « pare-feu » dédié aux dépendances suscite l’intérêt des analystes

Harness a clairement affiché son intention de se lancer dans la gestion des artefacts et propose déjà un module plus complet dédié à la sécurité de la chaîne logistique. Mais la disponibilité générale de Harness Artifact Registry intègre également Dependency Firewall, un « pare-feu » spécialement conçu pour la gestion basée sur des politiques des paquets open source, notamment pour bloquer les paquets potentiellement malveillants avant qu’ils ne soient introduits dans les chaînes logicielles des entreprises.

Selon certains analystes, cela pourrait placer Harness dans une position concurrentielle rare.

Bien que de nombreux autres éditeurs proposent des fonctionnalités similaires à Dependency Firewall, notamment JFrog, Sonatype et Cloudsmith, celles-ci sont généralement liées à des référentiels d’artefacts plutôt qu’à des pipelines CI/CD contrôlés par ces fournisseurs, explique Katie Norton, analyste chez IDC.

Le partenariat entre JFrog et GitHub brouille quelque peu les pistes. JFrog propose également JFrog Pipelines, mais selon Katie Norton, à sa connaissance, ce produit n’est pas aussi largement adopté que ceux de GitHub, GitLab et autres. GitHub dispose également de ses propres actions de téléchargement et de chargement d’artefacts, ainsi que d’une action d’attestation de la provenance des builds et de Dependabot. GitLab, lui, propose un registre de paquets et de conteneurs.

Dans l’ensemble, « ce qui distingue quelque peu le positionnement de Harness, c’est l’angle de la propriété du pipeline », ajoute Katie Norton. « Comme ils orchestrent le CI/CD, l’intégration du registre et des contrôles de dépendance directement dans le flux de livraison signifie que l’application des politiques peut se faire nativement au sein du pipeline, plutôt que par le biais d’une passerelle externe ».

Cela s’inscrit dans le cadre d’une stratégie de sécurité plus large que Harness a mise en place au cours des deux dernières années, d’après l’analyste d’IDC. Les mises à jour de produits réalisées pendant cette période incluent le module Supply Chain Security, l’intégration des fonctionnalités de sécurisation du runtime et des API de Traceable, ainsi que les tests de sécurité (SAST) et la gestion de la posture de sécurité des applications de Qwiet AI.

En général, les éditeurs DevSecOps répondent à deux grandes tendances qui ont marqué le secteur au cours de l’année dernière. Les attaques très médiatisées visant la chaîne logistique des logiciels, souvent dues à l’importation par les développeurs de paquets open source compromis, ont fait la une des journaux. Parallèlement, l’on a assisté à une explosion du code généré par l’IA, qui a déferlé à grande vitesse sur les pipelines DevOps, selon Janet Worthington, analyste chez Forrester Research.

« Le registre des artefacts joue un rôle clé dans la gestion de ce qui peut et ne peut pas être utilisé dans le cycle de vie du développement logiciel », avance Janet Worthington. « La gouvernance devient de plus en plus importante, tout comme la gestion de la chaîne de contrôle des artefacts de construction, afin de permettre aux équipes de développement d’avancer rapidement et en toute sécurité ».

Cet article a été initialement publié sur SearchSoftwareQuality.