CISA SBOM Rahmen-Dokument: Dritte Auflage
Interlynk
In den Vereinigten Staaten arbeitet die Cybersecurity and Infrastructure Security Agency (CISA) seit 2018 daran, Standards und die Einführung von Software Bill of Materials (SBOM) zu fördern.
CISAs Fokus liegt darin, die Nutzung von SBOM operativ umzusetzen und zu skalieren, indem Werkzeuge geteilt, Technologien empfohlen und Anwendungsfälle beschrieben werden. Gleichzeitig hat CISA an den zugrunde liegenden Anforderungen gearbeitet, um die nächste Phase der Einführung zu gestalten.
In der letzten Woche veröffentlichte CISA Framing Software Component Transparency, 3rd Edition, um diese nächste Phase voranzutreiben.
Hintergrund
Nach einem drastischen Anstieg von Angriffen auf die Software-Lieferkette, die mehrere Bundesbehörden betroffen haben, übernahmen NTIA und dann CISA die Aufgabe, die Transparenz in den Software-Lieferketten zu verbessern. CISA erkennt an, dass eine eingeschränkte Sichtbarkeit in diese Lieferketten zu höheren Risiken für die Cybersicherheit führt, die Kosten für den Technologiebetrieb erhöht und dazu ermutigt, Geschwindigkeit über Sicherheit zu stellen. Im Jahr 2018 arbeitete die NTIA mit Industrie- und Gemeinschaftspartnern zusammen, um die Software-Lieferketten transparenter zu gestalten, mit dem Ziel, Risiken, Kosten und die für die Bewältigung von Cybersicherheitsvorfällen benötigte Zeit zu reduzieren. Empfehlungen für Software Bill of Materials (SBOM) und Vulnerability Exploitability eXchange (VEX) sind aus diesen kollaborativen Arbeitsgruppen hervorgegangen.
Transparenz von Software-Komponenten gestalten
Die erste Auflage von Framing Software Component Transparency erschien 2019, gefolgt von der zweiten im Jahr 2021.
Die Arbeitsgruppe für SBOM-Tooling und -Implementierung ist verantwortlich für die dritte Auflage. Diese Gruppe hat das Ziel, ein Modell für Softwarekomponenteninformationen zu entwickeln, das branchenübergreifend offen geteilt werden kann.
In diesem Modell ist das Software-Bill-of-Materials (SBOM das zentrale Artefakt – es listet die Komponenten einer Software auf, enthält Eigentumsdetails und zeigt, wie die Komponenten miteinander verbunden sind.
Änderungen der dritten Auflage
Das Problem der Softwarebenennung - die Fähigkeit, eine Software oder ein Komponenten innerhalb des SBOM eindeutig zu identifizieren - ist eine der zentralen Herausforderungen bei der Verarbeitung von SOM. Der Schwerpunkt der dritten Auflage liegt darauf, Praktiken zu empfehlen, die helfen, diese Herausforderung anzugehen.
Um dies zu erreichen, konzentriert sie sich auf -
1. Die Deklaration eines erforderlichen Mindestsets an Baseline-Attributen, die notwendig sind, um Komponenten mit ausreichender relativer Einzigartigkeit zu identifizieren
2. Die Identifizierung zusätzlicher, optionaler Attribute und externer Elemente über das Baseline-Set hinaus, um eine Vielzahl von SBOM-Anwendungen zu bedienen und
3. Die Ermöglichung der Korrelation von SBOMs mit externen Quellen für relevante Analysen
Baseline-Attribute von Komponenten
Diese Auflage konzentriert sich auf die Definition der verpflichtenden Baseline-Attribute zur Identifizierung von Komponenten.
Ein Komponentenattribut Reifegrad ist ebenfalls für Organisationen/Tools festgelegt, die zusätzliche Details bereitstellen möchten, um umfassendere Anforderungen zu erfüllen.
Diese Reifegrade sind:
Erwartetes Minimum
Empfohlene Praxis
Inspirierendes Ziel
Die Liste der Baseline-Attribute ist wie folgt, zusammen mit ihrem Minimum und empfohlenen Details:
SBOM-Ebenenattribute
Zeitstempel
Type
Primäre Komponente
Komponentenebenenattribute
Komponentenname
Version
Lieferantenname
Minimum: Wenn die Komponente unverändert ist, verwenden Sie den Namen des vorhergehenden Lieferanten, andernfalls ersetzen Sie ihn durch den Namen des Lieferanten der primären Komponente
Einzigartige Identifikatoren
Empfohlen: Mindestens ein eindeutiger Identifikator für jede Komponente
Minimum: So viele global eindeutige Identifikatoren wie verfügbar für jede Komponente
Kryptographische Hashes
Empfohlen: Mindestens ein sicherer Hash und dessen Algorithmus für die primäre Komponente
Minimum: Mindestens ein Hash und dessen Algorithmus für jede Komponente, wenn bekannt
Beziehungen
Empfohlen: Beziehungen und deren Vollständigkeit für alle enthaltenen Komponenten
Minimum: Beziehungen und deren Vollständigkeit für die primäre Komponente und ihre direkten Abhängigkeiten
Lizenz
Empfohlen: Lizenzinformationen für so viele wie möglich
Minimum: Lizenzinformationen für die primäre Komponente
Urheberrechtshinweis
Empfohlen: Urheberrechtshinweis für so viele wie möglich
Minimum: Urheberrechtshinweis für die primäre Komponente
Darüber hinaus klärt diese Auflage, wie mit Szenarien umgegangen wird, wenn die Daten, die erforderlich sind, um das SBOM zu vervollständigen, unbekannt, nicht verfügbar oder nicht deklarierbar sind.
Unbekannte Komponentenattribute
Verwendung des Wertes "keine Behauptung" (d.h. Daten fehlen) anders als dem Wert "kein Wert" (d.h. das Attribut ist nicht anwendbar für dieses spezifische SBOM).
Nach allen angemessenen Bemühungen, "keine Behauptung" von den Baseline-Attributen zu eliminieren.
Redigierte Komponenten
Wenn eine Komponente eine Redigierung erfordert, muss sie weiterhin die Versionsnummer der Komponente und die kryptografischen Hashes zusammen mit ihren Abhängigkeitsbeziehungen bewahren.
Unbekannte Abhängigkeiten
Wenn ein SBOM bekannte unbekannte Abhängigkeiten enthält, müssen die Felder zur Beziehungsvollständigkeit verwendet werden, um den Vollständigkeitsstatus jeder Komponente zu deklarieren.
Zusätzliche Informationen
Die dritte Auflage klärt, wie das SBOM erweitert werden kann, um zusätzliche Anwendungsfälle durch Bereitstellung zusätzlicher Informationen zu unterstützen, wie -
End-of-Life-Daten oder Unterstützungsstufen für Komponenten
Angabe, welche Technologien eine Komponente implementiert oder unterstützt
SWID entfernt
In einer weiteren wesentlichen Änderung hat die dritte Auflage SWID aus dem empfohlenen Format entfernt und die Zuordnung für die verbleibenden SPDX- und CycloneDX-Formate aktualisiert.
Übereinstimmung mit der dritten Auflage
sbomqs - Interlynk's Open-Source-Multi-Spezifikations-SBOM Dienstprogramm wurde aktualisiert, um die Übereinstimmung mit der dritten Auflage der SBOM zu überprüfen. Mit der Build-Version 0.2.2 oder höher kann sbomqs die Compliance der SBOM nach den folgenden Kriterien aufschlüsseln
Punktzahl für jedes Feld bei Abschluss
Prozentualer Abschluss eines bestimmten Basisattributs
Reifegrad des Basisattributs - Keine / Mindestanforderung / Empfehlung
Mit dem Befehl - sbomqs Compliance -f sbom.cdx.json --color
Zusammenfassung
CISA bleibt der Softwaretransparenz verpflichtet, und die SBOM-Working Groups tragen dazu bei, die SBOM zu standardisieren und operationalisieren, um die Transparenz des Software-Risikos zu verbessern. Die dritte Ausgabe von Framing Software Component Transparency enthält praktische Anleitungen für SBOM-Tool-Builder und -Betreiber, um Konsistenz in der SBOM-Generierung und einen echten Wert aus solchen SBOMs zu gewährleisten.
Bei Interlynk entwickeln wir unsere Open-Source-Tools und Plattformfähigkeiten weiter, während die Spezifikationen klärbar werden. Interlynks Open-Source-Utilities wie sbomqs und sbomasm sowie Interlynks kostenlose SBOM-Management-Plattform - https://app.interlynk.io/ bleiben die vertrauenswürdigsten und aktuellsten Utilities für die Arbeit mit SBOM.