# OSS Project Security Baseline Self-Assessment: [Project name]

> Self-assessment for maintainers of an open-source project against the OpenSSF Open Source Project
> Security Baseline (OSPS Baseline) release v2026.08.28, which groups security requirements into
> eight control families and three maturity levels. Automated evidence comes from OpenSSF Scorecard
> (v5.6.0, October 2026). Requirement IDs and control short names are cited from the OSPS Baseline
> with attribution; the "what must be true" column is an original paraphrase, so read the official
> requirement text and recommendations before you mark a requirement as met. Replace every
> `[bracketed]` value and every row marked *Example*. The worked example assesses corvid-sdk, a
> fictional Apache-2.0 client library maintained by Corvid Commerce, a fictional SaaS company.

<!--
Guidance: How to use this template
- Assess one project (one or more repositories released together). Choose the target maturity level
  first (section 1.2): Level 1 applies to every project, Levels 2 and 3 add requirements for
  projects with more maintainers and users.
- Run Scorecard before the workshop, then walk through every requirement with at least two
  maintainers. Scorecard covers only part of the Baseline; most documentation and policy
  requirements need a human to check them.
- Mark a requirement Met only with evidence a stranger could verify: a URL, a setting screenshot, a
  workflow file. "We always do this" is Partially met until it is written down or enforced.
- Common pitfall: chasing the Scorecard aggregate number. Fix the requirements your target level
  needs, in risk order, and let the score follow.
-->

## Document control

<!-- Guidance: The assessment belongs to the project, not to one maintainer. Record which release it describes, because results change with each release. -->

| Field | Value |
|---|---|
| Document ID | [OSPS-SA-CORVIDSDK-2026-01] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@lead-maintainer] |
| Approvers / reviewers | [@maintainer-2], [@ospo-lead], [@product-security-reviewer] |
| Last updated | YYYY-MM-DD |
| Classification | [Public] |
| Project | [corvid-sdk] |
| Repositories in scope | [*Example:* github.com/corvid-example/corvid-sdk] |
| Release assessed | [*Example:* 3.2.1] |
| OSPS Baseline release | v2026.08.28 |
| Scorecard version and run date | [*Example:* v5.6.0, YYYY-MM-DD] |
| Target maturity level | [*Example:* Level 2 by release 3.4] |
| Next assessment | YYYY-MM-DD (each minor release or every 6 months, whichever is sooner) |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Lead maintainer | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Second maintainer | [@name] | [Decision] | YYYY-MM-DD |
| Open source programme office (if corporate-backed) | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Scorecard run and first pass |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Reviewed by both maintainers; remediation plan agreed |

## Contents

- [1. Project profile and target level](#1-project-profile-and-target-level)
- [2. Assessment method](#2-assessment-method)
- [3. Results summary](#3-results-summary)
- [4. Assessment by control family](#4-assessment-by-control-family)
- [5. OpenSSF Scorecard results](#5-openssf-scorecard-results)
- [6. Gap analysis and remediation plan](#6-gap-analysis-and-remediation-plan)
- [7. Crosswalks and related obligations](#7-crosswalks-and-related-obligations)
- [8. Maintaining conformance](#8-maintaining-conformance)
- [9. Glossary and references](#9-glossary-and-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Project profile and target level

<!-- Guidance: Describe the project the way a downstream consumer would see it: what it is, how it is released, who can release it, and how widely it is used. These facts decide the target level. -->

### 1.1 Profile

| Item | Value |
|---|---|
| Purpose | *Example:* Client library for the Corvid Commerce storefront API (TypeScript and Python) |
| Licence | *Example:* Apache-2.0 |
| Governance | *Example:* Corporate-backed; two maintainers employed by Corvid Commerce, one external maintainer |
| Release channels | *Example:* npm and PyPI packages; GitHub releases with source archives |
| Release cadence | *Example:* Minor release monthly, patch releases as needed |
| Downstream use | *Example:* About 4,000 weekly downloads; used by Corvid customers' integrations |
| Sensitive resources | *Example:* Package registry publish tokens, release workflow, repository admin settings, signing identity |
| Security contact | *Example:* SECURITY.md; private vulnerability reporting |

### 1.2 Choosing the target level

The OSPS Baseline defines three cumulative levels. Level 1 applies to any project, code or not,
with any number of maintainers or users. Level 2 applies to code projects that have at least two
maintainers and a small number of consistent users. Level 3 applies to code projects with a large
number of consistent users. Each requirement is assigned the lowest level at which it applies;
meeting a level means meeting every applicable requirement at that level and below.

| Criterion | corvid-sdk *(Example)* | Indicates |
|---|---|---|
| Maintainers with merge rights | 3 | Level 2 or above |
| Consistent users | Thousands of weekly downloads, paying customers depend on it | Level 3 eventually |
| Ships compiled or packaged assets | Yes (npm, PyPI) | Release requirements apply |
| Corporate backing for remediation | Yes | Level 3 realistic within a year |
| **Decision** | Level 1 confirmed now; Level 2 by release 3.4; Level 3 by YYYY-MM-DD | |

## 2. Assessment method

<!-- Guidance: Make the method repeatable so the next assessor reaches the same answer. Define the status values and the evidence rule before scoring anything. -->

### 2.1 Steps

```mermaid
flowchart LR
  A["Choose target level"] --> B["Run Scorecard on default branch"]
  B --> C["Collect evidence per requirement"]
  C --> D["Two-maintainer review workshop"]
  D --> E["Status per requirement"]
  E --> F["Gap list and remediation plan"]
  F --> G["Publish summary and track issues"]
```

1. Confirm the Baseline release and read its requirement text and recommendations for every
   requirement up to the target level (the official site lists them per level).
2. Run Scorecard against the default branch with a token that can read branch protection settings
   (some checks need administrative read access to be accurate).
3. Collect evidence: repository and organisation settings, workflow files, documentation URLs,
   release pages, registry settings.
4. Review each requirement with at least two maintainers; record status and evidence.
5. Turn every gap at or below the target level into a tracked issue with an owner and date.
6. Publish the summary (section 3) in the repository, for example in `SECURITY-ASSESSMENT.md`, so
   consumers can see it.

### 2.2 Status values

| Status | Meaning |
|---|---|
| Met | Evidence shows the requirement is satisfied and enforced or documented as required |
| Partially met | Part of the requirement is satisfied, or it is practised but not enforced or documented |
| Not met | No evidence |
| Not applicable | The condition in the requirement does not occur for this project (for example a single-repository project for multi-repository requirements); give the reason |

### 2.3 Metrics

- Conformance at level *n* = requirements Met at level *n* and below ÷ applicable requirements at
  level *n* and below × 100, where applicable excludes Not applicable.
- A level is achieved only at 100% conformance; partial credit is reported for planning only.
- Gap count at target level = Partially met + Not met at the target level and below.

## 3. Results summary

<!-- Guidance: Lead with the answer a consumer wants: which level does the project meet today, and when will it meet the next one. Recompute the counts whenever a status changes. -->

### 3.1 By maturity level

The Baseline release v2026.08.28 contains 64 active requirements (one further requirement,
OSPS-BR-01.02, is retired): 24 first apply at Level 1, 19 at Level 2 and 21 at Level 3.

| Level | Requirements (cumulative) | Not applicable | Applicable | Met | Partially met | Not met | Conformance | Achieved |
|---|---|---|---|---|---|---|---|---|
| Level 1 *(Example)* | 24 | 1 | 23 | 23 | 0 | 0 | 100% | Yes |
| Level 2 *(Example)* | 43 | 1 | 42 | 37 | 2 | 3 | 88.1% | No (5 gaps) |
| Level 3 *(Example)* | 64 | 2 | 62 | 39 | 9 | 14 | 62.9% | No (23 gaps) |

### 3.2 By control family (cumulative, Met ÷ applicable)

| Family | Level 1 | Level 2 | Level 3 |
|---|---|---|---|
| Access Control (AC) *(Example)* | 4/4 | 5/5 | 5/6 |
| Build and Release (BR) | 5/5 | 8/9 | 9/12 |
| Documentation (DO) | 2/2 | 3/4 | 3/8 |
| Governance (GV) | 2/2 | 4/5 | 4/6 |
| Legal (LE) | 4/4 | 5/5 | 5/5 |
| Quality (QA) | 5/5 | 7/7 | 8/11 |
| Security Assessment (SA) | none at this level | 1/3 | 1/4 |
| Vulnerability Management (VM) | 1/1 | 4/4 | 4/10 |
| **Total** | **23/23** | **37/42** | **39/62** |

*Example* conclusion: corvid-sdk meets OSPS Baseline Level 1. Five gaps block Level 2: unsigned
releases (OSPS-BR-06.01), no published dependency management description (OSPS-DO-06.01), an
incomplete list of members with sensitive access (OSPS-GV-01.01), incomplete design documentation
(OSPS-SA-01.01) and no security assessment (OSPS-SA-03.01). The plan in section 6 closes them by
release 3.4.

## 4. Assessment by control family

<!-- Guidance: One row per requirement. The paraphrase helps you scan, but the official requirement text is what you assess against. Scorecard checks marked with a dagger are this template's suggestion; unmarked ones come from the Baseline's own draft mapping to Scorecard. -->

Columns: requirement ID and control short name as published in OSPS Baseline v2026.08.28; the
lowest maturity level at which the requirement applies; an original paraphrase; the *Example*
status and evidence for corvid-sdk; and related Scorecard checks (dagger † marks a suggestion of
this template rather than the Baseline mapping).

### 4.1 Access Control (OSPS-AC)

| Requirement | Control (short name) | Level | What must be true (paraphrase) | Status | Evidence *(Example)* | Scorecard check |
|---|---|---|---|---|---|---|
| OSPS-AC-01.01 | Use MFA for Sensitive Actions | 1 | MFA is enforced for anyone reading or changing sensitive repository resources | Met | Organisation setting "require 2FA"; passkeys allowed | - |
| OSPS-AC-02.01 | Restrict Collaborator Permissions | 1 | New collaborators get lowest privileges by default or explicit manual assignment | Met | Base permission "read"; teams granted explicitly | - |
| OSPS-AC-03.01 | Protect the Primary Branch from Accidental Modification | 1 | Direct commits to the primary branch are blocked | Met | Ruleset on `main`; Scorecard Branch-Protection 8 | Branch-Protection |
| OSPS-AC-03.02 | Protect the Primary Branch from Accidental Modification | 1 | Deleting the primary branch needs explicit confirmation | Met | Ruleset blocks deletion | Branch-Protection |
| OSPS-AC-04.01 | Enforce Least Privilege on CI/CD Pipelines | 2 | CI tasks with no declared permissions default to the lowest level | Met | Default workflow token set to read-only | Token-Permissions † |
| OSPS-AC-04.02 | Enforce Least Privilege on CI/CD Pipelines | 3 | Each CI job is granted only the privileges it needs | Partially met | Release workflow still has `contents: write` at workflow level | Token-Permissions † |

### 4.2 Build and Release (OSPS-BR)

| Requirement | Control (short name) | Level | What must be true (paraphrase) | Status | Evidence *(Example)* | Scorecard check |
|---|---|---|---|---|---|---|
| OSPS-BR-01.01 | Prevent Untrusted Input When Building and Releasing | 1 | Untrusted metadata (branch names, titles) is sanitised before use in CI | Met | No direct interpolation of event fields; Dangerous-Workflow 10 | Dangerous-Workflow |
| OSPS-BR-01.03 | Prevent Untrusted Input When Building and Releasing | 1 | Pipelines running untrusted code cannot reach privileged credentials | Met | Fork pull requests run without secrets | Dangerous-Workflow |
| OSPS-BR-01.04 | Prevent Untrusted Input When Building and Releasing | 3 | Input from trusted collaborators is also validated before use in CI | Partially met | Manual-dispatch inputs not validated in one workflow | Dangerous-Workflow |
| OSPS-BR-02.01 | Assign Unique Version Identifiers | 2 | Each official release has a unique version identifier | Met | SemVer tags | - |
| OSPS-BR-02.02 | Assign Unique Version Identifiers | 3 | Every release asset is tied to the release or its own unique identifier | Met | Assets named with version | - |
| OSPS-BR-03.01 | Use Encrypted Channels for Development and Release Activity | 1 | Official project channels are served only over encrypted transport | Met | HTTPS only for site and docs | - |
| OSPS-BR-03.02 | Use Encrypted Channels for Development and Release Activity | 1 | Distribution channels resist adversary-in-the-middle attacks | Met | Registry over HTTPS with authenticated publishing | - |
| OSPS-BR-04.01 | Publish Change Log With Release | 2 | Each release includes a change log covering functional and security changes | Met | CHANGELOG.md and release notes | - |
| OSPS-BR-05.01 | Use Standardized Dependency Management Tools | 2 | Dependencies are ingested with standard tooling where it exists | Met | Language package manager with lockfile | Dependency-Update-Tool † |
| OSPS-BR-06.01 | Include Signatures and Hashes With Release | 2 | Releases are signed, or listed with hashes in a signed manifest | Not met | Packages published without signatures or provenance | Signed-Releases |
| OSPS-BR-07.01 | Secure Secrets and Credentials | 1 | Unencrypted secrets are kept out of version control | Met | Secret scanning and push protection on | - |
| OSPS-BR-07.02 | Secure Secrets and Credentials | 3 | A documented policy covers storing, accessing and rotating project secrets | Not met | No written secrets policy | - |

### 4.3 Documentation (OSPS-DO)

| Requirement | Control (short name) | Level | What must be true (paraphrase) | Status | Evidence *(Example)* | Scorecard check |
|---|---|---|---|---|---|---|
| OSPS-DO-01.01 | Publish User Guides for Basic Functionality | 1 | Released software has user guides for basic functionality | Met | Docs site | - |
| OSPS-DO-02.01 | Provide Mechanisms for Reporting Defects | 1 | Documentation explains how to report defects | Met | Issue templates and CONTRIBUTING.md | - |
| OSPS-DO-03.01 | Publish Provenance Verification Instructions | 3 | Documentation explains how to verify release integrity and authenticity | Not met | Depends on BR-06.01 | - |
| OSPS-DO-03.02 | Publish Provenance Verification Instructions | 3 | Documentation explains how to verify the identity of the release author or process | Not met | Depends on BR-06.01 | - |
| OSPS-DO-04.01 | Publish Support Scope and Duration | 3 | Documentation states support scope and duration per release | Partially met | Support policy exists for 3.x only | - |
| OSPS-DO-05.01 | Document Security Update Scope and Duration | 3 | Documentation states when versions stop receiving security updates | Partially met | End-of-life dates not published | - |
| OSPS-DO-06.01 | Publish Dependency Management Policy | 2 | Documentation describes how dependencies are selected, obtained and tracked | Not met | No dependency policy published | Pinned-Dependencies |
| OSPS-DO-07.01 | Provide Instructions on How to Build From Source | 2 | Documentation explains how to build from source, including prerequisites | Met | BUILDING.md | - |

### 4.4 Governance (OSPS-GV)

| Requirement | Control (short name) | Level | What must be true (paraphrase) | Status | Evidence *(Example)* | Scorecard check |
|---|---|---|---|---|---|---|
| OSPS-GV-01.01 | Publish Project Roles and Responsibilities | 2 | Documentation lists members with access to sensitive resources | Partially met | MAINTAINERS.md lacks release-permission holders | - |
| OSPS-GV-01.02 | Publish Project Roles and Responsibilities | 2 | Documentation describes project roles and responsibilities | Met | GOVERNANCE.md | - |
| OSPS-GV-02.01 | Provide Public Discussion Mechanisms | 1 | Public channels exist to discuss changes and usage problems | Met | GitHub Discussions | - |
| OSPS-GV-03.01 | Publish Contribution Guide | 1 | Documentation explains the contribution process, or says contributions are not accepted | Met | CONTRIBUTING.md | - |
| OSPS-GV-03.02 | Publish Contribution Guide | 2 | A contributor guide sets requirements for acceptable code contributions | Met | CONTRIBUTING.md coding and test rules | - |
| OSPS-GV-04.01 | Require Formal Review of Permission Grants | 3 | A policy requires review of collaborators before escalated permissions are granted | Not met | Practice exists but is not written down | - |

### 4.5 Legal (OSPS-LE)

| Requirement | Control (short name) | Level | What must be true (paraphrase) | Status | Evidence *(Example)* | Scorecard check |
|---|---|---|---|---|---|---|
| OSPS-LE-01.01 | Require Code Contributors to Assert Right to Commit | 2 | Every commit carries the contributor's assertion of the right to contribute | Met | DCO sign-off enforced by app | - |
| OSPS-LE-02.01 | Ensure Project Licenses are Fully Open Source | 1 | The source licence meets the OSI or FSF definition | Met | Apache-2.0 | License |
| OSPS-LE-02.02 | Ensure Project Licenses are Fully Open Source | 1 | Licences of released assets meet the OSI or FSF definition | Met | Apache-2.0 | License |
| OSPS-LE-03.01 | Maintain and Release Licenses in a Well Known Location | 1 | The source licence is kept in a standard location in the repository | Met | LICENSE file | License |
| OSPS-LE-03.02 | Maintain and Release Licenses in a Well Known Location | 1 | Released assets include their licence or have it alongside | Met | LICENSE inside the package | License |

### 4.6 Quality (OSPS-QA)

| Requirement | Control (short name) | Level | What must be true (paraphrase) | Status | Evidence *(Example)* | Scorecard check |
|---|---|---|---|---|---|---|
| OSPS-QA-01.01 | Publish Source Code and Change History | 1 | Source code is publicly readable at a static URL | Met | Public repository | - |
| OSPS-QA-01.02 | Publish Source Code and Change History | 1 | Version control keeps a public record of all changes, authors and times | Met | Git history | - |
| OSPS-QA-02.01 | Publish Software Dependencies | 1 | The repository contains a list of direct dependencies where the ecosystem supports it | Met | Manifest and lockfile | SBOM † |
| OSPS-QA-02.02 | Publish Software Dependencies | 3 | Compiled released assets ship with an SBOM | Not met | No SBOM generated in release workflow | SBOM † |
| OSPS-QA-03.01 | Address Pass/Fail Checks Before Accepting Changes | 2 | Automated status checks must pass, or be bypassed explicitly, before commits reach the primary branch | Met | Required checks in ruleset | - |
| OSPS-QA-04.01 | Enforce Security Requirements on All Codebases | 1 | Multi-repository projects list all their codebases | Not applicable | Single repository | - |
| OSPS-QA-04.02 | Enforce Security Requirements on All Codebases | 3 | Sub-projects in a release enforce security requirements at least as strict as the main codebase | Not applicable | Single repository | - |
| OSPS-QA-05.01 | Prevent Executables in the Codebase | 1 | Version control holds no generated executable artefacts | Met | Binary-Artifacts 10 | Binary-Artifacts |
| OSPS-QA-05.02 | Prevent Executables in the Codebase | 1 | Version control holds no unreviewable binary artefacts | Met | Test fixtures are text | Binary-Artifacts |
| OSPS-QA-06.01 | Use Automated Testing in CI/CD Pipelines | 2 | At least one automated test suite runs in CI before a commit is accepted | Met | CI-Tests 10 | CI-Tests |
| OSPS-QA-06.02 | Use Automated Testing in CI/CD Pipelines | 3 | Documentation says when and how tests run | Met | CONTRIBUTING.md testing section | CI-Tests |
| OSPS-QA-06.03 | Use Automated Testing in CI/CD Pipelines | 3 | A policy expects major changes to add or update automated tests | Partially met | Expectation stated in pull request template only | CI-Tests |
| OSPS-QA-07.01 | Require Merge Approvals | 3 | At least one human approval by someone other than the author before merge to the primary branch | Not met | Single maintainer can self-merge; Code-Review 4 | Code-Review |

### 4.7 Security Assessment (OSPS-SA)

| Requirement | Control (short name) | Level | What must be true (paraphrase) | Status | Evidence *(Example)* | Scorecard check |
|---|---|---|---|---|---|---|
| OSPS-SA-01.01 | Publish Design Descriptions of System Actors and Actions | 2 | Released software has design documentation showing actors and actions | Partially met | Architecture page lacks data flows | - |
| OSPS-SA-02.01 | Publish External Interface Descriptions | 2 | Released software documents all external software interfaces | Met | API reference | - |
| OSPS-SA-03.01 | Maintain a Project Security Assessment | 2 | A security assessment of the most likely and most damaging problems is done | Not met | None performed | - |
| OSPS-SA-03.02 | Maintain a Project Security Assessment | 3 | Threat modelling and attack surface analysis are performed | Not met | None performed | - |

### 4.8 Vulnerability Management (OSPS-VM)

| Requirement | Control (short name) | Level | What must be true (paraphrase) | Status | Evidence *(Example)* | Scorecard check |
|---|---|---|---|---|---|---|
| OSPS-VM-01.01 | Publish Coordinated Vulnerability Disclosure Policy | 2 | A coordinated vulnerability disclosure policy with a response timeframe is published | Met | SECURITY.md with 5-day acknowledgement | Security-Policy |
| OSPS-VM-02.01 | Publish Contacts and Process for Reporting Vulnerabilities | 1 | Security contacts are published | Met | SECURITY.md | Security-Policy |
| OSPS-VM-03.01 | Maintain Private Vulnerability Reporting Process | 2 | A private channel lets reporters reach the security contacts directly | Met | Private vulnerability reporting enabled | - |
| OSPS-VM-04.01 | Publish Discovered Vulnerabilities | 2 | Data about discovered vulnerabilities is published | Met | Repository security advisories | - |
| OSPS-VM-04.02 | Publish Discovered Vulnerabilities | 3 | Component vulnerabilities that do not affect the project are explained in VEX | Not met | No VEX published | - |
| OSPS-VM-05.01 | Publish and Enforce a Dependency Remediation Policy | 3 | A policy sets remediation thresholds for SCA vulnerability and licence findings | Not met | No written threshold | Security-Policy, Vulnerabilities |
| OSPS-VM-05.02 | Publish and Enforce a Dependency Remediation Policy | 3 | A policy requires SCA violations to be addressed before release | Not met | Not written | Security-Policy, Vulnerabilities |
| OSPS-VM-05.03 | Publish and Enforce a Dependency Remediation Policy | 3 | Every change is checked automatically against a policy for malicious and vulnerable dependencies and blocked on violation unless suppressed as non-exploitable | Partially met | Dependency review runs but does not block | Security-Policy, Vulnerabilities |
| OSPS-VM-06.01 | Publish and Enforce an Application Security Testing Policy | 3 | A policy sets remediation thresholds for SAST findings | Not met | Not written | Security-Policy, Vulnerabilities, SAST |
| OSPS-VM-06.02 | Publish and Enforce an Application Security Testing Policy | 3 | Every change is checked automatically for security weaknesses and blocked on violation unless suppressed as non-exploitable | Partially met | SAST runs weekly, not on each change | Security-Policy, Vulnerabilities, SAST |

## 5. OpenSSF Scorecard results

<!-- Guidance: Scorecard is a heuristic, not an audit. Use it to find gaps quickly and to monitor drift between assessments, and read each check's documentation before acting on a low score. -->

### 5.1 Run details

| Item | Value |
|---|---|
| Version | [*Example:* v5.6.0] |
| How run | [*Example:* Scorecard GitHub Action on push to `main` and weekly; results published to the OpenSSF API] |
| Token scope | [*Example:* Read-only fine-grained token with administration read, so branch protection is visible] |
| Aggregate score | [As reported by the tool; do not recompute it by hand because checks are weighted by risk] |
| Run date | YYYY-MM-DD |

### 5.2 Check results

| Check | Score *(Example)* | Related OSPS requirements | Interpretation and action |
|---|---|---|---|
| Binary-Artifacts | 10 | OSPS-QA-05 | No binaries committed |
| Branch-Protection | 8 | OSPS-AC-03 | Ruleset in place; administrators can bypass for emergency fixes: accepted, reviewed quarterly (section 8) |
| CI-Tests | 10 | OSPS-QA-06 | Tests run on every pull request |
| CII-Best-Practices | 0 | none | OpenSSF Best Practices Badge not yet requested; optional, see REM-010 |
| Code-Review | 4 | OSPS-QA-07 | Many recent changes self-merged; Level 3 gap, REM-007 |
| Contributors | 6 | none | Contributors from two organisations; informational |
| Dangerous-Workflow | 10 | OSPS-BR-01 | No unsafe triggers or untrusted interpolation |
| Dependency-Update-Tool | 10 | OSPS-BR-05 † | Automated dependency update pull requests enabled |
| Fuzzing | 0 | none | Not fuzzed; consider for the request parser, REM-011 |
| License | 10 | OSPS-LE-02, OSPS-LE-03 | Apache-2.0 detected |
| Maintained | 10 | none | Active commits and issue responses |
| Packaging | 10 | none | Packages published from a workflow |
| Pinned-Dependencies | 6 | OSPS-DO-06 | Third-party actions pinned by tag, not commit hash; REM-003 |
| SAST | 7 | OSPS-VM-06 | SAST runs, but not on every commit; REM-008 |
| SBOM | 0 | OSPS-QA-02 † | No SBOM in releases; REM-006 |
| Security-Policy | 10 | OSPS-VM-01, OSPS-VM-02 | SECURITY.md present with contact and timeframe |
| Signed-Releases | 0 | OSPS-BR-06 | No signatures or provenance attached; REM-001 |
| Token-Permissions | 7 | OSPS-AC-04 † | One workflow grants write at workflow level; REM-005 |
| Vulnerabilities | 9 | OSPS-VM-05 | One open advisory in a development dependency |
| Webhooks | [Not run] | none | Needs an administrative token; check manually |

The Baseline's own Scorecard mapping is marked draft in the v2026.08.28 repository, so treat the
relationships as indicative. A high Scorecard score does not prove a Baseline requirement is met,
and many Baseline requirements (documentation, policy, governance) have no Scorecard check at all.

## 6. Gap analysis and remediation plan

<!-- Guidance: Order by the level that needs the fix, then by risk. Every gap at or below the target level must have an owner and a date; gaps above it can be scheduled later but should be visible. -->

| ID | Requirement(s) | Level | Gap | Remediation | Owner | Due | Status |
|---|---|---|---|---|---|---|---|
| REM-001 *(Example)* | OSPS-BR-06.01 | 2 | Releases not signed | Generate build provenance and keyless signatures in the release workflow; publish signatures and hashes with each release | [@maintainer-2] | Release 3.3 | Open |
| REM-002 *(Example)* | OSPS-SA-03.01 | 2 | No security assessment | Run a lightweight threat model of the SDK (token handling, request signing, retries) and publish the summary | [@lead-maintainer] | Release 3.4 | Open |
| REM-003 *(Example)* | OSPS-DO-06.01 | 2 | Dependency handling not documented | Publish how dependencies are chosen, pinned, updated and tracked; pin actions by commit hash | [@maintainer-3] | Release 3.3 | Open |
| REM-004 *(Example)* | OSPS-GV-01.01, OSPS-SA-01.01 | 2 | Sensitive-access list and design documentation incomplete | List registry publishers and repository admins in MAINTAINERS.md; add actors and data flows to the architecture page | [@lead-maintainer] | Release 3.3 | Open |
| REM-005 *(Example)* | OSPS-AC-04.02, OSPS-BR-01.04 | 3 | Over-broad workflow permissions; unvalidated dispatch inputs | Move permissions to job level; validate inputs against an allow-list | [@maintainer-2] | Release 3.5 | Planned |
| REM-006 *(Example)* | OSPS-QA-02.02, OSPS-VM-04.02 | 3 | No SBOM or VEX | Generate CycloneDX SBOM per release; publish OpenVEX for non-affecting dependency CVEs | [@maintainer-3] | Release 3.5 | Planned |
| REM-007 *(Example)* | OSPS-QA-07.01, OSPS-GV-04.01 | 3 | Self-merge possible; no written permission review policy | Require one non-author approval; write permission-grant review rule in GOVERNANCE.md | [@lead-maintainer] | Release 3.5 | Planned |
| REM-008 *(Example)* | OSPS-VM-05.01 to 05.03, OSPS-VM-06.01, 06.02 | 3 | SCA and SAST thresholds not defined or enforced | Write remediation thresholds; make dependency review and SAST blocking on pull requests | [@maintainer-2] | YYYY-MM-DD | Planned |
| REM-009 *(Example)* | OSPS-BR-07.02, OSPS-DO-03.01, 03.02, OSPS-DO-04.01, OSPS-DO-05.01, OSPS-QA-06.03, OSPS-SA-03.02 | 3 | Remaining Level 3 documentation and assessment gaps | Secrets policy, verification guide, support and end-of-life statement, test policy, threat model refresh | [@lead-maintainer] | YYYY-MM-DD | Planned |
| REM-010 *(Example)* | none | n/a | Best Practices Badge not requested | Optional: apply for the badge once Level 2 is met | [@ospo-lead] | YYYY-MM-DD | Optional |
| REM-011 *(Example)* | none | n/a | No fuzzing | Optional: add property-based tests for the request parser | [@maintainer-3] | YYYY-MM-DD | Optional |

Check: REM-001 to REM-004 cover the five Level 2 gaps in section 3 (BR-06.01, DO-06.01, GV-01.01,
SA-01.01 and SA-03.01). REM-005 to REM-009 cover the remaining 18 Level 3 gaps.

## 7. Crosswalks and related obligations

<!-- Guidance: Consumers may ask about other frameworks. The Baseline repository publishes mapping files; cite them rather than building your own mapping from scratch. -->

The OSPS Baseline repository (release v2026.08.28) publishes mapping files from Baseline controls to
other frameworks, including OpenSSF Scorecard, the OpenSSF Best Practices Badge, SLSA, NIST SSDF
(SP 800-218), NIST CSF 2.0, the EU Cyber Resilience Act, ISO/IEC 18974, OWASP SAMM and others. Use
them as a starting point when a consumer asks how the project relates to their framework, and check
the mapping status in the repository before relying on it.

| Topic | How it relates to this assessment | Where to go |
|---|---|---|
| Supply chain integrity (SLSA, signing) | OSPS-BR-06 and OSPS-DO-03 overlap with build provenance and signing | Software Supply Chain Security Assessment (`security/supply-chain-security`) |
| SBOM and VEX | OSPS-QA-02.02 and OSPS-VM-04.02 require them at Level 3 | SBOM and VEX Policy (`security/sbom-vex-policy`) |
| Vulnerability reporting | OSPS-VM-01 to VM-03 | Security Policy (`dev/security-policy`) and Vulnerability Disclosure Policy (`security/vulnerability-disclosure-policy`) |
| Advisories | OSPS-VM-04.01 | Security Advisory (`security/security-advisory`) |
| Governance and contribution | OSPS-GV and OSPS-LE | Governance (`dev/governance`), Contributing Guide (`dev/contributing`), Code of Conduct (`dev/code-of-conduct`) |
| Releases and change logs | OSPS-BR-02, OSPS-BR-04 | Versioning and Release Policy (`dev/versioning-release-policy`), Release Checklist (`dev/release-checklist`), Changelog (`dev/changelog`) |
| Dependencies | OSPS-DO-06, OSPS-VM-05 | Dependency Management Policy (`dev/dependency-management-policy`) |
| Secure development practices | Overlaps with SSDF practices | SSDF Practice Conformance (`security/ssdf-practice-attestation`) |
| EU Cyber Resilience Act | Projects monetised by a manufacturer, or supported by an open-source software steward, may have CRA duties; Article 14 reporting applies from 11 September 2026 (check the consolidated text) | CRA Vulnerability Handling and Reporting Procedure (`security/cra-vulnerability-handling`) |

## 8. Maintaining conformance

<!-- Guidance: Conformance decays: new workflows, new maintainers and new dependencies reopen closed gaps. Automate what you can and re-check the rest on a schedule. -->

| Activity | Frequency *(Example)* | Owner | Evidence |
|---|---|---|---|
| Scorecard run and drift review | Weekly (automated), reviewed monthly | [@maintainer-2] | Scorecard results history |
| Full Baseline reassessment | Each minor release or every 6 months | [@lead-maintainer] | This document, new version |
| Review of members with sensitive access | Quarterly and when a maintainer joins or leaves | [@lead-maintainer] | MAINTAINERS.md history |
| Check for a new Baseline release | Quarterly | [@ospo-lead] | Revision history entry |
| Remediation plan review | Monthly maintainers' call | [@lead-maintainer] | Issue tracker milestone |

Re-assess immediately when the project adds a repository, changes its release channel, adds a
maintainer with publish rights, or suffers a security incident. When a new Baseline release
appears, compare requirement IDs and levels with this assessment, because requirements can be added,
moved between levels or retired between releases.

## 9. Glossary and references

<!-- Guidance: Keep definitions short and original. Link to the Baseline site for the normative wording. -->

### 9.1 Glossary

| Term | Definition |
|---|---|
| OSPS Baseline | OpenSSF Open Source Project Security Baseline: a catalogue of security requirements for open-source projects, organised by control family and maturity level |
| Control | A named security objective in the Baseline (for example OSPS-AC-01) |
| Assessment requirement | A testable statement under a control (for example OSPS-AC-01.01) |
| Maturity level | One of three cumulative sets of requirements matched to a project's size and use |
| Scorecard | OpenSSF tool that runs automated checks on a repository and scores each from 0 to 10 |
| Primary branch | The branch from which releases are made (often `main`) |
| VEX | Vulnerability exploitability exchange statement saying whether a product is affected by a vulnerability |
| SCA, SAST | Software composition analysis (dependency scanning) and static application security testing |

### 9.2 References

| Reference | Use |
|---|---|
| OpenSSF, *Open Source Project Security Baseline*, release v2026.08.28 (baseline.openssf.org; github.com/ossf/security-baseline) | Control IDs, short names and levels (sections 3, 4) |
| OpenSSF Scorecard v5.6.0, 12 October 2026, and check documentation (scorecard.dev; github.com/ossf/scorecard) | Automated checks (section 5) |
| OSPS Baseline mapping files, including the draft mapping to Scorecard (github.com/ossf/security-baseline, `baseline/mappings`) | Section 5 and 7 crosswalks |
| OpenSSF Best Practices Badge (bestpractices.dev) | Optional complementary self-certification |
| Regulation (EU) 2024/2847 (Cyber Resilience Act), eur-lex.europa.eu | Section 7 |

## Standard and licence note

Structure aligned with the OpenSSF Open Source Project Security Baseline, release v2026.08.28, and
OpenSSF Scorecard v5.6.0, both published by the Open Source Security Foundation (a Series of LF
Projects, LLC) under the Apache License 2.0; attribution: "OSPS Baseline contributors" and "OpenSSF
Scorecard authors". Requirement IDs, control short names, maturity levels and Scorecard check names
are cited for interoperability; the requirement paraphrases, method and worked example are
original. Check the current official release at baseline.openssf.org and scorecard.dev before
relying on this assessment, because requirements and levels change between releases. OpenSSF and
Scorecard are trademarks of The Linux Foundation; this template is not affiliated with or endorsed
by it. Template licence: MIT.