Skip to main content

Priorisieren von Dependabot-Warnungen mithilfe von Metriken

Du kannst Dependabot alerts in deiner Organisation priorisieren, indem du die bereitgestellten Metriken analysierst. Mit diesem Ansatz kannst du deinen entwickelnden Personen mitteilen, dass sie sich zuerst auf die wichtigsten Sicherheitsrisiken zu konzentrieren sollten.

Wer kann dieses Feature verwenden?

Organisationsbesitzerinnen, Sicherheitsmanagerinnen und Organisationsmitglieder mit der Administratorrolle

Priorisieren von Dependabot alerts mithilfe von Metriken

Anwendungssicherheitsmanager (AppSec) sehen sich häufig mit einer Flut von Dependabot alerts konfrontiert, wodurch es schwierig wird, zu ermitteln, welche Sicherheitsrisiken zuerst behoben werden sollen. Dependabot-Metriken bieten wertvolle Erkenntnisse, die bei der effizienten Priorisierung von Warnungen helfen, damit kritische Sicherheitsprobleme umgehend behoben werden. Benutzende Personen können fundierte Entscheidungen treffen und Ressourcen auf die Sicherheitsrisiken mit den größten Auswirkungen konzentrieren. Dieser Ansatz stärkt den Sicherheitsstatus der Organisation und optimiert das Sicherheitsmanagement.

Grundlegendes zu Dependabot-Metriken

Dependabot-Metriken bieten detaillierte Informationen zu Sicherheitsrisiken, die in deinen Abhängigkeiten erkannt wurden. Zielmetriken umfassen:

  • Severity: Gibt die potenziellen Auswirkungen eines Sicherheitsrisikos an (z. B. niedrig, mittel, hoch, kritisch)
  • Exploitability: Bewertet, wie einfach ein Sicherheitsrisiko ausgenutzt werden kann
  • Dependency relationship: Dabei wird zwischen direkten und transitiven Abhängigkeiten unterschieden.
  • Dependency scope: Dabei wird zwischen Laufzeit- und Entwicklungsabhängigkeiten unterschieden. Hiermit wird bestimmt, ob der anfällige Code tatsächlich in deiner Anwendung verwendet wird.
  • Warnungen, die in den letzten 30 Tagen geschlossen wurden, einschließlich der Anzahl der warnungen, die durch Dependabot manuell und automatisch geschlossen wurden: Dabei wird der Fortschritt beim Beheben von Warnungen nachverfolgt. Hierbei wird veranschaulicht, wie GitHub Code Security dir helfen kann, Sicherheitsrisiken frühzeitig zu erkennen.
  • Tabelle mit der Gesamtanzahl der geöffneten Warnungen für jedes Repository sowie Daten zu „Severity“ und „Exploitability“: Ermöglicht es dir, auf Repositoryebene weitere Untersuchungen anzustellen

Darüber hinaus kannst du komplexe Filter anwenden, die einzelne verfügbare Filter miteinander kombinieren. Weitere Informationen zu Filtern findest du unter Dependabot-Dashboardansichtsfilter.

Schritte zum Priorisieren von Warnungen

Mit diesen ersten Schritten kannst du die Dependabot alerts identifizieren, die deine Organisation am meisten gefährdet haben, damit du deinen entwickelnden Personen mitteilen kannst, welche Warnungen für die Behebung verwendet werden sollen.

1. Passe die Trichterreihenfolge an die Anforderungen deiner Organisation an

Du kannst die Standardtrichterreihenfolge im Diagramm „Alert priorization“ anpassen, damit es das eindeutige Risikoprofil, die geschäftlichen Prioritäten und die Complianceanforderungen deiner Organisation widerspiegelt. Weitere Informationen findest du unter Anzeigen von Metriken für Dependabot-Warnungen.

2. Konzentrieren auf kritische Warnungen und Warnungen mit hohem Schweregrad

Beginne damit, Warnungen mit dem höchsten Schweregrad zu identifizieren, indem du die Filter severity-critical oder severity-high verwendest. Diese Sicherheitsrisiken stellen das größte Risiko dar und werden häufig nach Compliancestandards priorisiert. Sie können anschließend folgende Aktionen durchführen:

3. Bewerten der Ausnutzbarkeit und Reichweite

Priorisiere Sicherheitsrisiken, die in deiner Codebasis wahrscheinlich ausgenutzt werden. Um Warnungen zu identifizieren, die wahrscheinlich ausgenutzt werden, kannst du den Filter epss_percentage verwenden, der einem Wert wie epss_percentage>=0.10 zugeordnet ist.

4. Überprüfen des Abhängigkeitsbereichs und der Beziehung

Direkte Abhängigkeiten sind in der Regel einfacher zu aktualisieren und haben möglicherweise größere Auswirkungen auf die Sicherheit deiner Anwendung. Es wird empfohlen, diese nach Möglichkeit vor transitiven Abhängigkeiten zu behandeln. Durch das Filtern von Warnungen mithilfe des Filters relationship:direct ist es möglich, bei unterstützten Ökosystemen wie npm Sicherheitsrisiken für direkte Abhängigkeiten anzuzeigen.

Laufzeitabhängigkeiten werden von einer Anwendung in der Produktion verwendet. Durch das Aktualisieren dieser Art von Abhängigkeit können Sicherheitsrisiken, Fehlerbehebungen und Leistungsverbesserungen behoben werden, die sich direkt auf deine Endbenutzenden oder Systeme auswirken. Andererseits werden Entwicklungsabhängigkeiten nur während der Entwicklungs-, Test- oder Buildprozesse verwendet. Obwohl sie wichtig sind, wirken sich Probleme in diesen Abhängigkeiten in der Regel nicht auf deine ausgeführte Anwendung oder die benutzenden Personen aus.

Du kannst die Filter scope:runtime oder scope:development verwenden, um nur Warnungen für Laufzeit- oder Entwicklungsabhängigkeiten anzuzeigen.

5. Berücksichtigen des Alters von Warnungen

Ältere Warnungen weisen möglicherweise auf langfristige Risiken hin. Überprüfe und behandle ältere Benachrichtigungen regelmäßig, um zu verhindern, dass sich Sicherheitsrisiken anhäufen. Nachdem du beispielsweise festgelegt hast, dass ein bestimmtes Repository mehr Warnungen als andere Repositorys hat, die priorisiert werden müssen, hast du folgende Möglichkeiten:

  1. Klicke in der Repositorytabelle auf den Repositorynamen, um nur die Warnungen für dieses Repository anzuzeigen.
  2. Verwende den Filter „Older“ in der Dropdownliste Sort sowie weitere Sortierkriterien, um die Visualisierung so zu optimieren, dass sie deine Kriterien nach Alter erfüllt.

6. Nutzen der Automatisierung

Verwende die automatisierten Pull Requests von Dependabot, um Sicherheitsrisiken schnell zu beheben. Integriere diese Updates in deine CI/CD-Pipeline, um eine schnellere Behebung und eine höhere Effizienz zu erzielen.

Bewährte Methoden

  • Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) zum Beheben von Sicherheitsrisiken basierend auf dem Schweregrad
  • Regelmäßiges Überwachen von Metriken zum Identifizieren von Trends und wiederkehrenden Probleme
  • Zusammenarbeit mit Entwicklern für rechtzeitige Updates und zum Minimieren von Unterbrechungen
  • Dokumentieren von Entscheidungen für Transparenz und zum Unterstützen zukünftiger Priorisierungen