Skip to content

Independent Security Review Process

CYPT71 edited this page Aug 9, 2026 · 1 revision

Independent security review process

This process is a release gate for production adoption. A review is independent only when the reviewer did not author the assessed changes and is not the person approving their release.

Review input

The release owner provides:

  • the immutable 40-character source SHA and intended SemVer tag;
  • all required GitHub checks on that exact SHA;
  • the architecture decisions and threat model;
  • the verified amd64 and arm64 OCI layouts;
  • SBOM, provenance, vulnerability, compatibility, benchmark, admission and MicroVM evidence;
  • the target installation and rollback report;
  • every open security finding and prior risk acceptance.

The reviewer stops if the SHA changes, evidence is missing, or the worktree is dirty. A new SHA requires a new decision.

Required review

The reviewer independently checks:

  1. OCI descriptor, layer and platform validation.
  2. Reproducibility claims and their documented boundary.
  3. Runtime isolation: non-root, read-only, dropped capabilities, no-new-privileges, network and resource limits.
  4. SBOM and vulnerability coverage, including native system libraries.
  5. Signature, provenance and Kubernetes admission identities.
  6. Branch, tag and protected release-environment controls.
  7. Installation, health verification and rollback in the target environment.
  8. Residual risks and all experimental functionality.

Findings and decision

Each finding records an identifier, severity, affected SHA/component, evidence, remediation, owner and due date. Critical and high findings block release unless an accountable production risk owner explicitly accepts them in writing with an expiry date.

The final review record contains:

reviewed_sha:
reviewed_tag:
reviewer_name:
reviewer_organization:
independence_statement:
review_date:
evidence_links:
findings:
residual_risks:
decision: approve | approve-with-conditions | reject
signature_or_auditable_approval_link:

The record is stored in the release evidence and linked from the GitHub release. Maintainers may prepare evidence and remediate findings, but must not fill in the reviewer identity or approval on the reviewer's behalf.

Clone this wiki locally