Vulnerability information

Le client NuGet, à partir de la version 6.7, peut télécharger des informations de vulnérabilité de package connues à utiliser dans des scénarios tels que la vérification des packages pendant les opérations de restauration. Bien que la ressource de métadonnées de package contient également des informations de vulnérabilité connues, si une application doit vérifier un grand nombre de packages pour connaître les vulnérabilités connues, il est beaucoup plus rapide de télécharger un fichier de vulnérabilités connues et de rechercher localement, plutôt que d’effectuer un grand nombre de requêtes HTTP. Par exemple, cela permet à NuGet Restore de vérifier rapidement les packages restaurés pour détecter les vulnérabilités connues, qui n’ont jamais jamais téléchargé les détails du package à partir de la ressource de métadonnées du package.

L’API se compose d’au moins deux fichiers, de l’index de vulnérabilité et d’un ou plusieurs fichiers de page de vulnérabilité. Les données de vulnérabilité connues peuvent être partitionnés en plusieurs fichiers, et l’index de vulnérabilité fournit aux clients des informations nécessaires pour mettre en cache les fichiers et mettre à jour le cache, efficacement.

La ressource utilisée pour générer cette URL est la ressource VulnerabilityInfo trouvée dans l’index de service .

Stratégie de partitionnement suggérée

Les pages répertoriées dans l’index de vulnérabilité doivent idéalement être optimisées pour optimiser la mise en cache, et donc réduire les mises à jour des fichiers volumineux. Cela permet aux clients de réduire la fréquence à laquelle il doit télécharger les mises à jour.

Une stratégie suggérée pour le partitionnement des données de vulnérabilité consiste à avoir deux pages, base.json et updates.json. Le base.json fichier est mis à jour régulièrement (par exemple une fois par mois) et contient toutes les vulnérabilités connues au moment où le fichier est régénéré. Le updates.json fichier doit contenir les nouveaux avis publiés depuis base.json la dernière regénération. Cela permet aux clients de télécharger rarement la grande base.json taille, tandis que le fichier fréquemment modifié updates.json est toujours relativement petit.

Les clients NuGet combinent les données de plusieurs fichiers de manière additive et peuvent charger les fichiers dans n’importe quel ordre. Le schéma du fichier de données n’autorise pas la modification ou la réaction d’une vulnérabilité connue à partir d’un autre fichier. Par conséquent, si la source de données de vulnérabilité d’un serveur (par exemple la base de données GitHub Advisories) modifie un avis existant, le serveur NuGet doit modifier la page que les informations de vulnérabilité ont été signalées précédemment. Pour ce faire, le schéma de partition suggéré consiste à traiter toutes les modifications et suppressions des vulnérabilités comme un déclencheur pour régénérer le fichier complet base.json et vide updates.json.

Si vous envisagez d’utiliser les données de vulnérabilité de nuget.org dans votre propre implémentation de serveur NuGet, vous devez prendre en compte les développeurs qui n’ont pas d’accès direct à nuget.org. Pour plus d’informations, consultez notre guide d’implémentation.

Versioning

Les valeurs @type suivantes sont utilisées :

Vulnerability index

L’index de vulnérabilité est un tableau JSON d’objets avec les propriétés suivantes :

Les restrictions suivantes s’appliquent :

• L’index doit être un tableau d’objets comportant entre 1 et 16 éléments. Si le serveur n’a pas de données de vulnérabilité (pages zéro), vous devez supprimer la VulnerabilityInfo ressource de l’instance ServiceIndex.
• @name doit être unique dans l’index, doit être compris entre 1 et 32 caractères, et ne peut utiliser que les caractères A pour Z, a pour z, 0 vers 9, -ou _.
• @id doit être une URL absolue, et non une URL relative.

Vulnerability page

Les fichiers de page de vulnérabilité sont un objet JSON utilisé comme dictionnaire. Les clés de propriété sont l’ID de package minuscule et les valeurs de propriété sont un tableau de l’objet suivant avec les propriétés suivantes :

Les ID de package (clés de l’objet racine) doivent être en minuscules String.ToLowerInvariantavec .

La liste des vulnérabilités connues pour un package doit être triée dans l’ordre décroissant de la version maximale de la plage de versions, suivie de la version décroissante de la version min, suivie de l’ordre croissant de l’URL. Les plages avec des versions minimales ou maximales null (non liées) dans une plage de versions doivent être triées avant les versions non null (limitées).

Une page vide, qui ne fournit aucune vulnérabilité connue, doit être un tableau JSON vide ([]).

Samples

Voici un exemple d’index de vulnérabilité :

[
    {
        "@name": "base",
        "@id": "https://nuget.contoso.com/v3/vulnerabilities/3bb6b300-2f74-45bc-af06-746fd21c024b.json",
        "@updated": "2023-06-01T06:14:58.4159909Z",
        "comment": "The base data for vulnerability update periodically"
    },
    {
        "@name": "update",
        "@id": "https://nuget.contoso.com/v3/vulnerabilities/ffd572cd-33f3-4372-8714-a9cab2e86b45.json",
        "@updated": "2023-06-14T11:35:30.3155764Z",
        "comment": "The patch data for the vulnerability. Contains all the vulnerabilities since base was last updated."
    }
]

Voici un exemple de fichier de données de vulnérabilité :

{
    "contoso.library": [
        {
            "url": "https://cve.contoso.com/advisories/1",
            "severity": 1,
            "versions": "(, 2.0.0)"
        },
        {
            "url": "https://cve.contoso.com/advisories/2",
            "severity": 2,
            "versions": "(1.0.0, 2.0.0)"
        }
    ],
    "contoso.utilities": [
        {
            "url": "https://cve.contoso.com/advisories/3",
            "severity": 3,
            "versions": "(, 1.0.0)"
        }
    ]
}