Meilleures pratiques pour l’écriture des avis de sécurité de référentiels

Toute personne disposant des autorisations d’administrateur sur un référentiel public peut créer et modifier un avis de sécurité.

À propos des avis de sécurité pour les référentiels

Les avis de sécurité des référentiels permettent aux gestionnaires de dépôts publics de discuter d’une faille de sécurité dans un projet et de la résoudre en privé. Après avoir collaboré sur un correctif, ils peuvent publier l’avis de sécurité pour rendre publique la vulnérabilité de sécurité auprès de la communauté du projet. En publiant des avis de sécurité, les chargés de maintenance des dépôts facilitent la mise à jour des dépendances de package pour leur communauté et la recherche de l’impact des vulnérabilités de sécurité. Pour plus d’informations, consultez « À propos des avis de sécurité des référentiels. »

Nous vous recommandons d’utiliser la syntaxe de la GitHub Advisory Database, en particulier la mise en forme de la version, quand vous écrivez un avis de sécurité de référentiel ou que vous apportez une contribution de la communauté à un avis de sécurité global.

Si vous respectez la syntaxe de la GitHub Advisory Database, en particulier quand vous définissez les versions affectées :

• Quand vous publiez votre avis de référentiel, nous pouvons ajouter votre avis à la GitHub Advisory Database en tant qu’avis « GitHub-reviewed », sans devoir demander plus d’informations.
• Dependabot a les informations nécessaires pour identifier exactement les référentiels affectés et leur envoyer des Dependabot alerts pour les avertir.
• Les membres de la communauté sont moins susceptibles de suggérer des modifications de votre avis pour corriger les informations manquantes ou incorrectes.

Vous ajoutez ou modifiez un avis de référentiel à l’aide du formulaire Brouillon d’avis de sécurité. Pour plus d’informations, consultez « Création d’un avis de sécurité de dépôt ».

Vous suggérez l’amélioration d’un avis global existant à l’aide du formulaire Améliorer un avis de sécurité. Pour plus d’informations, consultez « Modification des avis de sécurité dans la base de données d’avis de GitHub ».

Écosystème

Vous devez attribuer l’avis à l’un des écosystèmes pris en charge à l’aide du champ Écosystème. Pour plus d’informations sur les écosystèmes que nous prenons en charge, consultez « Exploration des avis de sécurité dans la base de données GitHub Advisory ».

Nom du package

Nous vous recommandons d’utiliser le champ Nom du package pour spécifier les packages affectés, car les informations de package sont nécessaires pour les avis « GitHub-reviewed » dans la GitHub Advisory Database. Les informations sur le package sont facultatives pour les avis de sécurité au niveau du référentiel. Toutefois, l’ajout de ces informations dès le début simplifie le processus de révision quand vous publiez votre avis de sécurité.

Versions affectées

Nous vous recommandons d’utiliser le champ Versions affectées pour spécifier les versions concernées, car ces informations sont nécessaires pour les avis « GitHub-reviewed » dans la GitHub Advisory Database. Les informations de version sont facultatives pour les avis de sécurité au niveau du référentiel. Toutefois, l’ajout de ces informations dès le début simplifie le processus de révision quand vous publiez votre avis de sécurité.

Pour plus d’informations sur la GitHub Advisory Database, consultez https://github.com/github/advisory-database.

Glossaire

Plage de versions vulnérables (VVR, Vulnerable Version Range)  : plage de versions vulnérables à un bogue logiciel particulier. Opérateur : n’importe quel symbole qui indique la délimitation d’une plage de versions vulnérables. Format de vulnérabilité open source (OSV, Open Source Vulnerability)  : format avec lequel les données GitHub Advisory Database s’efforcent d’être compatibles.

Syntaxe de version

• Les nombres plus petits sont des versions antérieures que les nombres plus grands. par exemple, 1.0.0 est une version antérieure à 2.0.0
• Les lettres antérieures dans l’alphabet sont des versions antérieures aux lettres ultérieures dans l’alphabet. Par exemple, 2.0.0-a est une version antérieure à 2.0.0-b.
• Toutes les lettres qui viennent après un nombre sont considérées comme faisant partie d’une préversion, de sorte que toutes les versions contenant des lettres après les nombres sont des versions antérieures à celles comportant des nombres sans lettres dans le numéro de version. Par exemple, 2.0.0-alpha, 2.0.0-beta et 2.0.0-rc sont antérieurs à 2.0.0.
• Une version définitive ne peut pas être plus petite au plus grand nombre dans la VVR. Par exemple, une version vulnérable est publiée et le mainteneur recommande de passer à une version antérieure. La version antérieure ne peut pas être utilisée comme version définitive, car elle est plus petite que la version vulnérable.

Opérateurs pris en charge

• >= pour « supérieur ou égal à cette version ».
• > pour « supérieur à cette version ».

• = pour « égal à cette version ».
• <= pour « inférieur ou égal à cette version ».
• < pour « inférieur à cette version ».

Spécification des versions impactées sur GitHub

• Une chaîne de version affectée valide est constituée de l’un des éléments suivants :

  • Séquence d’opérateur de limite inférieure.
  • Séquence d’opérateur de limite supérieure.
  • Séquence d’opérateurs de limite supérieure et inférieure.
  • Une séquence de version spécifique utilisant l’opérateur d’égalité (=).
  • Chaque séquence d’opérateur doit être spécifiée avec l’opérateur, un espace, puis la version. Pour plus d’informations sur les opérateurs valides, consultez Opérateurs pris en charge ci-dessus.
  • La version doit commencer par un chiffre suivi d’un nombre quelconque de chiffres, de lettres, de points, de tirets ou de traits de soulignement (tout sauf un espace ou une virgule). Pour plus d’informations sur la mise en forme des versions, consultez la syntaxe version ci-dessus.
  • Quand vous spécifiez une séquence de limites supérieure et inférieure, la limite inférieure doit être indiquée en premier, suivie d’une virgule et d’un espace, puis de la limite supérieure.

  Remarque : les chaînes de versions affectées ne peuvent pas contenir d’espaces de début ou de fin.

• Les opérateurs de limite supérieure peuvent être inclusifs ou exclusifs, c’est-à-dire <= ou < respectivement.

• Les opérateurs de limite inférieure peuvent être inclusifs ou exclusifs, c’est-à-dire >= ou > respectivement. Toutefois, si vous publiez votre avis de référentiel et que nous convertissons votre avis de référentiel en avis global, une règle différente s’applique : les chaînes de limite inférieure doivent être inclusives, c’est-à-dire >=. L’opérateur de limite inférieure exclusif (>) est autorisé uniquement si la version est 0, par exemple > 0.

  Remarques : la limitation de la limite inférieure :

  • Est due à des incompatibilités avec le schéma OSV (Open Source Vulnerability).
  • S’applique uniquement quand vous faites une suggestion sur un avis existant dans la GitHub Advisory Database.

• Vous ne pouvez pas spécifier plusieurs plages de versions affectées dans le même champ comme > 2.0, < 2.3, > 3.0, < 3.2. Pour spécifier plusieurs plages, vous devez créer une section Produits affectés pour chaque plage, en cliquant sur le bouton + Ajouter un autre produit affecté.

  

• Si la plage de versions affectées comprend une seule limite supérieure ou inférieure :

  • La valeur implicite est toujours > 0 si la limite inférieure n’est pas spécifiée explicitement.
  • La valeur implicite est toujours infinie si la limite supérieure n’est pas spécifiée explicitement.

Paramétrage d’une limite supérieure uniquement sur une VVR

• Si vous paramétrez uniquement une limite supérieure, utilisez <= ou <.
• Les avis de sécurité PyPa utilisent souvent >= 0, <= n ou >= 0, < n pour faire référence à des plages de versions qui n’ont qu’une limite supérieure.
• L’inclusion de >= 0 dans une plage qui n’a qu’une limite supérieure n’est pas techniquement incorrecte, mais >= 0 n’est pas nécessaire si vous avez une limite supérieure.

Paramétrage d’une limite supérieure uniquement sur une VVR

• Si vous paramétrez uniquement une limite supérieure, utilisez <= ou <.
• Les avis de sécurité PyPa utilisent souvent >= 0, <= n ou >= 0, < n pour faire référence à des plages de versions qui n’ont qu’une limite supérieure.
• L’inclusion de >= 0 dans une plage qui n’a qu’une limite supérieure n’est pas techniquement incorrecte, mais >= 0 n’est pas nécessaire si vous avez une limite supérieure.

Paramétrage d’une limite inférieur uniquement sur une VVR

• >= 0 pour toutes les versions
• > 0 n’est généralement pas utilisé.
• L’équipe d’organisation des avertissements ne recommande pas de paramétrer uniquement des limites inférieures sur les avertissements autres que les programmes malveillants. Cela est dû au fait que, si une version définitive est publiée, les utilisateurs de la version définitive continuent de recevoir des alertes Dependabot inutiles jusqu’à ce que l’avertissement soit mis à jour manuellement.

Spécification d’une seule version impactée

• = n pour la seule version impactée
• N’oubliez pas que = n’inclut pas automatiquement les préversions, les versions alpha ou bêta, uniquement la version spécifiée.
• Utilisation appropriée des espaces
  • Utilisez un espace entre un opérateur et un numéro de version.
  • N’utilisez pas d’espace dans >= ou <=.
  • N’utilisez pas d’espace entre un nombre et une virgule dans >= lower bound, <= upper bound.
  • Utilisez un espace entre une virgule et l’opérateur de la limite supérieure.

Erreurs courantes

• Évitez d’utiliser la plage de versions vulnérables < n, puis de dire que n+1 est corrigé.

  • < n ne doit être utilisé que lorsque n n’est pas vulnérable.
  • Dans ce cas, la VVR doit être <= n or < n+1.

• Évitez d’utiliser uniquement un nombre pour décrire les versions définitives avec des numéros de version officiels qui contiennent des lettres. Dites que votre logiciel a deux branches, linux et windows. Lorsque vous publiez 2.0.0-linux et 2.0.0-windows, l’utilisation de < 2.0.0 comme version vulnérable marque 2.0.0-linux et 2.0.0-windows comme vulnérable, car la logique de version interprète -linux et -windows comme des préversions. Vous devrez marquer 2.0.0-linux, la branche la plus antérieure dans l’alphabet, comme la première version corrigée pour éviter que 2.0.0-linux et 2.0.0-windows soient considérés comme vulnérable.

Exemples

Avertissements avec plusieurs VVR et plusieurs opérateurs

L’authentification TLS de la passerelle Etcd s’applique uniquement aux points de terminaison détectés dans les enregistrements SRV DNS (GHSA-wr2v-9rpq-c35q) a deux plages de versions vulnérables :

• < 3.3.23, qui a une limite supérieure sans limite inférieure et utilise l’opérateur <.
• >= 3.4.0-rc.0, <= 3.4.9, qui a une limite supérieure et une limite inférieure, et utilise les opérateurs >= et <=.

Avertissement montrant la relation entre une préversion et une version régulière

La plateforme XWiki autorise XSS via le nom XClass dans les propriétés de chaîne (GHSA-wcg9-pgqv-xm5v) a quatre plages de versions vulnérables :

• >= 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

Trois de ces VVR incluent des préversions dans le compartiment des versions vulnérables. L’un des VVR, = 16.0.0-rc-1, montre que seul 16.0.0-rc-1 est vulnérable, tandis que la version régulière publiée après elle, 16.0.0, ne l’est pas. La logique considère 16.0.0-rc-1 et 16.0.0 comme des versions distinctes, 16.0.0-rc-1 étant une version antérieure à 16.0.0.

La mise à jour corrective pour cette vulnérabilité a été publié le 24 janvier 2024, pour la version 16.0.0. Pour plus d’informations, consultez commit 27eca84 dans le référentiel xwiki/xwiki-platform . La page XWiki Platform Old Core dans le site du référentiel MVN indique que 16.0.0-rc-1 a été publié le 22 janvier 2024, avant que le correctif ait été ajouté à XWiki, et que 16.0.0 a été publié le 29 janvier 2024, après la validation du correctif.

Avertissements concernant les noms de branches dans les numéros de version

Google Guava a deux branches, android et jre, dans ses versions publiées. Guava vulnérable à l’utilisation non sécurisée d’un annuaire temporaire (GHSA-7g45-4rm6-3mm3) et Divulgation d’informations dans Guava (GHSA-5mg8-w23w-74h3) sont des avertissements concernant les vulnérabilités qui affectent Guava. Les deux avertissements définissent 32.0.0-android comme version corrigée.

• En raison de la logique de la plage de versions qui interprète les lettres après 32.0.0 comme préversion, si vous définissez la version corrigée comme 32.0.0, 32.0.0-android et 32.0.0-jre seraient tous deux incorrectement marquées comme vulnérables.
• En raison de la logique de la plage de versions qui interprète les lettres ultérieures dans l’alphabet comme étant une version ultérieure que les lettres antérieures dans l’alphabet, si vous définissez la version corrigée comme 32.0.0-jre, 32.0.0-android serait incorrectement marquée comme vulnérable.

La meilleure façon d’indiquer que 32.0.0-android et 32.0.0-jre sont tous deux corrigés est d’utiliser 32.0.0-android comme version corrigée, et la logique interprétera tout ce qui suit 32.0.0-android dans l’alphabet comme corrigé.