Bibliotheken von Drittanbietern sind unerlässlich, um den Lebenszyklus der Softwareentwicklung zu beschleunigen. Anstatt von Grund auf zu programmieren, integrieren Entwickler oft Open-Source-Bibliotheken für verschiedene Zwecke - sei es aus Kostengründen, wegen fehlender Ressourcen oder wegen besserer Flexibilität. Repositories wie Maven Central und PyPI sowie Tools zur Verwaltung von Abhängigkeiten vereinfachen diesen Prozess und steigern die Produktivität. Eine solche Abhängigkeit birgt jedoch auch potenzielle Sicherheitsrisiken.
Die Verwaltung der Open-Source-Abhängigkeiten eines Projekts kann Herausforderungen mit sich bringen, z. B. verschachtelte Abhängigkeiten (eine oder mehrere Abhängigkeiten innerhalb einer Abhängigkeit) und begrenzte Fachkenntnisse in der Verwaltung von Abhängigkeiten. Die Integration externer Bibliotheken vergrößert die Angriffsfläche und erhöht die Sicherheitsrisiken. Die Entdeckung einer Schwachstelle in einer Bibliothek kann die gesamte Software gefährden, die auf diese Komponente angewiesen ist. Daher ist es unerlässlich, Tools zum Scannen von Abhängigkeiten zu verwenden, um bekannte Schwachstellen zu erkennen und zu beheben, die von Abhängigkeiten von Drittanbietern herrühren.
Wiederverwendung von Software und Übernahme von Abhängigkeiten
Da Vertriebsökosysteme immer zugänglicher werden, entscheiden sich Entwickler für die Wiederverwendung vorhandener Software, um die Entwicklung komplexer Software zu beschleunigen. Diese Bequemlichkeit kann jedoch zu unerwarteten Sicherheitsproblemen führen, wenn sie nicht sorgfältig gehandhabt wird. Diese bestehenden Softwareprogramme werden in erster Linie über das Internet in Form von Paketen vertrieben, d. h. in Form von Archiven, die als Bibliotheken bekannte Release-Versionen sowie Metadaten mit Angaben zu Version, Autor, Lizenz, Referenzen und anderen relevanten Informationen enthalten. Die Paketierung von Software vereinfacht den Vertrieb und die Versionskontrolle.
Entwickler stellen ihren Code häufig unter Open-Source-Lizenzen öffentlich zur Verfügung, was die Überprüfung des Codes, die Zusammenarbeit in der Gemeinschaft und eine einfache Integration ermöglicht. Jeder Entwickler kann die Codebasis wiederverwenden, verändern oder zu ihr beitragen. Die Projekte unterscheiden sich stark in Bezug auf Qualität, Wartung und Support. Die Autoren geben diese Pakete frei, um sie leichter zugänglich zu machen, aber Support und Haftung hängen von der Lizenz ab.
Sobald ein Paket in einem anderen Projekt referenziert wird, wird es zu einer Projektabhängigkeit, die eine externe Paketreferenz darstellt. Abhängigkeiten schaffen einseitige Beziehungen zwischen Softwarepaketen, wobei ein Paket auf ein anderes angewiesen ist, um ordnungsgemäß zu funktionieren. Entwickler bauen Abhängigkeiten in ihre Anwendungen ein, lösen sie zum Zeitpunkt der Erstellung auf und holen die benötigten Pakete ab.
Die Lieferkette bezieht sich auf alle externen Lieferanten, die an dem Prozess beteiligt sind, insbesondere auf diejenigen, die Software-Abhängigkeiten liefern. Das Management der Lieferkette hat in den letzten Jahren in der Softwareentwicklung an Bedeutung gewonnen, wobei die Unternehmen Richtlinien einführen, die die Anforderungen an die Lieferanten, rechtliche Dokumente und Verträge umfassen, um die Einhaltung der Vorschriften zu gewährleisten, bevor sie einen Lieferanten akzeptieren.
Verwaltung von Abhängigkeiten
Die Verwaltung von Abhängigkeiten kann schnell überwältigend werden, was zu der so genannten "Abhängigkeitshölle" führt. Moderne Anwendungen können Hunderte oder sogar Tausende von direkten Abhängigkeiten haben, was das Aufspüren von Schwachstellen schwierig macht. Hier sind einige Szenarien, in denen die Verwaltung großer Mengen von Abhängigkeiten zur Herausforderung wird.
- Mangelnde Überprüfung des Codes: Trotz der Open-Source-Transparenz unterlassen es Teams manchmal, den Code zu überprüfen, was zu einem falschen Sicherheitsgefühl führt.
- Implizites Vertrauen: Entwickler nehmen oft Abhängigkeiten auf, ohne die Autoren gründlich zu überprüfen, und verlassen sich allein auf die Aufnahme in das Repository.
- Umfangreiche Nutzung von Abhängigkeiten: Entwickler verlassen sich oft stark auf Pakete, auch wenn nur ein Bruchteil ihrer Funktionalität benötigt wird, was zu übermäßigen Abhängigkeiten führt.
- Brüchige Änderungen: Die Aktualisierung von Paketen kann sehr komplex sein und Änderungen mit sich bringen, die zu Verzögerungen und veralteten Paketen führen können.
- Haftungsfragen: Die Wartungs- und Support-Standards für Open-Source-Software sind nicht so hoch wie die für kommerzielle Software, was zu Streitigkeiten und unrealistischen Erwartungen der Projektentwickler führt und möglicherweise unsichere Pakete zur Folge hat.
Die Zunahme von Angriffen, die auf Abhängigkeiten von Drittanbietern abzielen, hat Bedenken hinsichtlich der Softwaresicherheit geweckt. Aufsehen erregende Vorfälle wie die Log4Shell-Schwachstelle im Jahr 2021 oder die XZ Utils-Backdoor im März 2024, von der Tausende von Maven-Paketen betroffen waren, haben die weitreichenden Auswirkungen solcher Schwachstellen deutlich gemacht. Im selben Jahr machte die Entdeckung von Malware in einem beliebten NPM-Paket ua-parser-jswas die Risiken deutlich, die mit der Verwendung von Drittanbieter-Bibliotheken in Anwendungsstapeln verbunden sind.
Ein weiterer bemerkenswerter Angriff im Januar 2024 ist MavenGate, eine neue Angriffsmethode für die Software-Lieferkette, bei der Abhängigkeiten über verlassene Bibliotheken gekapert werden. Wenn diese Schwachstellen erfolgreich ausgenutzt werden, könnten böswillige Akteure anfällige Artefakte in Abhängigkeiten finden und bösartigen Code in die Anwendung einschleusen oder, schlimmer noch, den Build-Prozess durch ein bösartiges Plugin kompromittieren.
Da die Verwendung von Open-Source-Bibliotheken zunimmt, wird das Verständnis und die Abschwächung dieser Risiken von größter Bedeutung. Dies veranlasst zu einer weiteren Untersuchung der Verbreitung, der Arten und der Persistenz von Schwachstellen in Open-Source-Bibliotheken sowie ihrer Beziehung zu Projektattributen und Commits.
Absicherung von Abhängigkeiten mit OPSWAT SBOM
Als Reaktion auf Angriffe auf die Lieferkette haben die Vereinigten Staaten von Amerika im Mai 2021 die "Executive Order on Improving the Nation's Cybersecurity" verabschiedet, die Schritte zur Verbesserung der Lieferkettenpolitik festlegt. Eine der wichtigsten Anforderungen ist die Bereitstellung einer SBOM für jedes Produkt.
OPSWAT Software Bill of Materials (SBOM) wird ständig weiterentwickelt, um den wachsenden Anforderungen der Softwareentwicklung in einer sicheren Umgebung gerecht zu werden. Eine der wichtigsten Funktionen von OPSWAT SBOM ist das Scannen von Abhängigkeiten. Diese Funktion wurde entwickelt, um die Sichtbarkeit Ihrer Codebasis zu verbessern, indem Schwachstellen in den Abhängigkeiten, auf die Ihre Projekte angewiesen sind, identifiziert werden.
Scannen von Paketabhängigkeiten
OPSWAT SBOM erkennt automatisch Sicherheitsschwachstellen in Software-Abhängigkeiten während der Entwicklung und des Testens. SBOM teilt den Teams beispielsweise mit, wenn die Anwendung eine Open-Source-Bibliothek verwendet, die bekanntermaßen anfällig ist. Die Teams können dann Maßnahmen ergreifen, um die Anwendung zu schützen.
Abhängigkeiten mit Python prüfen
Container Bild-Scanning
OPSWAT SBOM untersucht jede Schicht eines Container-Images, um Schwachstellen oder Bedrohungen zu identifizieren, einschließlich Betriebssystempakete und abhängige Softwarebibliotheken, die von der Anwendung verwendet werden. Dieser proaktive Ansatz ermöglicht die Erkennung und Behebung potenzieller Probleme, bevor sie sich zu größeren Problemen auswachsen.
Abhängigkeit mit Alpine prüfen
Entwickler und Sicherheitsteams profitieren davon, dass sie die allgemeinen Arten, die Verbreitung und das Fortbestehen von Schwachstellen in Abhängigkeiten verstehen und so den Schweregrad einschätzen und Abhilfestrategien entwickeln können.
SBOM scannt die Abhängigkeiten Ihres Projekts auf bekannte Sicherheitslücken. Nach der Erkennung liefert SBOM detaillierte Informationen, darunter Schweregrade, Beschreibungen der Schwachstellen und verfügbare Korrekturen.
Ein detaillierter Bericht kann exportiert werden, damit die Teams den Überblick behalten:
- Gesamtzahl der gescannten Abhängigkeiten
- Gesamtzahl der gefundenen Schwachstellen in allen Abhängigkeiten
- Eine Reihe von Versionen gescannt
- Bekannte CVEs
- Gesamtzahl der kritischen, hoch-, mittel- und niedriggradigen Schwachstellen
OPSWAT SBOM empfiehlt den Sicherheitsteams, alle anfälligen Pakete auf die neuesten Versionen zu aktualisieren, die Sicherheitslücken beheben. Auf diese Weise können Teams die Schwachstellen von Paketbetreuern beheben oder Pakete aus dem Abhängigkeitsbaum entfernen. Mit diesem proaktiven Ansatz können Teams potenzielle Sicherheitsrisiken angehen, bevor sie zu einem Problem werden, und so die Sicherheit und Integrität ihrer Softwareprojekte erheblich verbessern. Darüber hinaus hilft OPSWAT SBOM Unternehmen dabei, in der Software-Lieferkette konform und sicher zu bleiben. Es wird dringend empfohlen, dass Teams dies tun:
Abbilden von Abhängigkeiten
Nutzen Sie Tools, um zu ermitteln, welche Abhängigkeiten in der Umgebung bestehen und wie diese zusammenhängen.
Unnötige Abhängigkeiten beseitigen
Entfernen Sie unnötige oder unwichtige Abhängigkeiten, um die Angriffsfläche zu verringern.
Verwenden Sie etablierte Repositories
Stellen Sie sicher, dass die Abhängigkeiten aus seriösen Quellen stammen.
Scannen Sie alle Abhängigkeiten
Bevor Sie Abhängigkeiten in einer Software verwenden, scannen Sie sie, um sich über Sicherheits- oder Qualitätsprobleme klar zu werden.
Abschließende Überlegungen
Durch den Einsatz von Tools zum Scannen von Abhängigkeiten wie OPSWAT SBOM können Sie proaktiv Schwachstellen in den Abhängigkeiten Ihres Projekts erkennen und beheben und so potenzielle Sicherheitsrisiken mindern, bevor sie ausgenutzt werden können. Nutzen Sie die Vorteile von Dependency Scanning und SBOMs, um sichere, konforme und widerstandsfähige Softwareanwendungen zu entwickeln.
