Was Frontend-Entwickler über SBOMs in JavaScript wissen müssen

Die wichtigsten Erkenntnisse

• JavaScript-Anwendungen enthalten oft Hunderte von versteckten Abhängigkeiten, sowohl direkte als auch transitive.
• SBOMs geben Ihnen einen vollständigen Einblick in Ihre Codebasis, decken Schwachstellen auf und sorgen für Transparenz.
• Tools wie Syft und CycloneDX machen die SBOM-Generierung einfach und helfen Ihnen, die Sicherheit zu erhöhen und die Compliance einzuhalten.

Ihre JavaScript-Anwendung ist eine Blackbox voller Abhängigkeiten. Wenn Sie node_modules öffnen, finden Sie vielleicht tausend Pakete, von denen Sie gar nicht wussten, dass Sie sie haben, und einige davon sind so kryptisch wie UFOs auf dem Radarschirm. In einer Zeit eskalierender Angriffe auf die Lieferkette ist das nicht nur gruselig, sondern auch gefährlich.

Hier kommen die SBOMs (Software Bill of Materials) ins Spiel: Ihre Sternenkarte für die Navigation durch die Galaxie der JavaScript-Abhängigkeiten. In diesem Beitrag erfahren Sie, was SBOMs sind, warum Frontend-Entwickler sie nicht ignorieren können und wie Sie mit Tools wie CycloneDX und Syft Ihr Ökosystem abbilden, die Sicherheit in Ihren Arbeitsablauf integrieren und Schwachstellen aufspüren können, bevor sie zum Absturz kommen.

Unheimliche Begegnungen der JavaScript-Art

Wenn wir Software als Ganzes betrachten, haben wir verschiedene Teile, die das Ganze zusammenhalten. Es gibt Pakete, Lizenzen, Menschen, Prozesse usw., die wie ein Puzzleteil zusammenpassen...die meiste Zeit über.

Software-Abhängigkeiten können sich so seltsam anfühlen wie ein UFO (Unidentified Flying Object) oder ein UAP (Unidentified Aerial Phenomena): manchmal erklärbar, oft verwirrend und immer mit der Möglichkeit einer überraschenden Begegnung.

Es könnte Ausreißer in Ihrem Code geben, von denen Sie vielleicht wissen, dass es sie gibt, und dann könnte Ihre Software im Handumdrehen gefährdet sein. An dieser Stelle kommen SBOMs ins Spiel.

Man kann sich das in etwa so vorstellen: Man installiert ein Paket, dieses Paket installiert ein anderes Paket, und dann werden das Mutterschiff und ALLE seine Kindschiffe zerstört.

Dieser Film bringt es auf den Punkt!

Wie viele Abhängigkeiten gibt es in Ihrer Anwendung?

Raten Sie einfach mal: Hat Ihre Anwendung 20 Abhängigkeiten? 200? Oder die einer kleinen Galaxie - eher tausend?

Wenn Sie npm ls in Ihrem Terminal ausführen, erhalten Sie eine Liste der Abhängigkeiten.

Warum nicht ALLE Abhängigkeiten auflisten? Wir können, es könnte das Terminal überlasten, da Abhängigkeitsstrukturen sehr groß sein können, aber es ist möglich.

Die Auflistung von Abhängigkeiten auf diese Weise zeigt nicht nur die direkten Abhängigkeiten, sondern auch die transitiven Abhängigkeiten.

Zwei Formen der Abhängigkeit

Wenn wir uns die Abhängigkeiten in unserem Projekt ansehen, haben wir es mit zwei Arten zu tun: Die eine ist eine direkte Abhängigkeit. Die eine können Sie sehen, wenn Sie Ihre package.json-Datei öffnen, den direkten Abhängigkeitsbaum.

Next ist zum Beispiel eine direkte Abhängigkeit, weil man es braucht, um eine Next-App zu erstellen.

JSON

"dependencies": {

"react": "^19.0.0",

"react-dom": "^19.0.0",

"next": "15.3.4"

}

Dann gibt es transitive Abhängigkeiten. Dies sind Abhängigkeiten von Abhängigkeiten, die Sie nur mit viel Mühe finden können. Normalerweise in einer package.json-Datei im Ordner node_modules eines Paketordners.

In diesem Beispiel ist @next/env eine transitive Abhängigkeit von next.

JSON

"dependencies": {

"@next/env": "15.3.4"

}

Was ist ein SBOM?

Ein SBOM ist im Grunde das Manifest Ihres Projekts - ein maschinenlesbares Inventar, in dem alle Komponenten, Abhängigkeiten und Beziehungen aufgeführt sind. Betrachten Sie es als die Zutatenliste für Ihre Codebasis oder als das Flugmanifest, das genau angibt, wer an Bord ist. Ein SBOM listet alle Abhängigkeiten und Versionen innerhalb eines Projekts auf.

Nachfolgend ein Auszug von Tahir Balarabe auf Medium. Diese Erklärung bringt es perfekt auf den Punkt.

"Eine SBOM (Software Bill of Materials) ist eine detaillierte, maschinenlesbare Liste aller Komponenten einer Software, einschließlich Abhängigkeiten, Metadaten und Beziehungen zwischen den Komponenten.

• https://medium.com/@tahirbalarabe2/why-every-modern-software-needs-a-software-bill-of-materials-sbom-for-security-04a4fec312c8

Sie fragen sich vielleicht: "Warum brauchen wir eine SBOM?" Es gibt viele Gründe, warum wir eine SBOM oder SBOMs brauchen, wenn wir Software produzieren oder nutzen. Einer davon ist Transparenz. Wir sollten wissen, was in unserem Produkt enthalten ist. Die Auslieferung eines Produkts oder das Anbieten eines unsicheren Produkts nützt niemandem; es wird letztendlich zu Problemen führen.

Transparenz in Bezug auf Ihre Abhängigkeitsstruktur trägt zur Sicherheit und zur Einhaltung von Vorschriften bei, was ebenfalls zwei sehr wichtige Gründe sind. Zu wissen, was in Ihrem Produkt enthalten ist, ist eine Sache, aber sicher und konform zu sein, ist eine andere.

Arten von SBOMs

Wenn wir über verschiedene SBOMs für unsere Software sprechen oder diese entwickeln, gibt es 6 verschiedene Typen. Alle diese Typen lassen sich auf verschiedene Teile des SLDC (Software Development Lifecycle) herunterbrechen.

• Entwurf SBOM
• Quelle SBOM
• SBOM erstellen
• Analysierte SBOM
• Eingesetztes SBOM
• Laufzeit SBOM

Weitere Informationen zu den Definitionen dieser SBOMs finden Sie im PDF-Dokument Types of Software Bill of Materials (SBOM) von der CISA (Cybersecurity & Infrastructure Security Agency).

Bei der Erörterung von SBOMs ist zu beachten, dass es sich nicht um eine Paketdatei oder eine Lock-Datei handelt - sie ist umfassender. Eine SBOM bietet auch eine vollständige, standardisierte Liste aller Dinge innerhalb Ihres Projekts: Komponenten, Metadaten usw.

Großes Frontend-Problem

Wenn Sie dies lesen und irgendetwas auf dem Frontend mit npm installiert haben, sind Sie höchstwahrscheinlich auf das Problem des Tippens aus dem Muskelgedächtnis gestoßen, weil Sie es schon 100x zuvor getan haben. Manchmal sind Sie vielleicht nicht aufmerksam und installieren einfach das, was Sie glauben zu brauchen. Möglicherweise kopieren Sie nicht einmal direkt von der Herstellerseite oder der npm-Registry und fügen es ein. Das bringt eine Menge Probleme mit sich; wir sprechen hier von Typosquatting.

Typosquatting ist auch als URL-Hijacking bekannt. Dabei handelt es sich um eine Angriffsart, bei der ein Angreifer eine oder mehrere Domänen mit leicht abweichenden Schreibfehlern registriert, um Benutzer dazu zu verleiten, seine Website zu besuchen, was oft bösartig ist. Dies gilt auch für die Paketverwaltung. Angreifer veröffentlichen auch bösartige Pakete und schreiben sie falsch, genau wie die Domänen. Ein Entwickler könnte versehentlich einen Tippfehler machen und ein bösartiges Paket anstelle des richtigen installieren.

Ein Beispiel hierfür ist die folgende Abbildung:

npm install express vs. npm install expres

Sie können sehen, dass die zweite Version die falsche Version von express ist und möglicherweise schädlich sein könnte.

Warum sind SBOMs wichtig?

Es gibt einige Gründe, warum eine SBOM äußerst wichtig ist:

• Sichtbarkeit der Komponenten
• Schwachstellen-Management
• Sicherheit der Lieferkette
• Zusammenarbeit und Patch-Management
• Einhaltung von Vorschriften

Die Einsicht in unsere Komponenten ist von entscheidender Bedeutung, insbesondere wenn es um transitive Abhängigkeiten geht. Wir wollen auch in der Lage sein, unsere Schwachstellen auf der Grundlage der von uns installierten Software zu verwalten. Und vergessen Sie nicht den menschlichen Faktor: Die gemeinsame Nutzung von SBOMs schafft Vertrauen beim Kunden und beweist, dass Ihre Software-Lieferkette transparent und sicher ist.

Wenn wir als Web- und Softwareexperten Software entwickeln, die von anderen genutzt werden soll, wollen wir sicherstellen, dass wir eine solide Beziehung zu unseren Kunden haben. Es ist von entscheidender Bedeutung, dass SBOMs für unsere Kunden verfügbar sind.

Installieren eines Werkzeugs zur Erzeugung einer SBOM

Es gibt verschiedene Möglichkeiten, wie Sie verschiedene Tools installieren können, um eine SBOM zu erstellen. In diesem Beitrag werden wir Syft von Anchore verwenden. Im Folgenden finden Sie einige Befehle zur Installation von Syft auf Ihrem Rechner.

Die empfohlene Methode ist die Verwendung von Curl:

curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin

Sie können das Paket auch mit Brew installieren:

brew install syft

Es gibt auch eine Version für Windows, die über Chocolatey installiert werden kann:

choco install syft -y

Microsoft bietet auch ein Tool zur Erstellung von SBOMs mit Winget an:

winget install Microsoft.SbomTool

Sobald wir Syft installiert haben, können wir mit der Erstellung einer SBOM in unserem Projekt fortfahren.

SBOM-Erzeugung

Es gibt zwei gängige Formate für die Erstellung von SBOMs: SPDX und CycloneDX. In den folgenden Beispielen verwenden wir SPDX, um unsere SBOM zu formatieren. Wir generieren auch eine SBOM in einem Angular-Projekt, speziell v19.

Sobald Sie in Ihrem Projekt sind, führen Sie den folgenden Befehl aus, um die SBOM zu erzeugen. Sie ist maschinenlesbar, aber das werden wir mit dem zweiten Befehl beheben, den wir ausführen werden. Sie werden sehen, dass am Ende des Befehls zwei Flags stehen, -source-name und -source-version. Wenn Sie diese nicht in den Befehl einfügen, wird das Terminal Sie anschreien. Es ist einfach die beste Praxis, sie mit anzugeben.

syft packages dir:. -o json > sbom.json --source-name "my-js-project" --source-version "1.0"

Um nun eine Version der SBOM zu erzeugen, die von einem Menschen gelesen werden kann. Sie können einen Befehl namens jq ausführen, um die SBOM hübsch auszudrucken, so dass Sie durchgehen und sich ansehen können, was erstellt wurde.

jq . sbom.json > sbom-pretty.json

Wenn Sie neue Pakete installieren, ist es eine gute Praxis, eine neue SBOM zu erstellen, damit das installierte Paket dokumentiert werden kann. Im Folgenden finden Sie ein Video zur Installation des Lucide-Pakets für Angular und zur manuellen Neugenerierung der SBOM, um das neue Paket zu sehen.

Dies kann auch mit einer GitHub-Aktion geschehen. Wenn Sie einen Push in den Main-, Dev- oder Release-Zweig durchführen, wird ein Workflow ausgelöst, der ein neues SBOM-Artefakt im JSON-Format erzeugt, das in GitHub gespeichert wird. Sie können selbst entscheiden, was Sie mit dieser Datei tun möchten.

Abschließende Überlegungen

Ein SBOM ist nicht mehr optional - es ist ein wichtiger Bestandteil der modernen Softwareentwicklung. Es zeigt nicht nur an, was installiert ist, sondern gibt Ihnen eine lebendige Karte der direkten und transitiven Abhängigkeiten. Sie hilft auch bei der Verwaltung von Schwachstellen und der Einhaltung von Vorschriften.

Transparenz ist von größter Bedeutung, und für viele Unternehmen ist eine SBOM eine Möglichkeit, ihr Engagement für Transparenz zu demonstrieren. Im Rahmen des Endless Lifecycle Support (ELS) für Anwendungen stellt TuxCare seinen Anwendern beispielsweise automatisch eine SBOM zur Verfügung - mit umfassenden Details darüber, wie jedes Paket erstellt, verifiziert und verteilt wird. Auf diese Weise ermöglicht TuxCare Entwicklern, die das erweiterte Patching für auslaufende Open-Source-Softwareprodukte nutzen, Transparenz und Verantwortlichkeit in ihren Software-Ökosystemen zu gewährleisten.

Wenn Sie also das nächste Mal Ihr Projekt öffnen, erstellen Sie ein SBOM, lassen Sie es durch einen Schwachstellen-Scanner laufen und sehen Sie genau, welche Pakete bekannte Schwachstellen beherbergen könnten. Das ist eine der einfachsten und intelligentesten Möglichkeiten, die Sicherheit Ihres Frontends zu erhöhen.