Release Compliance Checklist¶

Copy this checklist into the release pull request or other durable release approval record. Mark non-applicable items N/A with a reason. A required item may not be silently omitted.

Release identity¶

Release/tag:
Commit:
Container/package digest:
Release owner:
Reviewer:
Date:

Scope and component record¶

[ ] Release contents are inside the approved program scope.
[ ] Dependency manifests, locks, Dockerfiles, and workflow references match the release.
[ ] New or changed open source components have a recorded source, version, license, intended use, and approval.
[ ] The component inventory/SBOM and provenance are generated and tied to the released digest.

License compliance¶

[ ] REUSE lint passes on the release commit.
[ ] License obligations, compatibility, interaction, and attribution were reviewed for changed components.
[ ] Modified or vendored components retain required notices and markings.
[ ] Required license texts, notices, attributions, source/source offer, and installation information are delivered with or alongside the release.
[ ] Any legal question is resolved by the legal expertise function.
[ ] Compliance artifacts and the approval record are archived.

Security assurance¶

[ ] Required test and security workflows pass.
[ ] Known vulnerability monitoring results were reviewed.
[ ] No unmitigated exploitable medium-or-higher vulnerability is known.
[ ] Every accepted residual risk has an owner, rationale, compensating control, review date, and Project Lead approval.
[ ] Security, upgrade, or disclosure guidance is included when warranted.
[ ] Artifact provenance and signature verification information are available.

Approval¶

[ ] Release owner confirms the evidence is complete.
[ ] Reviewer confirms the release satisfies the program or records why it is blocked.
[ ] Project Lead approves any exception or material residual risk.