> For the complete documentation index, see [llms.txt](https://docs.algenta.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.algenta.ai/trust-and-security/supply-chain.md). # Supply chain What's verifiable about an Algenta release today — SBOMs and a vulnerability scan per image — and what isn't yet, stated as plainly as what is. ## What exists today Every release build (API, worker, and engine images) runs through the same step in CI, against the exact image just pushed, referenced **by digest** rather than by a tag like `latest` — a tag can move between the push and the scan; a digest cannot. | Artifact | Format | Generated by | | -------------------- | ----------------------------------- | ----------------------------- | | SBOM | SPDX (`*-sbom.spdx.json`) | `anchore/sbom-action` | | SBOM | CycloneDX (`*-sbom.cyclonedx.json`) | `anchore/sbom-action` | | Vulnerability report | JSON (`*-vulnerabilities.json`) | `anchore/scan-action` (Grype) | All three are uploaded as GitHub Actions workflow artifacts (90-day retention) for every image, on every push to `main`. ```bash syft /@ -o spdx-json syft /@ -o cyclonedx-json grype /@ -o json ``` ## Why the scan is advisory, not a release gate Every image has known CVEs in its base OS packages the day it's built — that's normal, not a defect specific to this project — and turning that into a hard release-blocking gate on day one would either block every release or get disabled at the first false positive. The scan makes the finding visible and diffable release-over-release; making specific severities blocking is a deliberate follow-up, done once there's a triaged baseline to ratchet against — the same pattern this repository already applies to its own internal reliability guards. ## What does not exist yet Stated directly, because a partner evaluating this page will check: | Control | Status | | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Image signing (cosign) | **Not built.** A signing key is a permanent trust anchor the moment any customer starts verifying against its public half — rotating it later is disruptive in a way that adding a new SBOM format isn't. Which key-custody model (and whether keyless signing is acceptable given air-gapped customers can't reach Rekor/Fulcio) is an owner decision, tracked separately from the scan-and-report step above. | | Helm chart signing / OCI provenance | **Not built.** Blocked on the same decision, and on the chart itself merging (see [Capability status](/trust-and-security/capability-status.md)). | | SLSA / in-toto provenance attestation | **Not built.** | | VEX statements for triaged/accepted findings | **Not built.** The vulnerability report above is raw scanner output; nothing has been triaged into "known, accepted, not exploitable in this configuration" yet. | | Reproducible-build verification | **Not built.** | Do not describe a release as "signed" or "provenance-attested" until the corresponding row above changes — this page will be updated in the same change that ships the control, not ahead of it. ## Dependency lockfiles Python dependencies are pinned via lockfiles committed to this repository; the Python and TypeScript SDKs are published from tagged releases through a Trusted-Publishing OIDC pipeline with no long-lived registry tokens to leak — see the [SDK repository](https://github.com/thyn-ai/algenta-sdk) for that pipeline's own detail, which is out of this repository's scope to restate. ## Next steps * [Capability status](/trust-and-security/capability-status.md) * [Security questionnaire](/trust-and-security/security-questionnaire.md) * [Audit and evidence](/trust-and-security/audit-and-evidence.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.algenta.ai/trust-and-security/supply-chain.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.