Best Practices für den Umgang mit Risiken durch Open Source-Code

Originalartikel von Aaron Ansari

Der Einsatz von Open-Source-Code hat in den letzten zehn Jahren immer mehr zugenommen, einschließlich bei kommerzieller Software. Entwickler tauschen weltweit  Features und Code-Funktionen über das Internet aus. Die Geschwindigkeit und die Anforderungen an die Anwendungsteams sind hoch – gab es früher eine Handvoll Anwendungsreleases pro Jahr, so sind es heute eine Handvoll pro Woche oder gar Tag. Dies hat dazu geführt, dass die Entwicklung von einer „Wasserfall“- und „iterativen“-Projektmethodik auf „agile“ umgestiegen ist, um den schnell wachsenden Anforderungen gerecht zu werden. Umso wichtiger ist es, die damit verbundenen Risiken zu verstehen und damit umgehen zu können.

Open-Source-Code kommt aus einer Vielzahl von Quellen. Die Wiederverwendung von Code, Bibliotheken von Drittanbietern und Downloads für Entwickler dominieren die Landschaft. Außerdem verwenden externe Berater häufig denselben Code in mehreren Kundenprojekten (wenn er für das Projekt von Kunde X funktioniert hat und Kunde Y etwas Ähnliches macht …):

Quelle: https://www.slideshare.net/denimgroup/create-a-unified-view-of-your-application-security-program-black-duck-hub-and-threadfix

Lesen Sie im Originalbeitrag das Beispiel von Capital One Bank nach.

Open Source ist nicht ganz kostenlos

Ein häufiges Missverständnis in Bezug auf Open-Source-Code ist, er sei „kostenlos“. Um von quelloffenem Code zu profitieren, müssen Organisationen die richtigen Leute und die richtige Technik einbeziehen, um die damit verbundenen Risiken zu minimieren.

Unter anderem können rechtliche Risiken hinsichtlich der lizenzierten Nutzung von Code, geistigem Eigentum, möglichem Einfluss auf Mergers & Acquisitions sowie der Reputation von Unternehmen bestehen. Viele große Unternehmen wie etwa Capital One oder Facebook haben einen Open-Source-Rechtsbeistand im Team als „Law and Technology Counsel“, und sie sind für die oben genannten Rechtsfragen zuständig.

Zu den Open Source-Sicherheitsrisiken gehören auftretende Schwachstellen – durchschnittlich 64 pro Codebasis. 1500+ Tage bis zu einer Behebung. Entwicklungsprozesse stellen die erste Verteidigungslinie dar. Des weiteren kann Gefahr durch Software unbekannter Herkunft drohen.

Um diese Risiken möglichst zu vermeiden, ist die Nutzung von Open-Source-Repository-Scantechnologien zwingend erforderlich. Es sollte ein Service sein, der in der Lage ist, entsprechende Dateien zu finden (zu identifizieren und zu analysieren), die direkten und indirekten Abhängigkeiten zu verstehen (und sie für bekannte Schwachstellen zu kennzeichnen). Die Integration ins unternehmenseigene Code-Repository hilft auch dabei, die mit den Projekten verbundenen Risiken zu identifizieren. Der nächste Schritt ist das Einbinden der gefundenen Probleme ins Ticketing-System (oder das Erstellen von Pull-Requests) für die Behebung auf Entwicklerebene, um sicherzustellen, dass der Code einen Eigentümer hat und während seines Lebenszyklus gepflegt wird. Die Wartung und Überprüfung (Remediation) ist ebenfalls erforderlich, weil jedes Mal, wenn die gleiche Pull-Anfrage vorkommt, auch ein Scan und aktualisierte Patch-Anfrage dort stattfinden muss.

Lösungen

Der Aufbau einer Kultur in einer Organisation, die das Eigentum am Code, die Wartung des Codes von Release zu Release beinhaltet, wird Zeit brauchen. Die Implementierung von Technologie-Checks darüber hinaus hilft den Teams bei der kontinuierlichen Durchführung dieser Maßnahmen.

Vier Best Practices für den sicheren Umgang mit Open-Source-Code-Schwachstellen:

  • Identifizieren: Führen eines Open-Source-Inventar
  • Analysieren: Tracken der Open-Source-Schwachstellen und -Lizenzen
  • Beseitigen: Fixen und Patchen, Upgrade
  • Auditieren: Kontinuierliche Überwachung

Um die kostspieligen Fehler zu vermeiden, die Open-Source-Schwachstellen und Lizenzrisiken verursachen, können SecOps-Teams eine Lösung wie Trend Micro Open Source Security by Snyk einsetzen. Diese unterstützt dabei, Open-Source-Inventories während der gesamten Anwendungsentwicklung mit erhöhter Transparenz für eine frühere Identifizierung und kontinuierlicher Überwachung zu sichern, um die Gefährdung zu minimieren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.