ossf / ossf/osv-schema

Release must include instructions for release author identity verification

Open
#481 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

security baseline
Dominant language
Go
Stars
271
Forks
129
Avg merge
3h 46m
Merged PRs (30d)
4

Description

Review and update OSV schema processes and/or documentation to ensure compliance with OpenSSF requirement OSPS-DO-03.02.

Requirement: When the project has made a release, the project documentation MUST contain instructions to verify the expected identity of the person or process authoring the software release.

Recommendation: The expected identity may be in the form of key IDs used to sign, issuer and identity from a sigstore certificate, or other similar forms. When possible, avoid storing this documentation in the same location as the build and release pipeline to avoid a single breach compromising both the software and the documentation for verifying the integrity of the software.

Control applies to: Maturity Level 3

External Framework Mappings
BPB: CC-B-8
CRA: 1.2d
SSDF: PO.4.2, PS.2, PS.2.1, PS.3.1, RV.1.3
OpenCRE: 171-222
PSSCRM: G1.3, G2.5, P1.2, P3.1, P3.2, P3.3, E2.6
PCIDSS: 3.1.1, 3.5.1, 4.1.1, 5.1.1, 6.1.1, 6.2.1, 7.1.1, 8.1.1, 11.1.1
UKSSCOP: 3.1
800-161: CM-2, IR-1, MP-1, SA-15, SI-7, SI-7(14)

https://baseline.openssf.org/versions/2025-10-10#osps-do-0302

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the OSPS-DO-03.02 requirement and the repository's existing release processes or documentation. Identify where release-author identity information is documented, then ensure the project provides verifiable identity instructions without relying solely on the build or release pipeline. Done means the documentation addresses the requirement and can be followed to verify a release author.

Written by the indexing model from the issue text.

Assessment

Domain
documentation, release, security
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.