Security Policy
Supported versions
Cargoship is pre-1.0 and releases from main on every conventional commit that warrants one, so fixes land in a new minor release rather than being backported. Only the most recent release line receives security fixes; upgrade before reporting an issue against an older tag.
| Version | Supported |
|---|---|
Latest v0.x release | Yes |
| Any earlier release | No |
Reporting a vulnerability
Report privately through GitHub: open a draft advisory. Do not open a public issue, and do not include a working exploit against a third party’s cluster.
You should expect an acknowledgement within 3 business days and an assessment – whether we consider it a vulnerability, and the severity we assign – within 10 business days. Confirmed issues are fixed in the next release, and we aim to publish the advisory within 90 days of the report, sooner when a fix is already out. You will be credited in the advisory unless you ask not to be.
Include the output of cargoship version, the host OS of the management node, the Kubernetes engine involved (K3s or RKE2), the commands that reproduce the behaviour, and what an attacker gains.
Scope
In scope: the cargoship CLI and the packages under the module root; package signing and the verification path (--verify, --key); credential handling in clustercfg, including the vault splice and age encryption; SSH orchestration against target hosts; and the release workflow and the artifacts it publishes.
Out of scope: vulnerabilities in K3s, RKE2, containerd, or any other upstream component Cargoship packages – report those to the project that owns them; anything that requires an attacker to already have root on the management node, which by design holds the cluster’s credentials; resource exhaustion from deliberately malformed or oversized packages supplied by the operator themselves; and misconfiguration of a user’s own cluster.
Verifying a release
Release archives, checksums.txt, and container images are signed with cosign using the key whose public half is cosign.pub in this repository, archives ship with an SBOM, and every tag also publishes ai-bom.json – the AI-usage disclosure manifest described below – attested and signed the same way.
cosign verify-blob --key cosign.pub --bundle checksums.txt.sigstore.json checksums.txt
cosign verify --key cosign.pub ghcr.io/colonel-byte/cargoship:<tag>
See the GoReleaser reference for the full set of published artifacts.
AI-assisted development
Cargoship’s code, docs, and design records are written with AI coding agents in the loop. See AI usage for what’s used and how it’s reviewed. Each release publishes ai-bom.json, a per-release snapshot of that disclosure – verify it the same way as the other release artifacts, above.
Security in CI
Pull requests and main are scanned by CodeQL, dependencies are updated by Dependabot, and supply-chain practices are scored weekly by OpenSSF Scorecard. Results appear in the repository’s Security tab. vendor/ costs points on a couple of Scorecard checks it can’t avoid given the repository’s need to build without network access; choice-osv-vendor-overrides and choice-binary-artifact-opa-wasm explain why.