Was verbirgt sich in Ihrem Code?

Sogar einfache Projekte neigen dazu, schnell in die Höhe zu treiben, und diese Tendenz wird durch die einfache Integration vorhandener Codeteile oder Knotenbibliotheken noch verstärkt.

Wenn Sie der Einzige sind, der diesen Code schreibt, ist es immer noch einigermaßen zu bewältigen, aber es wird schwieriger, wenn der Code von mehreren Entwicklern und Teams geschrieben wird, wie es normalerweise der Fall ist.

Selbst der Teamleiter, der für die Genehmigung aller Pull-Anfragen verantwortlich ist, kann nicht jede Codezeile, jede Funktion und jede Variable kennen.

Eine Frage des Vertrauens

Das ist einer der Gründe für die geringfügige Codeänderung, die Ende 2020 in der Orion-App stattfand, im späteren Fall bekannt als Sonnenwinde, blieb so lange unentdeckt. Die gesamte Änderung umfasste nur ein paar Dutzend Zeilen Code, und sie waren sehr gut in der ursprünglichen Klasse verborgen.

Das geänderte Produkt war ordnungsgemäß signiert, sodass kein Grund zur Vermutung bestand, und die Entwicklungsteams vertrauten dem Eigentümer des Codes.

Erst kürzlich haben wir erfahren, dass NPM eine „logischer Fehler” Dies ermöglichte es böswilligen Akteuren, betrügerische Bibliotheken als legitim auszugeben. Grundsätzlich erlaubte NPM, jeden als Betreuer eines Pakets hinzuzufügen, ohne diese Benutzer zu benachrichtigen oder ihre Zustimmung einzuholen. 

Dies ermöglichte die Erstellung von mit Malware infizierten Paketen und deren Zuweisung an vertrauenswürdige, beliebte Betreuer ohne deren Wissen. Ein Fall von fehlgeleitetem Vertrauen könnte auf eine problematische Sicherheitslücke in Ihrem Code hinweisen.

Eine weitere gängige Praxis, die es zu berücksichtigen gilt, besteht darin, dass Entwickler Code aus vorhandenen Bibliotheken oder StackOverFlow kopieren und einfügen, um ihn in ihrem eigenen Code zu verwenden oder ihn erneut in neue Bibliotheken hochzuladen. Dies erhöht die Wahrscheinlichkeit, dass auch unsicherer und anfälliger Code kopiert wird, der nun praktisch nicht mehr verfolgt wird. Selbst wenn der ursprüngliche Code eine CVE erhält und schließlich korrigiert wird, ist die problematische Funktion, die Sie kopiert haben, unsichtbar und könnte jede Codebasis kontaminieren, die sie über Jahre hinweg verwenden würde. 

In einer aktuellen Studie der University of Kansas („Was zum Teufel? Suche nach versteckten Code-Klonen in npm„) veranschaulichen die Forscher, wie unsicher die Verwendung selbst vollständig geprüfter Verpackungen sein kann.

Was können Sie dagegen tun?

Daher können Sie den signierten Produkten und Updates der Anbieter nicht vertrauen. Möglicherweise wurde Ihr eigener Code aufgrund der vielen darin integrierten externen Bibliotheken und Codes bereits geändert oder ergänzt. Was können Sie dann tun, um wirklich sicherzustellen, dass Sie keine schädlichen Dateien auf Ihrem System installieren?

Es gibt ein paar Dinge, die Sie tun können:

1. Fordern Sie von jedem Bibliothekseigentümer oder Programmanbieter, den Sie einbeziehen, eine vollständige SBOM an. Mithilfe einer SBOM können Sie sicherstellen, dass alle „Zutaten“ in der Bibliothek oder im Produkt enthalten sind. Wenn Sie außerdem etwas in der Bibliothek oder im Produkt finden, das nicht in der SBOM aufgeführt ist, sollten Sie es als verdächtig betrachten. Erfahren Sie mehr darüber, was eine SBOM ist HIER.
2. Fordern Sie vom Anbieter oder Bibliothekseigentümer eine vertrauenswürdige Bescheinigung an, dass eine Integritätsprüfung durchgeführt wurde und Sie das erhalten, was Sie erwarten. Sie sollten nicht nur der Zusicherung des Anbieters vertrauen müssen.
   
3. Verwenden Sie bei der Installation von Paketen das npm-CLI-Flag --ignore-scripts um zu vermeiden, dass während der Installationsphase Skripte von Drittanbieterpaketen ausgeführt werden.
4. Verwenden Paket-lock.json Datei zum Sperren von Paketversionsnummern. Wenn Sie a verwenden Paket-lock.json Sie sperren nicht nur die von Ihnen verwendeten Paketversionen, sondern auch deren Abhängigkeiten. Das Risiko besteht darin, dass Sie keine automatischen Paketaktualisierungen einspielen, die möglicherweise Korrekturen für verschiedene Fehler enthalten. Wenn Sie sich jedoch die Mühe gemacht haben, eine bestimmte Version zu verifizieren, und nichts anderes hinzufügen möchten, ohne es vorher zu verifizieren, ist das Sperren Ihrer Versionsnummern die beste Option.

folgende neue VorschriftenEs wird erwartet, dass die meisten Menschen in naher Zukunft mit der Verwendung von SBOMs beginnen werden. Je mehr Unternehmen SBOMs und andere Bescheinigungen verlangen, desto mehr Organisationen und Betreuer müssen sich daran halten.