Envoyer les versions depuis votre CI

Le SBOM le plus sûr est celui qu’on établit là où la version est construite. Le cœur open source de Provetry, provetry-core, fournit une action GitHub et un modèle GitLab qui établissent le SBOM à chaque étiquette et l’envoient à votre espace.

1. Dans Réglages, créez une clé d’API (propriétaires et administrateurs). Copiez-la : elle n’est affichée qu’une fois.
2. Enregistrez-la dans votre CI comme secret nommé PROVETRY_API_KEY, avec l’identifiant du produit dans PROVETRY_PRODUCT_ID (affiché sur la page du produit).
3. Ajoutez l’action (GitHub) ou incluez le modèle (GitLab), comme le décrit le README du cœur.
4. Poussez une étiquette : la version apparaît dans Provetry avec son SBOM, et la vérification des vulnérabilités se lance.

À chaque version, ou à chaque commit ?

Le Cyber Resilience Act regarde ce que vous mettez sur le marché : les versions qu’utilisent vos clients. C’est pourquoi l’action et le modèle envoient le SBOM à chaque étiquette, une version par version publiée. Gardez ce réglage si vous le pouvez : chaque SBOM correspond alors à une version en circulation, avec ses vulnérabilités, ses évaluations et ses preuves.

Certains produits sont livrés à chaque commit (livraison continue, version nocturne installée par les utilisateurs). Sur GitHub, l’action peut alors envoyer le SBOM à chaque passage : réglez son entrée upload sur always. Chaque passage devient une version nommée d’après les douze premiers caractères du commit.

• Chaque version envoyée ainsi est surveillée comme les autres, et compte dans le nombre de versions par produit de votre offre (50 avec Starter, 200 avec Pro et Consultant). Une fois la limite atteinte, les nouveaux envois sont refusés et la tâche de CI échoue : supprimez régulièrement les anciennes (une version marquée Plus maintenue n’est plus surveillée, mais elle compte toujours). Les envois sont aussi limités à 100 par jour et par produit.
• Limitez-le à la branche d’où vous livrez (if: github.ref == 'refs/heads/main' sur l’étape), pas à chaque demande de fusion.
• Le modèle GitLab n’envoie qu’à chaque étiquette.

Images de conteneur et micrologiciels

Pour un produit livré en image de conteneur, donnez à l’entrée image de l’action le nom de l’image (téléchargée si besoin, puis enregistrée avec docker save) ou une archive d’image ; pour une image multiplateforme, l’entrée platform en choisit une (linux/arm64 ; par défaut linux/amd64). Pour un appareil, indiquez l’archive du système de fichiers racine produite par votre build (rootfs.tar.gz de Yocto, Buildroot ou debootstrap). Provetry lit, couche par couche et sans rien exécuter, les paquets du système (dpkg, apk, opkg), les paquets Python et Node.js installés et les fichiers de verrouillage présents. Les paquets Debian, Ubuntu et Alpine sont recherchés selon leur version de distribution, ceux de Wolfi et Chainguard tels quels ; ceux d’une distribution dérivée (Raspberry Pi OS, Linux Mint) seulement de façon approchée, comme la version qu’elle suit. Certains paquets ne sont pas recherchés : les bases RPM ne sont pas lues, et les paquets opkg, comme ceux d’une version qu’aucune base publique d’avis ne couvre (Debian testing, Alpine edge), sont listés mais pas recherchés. Le SBOM le signale, et la version dans Provetry indique que certains composants ne sont pas surveillés. Avec image-tool: syft, c’est Syft qui produit le SBOM : il liste aussi les paquets RPM, les archives Java et les binaires Go, mais les paquets RPM ne sont pas recherchés pour autant. Avec image, l’analyse d’atteignabilité n’est pas faite (elle lit le code source, pas les images). Le modèle GitLab ne lit pas encore les images.

Aussi depuis la CI

• Atteignabilité : la même étape lance provetry reach et envoie ce qu’elle trouve sur l’usage du code vulnérable. Voir Atteignabilité.
• Faire échouer le pipeline : réglez PROVETRY_FAIL_ON pour faire échouer un build qui livre une vulnérabilité dont l’outil prouve qu’elle est appelée.

L’envoi par l’API demande une offre payante. Les clés se révoquent à tout moment dans Réglages.