Envoyer une version : SBOM ou fichiers de verrouillage

Chaque version d’un produit a sa propre nomenclature logicielle (SBOM). Provetry les garde toutes : vous pouvez toujours dire quelles versions en circulation contiennent un composant donné.

Ce que vous pouvez envoyer

• Un SBOM en CycloneDX ou SPDX (JSON), produit par votre build.
• Les fichiers de verrouillage des principaux gestionnaires de paquets (npm, pnpm, Yarn, Cargo, Poetry, uv, pip, Composer, Bundler, NuGet, Gradle, Maven…), avec le manifeste à côté, pour que Provetry distingue les dépendances directes des autres.

Étapes

1. Ouvrez le produit, puis Envoyer une version.
2. Saisissez le numéro de version et choisissez les fichiers.
3. Cliquez sur Envoyer et analyser. Les résultats apparaissent en moins d’une minute.

Provetry écrit le SBOM en CycloneDX 1.6 (toutes les offres) et en SPDX 2.3 et 3.0.1 (offres payantes) ; chacun se télécharge depuis la version. CycloneDX 1.6 et SPDX 3.0.1 sont les versions que demande le BSI allemand. Vous pouvez aussi envoyer un fichier SPDX 3 (JSON-LD).

Depuis un dépôt GitHub

Dans Importer depuis GitHub, indiquez l’adresse du dépôt, et si vous le souhaitez une branche ou un tag (sinon la branche par défaut) et la version (sinon les sept premiers caractères du commit). Provetry lit les fichiers de verrouillage de ce commit par l’API de GitHub, avec leurs manifestes, et laisse de côté les dossiers de dépendances embarquées, de tests et d’exemples. Rien ne change dans votre CI, et rien n’est cloné ni exécuté.

Pour un dépôt privé, indiquez un jeton à portée limitée (fine-grained), en lecture du contenu de ce seul dépôt. Il est envoyé à GitHub pour cet import et jamais conservé. Le dépôt et le commit sont inscrits au journal de preuves avec la version.

Versions maintenues

Chaque version marquée maintenue est vérifiée chaque jour (chaque semaine avec l’offre gratuite). Avec les offres payantes, elle est aussi revérifiée dans l’heure quand OSV.dev publie ou met à jour une vulnérabilité de l’un de ses paquets, et les listes de vulnérabilités exploitées sont aussi relues régulièrement (CISA KEV toutes les heures, EUVD de l’ENISA toutes les six heures) : une vulnérabilité déjà trouvée dans une version est en général signalée comme exploitée dans l’heure qui suit son inscription au KEV, dans les six heures pour une entrée recensée seulement par l’EUVD. Quand une version n’est plus en circulation, cliquez sur Plus maintenue : elle garde son historique mais n’est plus surveillée.

Si une source de vulnérabilités n’a pas répondu pendant une vérification, la version indique que le résultat est incomplet, et la vérification suivante le complète.