How Kubemoot Is Built and Secured

How changes are made, how versions and releases work, how the supply chain is protected, how the code is checked, and how the settings are managed, with a link to the evidence for each point.

This page describes how the project builds, releases, and protects its software, and where you can see each practice for yourself. It follows the OpenSSF Best Practices criteria for open-source projects. The per-criterion answers live on the project’s Best Practices entry; this page explains the practices in plain words and links to the files, workflows, and pages that show them.

How changes are made

Pull requests from forks. Contributors fork a repository, branch off main, and open a pull request using the template. A maintainer review and approval is required to merge. See Contributing and Governance.
Conventional Commits. Every commit message carries a prefix such as fix: or feat:, and the prefix decides the version bump. See Contributing.
Developer Certificate of Origin. Every commit is signed off, and a pull request check named “DCO” verifies it (workflow). There is no contributor license agreement. See Contributing.
Tests ship with the change. A new feature comes with tests, and a bug fix comes with a test that fails without the fix. The pull request template has a checklist item for it (template). See Contributing.
AI-assisted work is visible. Agent-authored commits use the Klaude identity and name the model in a Co-Authored-By: trailer, and they pass the same gates as every other change. See Contributing.
License. Every repository is Apache License 2.0, for example the LICENSE of kubemoot.

How versions and releases work

Versions live only in git tags. Files in git hold 0.0.0; every build computes its version from the tags and stamps it into what it publishes, and CI never commits a version back. See The version rule.
Every merge to main builds a release candidate. Candidates are tagged X.Y.Z-rc.N and are not published publicly. See From merge to release.
A maintainer publishes a candidate. The Publish Release workflow starts as a dry run that publishes nothing, then runs again with approval. It copies the exact tested images by digest rather than rebuilding them (workflow).
Releases are immutable. A published version is never rewritten; a fix ships as the next version.
Release notes list what users see. Breaking changes, new features, fixes, and speedups, with a link to every commit. See Release notes and the releases of kubemoot.
One shared pipeline. Every repository uses the same pinned actions from kubemoot/release-actions, so the logic is not copied from repository to repository.
No stored registry tokens for CrewForge. The extension is published to the VS Code Marketplace and Open VSX only from the Publish Release workflow, in a protected environment that waits for maintainer approval, using federated sign-in instead of a stored token. See CrewForge.

How the supply chain is protected

Dependencies are pinned by digest. Container base images and GitHub Actions reference an immutable digest or commit, not a movable tag. The default workflow token is read-only, and a job that needs more asks for it.
Dependabot proposes updates to dependencies and Actions in every repository (configuration).
Signatures and provenance. kmctl and CrewForge releases carry a keyless Sigstore signature and SLSA build provenance. Every container image and Helm chart published to GHCR carries both from the next release on. No signing key is stored; the certificate is issued to the release workflow’s identity. You can check any of them yourself with the commands in Verify images and charts.
Secret scanning with push protection is on for every public repository and blocks a push that contains a known credential format.

How the code is checked

Tests run in CI on every pull request and every push to main, and the quickstart runs against each release’s published chart. The Development Guide lists the command for each component.
Linters run in CI for every language and block a merge on any finding: golangci-lint for each Go module, Checkstyle for the Java services, ESLint and svelte-check for the dashboard and CrewForge, ruff for Python, and ShellCheck for scripts, with a cyclomatic complexity limit of 10. A false positive is suppressed on its line with the reason. See Linters and warnings.
CodeQL scans every repository on every pull request, every push to main, and weekly. Every alert it has raised was fixed.
SonarQube applies a quality gate on every push to main in the code repositories (workflow).
Fuzz tests. Every Go native fuzz target in the operator runs on each operator change (workflow). Fuzzing has found real parser bugs, and each failing input is kept as a regression seed beside its fix.
OpenSSF Scorecard runs on every push to main and weekly, and the results are public (workflow).

The same checks are summarized on Security.

How vulnerabilities are reported

Report a vulnerability privately through GitHub private vulnerability reporting or security@kubemoot.org, never in a public issue. The steps, the supported versions, and the security model with its known limitations are on the Security page, and each repository carries a SECURITY.md with the same instructions.

Settings are code

The settings that protect the project are managed as code in OpenTofu, not by hand in a web console: GitHub organization and repository settings, DNS, project mail routing, CodeQL setup, and private vulnerability reporting. A settings change is therefore a reviewed commit, and a drifted setting is corrected by the next apply. This configuration lives in a maintainer-only repository.