Security

CloudRING is meant to run clouds that many tenants share, so security has to be part of how it's built. This page lists what's in place today, with links to the code that does it, and what isn't.

Checks on every change

• Static analysis. CodeQL scans the Go code in cmd, internal and pkg, and gosec runs alongside it. A gosec suppression needs a written justification and a named rule.
• Known vulnerabilities. govulncheck checks the source on every pull request and the compiled binaries before a release.
• Secrets. gitleaks scans the whole tree and every commit in each pull request and push, and GitHub secret scanning with push protection is on for the repository. A separate source-safety scanner checks every change for private material that doesn’t belong in the public repository.
• The pipeline itself. GitHub Actions are pinned to commit hashes, workflows are linted with actionlint and checked against a recorded policy, and jobs get only the token permissions they need.
• Dependencies. Dependabot proposes updates to Go modules and GitHub Actions every week, and Dependabot security updates are on.
• Contributions. Every contributor commit needs a DCO sign-off, and CI checks it. Commits from Dependabot and GitHub Actions are exempt.
• History. Changes reach main through pull requests. Force-pushes and deletions are blocked on the main branch and on version tags, and only the repository owner can bypass these rules.

Release integrity

• SBOMs. Releases ship CycloneDX software bills of materials.
• Build attestations. Release artifacts carry GitHub artifact attestations signed through Sigstore: build provenance in the SLSA format, and the SBOM.
• Reproducibility. The Linux release bundle and its SBOM are built twice with separate caches. If the two builds differ by a single byte, the release stops before anything is attested.
• Immutable releases. A published release can’t be changed, and version tags are protected.

Both releases so far, v0.1.0-c01.1 and v0.1.0-c02.1, are development prereleases. You can check them yourself with the GitHub CLI. After downloading cloudring-linux-amd64.tar.gz from a release:

gh release verify v0.1.0-c02.1 --repo opencloudtech/CloudRING
gh attestation verify cloudring-linux-amd64.tar.gz \
  --repo opencloudtech/CloudRING \
  --signer-workflow opencloudtech/CloudRING/.github/workflows/release-provenance.yml

Security in the platform design

• Tenant boundaries in IAM. Tests in pkg/iam check that a tenant can’t write outside its own project’s scopes and that denied attempts are audited.
• API tokens. Tokens are scoped, expiring and revocable, with tests in pkg/iam.
• Secrets. A contract and the cloudring-openbao tool bind workloads to OpenBao through Kubernetes authentication with least-privilege policies.
• Transport security. A read-only probe checks a CloudRING deployment’s HTTPS redirect, HSTS, Content Security Policy and TLS settings before the deployment is promoted.
• Fail-closed modules. The security policy requires platform validation to reject a module that leaves out required security behaviour or metadata.

Network and runtime isolation between tenants is roadmap goal G05, which hasn’t started.

AI in development

AI agents help write and review CloudRING’s code. Their changes go through the same pull requests and CI checks as anyone else’s, and the lead maintainer stays accountable for every change that’s accepted. AI tools also help review CloudRING’s code for security problems.

Planned before 1.0

• A published threat model and incident-response runbooks, as part of roadmap goal G27, the final security review before 1.0.
• Response-time targets and a list of supported releases for vulnerability reports.
• End-to-end evidence of network and runtime isolation between tenants (roadmap goal G05).

Not in place

• Independent review of the lead maintainer’s own changes. Today the maintainer accepts them after automated and AI-assisted review.
• An OpenSSF Scorecard result or an OpenSSF Best Practices badge.
• Detached cosign signatures on release artifacts, and container image and configuration scanning in the public CI.
• GitHub private vulnerability reporting. Reports go by email for now.

This website

This site is static HTML. It loads no third-party scripts, fonts, trackers or cookies, and it’s served with a strict Content Security Policy. Its security.txt follows RFC 9116.