Open remediation standards for regulated consumption
The ratified OSERA-SP-0.1.0 standards pack for producing, publishing, and consuming open patches with provenance, release evidence, and vulnerability feeds.
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 standards focus 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-<reponame>` name in the finos-osera GitHub organization.
v0.1.0 · Required check
Fork Management
Ratified
OSERA-SP-0.1.0 ratified
2026-09-10
FORK-002
Patch Branches
Patch providers use `patch/<version>` source workflow branches for every supported major or minor line.
v0.1.0 · Required check
Fork Management
Ratified
OSERA-SP-0.1.0 ratified
2026-09-10
FORK-003
Baseline Tags
Every patch line identifies its unpatched starting source SHA with a `v<VERSION>+patch.baseline` tag.
v0.1.0 · Required check
Fork Management
Ratified
OSERA-SP-0.1.0 ratified
2026-09-10
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
Ratified
OSERA-SP-0.1.0 ratified
2026-09-10
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
Ratified
OSERA-SP-0.1.0 ratified
2026-09-10
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
Ratified
OSERA-SP-0.1.0 ratified
2026-09-10
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
Ratified
OSERA-SP-0.1.0 ratified
2026-09-10
REL-003
Patch Version Naming
Patched releases use package-ecosystem-appropriate version naming profiles that optimize recipient tooling outcomes before choosing a concrete syntax.
v0.1.0 · Required check
Release Process
Ratified
OSERA-SP-0.1.0 ratified
2026-09-10
REL-003-JAVA
Java Patch Version Naming
Java patched releases use a version naming profile that optimizes Maven, Gradle, repository-manager, dependency-update, SCA, feed, and policy-tool behavior for the affected upstream version line.
v0.1.0 · Required Java profile check
Release Process
Ratified
OSERA-SP-0.1.0 ratified
2026-09-10
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
Ratified
OSERA-SP-0.1.0 ratified
2026-09-10
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
Ratified
OSERA-SP-0.1.0 ratified
2026-09-10
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
Ratified
OSERA-SP-0.1.0 ratified
2026-09-10
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
Ratified
OSERA-SP-0.1.0 ratified
2026-09-10
Recipient guidance in observe mode
EVD-001 collects recipient guidance for 0.2.0: what changed, why it changed, and what application surface area recipients should consider testing. It does not block 0.1.0 alignment.