DevSecOps

Moderne Anwendungen bestehen heute zu 90 % aus OSS-Komponenten. Das bedeutet, dass der Großteil der Software, die wir täglich erstellen, einsetzen und nutzen, mit größerer Wahrscheinlichkeit Sicherheitslücken enthält als je zuvor. Da diese Komponenten „offen” sind, haben Hacker eine schnelle und einfache Möglichkeit, Einblick in den Code zu erhalten und dort nach Sicherheitslücken zu suchen. Open Source-Software stellt nicht nur ein Risiko aufgrund von Sicherheitslücken dar, sondern kann auch komplexe Probleme bei der Einhaltung von Lizenzbestimmungen für Unternehmen mit sich bringen. Eine mögliche Komplikation könnte darin bestehen, dass eine Lizenz besagt: „Wenn Sie diese Komponente verwenden, müssen Sie Ihren Code als Open Source zur Verfügung stellen“.

Idealerweise sollten alle OSS-Komponenten so früh wie möglich im Entwicklungsprozess auf Lizenzkonformität und Sicherheitslücken überprüft und diese identifiziert werden. Zu wissen, welche Komponenten man über sein gesamtes Portfolio von Anwendungssoftware verteilt hat und diese nachverfolgen zu können, ist ein absolutes Muss, und sollte am besten automatisiert werden. Dies sollte ein integraler Bestandteil der CI/CD-Pipeline sein, um die Entwicklungs- und Release-Geschwindigkeit auf Kurs zu halten.

In der Vergangenheit war es für die Sicherung des SDLC und der Produktion erforderlich, Agenten zum Scannen von Komponenten einzusetzen. Heute gibt es verschiedene Lösungen, die ein höheres Maß an Sicherheit und Compliance-Überwachung bieten, die direkt in Ihre IDE, Ihren Repository-Manager und Ihre CI/CD-Pipeline integriert sind und sogar Ihre Container-Images scannen können. Um die Sicherheit und die Überwachung der Lizenzeinhaltung von Open Source zu gewährleisten, ist es am besten, mit einer nativ integrierten SCA-Lösung zu arbeiten.

Fortschrittliche SCA-Tools bieten Funktionen zur Durchsetzung von Richtlinien und ermöglichen die automatische Überwachung von Open Source-Komponenten. Diese können so konfiguriert werden, dass je nach Kontext des zu überprüfenden Vorgangs unterschiedliche Verhaltensweisen bei festgestellten Sicherheits- oder Compliance-Verstößen möglich sind. Ein Beispiel wäre, dass der Build einer hochsensiblen Anwendungssoftware aufgrund einer Sicherheitslücke fehlschlägt, während der Build einer Testanwendungssoftware mit derselben anfälligen Komponente nicht fehlschlägt. SCA-Tools vergleichen jede Open Source-Komponente Ihres Codes mit Ihren Vorschriften und Richtlinien, um entsprechend unterschiedliche automatisierte Prozesse, die auf dem Ergebnis des Abgleichs basieren, in Gang zu bringen.

Ein SCA-Tool benutzt eine Referenzdatenbank für bereits bekannte Sicherheitslücken und existierende Lizenzen und gleicht diese dann mit den Open Source-Abhängigkeiten Ihrer Anwendungssoftware ab. Je umfassender diese Datenbanken sind, desto geringer ist das Risiko, dass bekannte Sicherheitslücken oder Lizenzierungsprobleme im Produktionscode auftreten.

Bei der Betrachtung von Tools für die Software Composition Analysis ist es wichtig, Folgendes zu beachten:
1. Technologische Unterstützung: Wie universell ist es und unterstützt es alle in Ihrem Unternehmen verwendeten Programmiersprachen und Pakettypen?
2. Ökosystem-Integration: Das SCA-Tool muss mit Repositories, IDEs, Paketmanagern, CI-Servern usw. integriert werden, und zwar über sofort einsatzbereite Integrationen und über umfangreiche offene APIs.
3. Datenbank: Eine umfassende Datenbank für Sicherheitslücken und Lizenzbestimmungen ist ein Muss, um Sie bestmöglich abzusichern.

Ein komplettes Sicherheitspaket sollte aus den folgenden Tools bestehen:
- Dynamic Application Security Testing (DAST)
- Interactive Application Security Testing (IAST)
- Software Composition Analysis (SCA)
- Static Application Security Testing (SAST)

JFrog Xray ist ein SCA-Tool, das sich auf die Erkennung und Beseitigung von Open Source-Sicherheitslücken und Lizenzkonformitätsproblemen in den OSS-Komponenten und Abhängigkeiten konzentriert, auf die Sie sich beim Schreiben Ihres Anwendungscodes stützen. Da die Basis eines Codes bis zu 90 % aus OSS besteht, kann Xray einen großen Einfluss auf die Stabilität und Sicherheit Ihrer Produktionsversionen haben.

Unternehmen, die sich einer solchen Herangehensweise bedienen, erhalten durchweg Verbesserungen ihres SDLCs, wie z. B.: verbesserte Qualität durch frühzeitige Erkennung von Problemen, Transparenz von eigenentwickeltem und Open Source-Code, geringere Kosten für die Behebung von Sicherheitslücken durch frühzeitige Erkennung und Behebung im Entwicklungsprozess, Minimierung des Risikos von Sicherheitsverstößen und optimierte Sicherheitstests.

Sie können die beste Integration von SCA-Tools aller Zeiten haben, aber eine Lösung zur Sicherheitsüberprüfung ist nur so gut wie die Datenbank der Sicherheitslücken. Die Verwendung einer Datenbank, die nicht auf dem neuesten Stand der Sicherheitslücken ist, gleicht einem Versuch, jemanden in einer Menschenmenge zu finden, ohne zu wissen, wie er aussieht. Einige Unternehmen betrachten die Verwendung der Common Vulnerability Enumeration (CVE) von MITRE in der National Vulnerability Database (NVD) als den Goldstandard für die Absicherung. Viele Sicherheitsexperten sind der Meinung, dass es nicht mehr ausreicht, sich auf CVE und NVD zu stützen, um Daten über Sicherheitslücken zu erhalten.

So hat beispielsweise Risk Based Security, das für einen der aktuellsten und umfassendsten Sicherheitslücken-Informationsdienste – VulnDB – bekannt ist, jedes Jahr die Gesamtzahl der von CVE und NVD identifizierten und katalogisierten Sicherheitslücken übertroffen. Über 249.155 Sicherheitslücken, die Produkte von 27.676 Anbietern abdecken, einschließlich zehntausender Sicherheitslücken, die nicht in CVE/NVD enthalten sind, was VulnDB zur umfassendsten Lösung auf dem Markt macht. Über 2.000 Bibliotheken von Drittanbietern wurden identifiziert und auf Sicherheitslücken überwacht.

JFrog Xray profitiert von einer engen Integration mit VulnDB, der primären Quelle für Sicherheitslücken- und Lizenzkonformitätsinformationen.

Zunächst einmal sind viele Sicherheitsexperten in der Branche der Meinung, dass es nicht mehr ausreicht, sich auf CVE- und NVD-Datenbanken für Sicherheitslückendaten zu verlassen. Es kann lange dauern, bis eine Sicherheitslücke in den CVE/NVD-Datenbanken veröffentlicht wird, und in der Zwischenzeit können hinterlistige Akteure diese Sicherheitslücken analysieren und herausfinden, wie sie sie für bösartige Aktivitäten nutzen können.

Je eher Ihre SCA-Lösung eine Sicherheitslücke in der Datenbank aufweist, desto eher können Sie Ihren Produktionscode gegen diese Sicherheitslücke absichern. Dasselbe gilt für die Überprüfung von Lizenztypen und -versionen. Ihre Compliance- oder Rechtsabteilungen werden über eine Reihe von Richtlinien in Hinblick auf die Verwendung von OSS-Lizenzen verfügen. Mit einer aktuellen Lizenzdatenbank, die Sie überprüfen können, minimieren Sie das Risiko, dass unbeabsichtigte Lizenztypen in Ihrem Produktionscode vorkommen, was teuer und kompliziert sein kann.