Abhängigkeiten
Was ist ein Abhängigkeitsgraph?
Ein Abhängigkeitsgraph bildet jedes Paket ab, von dem Ihre Software abhängt, und zeigt, welches Paket es mitgebracht hat. Eine Liste sagt Ihnen, was in Ihrer Software steckt. Der Graph sagt Ihnen, warum es dort ist und was es sonst noch berührt, und genau das fragen Sie sich, wenn eine Schwachstelle bekannt wird.
Aktualisiert am
Knoten, Kanten und Pfade
In einem Abhängigkeitsgraphen ist jedes Paket ein Knoten, und jedes „hängt ab von“ ist eine Kante von einem Paket zum anderen. Ihr Projekt steht ganz oben. Seine direkten Abhängigkeiten sind eine Kante entfernt, und seine transitiven Abhängigkeiten sind alles, was weiter unten liegt. Der Weg von Ihrem Projekt zu einem Paket ist dessen Abhängigkeitspfad, und ein Paket kann mehrere haben.
Graph, Baum oder Liste
Dieselben Abhängigkeiten lassen sich auf drei Arten darstellen, und jede beantwortet eine andere Frage.
| Ansicht | Was sie zeigt | Was verloren geht |
|---|---|---|
| Flache Liste | Jedes Paket einmal, mit seiner Version | Warum jedes Paket vorhanden ist |
| Baum | Jeden Pfad ab Ihrem Projekt, so wie Paketmanager ihn ausgeben | Gemeinsame Pakete wiederholen sich, der Baum wirkt also größer, als er ist |
| Graph | Jedes Paket einmal, mit einer Kante von jedem übergeordneten Paket | Ohne Viewer schwerer mit bloßem Auge zu lesen |
Gemeinsame Pakete sind der Grund, warum Graphen wichtig sind. Wenn zwei Ihrer Abhängigkeiten dasselbe Paket brauchen, entsteht eine Raute: ein Knoten mit zwei übergeordneten Paketen. Um darin eine Schwachstelle zu beheben, müssen Sie beide Pfade kennen, denn jedes der beiden übergeordneten Pakete kann die alte Version pinnen.
Wofür Sie einen Abhängigkeitsgraphen nutzen
- Den Fix-Pfad finden. Ein verwundbares transitives Paket beheben Sie, indem Sie etwas auf seinem Pfad aktualisieren oder überschreiben. Der Graph zeigt, welche direkte Abhängigkeit Sie ändern müssen.
- Den Schadensradius messen. Wenn ein Advisory erscheint, zeigt der Graph, welche Ihrer direkten Abhängigkeiten, Dienste und Produkte zum betroffenen Paket führen.
- Lizenzen prüfen. Eine Copyleft-Lizenz tief im Graphen gilt genauso wie eine ganz oben, und der Pfad zeigt, welche Abhängigkeit sie hereingebracht hat.
- Upgrades planen. Ein Major-Upgrade eines Pakets verändert alles darunter. Der Graph zeigt, wie viel von Ihrem Baum sich ändert.
- Risikokonzentration erkennen. Ein kleines, nicht gepflegtes Paket, durch das viele Pfade führen, ist ein Single Point of Failure.
So erhalten Sie einen Abhängigkeitsgraphen
Vom Paketmanager. Jeder Paketmanager gibt den aufgelösten Baum aus, und die meisten können erklären, warum ein einzelnes Paket vorhanden ist. Transitive Abhängigkeiten listet die Befehle für npm, pnpm, Python, Go, Rust, Maven und Gradle auf.
Von GitHub. Der Abhängigkeitsgraph im Tab Insights eines Repositorys ist eine Zusammenfassung der Manifeste und Lockfiles im Repository sowie der über die Dependency Submission API eingereichten Abhängigkeiten. Bei unterstützten Ökosystemen zeigt GitHub den transitiven Pfad, über den jede Abhängigkeit hineingekommen ist, und kann den Graphen als SBOM exportieren.
Aus einer SBOM. CycloneDX hält den Graphen in einem dependencies-Abschnitt fest, in dem jede Komponente auflistet, wovon sie abhängt. SPDX nutzt DEPENDS_ON-Beziehungen zwischen Paketen. Ein CycloneDX-Graph für einen Teil einer Express-App sieht so aus:
"dependencies": [
{ "ref": "my-app", "dependsOn": ["express"] },
{ "ref": "express", "dependsOn": ["body-parser", "send"] },
{ "ref": "body-parser", "dependsOn": ["raw-body", "debug"] },
{ "ref": "send", "dependsOn": ["mime-types", "debug"] }
] Hier erscheint debug unter zwei übergeordneten Paketen: eine Raute. Viele SBOMs lassen die Beziehungen weg und listen nur Komponenten auf. Das Inventar bleibt erhalten, aber jeder Pfad geht verloren.
Ein Graph ist nur so gut wie seine Quelle
Die meisten Abhängigkeitsgraphen entstehen aus Manifesten und Lockfiles und zeigen daher den Baum, den der Paketmanager geplant hat. Sie zeigen weder Pakete, die aus CI-Caches wiederhergestellt wurden, noch Build-Tools, die Setup-Schritte installiert haben, noch Code, den Install-Skripte und Downloads geladen haben, und sie können nicht erkennen, ob der Build genau das Lockfile installiert hat. Siehe warum ein Lockfile keine Aufzeichnung des Ausgelieferten ist.
Abhängigkeitsgraphen in CRACI
CRACI baut seinen Graphen aus dem Build selbst. Es ist ein GitHub-Actions-Runner, der jedes Paket, das ein Job lädt, auf jeder Ebene des Baums und einschließlich der aus CI-Caches wiederhergestellten Pakete, in einer SBOM aufzeichnet, die ihre eigene Vollständigkeit ausweist.
- Eine Graph-Ansicht der SBOM. Die Abhängigkeitsansicht zeigt die Abhängigkeitsebenen der SBOM in den Ansichten Pivot, Graph, Blob, Chord und Sunburst, mit Filtern für Tiefe und Schweregrad.
- Exporte mit dem ganzen Baum. CycloneDX- und SPDX-Exporte enthalten transitive Abhängigkeiten, jede mit ihrer deklarierten Lizenz.
- Betroffene Builds im Zeitverlauf. Wenn eine neue Schwachstelle bekannt wird, zeigt die Build-Historie, welche früheren Builds das verwundbare Paket enthielten, direkt oder transitiv.
Siehe SBOM-Generierung in CRACI, oder buchen Sie eine Demo, um den Graphen eines Ihrer eigenen Builds zu erkunden.
Abhängigkeitsgraphen: häufig gestellte Fragen
Was ist ein Abhängigkeitsgraph?
Ein Abhängigkeitsgraph ist eine Karte aller Pakete, von denen Ihre Software abhängt, mit einem Pfeil von jedem Paket zu den Paketen, die es braucht. Er zeigt nicht nur, was in Ihrer Software steckt, sondern auch warum: den Pfad von Ihrem Code zu jeder transitiven Abhängigkeit.
Was ist der Unterschied zwischen einem Abhängigkeitsbaum und einem Abhängigkeitsgraphen?
Ein Baum zeigt jeden Pfad einzeln, sodass ein Paket, das zwei übergeordnete Pakete brauchen, zweimal erscheint. Ein Graph zeigt jedes Paket einmal, mit einer Kante von jedem übergeordneten Paket, das es braucht. Paketmanager geben Bäume aus, weil sie gut lesbar sind; Tools, die Auswirkungen analysieren, arbeiten mit dem Graphen.
Enthält eine SBOM einen Abhängigkeitsgraphen?
Das kann sie. CycloneDX hat einen dependencies-Abschnitt, in dem jede Komponente die Komponenten auflistet, von denen sie abhängt, und SPDX drückt dasselbe mit DEPENDS_ON-Beziehungen aus. Viele SBOMs lassen die Beziehungen weg und listen nur Komponenten auf, wodurch die Pfade verloren gehen.
Wie sehe ich den Abhängigkeitsgraphen eines GitHub-Repositorys?
Öffnen Sie im Repository den Tab Insights und wählen Sie Dependency graph. GitHub baut ihn aus den Manifesten und Lockfiles im Repository sowie allem, was über die Dependency Submission API eingereicht wurde, und zeigt bei unterstützten Ökosystemen den Pfad, über den jede transitive Abhängigkeit hineingekommen ist.
Was ist eine Diamant-Abhängigkeit?
Zwei Ihrer Abhängigkeiten hängen vom selben Paket ab, sodass der Graph eine Raute bildet. Brauchen sie inkompatible Versionen davon, muss der Paketmanager zwei Kopien installieren oder abbrechen. Das ist einer der Gründe, warum ein Graph schwerer zu handhaben ist, als er aussieht.
Sehen Sie den Graphen dessen, was Ihr Build geladen hat
Lassen Sie einen GitHub-Actions-Workflow auf CRACI laufen und erkunden Sie den Abhängigkeitsgraphen seiner aufgezeichneten SBOM, auf jeder Ebene des Baums.
Demo buchen