CISA SBOM Framing Document: Dritte Ausgabe
| Interlynk
In den Vereinigten Staaten arbeitet die Cybersecurity and Infrastructure Security Agency (CISA) seit 2018 daran, Standards und die Einführung von Software-Stücklisten (Software Bill of Materials – SBOM) zu fördern.
Der Schwerpunkt der CISA liegt auf der Operationalisierung und Skalierung der SBOM-Nutzung durch den Austausch von Tools, die Empfehlung von Technologien und die Beschreibung von Anwendungsfällen. Gleichzeitig hat die CISA die zugrunde liegenden Anforderungen kontinuierlich weiterentwickelt, um sie an die nächste Einführungsphase anzupassen.
Letzte Woche hat die CISA das Dokument Framing Software Component Transparency, 3. Ausgabe veröffentlicht, um diese nächste Phase voranzutreiben.
Hintergrund
Nach einem rasanten Anstieg von Angriffen auf die Software-Lieferkette, die mehrere Bundesbehörden betrafen, übernahmen die NTIA und anschließend die CISA die Aufgabe, die Transparenz in Software-Lieferketten zu verbessern. Die CISA ist sich bewusst, dass eine eingeschränkte Sichtbarkeit dieser Lieferketten zu höheren Cybersicherheitsrisiken führt, die Wartungskosten für Technologien erhöht und dazu beiträgt, Schnelligkeit über Sicherheit zu stellen. Im Jahr 2018 schloss sich die NTIA mit Partnern aus der Industrie und der Community zusammen, um die Software-Lieferketten transparenter zu gestalten, mit dem Ziel, Risiken, Kosten und den Zeitaufwand für die Bewältigung von Cybersicherheitsvorfällen zu reduzieren. Aus diesen kollaborativen Arbeitsgruppen sind Empfehlungen für eine Software-Stückliste (Software Bill of Materials – SBOM) und den Vulnerability Exploitability eXchange (VEX) hervorgegangen.
Rahmenbedingungen für Transparenz bei Softwarekomponenten
Die erste Ausgabe von Framing Software Component Transparency erschien 2019, gefolgt von der second im Jahr 2021.
Die SBOM Tooling and Implementation Working Group war für die dritte Ausgabe verantwortlich. Diese Gruppe zielt darauf ab, ein Modell für Softwarekomponenten-Informationen zu entwickeln, das branchenübergreifend offen geteilt werden kann.
In diesem Modell ist die Software-Stückliste (Software Bill of Materials – SBOM) das zentrale Artefakt – sie listet die Komponenten einer Software auf, enthält Details zur Eigentümerschaft und zeigt, wie die Komponenten miteinander verbunden sind.
Änderungen der dritten Auflage
Das Problem der Software-Benennung – die Fähigkeit, eine Software oder Komponente innerhalb der SBOM eindeutig zu identifizieren – ist eine der zentralen Herausforderungen bei der Verarbeitung von SBOMs. Der Hauptfokus der dritten Ausgabe liegt auf der Empfehlung von Praktiken, die zur Bewältigung dieser Herausforderung beitragen.
Um dies zu erreichen, konzentriert sie sich auf –
1. Deklaration eines erforderlichen Mindestsatzes an Basisattributen (Baseline Attributes), die notwendig sind, um Komponenten mit ausreichender relativer Eindeutigkeit zu identifizieren
2. Identifizierung zusätzlicher, optionaler Attribute und externer Elemente über den Mindestsatz hinaus, um eine Vielzahl von SBOM-Anwendungen zu unterstützen und
3. Ermöglichung der Korrelation von SBOMs mit externen Quellen für relevante Analysen
Komponenten-Basisattribute
Diese Ausgabe konzentriert sich auf die Definition von verbindlichen Basisattributen (Baseline Attributes) zur Komponentenidentifikation.
Ein Reifegrad für Komponentenattribute (maturity level) wird ebenfalls für Organisationen/Tools spezifiziert, die zusätzliche Details bereitstellen möchten, um umfassendere Anforderungen zu erfüllen.
Diese Reifegrade sind:
Mindestens Erwartet
Empfohlene Praxis
Angestrebtes Ziel
Die Liste der Basisattribute lautet wie folgt, zusammen mit ihren minimalen und empfohlenen Details:
Attribute auf SBOM-Ebene
Zeitstempel
Typ
Hauptkomponente
Attribute auf Komponentenebene
Komponentenname
Version
Name des Lieferanten
Minimum: Wenn die Komponente unverändert ist, verwenden Sie den Namen des Upstream-Lieferanten, andernfalls ersetzen Sie ihn durch den Lieferanten der Hauptkomponente
Eindeutige Identifikatoren
Empfohlen: Mindestens ein eindeutiger Identifikator für jede Komponente
Minimum: So viele global eindeutige Identifikatoren wie für jede Komponente verfügbar sind
Kryptographische Hashes
Empfohlen: Mindestens ein sicherer Hash und sein Algorithmus für die Hauptkomponente
Minimum: Mindestens ein Hash und sein Algorithmus für jede Komponente, sofern bekannt
Beziehungen
Empfohlen: Beziehungen und deren Vollständigkeit für alle enthaltenen Komponenten
Minimum: Beziehungen und deren Vollständigkeit für die Hauptkomponente und ihre direkten Abhängigkeiten
Lizenz
Empfohlen: Lizenzinformationen für so viele wie möglich
Minimum: Lizenzinformationen für die Hauptkomponente
Urheberrechtshinweis
Empfohlen: Urheberrechtshinweis für so viele wie möglich
Minimum: Urheberrechtshinweis für die Hauptkomponente
Darüber hinaus klärt diese Ausgabe, wie mit Szenarien verfahren werden soll, in denen die zur Vervollständigung der SBOM benötigten Daten unbekannt, nicht verfügbar oder nicht deklarierbar sind.
Unbekannte Komponentenattribute
Ein unbekanntes Attribut sollte wie folgt behandelt werden:
Verwendung des Wertes „no assertion“ (d. h. Daten fehlen) im Unterschied zum Wert „no value“ (d. h. das Attribut ist für diese spezifische SBOM nicht anwendbar).
Nachdem alle zumutbaren Anstrengungen unternommen wurden, um „no assertion“ aus den Basisattributen zu eliminieren.
Schwärzung von Komponenten
Wenn eine Komponente geschwärzt werden muss, müssen die Komponentenversion und die kryptographischen Hashes zusammen mit ihren Abhängigkeitsbeziehungen weiterhin erhalten bleiben.
Unbekannte Abhängigkeiten
Wenn eine SBOM bekannte unbekannte Abhängigkeiten enthält, müssen die Felder für die Vollständigkeit der Beziehung verwendet werden, um den Vollständigkeitsstatus jeder Komponente zu deklarieren.
Ergänzende Informationen
Die dritte Ausgabe verdeutlicht die Erweiterung von SBOM zur Unterstützung zusätzlicher Anwendungsfälle durch die Bereitstellung ergänzender Informationen wie –
End-of-Life-Daten oder Support-Level für Komponenten
Angabe, welche Technologien eine Komponente implementiert oder unterstützt
SWID entfernt
In einer weiteren wichtigen Änderung wurde in der dritten Ausgabe SWID aus dem empfohlenen Format entfernt und das Mapping für die verbleibenden Formate SPDX und CycloneDX aktualisiert.
Übereinstimmung mit der dritten Ausgabe
sbomqs – Das Open-Source-Multi-Spezifikations-SBOM-Dienstprogramm von Interlynk wurde aktualisiert, um die SBOM-Konformität mit der dritten Edition zu überprüfen. Ab der Build-Version 0.2.2 oder neuer kann sbomqs die Compliance von SBOMs wie folgt aufschlüsseln:
Punktzahl für jedes Feld bei Fertigstellung
prozentuale Fertigstellung bestimmter Baseline-Attribute
Reifegrad des Baseline-Attributs – Keine / Minimum / Empfohlen
Mit dem Befehl - sbomqs compliance -f sbom.cdx.json --color
Zusammenfassung
CISA setzt sich weiterhin für Softwaretransparenz ein, und die SBOM-Arbeitsgruppen helfen dabei, SBOM zu standardisieren und zu operationalisieren, um die Transparenz von Softwarisiken zu verbessern. Die dritte Ausgabe von „Framing Software Component Transparency“ enthält praktische Anleitungen für Entwickler und Betreiber von SBOM-Tools, um Konsistenz bei der SBOM-Generierung und eine echte Wertschöpfung aus diesen SBOMs zu gewährleisten.
Bei Interlynk entwickeln wir unsere Open-Source-Tools und Plattformfunktionen weiter, sobald die Spezifikationen präzisiert werden. Die Open-Source-Dienstprogramme von Interlynk wie sbomqs und sbomasm sowie die kostenlose SBOM-Verwaltungsplattform von Interlynk – https://app.interlynk.io/ – bleiben die vertrauenswürdigsten und aktuellsten Dienstprogramme für die Arbeit mit SBOM.