Elastic ist das Unternehmen hinter der Elasticsearch Platform und bedient zehntausende Organisationen mit Such-, Observability- und Sicherheitslösungen, auch in stark regulierten Umgebungen. Open Source ist ein Kernbestandteil des Ethos von Elastic: Elasticsearch selbst ist Open Source, und der breitere Stack stützt sich stark auf Open-Source-Komponenten. Das ist sowohl eine Stärke als auch eine ständige Verantwortung.

Die Herausforderung

Bei der Größenordnung von Elastic ist Containersicherheit eine operative Disziplin. Mit Tausenden von Ingenieuren weltweit und einem veröffentlichten Artefakt-Portfolio, das Open Source in seiner DNA trägt, war es eine ständig wachsende Belastung, jedes Container-Image frei von bekannten Schwachstellen zu halten. Und als Elastic seinen Vorstoß in Richtung FedRAMP High-Akkreditierung beschleunigte, stieg der Einsatz.

Drei Herausforderungen trafen gleichzeitig aufeinander. Erstens beanspruchte die CVE-Behebung einen bedeutenden Teil der Kapazität der Plattform-Entwicklung. Zweitens waren FIPS-validierte kryptografische Module, eine harte Anforderung für regulierte Umgebungen, intern nur schwer zu pflegen. Und schließlich verlagerte sich die Arbeit an Schwachstellen zunehmend in die letzten Phasen des Release-Zyklus, was wiederholt zu Verzögerungen bei der Veröffentlichung des Elastic Stacks führte.

Wie Maha Alsayasneh, Senior Engineering Manager bei Elastic, es beschrieb: „Wir haben zu viel Zeit damit verbracht, defensiv zu agieren. In jedem Release-Zyklus fanden wir uns dabei wieder, CVEs bis in die letzten Tage vor dem GA (General Availability) hinterherzujagen. Das ist keine nachhaltige Arbeitsweise, wenn man in unserem Maßstab und für unsere regulatorischen Umgebungen ausliefert.“

Das Team skizzierte, was nötig wäre, um ein eigenes gehärtetes, FIPS-validiertes Image-Fundament in großem Maßstab aufzubauen und zu pflegen. Das Fazit war, dass die Skalierung des internen Ansatzes von Elastic strukturell unhaltbar war: Es würde ein dediziertes Team erfordern, das Vollzeit nur an der Image-Härtung arbeitet, plus eine erhebliche geplante Investition, um FIPS-validierte Builds intern aufzusetzen.

Diese Herausforderungen hatten echte geschäftliche Konsequenzen. Für kommerzielle Kunden bedeuteten die Release-Verzögerungen einen langsameren Zugriff auf neue Funktionen. Für Kunden aus dem öffentlichen Sektor war das Fehlen ausgereifter Lieferkettenkontrollen und FIPS-validierter Images eine harte Barriere. FedRAMP High war ohne eine ordnungsgemäße Lösung nicht erreichbar.

Die Lösung

Als Elastic die Kosten-Nutzen-Rechnung für „Build vs. Buy“ ehrlich durchführte, war die Antwort klar. Elastic wandte sich an Chainguard Containers als Basisschicht für seine veröffentlichten Artefakte.

Anstatt eine interne Fabrik für gehärtete Images aufzubauen, erkannte Elastic, dass Chainguard mit der Chainguard Factory bereits eine solche geschaffen hatte – inklusive integrierter kontinuierlicher CVE-Behebung und FIPS-validierter Varianten.

Die Integration passte nahtlos in die bestehende Infrastruktur von Elastic: Chainguard Containers fließen durch die Buildkite-basierte CI und die ArgoCD-gesteuerten GitOps-Workflows, werden von Snyk gescannt, durch automatisierte Qualitäts-Gates validiert und ohne Unterbrechung an nachgelagerte Registries ausgeliefert.

Die Ergebnisse

Wiedergewonnene Engineering-Kapazität

Die unmittelbarste Auswirkung spürte das Platform Engineering Productivity-Team von Elastic, das für die Frameworks, Tools und Infrastruktur verantwortlich ist, die es allen Produktteams von Elastic ermöglichen, in großem Maßstab zu bauen, zu testen und zu veröffentlichen. Der Aufwand für die CVE-Behebung sank erheblich, und die Kapazität, die zuvor durch die Arbeit an der Image-Härtung gebunden war, wurde auf Plattform-Innovationen umgelenkt.

Produktteams erlebten weniger kurzfristige Hektik durch CVEs am Ende des Zyklus, die ihre Lieferpläne störten, und das Release Engineering gewann einen vorhersehbareren Release-Rhythmus, bei dem die CVE-Compliance in der Basisschicht integriert ist, anstatt sie am Ende nachzubessern.

FedRAMP High freigeschaltet

Die Fähigkeit, auf gehärtete, FIPS-validierte und kontinuierlich aktualisierte Container-Images verweisen zu können, beseitigte ein hartes Hindernis auf dem Weg von Elastic in regulierte Märkte. Für Sicherheits- und Compliance-Teams schuf dies eine stärkere, prüfungsbereite Basis. Für Kunden aus dem öffentlichen Sektor bedeutete dies, dass Elastic nun glaubwürdig um Aufträge konkurrieren und Kunden bedienen konnte, bei denen die Integrität der Lieferkette ein echtes Beschaffungskriterium ist – Märkte, die zuvor einfach nicht zugänglich waren.

Erhöhte Geschwindigkeit und Zuversicht

Die vielleicht nachhaltigste Veränderung, die durch die Zusammenarbeit mit Chainguard angestoßen wurde, war kultureller Natur. Vor Chainguard löste jede neue Open-Source-Abhängigkeit eine Sicherheitsüberprüfung und einen Behebungsplan aus. Jetzt, wenn es über das Chainguard Repository verfügbar ist, ist es bereits vertrauenswürdig. Wie Maha es beschrieb, hat das Team den Wechsel „von einer defensiven zu einer selbstbewussten Haltung“ vollzogen und baut nun mit Zuversicht statt mit Vorsicht. Und für Maha ist die umfassendere Lektion eine, die jeder Engineering-Leiter wiedererkennen wird: Sicherheit in der Lieferkette ist kein Problem, das man einmal löst und dann vergisst. Es ist eine kontinuierliche Disziplin – die Frage ist nur, ob man dafür intern Personal einstellt oder die Aufgabe an einen dedizierten Partner auslagert.