Supply-Chain Security¶
Opencomplai ships official container images with cryptographic signatures and software bill of materials (SBOM) attestations. This page covers how the signatures are produced and how you can verify them before deploying.
How official images are signed¶
Every image published from this repository under ghcr.io/opencomplai/opencomplai/<service> is built, signed, and attested by the supply-chain.yml GitHub Actions workflow. The workflow runs on every version tag (v*.*.*) and on manual dispatch.
The signing uses cosign keyless mode, backed by the Sigstore public-good infrastructure (Rekor transparency log and Fulcio CA). No long-lived signing key is stored in CI. The signing identity is the workflow's OIDC token, scoped to the opencomplai/opencomplai repository and the supply-chain.yml workflow file.
The SBOM is generated by syft in SPDX-JSON format and attached to the image as a cosign in-toto attestation (--type spdxjson).
Verifying an image signature¶
The command exits 0 and prints the signing certificate when the signature is valid and the identity matches the expected workflow.
Verifying the SBOM attestation¶
Use the helper script bundled with the repository:
It runs both cosign verify and cosign verify-attestation and decodes the predicate name from the SBOM payload.
SBOM format¶
The SBOM is SPDX-JSON (SPDX 2.3). You can extract it from the attestation and pipe it into other tooling:
Scanning for known vulnerabilities¶
syft and grype compose cleanly:
CI runs an equivalent scan on every pull request via the vulnerability-scan job in ci-docker.yml. CRITICAL and HIGH fixable findings fail the build.
That job scans all five service images — gateway-api, risk-engine, evidence-vault, doc-generator and egress-proxy. It previously covered only gateway-api, so the other four were signed and SBOM'd at release but never CVE-scanned: an SBOM records what is in an image, it does not say the contents are safe.
The same scan now also runs as a release gate in supply-chain.yml, before the image is pushed or signed. Signing first would mean attesting an image nobody had checked.
Unfixable findings are excluded (ignore-unfixed). They cannot be acted on here, and a gate that cannot be made green is one people learn to route around.
Python packages¶
PyPI releases are published with Trusted Publishing (OIDC) — no API token and no long-lived secret. Every distribution carries two independent attestations:
- PEP 740 attestations, generated at upload and shown on the file's PyPI page.
- SLSA build provenance, attached to the same files and verifiable with:
Until this change the Python side was held to a weaker bar than the container side — signed images and SBOMs for what runs in a cluster, a static API token and no attestation at all for the artifacts every pip install actually pulls.