Skip to main content
Version: MVP

Security Release Process

3 min readFor maintainersUpdated 2026-05-19

What you'll find here

The same package gates as a normal release, with private coordination before disclosure. Use this when responding to a vulnerability report or any security-sensitive fix.

Patch first, disclose second.

No exploit details in public issues, PR titles, changelog drafts, or generated docs until patched artifacts are available.

Security Patch Flow

  1. Triage the report privately and record the impacted versions.
  2. Open a private fix branch or security advisory branch.
  3. Add regression tests that fail without the fix.
  4. Run quality, package, docs, and security checks.
  5. Publish the smallest viable 0.x.y patch release.
  6. Publish advisory details after patched artifacts are available.

Private Coordination

No public exploit details before patched packages are available.

Use GitHub Security Advisories or a private maintainer channel for coordination. Avoid leaking impacted-version detail in public-facing PR titles or commit messages.

Release notes

Security release notes must state:

Affected versions

Fixed version

Severity and impact

In user terms — not internal jargon.

Mitigation

For users who cannot upgrade immediately.

Exposure scope

Whether secrets · receipts · local state · provider calls · or memory writes may have been exposed.

Disclosure

Disclosure happens only after every gate below is green.

  1. The patch release is published to PyPI.
  2. GitHub release notes are live.
  3. The changelog is updated.
  4. Any required advisory or CVE entry is ready.

Post-Release Verification

  1. Install the patched package from PyPI in a clean environment.
  2. Run the relevant regression tests or smoke workflow.
  3. Confirm that docs and release notes point to the fixed version.
  4. Verify the signed tag with git tag -v vX.Y.Z.
  5. Confirm the GitHub Release includes craik-release-signing-key.asc and that its fingerprint matches the tag-signing key.

What's next