Elastic est l'entreprise derrière la plateforme Elasticsearch, au service de dizaines de milliers d'organisations avec des solutions de recherche, d'observabilité et de sécurité, y compris dans des environnements hautement réglementés. L'open source est au cœur de l'éthique d'Elastic : Elasticsearch lui-même est open source, et sa pile technologique plus large repose fortement sur des composants open source. C'est à la fois une force et une responsabilité continue.

Le défi

À l'échelle d'Elastic, la sécurité des conteneurs est une discipline opérationnelle. Avec des milliers d'ingénieurs dans le monde et un portefeuille d'artefacts publié qui porte l'open source dans son ADN, maintenir chaque image de conteneur exempte de vulnérabilités connues était un fardeau sans cesse croissant. Et à mesure qu'Elastic accélérait sa progression vers l'accréditation FedRAMP High, les enjeux devenaient plus importants.

Trois défis convergeaient simultanément. Premièrement, la remédiation des CVE consommait une part significative de la capacité d'ingénierie de la plateforme. Deuxièmement, les modules cryptographiques validés FIPS, une exigence stricte pour les environnements réglementés, étaient complexes à maintenir en interne. Enfin, le travail sur les vulnérabilités était de plus en plus repoussé aux dernières étapes du cycle de publication, provoquant des retards répétés dans les versions d'Elastic Stack.

Comme l'a décrit Maha Alsayasneh, directrice de l'ingénierie chez Elastic : « Nous passions trop de temps à réagir dans l'urgence. À chaque cycle de publication, nous nous retrouvions à traquer les CVE dans les derniers jours précédant la mise à disposition générale (GA). Ce n'est pas une façon durable de travailler lorsque vous livrez à notre échelle et dans nos environnements réglementés. »

L'équipe a évalué ce qu'il faudrait pour construire et maintenir sa propre base d'images durcies et validées FIPS à grande échelle. La conclusion a été que le passage à l'échelle de l'approche interne d'Elastic était structurellement intenable : cela nécessiterait une équipe dédiée travaillant à temps plein uniquement sur le durcissement des images, ainsi qu'un investissement planifié important pour mettre en place des builds validés FIPS en interne.

Ces défis avaient des conséquences commerciales réelles. Pour les clients commerciaux, les retards de publication signifiaient un accès plus lent aux nouvelles fonctionnalités. Pour les clients du secteur public, l'absence de contrôles matures de la chaîne d'approvisionnement et d'images validées FIPS constituait un obstacle majeur. L'accréditation FedRAMP High n'était pas accessible sans résoudre correctement ce problème.

La solution

Lorsqu'Elastic a honnêtement évalué le coût de « construire vs acheter », la réponse était claire. Elastic s'est tourné vers Chainguard Containers comme couche de base pour ses artefacts publiés.

Plutôt que de mettre en place une usine interne d'images durcies, Elastic a reconnu que Chainguard en avait déjà construit une avec la Chainguard Factory, intégrant une remédiation continue des CVE et incluant des variantes validées FIPS.

L'intégration s'est parfaitement adaptée à l'infrastructure existante d'Elastic : les conteneurs Chainguard circulent via ses flux de travail CI basés sur Buildkite et GitOps pilotés par ArgoCD, sont analysés par Snyk, validés par des portes de qualité automatisées et expédiés vers les registres en aval sans interruption.

Les résultats

Capacité d'ingénierie récupérée

L'impact le plus immédiat a été ressenti par l'équipe de productivité de l'ingénierie de plateforme d'Elastic, responsable des frameworks, des outils et de l'infrastructure qui permettent à toutes les équipes produit d'Elastic de construire, tester et publier à grande échelle. La charge de travail liée à la remédiation des CVE a considérablement diminué, et la capacité précédemment absorbée par le travail de durcissement des images a été redirigée vers l'innovation de la plateforme.

Les équipes produit ont constaté moins de courses contre la montre liées aux CVE en fin de cycle perturbant leurs plans de livraison, et l'ingénierie de publication a gagné une cadence de publication plus prévisible, avec la conformité aux CVE intégrée dans la couche de base plutôt que corrigée à la fin.

FedRAMP High débloqué

La possibilité de s'appuyer sur des images de conteneurs durcies, validées FIPS et continuellement mises à jour a levé un obstacle majeur sur la voie d'Elastic vers les marchés réglementés. Pour les équipes de sécurité et de conformité, cela a créé une base plus solide et prête pour l'audit. Pour les clients du secteur public, cela signifiait qu'Elastic pouvait désormais concourir de manière crédible et servir des comptes où l'intégrité de la chaîne d'approvisionnement est un véritable critère d'achat, des marchés qui n'étaient tout simplement pas accessibles auparavant.

Vitesse et confiance accrues

Le changement le plus durable inspiré par l'adoption de Chainguard est peut-être culturel. Avant Chainguard, chaque nouvelle dépendance open source déclenchait un examen de sécurité et un plan de remédiation. Désormais, si elle est disponible via le dépôt Chainguard, elle est déjà approuvée. Comme l'a décrit Maha, l'équipe est passée « d'une posture défensive à une posture confiante », construisant avec assurance plutôt qu'avec prudence. Et pour Maha, la leçon plus large est celle que tout responsable d'ingénierie reconnaîtra : la sécurité de la chaîne d'approvisionnement n'est pas un problème que l'on résout une fois pour toutes. C'est une discipline continue — la question est de savoir si vous y affectez du personnel en interne ou si vous externalisez auprès d'un partenaire dédié.