Skip to content

📖 doc: add security disclosure policy to release process #653

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
zyzzmohit wants to merge 2 commits into
base: main
Choose a base branch
from
+10 −3
Open

📖 doc: add security disclosure policy to release process #653

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
abe66cd
doc: clarify kubestellar repo context for GHA scripts
zyzzmohit Jan 14, 2026
e90c8ed
doc: add security disclosure policy to release process
zyzzmohit Jan 14, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions docs/content/contribution-guidelines/operations/github-actions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,13 +2,16 @@

For the sake of supply chain security, every reference from a workflow to an action identifies the action's version by a commit hash rather than a tag or branch name. This ensures reproducibility and prevents supply chain attacks through action tampering.

> [!NOTE]
> These instructions apply to the main [kubestellar/kubestellar](https://github.com/kubestellar/kubestellar) repository. The scripts and files mentioned below are located in the root of that repository.

## The Reversemap File

The file `.gha-reversemap.yml` in the root of the repository is the single source of truth for the mapping from action identity (owner/repo and version tag) to commit hash. This file should only be updated when you have confidence in the new or added version.
The file `.gha-reversemap.yml` in the root of the `kubestellar` repository is the single source of truth for the mapping from action identity (owner/repo and version tag) to commit hash. This file should only be updated when you have confidence in the new or added version.

## Managing Action References

The script `hack/gha-reversemap.sh` provides commands for managing GitHub Action references across workflows.
The script `hack/gha-reversemap.sh` (in the `kubestellar` repository) provides commands for managing GitHub Action references across workflows.

### Available Commands

Expand Down
6 changes: 5 additions & 1 deletion docs/content/direct/release.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -56,7 +56,7 @@ Making a new kubestellar release requires a contributor to do the following thin

- Until we have our first stable release, edit the old docs README(`oldocs/README.md`, section "latest-stable-release") where it wishes it could cite a stable release but instead cites the latest release, to refer to the coming release.

- Edit the release notes in `docs/content/direct/release-notes.md`.
- Edit the release notes in `docs/content/direct/release-notes.md`. **Crucial:** You must explicitly disclose any fixed CVEs or security vulnerabilities in the release notes.

- Make a new Git commit with those changes and get it into the right branch in the shared repo (through the regular PR process if not authorized to cheat).

Expand Down Expand Up @@ -144,6 +144,10 @@ Right after making a release we test it thoroughly.

We plan a few deliberately feature-incomplete releases. They will be regular releases as far as the technology here is concerned. They will be announced only to selected users who acknowledge that they are getting something that is incomplete. In GitHub, these will be marked as "pre-releases". The status of these releases will be made clear in their documentation (which currently appears in [the release notes](release-notes.md).

### Security Disclosure

All releases must explicitly list any security vulnerabilities (CVEs) addressed in that release. If a release fixes a vulnerability, the release notes must describe it and provide the CVE identifier (if available) or a description of the security impact. This ensures compliance with OpenSSF Best Practices.

### Website

We aim to keep the documents viewable both through the website and GitHub's web UI for viewing files. We aim for all of the documentation to be reachable on the website and in the GitHub file UI starting from the repository's README.md.
Expand Down
Loading