Toute personne disposant des autorisations d’administrateur sur un référentiel public peut créer et modifier un avis de sécurité.
Remarque : Si vous êtes chercheur en sécurité, vous devez contacter directement les mainteneurs pour leur demander de créer des avis de sécurité ou d’émettre des CVE en votre nom dans les dépôts que vous n’administrez pas. Toutefois, si les rapports de vulnérabilités privés sont activés pour le dépôt, vous pouvez signaler vous-même une vulnérabilité en privé. Pour plus d’informations, consultez « Signalement privé d’une vulnérabilité 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
et2.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 ».
Warning
L’utilisation de l’option d’opérateur >
n’est pas recommandée, car OSV ne le prend pas en charge.
=
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 est0
, 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.
- La valeur implicite est toujours
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 quen+1
est corrigé.< n
ne doit être utilisé que lorsquen
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
etwindows
. Lorsque vous publiez2.0.0-linux
et2.0.0-windows
, l’utilisation de< 2.0.0
comme version vulnérable marque2.0.0-linux
et2.0.0-windows
comme vulnérable, car la logique de version interprète-linux
et-windows
comme des préversions. Vous devrez marquer2.0.0-linux
, la branche la plus antérieure dans l’alphabet, comme la première version corrigée pour éviter que2.0.0-linux
et2.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 comme32.0.0
,32.0.0-android
et32.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é.