Eine bessere Möglichkeit, Anwendungen von Drittanbietern zu nutzen
Anwendungen von Drittanbietern wie gängige Datenbanken (MySQL, Postgres, Clickhouse usw.), Server (NGINX, Envoy usw.) und Entwicklertools (ArgoCD, Spark, Prometheus usw.) sind wesentliche Bausteine für die moderne Softwareentwicklung. Traditionell installieren Entwickler diese Anwendungen entweder manuell auf einem vollständigen Linux-Betriebssystem oder laden ein Container-Image aus öffentlichen Internetquellen herunter, um die Anwendung zu erwerben. Dies bringt jedoch eine Reihe von Herausforderungen mit sich:
Die manuelle Installation von Anwendungspaketen von Drittanbietern aus nicht vertrauenswürdigen Internetquellen kehrt oft die von Plattformteams durchgeführten Härtungsbemühungen um.
Open-Source-Anwendungsbilder von Drittanbietern aus Registern wie Docker basieren auf ungehärteten Verteilungen von Küchenspülen, was eine große Menge an CVEs einführt und die bereits große Angriffsfläche Ihres Containers erweitert.
Und in beiden Szenarien fehlt den Entwicklern die Kontrolle über den Anwendungsabhängigkeitsbaum, was bedeutet, dass sie entweder 1) vollständig den vorgelagerten Betreuern für Probleme mit Patches verpflichtet sind oder 2) die Last übernehmen, Code von Drittanbietern selbst zu forken und zu patchen, was zu weiterer Komplexität führt.
Kurz gesagt, der traditionelle Ansatz zum Konsumieren von Anwendungsbildern von Drittanbietern ist fragil und unterstreicht die dringende Notwendigkeit einer besseren Lösung. Eine, die es Entwicklern ermöglicht, alle Anwendungen abzurufen, die sie benötigen – sicher und skalierbar von Anfang an. Bei Chainguard lösen wir dieses Problem mit unseren Application Images, einer Suite von über 1.100 Container-Images, die vollständig aus der Quelle erstellt wurden, minimal sind und entwickelt wurden, um Ihre Container-Angriffsfläche zu reduzieren. Und unsere Anwendungsbilder sind einfach zu bedienen – Entwickler können sie direkt in ihre bestehenden Entwicklungsstapel ablegen und in Bewegung bleiben.
Um die Vorteile von Chainguards Anwendungsbildern besser zu veranschaulichen, lassen Sie uns tiefer in den Status quo und die damit verbundenen Herausforderungen einsteigen.
Auf der Vorderseite gehärtet, geben CVEs in den Back
Platform-Teams, den unbesungenen Helden der modernen DevOps-Best Practices, oft enorme Anstrengungen auf, um traditionelle Basis-Betriebssystem-Distributionen zu härten. Bei Chainguard bezeichnen wir diese Distributionen oft als "Küchenspülen" -Betriebssysteme, weil sie für die Breite gebaut wurden und Laptops, Server, VMs und mehr unterstützen. Diese Distributionen sind jedoch im Allgemeinen nicht für Container und Cloud-native Entwicklung optimiert, da sie 1) überschüssige Komponenten enthalten, die nicht für den Aufbau und Betrieb eines Containers benötigt werden (Verbreiterung der Angriffsfläche), und 2) in eingefrorenen, "stabilen" Versionen geliefert werden, die die Fähigkeit der Betreuer hemmen, alle Software-Updates und CVE-Fixes bereitzustellen. Infolgedessen müssen Plattformteams die Härtungsarbeiten selbst durchführen, um sicherzustellen, dass Entwickler Anwendungen auf einer sichereren Grundlage erstellen können.
Bei Anwendungen von Drittanbietern beginnt dieses empfindliche Gleichgewicht zu brechen. Sobald das Basis-Betriebssystem nachgelagert verteilt ist, haben wir von Kunden gehört, dass Anwendungsentwickler in der Regel manuell Anwendungskomponenten installieren oder Open-Source-Anwendungs-Images von nicht vertrauenswürdigen Quellen auf das Basis-Image schichten – wodurch die harte Arbeit des Plattformteams zunichte gemacht wird.
Dieser Ansatz ist zwar praktisch, führt aber zu zahlreichen schlechten Ergebnissen für Plattformingenieure und Anwendungsentwickler:
Aufgeblähte Container: Das Hinzufügen zusätzlicher Pakete zum Basis-Betriebssystem, entweder manuell oder über Anwendungsbilder von Küchenspülen, bedeutet eine größere Angriffsfläche, die es zu verteidigen gilt.
Fehlende Kontrolle: Entwickler haben keine Kontrolle über den Anwendungsabhängigkeitsbaum, was bedeutet, dass sie sich beim Patchen entweder auf Upstream verlassen oder Bilder selbst manuell patchen müssen, um die Komplexität der Verwaltung von Code von Drittanbietern zu übernehmen.
Wartung und Overhead: Sollte sich das Engineering für die Verwaltung des Anwendungscodes von Drittanbietern entscheiden, besteht ein weiteres Risiko des Bruchs, wenn Patches gepusht und Anwendungen in ihren Entwickler-Stack integriert werden.
Diese Herausforderungen gelten auch für Open-Source-Bilder für beliebte Anwendungen von Drittanbietern wie Airflow. Nachfolgend finden Sie ein veranschaulichendes Beispiel für Airflow, dessen Open-Source-Bild 79 CVEs (einschließlich 15 kritischer/hoher CVEs) bei einer Bildgröße von 405 MB und 612 Paketen enthält.

Die moderne Lösung von Chainguard: Zweckgerechte, minimale Anwendungsbilder
Um diese Herausforderungen für unsere Kunden zu lösen, hat Chainguard auf minimale Weise über 1.100 zweckspezifische Anwendungsbilder aus der Quelle erstellt, wodurch Angriffsfläche und CVEs eliminiert werden. Und was noch wichtiger ist, diese Bilder lassen sich einfach in Ihren bestehenden Entwicklungsstack einfügen und schnell in Bewegung setzen, da Chainguard die Last des Image-Managements und der CVE-Sanierung übernimmt, sodass Sie dies nicht tun müssen. Wie unsere Basis-Images enthalten die Anwendungs-Images von Chainguard nur die Komponenten, die zum Erstellen und Ausführen Ihrer Anwendungen erforderlich sind, mit vollständig transparenter Bescheinigung in Form von vollständigen Build-Time-SBOMs und Codesignaturen über Sigstore.
Um diesen Punkt zu demonstrieren, nehmen Sie zum Beispiel das Luftstrombild von Chainguard, das unten abgebildet ist. Das Chainguard Airflow-Bild hat nur 6 CVEs, mit nur einem kritischen, im Vergleich zum 79/15 Split des OSS-Bildes, und ist mit 270 MB und 400 Paketen deutlich kleiner (im Vergleich zu 405 MB und 612 Paketen).

Wir sehen diese ähnlichen Ergebnisse – Größe und CVE-Reduktion – in den Anwendungsbildern in unserem Katalog, so dass Sie sich auf das Wesentliche konzentrieren können: die bestmögliche Erfahrung für Ihre Kunden zu schaffen. Und wir bauen unseren Katalog weiter aus und helfen unseren Kunden, ihre Produkte zu skalieren und ihren Nutzern zu liefern.
Reduzierung Ihrer Instandhaltungslast
Einer der überzeugendsten Vorteile des Chainguard-Modells für Anwendungs-Images von Drittanbietern ist der geringere Wartungsaufwand für Entwickler, insbesondere wenn es um den Besitz von Anwendungscode von Drittanbietern geht. Herkömmliche Ansätze für die Nutzung von Anwendungs-Images erfordern, dass Engineering-Teams nicht nur Verantwortung für ihren First-Party-Anwendungscode übernehmen, sondern auch für die Basis-Distribution, ihre Linux-Abhängigkeiten und alle ihre Abhängigkeiten.
Mit Chainguard können Kunden das Management und die CVE-Sanierung auslagern, wobei Chainguard auch die Verantwortung für die Basis-Linux-Distribution, die Linux-Abhängigkeiten und die App-Abhängigkeiten übernimmt. Wir heben die gemeinsame Verantwortung zwischen Chainguard und unseren Kunden im folgenden Diagramm hervor:

Chainguard Application Images: The Modern Approach
Bereit, Ihre Anwendungsentwicklungspraktiken zu verbessern? Entdecken Sie noch heute die Anwendungsbilder von Chainguard und wenden Sie sich an uns, um mehr darüber zu erfahren, wie sie Ihre Arbeitsabläufe verändern können.
Share this article
Related articles
- product
Super SBOMs: See exactly what's inside
Tony Camp, Staff Product Manager
- product
Security baked into your software supply chain: The combined benefit of JFrog and Chainguard
Mandy Hubbard, Senior Technical Product Marketing Manager, and Dafna Zahger Bernanka, JFrog Director of Product Marketing, Security
- product
Introducing automatic, short-lived credentials for Chainguard Libraries for Python
Jason Hall, Principal Software Engineer, and Ross Gordon, Staff Product Marketing Manager
- product
Unwrapping Ruby 4.0: Chainguard delivers a gem just in time for Boxing Day
Sergio Durigan Junior, Senior Software Engineer
- product
Custom Certificates are now available in Custom Assembly
Tony Camp, Staff Product Manager
- product
The Engineer’s Never-Gift Guide: Avoiding the nightmare before Christmas
Sam Katzen, Staff Product Marketing Manager