Open Source bildet nach wie vor die Basis zahlreicher Anwendungen und Plattformen — von Entwickler‑Toolchains bis zu Cloud‑ und Edge‑Infrastrukturen. Canonical hat in der Studie „The open source chain of trust“ 500 DevOps‑Fachleute weltweit befragt, um zu ermitteln, wie Unternehmen ihre Open‑Source‑Softwarelieferketten organisieren. Das Ergebnis: Viele Organisationen haben bereits Policies und Sicherheitswerkzeuge eingeführt, arbeiten jedoch mit fragmentierten Prozessen und leiden unter mangelnder Zusammenarbeit zwischen Teams.
Warum fragmentierte Prozesse gefährlich sind
Die Untersuchung zeigt, dass Open Source zwar allgegenwärtig ist, seine Verwaltung jedoch oft auf Flickenteppich‑Weise erfolgt. Komponenten stammen aus unterschiedlichsten Quellen, werden mit wechselnden Update‑Rhythmen kombiniert und häufig inkonsistent integriert. Solche Inkohärenz erschwert vor allem die Nachverfolgung transitive Abhängigkeiten und schränkt die Sichtbarkeit entlang der CI/CD‑Pipeline ein. Laut Studie sehen 90 Prozent der Befragten Verbesserungsbedarf bei der teamübergreifenden Zusammenarbeit in Sachen Open Source.
Kernergebnisse in Zahlen
Einige der wichtigsten statistischen Erkenntnisse der Umfrage:
- 71 Prozent nennen Spannungen zwischen DevOps‑ und Platform‑Engineering‑Teams als Hemmnis für die skalierbare Nutzung von Open Source.
- 35 Prozent verlassen sich bei Sicherheitsprüfungen noch auf manuelle Code‑Reviews.
- 21 Prozent verfolgen Schwachstellen mit manuellen Verfahren statt automatisierter Tools.
Diese Zahlen deuten darauf hin, dass menschliche Abläufe nach wie vor eine zentrale Rolle spielen — und gleichzeitig eine Hauptursache für langsame und fehleranfällige Prozesse sind.
Warum Patching verzögert wird
Die Studie befragt auch nach den Gründen für Verzögerungen beim Einspielen von Sicherheitsupdates. Die drei häufigsten Ursachen sind:
- Systemkompatibilitäts‑Bedenken: 53 Prozent gaben an, dass Unsicherheiten zur Verträglichkeit neuer Pakete mit bestehenden Systemen Updates verzögern.
- Personelle Ressourcen: 43 Prozent nannten Kapazitätsengpässe, etwa fehlendes Personal, als entscheidenden Faktor.
- Weitere organisatorische Hürden, die zu Abstimmungsaufwand und Verzögerungen führen.
Solche Verzögerungen erhöhen das Risiko, weil bekannte Schwachstellen länger ausgenutzt werden können, bevor Gegenmaßnahmen greifen.
Mit welchem Ansatz lassen sich Lücken schließen?
Die Untersuchung identifiziert mehrere Stellhebel, die Organisationen helfen können, ihre Open‑Source‑Lieferketten robuster zu machen:
Betriebssystem als strategische Steuerungsebene
Fast alle Befragten (98 Prozent) bewerten das Betriebssystem als sehr oder äußerst wichtig, um Updates für Open‑Source‑Komponenten zu erkennen und bereitzustellen. Daraus leiten die Autoren ab, dass das OS als zentraler Kontrollpunkt dienen kann, um einheitliche Governance‑Mechanismen zu etablieren und Sichtbarkeit entlang der Lebenszyklen zu verbessern.
Verifizierbare Provenienz
48 Prozent der Teilnehmer geben an, dass die Möglichkeit, Pakete nachzuverfolgen, ihr Vertrauen in die Sicherheit der Softwarelieferkette deutlich steigern würde. Verifizierbare Herkunftsinformationen erleichtern Risikoabschätzungen und beschleunigen Entscheidungen, ob und wie ein Paket in Produktion gebracht werden kann.
Stärkere teamübergreifende Abstimmung und Automatisierung
Die Studie empfiehlt, verstärkt auf automatisierte Workflows und gemeinsame Plattformen zu setzen, die DevOps, Plattform‑Engineering, Security und Betrieb zusammenführen. Automatisierung reduziert Wiederholungsaufwand und menschliche Fehler, während eine gemeinsame Grundlage Konflikte über Zuständigkeiten und Update‑Rhythmen entschärfen kann.
Was Canonical als Konsequenz anbietet
Canonical nutzt die Ergebnisse, um die Rolle von Ubuntu als zentraler Betriebssystem‑Kontrollpunkt zu betonen. Das Unternehmen verweist auf Ubuntu Pro, das laut Canonical konsistente Sicherheitswartung für das OS sowie für tausende upstream Open‑Source‑Pakete bietet. Teil des Angebots ist die Zusage, Plattformstabilität durch Backporting über längere Zeiträume bereitzustellen — bis zu 15 Jahre werden genannt — wodurch sich laut Canonical der Zielkonflikt zwischen Stabilität und notwendiger Sicherheitsanpassung verringern lässt.
Weiterhin empfiehlt Canonical, durch eine klar definierte Plattform Governance‑Standards zu vereinheitlichen und so die Zusammenarbeit zwischen den beteiligten Teams zu stärken. Die Studie selbst basiert auf einer globalen Umfrage, die von Vanson Bourne durchgeführt wurde und Teilnehmer aus den Regionen Americas, EMEA und APAC einbezieht.
Was das für Betreiber und Architekturen bedeutet
Für Betreiber, die Open Source im großen Maßstab nutzen, lassen sich aus der Studie konkrete Handlungsfelder ableiten:
- Prozesse verschlanken: Manuelle Review‑ und Tracking‑Abläufe dort reduzieren, wo Automatisierung zuverlässig greifen kann.
- OS‑zentrierte Instrumente nutzen: Das Betriebssystem kann als gemeinsame Steuerungsebene dienen, um Updates, Backports und Sicherheits‑Policies zentral zu orchestrieren.
- Provenienz implementieren: Metadaten über Herkunft und Integrität von Paketen fördern Vertrauen und erleichtern Compliance‑Entscheidungen.
- Cross‑Team‑Governance einführen: Klare Verantwortlichkeiten und gemeinsame Plattformen vermindern Abstimmungsaufwand und Konflikte.
Diese Maßnahmen sind kein Allheilmittel, aber sie adressieren direkt mehrere der in der Umfrage identifizierten Schwachstellen.
Fazit
Die Canonical‑Studie macht deutlich: Open Source bleibt Träger moderner IT‑Landschaften, steht jedoch vor operationalen und organisatorischen Herausforderungen. Fragmentierte Update‑Prozesse, manuelle Sicherheitsverfahren und fehlende teamübergreifende Abstimmung verlangsamen Patching‑Zyklen und erhöhen Risiken. Als Gegentakt schlagen die Autoren vor, das Betriebssystem stärker als Steuerungsebene zu nutzen, verifizierbare Provenienz zu etablieren und Automatisierung sowie gemeinsame Plattformen voranzutreiben. Für Organisationen, die ihre Lieferkette sicherer gestalten wollen, sind das pragmatische Ansatzpunkte — ob sie dabei auf Angebote wie Ubuntu Pro setzen, bleibt eine strategische Entscheidung der jeweiligen IT‑Organisation.