Open-Source-Sicherheit erklärt

Open-Source-Software wird seit einigen Jahren aufgrund ihres kollaborativen und öffentlichen Charakters immer häufiger eingesetzt. Das macht sie sowohl für Entwickler als auch für Angreifer attraktiv. Sobald Angreifer feststellen, dass eine Anwendung für eine öffentlich bekannte Schwachstelle anfällig ist, können sie jede Anwendung angreifen, die mit diesem Open-Source-Code entwickelt wurde. Fälle wie die Schwachstellen in Log4j und Apache Struts zeigen, dass dies für Unternehmen ein reales und mitunter erhebliches Risiko darstellt.

Um dieses Risiko zu mindern, müssen Open-Source-Komponenten und -Abhängigkeiten unbedingt verwaltet werden. Es ist jedoch schwierig, den Überblick über alle in einer Anwendung verwendeten Open-Source-Komponenten zu behalten. Auch die manuelle Prüfung dieser Komponenten anhand von Datenbanken mit bekannten Schwachstellen ist mühsam. Verschachtelte Abhängigkeiten erschweren die Sache zusätzlich: Geschützt werden muss nicht nur der von Entwicklern geschriebene Code, sondern auch sämtlicher genutzter Open-Source-Code samt allen darin enthaltenen Abhängigkeiten.

In diesem Beitrag erklären wir, was Open-Source-Sicherheit bedeutet, gehen auf die Risiken von Open-Source-Software ein und stellen Tools und Prozesse vor, mit denen sich die Risiken für Unternehmen beim Einsatz von Open-Source-Software verringern lassen.

Was bedeutet Open-Source-Sicherheit?

Open-Source-Sicherheit umfasst die Risiken und Schwachstellen, die mit Software von Drittanbietern einhergehen, sowie die Tools und Prozesse, mit denen sich Open-Source-Software absichern lässt. Sicherheitstools können Open-Source-Bibliotheken und -Abhängigkeiten im Code automatisch aufspüren, analysieren, wie diese Komponenten in Anwendungen verwendet werden, und bei erkannten Schwachstellen Warnmeldungen oder Maßnahmen zur Behebung auslösen. Praktiken wie die Zwei-Faktor-Authentifizierung bieten eine zusätzliche Sicherheitsebene, um sich vor Sicherheitsverletzungen zu schützen.

4 Vorteile von Open-Source-Software

Die Anforderungen der Wirtschaft führen zu schnelleren Entwicklungs- und Release-Zyklen für Software. Um diesen Anforderungen gerecht zu werden, greifen Entwickler zunehmend auf Open-Source-Software zurück, um intern entwickelten Code zu ergänzen.

Ihre Beliebtheit beruht auf mehreren Faktoren:

1. Kosten: Entwickler können gemeinfreie Open-Source-Software kostenlos nutzen, verändern und weitergeben, während eine weltweite Community aus Entwicklern und freiwilligen Helfern an ihrer Wartung arbeitet. Selbst kommerzielle Open-Source-Softwarepakete sind im Vergleich zu den Kosten einer vollständigen Eigenentwicklung relativ günstig.

2. Benutzerfreundlichkeit: Dank des vorgefertigten und offenen Charakters von Open-Source-Software können Entwickler bereits vorhandenen Code für ihre spezifischen Anforderungen nutzen. So bleibt mehr Zeit für wichtigere Aufgaben.

3. Qualität: Da eine Community aus Entwicklern Open-Source-Code erstellt, nutzt und überprüft, gibt es theoretisch weniger Fehler: Schwachstellen werden schnell aufgedeckt und behoben.

4. Geschwindigkeit: Durch den Einsatz von Open-Source-Software können Entwickler wertvolle Geschäftsanwendungen schneller auf den Markt bringen.

In manchen Fällen hat sich die Nutzung von Open-Source-Software mindestens verdoppelt. Entwickler profitieren dabei von Skaleneffekten: Es stehen mehr Tools zur Verfügung und besser geschulte Entwickler kommen auf den Markt. Gleichzeitig bestehen Zielkonflikte zwischen Offenheit und Schwachstellen sowie Agilität und Qualität.

Abbildung 1: Jährlich neu erstellte Pakete nach Ökosystem

Wer Open-Source-Software nutzt, verlässt sich darauf, dass Unbekannte den Code warten, auf den die eigenen Anwendungen angewiesen sind. Deshalb sind Systeme und Tools entscheidend, mit denen sich mögliche Nachteile minimieren lassen.

3 Sicherheitsrisiken von Open-Source-Software

Fast alle cloudnativen Anwendungen setzen auf Open-Source-Komponenten. Da jedoch niemand für deren Wartung oder Sicherheit verantwortlich ist, birgt Open-Source-Software zahlreiche Risiken, darunter:

1. Schwachstellen in Open-Source-Abhängigkeiten

Dazu gehören bekannte und unbekannte Schwachstellen. Zu den bekannten Schwachstellen zählen solche, denen eine Common Vulnerabilities and Exposures (CVE)-Nummer zugewiesen wurde, die im Internet offengelegt oder in öffentlichen Schwachstellendatenbanken erfasst sind, sowie solche in privaten Schwachstellendatenbanken. Grundsätzlich gilt: Je bekannter eine Schwachstelle ist, desto dringlicher muss sie behoben werden.

Neben der Erfassung von Schwachstellen ist es entscheidend, jede Open-Source-Abhängigkeit in einer Anwendung im Blick zu behalten. Transitive Abhängigkeiten – bei denen Abhängigkeiten wiederum von anderen Abhängigkeiten abhängen – sind ein besonderes Problem. Sie sind für Sicherheitstools und bei Audits weniger sichtbar. Daher empfiehlt es sich, Tools oder Prozesse einzusetzen, mit denen sich alle Abhängigkeiten einer Anwendung ermitteln und prüfen lassen.

2. Risiken bei der Lizenzkonformität

Entwickler müssen die einzelnen Softwarelizenztypen der verwendeten Open-Source-Pakete kennen, um den Code lizenzkonform nutzen zu können. Dafür müssen sie über die Lizenzbedingungen Bescheid wissen und deren Einhaltung in allen Projekten durchsetzen. Um Open-Source-Lizenzen durchzusetzen, benötigen Unternehmen einen umfassenden Einblick in die Nutzung von Open-Source-Komponenten. Außerdem müssen Lizenzen kontinuierlich überwacht werden, falls der Urheber die Lizenz einer Bibliothek ändert.

3. Nicht gewartete Open-Source-Pakete

Open-Source-Pakete werden meist von einer einzelnen Person oder einem kleinen Team gewartet – sofern sie überhaupt gewartet werden. Entwickler von Community-Projekten sind nicht verpflichtet, die Software zu pflegen; sie wird ohne Gewähr bereitgestellt. Daher liegt es in der Verantwortung der Nutzer, Zeit und Ressourcen in die Sicherheit des Codes zu investieren. Glücklicherweise gibt es hilfreiche Tools, die diesen Prozess vereinfachen können, etwa Snyk Advisor. Das Tool analysiert Pakete nach Wartungsstatus, Community, Sicherheitslage und Beliebtheit, damit Sie den Zustand der verwendeten Open-Source-Pakete besser einschätzen können.

Möchten Sie mehr über die Risiken von Open-Source-Software erfahren? Lesen Sie unseren Beitrag 5 potenzielle Risiken von Open-Source-Software.

Wichtige Statistiken aus dem State of Open Source Report

Daten schaffen Wissen. Deshalb hat Snyk Entwickler und Sicherheitsexperten zu ihren Bedenken im Bereich Open-Source-Sicherheit, zu Schwachstellentrends bei Paketen und Container-Images sowie zu den Maßnahmen von Maintainer-Teams und Unternehmen zum Schutz ihrer Software befragt. Die Ergebnisse haben wir in unserem State of Open Source Security Report 2020 veröffentlicht. Hier sind einige zentrale Erkenntnisse aus dem Bericht.

Die Nutzung von Open-Source-Software nimmt zu

Open-Source-Ökosysteme wachsen kontinuierlich – getrieben von Marktanforderungen und wirtschaftlichen Realitäten. An der Spitze lag npm mit einem jährlichen Wachstum von über 33 % und 1,8 Millionen Paketen (Stand: März 2022). Die meisten Schwachstellen in Open-Source-Software werden weiterhin in indirekten Abhängigkeiten entdeckt:

• npm: 86 %

• Ruby: 81 %

• Java: 74 %

In der Open-Source-Sicherheitskultur rückt die Verantwortung stärker zu den Entwicklern

Die Befragten gaben an, dass sie Sicherheit als gemeinsame Verantwortung verschiedener Abteilungen betrachten:

• 85 % sahen Entwickler in der Verantwortung für Open-Source-Sicherheit

• 55 % sahen Sicherheitsteams in der Verantwortung

• 35 % meinten, dass auch der Betrieb eine Rolle spielt

Schwachstellentrends

Die Zahl neuer Schwachstellen sank insgesamt um 20 %. Am häufigsten wurden Cross-Site-Scripting-Schwachstellen (XSS) gemeldet.

Abbildung 2: Seit 2014 in Ökosystemen identifizierte Sicherheitslücken

Herausforderungen bei Containern und Orchestrierung

Offizielle Basis-Images mit dem Tag „latest“ enthalten häufig bekannte Schwachstellen. Besonders auffällig ist das offizielle Node-Image mit fast 700 bekannten Schwachstellen. Über 30 % der Umfrageteilnehmer prüfen Kubernetes-Manifeste nicht auf unsichere Konfigurationen. Auch Anforderungen an sicherheitsrelevante Ressourcenbeschränkungen in Kubernetes sind noch nicht weit verbreitet.

Abbildung 3: Sicherheitslücken in offiziellen Container-Images

Open-Source-Sicherheitstrends 2022

Im vergangenen Jahr prägten mehrere Trends die Diskussion rund um Open-Source-Sicherheit: die Supply-Chain-Sicherheit, ein kultureller Wandel bei der Verantwortlichkeit, ein Rückgang neu entdeckter Schwachstellen, die Abhängigkeit von ehrenamtlichen Open-Source-Maintainern und veränderte Erwartungen an die Behebung von Schwachstellen.

Angriffe auf die Supply Chain nehmen zu

Komponenten von Drittanbietern liegen in zentralisierten Repositorys und bilden die Software-Supply-Chain. Diese Supply Chain ist ein attraktives Angriffsziel: Angreifer können Schwachstellen in der Entwicklungspipeline ausnutzen, ohne Repositorys für Software ändern zu müssen. Beispielsweise können sie Designfehler mit einem Angriff durch Dependency- oder Namespace-Verwechslung ausnutzen oder über Komponenten von Drittanbietern Nutzerdaten kompromittieren und auf interne Systeme zugreifen.

Jedes Glied kann als potenzieller Angriffsvektor dienen. Deshalb muss die Supply Chain vom Quellcode bis zur Bereitstellung geschützt werden. Schwachstellen in der Supply Chain sind kein neues Problem, standen aber 2021 im Mittelpunkt der Diskussion und waren ein wiederkehrendes Thema in der Cybersicherheits-Verordnung von Präsident Biden.

Ein Kulturwandel hin zu gemeinsamer Verantwortung für Sicherheit

Wer sollte für Sicherheit verantwortlich sein? Einer der spannendsten Trends, die wir beobachtet haben, ist der Wandel hin zu gemeinsamer Verantwortung von Entwicklungs-, Sicherheits- und Betriebsteams.

Der Wandel hin zu DevSecOps ist positiv. Allerdings gaben 47 % der Befragten an, dass es keine konkreten Programme gibt, um die gemeinsame Verantwortung zu fördern. Nur 15 % hatten Security-Champions-Programme eingeführt – eine zentrale Sicherheitsmaßnahme des OWASP Software Assurance Maturity Model (SAMM). Das zeigt, dass zwischen dem Bewusstsein für die Notwendigkeit gemeinsamer Verantwortung und ihrer praktischen Umsetzung noch eine Lücke besteht.

Aus dem State of DevOps Report von Puppet haben wir außerdem erfahren, dass mit zunehmender Reife der DevOps-Praktiken in Unternehmen auch deren Sicherheitspraktiken reifen.

„Mit der Verbesserung der DevOps-Praktiken folgt DevSecOps ganz natürlich. Unternehmen mit einer hohen Entwicklungsreife haben Security nach links verlagert. Die Mehrheit integriert Sicherheit in die Anforderungsdefinition (51 %), das Design (61 %), die Entwicklung (53 %) und die Tests (52 %). Bei den meisten Unternehmen mit mittlerer Reife wird Security dagegen erst bei einem planmäßigen Audit der Produktionsumgebung (48 %) oder nach einer dort gemeldeten Störung (45 %) einbezogen.“

Puppet State of DevOps Report 2021

Weniger Schwachstellen entdeckt

Eine überraschende Erkenntnis des Berichts: Die Zahl neuer Schwachstellen ist insgesamt um 20 % gesunken. Das ist besonders bemerkenswert, weil die Open-Source-Ökosysteme gleichzeitig rasant wachsen.

Es ist unklar, warum die Zahl der Open-Source-Schwachstellen zurückgegangen ist, obwohl sich die Landschaft in manchen Ökosystemen mehr als verdoppelt hat. Das könnte jedoch darauf hindeuten, dass Verbesserungen beim Sicherheitsbewusstsein, bei den Praktiken und bei den Tools Wirkung zeigen.

Wir werden diesen Trend weiter beobachten. Für Selbstzufriedenheit bei Sicherheitskontrollen und -praktiken ist es jedoch noch zu früh.

Open-Source-Maintainer wehren sich gegen Unternehmen

Wir rechnen mit zunehmenden Spannungen zwischen Open-Source-Maintainern und Unternehmen, die mit ihrer Software entwickelte Produkte vermarkten, ohne die Maintainer zu finanzieren.

Eine Umfrage von Tidelift aus dem Jahr 2021 unter 400 Open-Source-Maintainern ergab, dass 46 % überhaupt nicht bezahlt werden und nur 26 % mit der Wartung mehr als 1.000 US-Dollar pro Jahr verdienen. Mehr als die Hälfte (59 %) hat die Wartung eines Projekts aufgegeben oder darüber nachgedacht. Fast die Hälfte der Befragten nannte die fehlende finanzielle Vergütung als Hauptgrund für ihre Unzufriedenheit mit der Maintainer-Rolle.

Diese Haltung hat konkrete Folgen. So fügte der Maintainer des weitverbreiteten npm-Pakets colors im Januar 2022 schädlichen Code hinzu, der eine Endlosschleife auslöst und jede Nutzung des Pakets verhindert.

Die fehlerhafte Version von colors wurde über 95.000-mal heruntergeladen. Colors wird in zahlreichen anderen Projekten eingesetzt, darunter dem Kommandozeilen-Helfer prompt (rund 500.000 Downloads pro Woche) und dem AWS-eigenen aws-cdk (rund 2 Millionen Downloads pro Woche). Das gibt Anlass zu großer Sorge.

Ein ähnlicher Vorfall ereignete sich beim beliebten npm-Paket faker, das von derselben Person gewartet wird. Der Maintainer eröffnete ein Issue und erklärte, die Projekte, die auch bei zahlreichen Fortune-500-Unternehmen zum Einsatz kommen, nicht länger kostenlos warten zu wollen.

Die Fristen für die Behebung von Sicherheitslücken erfüllen weiterhin nicht die Erwartungen

Laut der Umfrage Open Source Security 2020 erwarten 47 % der Befragten, dass eine Sicherheitslücke innerhalb einer Woche nach ihrer Entdeckung behoben wird. Knapp 18 % erwarten eine Behebung innerhalb eines Tages.

Abbildung 4: Erwartete Behebung von Open-Source-Schwachstellen

Tatsächlich wurden nur 35 % der Sicherheitslücken in gescannten Projekten innerhalb von weniger als 20 Tagen behoben, während die Behebung bei 36 % mindestens 70 Tage dauerte. Die durchschnittliche Behebungszeit betrug 68 Tage.

Es ist klar, dass Unternehmen ihre Erwartungen an ihre Risikolage anpassen müssen. Sie müssen die SLAs für die Behebung von Open-Source-Sicherheitslücken berücksichtigen – insbesondere, wenn einzelne Mitwirkende für die Pflege des Codes verantwortlich sind.

Wichtige Kennzahlen für Ihre Open-Source-Sicherheitsstrategie

Ein guter Anfang ist, die Sicherheitskennzahlen der verwendeten Open-Source-Bibliotheken sorgfältig zu erfassen. Berücksichtigen Sie Kennzahlen wie:

• Die Anzahl der Tage zwischen der Entdeckung und Behebung einer Sicherheitslücke

• Die durchschnittliche Zeit bis zum Zusammenführen eines Pull Requests nach Meldung eines Problems

• Der Zeitaufwand, um Code selbst zu korrigieren

Diese Antworten verschaffen Ihnen einen besseren Überblick darüber, wie Sie auf Sicherheitsprobleme in den von Ihnen verwendeten Paketen reagieren. So können Sie eine Strategie für das Management von Komponenten sowie das Aufdecken und Beheben von Sicherheitslücken entwickeln.

Gehen Sie außerdem proaktiv mit den verwendeten Open-Source-Paketen um. Reichen Sie Pull Requests bei den Maintainerinnen und Maintainer ein, damit sie auf Probleme aufmerksam werden. Machen Sie sich bewusst, wie sich Open-Source-Software auf Ihr Unternehmen auswirkt, und entwickeln Sie eine wirtschaftliche Begründung für ihr systematisches Management.

6 Funktionen, auf die Sie bei einem Open-Source-Sicherheitstool achten sollten

Sicherheitstools spielen eine zentrale Rolle in einer Open-Source-Sicherheitsstrategie. Sie ermöglichen die automatische Prüfung von Open-Source-Code auf bekannte Sicherheitslücken und greifen auf Schwachstellendatenbanken zurück. Diese geben Aufschluss über die möglichen Auswirkungen einer Sicherheitslücke und zeigen Schritte zu ihrer Behebung auf. Die Tools können Code kontinuierlich in der Produktion überwachen und Sicherheit sowie Lizenz- und Governance-Prüfungen in den gesamten Softwareentwicklungsprozess integrieren.

1. Umfassender Überblick über Pakete und die sie betreffenden Sicherheitslücken

Da die mangelnde Transparenz bei Open-Source-Komponenten und Abhängigkeiten eine Sicherheitsherausforderung darstellt, verschafft Ihnen die automatische Erfassung und Bewertung von Komponenten mehr Kontrolle über Ihre Open-Source-Umgebung. Achten Sie auf Automatisierung, die Komponenten in CI/CD-Pipelines identifiziert und ihre jeweilige Bedrohungsstufe bewertet. Werden anfällige Komponenten tatsächlich von der Anwendung verwendet?

2. Funktionen für das Lizenzmanagement

Sicherheitstools können Drittanbieter- und eigenen Code während der Entwicklung kontinuierlich auf Sicherheitslücken und Lizenzrisiken prüfen. So entfällt die Notwendigkeit, Code-Repositories zu scannen.

3. Automatisierung

Mit Sicherheitstools können Sie Sicherheitslücken automatisch überwachen und erkennen. Im Falle eines Sicherheitsvorfalls können die Tools anschließend den Schaden einstufen und eine geeignete Reaktion entwickeln. Sie können außerdem Richtlinien für Korrekturen, Anfragen, Patches und Aktualisierungen von Abhängigkeiten festlegen und diese Prozesse ebenfalls automatisieren.

4. Direkte Integrationen in Entwicklertools, Workflows und Automatisierungs-Pipelines

Die direkte Integration von Sicherheit in Entwicklertools und -prozesse vereinfacht die Absicherung von Code. Mit Plugins können Entwicklerinnen und Entwickler Korrekturen direkt über ihre CLI oder IDE anwenden. GitHub-Integrationen ermöglichen es Ihnen, Repositories, Projekte und Pull Requests zu testen und Korrekturen mithilfe automatisierter Pull Requests anzuwenden.

5. Aktuelle, angereicherte Datenbank, die über bekannte CVEs hinausgeht

Sicherheitstools gehen über öffentliche Datenbanken bekannter Sicherheitslücken hinaus und erstellen eigene, kuratierte Datenbanken. Diese enthalten Sicherheitslücken mit CVE-Nummern, aus Sicherheitshinweisen, aus Issue-Trackern sowie aus Foren und sozialen Medien und weiteren Quellen.

6. Kontinuierliche Überwachung von Projekten

Sicherheitstools können Anwendungen in der Produktion kontinuierlich überwachen, um die Ausnutzung von Sicherheitslücken automatisch zu verhindern. So entstehen Anwendungen, die sich praktisch selbst überwachen und sich gegen Angriffe sowie auftretende Lizenzprobleme schützen können.

Weitere Informationen zur Auswahl eines Sicherheitstools für die Überwachung von Open-Source-Komponenten finden Sie in unserem Leitfaden So wählen Sie SCA-Tools aus.

6 Vorteile von Snyk für Ihre OSS-Sicherheit

Snyk Open Source bietet ein entwicklerorientiertes Sicherheitstool, das Anwendungssicherheit in die gesamte Softwareentwicklungspipeline integriert. So können Sie Anwendungen mit Open-Source-Software erstellen und bereitstellen und gleichzeitig den Code vor Sicherheitslücken und Lizenzproblemen schützen.

1. Kompatibel mit DevSecOps

Snyk Open Source lässt sich vom ersten geschriebenen Code an in den SDLC integrieren. Wir haben umfassend in Integrationen investiert, damit Sicherheits- und Lizenzprüfungen so reibungslos wie möglich ablaufen. Dadurch tragen Entwicklerinnen und Entwickler direkt Verantwortung für die Sicherheit ihrer Anwendungen und können produktiv mit Sicherheits- und Betriebsteams zusammenarbeiten.

Wir haben außerdem einen DevSecOps Hub eingerichtet, der Technologien, Prozesse und Menschen vorstellt, die Unternehmen beim Aufbau einer DevOps-Kultur unterstützen, in der Sicherheit wirksam integriert ist. Unsere DevSecOps Community bringt Entwicklerinnen, Entwickler und Sicherheitsverantwortliche über ein Support-Portal, virtuelle und Präsenzveranstaltungen sowie ein Ambassador-Programm zusammen. Dieses unterstützt Security Champions durch einen direkteren Kontakt zu Snyk.

2. Probleme direkt in eingebetteten Entwickler-Workflows beheben

Snyk Open Source ist in Entwicklertools wie Atlassian Bitbucket, Visual Studio Code, Maven Central, GitHub und JetBrains integriert. So können Entwicklerinnen und Entwickler direkt in ihrem bevorzugten Tool auf Snyk zugreifen und Sicherheitslücken sowie Lizenzprobleme aufdecken.

3. Wenige falsch-positive Ergebnisse

Das Team aus Sicherheitsexpertinnen und -experten von Snyk pflegt die Datenbank und sorgt für eine niedrige Falsch-Positiv-Rate. Es analysiert und testet jeden Eintrag, weist jeder Sicherheitslücke einen CVSS-Score und -Vektor zu, investiert in eigene Forschung zum Aufdecken neuer Sicherheitslücken und ergänzt die Einträge, wo möglich, um handverlesene Zusammenfassungen mit Codebeispielen.

4. Abhängigkeitsbaum-Ansicht

Snyk verwendet den Paketmanager Ihrer Anwendung, um einen Abhängigkeitsbaum zu erstellen und in der Snyk-Benutzeroberfläche anzuzeigen. So können Sie erkennen, welche Komponente ein Problem verursacht, und es mit Snyk beheben – auch wenn es sich um eine transitive Abhängigkeit handelt. Außerdem lässt sich die Erstellung einer Software Bill of Materials (SBOM) direkt in Entwickler-Workflows automatisieren. Sobald Ihre SBOM vorliegt, können Sie sie mithilfe des SBOM Checkers von Snyk auf Sicherheitslücken prüfen.

5. Automatisierte Korrekturen

Snyk schlägt automatisch Korrekturen für Sicherheitslücken vor, sofern verfügbar – direkt in der CLI, IDE und den CI/CD-Pipelines. Gibt es für eine Abhängigkeit noch keine Korrektur, benachrichtigt Snyk Sie, sobald eine verfügbar ist oder neue Sicherheitslücken für diese Abhängigkeit entdeckt werden.

6. Governance und Lizenzmanagement

Mit dem Lizenz-Compliance-Management von Snyk Open Source können Sie Lizenzen direkt in Entwickler-Workflows verwalten. Dafür stehen Ihnen automatisierte Richtliniendurchsetzung und eine detaillierte Verwaltung zur Verfügung. So können Sie jeden Schritt vom ersten geschriebenen Code bis zur bereitgestellten Anwendung überwachen und sicherstellen, dass Ihre Projekte keine Lizenzen verletzen.

Play Video: Snyk Open Source Security Overview

FAQ-Bereich

Was ist Open-Source-Sicherheit?

Open-Source-Sicherheit umfasst die Risiken, denen Entwicklerinnen, Entwickler und Sicherheitsteams heute beim Einsatz von Open-Source-Code von Drittanbietern in ihren Anwendungen begegnen, sowie die Prozesse, Methoden und Tools, mit denen sie diese Risiken mindern. Jüngste Angriffe, bei denen Sicherheitslücken in Open-Source-Code ausgenutzt wurden, haben Unternehmen enorme Kosten verursacht. Das unterstreicht die Bedeutung von Open-Source-Sicherheit und die Notwendigkeit, entsprechende Sicherheitsstrategien umzusetzen und zu überwachen.

Warum ist Open-Source-Sicherheit wichtig?

Open Source treibt die digitale Transformation voran, die wir derzeit erleben, und wird von Unternehmen jeder Größe und aus allen Branchen genutzt. Doch Open Source bringt auch Risiken mit sich. Diese Risiken anzuerkennen, ist ein wichtiger erster Schritt. Darauf sollten jedoch Investitionen und die kontinuierliche Pflege eines klar formulierten Open-Source-Sicherheitsplans folgen, der regelmäßige Sicherheitstests und Überwachung umfasst.

Welche Risiken birgt Open Source?

Entwicklerinnen und Entwickler binden große Mengen an Open-Source-Abhängigkeiten ein, ohne diese ausreichend abzusichern oder im Blick zu behalten. Diese Open-Source-Komponenten werden von Freiwilligen außerhalb des Unternehmens gepflegt. Maintainer sind jedoch nicht verpflichtet, Komponenten zu aktualisieren oder abzusichern. Da der Code öffentlich zugänglich ist, können Angreifer außerdem von Sicherheitslücken erfahren und diese ausnutzen, sobald Entwicklerinnen und Entwickler davon Kenntnis erlangen. Dies sind einige der Risiken von Open-Source-Software.