Open-Source-Sicherheit verständlich erklärt

Open-Source-Software erfreut sich seit einigen Jahren wachsender Beliebtheit, insbesondere weil sie auf Kooperation und Offenheit setzt. Das macht Entwicklern das Leben leichter – was leider auch für Hacker und andere Angreifer gilt. Denn sobald eine Schwachstelle bekannt wird, werden sämtliche Anwendungen, in denen der betroffene Code vorkommt, zu potenziellen Angriffszielen. Bekannte Beispiele wie Log4j und Apache Struts zeigen, dass sich aus diesem Umstand ein durchaus ernstzunehmendes Risiko für Unternehmen ergibt.

Folglich sollten Anfälligkeit und Abhängigkeiten von Open-Source-Komponenten ständig überwacht werden. Doch es ist keineswegs einfach, den Überblick über alle in einer Anwendung verwendeten Open-Source-Komponenten zu behalten. Und ihre manuelle Überprüfung anhand von Datenbanken mit bekannten Schwachstellen ist äußerst mühselig. Durch eingebettete Abhängigkeiten wird das sogar noch komplizierter, da nicht nur der selbst geschriebene, sondern auch der gesamte verwendete Open-Source-Code – mitsamt darin enthaltenen Abhängigkeiten – sicher sein muss.

In diesem Beitrag wird deshalb zunächst der Begriff der Open-Source-Sicherheit definiert. Anschließend werden die Risiken beschrieben, die sich aus quelloffener Software ergeben. Und schließlich werden Tools und Prozesse vorgestellt, mit denen sich diese Risiken eindämmen lassen.

Was versteht man unter Open-Source-Sicherheit?

Die Open-Source-Sicherheit umfasst einerseits die Risiken und Schwachstellen, die sich durch Drittanbieter-Software ergeben, andererseits die Tools und Prozesse, um Open-Source-Software zu schützen. Mit bestimmten Sicherheitstools lässt sich die Erkennung quelloffener Bibliotheken und Abhängigkeiten im Quelltext automatisieren. Zudem kann analysiert werden, wie diese in den Anwendungen eingesetzt werden. Außerdem können Warnungen und Korrekturempfehlungen ausgegeben werden, sobald eine Schwachstelle erkannt wird. Mit Verfahren wie der Zwei-Faktor-Authentifizierung lässt sich zusätzlich noch eine zweite Schutzschicht anlegen.

Vier Vorteile von Open-Source-Software

Geschäftliche Anforderungen führen zu immer kürzeren Entwicklungs- und Releasezyklen. Deshalb nutzen Entwickler zunehmend Open-Source-Software, um den eigenen Code zu ergänzen.

Deren Beliebtheit beruht auf konkreten Vorteilen:

1. Kosten: Open-Source-Software kann uneingeschränkt verwendet und verändert werden. Die Softwarepflege wird dabei von einer weltweiten Community aus Entwicklern und Ehrenamtlichen übernommen. Selbst kommerzielle Open-Source-Softwarepakete sind gegenüber einer kompletten Eigenentwicklung noch relativ kostengünstig.

2. Benutzerfreundlichkeit: Open-Source-Software ist frei verfügbar, komplett offen und kann für die eigenen Anforderungen problemlos weiterentwickelt werden. So bleibt mehr Zeit für die wirklich wichtigen Dinge.

3. Qualität: Da Open-Source-Code von einer ganzen Entwickler-Community geschrieben, verwendet und geprüft wird, gibt es – zumindest theoretisch – weniger Fehler, weil Schwachstellen viel schneller erkannt und behoben werden können.

4. Tempo: Mit Open-Source-Software lassen sich wichtige Unternehmensanwendungen deutlich schneller auf den Markt bringen.

Die Beliebtheit von Open-Source-Software hat sich in einigen Fällen mehr als verdoppelt. Das wiederum führt zu Skaleneffekten, da immer mehr Tools und immer besser ausgebildete Entwickler verfügbar sind. Dabei gilt es allerdings, das richtige Gleichgewicht zwischen Offenheit, Anfälligkeit, Flexibilität und Qualität zu finden.

Abbildung 1: Anzahl neuer Pakete je Ökosystem und Jahr

Denn wer Open-Source-Software nutzt, verlässt sich letztlich darauf, dass Fremde den Code pflegen, auf dem die eigenen Anwendungen basieren. Deshalb sollte man Systeme und Tools verwenden, die diese potenziellen Nachteile minimieren.

Drei Sicherheitsrisiken von Open-Source-Software

So gut wie alle cloudnativen Anwendungen beruhen auf Open-Source-Komponenten. Doch da für deren Pflege und Sicherheit niemand wirklich zuständig ist, bergen sie zahlreiche Risiken, auf die wir im Folgenden näher eingehen.

1. Schwachstellen in Open-Source-Abhängigkeiten

Es gibt sowohl bekannte als auch unentdeckte Schwachstellen. Zu den bekannten zählen alle, denen bereits eine CVE-Nummer (Common Vulnerabilities and Exposures) zugeordnet wurde und die im Internet oder in öffentlichen bzw. privaten Datenbanken veröffentlicht wurden. Grundsätzlich gilt dabei: Je bekannter eine Schwachstelle ist, desto dringender sollte sie angegangen werden.

Neben der Erkennung von Schwachstellen ist es außerdem wichtig, alle in einer Anwendung enthaltenen Open-Source-Abhängigkeiten im Blick zu behalten. Transitive Abhängigkeiten – also Abhängigkeiten, die ihrerseits Abhängigkeiten beinhalten – sind hier von besonderer Bedeutung, da sie für Sicherheitstools und bei Audits nur schwer zu erkennen sind. Deshalb sollte man Tools und Prozesse verwenden, die sämtliche Abhängigkeiten in einer Anwendung erkennen und überprüfen können.

2. Lizenzrisiken

Entwickler sollten sich mit den verschiedenen Software-Lizenztypen in verwendeten Open-Source-Paketen vertraut machen. Denn nur so ist sichergestellt, dass beim Programmieren alle Lizenzbedingungen eingehalten werden. Dazu ist allerdings deren genaue Kenntnis und konsequente Durchsetzung im gesamten Projektverlauf erforderlich. Zu diesem Zweck benötigen Unternehmen einen lückenlosen Überblick über die genaue Verwendung sämtlicher Komponenten, die Open-Source-Lizenzen unterliegen. Zudem sollten diese Lizenzen laufend auf etwaige Änderungen durch die Rechteinhaber überprüft werden.

3. Open-Source-Pakete ohne Verantwortliche

Für Open-Source-Pakete ist meist nur ein bestimmter Entwickler oder ein kleines Team zuständig – wenn überhaupt. Und bei Open-Source-Projekten aus der Community gibt es meist überhaupt keine klare Verantwortungsstruktur, was die Softwarepflege betrifft. Die Software muss so wie sie ist, übernommen werden. Die Verantwortung liegt also ganz bei den Entwicklern, die die Software verwenden: Sie müssen die nötige Zeit und Ressourcen investieren, um die Codesicherheit zu gewährleisten. Doch glücklicherweise gibt es einige hilfreiche Tools, die diese Aufgabe vereinfachen. Eines davon ist der Snyk Advisor, der Pakete nach Maintenance-Level, Community, Sicherheitsprofil und Beliebtheit analysiert. So ist immer absolut klar, wie es um die Integrität der verwendeten Open-Source-Pakete bestellt ist.

Sie möchten mehr über die Risiken quelloffener Software erfahren? Dann empfehlen wir Ihnen unseren Beitrag zu den 5 potenziellen Risiken von Open-Source-Software.

Interessante Statistiken aus dem Open-Source-Sicherheitsbericht

Daten sind Wissen. Deshalb hat Snyk Entwickler und Sicherheitsexperten nach ihren größten Bedenken hinsichtlich der Open-Source-Sicherheit, aktueller Trends bei Schwachstellen in verschiedenen Paketen und Container-Images und Verfahren zum Schutz ihrer Software gefragt. Die Ergebnisse dieser Befragung finden sich im Open-Source-Sicherheitsbericht 2020. Hier einige Auszüge:

Open Source wird immer beliebter

Open-Source-Ökosysteme gewinnen zunehmend an Bedeutung. Ursache dafür sind vor allem die Marktnachfrage und wirtschaftliche Gründe. Ganz oben in der Rangliste steht npm mit 33 % Wachstum gegenüber dem Vorjahr und 1,8 Mio. Paketen (Stand: März 2022). Die meisten Open-Source-Schwachstellen werden weiterhin in indirekten Abhängigkeiten entdeckt:

• npm: 86 %

• Ruby: 81 %

• Java: 74 %

Die Sicherheitsverantwortung verlagert sich zunehmend auf die Entwickler

Die Umfrageteilnehmer betrachten die Sicherheit als gemeinsame Aufgabe aller Beteiligten:

• 85 % sehen die Verantwortung für die Open-Source-Sicherheit bei den Entwicklern.

• 55 % sagen, dass ihr Security-Team verantwortlich sei.

• 35 % geben an, dass Operations eine wichtige Rolle spiele.

Weniger neue Sicherheitslücken

In allen Bereichen werden 20 % weniger neue Schwachstellen gemeldet, wobei Cross-Site-Scripting (XSS) am häufigsten vorkommt.

Abbildung 2: Anzahl festgestellter Sicherheitslücken seit 2014

Schwierigkeiten mit Containern und Orchestrierung

In den aktuellsten offiziellen Base-Images finden sich häufig bekannte Schwachstellen. Das gilt insbesondere für das offizielle Node-Image mit fast 700 bekannten Sicherheitslücken. Mehr als 30 % der Befragten prüfen Kubernetes-Manifeste eigenen Angaben zufolge nicht auf unsichere Konfigurationen. Und auch sicherheitsbezogene Ressourcenkontrollen in Kubernetes werden nicht konsequent durchgeführt.

Abbildung 3: Anzahl der Schwachstellen in offiziellen Container-Images

Trends in der Open-Source-Sicherheit 2022

Im vergangenen Jahr gab es einige vorherrschende Trends im Bereich der Open-Source-Sicherheit. Hierzu zählen unter anderem die Sicherheit in der Lieferkette, Verantwortungsverlagerungen, ein Rückgang neu entdeckter Sicherheitslücken, der Rückgriff auf Freiwillige bei der Pflege von Open-Source-Komponenten sowie veränderte Erwartungen bei der Korrektur von Schwachstellen.

Immer mehr Angriffe auf die Lieferketten

Softwarekomponenten von Drittanbietern liegen in einem zentralen Repository, das die Software-Lieferkette bildet. Und die bietet eine große Angriffsfläche, da Hacker Schwachstellen in der Entwicklungspipeline ausnutzen können, ohne Änderungen an den Software-Repositorys vornehmen zu müssen. So können sie beispielsweise Designmängel mithilfe von Dependency- oder Namespace-Confusion-Angriffen ausnutzen oder bei Komponenten von Drittanbietern ansetzen, um Benutzerdaten zu kompromittieren und sich Zugang zu internen Systemen zu verschaffen.

Jeder Link stellt dabei eine potenzielle Angriffsfläche dar. Deshalb sollte stets die gesamte Lieferkette vom Code bis zur Implementierung abgesichert werden. Sicherheitslücken entlang der Lieferkette sind dabei kein neues Problem. Sie waren bereits 2021 ein heiß diskutiertes Thema und werden im Cybersecurity-Dekret von US-Präsident Joe Biden gleich mehrfach erwähnt.

Trend zur gemeinsamen Sicherheitsverantwortung

Wer trägt eigentlich die Sicherheitsverantwortung? Zu den interessantesten Entwicklungen in dieser Frage zählt der Trend hin zur Verantwortungsaufteilung zwischen Entwicklung, Security und Operations.

Die zunehmende Verlagerung hin zu DevSecOps ist zwar durchaus positiv zu bewerten. Doch 47 % der Umfrageteilnehmer geben an, keine konkreten Programme für eine geteilte Verantwortung zu befolgen. Und nur 15 % setzen das Security-Champions-Programm um, das laut OWASP Software Assurance Maturity Model (SAMM) als zentraler Sicherheitsbaustein gilt. Das zeigt, dass derzeit noch eine beträchtliche Lücke zwischen dem Bedarf an einer gemeinsamen Verantwortung und deren tatsächlicher Umsetzung klafft.

Dem Puppet-Bericht „State of DevOps“ zufolge gehen mit zunehmender DevOps-Erfahrung auch ausgefeiltere Sicherheitsverfahren einher.

„Je besser die DevOps-Verfahren sind, desto besser ist es auch um DevSecOps bestellt. Unternehmen, die in dieser Hinsicht besonders weit sind, verlagern das Thema Sicherheit stärker an den Anfang, meist in die Bereiche Anforderungsanalyse (51 %), Konzeption (61 %), Build (53 %) und Tests (52 %). Demgegenüber verorten viele Unternehmen aus dem Mittelfeld Sicherheitsbelange in planmäßigen Produktionsprüfungen (48 %) sowie bei Problemmeldungen in der laufenden Produktion (45 %).

Puppet-Bericht „State of DevOps Report 2021“

Weniger Sicherheitsrisiken

Ein überraschender Befund des Berichts lautet, dass insgesamt 20 % weniger neue Sicherheitslücken festgestellt werden. Dass diese Entwicklung in Zeiten fällt, in denen Open-Source-Ökosysteme ein exponentielles Wachstum verzeichnen, überrascht umso mehr.

Eine eindeutige Ursache für diesen Trend lässt sich nicht feststellen. Eine mögliche Erklärung könnten allerdings das größere Sicherheitsbewusstsein, verbesserte Verfahren und leistungsstarke Tools sein.

Wir werden die Entwicklung definitiv im Blick behalten. Noch dürfte es allerdings zu früh sein, um Sicherheitskontrollen und entsprechende Verfahren auf die leichte Schulter zu nehmen.

Open-Source-Maintainer kontra Unternehmen

In Zukunft könnte es vermehrt zu Spannungen zwischen Open-Source-Maintainern und Unternehmen kommen, denen erstere vorwerfen, ohne finanzielle Gegenleistung Profit mit ihrer Software zu machen.

So kommt eine Umfrage von Tidelift von 2021 zu dem Ergebnis, dass von 400 Open-Source-Maintainern ganze 46 % unbezahlt arbeiten und gerade einmal 26 % mehr als 1.000 USD im Jahr erhalten. Mehr als jeder zweite (59 %) hat deshalb bereits das Handtuch geworfen oder in Erwägung gezogen, seine Tätigkeit als Projekt-Maintainer an aufzugeben. Knapp die Hälfte der Befragten führt zudem die unzureichende Vergütung als Hauptgrund für die Frustration mit dieser Aufgabe an.

Diese Gemengelage zeitigt reale Konsequenzen. So veröffentlichte der Maintainer des beliebten colors-Pakets von npm im Januar 2022 fehlerhaften Code, der Endlosschleifen verursachte und die Nutzung des Pakets unmöglich machte.

Die schadhafte Paketversion wurde über 95.000 Mal heruntergeladen. Colors kommt in zahlreichen anderen Projekten zum Einsatz wie dem Prompt Command Line Helper (ca. 500.000 Downloads pro Woche) und AWS-CDK von AWS (ca. 2 Mio. Downloads pro Woche). Es besteht also durchaus Anlass zur Sorge.

Ein ähnlicher Vorfall ereignete sich mit dem beliebten Package Faker von npm, für den derselbe Maintainer zuständig ist. Dabei verkündete dieser, dass er für das Projekt, das von vielen internationalen Konzernen verwendet wird, nicht mehr unbezahlt als Maintainer zur Verfügung stehen werde.

Sicherheitslücken werden nicht schnell genug geschlossen

Bei der Umfrage 2020 Open Source Security gaben 47 % der Befragten an, Sicherheitslücken sollten innerhalb einer Woche nach ihrer Entdeckung geschlossen werden. 18 % erwarteten dies sogar binnen eines Tages.

Abbildung 4: Erwarteter Zeitaufwand für die Beseitigung von Open-Source-Schwachstellen

Tatsächlich werden allerdings nur 35 % aller Schwachstellen in weniger als 20 Tagen behoben, 36 % sogar erst nach über 70 Tagen. Der Durchschnittswert liegt hier bei ganzen 68 Tagen.

Ganz offensichtlich braucht es also ein gewisses Erwartungsmanagement bei der Risikoexposition. Unternehmen müssen wissen, wie lange die Beseitigung bekannt gewordener Sicherheitslücken tatsächlich dauert. Dies gilt umso mehr, wenn nur ein einzige Maintainer zuständig ist.

Wichtige Kennzahlen für Ihre Open-Source-Sicherheitsstrategie

Als Ausgangspunkt empfiehlt sich die sorgfältige Erhebung bestimmter Kennzahlen zu den jeweils verwendeten Open-Source-Bibliotheken. Dazu zählen u. a. Folgende:

• Zeitraum von der Entdeckung bis zur Beseitigung von Sicherheitslücken

• durchschnittlicher Zeitaufwand für die Zusammenführung von Pull-Requests nach der Ticketerstellung

• Zeitaufwand für die eigenständige Code-Korrektur

Wer diese Eckdaten kennt, kann sich ein genaueres Bild von der eigenen Reaktionsstärke machen. Auf dieser Grundlage lässt sich dann eine Strategie für das Komponentenmanagment sowie die Erkennung und Beseitigung von Schwachstellen aufstellen.

Eine weitere Empfehlung lautet, proaktiv mit den verwendeten Open-Source-Paketen umzugehen. Pull-Requests sollten an die jeweiligen Maintainer weitergegeben werden, damit diese die vorhandenen Probleme kennen. Machen Sie sich außerdem klar, welchen Stellenwert Open Source für Ihr Unternehmen besitzt, und entwickeln Sie einen Business Case für die systematische Verwaltung Ihrer Open-Source-Software.

Sechs Anforderungen an Sicherheitstools für Open Source

Sicherheitstools spielen in jeder Security-Strategie für Open Source eine Schlüsselrolle. Denn sie ermöglichen die automatische Prüfung des Codes auf bekannte Schwachstellen und gleichen ihn mit Referenzdatenbanken ab. So lassen sich die möglichen Folgen von Sicherheitsrisiken besser abschätzen und geeignete Gegenmaßnahmen formulieren. Außerdem können Sicherheitstools die laufende Programmierung überwachen und Security-, Lizenz- und Governance-Belange in die Softwareentwicklung einbinden.

1. Inventarisierung von Paketen und Schwachstellen

Da transparente Open-Source-Komponenten und -Abhängigkeiten sicherheitsrelevant sind, braucht es eine Möglichkeit, diese automatisch zu erfassen und zu evaluieren. Denn nur so behält man seine Open-Source-Umgebung im Griff. Am besten ist dafür ein automatisiertes Verfahren, das die Komponenten in den CI/CD-Pipelines identifiziert und auf ihr Gefahrenpotenzial hin überprüft. So lässt sich die Frage beantworten, ob anfällige Komponenten tatsächlich in der jeweiligen Anwendung zum Einsatz kommen.

2. Lizenzmanagement

Sicherheitstools können extern wie intern erstellten Code bereits auf Schwachstellen und Lizenzrisiken prüfen, während er noch in der Entwicklungsumgebung geschrieben wird. So müssen keine Code-Repositorys mehr gescannt werden.

3. Automatisierung

Sicherheitstools bieten ein automatisches Monitoring und eine automatische Schwachstellenerkennung. Bei einem Sicherheitsvorfall schätzen sie dessen mögliche Folgen ab und ermitteln dann eine angemessene Reaktion. Um die entsprechenden Abläufe zu automatisieren, kann man zudem Richtlinien für Fixes, Requests, Patches und Dependency-Upgrades festlegen.

4. Direkte Einbindung in Entwickler-Tools, Workflows und Automatisierungs-Pipelines

Werden Sicherheitsfunktionen direkt in die Tools und Prozesse der Entwickler integriert, lässt sich die Codesicherheit noch weiter optimieren. Mithilfe von Plugins können Fixes dann unmittelbar per CLI bzw. CDE erfolgen. Und mit GitHub-Integrationen lassen sich Repositorys, Projekte und Pull-Requests testen und Fixes mithilfe automatischer Pull-Requests anwenden.

5. Aktuelle, erweiterte Datenbanken, die über bekannte CVEs hinausgehen

Geeignete Sicherheitstools können mehr als öffentliche Datenbanken über bekannte Schwachstellen und ermöglichen so den Aufbau eigener, kuratierter Datenbanken. Darin enthalten sind dann nicht nur Sicherheitslücken mit CVE-Nummer, sondern auch solche, die in Sicherheitshinweisen, Ticketsystemen, Foren und sozialen Netzwerken erwähnt werden.

6. Laufendes Projektmonitoring

Die Sicherheitstools sollten in der Lage sein, die Anwendungen in der Produktion im Blick zu behalten und Angriffe auf Schwachstellen automatisch zu verhindern. So entstehen Anwendungen, die sich wirksam selbst überwachen und gut gerüstet gegen etwaige Angriffe und Lizenzverstöße sind.

Weitere Informationen, wie Sie das richtige Sicherheitstool für Open-Source-Komponenten finden, erhalten Sie in unserem Leitfaden zur Auswahl geeigneter SCA-Tools.

Die sechs Snyk-Vorteile für Ihre Open-Source-Security

Snyk Open Source ist ein entwicklerfreundliches Sicherheitstool, das die Anwendungssicherheit in allen Phasen der Softwareentwicklung einbettet. So können Sie auf Open-Source-Software basierende Anwendungen erstellen und implementieren, während Ihr Code vor Sicherheits- und Lizenzrisiken geschützt wird.

1. DevSecOps-Kompatibilität

Snyk Open Source fügt sich ab der ersten Codezeile in den Softwareentwicklungszyklus ein. Und dank umfangreicher Investitionen in Integrationen erfolgen die Sicherheits- und Lizenzscans absolut reibungslos. So können Entwickler die Verantwortung für die Sicherheit ihrer Anwendungen übernehmen und effizient mit den Security- und Operations-Teams zusammenarbeiten.

Außerdem stellen wir im DevSecOps Hub Technologien, Prozesse und Experten vor, die Unternehmen beim Aufbau einer effizienten und sicheren DevOps-Kultur unterstützen können. In unserer DevSecOps Community bringen wir zudem Entwickler und Sicherheitsexperten in einem Support-Portal sowie bei Online- und Live-Veranstaltungen zusammen. Und unser Ambassador-Programm bietet Sicherheitsverantwortlichen einen direkten Draht zu Snyk.

2. Eingebettete Problembehebung in Entwickler-Workflows

Synk Open Source lässt sich in Entwicklertools wie Atlassian Bitbucket, Visual Studio Code, Maven Central, GitHub und JetBrains einbinden. So können Entwickler auf Snyk zugreifen und Sicherheitslücken sowie Lizenzverstöße mit dem Tool ihrer Wahl identifizieren.

3. Weniger Fehlalarme

Die Snyk-Sicherheitsexperten sorgen mit einer eigenen Datenbank für weniger False-Positives. Jeder einzelne Datenbankeintrag wird dabei ausgewertet, geprüft und mit einem CVSS-Score und Vektor versehen. Außerdem investieren wir aktiv in die Erkennung neuer Schwachstellen und erstellen (wenn möglich) detaillierte Übersichten mitsamt Code-Snippets.

4. Übersichtliche Abhängigkeitsdiagramme

Snyk erstellt mithilfe des Paketmanagers Ihrer Anwendung ein Baumdiagramm zu allen enthaltenen Abhängigkeiten und zeigt dieses in der Snyk-UI an. Sie erhalten einen Überblick darüber, welche Komponenten für ein bestimmtes Problem verantwortlich sind – selbst wenn es sich dabei um transitive Abhängigkeiten handelt. Außerdem können so automatische Software Bill of Materials (SBOM) direkt in den Entwickler-Workflows erstellt werden. Auf dieser Grundlage lässt sich dann mit dem SBOM Checker von Snyk nach Sicherheitslücken suchen.

5. Automatische Korrektur

Snyk empfiehlt innerhalb der CLI-, IDE- und CI/CD-Pipelines automatisch verfügbare Fixes. Liegen zu einer Abhängigkeit keine Fehlerbehebungen vor, erhalten Sie eine Benachrichtigung, sobald sich dies ändert oder neue Schwachstellen bekannt werden.

6. Governance und Lizenzfragen

Mit dem Snyk Open Source License Compliance Management können Sie Ihre Lizenzen dank der präzisen automatischen Richtliniendurchsetzung direkt in den Entwickler-Workflows koordinieren. So behalten Sie jeden einzelnen Schritt im Blick und sorgen dafür, dass Ihre Projekte nicht gegen Lizenzbedingungen verstoßen – von der ersten Codezeile bis zur fertigen Anwendung.

Häufig gestellte Fragen

Was versteht man unter Open-Source-Sicherheit?

Der Begriff der Open-Source-Sicherheit umfasst Risiken, mit denen Entwicklungs- und Sicherheitsteams bei der Ausführung von externem Open-Source-Code in ihren Anwendungen konfrontiert sind, sowie die Prozesse, Methoden und Tools zu deren Eingrenzung. In jüngster Vergangenheit haben Angriffe auf Schwachstellen in Open-Source-Code Unternehmen enorme Kosten verursacht. Daran zeigt sich überdeutlich, wie wichtig das Thema Open-Source-Sicherheit und entsprechende Sicherheitsstrategien tatsächlich sind.

Warum ist Open-Source-Sicherheit so wichtig?

Open Source ist eine wichtige Triebfeder der Digitalisierung und wird von Unternehmen jeder Größenordnung und in sämtlichen Branchen eingesetzt. Doch dadurch ergeben sich auch neue Gefahren. Diese anzuerkennen ist ein wichtiger erster Schritt, der jedoch von Investitionen in ein durchdachtes und laufend aktualisiertes Sicherheitskonzept flankiert werden sollte, das auch Sicherheitsprüfungen und ein kontinuierliches Monitoring vorsieht.

Welche Risiken ergeben sich durch Open Source?

Open-Source-Abhängigkeiten sind heutzutage in Anwendungen üblich. An Kontrolle und Transparenz fehlt es dagegen gänzlich. Zudem werden die entsprechenden Komponenten von Ehrenamtlichen außerhalb des Unternehmens gepflegt, die keinerlei Verpflichtung zu ihrer Aktualisierung oder Sicherheit unterliegen. Aufgrund ihrer öffentlichen Zugänglichkeit bekommen dabei auch Hacker oft schnell Wind von neuen Schwachstellen und nutzen diese bereitwillig aus. Und das sind nur einige der Risiken, die mit Open-Source-Software einhergehen.