Es gibt Open-Source-Code in fast jedem Softwareentwicklungsprojekt, das Sie sich vorstellen können. Entwickler lieben es. Aber Sie müssen die versteckten Risiken verstehen und wissen, wie Sie sie minimieren können, oder Sie könnten Ihre Anwendung für unbekannte Sicherheitslücken offen lassen.
Coding Before Open Source
h2>
Es war einmal, als Softwareentwickler alles von Grund auf neu schrieben. Dann tauchten Codebibliotheken, Toolkits und andere Add-Ons auf. Sie könnten sich einen Vorsprung verschaffen, indem Sie ein Toolkit verwenden, um einige Funktionen bereitzustellen, z. B. ein Berichtsmodul oder ein Schnittstellen-Widget. Diese könnten Sie als fertige, fertig geformte Komponenten in Ihr Projekt einbinden und sofort verwenden. Die Alternative bestand darin, Zeit, Geld und Entwicklungsaufwand zu verschwenden, um das Rad neu zu erfinden.
Natürlich haben Sie im Laufe der Zeit Ihre eigene Bibliothek mit Routinen und Modulen aufgebaut, die im Haus geschrieben wurden. Wenn Sie also eine neue Coderoutine oder ein neues Schnittstellenelement entwickelten, standen Ihnen drei Optionen zur Verfügung. Schreiben Sie es selbst, verwenden Sie zuvor geschriebenen internen Code wieder oder kaufen Sie eine Bibliothek oder ein Toolkit.
Der Aufstieg von Open Source
Das Aufkommen von Open-Source-Code hat das alles geändert. Open-Source-Software macht den Quellcode eines Projekts innerhalb der Grenzen einer —normalerweise harmlosen—Lizenz frei zur Nutzung durch andere verfügbar. Das Wachstum und die Akzeptanz von Open Source waren atemberaubend. Das Wort Proliferation scheint es nicht abzudecken. Open-Source-Software hat phänomenal zugenommen, und zwar nicht nur im Hinblick auf die unglaubliche Anzahl von Open-Source-Projekten und -Produkten, sondern auch in Bezug auf die Verwendung von Open Source in kommerziellen Produkten.
< p>Open-Source-Software hat vor einigen Jahren eine kritische Masse erreicht und hat sich von einer Nischenposition am Rande zu einer voll akzeptierten Mainstream-Entwicklungsressource entwickelt. Da es von einer Community betrieben und entwickelt wurde und nicht von einem traditionellen kommerziellen Unternehmen, wurde es auch als eine Art Amateur angesehen.
Werbung
Jetzt fühlt es sich an, als wäre Open Source erwachsen und ausgereift. Und es hat. Aber die größte Veränderung war eine breitere Wertschätzung von Open Source, ein Verständnis der Vorteile, die es mit sich bringt, und die Erkenntnis, dass die Einbeziehung von Open Source in Ihr Produkt nichts ist, wofür Sie sich schämen müssen.
Schätzungen gehen davon aus, dass nicht-triviale Softwareprojekte höchstens etwa 20 Prozent des ursprünglichen Codes schreiben. Die anderen 80 Prozent sind Open Source. Die große Open-Source-Hosting-Site für Repositorys, GitHub, erreichte 2018 über 100 Millionen Repositorys. Und es gibt viele andere gehostete Git-Plattformen wie GitLab und BitBucket.
Open Source ist ein Phänomen der Softwareentwicklung. Aber es sind nicht alle Rosen im Entwicklungsgarten. Es gibt Probleme, die Sie kennen und verwalten müssen.
Die Sicherheitsprobleme
Die Verwendung von Open-Source-Komponenten in großen Softwareprojekten senkt die Entwicklungskosten, verkürzt die End-to-End-Entwicklungszeit und fördert die Innovation. Da es Ihre Entwicklungsmitarbeiter vom Alltäglichen befreit, können sie sich auf die einzigartigen und marktattraktiven Aspekte Ihres Produkts konzentrieren.
Es gibt einige Open-Source-Produkte, hinter denen eine kommerzielle Einheit steht. Die Organisation veröffentlicht ihr Produkt im Rahmen eines dualen Lizenzschemas. Eine kommerzielle Version hat einen offiziellen, professionellen Support-Kanal und kann andere Vorteile wie proprietäre Extras enthalten, die mit dem Produkt gebündelt sind. Sie veröffentlichen auch eine von der Community unterstützte Version, die von den Programmierbemühungen des kommerziellen Teams sowie von den Beiträgen der eigenen Community profitieren wird. Bedeutende Community-Beiträge werden auch in die kommerzielle Version zurückkehren.
Die Mehrheit der Open-Source-Projekte ist jedoch vollständig von der Community gesteuert. Sie können von kommerziellen Einrichtungen unterstützt werden, aber diese Unterstützung sind Spenden und Sponsoring, keine Code-Beiträge.
Werbung
Unabhängig von ihrer Herkunft handelt es sich bei den Open-Source-Komponenten, die für die Aufnahme in neue Entwicklungsprojekte ausgewählt werden, in der Regel um etablierte und seriöse Projekte. Sie haben sich ein hohes Maß an Vertrauen erarbeitet. Aber das ist nicht immer der Fall. Manchmal ist die benötigte Funktionalität verfügbar, aber sie ist in einem neuen und noch nicht erprobten Projekt enthalten. Aber Sie haben den Quellcode, oder? Sie können eine Codeüberprüfung durchführen.
Aus Sicherheitssicht ist Open Source weder sicherer noch weniger sicher als proprietärer selbst erstellter Code. Es ist schließlich alles von Menschen geschriebener Code. Befürworter von Open Source verweisen auf Eric S. Raymonds Gesetz, das er zu Ehren von Linus Torvalds benannt hat und das besagt, dass “bei genügend Augäpfeln alle Bugs flach sind.” Wenn genügend Leute den Code überprüfen und Betatests durchführen, sollten Probleme schnell identifiziert, charakterisiert und behoben werden.
Das stimmt so weit wie es geht. Aber Sicherheitsprobleme sind nicht unbedingt Fehler. Eine Schwachstelle kann ein Umstand sein, der als Nebeneffekt komplexer Logik in einem Projekt mit vielen Quellcodemodulen in Millionen von Codezeilen entsteht. Das Produkt tut, was es soll, und es wird gesehen, dass es wie vorgesehen funktioniert. Und so besteht es Code-Review, Produktverifizierung, Feldtests und erhält ein sauberes Gesundheitszeugnis.
Abgesehen von reinem Glück und Zufall werden bei dieser Überprüfungs-, Test-, Test- und Veröffentlichungsschleife keine Sicherheitslücken aufgedeckt.
Warum Open Source für Hacker attraktiv ist
Darüber hinaus gibt es Aspekte von Open Source, die für Hacker und Bedrohungsakteure positiv attraktiv sind. Sie können auch den Quellcode sehen. Sie können mit einer anderen Denkweise nach Schwachstellen suchen als der durchschnittliche Community-Mitwirkende, der zwar ein kompetenter Entwickler ist, aber wahrscheinlich keinen wirklichen Sicherheitshintergrund hat.
Natürlich haben Mitwirkende an Open Source kommen in allen Geschmacksrichtungen mit unterschiedlichen Hintergründen. Einige von ihnen werden zweifellos über praktische Sicherheitserfahrungen verfügen, aber sie werden die Minderheit sein. Bedrohungsakteure sind ein ganz anderes Tier. Und sie sind nicht darauf beschränkt, Schwachstellen zu finden, sie können sie auch einschleusen.
Werbung
Es gab viele Fälle, in denen ein Bedrohungsakteur eine Schwachstelle über einen von ihm erstellten und an ein Projekt übermittelten Patch eingeführt hat. Es hat seinen Weg durch die Codeüberprüfung, in die Codebasis und in die nächste Version des Produkts gefunden.
Das vielleicht ultimative Beispiel dafür war eine JavaScript-Komponente namens event-stream. Dieses Open-Source-Projekt wurde von einem einzigen Entwickler betreut. Die Last der Verwaltung des Projekts war ihm entwachsen. Er wurde überredet, es einem neuen Betreuer zu übergeben.
Der neue Betreuer war ein Bedrohungsakteur. Sie übernahmen das Projekt, führten es für kurze Zeit normal aus und fügten dann Schadcode hinzu. Jede Kopie jedes anderen Programms, das diese Softwarekomponente verwendet, entführte im Stillen bestimmte Arten von Bitcoin-Wallets für den Bedrohungsakteur.
Was Sie tun können, um das Risiko zu verringern
Wie bei vielen Aspekten der Sicherheit steuern Sie dieses Risiko durch die Anwendung von Kontrollen. Das erfordert Governance, d. h. Richtlinien und Verfahren. Zum Glück gibt es Software, die dabei helfen kann.
Ein Open-Source-Register erstellen
Sie müssen die von Ihnen verwendete Open Source quantifizieren. Erstellen Sie ein Register, das die Open-Source-Komponenten auflistet, die Sie in Ihren Projekten verwenden. Listen Sie jede Open-Source-Komponente auf, die Version oder Versionen, die Sie verwendet haben, die Projekte, in denen Sie sie verwendet haben, was die neueste Version ist und wo sie heruntergeladen werden kann. In der Design-Dokumentation für jedes Ihrer Projekte sollten Sie die verwendeten Open-Source-Komponenten auflisten.
Der Teufel steckt im Detail. Vergessen Sie nicht die Abhängigkeiten und die hierarchische Natur eines Großteils von Open Source. Open-Source-Projekte verwenden oft andere Projekte in sich selbst, die wie russische Puppen verschachtelt sind, oder sie erfordern die Installation anderer Open-Source-Komponenten auf dem Zielcomputer, damit sie sie nutzen können.
Werbung
Dringen Sie diese Abhängigkeiten auf und listen Sie sie in Ihrem Open-Source-Register auf.
Automatische Audits ausführen
Sicherheitslücken in Open-Source-Paketen sind ein großes Problem für NPM, den Paketmanager für JavaScript. Um dies zu beheben, haben sie ein automatisches Audit-Tool entwickelt, das mit Sicherheitsupdates nach veralteten Paketen sucht.
Dies hat natürlich seine Grenzen, und es ist wichtig, bewusst zu sein und sich nicht ausschließlich auf automatische Werkzeuge zu verlassen. Es werden nur Pakete mit bekannten Sicherheitslücken und Updates abgefangen. Wenn das Paket eine Sicherheitslücke aufweist, aber nicht aktualisiert wurde, um diese zu beheben, sagt Ihnen das NPM-Audit nichts.
VERBUNDEN: Überprüfen Sie Ihre NPM-Abhängigkeiten, Sie machen 86% der Sicherheitsfehler aus
Erstellen Sie eine Schwachstellenkarte
Ihr Open-Source-Register gibt Ihnen ein klares Bild von der Open-Source, die Sie verwenden. Der nächste Schritt besteht darin, bekannte Schwachstellen auf dieses Register abzubilden. Manchmal können diese entdeckt werden, indem Sie die Homepage des Projekts besuchen und sich die Liste der bekannten Probleme ansehen.
Die National Vulnerability Database (NVD) gibt Ihnen ein viel detaillierteres Bild. Sie können die Suchseite verwenden, um Produkte nach Namen zu suchen, um herauszufinden, welche allgemeinen Schwachstellen und Gefährdungen diese Softwarekomponente betreffen. Die NVD ist eine großartige Ressource, auch wenn ihr Format etwas zu entwirren ist, bis Sie sich daran gewöhnt haben.
Aktualisieren Sie Ihr Register und Ihre Schwachstellenkarte
Dies ist natürlich etwas, das Sie im Auge behalten müssen. Es werden ständig neue Sicherheitslücken entdeckt, sodass der Sicherheitsstatus Ihres Produkts bei der Einführung wahrscheinlich im Laufe der Zeit langsam abgebaut wird.
Werbung
In Anerkennung dieses neuen Bedarfs gibt es kommerzielle (Black Duck, WhiteSource) Anwendungen, die dabei helfen. Sie können Ihre Projekte scannen und Open-Source-Code identifizieren und Schwachstellen automatisch suchen. Einige davon (FOSSA) bieten eine kostenlose Stufe an.
Die statische Analyse Ihrer Codebasis —einschließlich der Open-Source-Komponenten—sollte sowieso ein Standardbestandteil Ihrer Entwicklungsstrenge sein. Tools wie Coverity Scan können Fehler in Ihrem Code finden, z. B. Pufferüberläufe, die zu Sicherheitslücken führen können. Es gibt sogar Ratschläge, wie sie behoben werden können.
Überprüfen Sie die Open Source-Lizenzen und halten Sie sie ein
Stellen Sie sicher, dass Sie die Lizenzen verstehen, die für die von Ihnen verwendeten Open Source-Lizenzen gelten . Es gibt viele verschiedene Lizenzen, also überprüfen Sie, ob Sie alle Anforderungen erfüllen. Ziehen Sie Ihren Lizenz- oder Compliance-Beauftragten hinzu, falls Sie einen haben.
Die Nichteinhaltung einer Open-Source-Lizenz kann zu Rechtsstreitigkeiten führen. Open-Source-Projekte reagieren genauso schnell auf Lizenzverstöße wie kommerzielle Softwarehäuser.
Aktualisieren Sie Ihre Open-Source-Komponenten
Da Schwachstellen von den Open-Source-Communitys behoben werden verwenden, stellen Sie sicher, dass Sie Ihre Versionen aktualisieren, damit Sie von diesen Fixes profitieren. Open Source verwendet ein “Pull” Modell. Sie kündigen einen neuen Fix an und dann müssen Sie diese neue Version herunterladen. Dies ist das Gegenteil vieler kommerzieller Software, die einen “Push” Modell, bei dem Updates an die registrierten Benutzer übertragen werden.
Werbung
Überwachen Sie die Projektseiten auf Ankündigungen neuer Versionen und laden Sie die neuen Builds herunter und testen Sie sie.
Die Kosten von Open Source
Open-Source-Software ist kostenlos erhältlich, bringt jedoch einen Verwaltungs- und Verwaltungsaufwand mit sich. Die Auswirkungen müssen verstanden und kontrolliert werden, um es sicher und mit minimalem Risiko verwenden zu können.