Dies ist die dritte Episode in einer Reihe von Artikeln über die am weitesten verbreitete Art von Angriffen auf die Software-Lieferkette: Angriffe, die ein öffentliches Register von Open-Source Softwarekomponenten. Nach der Analyse in der vorherigen Folge „Anatomie bösartiger Pakete: Was sind die Trends?„Wenn wir uns ansehen, wie die böswilligen Akteure bösartiges Verhalten in neue oder bereits veröffentlichte Komponenten einschleusen, sind wir bereit, unsere Feuerwehrwesten anzuziehen und zu untersuchen, wie wir auf diese Weise verbreitete bösartige Software erfolgreich blockieren können, oder, alternativ, mit einem potenziell schwerwiegenden Cyber-Vorfall fertig werden, weil wir den falschen Ansatz gewählt haben.
Die meisten sicherheitsbewussten Fachleute haben Ideen, wie man mit dieser Bedrohung umgehen kann. Wir haben Sicherheitsmanager ohne Zögern sagen hören: SCA Tools erkennen bereits, wann eine Paketversion Malware enthält. Oder dass sie auf bekannte, hochgeprüfte Softwarekomponenten angewiesen sind, bei denen Malware umgehend erkannt und entfernt wird. Sie verwenden offene Neben-/Patch-Versionen, um Schwachstellen automatisch zu beheben. Dies ist der richtige und empfohlene Weg, um das Risiko von Open-Source-Abhängigkeiten zu senken, gemäß dem „früh patchen, oft patchenPrinzip.
In dieser Folge untersuchen wir, warum diese Vorstellungen falsch sind und wie solche Missverständnisse zur Popularität dieses Angriffsmechanismus beitragen und zu einem enormen Risiko für Organisationen führen. Wir beenden die Diskussion damit, was funktioniert und welcher Aufwand und welche Ressourcen dafür erforderlich sind.
Häufige Missverständnisse
Während unserer Reise in die Softwaresicherheit haben wir die Entwicklung der Angriffstechniken und eine breite Palette von Ideen sicherheitsbewusster Menschen beobachtet. Organisationen verstehen oft nicht, was gegen diese Bedrohung funktioniert. Daher werden wir zunächst untersuchen, was nicht funktioniert. Dies ist in der folgenden, nicht erschöpfenden Liste von Missverständnissen zusammengefasst.
Missverständnis Nr. 1: SCA Tools melden bereits schädliche Komponenten
In der Tat! Aber im Nachhinein… Wenn es wahrscheinlich zu spät ist, wenn das Element in einem Software-Build verwendet wurde und die schlechten Akteure bereits in einem Entwickler- oder CI/CD Host. Geheimnisse könnten exfiltriert worden sein, zusätzliche Malware heruntergeladen und installiert worden sein, und vielleicht hat sich der Angreifer seitlich bewegt und bereits an anderer Stelle Zugriff erlangt.
Software Composition Analysis (SCA) Tools wurden entwickelt, um potenzielle bekannte Schwachstellen zu identifizieren. Moderne Tools leisten hervorragende Arbeit, indem sie das Signal-Rausch-Verhältnis verbessern und so feststellen, ob die Schwachstelle tatsächlich erreichbar oder ausnutzbar ist. Gegen neue Malware sind sie jedoch nutzlos. Stellen Sie sich eine bösartige Komponente als Zero-Day-Schwachstelle vor: Erst wenn ihr bösartiges Verhalten erkannt wird, wird die Komponente an das zuständige Register gemeldet, wo sie nach einer Überprüfung durch ein Sicherheitsteam als bösartig bestätigt und aus dem Register entfernt wird. [1]..
Zu diesem Zeitpunkt war die Welt (einschließlich SCAs) weiß, dass die Installation oder Verwendung der Komponente (oder einiger Versionen einer vorhandenen Komponente) nicht sinnvoll ist. Dies ist jedoch der Fall, wenn die Komponente nicht in der Registrierung verfügbar ist.. Zu wissen, dass ich Schwachstellen in Komponenten von Drittanbietern habe, oder sogar in Komponenten, die von der Registrierung als bösartig eingestuft wurden, ist gut, aber leider SCA oder herkömmliche Audit-Tools helfen in diesem Zusammenhang nicht weiter. Es sei denn, die SCA/Audit-Tool kann wirklich im Voraus wissen, dass eine Komponente bösartig ist, bevor sie in Ihrer Organisation verwendet wird.
Denken Sie daran, dass jede Lösung gegen bösartige Open-Source-Komponenten diese erkennen muss on-the-fly, zwischen der Veröffentlichung der Komponente in der Registrierung und der ersten Verwendung der Komponente (Version) in Ihrer Organisation. Und das schließt transitive Komponenten ein.
Missverständnis Nr. 2: Die Kontrolle von Installationsskripten zur Build-Zeit verhindert bösartiges Verhalten von Open-Source-Komponenten
Verschiedene Paketmanager bieten die Möglichkeit, Skripte auszuführen (die im Komponenten-Tarball enthalten sind). [2].), aus legitimen Gründen, wie etwa zum Kompilieren erforderlicher Elemente auf unterschiedlichen Plattformen, zum Generieren von Code oder zum Ausführen von Tests. Und wir sollten alle wissen, dass sie von böswilligen Akteuren missbraucht werden können, wenn das Tarball schädliche Skripts enthält oder wenn der Angreifer ein schädliches Skript anstelle des guten ausführen kann.
Wenn wir das wissen, können wir den Paketmanager so konfigurieren, dass er Skripte ignoriert. Mit NPM zum Beispiel –Ignore-Skripte Flag (oder eine Konfigurationseigenschaft im .npmrc Datei) überspringt die Skripte während der Installation. Dies kann zu Problemen führen, da das Ausführen von Skripten in vielen Ökosystemen üblich ist: Einige Paketmanager erlauben nicht einmal das Deaktivieren der Skriptausführung (Hinweis: Eingabeaufforderung „Welche Paketmanager erlauben es nicht, die Ausführung von Installationsskripten zu deaktivieren?” in Ihrer bevorzugten KI). Dies schützt jedoch nicht allgemein (wir müssen durchsetzen, dass die Konfiguration zum Deaktivieren des Überspringens überall vorhanden ist).
Und wenn das bösartige Verhalten nicht in den Installationsskripten, sondern in der zur Laufzeit auszuführenden Software liegt, schützt uns diese Option allein nicht.
Irrtum Nr. 3: Version Pinning verhindert die Installation bösartiger Komponenten
Es besteht ein Kompromiss zwischen frühem und häufigem Patchen mit offene Versionen (dadurch kann der Paketmanager automatisch neue Updates installieren, wenn diese für Sicherheitsfixes verfügbar sind) und Versionsfixierung (alle direkten und transitiven Abhängigkeiten für eine Software in einer festen Version). Die Sicherheitsprinzipien sind hartnäckig und manchmal widersprüchlich, wie es bei „Patch früh, Patch oft“ der Fall ist und „Ein Upgrade sollte nicht auf die leichte Schulter genommen werden“. Einige Paketmanager führen automatische Updates mit Serverbereichen als empfohlene Methode durch. Großartig, wenn Sie auch die bösartigen Updates erhalten möchten! Ja, Komponenten müssen aktualisiert werden, um Sicherheitsfixes zu erhalten, die Schwachstellen so schnell wie möglich schließen, aber … lassen Sie den Paketmanager dies niemals automatisch tun.
Irrtum Nr. 4: Die Verwendung vertrauenswürdiger Komponenten ist sicher. Jede bösartige Version würde umgehend gefunden, offengelegt und entfernt werden.
Warum wird einer Komponente vertraut? Möglicherweise, weil sie sehr beliebt ist, viele Augen auf der Suche nach Schwachstellen hat, eine große Anzahl an Mitwirkenden für die Wartung hat und mehrere Kern-Maintainer alle Komponenten sorgfältig überprüfen. pull requests. Die Realität sieht ganz anders aus. Einige wesentliche Komponenten werden von einem einzigen, unbezahlten Entwickler gepflegt. Weit verbreitete Frameworks haben einige regelmäßige Mitwirkende, mit einer rasch abnehmenden Zahl von commits pro Betreuer (populäre Projekte haben eine lange Reihe von Mitwirkenden, die einige Drive-by- commit und nie wieder zurückkommen). Und es gibt jede Menge populäre Projekte mit nur einem Betreuer.
Stellen Sie sich vor, Sie sagen „Oh, wir verwenden Spring Boot / Angular / React / PyTorch / offizielle Basis-Docker-Images, also ist das Risiko, von dem Sie sprechen, ziemlich gering.“ Vielleicht stimmt das, wir Sicherheitsanbieter verbreiten ständig Panik, und es ist Unsinn, sich in Entwicklungsteams einzumischen, um ein fragwürdiges Risiko zu mindern. Sie könnten versucht sein, gleich zum Absatz über die Risikoakzeptanz (im nächsten Abschnitt) zu springen und fertig. Leider sind die beliebtesten Komponenten Ziele für böswillige Akteure, und zum Beispiel die beliebten PyTorch-Bibliothek wurde angegriffen in der Vergangenheit.
„Umgehend gefunden, offengelegt und entfernt.“ Es dauert Tage, bis eine neue bösartige Komponente aus dem öffentlichen Register entfernt wird. Register sind beim Entfernen einer Komponentenversion vorsichtig, zum Guten. Unsere Erfahrung zeigt, dass die durchschnittliche Zeit, die das Register benötigt, um die betroffene Version zu entfernen, nach der Meldung von unserer Seite 39 Stunden beträgt, also mehr als anderthalb Tage. Es gibt bösartige Komponenten, die nach unserer ersten Meldung noch eine Woche im Register sind, bevor sie entfernt werden. Und in einigen Fällen wird die Komponente erst entfernt, nachdem ein Opfer oder ein Incident-Response-Unternehmen einen Vorfall mit der Komponente gemeldet hat.
Was gegen bösartige Komponenten NICHT hilft
Jeder unspezifische Ansatz wird kläglich scheitern. Das ist sicher, Sie treffen keine wirksamen Gegenmaßnahmen gegen das Risiko, das mit dieser Bedrohung verbunden ist.
Traditionell SCA Tools informieren Sie über bekannte Malware, haben aber ein großes Angriffsfenster. Sofern sie nicht proaktiv Malware erkennen und schädliche Komponenten blockieren, wirken sie nicht gegen diese Bedrohung.
Das Deaktivieren von Installationsskripten könnte hilfreich sein, muss aber überall erzwungen werden, wo eine Komponente installiert werden muss. Dasselbe gilt für die Versionsfixierung, da Versionen nicht für immer von einem sicheren Anfangszustand fixiert werden können.
Die Annahme, dass beliebte Komponenten genügend Aufmerksamkeit erhalten, sodass sie bei einem Supply-Chain-Angriff nicht mit unbeabsichtigtem Verhalten infizieren können, ohne dass eine nahezu sofortige Erkennung erfolgt, um Schäden zu verhindern, ist naiv und riskant. Sie möchten doch nicht am Rande des Abgrunds leben, oder?
Wenn Sie an dieser Stelle aufhören, dann Risikoakzeptanz ist das einzige, was Sie tun können: Dies ist ein decision, die in Ihrem Bedrohungsmodell/Ihrer Risikobewertung dokumentiert werden muss, einschließlich der Gründe für die Akzeptanz des Risikos und seiner potenziellen Auswirkungen. Sensibilisieren Sie das Management und andere relevante Parteien. Einige Kontingenz könnte geplant werden, wenn eine bösartige Komponente in Ihre Software installiert oder integriert wird, aber das ist schwierig, weil Angreifer viele Wege verfolgen können. Die Details eines Supply-Chain-Angriffs, der auf der Verwendung einer bösartigen Komponente basiert, werden die öffentliche Bekanntgabe des Vorfalls drastisch verändern, was wahrscheinlich im Rahmen der gesetzlichen Bestimmungen Ihres Unternehmens vorgeschrieben ist. Sie können auch Folgendes ansprechen: Kompensationskontrollen or Transferrisiko zB mit Versicherungen.
Es gibt jedoch Kontrollen, die der Bedrohung begegnen und die in Betracht gezogen werden sollten, wenn Sie mit der Risikoakzeptanz nicht zufrieden sind. Bitte lesen Sie weiter.
Was hilft gegen Angriffe mit bösartigen Komponenten
Solide Versionshandhabung
Versions-Pinning mit kontrollierten und informierten Versionssprüngen ist der richtige Weg, um die Notwendigkeit der Beseitigung von Schwachstellen ohne den Empfang von Malware auszugleichen. Aber denken Sie an Missverständnis Nr. 3: Versions-Pinning allein reicht nicht aus, um bösartigen Code aus neuen Versionen zu blockieren, da Sie in Zukunft Versionen in jeder direkten oder indirekten Abhängigkeit aktualisieren müssen. Zu diesem Zeitpunkt benötigen Sie ausreichend starke Beweise dafür, dass alle geänderten Versionen keine Malware enthalten.
Frühwarnung
Ein Ansatz zur Lösung des Problems bösartiger Komponenten ist ein Frühwarnsystem (hier genannt Frühwarnung vor Malware oder MEW), wobei neu veröffentlichte Versionen (für neue oder vorhandene Komponenten) von einer Erkennungs-Engine analysiert werden, die bei ausreichenden Beweisen die neue Version als potenziell bösartig einstufen kann.
Automatisierung ist hier unerlässlich, da es bei der aktuellen Veröffentlichungsrate unmöglich ist, alle neuen Komponenten manuell zu überprüfen. Daher muss die Erkennungs-Engine verschiedene Techniken kombinieren, darunter möglicherweise statische, dynamische und Fähigkeitsanalysen, Benutzerreputation und Beweise, die sich aus Diskrepanzen zwischen den Komponentenmetadaten und den Tarball-Inhalten oder zwischen Tarball und dem Quellrepository ergeben, aus dem die Komponente vermutlich stammt.
Da ist ein dunkle Zone zwischen dem Veröffentlichungszeitpunkt und dem Zeitpunkt, an dem die Engine den Komponenteninhalt analysiert, sollte jedoch einige Minuten nicht überschreiten. Das Schema kann geändert werden, beispielsweise indem man wartet, bis neue Komponenten analysiert wurden, bevor man sie installiert und im Software-Build verwendet. pipelines oder analysieren Sie sie bei Bedarf. Eine Komponente in einer bestimmten Version ist unveränderlich [3]., daher muss es nur einmal analysiert werden.
Eine vollständige Automatisierung ist nicht möglich und eine Sicherheitsüberprüfung auf potenziell schädliche Komponenten ist erforderlich. Vorsicht vor den Befürwortern digitaler Allheilmittel: KI und maschinelles Lernen sind noch nicht weit genug entwickelt, um das letzte Wort zu haben, wenn es darum geht, zu bestätigen, ob eine verdächtige Komponente Malware enthält. Sicher, maschinelles Lernen spielt eine Schlüsselrolle in der Erkennungs-Engine bei der Klassifizierung der Eingabekomponente anhand der erfassten Rohbeweise, aber sobald die Komponente „unter Quarantäne gestellt“ ist, liegt das letzte Wort bei der manuellen Überprüfung durch ein Sicherheitsteam mit Erfahrung mit bösartigen Komponenten. Dadurch wird jede potenzielle Malware bestätigt oder als sicher neu klassifiziert. Und der Zeitraum liegt im Stundenbereich.
Das Register meldet die bösartige Version/Komponente; das Register führt dann seine Überprüfung durch, um dies zu bestätigen, und fährt mit der öffentlichen Bekanntgabe und Entfernung aus dem Register fort. Einige Register führen ein Sicherheitspaket. Der Zeitbereich hier ist die Anzahl der Tage oder Wochen seit der Veröffentlichung, also die „Verweilzeit' oder 'Belichtungsfenster' für die meisten bösartigen Komponenten.
Ist es möglich, festzustellen, ob eine Komponentenversion bösartig ist?
Um eine Frühwarnung zu ermöglichen, müssen wir also eine zufriedenstellende Antwort auf diese Frage geben: Wie kann ich wissen, dass eine Bibliothek oder ein Paket (nicht) bösartig ist? Wie kann ich genügend Beweise für bösartiges Verhalten sammeln? Möglich, aber schwierig, da die Angreifer viel Einfallsreichtum an den Tag legen, um nicht entdeckt zu werden. Es gibt verschiedene Ansätze, jeder mit Vor- und Nachteilen.
Statische Analyse kann alle Ausführungspfade untersuchen, auf von Angreifern verwendete Techniken prüfen, ohne die Komponente auszuführen, und Vorverarbeitungsaufgaben wie Deobfuskation oder Entschlüsselung durchführen. Da Angreifer versuchen, ihr Unheil zu verbergen, sind Verschleierungsversuche tatsächlich ein Beweis für Malware (aber beachten Sie, dass legitime Komponenten Code verschleiern, um geistiges Eigentum zu schützen, was im Widerspruch zu „Open-Source-”). Nur wenige hochentwickelte Angriffe mit starker Verschleierung benötigen eine Sandbox, aber eine so starke Verschleierung ist ein verräterisches Zeichen für Böswilligkeit. Bitte beachten Sie, dass konventionelle SAST Die Tools wurden für unbeabsichtigte Schwachstellen entwickelt, nicht für böswillige Zwecke wie Hintertüren.
Dynamische Analyse führt die Komponente aus und untersucht die Antwort, indem die Laufzeit instrumentiert wird, normalerweise durch Bereitstellung einer Sandbox-Umgebung. Bösartiges Verhalten, das unter bestimmten Bedingungen ausgelöst wird, kann unentdeckt bleiben: Bitte beachten Sie, dass Malware Umgehungstechniken verwenden kann wie Virtualisierung/Sandbox-Umgehung nur aktiviert wird, wenn keine Beobachtung erfolgt, und außerdem ein verräterisches Zeichen böswilliger Aktivitäten für jede statische Analyse-Engine.
Fähigkeitenanalyse berücksichtigt, was die Komponente tut: Wohin sie sich verbindet, auf welche Dateien sie zugreift, welche Befehle oder Programme ausgeführt werden, welche Terminal- oder Geräte-E/A ausgeführt werden oder welche Systemaufrufe aufgerufen werden. Diese Verhaltensabdrücke könnten (für eine vorhandene Komponente) über verschiedene Versionen hinweg verglichen werden, sodass bei der Erkennung unerwarteten Verhaltens dieser Beweis den Verdacht auf potenziell bösartige Aktivitäten in der neuen Version wecken könnte. Dieser Ansatz folgt den Triage-Schritten, die Sicherheitsanalysten befolgen, wenn sie mit potenzieller Malware konfrontiert werden: eine Überprüfung mithilfe Streicher oder ähnliche Tools. Dieser Ansatz erkennt bösartiges Verhalten unabhängig von den auslösenden Bedingungen und funktioniert, wenn kein Quellcode verfügbar ist.
Kontextanalyse sammelt Informationen darüber, wie und von wem die Komponente veröffentlicht wurde. Kampagnen von böswilligen Akteuren verwenden häufig neue Benutzerkonten, die keinem strengen Prüfprozess unterliegen. Das Verfolgen früherer Aktivitäten kann Einblicke in den zugrunde liegenden Benutzer geben, vor allem bei Anomalien, die auf einen möglichen Kompromiss hindeuten könnten. Ein guter Ruf ist so schwer zu gewinnen und so leicht zu verlieren! Ein Benutzer ohne frühere Aktivitäten ist neutral, aber das Karma verfolgt die Übeltäter. Hacktivisten oder normale Benutzer, deren Veröffentlichungsdaten gestohlen wurden, sollten sorgfältig verfolgt werden.
Eine weitere Kontextinformation ist jede Diskrepanz zwischen dem Quellrepository, das angeblich zum Erstellen des Komponenten-Tarballs verwendet wurde, und dem Inhalt des Tarballs selbst. Und auch das Befolgen bewährter Praktiken, wie das Erstellen von Tags oder Releases im Quellrepository, die den Versionen der Komponente entsprechen, die im öffentlichen Register veröffentlicht wurden. Wenn das Quellrepository an einem bestimmten commit ist mit Release gekennzeichnet und dann folgt plötzlich eine Version nicht mehr diesem Hinweis, ist das allein schon ein starker Hinweis darauf, dass die Komponente manipuliert sein könnte: Der böswillige Akteur hat möglicherweise das Konto kompromittiert, das zum Veröffentlichen der Komponente verwendet wurde, hat aber keine Schreibberechtigung im Quellcode-Repository). Viele Angriffe werden routinemäßig mithilfe dieser Regeln erkannt: Beispielsweise die Ledger-Angriff könnten auf diese Weise leicht erkannt werden. Die Kontextanalyse identifiziert daher solche Anomalien im Veröffentlichungsprozess.
Abhängigkeits-Firewalling
Ein anderer Ansatz besteht darin, eine umfassende Whitelist von Komponenten für alle in Ihrer Software verwendeten Abhängigkeitsdiagramme zu haben, sodass in jedem Build pipeline in Ihrer Organisation laufen, können nur freigegebene Komponentenversionen installiert und verwendet werden. Die „Firewall” wird mithilfe eines internen Registers erzwungen, in dem die Tarballs für die zulässigen Komponentenversionen bereitgestellt werden (zwischengespeichert oder über Proxy). Bitte beachten Sie, dass eine Whitelist nur funktioniert, wenn Sie über die Technologie verfügen, um jede neue Version als einigermaßen sicher einzustufen, sodass sie zur Whitelist hinzugefügt werden kann.
Bitte beachten Sie, dass eine frühzeitige Warnung (schnelle Erkennung so bald wie möglich nach der Veröffentlichung der neuen Version) mit einer Möglichkeit kombiniert werden muss, diese Informationen proaktiv zu nutzen, um die Komponente zu blockieren, die den Build beeinflusst. pipelines oder die Maschinen der Entwickler [4].. Wir nennen das „Abhängigkeits-Firewall”: ein Quarantänemechanismus zum Schutz automatisierter Builds vor bösartigen Paketen. Interne Pakete und Image-Registrierungen sind gut, um Organisationen vor äußerem Übel zu schützen, aber es sind ausreichend starke Beweise erforderlich, um eine Quarantäne wirksam zu machen.
Laufzeit-Sandboxing
Ein alternativer Ansatz zur Erkennung zum Veröffentlichungszeitpunkt ist die Analyse des Verhaltens zur Laufzeit. Die Idee besteht darin, das erwartete Verhalten der Software zu erfassen und alle gefundenen Anomalien zu erkennen (oder zu blockieren). Bei dieser Vorgehensweise besteht das Problem, dass die Laufzeit zur Überwachung oder Blockierung instrumentiert werden muss. Es handelt sich um eine vielversprechende Idee, die das Arsenal an Schutzmechanismen gegen die Plage der bösartigen Komponenten ergänzen wird.
Festlegung einer umfassenden Strategie
Die empfohlene Strategie muss verschiedene Techniken im Softwareentwicklungsprozess kombinieren und die Kontrolle über die Versionsaktualisierungen übernehmen, um eingehende bösartige Komponenten zu blockieren. Wir müssen Versions-Pinning ermöglichen, um eine automatische Infektion durch aktualisierte Versionen zu vermeiden, um Korrekturen für die wichtigen Schwachstellen zu erhalten. Eine schnelle und effiziente Bewertung direkter und indirekter Abhängigkeiten während Versionsaktualisierungen, um genügend Beweise dafür zu haben, dass sie nicht von Malware befallen sind. Software-Builds, die von bekannten bösartigen Komponenten abhängen, müssen blockiert werden. Und alle müssen erzwungen werden.
Verwenden Sie nach Möglichkeit die Versionsfixierung, da dadurch Builds reproduzierbarer werden. Versions-Pinning mit kontrollierten, manuell freigegebenen Versions-Bumpsund unterstützt durch Hilfstechnologie, sollte beurteilen, ob das Update Malware mit sich bringt oder die Software beschädigt, und Updates zum Beheben von Schwachstellen mit der Vermeidung von Malware-Infektionen in Einklang bringen. Tools können hier helfen, indem sie (1) priorisieren, welche Schwachstellen wirklich wichtig sind (erreichbar und ausnutzbar, mit hohem Risiko, von Angreifern angegriffen zu werden), (2) Zielversionen auswählen, die mit der aktuellen Komponentenverwendung kompatibel sind und die Software nicht beschädigen, (3) Zielversionen wählen, die kein bösartiges Verhalten aufweisen, und (4) das Versionsupdate für direkte und indirekte Abhängigkeiten zum Kinderspiel machen, indem Änderungen in den Manifestdateien vorgeschlagen werden, die schnell genehmigt werden können. Für Schritt (3) sind spezifische Informationen über bösartige Komponenten so zeitnah wie möglich an ihrem Veröffentlichungszeitpunkt erforderlich.
Dieser Prozess der Aktualisierung von Abhängigkeiten muss erzwungen und verified an allen Orten. Der Prozess muss dokumentiert werden, und alle Beteiligten sollten geschult werden, da die Entwicklung und der Software-Build/-Deployment oft extern vergeben werden. Die CI/CD pipelines sollten entsprechend geändert werden, damit durch Automatisierung keine böswillige indirekte Abhängigkeit in den Build eindringt: guardrails Die empfohlene Vorgehensweise besteht darin, den Build zu blockieren, wenn genügend Hinweise auf potenzielle Schadsoftware in einer Abhängigkeit vorliegen.
Wenn Ihre Organisation über ein internes Register verfügt, das als Sicherheitsproxy für die Speicherung der zulässigen Komponentenversionen fungiert, müssen Sie (neben anderen Kriterien) Informationen zu bösartigen Komponenten einholen, um eine angeforderte Komponente zu überprüfen, bevor Sie sie zur Zulassungsliste hinzufügen.
Es ist nicht einfach, Open-Source-Software sicher zu nutzen. Der Malware-Faktor muss vollständig berücksichtigt werden, und der Umgang mit Sicherheitslücken muss mit ähnlichem Aufwand erfolgen.
Ein letzter Hinweis: Quellenherkunft, in Form von Software-Bescheinigungen, die zum Zeitpunkt des Erstellens der Komponente generiert werden, ist ein weiteres Schlüsselelement bei der Verfolgung des Artefakts (Komponenten-Tarball) mit den Quellen und dem Erstellungsprozess, der es erzeugt hat. Beachten Sie, dass diese Verknüpfung zwischen dem Quell-Snapshot + der Build-Umgebung und dem zugehörigen Software-Artefakt (signiert vom vertrauenswürdigen Build-System) nicht per se verhindert, dass die Komponente kein bösartiges Verhalten enthält, es den Bösewichten jedoch erschwert, Malware einzuschleusen. Und die Validierung der Herkunft zu einer allgemeinen Anforderung für die Nutzung von Open-Source-Komponenten zu machen, wird lange dauern und nur kürzlich zu NPM hinzugefügt. Diese vertrauenswürdigen Build- und Deployment-Systeme manipulationssicher zu machen oder die Erkennung jeglicher Manipulationen im Build zu ermöglichen, ist eine andere Geschichte und liegt außerhalb des Rahmens dieses Beitrags.
Weiterführende Literatur
Die nächste Folge Schädliche Open-Source-Pakete: Der Xygeni-Ansatz präsentieren wir die Strategie, die wir bei Xygeni verfolgen für unsere Frühwarnung vor Malware (MEW)-System. Neue Paketversionen in den öffentlichen Paket- und Image-Registern werden gescannt und Beweise mithilfe einer Kombination aus statischer, dynamischer, leistungsfähiger und kontextbezogener Analyse gesammelt. Die Beweise, kombiniert mit der Benutzerreputation und dem Änderungsverlauf in Quellcode-Repositories, ermöglichen eine vollautomatische Klassifizierung einer Komponente in Kategorien mit hohem Risiko und wahrscheinlich bösartig. Das System lernt aus früheren Beweisen, die aus Paketen gesammelt wurden, um die Anzahl falscher Positivmeldungen auf ein Minimum zu reduzieren.
Abonnierte Organisationen erhalten eine Warnmeldung für Komponenten, die sie direkt oder indirekt verwenden, wenn eine bösartige Version kategorisiert wird. Anschließend führen unsere Analysten eine manuelle Analyse durch, die die Klassifizierung bestätigt oder ablehnt. Bei bestätigter Malware wird das öffentliche Register benachrichtigt, damit es eine eigene Analyse durchführen und in der Regel die bösartige Version entfernen oder zusätzliche Maßnahmen ergreifen kann, z. B. das Blockieren oder Entfernen des betreffenden Benutzerkontos.
Wir erklären, wie wir NPM, PyPI, GitHub und anderen wichtigen Infrastrukturen im Open-Source-Ökosystem helfen, die Verweildauer einer neuen veröffentlichten Schadkomponente zu verkürzen, bis sie als Malware bestätigt und aus dem Register entfernt wird. Und wie Organisationen vom MEW-System profitieren können, um einen viel besseren Schutz gegen Angriffe auf die Software-Lieferkette mit Open-Source-Komponenten zu haben.
- [1]. Auf jeden Fall müssen Benutzer der Komponente prüfen, ob das Komponenten-Tarball irgendwo zwischengespeichert oder registriert ist, beispielsweise in einem internen Register, damit das Problem behoben wird.
- [2]. Die gepackte Komponente enthält ein Manifest, das ihren Inhalt und ihre Metadaten, Quell- oder kompilierten Code, Installationsskripte und zusätzliche Elemente wie Testsuiten gemäß einem Verpackungsformat und normalerweise in komprimierter Form deklariert. Dies wird als „Komponenten-Tarball“ bezeichnet.
- [3]. Selbst wenn der böswillige Akteur eine veröffentlichte Komponente aufgrund einer Sicherheitslücke in der Registrierung selbst ändern kann, kann ein herkömmlicher kryptografischer Digest nach Abschluss der Analyse jede Änderung im Tarball erkennen.
- [4]. Denken Sie daran, dass einige bösartige Komponenten während der Installation ausgeführt werden. Daher können Entwicklerknoten betroffen sein, die unbeabsichtigt „npm install X“ mit X, einer bösartigen Komponente, ausführen.
