📖 Scorecard v6: OSPS Baseline conformance proposal and 2026 roadmap

.gitignore

@@ -64,3 +64,6 @@ newRelease.json
 # Ignore golang's vendored files
 /vendor/
 /tools/vendor/
+
+# AI tooling instructions
+AGENTS.md

docs/ROADMAP.md

@@ -0,0 +1,150 @@
+# OpenSSF Scorecard Roadmap
+
+## 2026
+
+### Theme: Scorecard v6 — Open Source Security Evidence Engine
+
+**Mission:** Scorecard produces trusted, structured security evidence for the
+open source ecosystem.
+
+Scorecard v6 evolves Scorecard from a scoring tool to an evidence engine. The
+primary initiative for 2026 is adding
+[OSPS Baseline](https://baseline.openssf.org/) conformance evaluation as the
+first use case that proves this architecture. Scorecard accepts diverse inputs
+about a project's security practices, normalizes them through probe-based
+analysis, and packages the resulting evidence in interoperable formats for
+downstream tools to act on.
+
+Check scores (0-10) and conformance labels (PASS/FAIL/UNKNOWN) are parallel
+evaluation layers over the same probe evidence, produced in a single run.
+Existing checks, probes, and scores are unchanged — v6 is additive. The
+conformance layer is a new product surface aligned with the
+[ORBIT WG](https://github.com/ossf/wg-orbit) ecosystem. (While Scorecard is not
+part of ORBIT WG, ecosystem interoperability with ORBIT tools is an overarching
+OpenSSF goal, and Scorecard interoperates through published output formats.)
+
+**Target Baseline version:** [v2026.02.19](https://baseline.openssf.org/versions/2026-02-19)
+
+**Current coverage:** See [docs/osps-baseline-coverage.md](osps-baseline-coverage.md)
+for a control-by-control analysis.
+
+### Phased delivery
+
+Phases are ordered by outcome. Maintainer bandwidth dictates delivery timing.
+
+#### Phase 1: Conformance foundation and Level 1 coverage
+
+**Outcome:** Scorecard produces a useful OSPS Baseline Level 1 conformance
+report for any public GitHub repository, available across CLI, Action, and
+API surfaces.
+
+Deliverables:
+
+- Evidence model and output formats:
+  - Enriched JSON (Scorecard-native)
+  - In-toto evidence predicate (`scorecard.dev/evidence/v0.1`)
+  - Gemara output (via [security-baseline](https://github.com/ossf/security-baseline)
+    dependency)
+  - OSCAL Assessment Results (via
+    [go-oscal](https://github.com/defenseunicorns/go-oscal))
+  - OpenSSF Best Practices Badge [Automation Proposals](https://github.com/coreinfrastructure/best-practices-badge/blob/main/docs/automation-proposals.md)
+- Unified framework abstraction for OSPS Baseline v2026.02.19:
+  - Checks and OSPS Baseline both use the same internal probe composition interface
+  - Probe-to-control mappings maintained in Scorecard
+- Applicability engine detecting preconditions (e.g., "has made a release")
+- Map existing probes to OSPS controls where coverage exists today
+- New probes for Level 1 gaps:
+  - Governance and documentation presence
+  - Dependency manifest presence
+  - Security policy deepening
+  - Secrets detection — consuming platform signals where available
+- Metadata ingestion layer — Security Insights as first supported source;
+  architecture supports additional metadata sources
+- Scorecard control catalog extraction plan
+
+#### Phase 2: Release integrity and Level 2 core
+
+**Outcome:** Scorecard evaluates release-related OSPS controls, covering the
+core of Level 2 and becoming useful for downstream due diligence workflows.
+
+Deliverables:
+
+- Release asset inspection layer
+- Signed manifest support
+- Release notes and changelog detection
+- Evidence bundle output (conformance results + in-toto statement)
+- Additional metadata sources for the ingestion layer
+
+**Note:** Phase 1 focuses on automatically verifiable controls. Design of
+attestation mechanisms (for non-automatable controls) is deferred to Phase 3 or
+beyond.
+
+#### Phase 3: Enforcement detection, Level 3, and multi-repo
+
+**Outcome:** Scorecard covers Level 3 controls including enforcement detection
+and project-level aggregation.
+
+Deliverables:
+
+- SCA policy and enforcement detection (Scorecard detects enforcement mechanisms without being an enforcement tool itself)
+- SAST policy and enforcement detection (Scorecard detects enforcement mechanisms without being an enforcement tool itself)
+- Multi-repo project-level conformance aggregation
+- Attestation mechanism for non-automatable controls (deferred from Phase 2)
+- Attestation integration GA
+
+### Ecosystem alignment
+
+Scorecard operates within the ORBIT WG ecosystem as an evidence engine. All
+downstream tools consume Scorecard evidence on equal terms through published
+output formats.
+
+[Allstar](https://github.com/ossf/allstar), a Scorecard sub-project,
+continuously monitors GitHub organizations and enforces Scorecard check
+results as policies. OSPS conformance output could enable Allstar to enforce
+Baseline conformance at the organization level.
+
+Scorecard SHOULD NOT (per [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119))
+duplicate evaluation that downstream tools handle:
+
+- **[Privateer](https://github.com/ossf/pvtr-github-repo-scanner)** — Baseline evaluation powered by Gemara and Security Insights
+- **[Minder](https://github.com/mindersec/minder)** — Policy enforcement and remediation platform (OpenSSF Sandbox, ORBIT WG)
+- **[AMPEL](https://github.com/carabiner-dev/ampel)** — Attestation-based policy enforcement; already consumes Scorecard probe results via [policy library](https://github.com/carabiner-dev/policies/tree/main/scorecard)
+- **[Darnit](https://github.com/kusari-oss/darnit)** — Compliance audit and remediation
+
+Scorecard's role is to produce deep, probe-based security evidence that these
+tools and downstream consumers can use through interoperable output formats
+(JSON, in-toto, Gemara, SARIF, OSCAL).
+
+### Design principles
+
+1. **Evidence is the product.** Scorecard's core output is structured,
+   normalized probe findings. Check scores and conformance labels are parallel
+   evaluation layers over the same evidence.
+2. **Probes normalize diversity.** Each probe understands multiple ways a
+   control outcome can be satisfied.
+3. **UNKNOWN-first honesty.** If Scorecard cannot observe a control, the
+   status is UNKNOWN with an explanation — never a false PASS or FAIL.
+4. **All consumers are equal.** Downstream tools consume Scorecard evidence
+   through published output formats.
+5. **No metadata monopolies.** Probes may evaluate multiple sources for the
+   same data. No single metadata file is required for meaningful results,
+   though they may enrich results.
+6. **Formats are presentation.** Output formats (JSON, in-toto, Gemara,
+   SARIF, OSCAL) are views over the evidence model. No single format is
+   privileged.
+
+### Open questions
+
+The following design questions are under active discussion among maintainers:
+
+- **Attestation identity model** — How non-automatable controls are attested
+  (repo-local metadata vs. signed attestations via Sigstore/OIDC). Decomposed
+  into identity (who signs) and tooling (what generates, when) sub-questions.
+- **Enforcement detection scope** — How Scorecard detects enforcement
+  mechanisms without being an enforcement tool itself
+
+### How to contribute
+
+See the [proposal](../openspec/changes/osps-baseline-conformance/proposal.md)
+for detailed requirements and open questions. Discussion and feedback are
+welcome via GitHub issues and the Scorecard community meetings.