Software Supply Chain Archive

In diesem Jahr werden viele große Unternehmen weltweit gezwungen sein, sich mit der Ursache von Cyberangriffen auseinanderzusetzen. Viele bekannte Schwachstellen sind ein offenes Einfallstor für eingeschränkte Netzwerkressourcen. In unserem ersten Threat Report des Jahres 2025 gehen wir auf einige katastrophale Sicherheitsverletzungen aus 2024 ein und befassen uns mit Sicherheitslücken, die im letzten Monat gefährlich wurden.

Die hier besprochenen Schwachstellen kratzen jedoch nur an der Oberfläche. Im Januar 2025 wurden über 4.000 neue CVEs (Common Vulnerabilities and Exposures) veröffentlicht, 22 mit der maximalen CVSS-Punktzahl von 10 und 375 mit kritischem Schweregrad. Die Flut von kritischen Schwachstellen in Edge-Networking-Geräten ist noch nicht abgeebbt. Neu angegriffene Schwachstellen in Produkten von globalen Tech-Giganten wie Microsoft, Apple, Cisco, Fortinet, Palo Alto Networks, Ivanti, Oracle und anderen wurden in den KEV-Katalog (Known Exploited Vulnerabilities) der CISA (Cybersecurity and Infrastructure Security Agency) aufgenommen.

Software-Lieferkette: Die Verantwortung der User

Wir alle arbeiten mit Software, die wir nicht selbst entwickelt haben. Daher spielt Vertrauen eine große Rolle. Wo das Vertrauen wackelt, sei es aus Angst vor mangelnder Sorgfalt, Böswilligkeit oder menschlichem Versagen, liegt die Verantwortung für die Cybersicherheit immer noch beim Endbenutzer. Die Absicherung gegen Risiken hängt in hohem Maß von technischem Wissen und gemeinsamen Anstrengungen ab. Verteidiger müssen sich im Jahr 2025 dessen bewusst sein.

Wenn die Sicherheit der Lieferkette versagt, fragen Sie nach den Gründen! Hat der Softwareanbieter die erforderlichen Tools zur Verfügung gestellt, damit Sie die Kontrolle über die Ergebnisse Ihrer Sicherheitsbemühungen übernehmen können? Führt Ihr Security-Team eine sorgfältige Erkennung und Behebung von Schwachstellen durch? Sind Ihre Ressourcen mit starken Zugangskontrollen segmentiert? Wurden die Mitarbeiter darin geschult, Phishing-Angriffe zu erkennen? Wurden noch andere, angemessene Cybersicherheitsmaßnahmen ergriffen? Unternehmen müssen ihre Resilienz gegen Ransomware stärken, das heißt, sie müssen regelmäßig die Schwachstellen bewerten und das Patchmanagement priorisieren. Darüber hinaus sollten sie überprüfen, ob zuverlässige Backup-Strategien bestehen, die die Recovery-Ziele erfüllen, und andere grundlegende Sicherheitskontrollen etablieren, um sensible Daten zu schützen und Ausfallzeiten zu vermeiden.

Erfolg durch Vorbereitung

Der Jahresbericht 2024 des britischen NCSC (National Cyber Security Center) zeichnet ein düsteres Bild: Die Zahl der bedeutenden Cyberangriffe hat sich im Vergleich zu 2023 verdreifacht. Aus der Vogelperspektive hat das CSIS (Center for International Strategic & International Studies) eine umfangreiche Liste der wichtigsten Cybervorfälle des Jahres 2024 veröffentlicht. Die Bedrohungslandschaft wurde durch den Russland-Ukraine-Konflikt geprägt und den weltweit beschleunigten Umschwung weg von der Globalisierung hin zur Feindseligkeit.

Check Point Research fand heraus, dass 96 % aller Schwachstellen, die 2024 ausgenutzt wurden, über ein Jahr alt waren. Dies sind positive Erkenntnisse für proaktive Verteidiger. Unternehmen, die ein Schwachstellenmanagement betreiben, sind wesentlich besser gegen gezielte Ransomware und Massenangriffe gewappnet. Klar ist: Proaktive Cybersicherheit reduziert die Kosten einer Sicherheitsverletzung.

Sehen wir uns zwei der wichtigsten Sicherheitsverletzungen aus dem Jahr 2024 an:

Das Change Healthcare Datenleck: Im Jahr 2024 gingen die Sicherheitsverletzungen im Gesundheitswesen gegenüber dem Rekordjahr 2023 insgesamt zurück. Der Ransomware-Angriff auf Change Healthcare stellte jedoch mit 190 Millionen betroffenen Personen einen neuen Rekord auf, wobei sich die Gesamtkosten bisher auf 2,457 Milliarden Dollar belaufen. Der Bundesstaat Nebraska hat nun eine Klage eingereicht gegen Change Healthcare, weil das Unternehmen veraltete IT-Systeme betreibt, die nicht den Sicherheitsstandards für Unternehmen entsprechen. Nach Angaben von IBM sind Sicherheitsverletzungen im Gesundheitswesen mit durchschnittlich 9,77 Millionen Dollar im Jahr 2024 am kostspieligsten.
Typhoon-Teams brechen in neun amerikanische TK-Unternehmen ein: Das Suffix „Typhoon“ wird von Microsofts Namenskonvention für Bedrohungsakteure für Gruppen mit chinesischem Ursprung verwendet. Der staatlich unterstützte chinesische Angreifer Salt Typhoon war in die Netzwerke von mindestens neun großen US-Telekommunikationsunternehmen eingedrungen und hatte auf die Anruf- und Text-Metadaten der Benutzer sowie auf Audioaufnahmen von hochrangigen Regierungsvertretern zugegriffen. Volt Typhoon drang in die Netzwerke von Singapore Telecommunications (SingTel) und anderen Telekommunikationsbetreibern weltweit ein. Die „Typhoons“ nutzten Schwachstellen in veralteten Netzwerkgeräten aus, darunter ungepatchte Microsoft Exchange Server, Cisco-Router, Fortinet- und Sophos-Firewalls sowie Ivanti-VPN-Anwendungen. Greenbone ist in der Lage, alle bekannten Software-Schwachstellen im Zusammenhang mit Salt Typhoon und Volt Typhoon-Angriffen zu erkennen [1][2].

UK: Verbot von Ransomware-Zahlungen im öffentlichen Sektor?

Die britische Regierung hat im Rahmen der Ransomware-Bekämpfung ein Verbot von Lösegeldzahlungen durch öffentliche Einrichtungen und Betreiber kritischer Infrastrukturen vorgeschlagen, um Cyberkriminelle davon abzuhalten, sie ins Visier zu nehmen. In einem neuen Bericht des National Audit Office (NAO), der unabhängigen britischen Aufsichtsbehörde für öffentliche Ausgaben, heißt es jedoch, dass „die Cyberbedrohung für die britische Regierung ernst ist und schnell voranschreitet“.

Das FBI, die CISA und die NSA raten von Lösegeldzahlungen ab. Schließlich garantiert die Zahlung eines Lösegelds nicht die Wiederherstellung verschlüsselter Daten oder verhindert die Veröffentlichung gestohlener Daten und kann sogar zu weiterer Erpressung ermutigen. Auf der anderen Seite räumt der Security-Thinktank von IBM ein, dass viele kleine und mittlere Unternehmen die durch Ransomware verursachten Ausfallzeiten finanziell nicht verkraften könnten. Auch wenn beide Seiten gute Argumente haben: Kann es zu einem positiven Ergebnis führen, wenn Cyber-Kriminelle bereichert werden und die Förderung lokaler Talente vernachlässigt wird?

Schwachstelle in SonicWall SMA 1000 aktiv ausgenutzt

Microsoft Threat Intelligence hat die aktive Ausnutzung von SonicWall SMA 1000 Gateways über CVE-2025-23006 (CVSS 9.8 Kritisch) aufgedeckt. Die Schwachstelle wird durch die unsachgemäße Behandlung nicht vertrauenswürdiger Daten während der Deserialisierung verursacht [CWE-502]. Über sie kann ein nicht authentifizierter Angreifer mit Zugriff auf die interne Appliance Management Console (AMC) oder die Schnittstelle der Central Management Console (CMC) beliebige Betriebssystembefehle ausführen. SonicWall hat den Hotfix Version 12.4.3-02854 veröffentlicht, um die Schwachstelle zu beheben.

Obwohl kein öffentlich zugänglicher Exploit-Code identifiziert wurde, haben zahlreiche Regierungsbehörden Warnungen herausgegeben, darunter das deutsche BSI CERT-Bund, das kanadische Center for Cybersecurity, CISA und der britische NHS (National Health Service). Greenbone kann SonicWall-Systeme erkennen, die von CVE-2025-23006 betroffen sind, indem es die im Service-Banner angegebene Version per Fernzugriff überprüft.

CVE-2024-44243 für persistente Rootkits in macOS

Der Januar 2025 war ein Monat voller Herausforderungen für die Apple-Sicherheit. Microsoft Threat Intelligence hat Zeit für einen Sicherheitstest von macOS gefunden und dabei eine Schwachstelle entdeckt, die es installierten Apps ermöglichen könnte, den Systemintegritätsschutz (SIP) des Betriebssystems zu verändern. Laut Microsoft könnten Angreifer auf diese Weise Rootkits und persistente Malware installieren und Transparency, Consent and Control (TCC) umgehen, das Anwendungen auf Ordnerbasis granulare Zugriffsberechtigungen gewährt. Obwohl noch kein aktiver Angriff gemeldet wurde, hat Microsoft technische Details zu den Erkenntnissen veröffentlicht.

Als der Januar zu Ende ging, wurde eine Reihe von 88 neuen CVEs veröffentlicht, von denen 17 einen kritischen Schweregrad (CVSS) aufweisen und das gesamte Spektrum der Apple-Produkte betreffen. Eine davon, CVE-2025-24085, wurde bei aktiven Angriffen beobachtet und in den KEV-Katalog der CISA aufgenommen. Darüber hinaus wurden zwei potenziell ausnutzbare Schwachstellen in den Chips der M-Serie von Apple mit den Bezeichnungen SLAP und FLOP entdeckt, denen jedoch noch keine CVEs zugeordnet wurden. Bei SLAP machten sich die Forscher die Schwachstellen des Chips zunutze, um die Heap-Allokationstechniken von Safari WebKit auszunutzen und JavaScript-String-Metadaten zu manipulieren, um spekulative Out-of-bounds-Lesevorgänge zu ermöglichen, sodass sie sensible DOM-Inhalte aus anderen geöffneten Website-Tabs extrahieren konnten. Für FLOP demonstrierten die Forscher, dass sensible Daten aus Safari und Google Chrome gestohlen werden können, indem sie die Javascript-Typüberprüfung in Safari WebKit und die Site Isolation von Chrome über WebAssembly umgehen.

Außerdem wurden fünf schwerwiegende Sicherheitslücken veröffentlicht, die Microsoft Office für macOS betreffen. Jede von ihnen kann einem Angreifer Remote Code Execution (RCE) ermöglichen. Zu den betroffenen Produkten gehören Microsoft Word (CVE-2025-21363), Excel (CVE-2025-21354 und CVE-2025-21362) und OneNote (CVE-2025-21402) für macOS. Es sind zwar noch keine technischen Details zu diesen Schwachstellen verfügbar, aber alle haben hohe CVSS-Bewertungen und Benutzer sollten so bald wie möglich ein Update durchführen.

Der Greenbone Enterprise Feed erkennt fehlende macOS-Sicherheitsupdates und viele andere CVEs, die Anwendungen für macOS betreffen, einschließlich der fünf neu entdeckten CVEs in Microsoft Office für Mac.

6 CVEs in Rsync mit Server- und Client-Übernahme

Die Kombination von zwei neu entdeckten Schwachstellen kann die Ausführung von beliebigem Code auf anfälligen Rsyncd-Servern ermöglichen, während nur anonymer Lesezugriff besteht. CVE-2024-12084, ein Heap Buffer Overflow, und CVE-2024-12085, ein Informationsleck, sind die Übeltäter. Öffentliche Mirrors, die Rsyncd verwenden, stellen das höchste Risiko dar, da sie von Natur aus keine Zugriffskontrolle haben.

Die Forscher fanden außerdem heraus, dass ein als Waffe eingesetzter Rsync-Server beliebige Dateien auf verbundenen Clients lesen und schreiben kann. Dies kann den Diebstahl sensibler Informationen und möglicherweise die Ausführung von Schadcode durch Änderung ausführbarer Dateien ermöglichen.

Hier ist eine Zusammenfassung der neuen Schwachstellen, geordnet nach CVSS-Schweregrad:

CVE-2024-12084 (CVSS 9.8 Kritisch): Unsachgemäße Handhabung der Prüfsummenlänge ermöglicht einen Heap Buffer Overflow und RCE.
CVE-2024-12085 (CVSS 7.5 Hoch): Uninitialisierte Stack-Inhalte können sensible Informationen preisgeben.
CVE-2024-12087 (CVSS 6.5 Medium): Die Path Traversal-Schwachstelle in Rsync ermöglicht Zugriff auf nicht autorisierte Dateien.
CVE-2024-12088 (CVSS 6.5 Medium): Path Traversal über die Option –safe-links kann beliebiges Schreiben von Dateien außerhalb des vorgesehenen Verzeichnisses ermöglichen.
CVE-2024-12086 (CVSS 6.1 Medium): Rsync-Server können beliebige Client-Dateien durchsickern lassen, wenn sie von einem Client auf einen Server kopiert werden.
CVE-2024-12747 (CVSS 5.6 Medium): Unsachgemäße Handhabung symbolischer Links führt zu einem Wettlauf, der die Erweiterung von Privilegien ermöglicht, wenn ein Admin-Benutzer den Rsyncd-Prozess kontrolliert.

Insgesamt stellen diese Schwachstellen ein ernsthaftes Risiko für RCE, Datenexfiltration und die Installation dauerhafter Malware sowohl auf Rsyncd-Servern als auch auf ahnungslosen Clients dar. Benutzer müssen auf die gepatchte Version aktualisieren, auf allen Systemen, die rsync verwendet haben, gründlich nach Indicators of Compromise (IoC) suchen und möglicherweise die Infrastruktur für die Dateifreigabe neu einrichten. Greenbone ist in der Lage, alle bekannten Schwachstellen in Rsync und die Nichteinhaltung wichtiger Sicherheitsupdates zu erkennen.

CVE-2025-0411: 7-Zip bietet MotW-Bypass

Am 25. Januar 2025 wurde die Sicherheitslücke CVE-2025-0411 (CVSS 7.5 Hoch) veröffentlicht, die das Archivierungsprogramm 7-Zip betrifft. Die Schwachstelle ermöglicht die Umgehung der Windows-Sicherheitsfunktion Mark of the Web (MotW) über speziell gestaltete Archivdateien. MotW kennzeichnet Dateien, die aus dem Internet heruntergeladen werden, mit einem Zone Identifier alternate data stream (ADS) und warnt, wenn sie aus einer nicht vertrauenswürdigen Quelle stammen. 7-Zip-Versionen vor 24.09 geben das MotW-Flag jedoch nicht an Dateien in verpackten Archiven weiter. Die Ausnutzung der Sicherheitslücke CVE-2025-0411, um die Kontrolle über das System eines Opfers zu erlangen, erfordert menschliche Interaktion. Die Zielpersonen müssen ein trojanisiertes Archiv öffnen und dann eine darin enthaltene bösartige Datei ausführen.

Interessanterweise haben Untersuchungen von Cofense ergeben, dass Regierungswebsites auf der ganzen Welt über CVE-2024-25608, eine Schwachstelle in der digitalen Plattform Liferay, für Credential-Phishing, Malware und Command-and-Control-Operationen (C2) missbraucht werden. Diese Schwachstelle ermöglicht es Angreifern, Benutzer von vertrauenswürdigen .gov-URLs auf bösartige Phishing-Seiten umzuleiten. Die Kombination der Umleitung von einer vertrauenswürdigen .gov-Domäne mit der 7-Zip-Schwachstelle birgt erhebliches Potenzial für die heimliche Verbreitung von Malware.

In Anbetracht der Risiken sollten Nutzer manuell auf die Version 24.09 aktualisieren, die seit Ende 2024 verfügbar ist. Wie bereits in der Einleitung erwähnt, liegt die Sicherheit der Software-Lieferkette oft in einer Grauzone, da wir alle von Software abhängig sind, die sich unserer Kontrolle entzieht. Bemerkenswert ist, dass 7-Zip vor der Veröffentlichung von CVE-2025-0411 die Benutzer nicht auf eine Sicherheitslücke hingewiesen hat. Und obwohl 7-Zip Open-Source ist, enthält das GitHub-Konto des Produkts nicht viele Details oder Kontaktinformationen für eine verantwortungsvolle Offenlegung.

Darüber hinaus hat das CVE eine DFN-CERT– und eine BSI CERT-Bund-Meldung ausgelöst [1][2]. Greenbone kann das Vorhandensein von anfälligen Versionen von 7-Zip erkennen.

Zusammenfassung

Diese Ausgabe unseres monatlichen Threat Reports befasst sich mit wichtigen Sicherheitsverletzungen aus dem Jahr 2024 und neu entdeckten kritischen Sicherheitslücken im Januar 2025. Die Software-Lieferkette stellt für alle großen und kleinen Unternehmen ein erhöhtes Risiko dar, sowohl durch Open-Source- als auch durch Closed-Source-Produkte. Open-Source-Software bietet jedoch Transparenz und die Möglichkeit für die Beteiligten, sich proaktiv für ihre eigenen Security-Resultate einzusetzen, entweder gemeinsam oder unabhängig. Obwohl die Kosten für Cybersicherheit beträchtlich sind, werden fortschreitende technische Fähigkeiten zunehmend ein entscheidender Faktor für die Sicherheit von Unternehmen und Staaten sein. Das Glück begünstigt diejenigen, die vorbereitet sind.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

Open Source ist bei der überwiegenden Mehrheit der Firmen, Softwarehersteller und -anbieter unaufhörlich auf dem Vormarsch. Mit diesem Siegeszug steigt aber auch die Bedeutung der Überwachung der Supply Chain, also der „Lieferkette“ der eingesetzten Software, die Dritte gemäß den Open-Source-Traditionen entwickelt haben. Doch nicht jeder, der Open-Source-Software benutzt, beachtet dabei alle bewährten Regeln. Greenbone kann helfen, solchen Fehlern auf die Schliche zu kommen. Dieser Blogpost erklärt das Problem und wie es sich vermeiden lässt.

Schwachstellen in Log4j, Docker oder NPM

Ende 2021 schlug das Bundesamt für Sicherheit in der Informationstechnik (BSI) wegen einer aus der Ferne ausnutzbaren Schwachstelle in der Logging-Bibliothek Log4j offiziell Alarm – sogar die Tagesschau berichtete. Prompt meldeten sich damals die Kritiker von Open-Source-Software zu Wort: Quelloffene Software wie Log4j sei implizit unsicher und in der Supply Chain anderer Programme ein praktisch unkalkulierbares Risiko.

Zwar hatten die Open-Source-Entwickelnden selbst das Problem binnen weniger Stunden gefixt, dennoch schlummern in zahllosen kommerziellen Produkten noch heute veraltete Versionen von Log4j – ohne Chance darauf, jemals ausgetauscht zu werden. Das ist kein Einzelfall: kürzlich sorgte die Geschichte eines Entwicklers für NPM (Node Package Manager, ein Softwarepaket-Format für den Webserver Node.js) für Aufsehen, der mit seinem eigentlich gut gemeinten Protest gegen den Krieg in der Ukraine das Vertrauen in die Open-Source-Supply-Chain und die Entwicklungsgemeinschaft massiv erschütterte.

Open Source in der Kritik

Es war nicht das erste Mal, dass NPM zum Ziel wurde. Schon Ende 2021 war der Paketmanager von Angriffen betroffen. Damals veröffentlichte der Entwickler Oleg Drapeza einen Fehlerbericht bei GitHub, nachdem er bösartigen Code zum Abfischen von Passwörtern in der Bibliothek UAParser.js gefunden hatte. Stück für Stück konnte der ursprüngliche Autor der Software, Faisal Salman, rekonstruieren, dass sich jemand in seinen Account im Paketsystem von NPM gehackt und dort Schadcode hinterlegt hatte. Das Problem: UAParser.js ist ein Modul für Node.js und kommt in Millionen von Setups weltweit zum Einsatz. Entsprechend gewaltig war der Kreis der betroffenen Nutzenden.

Wieder hieß es seitens der Open-Source-Kritischen, quelloffene Software wie UAParser.js sei implizit unsicher und in der Supply Chain anderer Programme ein praktisch unkalkulierbares Risiko. Mehr noch: Open-Source-Entwickelnde, so der explizit vorgetragene Vorwurf, bänden externe Komponenten wie Bibliotheken oder Container-Images viel zu unvorsichtig ein und verschwendeten kaum einen Gedanken an die damit verbundenen Sicherheitsimplikationen. Aus diesem Grund sei ihr Werk latent anfällig für Sicherheitsangriffe, vor allem eben in der Open-Source-Supply-Chain. Alyssa Shames diskutiert auf docker.com das Problem am Beispiel von Containern und schildert dabei ausführlich die Gefahren.

Die Schattenseiten des Basars

Tatsächlich haben DevOps und Cloud Native die Arbeitsweise in der Entwicklung in den vergangenen Jahren stark beeinflusst. In der Community existierende Komponenten in die eigene Anwendung einzubinden statt vergleichbare Funktionalität selber neu zu programmieren ist dabei Teil des Selbstverständnisses der gesamten Open-Source-Szene. Diese Community und ihr Angebot lassen sich mit einem Basar vergleichen, mit allen Vor- und Nachteilen. Viele Entwickelnde stellen ihre Programme gerade deshalb unter eine offene Lizenz, weil sie die Beiträge der anderen „Basarbesuchenden“ schätzen. Auf diese Weise können andere, die ähnliche Probleme haben, profitieren – unter denselben Bedingungen – und müssen das Rad nicht neu erfinden. Galt das früher mehr oder weniger nur für einzelne Bestandteile von Software, haben Cloud und Container dazu geführt, dass Entwickelnde inzwischen nicht mehr nur einzelne Komponenten übernehmen, sondern gleich ganze Images. Dabei handelt es sich um Softwarepakete, eventuell sogar inklusive Betriebssystem, die auf der eigenen Infrastruktur dann schlimmstenfalls ungeprüft starten.

Ein wachsendes Risiko?

In der Tat ist der mögliche Angriffsvektor dabei deutlich größer als zuvor und wird aktiv ausgenutzt. Laut Dev-Insider beispielsweise ist im vergangenen Jahr „die Zahl der Angriffe auf Open-Source-Komponenten […] von Software-Lieferketten laut einer Studie des Anbieters Sonatype […] um 430 Prozent gestiegen.“ Das bestätigt auch der Risiko-Analyse-Bericht von Synopsis, der zudem feststellt, „dass kommerzieller Code heute hauptsächlich aus Open-Source-Software besteht.“ Schon 2020 berichtete der Cloud-Native-Experte Aquasec auf seinem Blog von Angriffen auf die Docker-API, über die Cyber-Kriminelle Cryptomining in Docker-Images betrieben.

Allerdings sind Entwickelnde, die auf Open-Source-Komponenten zurückgreifen oder aus der Open-Source-Community stammen, nicht annähernd so unaufmerksam, wie es solche Meldungen suggerieren. Anders etwa als in proprietären Produkten, in denen lediglich die Mitarbeitenden eines Unternehmens den Code im Auge haben können, schauen in Open-Source-Projekten viele Menschen auf den verwalteten Quelltext. Dass dabei regelmäßig auch Sicherheitslücken wie im Fall von Log4j, Docker oder NPM ans Tageslicht kommen, liegt auf der Hand. Hier beweist die Open-Source-Szene dass sie gut funktioniert, nicht etwa dass ihre Software grundsätzlich unsicher(er) wäre.

Nicht schutzlos ausgeliefert

Ein großes Problem ist dagegen – unabhängig, ob Open-Source- oder proprietäre Software – die mangelnde Weitsicht bei der Update- und Patch-Strategie mancher Anbieter. Nur deshalb finden sich vielerorts Geräte mit veralteten, oft angreifbaren Softwareversionen, die als Scheunentor für Angreifende dienen können. Die Greenbone Enterprise Appliance, die professionelle Produktlinie von Greenbone, hilft dabei, solche Lücken zu finden und sie zu schließen.

Hinzu kommt, dass komplexe Sicherheitslecks wie die oben beschriebenen in Log4j oder UAParser.js eher die Ausnahme als die Regel darstellen. Die meisten Angriffe erfolgen mit deutlich simpleren Methoden: In den fertigen Images für Docker-Container im Docker Hub etwa findet sich regelmäßig Malware, die aus einer Datenbank den oben beschriebenen Bitcoin-Miner macht. Auch diesem Treiben stehen Entwickelnde, die Open-Source-Komponenten integrieren, jedoch keineswegs schutzlos gegenüber. Längst gibt es Standards, die Angriffe der beschriebenen Art verhindern, beispielsweise fertige Container-Images nur direkt beim Hersteller einer Lösung zu beziehen oder sie besser gleich per CI/CD-Pipeline selbst zu bauen. Ganz grundsätzlich steht Entwickelnden obendrein ein gesundes Misstrauen gut zu Gesicht, etwa wenn Software aus einer Quelle kommt, die erkennbar nicht jene des Herstellers ist.

Supply-Chain-Überwachung bei Greenbone

Dass Open-Source-Software im eigenen Programm kein unkalkulierbares Risiko ist, zeigt Greenbone in seinen Produkten, den Greenbone Enterprise Appliances. Im Unternehmen gelten eine Reihe von Richtlinien, die das Thema Supply Chain in der Softwareentwicklung in den gesamten Entwicklungszyklus einbinden. Neben umfangreichen Funktionstests unterzieht Greenbone seine Produkte dabei beispielsweise automatisierten Tests mit gängigen Sicherheitswerkzeugen. Wer bei Greenbone kauft, verlässt sich zu Recht auf das starke Gespann aus Open-Source-Transparenz und sorgfältigster Qualitätssicherung des Herstellers, ein Aufwand den sich nicht generell alle Open-Source-Projekte leisten können.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

Schlagwortarchiv für: Software Supply Chain

Januar 2025 Threat Report: Der Lohn der Vorbereitung