Die distrolose Revolution wird gestört
Dies ist der letzte Eintrag in einer dreiteiligen Serie, in der die Bereitstellung von Open-Source-Software untersucht wird — die jüngste Vergangenheit, der Wendepunkt der Gegenwart und die Zukunft.
Im ersten Beitrag befassen wir uns mit den Grundlagen, die Unix- und Linux-Betriebssystemdistributionen erstellt und definiert haben, und den Herausforderungen, die sich aus dem traditionellen Distributionsstatus quo ergeben. In der zweiten haben wir über die Innovationen und Anwendungsfälle gesprochen, die gerade jetzt einen störungsfreien Wendepunkt darstellen.
Heute werden wir darüber sprechen, wie die Zukunft aussieht und warum sie jetzt beginnt.
Wir haben die Herausforderungen mit traditionellen "eingefrorenen" Linux-Distributionen und die Innovationen und Anwendungsfälle skizziert, die die moderne, cloud-native containerisierte Anwendungsentwicklung und -bereitstellung vorangetrieben haben. Es ist erwähnenswert, dass ohne traditionelle Distributionen der iterative Fortschritt, der uns zu diesem Moment gebracht hat, nicht stattgefunden hätte, aber wir haben einen Punkt erreicht, an dem die Sicherheits-, Leistungs- und Innovationsnachteile die Vertrautheit und die wahrgenommene Stabilität der letzten Generation der Softwarebereitstellung überwiegen.
Wie sollte also die nächste Generation der Bereitstellung von Open-Source-Software aussehen?
Um die modernen Sicherheits-, Leistungs- und Produktivitätserwartungen zu erfüllen, benötigen Softwareentwickler die neueste Software in der kleinsten Form, die für ihren Anwendungsfall entwickelt wurde, ohne die CVEs, die zu Risiken für das Unternehmen führen (und eine Liste der "Fix its" von den Sicherheitsteams). Die Einhaltung dieser Parameter erfordert mehr als nur das Überwinden der Vergangenheit. Stattdessen muss die nächste Generation der Open-Source-Softwarebereitstellung von der Quelle sicherer, aktualisierter Software ausgehen: den vorgelagerten Betreuern.
Indem Sie über die nachgelagerten Distributionen hinausgehen, ist es möglich, die aktuellsten Softwarepakete zu nutzen, die von den neuesten Sicherheitsfixes und Leistungsaktualisierungen profitieren, ohne auf nachgelagerte Betreuer angewiesen zu sein. Wenn Sie über die traditionellen Distributionen hinausgehen, können Sie zu Beginn gezielt erstellte Container-Images nutzen, anstatt sich auf Ihre eigenen nachgelagerten Anpassungen von häufig aufgeblasenen Allzweck-Distributionen zu verlassen.
Meet Chainguard OS
Chainguard hat diesen neuen distroless-Ansatz entwickelt und Softwarepakete kontinuierlich neu erstellt, die nicht auf Downstream-Distributionen basieren, sondern auf den Upstream-Quellen, die Schwachstellen beseitigen und Leistungsverbesserungen hinzufügen. Wir nennen es Chainguard OS.
Chainguard OS dient als Grundlage für die umfassenden Sicherheits-, Effizienz- und Produktivitätsergebnisse, die Chainguard-Produkte heute liefern, und "Chainguarding" einen schnell wachsenden Katalog von über 1.000 Containerbildern.
Chainguard OS hält sich an vier Schlüsselprinzipien, um dies zu ermöglichen:
Kontinuierliche Integration und Bereitstellung: Betonung der kontinuierlichen Integration, des Testens und der Freigabe von vorgelagerten Softwarepaketen, um eine optimierte und effiziente Entwicklungspipeline durch Automatisierung zu gewährleisten.
Nano-Updates und -Umbauten: Begünstigt inkrementelle Non-Stop-Updates und -Umbauten gegenüber wichtigen Release-Upgrades, um reibungslosere Übergänge zu gewährleisten und störende Änderungen zu minimieren.
Minimale, gehärtete, unveränderliche Artefakte: Entfernt unnötiges Aufblähen von Software-Artefakten, macht Sidecar-Pakete und Extras für den Benutzer optional und erhöht gleichzeitig die Sicherheit durch Härtungsmaßnahmen.
Delta-Minimierung: Hält Abweichungen von Upstream auf ein Minimum und integriert zusätzliche Patches nur bei Bedarf und nur so lange wie nötig, bis eine neue Version von Upstream geschnitten wird.
Vielleicht ist der beste Weg, den Wert der Prinzipien von Chainguard OS hervorzuheben, die Auswirkungen in Chainguard Images zu sehen.
Im folgenden Screenshot (und hier einsehbar) sehen Sie einen Side-by-Side-Vergleich zwischen einem externen und Chainguard-Bild.

Abgesehen von der sehr deutlichen Diskrepanz in der Anzahl der Schwachstellen lohnt es sich, den Größenunterschied zwischen den beiden Containerbildern zu untersuchen. Das Chainguard-Bild macht nur 6 % des alternativen Open-Source-Bildes aus.
Zusammen mit der minimierten Bildgröße wurde das Chainguard-Bild zuletzt nur eine Stunde vor dem Screengrab aktualisiert, was täglich geschieht:

Ein schneller Scan der Provenienz- und SBOM-Daten veranschaulicht die End-to-End-Integrität und Unveränderlichkeit der Artefakte — eine Art vollständiges Nährwertkennzeichen, das die Sicherheit und Transparenz unterstreicht, die ein moderner Ansatz für die Bereitstellung von Open-Source-Software bieten kann.

Jedes Chainguard-Bild steht als praktisches Beispiel für den Wert, den Chainguard OS bietet, und bietet eine deutliche Alternative zu dem, was vor ihm gekommen ist. Der vielleicht größte Indikator ist das Feedback, das wir von Kunden erhalten haben, die uns mitgeteilt haben, wie die Container-Images von Chainguard dazu beigetragen haben, CVEs zu eliminieren, ihre Lieferketten zu sichern, Compliance zu erreichen und aufrechtzuerhalten und die Entwicklungsarbeit zu reduzieren, sodass sie wertvolle Entwicklerressourcen neu zuweisen können.
Wir sind davon überzeugt, dass die Prinzipien und der Ansatz von Chainguard OS auf eine Vielzahl von Anwendungsfällen angewendet werden können, wodurch die Vorteile von kontinuierlich aus der Quelle neu erstellten Softwarepaketen auf noch mehr Open-Source-Ökosysteme ausgeweitet werden.
Wenn Sie dies nützlich fanden, lesen Sie unbedingt unser Whitepaper zu diesem Thema und die umfassendere Methode, mit der wir dieses Problem für Unternehmen gelöst haben. Und schauen Sie sich unser bevorstehendes Webinar am 9. April an, in dem wir tiefer in das Thema eintauchen werden.
Share this article
Related articles
- engineering
Breaking the release monolith: How OutSystems platform engineering restored trust in delivery
Maria Chec, Technical Program Manager, Outsystems, and João Brandão, Release Engineering Director, Outsystems
- engineering
Owning the boundary: Introducing the Chainguard FIPS Provider for OpenSSL 3.4.0
Dimitri John Ledkov, Senior Principal Software Engineer, and Mandy Hubbard, Senior Technical Product Marketing Manager
- engineering
FIPS-ing the Un-FIPS-able: Apache Kafka
Jamon Camisso, Senior Manager, Software Engineering
- engineering
This Shit is Hard: The complexities of fixing Python library security issues at scale
Wesley Wiedenmeier, Senior Software Engineer
- engineering
How I learned to stop worrying and love the latest tag
Adrian Mouat, Staff Developer Relations Engineer
- engineering
The tech leader’s mandate: Use engineering to accelerate sales velocity
Sam Katzen, Staff Product Marketing Manager