Zum Inhalt springen
Craftifact

CRA-relevante Software-Lieferketten-Workflows

Wie du Craftifact-Workflows für Artefakte, SBOMs, Schwachstellen, Zugriff, Backups und APIs auf CRA-relevante technische Vorbereitung abbildest.

Nutze diese Anleitung als Workflow-Karte für technische Vorbereitung rund um CRA-relevante Nachweise in der Software-Lieferkette. Sie ist keine Rechtsberatung, trifft keine Compliance-Entscheidung und ersetzt weder Produktrisikobewertung, Vulnerability-Disclosure-Verantwortung, gesetzliche Meldeprozesse noch die Auslieferung von Updates an Nutzer.

Das Ziel ist enger: Release-Artefakte, SBOMs, Schwachstellen-Kontext, Zugriffskontrollen und Informationen zur betrieblichen Kontinuität sollen so verbunden sein, dass deine eigenen Workflows für CRA-Vorbereitung und Audit-Unterstützung belastbare technische Eingaben haben.

Kurzpfad

  1. Identifiziere die Release-Artefakte oder OCI-Digests, die zu der geprüften Softwareversion gehören.
  2. Hänge CycloneDX-SBOMs an diese Subjects an oder lasse sie durch Craftifact erzeugen.
  3. Prüfe Abhängigkeits- und Komponentenübersicht aus der effektiven SBOM.
  4. Prüfe Schwachstellen-Findings, Scan-Status und Freshness, bevor du ein Ergebnis als aktuell behandelst.
  5. Dokumentiere Suppressions nur mit engem Scope, Ablaufdatum und einer Begründung, die eine andere prüfende Person verstehen kann.
  6. Prüfe Zugriff über RBAC, Gruppen, Robot-Accounts und scoped Tokens.
  7. Nutze APIs, um Artifact-IDs aufzulösen, SBOMs hochzuladen, gespeicherte Schwachstellenberichte abzurufen und technische Evidence-Bundles für explizite Subject-Sets zu exportieren.
  8. Nutze die Backup- und Restore-Dokumentation als Kontext für betriebliche Kontinuität rund um die Repository-Daten hinter diesen Workflows.

Evaluierungs-Checkliste

Nutze diesen Abschnitt, wenn du Nachfragen zu verwendeten Abhängigkeiten, bekannten Schwachstellen, Lizenzen, Suppressions oder Zugriffen für ein konkretes Release beantworten musst. Wende jeden Punkt auf ein konkretes Release, eine konkrete Artefaktmenge oder eine konkrete OCI-Digest-Menge an.

  • Release-Subjects: Identifiziere die exakten Paketartefakte oder OCI-Digests in Browse und halte die geprüfte Release-Menge fest. Halte Release-Zuordnung, Support-Zeiträume und Produktrisiko-Entscheidungen in deinem eigenen Release-Datensatz; Craftifact-Evidence-Exporte arbeiten mit expliziten Paketartefakt- und OCI-Subject-Sets.
  • SBOM-Abdeckung: Prüfe, ob jedes Subject eine hochgeladene oder von Craftifact generierte SBOM hat und ob die Verarbeitung bereit ist. Craftifact unterstützt heute CycloneDX JSON, mit generierten SBOMs für ausgewählte Hosted-Maven- und OCI-Inhalte.
  • Komponentenprüfung: Nutze Browse -> Detailbereich -> Insights -> Dependencies für die Komponenten aus der effektiven SBOM. Behandle breitere Repository-Suchen als Kontext, nicht als Nachweis, dass eine Release-Menge vollständig ist.
  • Schwachstellenstatus: Nutze Findings -> Vulnerabilities, um Severity, KEV, EPSS, Scan-Status und Freshness zu prüfen. Pending, failed, invalid, skipped oder stale Zustände brauchen Nacharbeit.
  • Suppression-Begründung: Prüfe aktive Suppressions auf Scope, Ablaufdatum und Begründung. Eine Suppression bewahrt eine Triage-Entscheidung; sie belegt nicht, dass ein Risiko rechtlich akzeptabel ist.
  • Zugriff und Automation: Prüfe RBAC, Gruppen, Robot-Accounts, Token-Scopes und Identity-Provider-Setup für die Repositorys hinter dem Release-Workflow. Kundenseitige Access Reviews und Release-Abnahmen bleiben außerhalb von Craftifact.
  • Policy-Entscheidungen: Nutze Lizenz-Policies, Pull Gates, Held Artifacts, Fast-track-Entscheidungen und Decision Log, sofern diese Policies konfiguriert sind. Diese Signale unterstützen eine Release-Prüfung und können als technischer Evidence-Kontext enthalten sein, soweit Craftifact sie erfasst hat.
  • Kontinuitätskontext: Beziehe Backup- und Restore-Grenzen ein, wenn Repository-Verfügbarkeit oder Wiederherstellungserwartungen Teil der Evaluation sind. Backups unterstützen Kontinuität; sie belegen für sich genommen keine Schwachstellenbehandlung.

Craftifact kann technische Evidence-Bundles für explizite Paketartefakt- und OCI-Subject-Sets speichern und exportieren. Pflege Release-Zuordnung, Produktrisiko-Entscheidungen, rechtliche Schlussfolgerungen und formale Release-Freigaben in deinem eigenen Review-System und nutze Craftifact als Quelle für Artefakt-, SBOM-, Findings-, Zugriffs-, Policy- und technische Evidence-Eingaben.

1. Release-Subjects identifizieren

Starte mit den exakten Paketartefakten oder OCI-Digests, die zum geprüften Release gehören. Vermeide breite Repository-Aussagen, wenn die eigentliche Frage eine konkrete Version, ein Image oder einen Digest betrifft.

In Craftifact nutzt du Browse, um bekannte Artefakte und OCI-Inhalte zu prüfen. Wenn Automation vor einem SBOM-Upload oder Report-Lookup die Paket-Artefaktkennung braucht, löst du die artifact_id über die Artefakt-Suche API aus repository-spezifischen Koordinaten, Pfad, Dateiname oder Digest auf.

Halte deinen externen Release-Datensatz getrennt von Craftifact, wenn er produktbezogene Metadaten wie Support-Zeiträume, Auslieferungsdaten an Nutzer oder Produktrisikobewertungen braucht. Craftifact liefert die Artefakt- und Supply-Chain-Datenschicht, nicht das gesamte Release-Governance-System.

2. SBOMs anhängen oder erzeugen

Für CRA-relevante Vorbereitung ist technisch wichtig, dass jedes geprüfte Subject eine nutzbare SBOM in einem gängigen maschinenlesbaren Format hat. Craftifact unterstützt CycloneDX JSON.

Nutze SBOMs mit Client-Tools erzeugen für die praktischen Paket- und OCI-Workflows:

  • Maven und Gradle können häufig ein CycloneDX-Sidecar publizieren.
  • Poetry, Twine, npm und OCI-Workflows publizieren üblicherweise zuerst und laden die SBOM danach hoch.
  • Craftifact kann SBOMs für unterstützte Hosted-Maven- und OCI-Inhalte erzeugen.

Für Automation bleibt der exakte Request-Vertrag in der SBOM-Upload-API. Das Upload-Ziel ist entweder eine Paket-artifact_id oder ein OCI-Digest zusammen mit dem Repository.

3. Komponenten prüfen

Nach abgeschlossener SBOM-Verarbeitung nutzt du Abhängigkeiten erkunden, um die Komponenten aus der effektiven SBOM zu prüfen.

Der zuverlässigste Weg startet beim konkreten Subject:

  1. Öffne das Artefakt, den OCI-Tag oder den OCI-Digest in Browse.
  2. Nutze im Detailbereich Insights -> Dependencies.
  3. Prüfe die subject-spezifische Ansicht Dependencies.
  4. Nutze Consumer- und Findings-Handoffs nur, wenn du breiteren Kontext brauchst.

So bleibt die Komponentenprüfung an genau das Artefakt oder Image gebunden, das du evaluierst.

4. Schwachstellen und Freshness prüfen

Nutze Schwachstellen-Findings prüfen, wenn das Subject eine effektive SBOM hat und du Schwachstellen-Kontext brauchst.

Bevor du das Ergebnis in einem Audit-Unterstützungs-Workflow nutzt, prüfe:

  • ob der Scan bereit, pending, failed, invalid, skipped oder stale ist,
  • ob generierte SBOM-Daten oder Schwachstellendatenbank-Daten als stale markiert sind,
  • ob Prioritätssignale wie KEV oder EPSS beim Erzeugen des Ergebnisses verfügbar waren,
  • ob aktive Suppressions das sichtbare Risikobild verändern.

Automation kann denselben subject-spezifischen Bericht über die SBOM-Schwachstellenbericht-API lesen. Behandle pending, failed, invalid, skipped oder stale Zustände als Kontext mit Nacharbeit, nicht als Nachweis, dass kein relevantes Problem existiert.

5. Suppressions eng dokumentieren

Suppressions sind nur dann hilfreich, wenn sie die Begründung hinter einem akzeptierten oder verschobenen Finding bewahren. Nutze sie für dokumentierte Triage-Entscheidungen, nicht als dauerhaftes Verstecken.

Für CRA-relevante Vorbereitung sollte eine Suppression Folgendes haben:

  • den engsten praktikablen Scope,
  • ein Ablaufdatum,
  • eine Begründung, warum das Risiko akzeptiert, verschoben oder nicht anwendbar ist,
  • genug Kontext, damit eine spätere prüfende Person die Entscheidung ohne Rückfrage beim ursprünglichen Autor verstehen kann.

Suppression-Aktionen brauchen Berechtigungen zur Findings-Verwaltung. Die Anleitung zu Schwachstellen-Findings erklärt UI-Flow und Berechtigungsgrenze.

6. Zugriff und Automatisierungszugänge prüfen

CRA-relevante Nachweise sind schwächer, wenn Repository-Zugriff unklar ist. Prüfe, wer die Repositorys hinter dem Release-Workflow veröffentlichen, lesen, administrieren und automatisiert nutzen darf.

Nutze diese Dokumentationspfade:

Wenn Automation Artefakt-, SBOM- oder Schwachstellendaten abruft, nutze bevorzugt scoped Robot-Account-Tokens statt persönlicher Zugangsdaten.

7. APIs und Exporte für Audit-Unterstützungs-Workflows nutzen

Für wiederholbare Nachweissammlung sind APIs meist besser als Screenshots:

  • Die Artefakt-Suche API löst vorhandene Paket-Artifact-IDs aus repository-spezifischen Koordinaten oder Dateiattributen auf.
  • Die SBOM-Upload-API lädt CycloneDX-SBOMs hoch und bindet sie an ein Paketartefakt oder OCI-Subject.
  • Die SBOM-Schwachstellenbericht-API liest den gespeicherten Schwachstellenbericht für ein SBOM-gestütztes Paketartefakt oder OCI-Subject.
  • Die Evidence-Snapshots-API erstellt technische Evidence-Snapshots für explizite Paketartefakt- und OCI-Subject-Sets.

Wenn eine prüfende Person ein herunterladbares Bundle für einen vorhandenen Snapshot braucht, exportiere ihn über GET /api/evidence/snapshots/{snapshot_id}/export/. Wenn die prüfende Person direkt aus der aktuellen Browse- oder Dependencies-Auswahl einen frischen Single-Subject-Snapshot braucht, erstelle ihn über die UI-Aktion. Craftifact öffnet den neuen Snapshot in der Evidence-Ansicht; dort kann die prüfende Person das Bundle herunterladen. Suppression-Akteur, Begründung und Scope-Felder sind Opt-ins beim Erfassen. Lass sie für Least-Privilege-Evidence weg; schließe sie nur ein, wenn die prüfende Person die Berechtigung findings:suppress für alle ausgewählten Repositorys hat und diese Werte für spätere Snapshot-Betrachter sichtbar sein sollen. KI-gestützte Workflows können MCP für Evidence-Sammlung mit mode=evidence_review und dem Prompt craftifact_collect_evidence_snapshot nutzen.

Nutze exportierte Bundles, wenn ein externer Audit-Unterstützungs-Workflow, ein Release-Archiv oder eine prüfende Person eine portable Kopie der technischen Evidence aus Craftifact braucht. Das Bundle ist technische Evidence für das explizite Subject-Set, keine Aussage dazu, ob das Set das vollständige Produkt-Release abbildet oder ob eine regulatorische Pflicht erfüllt ist.

8. Betriebliche Kontinuität mitdenken

Backups belegen für sich genommen keine Schwachstellenbehandlung, sind aber wichtig für Kontinuität rund um die Repository-Daten, die diese Workflows tragen.

Nutze Backup und Restore, um aktuelle Backup-Verfügbarkeit, Defaults je Plan, manuelle Backups, Restore-Pfade und Restore-Grenzen zu verstehen. Nimm diese Grenzen in deine eigenen betrieblichen Nachweise auf, wenn Repository-Verfügbarkeit und Wiederherstellungserwartungen Teil einer Evaluation sind.

Grenz-Checkliste

Nutze Craftifact für die technische Supply-Chain-Schicht:

  • Identifikation von Artefakten und OCI-Subjects,
  • CycloneDX-SBOM-Upload, Binding, Parsing und ausgewählte generierte SBOMs,
  • Komponentenübersicht aus SBOM-Daten,
  • Schwachstellen-Findings mit Freshness-Status und Suppressions,
  • RBAC, Gruppen, Robot-Accounts und scoped Tokens,
  • APIs für wiederholbare Artefakt- und Schwachstellen-Workflows,
  • technische Evidence-Snapshots und Exporte für explizite Paketartefakt- und OCI-Subject-Sets,
  • Backup- und Restore-Kontext für Repository-Kontinuität.

Dein Unternehmen bleibt verantwortlich für Product Security Engineering, rechtliche Bewertung, Release-Abnahme, Coordinated-Disclosure-Policy, verpflichtende externe Prozesse und Nutzerkommunikation. Kein einzelner Artefakt-Repository-Workflow erzeugt das vollständige regulatorische Ergebnis für einen Hersteller.

Verwandte Seiten