Bewährte Methoden für das Schreiben von Sicherheitshinweisen für Repositorys

Informationen zu Sicherheitsempfehlungen für Repositorys

Mithilfe von Sicherheitsempfehlungen für Repositorys können Verwalter*innen von öffentlichen Repositorys ein Sicherheitsrisiko in einem Projekt privat besprechen und beheben. Nach der Zusammenarbeit an einer Lösung können Repositoryverwalter die Sicherheitsempfehlung veröffentlichen, um das Sicherheitsrisiko öffentlich für die Community des Projekts offenzulegen. Durch die Veröffentlichung von Sicherheitsempfehlungen erleichtern Repositoryverwalter ihrer Community das Aktualisieren von Paketabhängigkeiten und das Untersuchen der Auswirkungen von Sicherheitsrisiken. Weitere Informationen finden Sie unter Informationen zu Sicherheitsempfehlungen für Repositorys.

Beim Schreiben einer Sicherheitsempfehlung oder bei Beiträgen zu einer globalen Sicherheitsempfehlung wird empfohlen, die in GitHub Advisory Database verwendete Syntax zu übernehmen, insbesondere die Versionsformatierung.

Die Verwendung der Syntax für GitHub Advisory Database hat die folgenden Vorteile, insbesondere bei der Angabe der betroffenen Versionen:

• Wenn du die Repositoryempfehlung veröffentlichst, können wir diese zu GitHub Advisory Database mit der Bezeichnung „Von GitHub geprüft“ hinzufügen, ohne dich um weitere Informationen zu bitten.
• Dependabot verfügt über die nötigen Informationen, um betroffene Repositorys präzise zu ermitteln und diese über Dependabot alerts zu benachrichtigen.
• Communitymitglieder schlagen seltener Änderungen an deiner Empfehlung vor, um fehlende oder falsche Informationen zu korrigieren.

Du kannst eine Repositoryempfehlung mithilfe des Formulars Sicherheitsempfehlung entwerfen hinzufügen oder bearbeiten. Weitere Informationen finden Sie unter Erstellen einer Sicherheitsempfehlung für ein Repository.

Verbesserungen an einer vorhandenen globalen Empfehlung kannst du über das Formular Sicherheitsempfehlung verbessern vorschlagen. Weitere Informationen finden Sie unter Bearbeiten von Sicherheitshinweisen in GitHub Advisory Database.

Ökosystem

Du musst die Empfehlung einem der unterstützten Ökosysteme zuweisen, indem du das Feld Ökosystem ausfüllst. Weitere Informationen zu den von uns unterstützten Ökosystemen finden Sie unter Durchsuchen von Sicherheitsempfehlungen in der GitHub Advisory Database.

Paketname

Es wird empfohlen, über das Feld Paketname anzugeben, welche Pakete betroffen sind. Diese Paketinformationen sind für Empfehlungen mit der Bezeichnung „Von GitHub geprüft“ in GitHub Advisory Database erforderlich. Paketinformationen sind für Sicherheitsempfehlungen auf Repositoryebene optional, aber das frühzeitige Angeben dieser Informationen vereinfacht den Überprüfungsprozess beim Veröffentlichen von Sicherheitsempfehlungen.

Betroffene Versionen

Es wird empfohlen, über das Feld Betroffene Versionen anzugeben, welche Versionen betroffen sind. Diese Informationen sind für Empfehlungen mit der Bezeichnung „Von GitHub geprüft“ in GitHub Advisory Database erforderlich. Versionsinformationen sind für Sicherheitsempfehlungen auf Repositoryebene optional, aber das frühzeitige Angeben dieser Informationen vereinfacht den Überprüfungsprozess beim Veröffentlichen von Sicherheitsempfehlungen.

Weitere Informationen zu GitHub Advisory Database finden Sie unter https://github.com/github/advisory-database.

Glossar

•           **Anfälliger Versionsbereich (Vulnerable Version Range, VVR):** der Bereich der Versionen, die für einen bestimmten Softwarefehler anfällig sind.
  

•           **Operator:**: ein Symbol, das die Grenze eines anfälligen Versionsbereichs angibt.
  

•           **Open Source-Sicherheitsrisikoformat (Open Source Vulnerability, OSV):** das Format, mit dem die GitHub Advisory Database-Daten Kompatibilität anstreben.
  

Versionssyntax

• Kleinere Zahlen stehen für frühere Versionen als größere Zahlen. Beispielsweise ist 1.0.0 eine niedrigere Version als 2.0.0.
• Frühere Buchstaben im Alphabet stehen für frühere Versionen als spätere Buchstaben im Alphabet. Beispielsweise ist 2.0.0-a eine frühere Version als 2.0.0-b.
• Buchstaben nach einer Zahl werden als Angabe einer Vorabversion betrachtet. Versionen mit Buchstaben nach den Zahlen sind daher frühere Versionen als Versionen ohne Buchstaben in derselben Versionsnummer. Beispielsweise sind 2.0.0-alpha, 2.0.0-beta und 2.0.0-rc frühere Versionen als 2.0.0.
• Die Zahl für eine korrigierte Version darf nicht niedriger als die höchste Zahl im VVR sein. Beispielsweise könnte eine anfällige Version veröffentlicht werden und der Maintainer empfiehlt ein Downgrade. Der Maintainer kann im Feld Fixed diese niedrigere Version nicht als korrigierte oder gepatchte Version angeben, da diese Version niedriger als die anfällige Version ist.

Unterstützte Operatoren

•           `>=` für „höher als oder gleich dieser Version“.
  

•           `>` für „höher als diese Version“.
  

  Warnung

  Auch wenn GitHub die Verwendung des Operators > unterstützt, wird die Verwendung dieses Operators nicht empfohlen, da er nicht durch das OSV-Format unterstützt wird.

•           `=` für „gleich dieser Version“.
  

•           `<=` für „niedriger als oder gleich dieser Version“.
  

•           `<` für „niedriger als diese Version“.
  

Angabe der betroffenen Versionen für GitHub

Es ist wichtig, die betroffenen Versionen klar zu definieren, um relevante Hinweise zu erhalten. GitHub stellt im Feld Betroffene Versionen mehrere Optionen für die Angabe anfälliger Versionsbereiche bereit.

Beispiele, die zeigen, wie betroffene Versionen in einigen vorhandenen Hinweisen definiert werden, finden Sie unter Beispiele.

• Eine gültige Zeichenfolge für betroffene Versionen besteht aus einem der folgenden Elemente:

  • Einer Operatorsequenz für die Untergrenze

  • Einer Operatorsequenz für die Obergrenze

  • Einer Operatorsequenz für die Unter- und Obergrenze Die untere Grenze muss zuerst angegeben werden, gefolgt von einem Komma und einem einzelnen Leerzeichen und der Angabe der oberen Grenze.

  • Einer speziellen Versionssequenz mit dem Gleichheitsoperator (=)

  • Jede Operatorsequenz muss im Format „Operator, einzelnes Leerzeichen, Version“ angegeben werden. Weitere Informationen zu gültigen Operatoren finden Sie oben unter Unterstützte Operatoren.

  • Die Version muss mit einer Zahl beginnen, gefolgt von einer beliebigen Anzahl von Zahlen, Buchstaben, Punkten, Bindestrichen oder Unterstrichen (keine Leerzeichen oder Kommas). Weitere Informationen zur Versionsformatierung finden Sie oben unter Versionssyntax.

  Hinweis

  Zeichenfolgen für betroffene Versionen dürfen keine führenden oder nachgestellten Leerzeichen enthalten.

• Operatoren für die Obergrenze können inklusiv (<=) oder exklusiv (<) sein.

• Operatoren für die Untergrenze können inklusiv (>=) oder exklusiv (>) sein. Wenn du deine Repositoryempfehlung veröffentlichst und diese zu einer globalen Empfehlung hochgestuft wird, gilt jedoch eine andere Regel: Zeichenfolgen für die Untergrenze dürfen nur inklusiv (>=) sein. Der exklusive Operator für die Untergrenze (>) ist nur bei 0 zulässig, also zum Beispiel > 0.

• Ordnungsgemäße Verwendung von Leerzeichen

  • Verwenden Sie zwischen einem Operator und einer Versionsnummer ein Leerzeichen.

  • In >= oder <= dürfen Sie kein Leerzeichen verwenden.

  • Zwischen einer Zahl und einem Komma in >= lower bound, <= upper bound dürfen Sie kein Leerzeichen verwenden.

  • Verwenden Sie ein Leerzeichen zwischen einem Komma und dem Operator für die obere Grenze.

  Hinweis

  Die Einschränkung für die untere Grenze:

  • besteht aufgrund von Inkompatibilitäten mit dem OSV-Schema.
  • gilt nur, wenn ein Vorschlag für eine vorhandene Empfehlung in GitHub Advisory Database eingereicht wird.

• Du kannst in einem Feld nicht mehrere betroffene Versionsbereiche angeben, zum Beispiel > 2.0, < 2.3, > 3.0, < 3.2. Wenn du mehr als einen Bereich angeben möchtest, musst du für jeden Bereich einen neuen Abschnitt Betroffene Produkte erstellen. Klicke hierfür auf + Weiteres betroffenes Produkt hinzufügen.

  

• Wenn der betroffene Versionsbereich nur eine Ober- oder Untergrenze enthält:

  • Der implizite Wert ist immer > 0, wenn die Untergrenze nicht explizit angegeben ist.
  • Der implizite Wert ist immer unendlich, wenn die Obergrenze nicht explizit angegeben ist.

Festlegen nur einer oberen Grenze für einen VVR

• Wenn Sie nur eine obere Grenze festlegen, verwenden Sie <= oder <.
• GitHub Advisory Database verwendet die PyPA-Datenbank als eine ihrer Datenquellen. GitHub stimmt jedoch nicht exakt mit dem PyPA-VVR-Format überein (PyPa-Sicherheitshinweise verwenden häufig >= 0, <= n oder >= 0, < n, um auf Versionsbereiche zu verweisen, für die nur eine obere Grenze festgelegt ist).
• Es ist nicht erforderlich, >= 0 in einen Bereich einzufügen, für den nur eine obere Grenze festgelegt ist.

Festlegen nur einer unteren Grenze für einen VVR

• Das Kuratierungsteam für Hinweise empfiehlt nicht, für andere Hinweise als Malwarehinweise nur untere Grenzen festzulegen. Wenn eine korrigierte Version veröffentlicht werden, erhalten Benutzer der korrigierten Version in diesem Fall weiterhin unnötige Dependabot alerts, bis der Hinweis manuell aktualisiert wird.
• Verwenden Sie >= 0 für alle Versionen.

•           `> 0` wird in der Regel nicht verwendet.
  

Angabe nur einer betroffenen Version

•           `= n` für die einzelne betroffene Version
  

• Denken Sie daran, dass = nicht automatisch öffentliche und private Vorschauversionen enthält, sondern nur die angegebene Version.

Häufige Fehler

• Vermeiden Sie die Verwendung des anfälligen Versionsbereichs < n und die anschließende Angabe, dass n+1 gepatcht wurde.

  •           `< n` sollte nur verwendet werden, wenn `n` nicht anfällig ist.
    

  • In diesem Fall sollte der VVR <= n oder < n+1 sein.

• Vermeiden Sie es, nur Zahlen zu verwenden, wenn Sie korrigierte Versionen mit offiziellen Versionsnummern beschreiben, die Buchstaben enthalten. Angenommen, Ihre Software verfügt über zwei Verzweigungen, linux und windows. Wenn Sie 2.0.0-linux und 2.0.0-windows veröffentlichen und dabei < 2.0.0 als anfällige Version verwenden, werden 2.0.0-linux und 2.0.0-windows als anfällig markiert, da die Versionslogik -linux und -windows als Vorabversionen interpretiert. Sie müssen 2.0.0-linux, die früheste Verzweigung gemäß dem Alphabet, als erste gepatchte Version markieren, um zu vermeiden, dass 2.0.0-linux und 2.0.0-windows als anfällig betrachtet werden.

Examples

Hinweis mit mehreren VVRs und mehreren Operatoren

          [TLS-Authentifizierung des Etcd-Gateways gilt nur für Endpunkte, die in DNS-SRV-Einträgen erkannt werden (GHSA-wr2v-9rpq-c35q)](https://github.com/advisories/GHSA-wr2v-9rpq-c35q), zwei anfällige Versionsbereiche:

•           `< 3.3.23`, für den nur eine obere Grenze (und keine untere Grenze) festgelegt wurde und der den Operator `<` verwendet.
  

•           `>= 3.4.0-rc.0, <= 3.4.9`, für den eine obere Grenze und eine untere Grenze festgelegt wurden und der die Operatoren `>=` und `<=` verwendet.
  

Hinweis, der die Beziehung zwischen einer Vorabversion und einer regulären Version zeigt

          [XWiki Platform lässt XSS über XClass-Namen in Zeichenfolgeneigenschaften zu (GHSA-wcg9-pgqv-xm5v)](https://github.com/advisories/GHSA-wcg9-pgqv-xm5v), vier anfällige Versionsbereiche:

• >= 1.1.2, < 14.10.21
• >= 15.0-rc-1, < 15.5.5
• >= 15.6-rc-1, < 15.10.6
• = 16.0.0-rc-1

Bei drei dieser VVRs handelt es sich um Vorabversionen im anfälligen Versionsbereich. Der letzte VVR, = 16.0.0-rc-1, zeigt, dass nur 16.0.0-rc-1 anfällig ist, während die später veröffentlichte reguläre Version, 16.0.0, nicht anfällig ist. Die Logik berücksichtigt 16.0.0-rc-1 und 16.0.0 als separate Versionen, wobei 16.0.0-rc-1 eine frühere Version als 16.0.0 ist.

Der Patch für dieses Sicherheitsrisiko wurde am 24. Januar 2024 für Version 16.0.0 veröffentlicht. Weitere Informationen finden Sie unter Commit 27eca84 im xwiki/xwiki-platform -Repository. Die Seite XWiki Platform Old Core auf der MVN Repository-Website zeigt, dass 16.0.0-rc-1 am 22. Januar 2024 veröffentlicht wurde, bevor XWiki korrigiert wurde, und dass 16.0.0 am 29. Januar 2024 veröffentlicht wurde, nachdem die Korrektur ausgeführt worden war.

Hinweis mit Verzweigungsnamen in Versionsnummern

          [Google Guava](https://mvnrepository.com/artifact/com.google.guava/guava) verfügt über zwei Verzweigungen, `android` und `jre`, in den Versionsveröffentlichungen.               [Guava ist für eine unsichere Verwendung temporärer Verzeichnisse anfällig (GHSA-7g45-4rm6-3mm3)](https://github.com/advisories/GHSA-7g45-4rm6-3mm3) und [Informationsoffenlegung in Guava (GHSA-5mg8-w23w-74h3)](https://github.com/advisories/GHSA-5mg8-w23w-74h3) sind Hinweise zu Sicherheitsrisiken, die Guava betreffen. Beide Hinweise geben `32.0.0-android` als gepatchte Version an.

• Die Versionsbereichslogik interpretiert Buchstaben nach 32.0.0 als Vorabversionen. Wenn Sie die gepatchte Version als 32.0.0 festlegen, würden sowohl 32.0.0-android als auch 32.0.0-jre fälschlicherweise als anfällig markiert.
• Die Versionsbereichslogik interpretiert Buchstaben, die weiter hinten im Alphabet stehen, als eine neuere Version als Buchstaben, die weiter vorne im Alphabet stehen. Wenn Sie 32.0.0-jre als gepatchte Version festlegen, würde 32.0.0-android als anfällig markiert werden.

Die beste Methode, um anzugeben, dass sowohl 32.0.0-android und 32.0.0-jre gepatcht wurden, ist die Verwendung von 32.0.0-android als gepatchter Version, sodass die Logik alle Versionen mit Buchstaben, die nach 32.0.0-android im Alphabet stehen, als gepatcht interpretiert.