Each scheduled or exceptional public release candidate uses one permanent report:
security/pentest/vX.Y.Z[-rc.N].md
Ordinary tagged development milestones between checkpoints have no scheduled report and do not publish to crates.io. An exceptional assessment may create a report without converting that milestone into a public release.
The report is updated throughout pentest and remediation. It is committed together with the final implementation state. If GitHub CI later requires any change, that change and the corresponding report update are committed together and CI is allowed to run again. The release tag is created only after the user confirms that GitHub is green.
Use these required machine-readable fields:
Version: vX.Y.Z
Baseline: vA.B.C
Status: PASS
Open-Findings: 0
Retest: PASS
Date: YYYY-MM-DD
Tester: name or accountable identity
Scope: Cumulative changes after vA.B.C through the vX.Y.Z candidate.
While a remediated candidate awaits external retest, ordinary CI also accepts this exact non-release state:
Status: RETEST REQUIRED
Open-Findings: 0
Retest: PENDING
The report must still be a regular file, committed at HEAD, updated with
every repository-changing commit, complete, and internally consistent.
Release and tag gates do not accept the pending state; they require the
PASS/PASS fields above.
For every post-v0.10 scheduled or exceptional checkpoint, Baseline must equal
the preceding public tag and Scope must name both ends of the reviewed range.
For example, v0.15.0 uses Baseline: v0.10.0 and covers changes after v0.10.0
through v0.15.0; v0.20.0 uses Baseline: v0.15.0. Patch and minor development
tags inside the range are included automatically and do not shift the next
five-minor checkpoint.
The body records the tested areas, methods, findings, remediation, retest
results, limitations, and residual risks. When no issue is found, say so
explicitly under ## Findings. When issues are found, retain a safe history of
the finding and remediation and set PASS only after clean retest with zero open
findings.
Commit subjects must follow
SECURITY.md#security-change-classification.
Closing a pentest finding does not authorize fix: or pentest-code wording
when the commit changes only documentation, policy, evidence, tests, or
tooling.
Do not commit exploit details, secrets, private test infrastructure, or information that would expose an unremediated vulnerability. Keep sensitive working notes private until disclosure is safe.