Ressourcen · 16
Software Supply Chain Assurance: Zu veröffentlichende Komponenten
Verbinden Sie Komponenten, Herkunft, Builds, Schwachstellen und Updates mit jedem tatsächlich bereitgestellten Release.
Aktualisiert · 2 min
Wozu dieser Leitfaden beiträgt
- Kennen Sie die tatsächlich ausgelieferten Abhängigkeiten
- Artefaktursprung überprüfen
- Priorisieren Sie Fehler im Kontext
- Testaustausch und Rollback
Kurzcheck
- Stimmt die Stückliste mit der bereitgestellten Version überein?
- Sind transitive Abhängigkeiten enthalten?
- Wer kann eine Freigabe unterzeichnen?
- Ist bei Ihrer Nutzung eine Schwachstelle erreichbar?
- Kann eine kritische Komponente ohne Improvisation entfernt werden?
Schritt-für-Schritt-Anleitung
- 1
Von der Karte ausgelieferte Versionen
Identifizieren Sie Repositories, direkte und transitive Abhängigkeiten, Build-Tools, Images, externe Dienste und Eigentümer. Verbinden Sie alle mit einer überprüfbaren Freigabe.
Lieferinhalt: Produkt-, Komponenten-, Versions- und Eigentümerkarte.
- 2
Erstellen Sie eine brauchbare Stückliste
Generieren Sie für jedes Release eine SBOM und vergleichen Sie diese mit den tatsächlich ausgelieferten Artefakten. Beheben Sie falsche Namen, fehlende Versionen und interne Komponenten.
Liefergegenstand: datierte und validierte SBOM.
- 3
Schützen Sie den Build
Veröffentlichungsrechte einschränken, sensible Phasen isolieren und Herkunft, Digests und Signaturen beibehalten. Überprüfen Sie diese Beweise vor der Bereitstellung.
Liefergegenstand: Build-Datensatz- und Verifizierungsrichtlinie.
- 4
Triage-Benachrichtigungen
Verknüpfen Sie jeden Schwachstellenhinweis mit der Komponente, der Version, der Gefährdung und der tatsächlichen Verwendung. Weisen Sie einen Eigentümer, eine Frist, eine Entscheidung und Abschlussnachweise zu.
Liefergegenstand: kontextbezogene Triage-Warteschlange.
- 5
Änderung proben
Ersetzen Sie eine kritische Komponente in einer Testumgebung, überprüfen Sie Geschäftsreisen und üben Sie Rollback. Messen Sie Abhängigkeiten, die die Änderung blockieren.
Liefergegenstand: Ersatz- und Fallback-Übungsbericht.
- 6
Beweissicherung
Überprüfen Sie Komponenten und Lieferanten bei Hauptversionen und nach Vorfällen. Bewahren Sie Aufzeichnungen für einen Zeitraum auf, der eine Untersuchung und Korrektur ermöglicht.
Liefergegenstand: Überprüfung des Kalenders und der Veröffentlichungshistorie.
Managementindikatoren
| Indikator | Was es misst | Erste Aktion |
|---|---|---|
| SBOM-Abdeckung | Ausgelieferte Releases mit geprüftem Komponentenbestand | Unstimmigkeiten vor der Veröffentlichung klären |
| Verifizierte Herkunft | Artefakte vor der Bereitstellung überprüft | Bei Blockfreigaben fehlen erwartete Beweise |
| Triage-Zeit | Zeit von der entsprechenden Mitteilung bis zur dokumentierten Entscheidung | Offengelegte Komponenten eskalieren |
| Reversibilität | Kritische Ersetzungen mit Rollback getestet | Blockierende Abhängigkeiten entfernen |
Häufige Fallstricke
- Verwechslung des Repository-Inventars mit bereitgestellten Komponenten
- Eine SBOM behalten, ohne sie zu aktualisieren
- Einstufung eines Fehlers nur nach Punktzahl
- Signieren eines Artefakts ohne Überprüfung der Build-Herkunft
Häufig gestellte Fragen
Ist eine SBOM ausreichend?
Nein. Es hilft bei der Identifizierung von Komponenten, aber auch Herkunft, Integrität, Offenlegung und Aktualisierungsfähigkeit müssen überprüft werden.
Sollte jede Schwachstelle eine Freigabe blockieren?
Entscheiden Sie anhand der tatsächlichen Nutzung, der Exposition, der kompensierenden Kontrollen und der Geschäftskritikalität und dokumentieren Sie die Begründung.
Welcher Referenzrahmen hilft?
Das NIST Secure Software Development Framework bietet sichere Entwicklungs- und Softwareschutzpraktiken über den gesamten Lebenszyklus hinweg.
Offizielle Referenzen
Die Referenzen unterstützen die Methode. Passen Sie die Prüfungen an Ihren Kontext an; sie stellen keine Zertifizierung dar. Originalreferenztitel und Quelldokumente können in einer anderen Sprache verfasst sein.
