Provetry startet im November 2026. Der kostenlose CRA-Check, die Werkzeuge und die Leitfäden sind schon jetzt verfügbar.

Versionen aus Ihrer CI senden

Die GitHub-Action und die GitLab-Vorlage: eine SBOM bei jedem Tag, automatisch gesendet.

Die verlässlichste SBOM ist die, die dort entsteht, wo die Version gebaut wird. Der Open-Source-Kern von Provetry, provetry-core, bringt eine GitHub-Action und eine GitLab-Vorlage mit, die bei jedem Tag die SBOM erstellen und an Ihren Arbeitsbereich senden.

  1. Legen Sie unter Einstellungen einen API-Schlüssel an (Inhaber und Admins). Kopieren Sie ihn: Er wird nur einmal angezeigt.
  2. Speichern Sie ihn in Ihrer CI als Secret namens PROVETRY_API_KEY, mit der Kennung des Produkts als PROVETRY_PRODUCT_ID (auf der Produktseite angezeigt).
  3. Fügen Sie die Action (GitHub) hinzu oder binden Sie die Vorlage (GitLab) ein, wie im README des Kerns beschrieben.
  4. Pushen Sie einen Tag: Die Version erscheint mit ihrer SBOM in Provetry, und die Schwachstellenprüfung läuft.

Bei jeder Version oder bei jedem Commit?

Die Cyberresilienz-Verordnung betrachtet, was Sie in Verkehr bringen: die Versionen, die Ihre Nutzer einsetzen. Deshalb senden Action und Vorlage die SBOM bei jedem Tag, eine Version pro veröffentlichtem Stand. Behalten Sie das nach Möglichkeit bei: Jede SBOM entspricht dann einer Version im Feld, und ihre Schwachstellen, Bewertungen und Nachweise bleiben daran gebunden.

Manche Produkte werden aus jedem Commit ausgeliefert (Continuous Delivery, ein nächtlicher Build, den Nutzer installieren). Auf GitHub kann die Action die SBOM dann bei jedem Lauf senden: Setzen Sie ihre Eingabe upload auf always. Jeder Lauf wird zu einer Version, benannt nach den ersten zwölf Zeichen des Commits.

  • Jede so gesendete Version wird wie die anderen überwacht und zählt zu den Versionen pro Produkt Ihres Tarifs (50 bei Starter, 200 bei Pro und Consultant). Ist die Grenze erreicht, werden neue Uploads abgelehnt und der CI-Job schlägt fehl: Löschen Sie die alten regelmäßig (eine als Nicht mehr unterstützt markierte Version wird nicht mehr überwacht, zählt aber weiterhin). Uploads sind außerdem auf 100 pro Tag und Produkt begrenzt.
  • Beschränken Sie es auf den Branch, aus dem Sie ausliefern (if: github.ref == 'refs/heads/main' am Schritt), nicht auf jeden Pull Request.
  • Die GitLab-Vorlage sendet nur bei jedem Tag.

Container-Images und Firmware

Für ein Produkt, das als Container-Image ausgeliefert wird, setzen Sie die Eingabe image der Action auf den Image-Namen (bei Bedarf heruntergeladen, dann mit docker save gespeichert) oder auf ein Image-Archiv; bei einem Multi-Plattform-Image wählt die Eingabe platform eine Plattform aus (linux/arm64; Standard linux/amd64). Für ein Gerät geben Sie das Archiv des Root-Dateisystems an, das Ihr Build erzeugt (rootfs.tar.gz aus Yocto, Buildroot oder debootstrap). Provetry liest Schicht für Schicht und ohne etwas auszuführen die Pakete des Betriebssystems (dpkg, apk, opkg), die installierten Python- und Node.js-Pakete und die vorhandenen Lock-Dateien. Debian-, Ubuntu- und Alpine-Pakete werden nach Distributionsversion abgeglichen, Wolfi- und Chainguard-Pakete als solche; die einer abgeleiteten Distribution (Raspberry Pi OS, Linux Mint) nur näherungsweise, als die Version, der sie folgt. Manche Pakete werden nicht abgeglichen: RPM-Datenbanken werden nicht gelesen, und opkg-Pakete werden wie die Pakete einer Distributionsversion, die keine öffentliche Advisory-Datenbank abdeckt (Debian testing, Alpine edge), aufgelistet, aber nicht abgeglichen. Die SBOM vermerkt das, und die Version in Provetry zeigt an, dass einige Komponenten nicht überwacht werden. Mit image-tool: syft erzeugt Syft die SBOM: Es listet auch RPM-Pakete, Java-Archive und Go-Binaries auf, doch RPM-Pakete werden trotzdem nicht abgeglichen. Mit image entfällt die Erreichbarkeitsanalyse (sie liest Quellcode, keine Images). Die GitLab-Vorlage liest noch keine Images.

Ebenfalls aus der CI

  • Erreichbarkeit: Derselbe Schritt führt provetry reach aus und sendet, was er über die Nutzung verwundbaren Codes findet. Siehe Erreichbarkeit.
  • Die Pipeline fehlschlagen lassen: Setzen Sie PROVETRY_FAIL_ON, damit ein Build fehlschlägt, der eine Schwachstelle ausliefert, deren Aufruf das Werkzeug nachweist.

Uploads über die API erfordern einen kostenpflichtigen Tarif. Schlüssel lassen sich jederzeit unter Einstellungen widerrufen.

Weiterhin Fragen? Schreiben Sie uns an hello@provetry.com.