Sichern Sie Ihre Software-Lieferkette mit Bytesafe

Halten Sie Ihre Lieferkette sicher

**Eine sichere Code-Lieferkette beginnt damit, dass Sie wissen, welchen Code Sie tatsächlich in Ihren Anwendungen verwenden.

Webanwendungen sind heute in hohem Maße auf Code angewiesen, der von externen Entwicklern erstellt wurde. So werden Sie feststellen, dass moderne Anwendungen überwiegend auf Open-Source-Software (OSS) von Drittanbietern aufgebaut sind.

Die Code-Lieferkette enthält den gesamten externen Code, von dem eine Anwendung abhängt - sowohl Open Source als auch kommerziell. Und wie bei jeder Lieferkette muss sichergestellt werden, dass der Code immer sicher und effizient das liefert, was Sie brauchen.

Eine Webanwendung kann aus Hunderten oder sogar Tausenden von Code-Abhängigkeiten bestehen. Synopsys gibt an, dass durch die Verwendung externer Abhängigkeiten bis zu 70 % des Codes in Ihren Anwendungen von jemand anderem geschrieben wird. Und 99 % aller analysierten Codebasen enthielten Open-Source-Code.

Hinzu kommt, dass viele Unternehmen nicht wirklich eine gute Bestandsaufnahme oder Kenntnis darüber haben, welche Open-Source-Software sie in ihren Produkten verwenden oder wie groß ihre Abhängigkeit von Open Source ist.

Gartner prognostiziert, dass die Höhe der weltweiten Sicherheitsausgaben bis 2022 170,4 Milliarden Dollar erreichen wird. Die finanziellen Gesamtkosten für Unternehmen, die von Cyberkriminalität betroffen sind, werden im Jahr 2021 weltweit auf 6 Billionen US-Dollar geschätzt. Der Aufwand für die ordnungsgemäße Verwaltung und Sicherung der Code-Lieferkette ist also oft verschwindend gering im Vergleich zu den potenziellen finanziellen Kosten und dem Reputationsverlust als Folge einer Sicherheitsverletzung!

Um den Überblick über Schwachstellen in Ihren Open-Source-Abhängigkeiten zu behalten, müssen Sie sich zunächst bewusst sein, dass sie in Ihrer Codebasis existieren. Fehlende Sichtbarkeit und Einblicke in die von Ihnen verwendeten Pakete können Ihre Softwareanwendung in vielerlei Hinsicht negativ beeinflussen.

Zusätzlich haben die meisten Abhängigkeiten, die Sie verwenden, eigene Abhängigkeiten. Wenn Sie also nur Ihren eigenen Code und dessen Abhängigkeiten scannen, ist Ihre Angriffsfläche viel größer, als Sie vielleicht denken.

Vermeiden Sie es, eine Anwendung mit Sicherheitslücken, Abhängigkeitsproblemen oder Verstößen gegen Lizenzbedingungen zu erstellen. Bytesafe kann verhindern, dass Sie Ihre Anwendungen und Ihr Geschäft gefährden, indem Sie die Sicherheit Ihrer Abhängigkeiten verbessern und Ihre Code-Lieferkette schützen.

Was ist Abhängigkeitssicherheit?

Abhängigkeitssicherheit ist das Konzept des Managements des Risikos, das durch externen Code in Ihre Anwendung eingebracht wird, Code, über den Sie keine direkte Kontrolle haben.

Abhängigkeitssicherheit beginnt damit, dass Sie die Abhängigkeiten, die Sie verwenden, kennen und kontrollieren. Und es geht weiter mit der Sicherstellung, dass Abhängigkeiten sicher und vertrauenswürdig sind, immer verfügbar, aktuell, den Sicherheitsrichtlinien Ihres Unternehmens entsprechend und absichtlich hinzugefügt wurden.

Die Kontrolle ist notwendig, um Sicherheitsangriffe wie Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), XML External Entity (XXE) und Business Logic-Angriffe abwehren zu können, um nur einige zu nennen. Angriffe, die möglicherweise durch Typosquatting oder Abhängigkeitsverwirrung in Ihre Lieferkette eingeschleust werden.

Die sich ständig verändernde Open Source-Landschaft macht die Verwaltung und Verfolgung von Code-Abhängigkeiten, Open Source-Sicherheit und Lizenzkonformität zu einer anspruchsvollen Aufgabe für Unternehmen, die Open Source in ihrer Codebasis verwenden.

Organisationen müssen sicherstellen, dass:

1. Open-Source-Abhängigkeiten sicher sind
2. Paket-Workflows die erforderlichen Geschäfts- und Sicherheitsrichtlinien erfüllen

Um sichere Anwendungen zu entwickeln, müssen Entwickler die verschiedenen Typen von Angriffen, die ausgenutzt werden können, verstehen und sich ihrer bewusst sein. Das tut nicht jeder. OWASP ist eine großartige Informationsquelle, die Ihnen hilft, sich auf den neuesten Stand zu bringen: https://cheatsheetseries.owasp.org/.

Was ist eine Abhängigkeit?

Die Verwendung und gemeinsame Nutzung von wiederverwendbaren Code-Bausteinen ist alltäglich und beschleunigt den Lebenszyklus der Softwareentwicklung (SDLC). Jeder Code-Baustein ist für einen bestimmten Zweck bestimmt und erspart den Entwicklern Zeit und Mühe, ihn selbst zu schreiben.

Eine Abhängigkeit ist ein wiederverwendbares Codestück, von dem eine Anwendung abhängt und das erforderlich ist, damit sie ordnungsgemäß funktioniert. Für Webanwendungsprojekte werden diese Abhängigkeiten oft über Paketmanager wie npm bezogen. Die öffentliche npm-Registry enthält etwa 1,5 Millionen Pakete, die Entwickler jederzeit herunterladen können, mit durchschnittlich 1 Milliarde Downloads pro Tag.

Abhängigkeiten im npm-Ökosystem sind aus zwei Gründen aus einer Sicherheitsperspektive besonders interessant.

Erstens ist die Verwendung von Abhängigkeiten ein natürlicher Teil von JavaScript, mit einem Open-Source-Ethos der Wiederverwendung von Code, der von Entwicklern weit verbreitet ist.

Zweitens, Abhängigkeiten haben oft selbst Abhängigkeiten. Wenn Sie also neue Pakete zu Ihrem Projekt hinzufügen, kann es sein, dass Sie mehr Abhängigkeiten einbeziehen, als Sie ursprünglich dachten oder beabsichtigten.

Es gibt zwei Typen von Abhängigkeiten;

• Direkte Abhängigkeiten, wenn Ihre Anwendung einen Teil des Codes direkt verwendet und ihn direkt referenziert
• Transitive Abhängigkeiten, bei denen es sich um Abhängigkeiten zu den direkten Abhängigkeiten Ihrer Anwendung handelt (auch bekannt als Abhängigkeit von einer Abhängigkeit)

Gutes Abhängigkeitsmanagement bedeutet, Sichtbarkeit, Einblick und Kontrolle über alle Abhängigkeiten zu haben, die Ihre Anwendungen verwenden. Einschließlich aller transitiven Abhängigkeiten!

Das Risiko besteht darin, dass Sie durch die Einführung von Software von Drittanbietern in Ihre Anwendung auch die Schwachstellen, Sicherheitslücken und Softwarefehler der Drittanbieter-Software übernehmen.

Verwalten der Abhängigkeitssicherheit

In größeren Organisationen mit mehreren Entwicklungsteams und zahlreichen Anwendungen kann es eine komplexe Aufgabe sein, den Überblick darüber zu behalten, welche Abhängigkeiten in Ihren Anwendungen verwendet werden.

Traditionell verwenden Backend-Dienste Authentifizierung, Verschlüsselung von Daten, sichere Speicher für Token und Berechtigungsnachweise, Zugriffsmanagement und so weiter. Aber Ihre Frontend-Sicherheit ist nur so stark wie Ihr schwächstes Glied oder Ihre externen Abhängigkeiten.

Es ist wichtig, dass Sie Ihre Abhängigkeiten auf dem neuesten Stand halten, aber die Priorisierung zwischen Abhängigkeiten, die anfällig für Sicherheitsbedrohungen sind, und Updates, die Ihren Code nicht zerstören, kann verwirrend sein.

Die Erstellung eines klaren Protokolls für die Verwaltung von Abhängigkeiten hilft, später im Entwicklungszyklus Kopfschmerzen zu vermeiden, wenn es teurer sein könnte, diese zu beheben.

Vermeiden Sie veraltete und überholte Abhängigkeiten

In gewisser Weise ist Software eine frische Ware, bei der Sie sicherstellen wollen, dass Sie gut gewartete und aktualisierte Komponenten verwenden. Neue Versionen enthalten möglicherweise nicht nur neue Funktionen, die Sie als Unternehmen nutzen möchten, sondern auch kritische Korrekturen für bekannte Schwachstellen, die potenzielle Angriffsvektoren schließen.

Als Anwender möchten Sie den Verfall von Software vermeiden und sicherstellen, dass die Abhängigkeiten, die Sie verwenden, mit den neuesten Versionen aktualisiert werden. Unternehmen sollten einen Ansatz entwickeln, wie sie ihre Abhängigkeiten kontinuierlich überprüfen und aktualisieren können. Dabei sollten sie die Vorteile aktueller Abhängigkeiten gegen den Aufwand abwägen, der nötig ist, um ihre Anwendungen mit neuen Abhängigkeitsversionen zu testen.

Ohne einen Plan zur Vermeidung veralteter Abhängigkeiten, kombiniert mit dem Verzicht auf Versionsaktualisierungen, verpassen Sie möglicherweise Folgendes

• Die neuesten Erweiterungen, die die Leistung verbessern oder neue Funktionen hinzufügen
• Fehlerbehebungen
• Warnungen vor Code, der veraltet ist oder das Ende der Lebensdauer erreicht hat
• Außerdem setzen Sie Ihre Anwendung und Benutzer bekannten Sicherheitslücken aus

Abhängigkeit von externen Entwicklern

Innerhalb Ihrer eigenen Organisation haben Sie wahrscheinlich interne Richtlinien und Kontrollen, um sicherzustellen, dass der von Ihnen geschriebene Code gründlich getestet wird, mit definierten KPIs für Code-Metriken und so weiter.

Was den Code von Drittanbietern angeht, wird das meiste davon nicht von großen Unternehmen wie Facebook oder Google geschrieben, mit all ihrer beträchtlichen Entwicklermacht dahinter. Stattdessen werden die meisten Pakete von engagierten Gemeinschaften einzelner Entwickler veröffentlicht, die den Code mit ihren eigenen Zielen im Hinterkopf pflegen.

Wenn Ihre Anwendung externe Abhängigkeiten nutzt, bedeutet das, dass Sie als Unternehmen von Entwicklern abhängig sind, auf die Sie keine wirkliche Kontrolle ausüben können. Und das ist ein ernüchternder Gedanke. Wie können Sie ohne Kontrolle wissen, ob die Open-Source-Komponenten in Ihrer Codebasis gewartet werden?

Wenn Sie eine Abhängigkeit von externen Entwicklern haben, sind Sie nicht in der Lage:

• Beeinflussen, wie der Komponentencode geschrieben wird
• Verhindern, dass der Code in der Zukunft geändert wird
• Angemessene Hintergrundprüfungen für neue Entwickler, die an der Codebasis mitarbeiten, sicherstellen
• Kontrollieren, ob die Entwickler Token und Berechtigungsnachweise sicher verwalten
• Wissen, ob der Code mit Ihren Abhängigkeiten kompatibel bleibt

Heutzutage hat npm eine viel striktere unpublish policy, aber in der Vergangenheit gab es Vorfälle aufgrund von unveröffentlichten Paketen. Zum Beispiel gab es einen Fall, in dem ein JavaScript-Entwickler seine Pakete aus npm herauszog. Programmierer wurden mit kaputten Builds und fehlgeschlagenen Installationen für eine Funktion zurückgelassen, die ausgiebig in anderen Anwendungen verwendet wurde. Das Kernproblem der mangelnden Kontrolle über Schlüsselkomponenten in Ihren Anwendungen bleibt bestehen, und verschiedene Dienste können unterschiedliche Richtlinien für das Unpublishing haben.

Mangel an sicherer Token- und Credentials-Verwaltung für Paketbetreuer

Statistiken von 2020 zeigen, dass nur 9,27% aller Betreuer von npm-Paketen eine 2-Faktor-Authentifizierung (2FA) verwenden, um ihre Konten vor Hackerangriffen oder Übernahmen zu schützen.

Da so viele Betreuer keine 2FA verwenden, um ihre Konten zu schützen, besteht das Risiko, dass man nicht wirklich darauf vertrauen kann, ob eine neue Paketversion vom ursprünglichen Betreuer oder einer Partei mit bösartigen Absichten veröffentlicht wurde.

Es gibt kein anderes Ökosystem wie Javascript mit den gleichen riesigen Mengen an Benutzern, Code und Downloads, wenn es um die Anzahl der verfügbaren Open-Source-Bibliotheken geht. Eine ideale Umgebung für Hacker, die versuchen, Ihre Code-Lieferkette anzugreifen.

Gehen Sie davon aus, dass Ihre Abhängigkeiten Sicherheitslücken haben.

Bei der Abhängigkeitssicherheit geht es auch darum, wie Sie mit bekannten Schwachstellen in Bibliotheken von Drittanbietern umgehen und neue Bedrohungen vermeiden, sowie darum, wie Sie die externen Abhängigkeiten in Ihren Anwendungen verwalten.

Im Laufe der Zeit können Anwendungsabhängigkeiten veraltet sein oder es können neue Schwachstellen gefunden werden. Daher ist es wichtig zu wissen, welche Abhängigkeiten Ihre Anwendung verwendet (sowohl direkte als auch transitive Abhängigkeiten), um potenzielle Probleme beheben zu können und auf dem neuesten Stand zu bleiben.

Es ist leicht, neue Abhängigkeiten einzubinden, daher müssen Sie sicherstellen, dass die Abhängigkeiten Ihrer Anwendung gemäß den von Ihrem Unternehmen festgelegten Regeln verwaltet werden.

Qualität von Abhängigkeiten

Wenn es um die Qualität von Open Source geht, gibt es keine Kontrollen oder Sicherheits-/Qualitätssicherungsprüfungen, die erfüllt werden müssen, um ein Paket in einer öffentlichen Registry zu veröffentlichen.

Das bedeutet, dass Sie Pakete finden werden, bei denen die Sicherheit ernst genommen wurde, aber es gibt auch viele Pakete, bei denen die Sicherheit keine Priorität war.

Während es viele Werkzeuge und Dienste gibt, um die Auffindbarkeit von Paketen zu vereinfachen, ist es auch wichtig zu entscheiden, welche Metriken man sucht und bewertet, bevor man sich entscheidet, eine neue Abhängigkeit in seine Anwendung aufzunehmen.

Eine oft verwendete Metrik ist zum Beispiel Popularität (Anzahl der Downloads, abhängige Pakete usw.), was für die Sicherheit von Abhängigkeiten nicht ausreichend ist und ein irreführendes Signal darstellt. Andere übliche Metriken, die man betrachten kann, sind das letzte Veröffentlichungsdatum, veraltete Abhängigkeiten, stabile Versionen, die Existenz von Schlüsseldateien (z.B. README), Codeabdeckung durch Tests und ob es eine eigene Webseite gibt.

Bei der großen Anzahl von externen Abhängigkeiten, die es gibt, sollte die Abhängigkeitssicherheit etwas sein, womit jeder in einem Team arbeiten und sich darum kümmern sollte, anstatt nur ein oder zwei Personen dafür zu haben. Abhängigkeitssicherheit ist jedermanns Problem!

Ist offener Quellcode sicher?

Nein, standardmäßig nicht.

Theoretisch bedeutet “open source allows for more eyes on the code”, dass mehr Leute den Code “beäugen”, was ein besseres Maß an Sicherheit impliziert, als zum Beispiel proprietärer geschlossener Code, der den Zugang und die Sichtbarkeit einschränkt.

Während es wahr ist, dass mehr Leute den Code anschauen, ist es ein Mythos, dass sie alle die Zeilen des Codes unter die Lupe nehmen, und fleißig versuchen die Falten auszubügeln. Bei so vielen Open-Source-Projekten, die Millionen von Codezeilen umfassen, gibt es nicht genügend entsprechend qualifizierte Personen im Sicherheitsbereich, die den Code umfassend prüfen und überprüfen können.

Und was noch schlimmer ist: In Situationen, in denen Software selten oder nie überprüft oder aktualisiert wird, können Code-Schwachstellen für bösartige Aktivitäten ausgenutzt werden.

Die Verwendung von Paketen aus der öffentlichen npm-Registry ist zu einem so einfachen Prozess geworden, dass er zum Anstieg der Downloads und der Softwareproduktivität beigetragen hat. Aber bei dem halsbrecherischen Tempo, das von Entwicklern erwartet wird, um Anwendungen zu produzieren, haben viele ihren Code und die Abhängigkeiten von Drittanbietern nie wirklich überprüft.

Versteckt im Offensichtlichen

Die Herausforderungen bei der Verwaltung von Abhängigkeiten und der Sicherheit sind nicht nur im JavaScript-Ökosystem zu finden. Die äußerst beliebte Open-Source-Bibliothek OpenSSL wurde von nur zwei Entwicklern gepflegt. Viele Websites auf der ganzen Welt waren von der Sicherheitslücke Heartbleed betroffen. Der Fehler war bereits seit 2 Jahren bekannt, bevor er gepatcht wurde, obwohl die Bibliothek quelloffen ist.

Angriffe auf die Code-Lieferketten

Angriffe auf die Lieferkette sind auf dem Vormarsch und haben in den letzten Jahren zugenommen. Anstatt zu versuchen, vorhandene Schwachstellen im Code zu hacken und auszunutzen, versuchen Hacker immer häufiger, ihren bösartigen Code als Teil des Build-Prozesses in Ihre Anwendungen einzubauen.

Supply-Chain-Angriffe, die Sie kennen und auf die Sie achten sollten:

• Paket- und Kontoübernahme (mit böswilliger Absicht)
• Typosquatting und Combosquatting
• Verwirrung von Abhängigkeiten

Der jüngste Supply-Chain-Angriff von SolarWinds ist vielleicht das bekannteste Beispiel für einen Supply-Chain-Angriff, bei dem bösartiger Code in eines der SolarWinds-Produkte eingefügt und als Update an viele ihrer Kunden verteilt wurde. Es gibt aber auch zahlreiche aktuelle Beispiele für bösartige Pakete ähnlicher Angriffe im npm-Ökosystem.

Da diese Art von Angriffen und Versuchen zunimmt, ist es jetzt wichtiger denn je, Ihre Code-Lieferkette zu schützen!

Paket- und Account-Übernahme-Angriffe

Eine Möglichkeit für Hacker, in Ihre Anwendung zu gelangen, ist über die Lieferkette, indem sie ein legitimes npm-Paket aus der langen Liste von Abhängigkeiten ausnutzen, die Sie bereits verwenden.

Mit Zugriff auf den Maintainer-Token für ein Paket kann leicht eine neue Version veröffentlicht werden, die eine gezielte Schwachstelle enthält, die ausgenutzt werden kann. Solche Angriffe behalten oft die gesamte ursprüngliche Funktionalität des ursprünglichen Pakets bei, da es dadurch abwärtskompatibel und schwieriger zu entdecken ist. Durch die weitverbreitete Wiederverwendung von npm-Paketen kann ein kompromittiertes Konto viele Benutzer auf der ganzen Welt betreffen.

Eine Möglichkeit, Zugriff auf ein legitimes Paket zu erhalten, ist die Ausnutzung der Tatsache, dass viele Paketbetreuer ihre Anmeldedaten nicht absichern, keine starken Passwörter erstellen oder die Zwei-Faktor-Authentifizierung mit npmjs verwenden.

Es wird auch traditionelles Social Engineering verwendet, bei dem böswillige Entwickler zunächst zur Codebasis beitragen, aber sobald sie als Betreuer hinzugefügt werden, fügen sie böswilligen Code hinzu und veröffentlichen neue Versionen oder entfernen sogar den ursprünglichen Betreuer (was als Kontoübernahme bezeichnet wird).

Typosquatting- und Combosquatting-Angriffe

Typosquatting-Angriffe, die Entwickler dazu verleiten, bösartige Pakete zu installieren, die ähnliche Namen wie die offiziellen Pakete haben. Combosquatting ist dem Typosquatting ähnlich, verwendet aber realitätsnahe Namen, anstatt sich auf Tippfehler zu verlassen.

Indem sie sich auf menschliche Fehler durch Tippfehler verlassen oder hoffen, dass sich Entwickler nicht die Mühe machen, die Abhängigkeiten zu überprüfen, wollen Hacker ihre Pakete in Ihre Projekte und Ihre Lieferkette einschleusen.

Wenn Sie Open-Source-Pakete herunterladen und verwenden, vertrauen Sie im Wesentlichen dem Herausgeber, obwohl keiner der Paket-Hosting-Dienste jemals garantieren kann, dass der gesamte hochgeladene Code frei von Malware ist.

Die meisten Entwickler und Organisationen vertrauen blind darauf, dass die verwendeten Abhängigkeiten keine bösartigen Inhalte enthalten (absichtlich oder nicht). Und bei der Installation von Paketen aus npm oder einem anderen Repository laden die Benutzer automatisch ein Paket zusammen mit allen zugehörigen Abhängigkeiten herunter und installieren es.

Um auf der sicheren Seite zu sein, müssen Sie sicherstellen, dass Sie die Pakete ziehen, die Sie beabsichtigen.

Abhängigkeitsverwirrungs-Angriffe

Abhängigkeitsverwirrung (manchmal auch als Substitutionsangriffe bekannt) verwirrt Paketmanager bei der Frage, welche Paketversion sie in ihr Projekt ziehen sollen. Die Angriffe zielen auf Schwachstellen oder Designfehler in automatisierten Build- oder Installations-Tools ab, die es ermöglichen, öffentliche Abhängigkeiten mit internen Abhängigkeiten mit genau demselben Namen zu verwechseln.

Der Angriff umfasst das Hochladen von Malware in Open-Source-Repositories und die automatische Verteilung von Paketen in die internen Anwendungen eines Unternehmens - wobei das öffentliche Paket Vorrang hat und gezogen wird, ohne dass der Entwickler etwas unternehmen muss.

Ist der Angriff erfolgreich, wird ein Paket aus einer ungewollten Quelle in Ihre Anwendungen eingebunden, mit der Möglichkeit, Skripte auszuführen und beliebigen Code auf dem Server auszuführen.

Absicherung Ihrer Code-Lieferkette

Das Sichern Ihrer Lieferkette setzt voraus, dass Sie die Prozesse eingerichtet haben, um sicherzustellen, dass neue Abhängigkeiten oder Versionen absichtlich hinzugefügt werden. Es setzt auch voraus, dass Sie Zugang zu den richtigen Tools haben, die Ihnen die richtige Tiefe an Transparenz und Übersicht bieten und Ihnen helfen, Ihr Unternehmen vor bösartigem Code zu schützen.

Wie bei der Qualitätssicherung (QA), wo es besser ist, Fehler zu finden, bevor sie eingesetzt werden, ist es besser, Sicherheits- und Lizenzprobleme zu blockieren und zu erkennen, bevor sie zu Problemen werden.

Sichern Sie Ihre Lieferkette durch:

• Kontinuierliches Scannen von Abhängigkeiten, um Schwachstellen zu finden
• Verwenden Sie Bytesafe-Sicherheitsrichtlinien, um Ihre Abhängigkeiten gemäß Ihren Geschäftsregeln zu verwalten
• Erstellen einer Abhängigkeits-Firewall
• das gleiche Sicherheitsniveau für alle Pakete haben

Abhängigkeiten kontinuierlich scannen, um Schwachstellen zu finden

Auch wenn Ihre Abhängigkeiten sicher sind, wenn Sie sie zu Ihren Anwendungen hinzufügen, werden ständig neue Schwachstellen gefunden. Scannen Sie Ihre Abhängigkeiten kontinuierlich, anstatt sich nur auf punktuelle Scans zu verlassen, und stellen Sie sicher, dass kritische Sicherheitslücken nicht ihren Weg in Ihre Anwendungen finden.

Der Vulnerability Scanner in Bytesafe erkennt bekannte Sicherheitslücken in Ihren Abhängigkeiten. Wenn der Scanner Schwachstellen identifiziert, werden Benachrichtigungen an die Benutzer gesendet und Sicherheits-Badges hinzugefügt, um die betroffenen Abhängigkeiten zu kennzeichnen.

Die Sicherheits-Badges zeigen den Schweregrad der Schwachstelle an und verweisen auf das Advisory, das zusätzliche Informationen enthält, z. B. eine Empfehlung, wie das Sicherheitsproblem behoben werden kann.

Der Schwachstellen-Scanner hilft Ihnen, über die Sicherheit Ihrer Abhängigkeiten auf dem Laufenden zu bleiben, indem er Schwachstellen findet und hervorhebt. Um Pakete einzuschränken, lesen Sie, wie Sie Bytesafe Security Policies verwenden.

Mit Bytesafe Security Policies verwalten Sie Ihre Abhängigkeiten nach vorgegebenen Geschäftsregeln

Sicherheitsrichtlinien in Bytesafe ermöglichen es Ihnen, Ihre Abhängigkeiten in Ihrer gesamten Umgebung homogen nach Ihren bestehenden Geschäftsregeln zu verwalten. Bytesafe-Sicherheitsrichtlinien sind Regeln, die vor jeder Registrierungsaktion ausgeführt werden und verhindern, dass unerwünschte Paketversionen in Ihre Registrierungen aufgenommen werden.

Um zu vermeiden, dass eine oder wenige Personen für die Abhängigkeitssicherheit verantwortlich sind, verlagern Sie die Verantwortung von einzelnen Entwicklern auf Ihre Teams, indem Sie effiziente Tools wie Bytesafe verwenden.

Nutzen Sie die Palette der Sicherheitsrichtlinien in Bytesafe, um die Kontrolle über die Abhängigkeiten zu etablieren. Ein Beispiel ist die Freeze-Policy, mit der Sie Registrierungen (vorübergehend oder dauerhaft) schreibgeschützt machen können. Oder die Secure policy, die verhindert, dass Paketversionen mit bekannten Sicherheitslücken in Ihre Registrierungen aufgenommen werden.

Die Block policy kann verwendet werden, um ganze Pakete oder Versionsbereiche davon abzuhalten, in eine Registrierung gezogen zu werden.

Durch das Blockieren von internen Paketnamen in einer Firewall-Registrierung ist es nicht mehr möglich, dass externe Pakete die internen Pakete ersetzen.

Erstellen einer Abhängigkeits-Firewall

Die Idee ist einfach: Erstellen Sie einen Link zur öffentlichen npm-Registry, der als einziger Kontaktpunkt mit der Außenwelt fungiert.

Alle anderen internen Registrierungen werden diese einzelne Firewall-Registrierung als Paketquelle verwenden. Dies ermöglicht einen zentralen Punkt, an dem Sicherheitsteams überwachen und sicherstellen können, dass nur genehmigte Pakete aufgenommen werden.

Durch diese Art der Verwendung einer Abhängigkeits-Firewall sickern neue Pakete und Versionen nicht automatisch zu allen anderen Benutzern und Anwendungen in einer Organisation durch.

Das gleiche Sicherheitsniveau für alle Pakete haben

Verwenden Sie Bytesafe, um Ihre verschiedenen Teams (Dev / DevOps / DevSecOps) zusammenzubringen, damit sie gemeinsam an der Sicherheit Ihrer Abhängigkeiten arbeiten können.

Sofern Sie nicht explizit die Verwendung einer privaten Registry konfiguriert haben, wird standardmäßig direkt die öffentliche Registry verwendet. Der npm-Client ermöglicht die Installation von Paketen sowohl von einer npm-Registry als auch direkt von einem Git-Repository.

Um eine zusätzliche Sicherheitsebene hinzuzufügen, sollten Sie sicherstellen, dass die gesamte Organisation private Registrierungen für Ihre eigenen Pakete verwendet, die Pakete aus der öffentlichen npm-Registrierung projizieren.

Auf diese Weise erhalten Sie Einblicke in die Pakete, die in einer Anwendung verwendet werden, und haben die Flexibilität, den Grad der Sicherheit zu bestimmen und zu kontrollieren.

Durch das Einrichten einer Hierarchie von Registries mit verschiedenen Sicherheitsstufen (Kuration und Trennung der Registries) können Sie Bytesafe-Richtlinien und Plugins auf alle Ihre Pakete anwenden, unabhängig davon, ob sie von einer npm-Registry oder einem Git-Repo stammen.

Daher sollten alle Entwickler und Systeme, die npm-Pakete verwenden, so konfiguriert werden, dass sie private Bytesafe-Registries mit höherer Sicherheit und Kontrolle verwenden.

Welche Sicherheit bringt Bytesafe?

Alle eigenen Pakete und externen Code-Abhängigkeiten zentral in Bytesafe zu haben, ermöglicht eine kontinuierliche Überwachung, Überprüfung und Kontrolle des Codes, den Sie verwenden.

Zu wissen, welchen (und wessen) Code Sie verwenden, ist der Kern der Sicherung Ihrer Code-Lieferkette. Schalten Sie nach links und identifizieren Sie alle Probleme früh im SDLC!

Die Verwendung von Bytesafe ermöglicht den Zugriff auf:

• Private Registries. Teilen Sie Ihre Pakete innerhalb von Teams in vollständig verwalteten Artefakt-Registries. Zwischenspeichern externer Abhängigkeiten, um sicherzustellen, dass sie immer verfügbar sind
• Identifizierung aller Abhängigkeiten. Wissen Sie, welche Abhängigkeiten Sie verwenden. Sofortige Erkennung, wenn direkte und transitive Abhängigkeiten als veraltet gekennzeichnet sind
• Abhängigkeits-Firewall. Schränken Sie mit Richtlinien und Plugins ein, welche Pakete in Ihren Registern erlaubt sind
• Sicherheits-Scanning. Schalten Sie nach links und erkennen Sie Schwachstellen frühzeitig, indem Sie kontinuierlich alle Pakete scannen
• Lizenzkonformität. Analysieren Sie, welche Lizenzen Sie in Ihre Anwendungen einbinden und erkennen Sie, ob Sie Lizenzprobleme haben
• Deterministische Ergebnisse. Stellen Sie sicher, dass Sie Bytesafe in Ihrer CI/CD-Pipeline über verschiedene Umgebungen hinweg einsetzen. Die Tester werden in der Lage sein, genau die gleichen Versionen zu testen, die die Entwickler beabsichtigt haben. Keine Fehlkonfigurationen mehr
• Bringen Sie Ihr Team zusammen. Ermöglichen Sie es Entwicklern, QA, Sicherheitsexperten und Geschäftsteams, dieselben Tools zu verwenden, um eine interne Trennung zwischen verschiedenen Rollen zu vermeiden. Sicherheit ist eine Teamleistung!