diff --git a/docs/content/contribution-guidelines/operations/github-actions.md b/docs/content/contribution-guidelines/operations/github-actions.md
index c00f4488..884f4afc 100644
--- a/docs/content/contribution-guidelines/operations/github-actions.md
+++ b/docs/content/contribution-guidelines/operations/github-actions.md
@@ -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
 
diff --git a/docs/content/direct/release.md b/docs/content/direct/release.md
index 8875af7e..c6252892 100644
--- a/docs/content/direct/release.md
+++ b/docs/content/direct/release.md
@@ -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).
 
@@ -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.