Die 7 Schwachstellen in den heutigen Software

Ein wichtiger Punkt ist die Unterscheidung zwischen SBOM und SCA (Software Analysis). Die SBOM ist das Inventar oder eine Liste der Komponenten. Die SCA bewertet, ob diese Komponenten anfällig, veraltet oder risikobehaftet sind. Zusammen geben sie Unternehmen die notwendigen Einblicke, um fundierte Entscheidungen zu treffen, schneller auf Sicherheitsprobleme zu reagieren und das gesamte Risikomanagement zu stärken.

Die Geschwindigkeit der modernen Entwicklung in Verbindung mit der starken Abhängigkeit von Drittanbieter- und Open-Source-Code hat zu schwerwiegenden Sicherheitslücken geführt. Angreifer nutzen sieben primäre Schwachstellen aus:

Wenn Entwickler Geschwindigkeit priorisieren, verwenden sie häufig große Open-Source-Bibliotheken ohne vollständige Codeüberprüfung. Eine einzelne Komponente kann zusätzliche transitive Abhängigkeiten mit sich bringen. Wenn Sie nur die oberste Ebene überwachen, können Sie bösartigen Code übersehen, der in diese versteckten transitiven Abhängigkeiten eingeschleust wurde.

Dieses Muster beobachten wir immer wieder in Open-Source-Ökosystemen. Ein einziges kompromittiertes Paket kann sich über Abhängigkeitsketten ausbreiten und Millionen von Downloads erreichen, bevor jemand etwas bemerkt. Ein kürzlich erfolgter Angriff auf die npm-Lieferkette mit Krypto-Malware zeigt genau, wie dies in der Praxis abläuft.

Bewährte Praktiken:

• Scannen Sie alle Open-Source-Pakete und deren vollständige Abhängigkeitsketten, um Schwachstellen, veraltete Komponenten oder versteckte Malware zu identifizieren, bevor diese in Ihren Code gelangen.
• Überwachen Sie Abhängigkeiten kontinuierlich im Laufe der Zeit, da sichere Komponenten durch neue CVEs oder bösartige Updates zu einem Risiko werden können.
• Verwenden Sie vertrauenswürdige Registrierungen und überprüfen Sie die Integrität der Pakete, um sicherzustellen, dass die von Ihnen heruntergeladenen Pakete nicht manipuliert wurden.
• Wenden Sie Richtlinien an, die riskante Lizenzen kennzeichnen oder blockieren, damit keine inkompatiblen oder viralen Lizenzbedingungen in Ihre Builds gelangen.
• Verzögern Sie die Verwendung neu veröffentlichter Pakete, bis sie überprüft wurden, um das Risiko zu verringern, dass ungeprüfte oder bösartige Versionen in Ihre Umgebung gelangen.

Lizenzierungsfragen betreffen mittlerweile sowohl den technischen als auch den rechtlichen Bereich. Virale Lizenzen wie die GPL können dazu führen, dass Ihre resultierende Anwendung unter derselben Lizenz veröffentlicht werden muss, wodurch Ihr Unternehmen möglicherweise sein eigenes geistiges Eigentum (IP) verliert. Eine kontinuierliche Überwachung ist erforderlich, da sich die Lizenzbedingungen ändern können, selbst für ältere, zuvor konforme Versionen.

Bewährte Praktiken:

• Verwenden Sie ein automatisiertes Tool zur Lizenzerkennung, um risikoreiche oder inkompatible Lizenzen frühzeitig in der Entwicklung zu erkennen. Eine ausführlichere Erklärung, warum dies wichtig ist, finden Sie hier: Die entscheidende Rolle der Lizenzerkennung für die Sicherheit von Open-Source-Software.
• Verfolgen Sie Lizenzänderungen kontinuierlich, um Verschiebungen zu erkennen, die sich auf die Compliance oder die Gefährdung des geistigen Eigentums auswirken können.
• Komponenten mit restriktiven oder viralen Lizenzen blockieren oder überprüfen, bevor sie in die Codebasis gelangen.
• Führen Sie ein übersichtliches Verzeichnis aller verwendeten Lizenzen, um Audits und Risikobewertungen zu vereinfachen.

Zwar schreiben Vorschriften die Weitergabe von SBOMs vor, doch eine allgemeine Liste reicht nicht aus. Für eine wirksame Risikominderung und Prävention sind detaillierte Datenpunkte erforderlich, darunter der Autor, Mitwirkende, die Häufigkeit der Veröffentlichung und der Wartungsstatus.

Bewährte Praktiken:

• Verbessern Sie SBOM-Berichte, indem Sie Komponenten erneut scannen, um sie mit aktualisierten Lizenzdaten, dem Status der Sicherheitslücken und anderen wichtigen Metadaten anzureichern. Ein detailliertes Beispiel hierfür finden Sie hier unter „CycloneDX SBOM Report Validation and Enrichment” (Validierung und Anreicherung von SBOM-Berichten mit CycloneDX).
• Validieren und ergänzen Sie SBOMs mithilfe automatisierter Tools, um sicherzustellen, dass die Informationen vollständig, korrekt und umsetzbar sind.
• Verlangen Sie von Anbietern die Bereitstellung einer vollständigen SBOM-Tiefe, einschließlich transitiver Abhängigkeiten und aller relevanten Metadaten.
• Aktualisieren und überwachen Sie SBOM-Bestände kontinuierlich, wenn sich Komponenten weiterentwickeln oder neue Schwachstellen auftreten.

Jeder Anbieter, auf den Sie sich verlassen, wird Teil Ihrer Lieferkette. Wenn dieser veraltete oder kompromittierte Komponenten liefert, übernehmen Sie dieses Risiko. Vollständige SBOMs, einschließlich transitiver Abhängigkeiten, ermöglichen es Ihnen, Ihre Risiken schnell zu erkennen, anstatt bei einem Vorfall den Anbietern hinterherlaufen zu müssen. Ein kürzlich veröffentlichter Beitrag zum Thema „Managing Dependency Vulnerabilities in Your Software Supply Chain ) untersucht, wie Teams diesen Teil des Prozesses stärken können.

Aufgrund der raschen Verbreitung von KI umgehen Teams häufig normale Einschränkungen, was dies zu einem wichtigen Angriffsvektor macht. Angreifer schleusen bösartigen Code in Machine-Learning-Modelle, PICO-Dateien oder Open-Source-Bibliotheken ein. Typosquatting ist in Umgebungen wie Pytorch weit verbreitet, wo Benutzer möglicherweise die falsche Bibliothek herunterladen, die Malware enthalten kann und zur vollständigen Remote-Codeausführung auf dem Rechner eines Ingenieurs führt.

Das Scannen von Containern muss sich weiterentwickeln und darf sich nicht nur auf Schwachstellen konzentrieren. Moderne Sicherheitslösungen müssen auch nach Malware, Crypto-Minern und schnell agierenden Bedrohungen suchen, die in öffentlich zugänglichen Container-Images veröffentlicht werden. Eine aktuelle Analyse des NVIDIA Container CVE-2024-0132 zeigt, wie leicht diese Probleme übersehen werden können.