Open remediation standards for regulated consumption

A provisional FINOS OSERA evaluation draft for producing, publishing, and consuming open patches with provenance, release evidence, vulnerability feeds, and recipient-focused test guidance. This branch proposes an initial OSERA-SP-0.1.0 standards pack for open discussion.

Browse standards Review v0.1.0 pack About OSERA Contribute

Candidate standards pack

OSERA-SP-0.1.0 proposes the first versioned set of remediation standards for issue #12. The pack includes conventions that current implementers can plausibly follow on day one and defers immature areas such as certification and estate-wide automated application.

View pack and release history Review fitness function

Why this exists

OSERA patch work has moved from a small set of experiments into a larger patch library spanning older Java ecosystems, build tooling variations, and end-of-life software lines. The emerging practice now needs a stable, open, bank-consumable format.

What it standardizes

The draft focuses on fork management, source-change provenance, release compatibility, VEX/SBOM feeds, and the recipient evidence enterprises need to assess what changed and what surface area to test.

Standards catalog

Numbered requirements and examples, modeled on the SDLC Controls Framework catalog style and adapted for patch production and consumption.

Standard lifecycle status and standards-pack membership are tracked separately. Ratifying a pack records the exact standard versions included in that pack; it does not rewrite every future draft into the pack. The same structured metadata is published in the generated standards catalog.

FORK-001 Repository Naming Patched-source repositories use a consistent `patch-` name in the finos-osera GitHub organization. v0.1.0 · Required check Fork Management Draft OSERA-SP-0.1.0 candidate Not ratified FORK-002 Patch Branches Patch providers use `patch/` source workflow branches for every supported major or minor line. v0.1.0 · Required check Fork Management Draft OSERA-SP-0.1.0 candidate Not ratified FORK-003 Baseline Tags Every patch line identifies its unpatched starting source SHA with a `v+patch.baseline` tag. v0.1.0 · Required check Fork Management Draft OSERA-SP-0.1.0 candidate Not ratified FORK-004 Open Source Patch Publication Patched-source repositories should be fully public, hosted in the appropriate official fork, and released under the same open-source license terms as the original code. v0.0.1 · Observe-only check Fork Management Pre-Draft OSERA-SP-0.2.0 observe Not ratified SRC-001 Patch Basis Classification Providers distinguish upstream backports from provider-developed fixes for each CVE or fix item carried by a patch release. v0.0.1 · Observe-only check Source Changes Pre-Draft OSERA-SP-0.2.0 observe Not ratified SRC-002 Upstream Provenance Links Backports link to the upstream commit or advisory that introduced the fix being carried back. v0.1.0 · Required evidence Source Changes Draft OSERA-SP-0.1.0 candidate Not ratified SRC-003 License Headers for New Files New source or test files match the prevailing license format of the surrounding project. v0.1.0 · Required check Source Changes Draft OSERA-SP-0.1.0 candidate Not ratified REL-001 Provider Test Provenance Test execution methods are provider-dependent, but the provider publishes a unit-test report artifact for recipients to understand release validation. v0.1.0 · Required evidence Release Process Draft OSERA-SP-0.1.0 candidate Not ratified REL-002 Bytecode Compatibility Patched artifacts preserve the bytecode level of the last released artifact unless an explicit exception is approved. v0.1.0 · Required evidence Release Process Draft OSERA-SP-0.1.0 candidate Not ratified REL-003 Patch Initiative Version Metadata Patched releases use SemVer build metadata that identifies the patching initiative and release sequence. v0.1.0 · Required check Release Process Draft OSERA-SP-0.1.0 candidate Not ratified REL-004 Approved Producers Official OSERA signed artifacts are produced only by producers approved for the targeted standards pack. v0.1.0 · Required check Release Process Draft OSERA-SP-0.1.0 candidate Not ratified REL-005 Artifact Publication Hygiene Published OSERA artifacts include consistent package metadata, checksums, and repository evidence required by the publication gate. v0.1.0 · Required check Release Process Draft OSERA-SP-0.1.0 candidate Not ratified REL-006 Patch Request Authorization Patch releases should trace to an approved backlog item, request, sponsor record, or equivalent authorization record. v0.0.1 · Observe-only check Release Process Pre-Draft OSERA-SP-0.2.0 observe Not ratified REL-007 Build Provenance and Signed Attestation Producers should sign an attestation linking the published artifact digest to the source tag, build process, SBOM, VEX, test evidence, and license audit. v0.0.1 · Observe-only check Release Process Pre-Draft OSERA-SP-0.2.0 observe Not ratified REL-008 Build Security Scanning Patch release builds should be checked for build-tool, dependency, and pipeline-injection risks before publication. v0.0.1 · Observe-only check Release Process Pre-Draft OSERA-SP-0.2.0 observe Not ratified FEED-001 OpenVEX and CycloneDX Feeds OSERA-compatible providers contribute patch data to both OpenVEX and CycloneDX feed formats. v0.1.0 · Required evidence Feeds and Advisories Draft OSERA-SP-0.1.0 candidate Not ratified EVD-001 Change and Test Surface Guidance Providers publish concise recipient guidance describing what changed and what surface area should be tested. v0.0.1 · Observe-only check Recipient Evidence Pre-Draft OSERA-SP-0.2.0 observe Not ratified APP-001 Estate-Wide Patch Application Patch feeds should support automated discovery and application across dependency estates. v0.0.1 · Observe-only check Patch Application Pre-Draft OSERA-SP-0.2.0 observe Not ratified STD-001 Standards-as-Code Source Metadata OSERA standards use human-authored Markdown with structured YAML front matter as the machine-readable source of truth. v0.1.0 · Required check Standards Governance Draft OSERA-SP-0.1.0 candidate Not ratified

Recipient evidence is part of the standard

Patch delivery should not stop at a patched coordinate. Providers should publish a concise, machine-readable explanation of what changed, why it changed, and what application surface area recipients should consider testing.

Review EVD-001