Send releases from your CI

The surest SBOM is the one built where the release is built. Provetry’s open-source core, provetry-core, comes with a GitHub action and a GitLab template that build the SBOM at every tag and send it to your workspace.

1. In Settings, create an API key (owners and admins). Copy it: it is shown only once.
2. Store it in your CI as a secret named PROVETRY_API_KEY, with the product’s identifier as PROVETRY_PRODUCT_ID (shown on the product page).
3. Add the action (GitHub) or include the template (GitLab), as described in the core’s README.
4. Push a tag: the release appears in Provetry with its SBOM, and the vulnerability check runs.

At each release, or at each commit?

The Cyber Resilience Act looks at what you place on the market: the versions your users run. That is why the action and the template send the SBOM at each tag, one release per published version. Keep it that way if you can: each SBOM then matches a version in the field, and its vulnerabilities, assessments and evidence stay attached to it.

Some products ship from every commit (continuous delivery, a nightly build users install). On GitHub, the action can then send the SBOM at every run: set its upload input to always. Each run becomes a release named after the first twelve characters of the commit.

• Every release sent this way is watched like the others, and counts in your plan’s releases per product (50 on Starter, 200 on Pro and Consultant). Once the limit is reached, new uploads are refused and the CI job fails: delete the old ones regularly (marking a release No longer supported stops its watch, but it still counts). Uploads are also limited to 100 a day per product.
• Limit it to the branch you deliver from (if: github.ref == 'refs/heads/main' on the step), not to every pull request.
• The GitLab template sends at each tag only.

Container images and firmware

For a product shipped as a container image, set the action’s image input to the image name (it is pulled if needed, then saved with docker save) or to an image archive; for a multi-platform image, the platform input picks one (linux/arm64; default linux/amd64). For a device, point it to the root filesystem archive your build produces (rootfs.tar.gz from Yocto, Buildroot or debootstrap). Provetry reads, layer by layer and without running anything, the operating system’s packages (dpkg, apk, opkg), the Python and Node.js packages installed and the lock files present. Debian, Ubuntu and Alpine packages are looked up by release, Wolfi and Chainguard packages as such; a derivative distribution (Raspberry Pi OS, Linux Mint) only approximately, as the release it follows. Some packages are not looked up: RPM databases are not read, and opkg packages, like those of a release no public advisory database covers (Debian testing, Alpine edge), are listed but not looked up. The SBOM says so, and the release in Provetry shows that some components are not watched. With image-tool: syft, Syft generates the SBOM instead: it also lists RPM packages, Java archives and Go binaries, but RPM packages are not looked up either. With image, reachability is skipped (it reads source code, not images). The GitLab template does not read images yet.

Also from CI

• Reachability: the same step runs provetry reach and sends what it finds about the use of vulnerable code. See Reachability.
• Failing the pipeline: set PROVETRY_FAIL_ON to fail a build that ships a vulnerability the tool proves is called.

API uploads require a paid plan. Keys can be revoked at any time in Settings.