Der Status von vertrauenswürdigem Open Source: Dezember 2025

Bei Chainguard haben wir einen einzigartigen Einblick darin, wie moderne Unternehmen Open-Source-Software tatsächlich nutzen und wo sie auf Risiken und betriebliche Belastungen stoßen. Über unseren wachsenden Kundenstamm und unseren umfangreichen Katalog von über 1.800 Container-Image-Projekten, 148.000 Versionen, 290.000 Images und 100.000 Sprachbibliotheken sowie fast einer halben Milliarde Builds hinweg können wir sehen, was Teams tagtäglich abrufen, bereitstellen und warten, zusammen mit den Schwachstellen und den Realitäten der Fehlerbehebung, die damit einhergehen.

Deshalb haben wir „The State of Trusted Open Source“ ins Leben gerufen, ein vierteljährliches Stimmungsbild zur Open-Source-Software-Lieferkette. Bei der Analyse anonymisierter Produktnutzungs- und CVE-Daten fielen uns gemeinsame Themen auf, womit Open-Source-Engineering-Teams tatsächlich arbeiten und welche Risiken damit verbunden sind.

Das haben wir herausgefunden:

• KI gestaltet den Basis-Stack neu: Python war das beliebteste Open-Source-Image bei unserem weltweiten Kundenstamm und bildet das Rückgrat des modernen KI-Stacks.

• Über die Hälfte der Produktion findet außerhalb der beliebtesten Projekte statt: Die meisten Teams mögen sich auf einen vertrauten Satz von Images standardisieren, aber die reale Infrastruktur wird von einem breiten Portfolio angetrieben, das weit über die Top 20 der beliebtesten hinausgeht – was wir in diesem Bericht als Longtail-Images bezeichnen.

• Beliebtheit lässt nicht auf das Risiko schließen: 98 % der in Chainguard-Images gefundenen und behobenen Schwachstellen traten außerhalb der Top 20 der beliebtesten Projekte auf. Das bedeutet, dass sich die größte Sicherheitslast im weniger sichtbaren Teil des Stacks ansammelt, wo das Patchen am schwierigsten zu operationalisieren ist.

• Compliance kann der Katalysator für Maßnahmen sein: Compliance nimmt heute viele Formen an: von SBOM- und Schwachstellenanforderungen bis hin zu Branchen-Frameworks wie PCI DSS, SOC 2 und Verordnungen wie dem Cyber Resilience Act der EU. FIPS ist nur ein Beispiel, das sich speziell auf die Verschlüsselungsstandards der US-Bundesbehörden konzentriert. Dennoch nutzen 44 % der Chainguard-Kunden ein FIPS-Image in der Produktion, was unterstreicht, wie häufig regulatorische Anforderungen reale Software-Entscheidungen beeinflussen.

• Vertrauen basiert auf der Behebungsgeschwindigkeit: Chainguard hat kritische CVEs im Durchschnitt in weniger als 20 Stunden beseitigt.

Bevor wir ins Detail gehen, ein Hinweis zu unserer Methodik: Dieser Bericht analysiert über 1800 einzigartige Container-Image-Projekte, insgesamt 10.100 Schwachstelleninstanzen und 154 einzigartige CVEs, die vom 1. September 2025 bis zum 30. November 2025 verfolgt wurden. Wenn wir Begriffe wie „Top-20-Projekte“ und „Longtail-Projekte“ (definiert als Images außerhalb der Top 20) verwenden, beziehen wir uns auf reale Nutzungsmuster, die in unserem Kundenportfolio und bei Produktions-Pulls beobachtet wurden.

Nutzung: Was Teams tatsächlich in der Produktion ausführen

Wenn man das Gesamtbild betrachtet, sieht der heutige Produktions-Container-Footprint genau so aus, wie man es erwarten würde: Grundlegende Sprachen, Runtimes und Infrastrukturkomponenten dominieren unsere Liste der beliebtesten Projekte.

Beliebteste Images: KI gestaltet den Basis-Stack neu

In allen Regionen sind die meistgenutzten Images vertraute Klassiker: Python (71,7 % der Kunden), Node (56,5 %), nginx (40,1 %), Go (33,5 %), Redis (31,4 %), gefolgt von JDK, JRE und einer Gruppe zentraler Observability- und Plattform-Tools wie Grafana, Prometheus, Istio, cert-manager, argocd, ingress-nginx und kube-state-metrics.

Dies deutet darauf hin, dass Kunden ein Portfolio kritischer Bausteine betreiben – einschließlich Sprachen, Gateways, Service Mesh, Monitoring und Controllern –, die zusammen das Fundament ihres Geschäfts bilden.

Es überrascht nicht, dass Python weltweit führend ist, da es die Standard-Verbindungssprache für den modernen KI-Stack ist. Teams standardisieren üblicherweise auf Python für die Modellentwicklung, Daten-Pipelines und zunehmend auch für Inferenz-Dienste in der Produktion.

Am beliebtesten nach Region: Ähnliche Grundlagen, unterschiedlicher Longtail-Mix

Nordamerika weist eine breite und konsistente Auswahl an Standard-Produktionsbausteinen auf: Python (71,7 % der Kunden), Node (56,6 %), nginx (39,8 %), Go (31,9 %), Redis (31,5 %), plus eine starke Verbreitung von Komponenten des Kubernetes-Ökosystems (cert-manager, istio, argocd, prometheus, kube-state-metrics, node-exporter, kubectl). Bemerkenswerterweise tauchen sogar Utility-Images wie busybox in signifikantem Maße auf.

Außerhalb Nordamerikas zeigt sich derselbe Kern-Stack, aber das Portfolio verteilt sich anders: Python (72 % der Kunden), Node (55,8 %), Go (44,2 %), nginx (41,9 %) sowie eine spürbare Präsenz von .NET-Runtimes (aspnet-runtime, dotnet-runtime, dotnet-sdk) und PostgreSQL.

Der Longtail von Bildern ist entscheidend für die Produktion, nicht Grenzfälle.

Die beliebtesten Images von Chainguard machen nur 1,37 % aller verfügbaren Images aus und sind für etwa die Hälfte aller Container-Pulls verantwortlich. Die andere Hälfte der Nutzung im Produktivbetrieb stammt von überall sonst: 1.436 Longtail-Images, die 61,42 % des Container-Portfolios eines durchschnittlichen Kunden ausmachen.

Mit anderen Worten: Die Hälfte aller Produktions-Workloads läuft auf Longtail-Images. Das sind keine Randfälle. Sie sind ein Kernbestandteil der Infrastruktur unserer Kunden. Es ist relativ einfach, die wichtigste Handvoll an Images auf Hochglanz zu halten, aber was vertrauenswürdige Open-Source-Software erfordert, ist die Aufrechterhaltung dieser Sicherheit und Geschwindigkeit über die gesamte Bandbreite dessen hinweg, was Kunden tatsächlich einsetzen.

FIPS-Nutzung: Compliance ist ein Katalysator für Maßnahmen

FIPS-Verschlüsselung ist eine wesentliche Technologie in der Compliance-Landschaft, die darauf ausgerichtet ist, die Verschlüsselungsanforderungen der US-Bundesbehörden zu erfüllen. Und es bietet einen nützlichen Einblick darin, wie regulatorischer Druck die Einführung vorantreibt. Laut unseren Daten betreiben 44 % der Kunden mindestens ein FIPS-Image in der Produktion.

Das Muster ist konsistent: Bei der Arbeit innerhalb von Compliance-Rahmenwerken wie FedRAMP, DoD IL-5, PCI DSS, SOC 2, CRA, Essential Eight oder HIPAA benötigen Teams gehärtete, vertrauenswürdige Open-Source-Software, die ihre kommerziellen Workloads widerspiegelt. Unsere am häufigsten verwendeten FIPS-Images orientieren sich am breiteren Portfolio, lediglich mit kryptografischen Modulen, die für die Auditierung und Verifizierung verstärkt wurden.

Zu den wichtigsten FIPS-Image-Projekten gehören Python-fips (62 % der Kunden mit mindestens einem FIPS-Image in der Produktion), Node-fips (50 %), nginx-fips (47,2 %), go-fips (33,8 %), redis-fips (33,1 %) sowie Plattformkomponenten wie istio-pilot-fips, istio-proxy-fips und cert-manager-Varianten. Sogar unterstützende Bibliotheken und Krypto-Grundlagen tauchen auf, wie zum Beispiel glibc-openssl-fips.

FIPS ist nicht die ganze Geschichte, aber es veranschaulicht eine umfassendere Wahrheit: Compliance ist ein universeller Treiber, der die Notwendigkeit von vertrauenswürdigem Open Source über den gesamten Software-Stack hinweg unterstreicht.

CVEs: Popularität entspricht nicht dem Risiko

Beim Blick auf den Image-Katalog von Chainguard zeigt sich, dass sich das Risiko überwiegend außerhalb der beliebtesten Images konzentriert. Von den CVEs, die wir in den letzten drei Monaten behoben haben, traten 214 in den Top-20-Images auf, was nur 2 % der gesamten CVEs ausmacht. Geht man über diese Top-Images hinaus, findet man die anderen 98 % der von uns behobenen CVEs (10.785 CVE-Instanzen). Das ist das 50-fache der Anzahl an CVEs in den Top-20-Images!

Das größte Volumen an CVEs wird als „Medium“ eingestuft, aber die betriebliche Dringlichkeit ergibt sich oft daraus, wie schnell „Critical“- und „High“-CVEs behoben werden und ob sich Kunden auf diese Geschwindigkeit über ihr gesamtes Portfolio hinweg verlassen können, nicht nur bei den gängigsten Images.

Vertrauen basiert auf der Geschwindigkeit der Fehlerbehebung

Für uns wird Vertrauen an der Zeit bis zur Behebung gemessen, und wir wissen, dass dies bei kritischen CVEs am wichtigsten ist. Im analysierten Dreimonatszeitraum erreichte unser Team eine durchschnittliche Behebungszeit von weniger als 20 Stunden für kritische CVEs, wobei 63,5 % der kritischen CVEs innerhalb von 24 Stunden, 97,6 % innerhalb von zwei Tagen und 100 % innerhalb von drei Tagen behoben wurden.

Zusätzlich zur Behebung kritischer CVEs bearbeitete unser Team High-CVEs in 2,05 Tagen, Medium-CVEs in 2,5 Tagen und Low-CVEs in 3,05 Tagen – deutlich schneller als unsere SLAs (sieben Tage für kritische CVEs und 14 Tage für High-, Medium- und Low-CVEs).

Und diese Geschwindigkeit beschränkt sich nicht nur auf die populärsten Pakete. Für jede einzelne CVE, die in einem Top-20-Image-Projekt behoben wurde, haben wir 50 CVEs in weniger populären Images gelöst.

In diesem Longtail verbirgt sich der Großteil Ihres tatsächlichen Risikos, und der Versuch, hier Schritt zu halten, kann sich aussichtslos anfühlen. Die meisten Engineering-Organisationen können schlichtweg keine Ressourcen für das Patchen von Schwachstellen in Paketen bereitstellen, die außerhalb ihres Core-Stacks liegen, aber unsere Daten machen deutlich, dass Sie die „stille Mehrheit“ Ihrer Software-Lieferkette mit der gleichen Strenge absichern müssen wie Ihre kritischsten Workloads.

Eine neue Baseline für vertrauenswürdige Open-Source-Software

In unseren Daten sticht eine Erkenntnis besonders hervor: Moderne Software wird von einem breiten, sich ständig verändernden Portfolio an Open-Source-Komponenten angetrieben, von denen die meisten außerhalb der 20 populärsten Images liegen. Das ist nicht der Bereich, in dem Entwickler ihre Zeit verbringen, aber dort sammelt sich der Großteil der Sicherheits- und Compliance-Risiken an.

Dies führt zu einer besorgniserregenden Diskrepanz: Es ist für Entwicklerteams rational, sich auf die wenigen Projekte zu konzentrieren, die für ihren Stack am wichtigsten sind, doch der Großteil des Risikos liegt in der Vielzahl an Abhängigkeiten, für deren Verwaltung ihnen die Zeit fehlt.

Genau deshalb kommt es auf die Breite an. Chainguard wurde entwickelt, um den operativen Aufwand des Longtails zu übernehmen und bietet Abdeckung sowie Fehlerbehebung in einem Umfang, den einzelne Teams allein nicht rechtfertigen können. Da Open-Source-Lieferketten immer komplexer werden, werden wir weiterhin Nutzungsmuster verfolgen und aufzeigen, wo die tatsächlichen Risiken liegen, damit Sie den Kampf gegen den Longtail nicht alleine führen müssen.

Sind Sie bereit, mit der vertrauenswürdigen Quelle für Open Source durchzustarten? Kontaktieren Sie uns, um mehr zu erfahren.