Die neue Handreichung wurde in dieser Woche veröffentlicht und schreibt die bisherigen Mindestanforderungen für SBOMs fort. Inhaltlich ist sie keine grundlegende Neuausrichtung, ergänzt aber zehn neu definierte Elemente und überarbeitet etwa ein Dutzend bestehender Angaben. Zu den neuen Pflichtangaben zählen laut Quelltext eine digitale Signatur, die Integrität und Authentizität einer SBOM nachweisen soll, sowie Name und Version des Werkzeugs, mit dem sie erstellt wurde.
Auch bestehende Elemente wurden angepasst. Besonders hervorgehoben wird der Wechsel vom bisherigen Merkmal „Tiefe“ zu „Abdeckung“. Praktisch bedeutet das: SBOMs sollen nicht nur die direkt eingebundenen Abhängigkeiten eines Programms erfassen, sondern auch die Abhängigkeiten dieser Abhängigkeiten, ohne feste Begrenzung der Erfassungstiefe.
Jeff Williams bewertet diese Richtung zwar positiv, erwartet davon aber keinen großen praktischen Effekt. Er argumentiert, bestehende SBOM-Standards unterstützten solche transitiven Abhängigkeiten bereits, und viele Werkzeuge versuchten schon heute, sowohl diese als auch den Erzeugungskontext zu erfassen. CISA halte damit nach seiner Einschätzung vor allem fest, was Standards und Werkzeuglandschaft ohnehin bereits leisten.
Seine Kritik geht darüber hinaus. Williams bemängelt, dass die neue Leitlinie VEX nicht verankert. VEX, kurz für Vulnerability Exploitability eXchange, wurde von der NTIA als Schwesterkonzept zur SBOM entwickelt. Es soll nicht nur zeigen, ob Lieferketten-Schwachstellen in einem Stack vorhanden sind, sondern auch, ob sie tatsächlich ausnutzbar sind oder gar nicht aufrufbar beziehungsweise nicht exponiert.
Hinzu kommt aus seiner Sicht ein grundsätzliches Problem bei der Reichweite des Dokuments. CISA stelle Genauigkeit, Vollständigkeit und die Absicherung der Abdeckung ausdrücklich außerhalb des Umfangs der Leitlinie. Genau darin liege aber ein Großteil des Problems: Entscheidend sei nicht nur, welche Felder in eine SBOM gehören, sondern ob das Inventar korrekt ist, den tatsächlich ausgelieferten oder eingesetzten Stand abbildet und als Grundlage für reale Sicherheitsentscheidungen taugt.
Rechtlich bindend sind die CISA-Leitlinien nicht. Nach Darstellung des Quelltexts liegt es an Regulierern und häufiger an Kunden, von ihren Lieferanten die Einhaltung solcher bewährten Verfahren einzufordern. Ohne verbindliche Regulierung müssten Organisationen interoperable SBOMs auf Basis von CycloneDX oder SPDX verlangen, messbare Qualitätsstandards definieren, zeitnahe Aktualisierungen fordern und unvollständige oder unbrauchbare Einreichungen zurückweisen. Ebenso wichtig sei, die Informationen tatsächlich in Beschaffung, Schwachstellenmanagement und Reaktion auf Sicherheitsvorfälle einzusetzen, statt die bloße Erstellung einer SBOM bereits als Sicherheitsziel zu behandeln.
Einen Tag nach den neuen SBOM-Leitlinien legte CISA zudem eine gesonderte, thematisch verwandte Empfehlung zur Sicherheit von Open-Source-Software vor. Das Dokument behandelt den Einsatz, die Bewertung und die Veröffentlichung von Open-Source-Software. Neben etablierten Best Practices schlägt es vor, dass Behörden für selbst entwickelte Software einen Ansatz „standardmäßig Open Source“ verfolgen: Statt im Einzelfall zu entscheiden, ob Eigenentwicklungen offengelegt werden, sollen Behörden grundsätzlich von einer Veröffentlichung ausgehen, sofern keine guten Gründe dagegensprechen.
Außerdem nimmt CISA in dieser Open-Source-Empfehlung KI-Systeme in den Blick. In einer Pressemitteilung vom 30. Juli schrieb die Behörde, Trainingsdaten von KI-Modellen könnten Quelle zahlreicher Cyberrisiken sein, würden aber bislang nicht mit einer vergleichbaren Transparenz behandelt wie Software-Komponenten in SBOMs. Die Leitlinie fordere Behörden daher auf, ausreichende Transparenz über alle relevanten Komponenten einschließlich der Trainingsdaten zu erlangen. Nur mit Transparenz und Zugang könnten Behörden Software verstehen, auf Schwachstellen analysieren und gefundene Schwachstellen oder Risiken beheben.