Best Practices für das Scannen von Paketen auf Sicherheitslücken
Das Scannen von Packages auf Sicherheitslücken ist ein wesentlicher Schritt in Richtung Absicherung einer modernen Softwarebereitstellungspipeline. Mithilfe von SCA-Tools können bekannte Schwachstellen in den Paketen, die für die Bereitstellung von Anwendungen verwendet werden, automatisch identifiziert werden. Der Einsatz eines solchen Paket-Scans verringert das Risiko der Freigabe unsicherer Software für die Produktion erheblich.
Die Sicherung von Paketen erfordert jedoch mehr als lediglich eine automatischen Package-Scanner einzurichten und davon auszugehen, dass diese alle potenziellen Schwachstellen aufspüren wird. In diesem Artikel wird gezeigt, dass Teams zusätzliche Maßnahmen treffen sollten, um den bestmöglichen Nutzen aus einem Package Vulnerability Scanning zu ziehen.
Was bedeutet Package Vulnerability Scanning?
Beim Scannen von Softwarepaketen auf Sicherheitslücken werden diese automatisch auf bekannte Schwachstellen untersucht.
Schwachstellen-Scanner können praktisch alle Arten von Paketen untersuchen. Sie können beispielsweise zum Scannen von Docker-Container-Images aber auch von Debian- oder RPM-Paketen verwendet werden, die Entwickler zur Bereitstellung von Software auf Linux-Systemen erstellen.
Normalerweise überprüfen Paket-Scanner, ob der Inhalt eines Softwarepakets mit Objekten übereinstimmt, die auf der Grundlage von Datenbanken, die Schwachstellen in Anwendungen und Bibliotheken erfassen, als anfällig bekannt sind. So kann ein Schwachstellen-Scanner etwa erkennen, dass ein Paket eine bestimmte Version einer Software-Bibliothek enthält, die ein bekanntes Sicherheitsproblem aufweist. Der Scanner würde diese Schwachstelle kennzeichnen und die Entwickler warnen, damit sie die Bibliothek auf eine neuere, sichere Version aktualisieren.
Wo die Grenzen von Package-Scans liegen
Zwar sind Schwachstellen-Scanner ein hilfreiches Werkzeug, um verschiedene Arten von Sicherheitsrisiken in Software zu finden, doch muss man bedenken, dass sie nur nach Schwachstellen Ausschau halten, die bereits in Datenbanken identifiziert und erfasst wurden.
So können sie in der Regel keine Sicherheitslücken, wie z. B. Pufferüberlauf Schwachstellen finden die im selbst geschriebenen Code stecken. Das ist Aufgabe von statischen Anwendungssicherheitstests (SAST). Sie überwachen auch nicht das Verhalten der Anwendung auf Hinweise auf eine Sicherheitslücke, was die Aufgabe von SIEMs und anderen Tools zur Security Monitoring ist.
Dazu kommt die Herausforderung die große Anzahl von Warnungen, die Schwachstellen-Scanner ausspucken, auch richtig zu interpretieren. Wenn Sie Ihre Softwarepakete scannen, bekommen Sie in der Regel eine lange Liste an Schwachstellen, und das Tool bewertet nicht unbedingt den Schweregrad jeder erkannten Schwachstelle. Hier muss man entscheiden, welche Schwachstellen so schwerwiegend sind, dass die eine Entfernung des Images rechtfertigen und welche ein geringes Risiko mit sich bringen. Für diese Entscheidung ist oft eine manuelle Analyse der jeweiligen Schwachstellen und ihrer potenziellen Auswirkungen erforderlich.
On-Demand Webinar: Wie Sie bösartige Paketen identifizieren und vermeiden
ZUM ON-DEMAND WEBINAR
So holen Sie das Optimum aus Paket-Schwachstellen-Scannern heraus
Die Bereitstellung eines automatischen Paketscanners als Teil Ihrer CI/CD-Pipeline ist der erste Schritt, um Sicherheitslücken immer einen Schritt voraus zu sein. Teams sollten allerdings noch weitere Vorkehrungen treffen, um ihre Chancen zu erhöhen, alle potenziellen Schwachstellen in Paketen zu finden.
Halten Sie Ihre Pakete so klein wie möglich
Je mehr Code und Abhängigkeiten ein Paket enthält, desto schwieriger kann es für Schwachstellen-Scanner sein, alle Ebenen zu entpacken und Schwachstellen zu entdecken. Außerdem wird es schwieriger, ein Problem zu beheben und das Paket neu zu generieren, wenn es viele Objekte enthält.
Am besten sorgen Sie dafür, dass jedes Paket, das Sie erstellen, nur den Code und die Ressourcen enthält, die für die Bereitstellung einer bestimmten Funktionalität benötigt werden. Widerstehen Sie der Versuchung, mehrere Komponenten einer Anwendung in ein einziges Paket zu packen.
Anstatt zum Beispiel ein Docker-Image zu erstellen, das mehrere Microservices enthält, sollten Sie für jeden Microservice ein eigenes Image erstellen. Oder anstatt das Frontend einer Anwendung und die Anwendungslogik in ein und dasselbe Debian-Paket zu packen, verteilen Sie sie auf verschiedene Pakete.
Scannen Sie so früh wie möglich im SDLC
Anstatt mit dem Scannen von Paketen bis kurz vor der Bereitstellung zu warten, sollten Sie versuchen, Scans durchzuführen, sobald die Pakete erstellt werden.
Das frühestmögliche Scannen bietet zwei Vorteile. Zum einen lassen sich Schwachstellen früher in der CI/CD-Pipeline leichter beheben, da Sie noch weniger investiert haben. Wenn Sie mit dem Scannen warten, bis Sie bereits andere Tests mit Ihren Paketen durchgeführt haben, müssen Sie diese erneut durchführen, wenn Sie eine Sicherheitslücke entdecken und das Paket neu erzeugen müssen.
Zweitens minimiert ein frühzeitiges Scannen das Risiko, eine unsichere Anwendung in das Produktivsystem zu übernehmen. Sie möchten keine Container-Images in eine Registry stellen, wo Nutzer sie herunterladen und installieren könnten, bevor Sie sie gescannt haben.
Frühzeitiges Scannen ersetzt dabei aber nicht das Scannen kurz vor der Bereitstellung. Das ist ebenfalls wichtig, um die Risiken der Software, die Sie in die Produktion einbringen, zu bewerten. Doch das Scannen zu einem früheren Zeitpunkt im Entwicklungszyklus hilft Ihnen, potenzielle Schwachstellen auszumerzen, bevor sie überhaupt in der Pipeline landen.
Priorisierung prüfen
Wie oben erwähnt, ist eine lange Liste an Schwachstellen nicht sehr hilfreich, wenn sich Ihr Team schwertut, festzustellen, welche Schwachstellen so gravierend sind, dass sie ein Paket nicht verwenden können.
Vermeiden Sie dieses Problem, indem Sie in einen Paket-Scanner investieren, der eine effektive Risikobewertung der Schwachstellen und eine Priorisierung auf der Grundlage einer Analyse der tatsächlichen Auswirkungen der einzelnen Schwachstellen auf die Sicherheit ermöglicht. So können Sie leicht feststellen, welche Schwachstellen echte Problemfälle sind und welche Sie ignorieren können.
Scannen Sie alle Pakete, auch wenn Sie der Quelle vertrauen
Manchmal stammen die Pakete, die Sie einsetzen, nicht aus dem eigenen Haus, sondern von Dritten. In diesen Fällen ist es wichtig, dass Sie die Pakete scannen, unabhängig davon, wie viel Vertrauen Sie in die Herkunft haben.
Investieren Sie in eine umfassende Schwachstellen-Datenbank
Open-Source-Paketschwachstellen-Scanner (SCA-Tools) sind nur so effektiv wie die Schwachstellendaten, mit denen Sie sie füttern. Wenn Ihre Schwachstellendatenbank ein bekanntes Sicherheitsproblem nicht enthält, kann Ihr Scanner es auch nicht erkennen.
Deshalb ist es eine weise Entscheidung, in eine Schwachstellen-Scanner-Lösung eines DevOps Security-Plattform-Spezialisten zu investieren, der eine umfassende Schwachstellen-Datenbank nutzt, indem er auf mehrere Quellen von Bedrohungsinformationen zurückgreift – einschließlich öffentlicher, proprietärer und interner Sicherheitsforschungsexpertise.
Das JFrog-Security Research Team erstellt und pflegt die JFrog Xray-Schwachstellendatenbank mit Open-Source-Paketdaten inklusive Lizenztypen und bekannter Schwachstellen (CVEs). Die Security Analysten ergänzen auch die vorhandene Kontext- und CVE-Daten mit alternativen Empfehlungen zur Abhilfe, wo anwendbar.
