Neue SBOM-Pflichten: CISA schreibt digitale Signatur und uneingeschränkte Abhängigkeitsabdeckung vor

Am 31. Juli 2026 hat die CISA gemeinsam mit 16 Behörden aus vier Kontinenten die aktualisierte Leitlinie zu den Mindestelementen für Software Bills of Materials veröffentlicht. Das Dokument ersetzt die NTIA-Richtlinien von 2021 und bringt zehn neue Pflichtfelder, den Wechsel vom Konzept der „Tiefe“ hin zur „Abdeckung“ sowie die Einführung einer digitalen Signatur, um Integrität und Authentizität zu belegen. Einen Tag später veröffentlichte die Behörde zudem einen separaten Leitfaden zur Sicherheit von Open Source.

Die zehn Felder, die das Software-Inventar neu gestalten

Die neue Leitlinie ergänzt zehn bislang fehlende Elemente. Das wirkmächtigste ist die digitale Signatur der SBOM, die deren Integrität und Authentizität in der gesamten Lieferkette gewährleisten soll. Hinzu kommt die Pflicht, Name und Version des zur Erzeugung des Inventars genutzten Werkzeugs anzugeben, zusammen mit weiteren Daten, die die Herkunft jeder Komponente nachvollziehbar machen.

Der ursprüngliche Entwurf von 2025 wurde nach Rückmeldungen von über 90 Organisationen – darunter Google, Microsoft und AWS – verfeinert. Das Ergebnis ist ein Anforderungskatalog, der zwar bereits verbreitete Praxis formalisiert – wie Jeff Williams von OWASP und Contrast Security anmerkt –, aber die von Softwareanbietern der Bundesregierung geforderte Transparenz verschärft.

Von der Tiefe zur Abdeckung: Keine Grenzen für indirekte Abhängigkeiten mehr

Die bedeutendste strukturelle Änderung betrifft den Umgang mit Abhängigkeiten. Bislang legte das Feld „depth“ eine maximale Verschachtelungstiefe fest. Die neue Leitlinie streicht es und führt das Feld „coverage“ ein: Ab sofort muss die SBOM alle transitiven Abhängigkeiten enthalten – also Abhängigkeiten von Abhängigkeiten – ohne jede Tiefenbegrenzung.

Dieser Wechsel zwingt Anbieter zu einer vollständigen rekursiven Analyse von Drittkomponenten und beseitigt blinde Flecken, in denen sich eine Schwachstelle in einem tiefer verschachtelten Paket verstecken konnte. Die Abdeckung wird zur absoluten Anforderung, nicht mehr parametrisierbar.

Was das für Softwareanbieter der US-Regierung bedeutet

Organisationen, die unter Bundeszulieferungskonformität arbeiten, müssen ihre SBOM-Erzeugungsprozesse an drei unmittelbare Vorgaben anpassen:

• Einbindung der digitalen Signatur;
• Erfassung des verwendeten Werkzeugs und dessen Version;
• Ausweitung der Analyse auf alle Abhängigkeitsebenen, ausnahmslos.

Es handelt sich nicht um revolutionäre Pflichten, denn Werkzeuge auf Basis von SPDX und CycloneDX bieten bereits viele dieser Funktionen. Die formelle Verschärfung erhöht jedoch den Einsatz für das Supply-Chain-Risikomanagement und die Konformität mit den aus den CISA-Vorgaben abgeleiteten Rahmenwerken.

Kritik: Ohne VEX und Verifikation bleibt die SBOM ein bruchstückhaftes Instrument

Laut Williams greift die Leitlinie zwei wesentliche Aspekte nicht auf. Es fehlt vor allem der VEX (Vulnerability Exploitability eXchange), ein Format, um die tatsächliche Ausnutzbarkeit von Schwachstellen im spezifischen Deployment-Kontext einzuordnen. Ohne ihn liefert die SBOM weiterhin CVEs-Listen, ohne bei der Priorisierung des Patchings zu helfen.

Der zweite Kritikpunkt ist die Überprüfung von Genauigkeit und Abdeckung. Die Leitlinie verlangt weder, dass das deklarierte Inventar tatsächlich dem ausgelieferten oder deployten Stand entspricht, noch sieht sie automatische Kohärenzprüfungen vor. Dies schränkt den praktischen Nutzen des Dokuments für alltägliche Sicherheitsentscheidungen ein. Bis zu einer Weiterentwicklung empfiehlt der Experte interne Prüfungen auf Vollständigkeit und Übereinstimmung zwischen SBOM und realen Artefakten.

Am Tag danach: Ein Leitfaden zur Open-Source-Sicherheit

Am 1. August veröffentlichte CISA einen zweiten Leitfaden, der sich Best Practices für die Sicherheit von Open-Source-Software widmet. Er ist keine direkte Ergänzung der neuen SBOM-Regelung, bildet aber gemeinsam mit dieser den Rahmen, mit dem die Behörde die Anforderungen an Transparenz und Sorgfalt in der Software-Lieferkette neu ausrichtet, und erstreckt die Vorgaben auch auf das Ökosystem offener Komponenten.