Open Source Security Management

Sicherer Umgang mit Open Source Code

| Autor / Redakteur: Patrick Carey / Peter Schmitz

Ohne Inventarisierung, Management und Sicherung der in Anwendungen verwendeten Open-Source-Komponenten bieten Unternehmen Angreifern ein leichtes Ziel.
Ohne Inventarisierung, Management und Sicherung der in Anwendungen verwendeten Open-Source-Komponenten bieten Unternehmen Angreifern ein leichtes Ziel. (Bild: Pexels)

Die Verwendung von Open Source Code in Anwendungen hat sich im Laufe der Jahre dramatisch erhöht. Mittlerweile umfassen Open Source-Komponenten 50 Prozent und mehr von vielen Software-Applikationen. Unternehmen übersehen dabei aber oft die Sicherheitsfragen im Zusammenhang mit Open Source-Anwendungen. Es gibt aber ein paar einfache Tipps, wie Unternehmen ihre Open Source Codebasis besser managen und Sicherheitsrisiken vermeiden können.

Während die Vorteile der Nutzung von Open Source offensichtlich sind - schnelleres Time-to-Market, größere Innovationsmöglichkeiten, niedrigere Entwicklungskosten, Unterstützung einer globalen Community – dürfen die Sicherheitsfragen im Zusammenhang mit Open Source-Anwendungen nicht übersehen werden. Mehr als 80 Prozent aller Cyber-Attacken zielen auf Software-Applikationen. Angreifer sehen Open-Source-Komponenten innerhalb von Anwendungen als lohnendes Ziel. Zudem sind Informationen über Open Source Schwachstellen weit verbreitet, und Angreifer können potenziell Tausende von Anwendungen mit minimalem Aufwand kompromittieren.

Um Missverständnissen vorzubeugen: Open Source ist genauso sicher wie kommerzieller Code. Die Debatte zu "Sicher oder nicht so sicher?" zieht sich wie ein roter Faden durch viele Diskussionsforen, übersieht aber den springenden Punkt: viele Unternehmen sind sich einfach im Unklaren darüber, wie viel Open-Source bei ihren Anwendungen zum Einsatz kommt. Als Folge sind sie anfällig für Schwachstellen, die sich in ihrem Open-Source befinden.

Open Source vs. Closed Source: Was ist sicherer?

Anwendungssicherheit und Sicherheitslücken

Open Source vs. Closed Source: Was ist sicherer?

30.01.17 - Open Source vs. Closed Source – ein Streit, der von vielen Anwendern mit religiösem Eifer ausgefochten wird. IT-Entscheider denken da pragmatischer: Sie suchen nach Lösungen, die ihrem Unternehmen den größten Nutzen bringen. lesen

Obwohl es für ihre Anwendungsentwicklung eigentlich kritisch ist, verfügen nur wenige Organisationen über strenge Prozesse, um die von ihnen verwendeten Open Source-Komponenten zu identifizieren, zu verfolgen und zu verwalten. Black Duck Audits von Kunden-Codebasen zeigen durchgehend, dass die meisten Unternehmen doppelt so viel Open-Source verwenden, wie sie glauben, dass sie in ihren Anwendungen haben. Hier folgen nun einige Hinweise, wie Unternehmen ihre Open Source Codebasis besser managen und Sicherheitsrisiken vermeiden.

Inventarisieren Sie Ihren Open Source Code

Zunächst benötigen Sie eine vollständige und genaue Bestandsaufnahme aller Open-Source-Komponenten in Ihrer Codebasis. Ein vollständiges Open-Source-Inventar sollte alle Open Source-Komponenten, die Version(en) im Einsatz und Download-Standorte für jede Anwendung in Entwicklung und Produktion enthalten. Sie müssen alle Abhängigkeiten - die Komponenten, auf die Ihr Code zugreift, sowie die Komponenten, mit denen die Abhängigkeiten verknüpft sind - in Ihr Inventar aufnehmen.

Verzeichnis über bekannte Schwachstellen

Stellen Sie sich eine Liste der bekannten Sicherheitslücken zusammen, die sich auf die von Ihnen inventarisierten Open-Source-Komponenten beziehen. Ihre primäre Ressource wird wahrscheinlich die National Vulnerability Database sein. Beachten Sie jedoch, dass nicht alle Schwachstellen der NVD gemeldet werden und dass das Format von NVD-Datensätzen es oft schwierig macht, festzustellen, welche Version einer bestimmten Open-Source-Komponente von einer Sicherheitslücke betroffen sind.

Identifizieren Sie mögliche Lizenz- und Code-Qualitätsrisiken

Wenn Sie Software-Bundles, eingebettete oder kommerzielle SaaS-Software erstellen, ist Open-Source-Lizenzkonformität auch ein wichtiger Punkt - insbesondere für Ihr juristisches Team. Unabhängig davon, wie Ihre Apps bereitgestellt werden, sollten Sie auch überprüfen, ob Sie qualitativ hochwertige Open-Source-Komponenten sowie aktuelle und stabile Versionen dieser Komponenten verwenden, die zudem von einer zuverlässigen Community aktiv verwaltet werden.

Risiko kontrollieren

Sobald Sie Sicherheitslücken identifiziert sowie die Lizenzierung und Qualität der Komponenten geklärt haben, ist es an der Zeit, diese Risiken zu priorisieren und diese zu anzugehen. Bestimmen Sie, welche Korrekturmaßnahmen durchgeführt werden müssen. Ordnen Sie den entsprechenden Personen die Sanierungsarbeiten zu und verfolgen Sie den Korrekturprozess: Was wird überprüft? Was wurde überprüft? Was wurde behoben? Welche Fixes wurden verschoben? Was wurde gepatcht? Die Arbeit hört nicht auf, wenn eine Applikation frei gegeben wird, sie müssen sie überwachen, solange die Anwendung in Betrieb ist.

Manuelles versus automatisiertes Open Source Security Management

Die Chancen sind leider groß, dass manuelles Open Source-Sicherheits-Management mit erheblichen Investitionen in Zeit, Ressourcen und Budget abläuft – und dabei dennoch nie komplett sein wird. Es wird sowohl die Produktivität Ihrer Software-Entwickler negativ beeinflussen als den gesamten SDLC (Secure Software Development Lifecycle). Daher wenden sich viele Organisationen einer automatisierten Lösung zum Open Source-Risikomanagement zu. So inventarisieren sie effektiv Open Source Code, schützen ihn vor Sicherheitsproblemen und anderen Open Source-Risiken und stellen die Anwendung von Open Source-Richtlinien sicher.

Anwendungs-Schwachstellen sind die Sicherheitsgefahr Nummer 1 für Ihr Unternehmen. Ohne Inventarisierung, Management und Sicherung der in Ihren Anwendungen verwendeten Open Source-Komponenten bieten Sie Angreifern ein leichtes Ziel.

Über den Autor: Patrick Carey ist Leiter Produktmarketing bei Black Duck Software.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44619410 / Schwachstellen-Management)