Meridian Request a Proof of Value
All open standards

Open Standard

OpenSSF OSPS Baseline

Open Source Project Security Baseline (OSPS Baseline)

Governed by OpenSSF Gemara Layer 2

A security baseline written natively for open source software delivery — designed for the engineering pipelines that Meridian governs, not the document-based frameworks that predate them.

What it is

The OpenSSF Open Source Project Security Baseline (OSPS Baseline) is a set of security requirements for open source software projects, structured as machine-readable controls at Gemara Layer 2. Unlike traditional security frameworks that describe what an organisation's policies should say, the OSPS Baseline describes what a software delivery pipeline should demonstrably do: what checks should run on every commit, what provenance should be captured for every build, what access controls should govern every release. The requirements are concrete, binary, and verifiable — a pipeline either meets them or it does not.

The baseline was built for the reality of modern software supply chains, where open source components make up the majority of most applications' code, and where the security of those components is determined by the practices of the projects that produce them. It provides a floor — the minimum set of practices that any project handling software for regulated use should implement — while remaining extensible for organisations with stricter requirements.

Why it matters

The SolarWinds breach and the Log4Shell vulnerability exposed a specific class of compliance failure: organisations had documented policies about software security, but those policies were not enforced in the pipelines where software was actually built. The gap was not between what organisations intended and what they could afford — it was between what compliance frameworks required and what engineering pipelines did. No existing framework had been designed with the build pipeline as the primary target.

The OSPS Baseline fills that gap. Its requirements are expressed at the level of pipeline behaviour — not "have a policy about dependency review" but "every pull request must trigger an automated dependency scan before merge." That specificity is what makes it useful to both compliance teams and the engineers they work with. It is not a framework to interpret and translate; it is a checklist a pipeline can be tested against directly.

Meridian's role

The OSPS Baseline was created by Meridian's founding team and contributed to the OpenSSF, where it is now maintained under independent governance with Meridian as a primary contributor. We built it for the same reason we built Gemara: the tooling existed but the standard did not. Organisations knew they needed pipeline security controls, but there was no agreed definition of what those controls should look like in a form that tools could enforce automatically.

Because we created it and continue to maintain it, the OSPS Baseline is closely aligned with Gemara's data model. It was designed from the beginning to operate as a Layer 2 control catalog — which means its controls slot directly into Meridian Chancery without adaptation, and evidence of compliance is captured in the structured form Meridian Admiralty and the rest of the platform already understand.

How it connects to the platform

Meridian Chancery can be pre-seeded with OSPS Baseline controls alongside or instead of the FINOS CCC catalog, depending on the organisation's context. For organisations whose primary compliance concern is the security of their own software delivery pipeline — fintechs, open source foundations, technology-forward enterprises — the OSPS Baseline is often the more immediately applicable starting point.

Meridian Tackle is the component most directly shaped by OSPS Baseline requirements. When Meridian Tackle orchestrates scanners and engineering assistants, the selection and configuration of those tools is driven by active policy in Meridian Chancery — and OSPS Baseline controls define precisely what those tools should check and what evidence they should produce. The result is a pipeline that does not just run security scans but runs the right scans, configured correctly, and records the output in a form that satisfies an auditor's definition of evidence.

Connected components Meridian Chancery Meridian Tackle