Skip to main content
Each released engine and first-party plugin image has a signed inventory of its software components, called a software bill of materials (SBOM). Verify the image and its inventory before deploying a digest from a GitHub release.

​
Find the inventory

The release’s images.txt lists immutable image digests. Its quivr.spdx.json describes the engine; quivr-plugin-<id>.spdx.json describes each plugin using its manifest id. These SPDX JSON files are generated by Syft from the published images and attached to the same release. A cosign attestation binds each inventory to its image digest and the release workflow’s GitHub identity. Older releases may predate these inventories. If SBOM assets are missing, choose a newer release that includes them. Download the matching file for your image from the release assets. The separate dependency-inventory.json produced by make verify covers evaluation services, model provenance and notices; it remains available alongside verification reports and is not the release SBOM.

​
Verify an image and its inventory

Install cosign and jq. Copy the version and engine or plugin digest from the same release. You need network access to GHCR and Sigstore’s verification services. The commands below are illustrative and were not run against a published release; replace the placeholders with values from one release:
Successful verification checks the image digest, GitHub’s OIDC issuer and the exact workflow/tag identity. The final file contains the signed inventory. Use it as the authenticated source; a release asset alone does not verify a signature. Stop deployment if either cosign command fails. Remove the two local JSON files when you no longer need them. A signature proves who published these bytes and that they have not changed. It does not prove the software is free of vulnerabilities. Use a verified digest when deploying Quivr; latest-alpha changes over time.

​
Vulnerability checks

Every pull request runs govulncheck across all Go modules to detect known vulnerabilities reachable from Go code. The required verify check includes this scan. Releases scan every engine and first-party plugin image with Grype before signing, attesting and promoting release tags. A critical vulnerability with an available fix fails publication; lower severities and findings without a fix do not block it. The nightly Release vulnerability scan workflow rescans every digest in the newest completed alpha image release with an updated vulnerability database. Its failure flags the release for maintainers; it does not remove previously published images. Before the first completed image release, it reports that there is nothing to scan. Release and nightly workflow artifacts retain JSON scan reports of findings with available fixes, including lower severities. Dependabot proposes grouped dependency updates weekly for Go, Python, npm and GitHub Actions. Maintainers review and merge those pull requests. Scanners can miss components or vulnerabilities absent from their databases; external services, plugins you supply, and deployment configuration need their own checks. These checks make no license-policy or compliance claim.

​
Report a vulnerability

Follow SECURITY.md to send a private report with the affected version, digest and reproduction steps. Security fixes target the newest alpha release; older alpha releases are not maintained.

​
Next