Sicherer Release: Signatur, Herkunft und Freigabe
Freigabe und Herkunft an die tatsächlich ausgelieferten Bytes binden.
Der Prüfauftrag
Arbeitsliste für Build-, Entwicklungs- und Deployment-Verantwortliche. Vertrauensanker und erwartete Herkunft vor der Artefaktprüfung festlegen; vorhandene Pipeline gezielt erweitern.
Am Ende hast du:Eine dokumentierte Erstprüfung mit nachvollziehbaren Nachweisen und einer Liste offener Maßnahmen.
Beweisen statt vermuten.
In einer isolierten Release-Prüfung ein nicht freigegebenes Testartefakt mit gültiger Signatur vorlegen; die Freigaberegel muss es dennoch zurückweisen.
Status, Prüfbereich und Notizen bleiben in diesem Browser. Keine Übertragung an MauriSec. Ohne Speicherung geht der Stand beim Verlassen verloren; gespeicherte Daten bleiben bis zu deiner Löschung. Keine Geheimnisse, Zugangsdaten oder fremden personenbezogenen Daten eintragen.
Quellrepository, Freigaberollen und Build-Workflow verbindlich zuordnen; Änderungen an Code und Pipeline vor Freigabe prüfen.
So belegst du es: Geschützte Änderungspfade, Review-Nachweise und benannte Verantwortliche.
Nachweis und nächsten Schritt notieren
Pipeline-Identitäten auf nötige Rechte begrenzen; kurzlebige Zugänge verwenden, wo unterstützt, und Geheimnisse aus nicht vertrauenswürdigen Builds heraushalten.
So belegst du es: Effektive Berechtigungen und getrennte Verarbeitung externer Pull Requests.
Nachweis und nächsten Schritt notieren
Build-Umgebung und Abhängigkeiten nachvollziehbar verwalten; Auflösung und Herkunft von Komponenten prüfen.
So belegst du es: Build-Konfiguration, aufgelöste Versionen sowie dokumentierte Abhängigkeitsquellen.
Nachweis und nächsten Schritt notieren
Komponentenübersicht beziehungsweise SBOM erzeugen und gegen relevante Schwachstellen bewerten; erreichbare betroffene Funktionen und Ausnahmen prüfen.
So belegst du es: Release-bezogene Komponentenliste und nachverfolgte Bewertung der Funde.
Nachweis und nächsten Schritt notieren
Ausgeliefertes Artefakt eindeutig über seinen kryptografischen Digest identifizieren; Integritätsinformationen aus vertrauenswürdiger Quelle beziehen.
So belegst du es: Digest der tatsächlich geprüften und anschließend eingesetzten Bytes.
Nachweis und nächsten Schritt notieren
Signaturen beziehungsweise Attestierungen gegen festgelegte vertrauenswürdige Schlüssel oder Identitäten prüfen.
So belegst du es: Verifizierungsprotokoll einschließlich des verwendeten Vertrauensankers.
Nachweis und nächsten Schritt notieren
Provenance zusätzlich gegen erwarteten Builder, Quellstand und Build-Parameter prüfen; eine gültige Signatur allein reicht nicht als Freigabe.
So belegst du es: Prüfregeln und negativer Test mit gültig signierter, aber unerwarteter Herkunft.
Nachweis und nächsten Schritt notieren
Deployment an das geprüfte Artefakt binden und ungeprüften Austausch über veränderliche Tags verhindern.
So belegst du es: Freigabenachweis, Deployment-Referenz und Übereinstimmung mit dem geprüften Digest.
Nachweis und nächsten Schritt notieren
Release, Herkunftsnachweise und Prüfentscheidungen geschützt archivieren; Rücknahme und Reaktion auf spätere Schwachstellen vorbereiten.
So belegst du es: Wiederauffindbarer Release-Satz und getesteter Eskalations-/Rücknahmeablauf.
Nachweis und nächsten Schritt notieren
Deine nächste Arbeit.
Beginne mit den vorrangigen Punkten. Markierte Lücken erscheinen hier mit deinen nächsten Schritten.
Grenzen und Primärquellen
Signaturen belegen unter definierten Vertrauensannahmen Integrität und Herkunft, nicht Fehlerfreiheit oder fachliche Freigabe. Eine SBOM ist keine automatische Vollständigkeitsgarantie. Provenance-Felder unterscheiden sich nach Format und Build-System. Ein dokumentierter SLSA-Level muss zur tatsächlich geprüften Plattform und Spezifikationsversion passen; hier wird kein Level verliehen.
NIST SP 800-218: Secure Software Development Framework ↗SLSA: Build - Verifying artifacts ↗NIST SSDF - vollständige Veröffentlichung ↗Prüfbericht / Selbsteinschätzung
Sicherer Release: Signatur, Herkunft und Freigabe · v2026.11 · 10.11.2026 ·
0/9 bearbeitet · 0 Lücken. Keine unabhängige Prüfung oder Zertifizierung.
1. Quellrepository, Freigaberollen und Build-Workflow verbindlich zuordnen; Änderungen an Code und Pipeline vor Freigabe prüfen.
Status: Offen
Erwarteter Nachweis: Geschützte Änderungspfade, Review-Nachweise und benannte Verantwortliche.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
2. Pipeline-Identitäten auf nötige Rechte begrenzen; kurzlebige Zugänge verwenden, wo unterstützt, und Geheimnisse aus nicht vertrauenswürdigen Builds heraushalten.
Status: Offen
Erwarteter Nachweis: Effektive Berechtigungen und getrennte Verarbeitung externer Pull Requests.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
3. Build-Umgebung und Abhängigkeiten nachvollziehbar verwalten; Auflösung und Herkunft von Komponenten prüfen.
Status: Offen
Erwarteter Nachweis: Build-Konfiguration, aufgelöste Versionen sowie dokumentierte Abhängigkeitsquellen.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
4. Komponentenübersicht beziehungsweise SBOM erzeugen und gegen relevante Schwachstellen bewerten; erreichbare betroffene Funktionen und Ausnahmen prüfen.
Status: Offen
Erwarteter Nachweis: Release-bezogene Komponentenliste und nachverfolgte Bewertung der Funde.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
5. Ausgeliefertes Artefakt eindeutig über seinen kryptografischen Digest identifizieren; Integritätsinformationen aus vertrauenswürdiger Quelle beziehen.
Status: Offen
Erwarteter Nachweis: Digest der tatsächlich geprüften und anschließend eingesetzten Bytes.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
6. Signaturen beziehungsweise Attestierungen gegen festgelegte vertrauenswürdige Schlüssel oder Identitäten prüfen.
Status: Offen
Erwarteter Nachweis: Verifizierungsprotokoll einschließlich des verwendeten Vertrauensankers.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
7. Provenance zusätzlich gegen erwarteten Builder, Quellstand und Build-Parameter prüfen; eine gültige Signatur allein reicht nicht als Freigabe.
Status: Offen
Erwarteter Nachweis: Prüfregeln und negativer Test mit gültig signierter, aber unerwarteter Herkunft.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
8. Deployment an das geprüfte Artefakt binden und ungeprüften Austausch über veränderliche Tags verhindern.
Status: Offen
Erwarteter Nachweis: Freigabenachweis, Deployment-Referenz und Übereinstimmung mit dem geprüften Digest.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
9. Release, Herkunftsnachweise und Prüfentscheidungen geschützt archivieren; Rücknahme und Reaktion auf spätere Schwachstellen vorbereiten.
Status: Offen
Erwarteter Nachweis: Wiederauffindbarer Release-Satz und getesteter Eskalations-/Rücknahmeablauf.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
Signaturen belegen unter definierten Vertrauensannahmen Integrität und Herkunft, nicht Fehlerfreiheit oder fachliche Freigabe. Eine SBOM ist keine automatische Vollständigkeitsgarantie. Provenance-Felder unterscheiden sich nach Format und Build-System. Ein dokumentierter SLSA-Level muss zur tatsächlich geprüften Plattform und Spezifikationsversion passen; hier wird kein Level verliehen.