Die Ergebnisse der von GitHub gemeldeten Abhängigkeitserkennung unterscheiden sich möglicherweise von den Ergebnissen, die von anderen Tools zurückgegeben werden. Hierfür gibt es gute Gründe, und es ist hilfreich zu verstehen, wie GitHub Abhängigkeiten für dein Projekt bestimmt.
Ermittelt das Abhängigkeitsdiagramm nur Abhängigkeiten in Manifesten und Sperrdateien?
Das Abhängigkeitsdiagramm enthält automatisch Informationen zu Abhängigkeiten, die explizit in der Umgebung deklariert sind. Das heißt, Abhängigkeiten, die in einem Manifest oder einer Sperrdatei angegeben sind. Das Abhängigkeitsdiagramm enthält im Allgemeinen auch transitive Abhängigkeiten – selbst wenn sie nicht in einer Sperrdatei angegeben sind –, indem die Abhängigkeiten der Abhängigkeiten in einer Manifestdatei untersucht werden.
Das Abhängigkeitsdiagramm enthält nicht automatisch „lose“ Abhängigkeiten. Als „lose“ Abhängigkeiten werden einzelne Dateien bezeichnet, die aus einer anderen Quelle kopiert und direkt oder in ein Repository (z. B. eine ZIP- oder JAR-Datei) eingecheckt werden, anstatt in einem Manifest oder einer Sperrdatei des Paket-Managers referenziert zu werden.
Sie können jedoch mithilfe der Abhängigkeitsübermittlungs-API Abhängigkeiten zum Abhängigkeitsdiagramm eines Projekts hinzuzufügen, auch wenn die Abhängigkeiten nicht in einer Manifest- oder gesperrten Datei deklariert sind, z. B. Abhängigkeiten, die beim Erstellen eines Projekts aufgelöst werden. Abhängigkeiten, die mit der Abhängigkeitsübermittlungs-API an ein Projekt übermittelt wurden, zeigen an, welche Erkennung für die Übermittlung verwendet wurde und wann die Übermittlung erfolgt ist. Weitere Informationen zur Abhängigkeitsübermittlungs-API findest du unter Verwenden der Abhängigkeitsübermittlungs-API.
Überprüfung: Handelt es sich um eine fehlende Abhängigkeit für eine Komponente, die nicht im Manifest oder in der Sperrdatei des Repositorys angegeben ist?
Erkennt das Abhängigkeitsdiagramm Abhängigkeiten, die mithilfe von Variablen angegeben wurden?
Das Abhängigkeitsdiagramm analysiert Manifeste, während sie an GitHub gepusht werden. Das Abhängigkeitsdiagramm hat also keinen Zugriff auf die Buildumgebung des Projekts und kann daher die in den Manifesten verwendeten Variablen nicht auflösen. Wenn Sie in einem Manifest Variablen verwenden, um den Namen oder die Version einer Abhängigkeit anzugeben, wird diese Abhängigkeit nicht automatisch in das Abhängigkeitsdiagramm einbezogen.
Sie können jedoch mithilfe der Abhängigkeitsübermittlungs-API Abhängigkeiten zum Abhängigkeitsdiagramm eines Projekts hinzuzufügen, auch wenn die Abhängigkeiten nur beim Erstellen eines Projekts aufgelöst werden. Weitere Informationen zur Abhängigkeitsübermittlungs-API findest du unter Verwenden der Abhängigkeitsübermittlungs-API.
Überprüfung: Ist die fehlende Abhängigkeit im Manifest deklariert, indem eine Variable für ihren Namen oder ihre Version verwendet wird?
Gibt es Grenzwerte, die die Daten des Abhängigkeitsdiagramms beeinflussen?
Ja, das Abhängigkeitsdiagramm hat Beschränkungen für die Größe, die Anzahl und den Speicherort der Manifestdateien, die verarbeitet werden.
Die Verarbeitungsgrenzwerte wirken sich auf das Abhängigkeitsdiagramm aus, das in GitHub angezeigt wird, und verhindern außerdem die Erstellung von Dependabot alerts.
Manifeste mit einer Größe von mehr als 10 MB werden ignoriert und generieren keine Dependabot alerts.
Standardmäßig verarbeitet GitHub nicht mehr als 600 Manifeste pro Repository. Dependabot generiert keine Dependabot alerts über diesen Grenzwert hinaus für Manifeste, und Dependabot alerts verhalten sich möglicherweise unvorhersehbar, wenn dieser Grenzwert überschritten wird.
Manifestdateien, die in Verzeichnissen mit Namen gespeichert sind, die normalerweise für anbieterbezogene Abhängigkeiten verwendet werden, werden nicht verarbeitet. Ein Verzeichnis, dessen Name mit den folgenden regulären Ausdrücken übereinstimmt, wird als Verzeichnis mit anbieterbezogenen Abhängigkeiten betrachtet:
(3rd|[Tt]hird)[-_]?[Pp]arty/(^|/)vendors?/(^|/)[Ee]xtern(als?)?/(^|/)[Vv]+endor/
Beispiele:
- third-party/dependencies/dependency1
- vendors/dependency1
- /externals/vendor1/dependency1
Meine Abhängigkeiten sehen nicht richtig aus, was kann ich tun?
Wenn die Tabelle der Abhängigkeiten für dein Projekt die Manifeste deines Repositorys nicht korrekt darstellt, kannst du eine Neuerstellung des Abhängigkeitsdiagramms auslösen.
Klicke auf der Registerkarte Dependabot alerts des Repositorys oben in der Warnungsliste auf . Wähle Refresh Dependabot alerts aus dem Dropdownmenü aus. Dadurch wird eine Hintergrundaufgabe zum Verarbeiten der Manifeste des Repositorys, zum Erkennen neuer oder geänderter Abhängigkeiten und zum Aktualisieren der Warnungen in die Warteschlange eingereiht.
Note
Du benötigst die Berechtigung zum Verwalten von Sicherheitswarnungen, um das Abhängigkeitsdiagramm eines Repositorys zu aktualisieren. Informationen zum Konfigurieren dieses Zugriffs findest du unter Verwalten von Sicherheits- und Analyseeinstellungen für dein Repository. Um das Missbrauchspotential weiter zu reduzieren, kann die Option Refresh Dependabot alerts nur einmal pro Stunde und Repository ausgelöst werden.
Durch das Klicken auf Refresh Dependabot alerts werden nur Manifestdateien überprüft. Wenn dein Abhängigkeitsdiagramm auch Abhängigkeitsinformationen zur Buildzeit enthält, die mithilfe der Abhängigkeitsübermittlungs-API übermittelt werden, löst das erneute Ausführen der Aktion oder des externen Prozesses, der die Abhängigkeitsinformationen generiert und übermittelt, auch eine Neuerstellung des Abhängigkeitsdiagramms des Repositorys aus. Weitere Informationen zu Abhängigkeitsübermittlungs-API findest du unter Verwenden der Abhängigkeitsübermittlungs-API.
Wenn du die automatische Abhängigkeitsübermittlung für Maven verwendest, löst das Pushen eines Commits, der die pom.xml-Datei des Repositorys aktualisiert, die Ausführung der automatischen Übermittlungsaktion aus.
Der Zeitstempel oben in der Liste der Warnungen gibt immer an, wie lange das Abhängigkeitsdiagramm zuletzt erstellt wurde.