Zusammenfassung

  • Die OSPS Baseline erlaubt Selbstattestierungen durch Projekte und beschreibt Konformität als punktuellen Zustand gegenüber einer bestimmten Version und Reifestufe.
  • Eine prüfbare Aussage verbindet Umfang, Version, Stufe, Datum, attestierende Stelle, Belege je Kontrolle, Ausnahmen und einen Auslöser für die Neubewertung, ohne Zertifizierung oder Release-Sicherheit vorzutäuschen.

Analyse

In einem Softwareverzeichnis leuchtet eine grüne Zelle: „OSPS compliant“. Sie wirkt wie eine abgeschlossene Prüfung. Unbekannt bleiben jedoch der verwendete Baseline-Text, die angewandte Stufe, das Bewertungsdatum und der Gegenstand. War nur das Hauptrepository erfasst, oder auch Build-Infrastruktur, Paketkanal und veröffentlichte Artefakte?

Die offiziellen Unterlagen liefern die fehlenden Koordinaten. Der Index bezeichnet v2026.08.28 als aktuelle Version für neue Konformitätsarbeiten, führt frühere Fassungen als historische Referenzen weiter und trennt die Entwicklungsfassung davon. Die FAQ lässt Selbstattestierung zu, bezeichnet Konformität als Zeitpunktstatus und empfiehlt die Angabe von Stichtag, Version und Stufe.

Ein Bezeichner ersetzt keine Version

Das Wartungsverfahren nutzt kalendarische Kennungen im Format YYYY-MM-DD. Eine wesentliche Bedeutungsänderung erhält eine neue Kontrollkennung. Kleinere Änderungen, auch ein Wechsel der Stufe, können dieselbe Kennung behalten. Wer nur OSPS-… speichert, kann deshalb die damals geprüfte Verpflichtung nicht immer rekonstruieren. Die eingefrorene Version gehört zum Nachweis.

Die Stufe bestimmt die Auswahl. In der Fassung 2026.08.28 gilt Level 1 für jedes Code- oder Nicht-Code-Projekt. Level 2 richtet sich an Codeprojekte mit mindestens zwei Maintainers und wenigen regelmäßigen Nutzern, Level 3 an Codeprojekte mit vielen regelmäßigen Nutzern. Eine Aussage ohne Level verschweigt die Reifegrenze, die den Prüfumfang geprägt hat.

Das Datum begrenzt die Lebensdauer. Berechtigungen, Branch-Regeln, Veröffentlichungswege, Sicherheitskontakte und Release-Verfahren ändern sich. Ein signiertes Manifest kann eine Ausgabe abdecken, ohne die nächste zu erfassen. Ein alter Befund bleibt nicht aktuell, nur weil das Tabellenfeld grün bleibt.

Der Umfang bindet diese Angaben an reale Oberflächen. Ein Projektname kann Hauptrepository, Unterprojekte, Website, Paketregister, Build-System und mehrere Wartungslinien umfassen. Die Baseline-Kontrollen unterscheiden selbst zwischen Projekt, maßgeblichem Repository, Versionsverwaltung, Pipeline und offizieller Veröffentlichung. Der Nachweis muss dem jeweiligen Subjekt folgen.

Selbstattestierung macht eine Grenze sichtbar

Eine Selbstattestierung ist kein unabhängiges Audit. Sie kann dennoch Einstellungen offenlegen, die ein öffentlicher Scanner nicht sehen darf. Die FAQ unterscheidet öffentlich beobachtbare Kontrollen von privilegierten Konfigurationen und lässt dem nachgelagerten Nutzer die Wahl, die Aussage anzunehmen oder eine andere Prüfung zu vereinbaren.

Daher müssen attestierende Stelle und Sichtbarkeit jedes Belegs erfasst werden. Sicherheitsrichtlinie, Beitragsleitfaden, Historie oder Release-Manifest können öffentlich sein. Berechtigungen können unter Vertraulichkeit von einer Stiftung oder einem Kunden geprüft werden. „Verifiziert“ braucht Prüfer, Methode, Gegenstand und Zeitpunkt. Ein fehlender öffentlicher Link ist weder automatisches Bestehen noch automatisches Scheitern.

Auch Zuordnungen zu anderen Rahmenwerken haben eine Grenze. Version 2026.08.28 beschreibt sie als Referenzen, nicht als garantierte Volltreffer oder funktionale Verknüpfungen. Laut FAQ begründen sie keine Konformität mit externen Katalogen und ersetzen weder Audit noch Zertifizierung. Eine Tabellenverknüpfung erzeugt keine NIST-, ISO- oder regulatorische Konformität.

Aus dem Etikett wird ein Belegsatz

Der minimale Belegsatz nennt Projekt, Repositories, Unterprojekte und Releases im Umfang; OSPS-Version und Level; Bewertungsdatum; attestierende Stelle und Befugnis; anwendbare Kontrollen; Beleg und Beobachtungszeit je Kontrolle; eingeschränkte Beweise; Ausnahmen und Nichtanwendbarkeit; sowie Frist oder Änderung für die nächste Prüfung.

Er verspricht keine Fehlerfreiheit, genehmigt keine Abhängigkeit, zertifiziert kein Binärpaket und prognostiziert keine Bereitstellung. Er ermöglicht die kleinere, belastbare Aussage: Was wurde gegenüber welchem Text, für welche Oberfläche und zu welchem Zeitpunkt erklärt?

Baseline-Maintainers veröffentlichen die gemeinsame Sprache. Das Projekt beschreibt seinen Zustand. Ein Dritter kann Belege prüfen. Der Produktverantwortliche entscheidet weiterhin über eine konkrete Version und Nutzung. Koordination verschmilzt diese Befugnisse nicht.

Die grüne Zelle kann als Link bleiben: „OSPS v2026.08.28, Level 2, bewertet 2026-09-07“. Kürze ist dann eine Ansicht des vollständigen Datensatzes statt seines Ersatzes.

Quellen

  1. Versionsindex der OSPS Baseline
  2. OSPS Baseline Version 2026.08.28
  3. FAQ der OSPS Baseline
  4. Wartungsverfahren der OSPS Baseline
  5. Projekt-Governance der OSPS Baseline