Diese Rolle spielt SBOM für Cybersicherheit

Eine kürzlich durchgeführte Umfrage zeigt, wie Unternehmen im Jahr 2022 die Sicherheit in der Software-Lieferkette erhöhen wollen. Ziel ist es, sich vor Angriffen zu schützen, die Sicherheitslücken ausnutzen.

 Die Studie wurde im Dezember 2021 mit 428 Führungskräften aus den Bereichen IT, Sicherheit und Entwicklung durchgeführt. Somit fiel die Erhebung in den Zeitraum kurz vor der Offenlegung der Log4j-Schwachstelle. Log4j ist eine Open-Source-Java-Bibliothek, die von der Apache Foundation entwickelt wurde, und bei Anwendungs- und Dienstentwicklern im Internet weit verbreitet ist. Die von den Befragten unmittelbar nach dem Vorfall beobachteten Auswirkungen auf die Cybersicherheit der Software-Lieferkette wurden als erheblich oder mäßig eingestuft.

Für 54 % der Befragten wird die Sicherheit der Software-Lieferkette im Jahr 2022 ein wichtiges Thema sein – wenn sie nicht sogar das Hauptaugenmerk darauf legen. Und bereits jetzt setzen 76 % der großen Unternehmen verstärkt auf die sogenannte Software Bill of Materials (SBOM). Das lässt vermuten, dass SBOM-Abläufe, die das Ziel haben, die Sicherheit der Software-Lieferkette zu verbessern, an Bedeutung gewinnen. Bis jetzt verfügen allerdings nur 18 % der Befragten über vollständige SBOMs für alle Anwendungen. Weniger als ein Drittel der Befragten befolgt Best Practices für die Pflege eines SBOM-Repositorys und die Anforderung von SBOMs von Anbietern.

„Die wichtigste Maßnahme besteht jetzt darin, SBOMs zu erstellen und zu speichern – am besten für die gängigsten Anwendungen, die Unternehmen entwickeln und verwenden. Das dient als Basis und sorgt für Transparenz bei den Softwarekomponenten, von denen sie abhängen und die sie nach der Bereitstellung auf Anwendungssicherheit überwachen müssen. Mit solchen SBOMs sind Unternehmen in der Lage, schnell auf die nächste Zero-Day-Schwachstelle zu reagieren“, so Josh Bressers, Vice President of Security bei Anchore, dem Unternehmen, das die oben genannte Studie durchgeführt hat.

Der Begriff SBOM bezeichnet die Menge der Komponenten und Bibliotheken sowie ihre jeweiligen Lizenzen und Abhängigkeiten, aus denen eine Softwareanwendung besteht. Es handelt sich um Dokumente, die von Maschinen interpretiert werden können und als natürliches Nebenprodukt moderner Entwicklungsprozesse angesehen werden. Das SBOM-Konzept gibt es bereits seit einem Jahrzehnt in der IT-Welt. An Aufmerksamkeit hat es jedoch erst gewonnen, seitdem verstärkt Mittel zur Gewährleistung der Sicherheit der Software-Lieferkette eingesetzt werden.

“Seit Jahren diskutieren wir über die Idee, dass Software und Cloud-Dienste über zuverlässige SBOMs verfügen sollten. Sie sollen transparent machen, welche Fehler für verwendete Produkte wirklich kritisch sind”, kommentiert Paul Ducklin, Principal Security Researcher bei Sophos.

Sogar die US-Regierung scheint dem SBOM-Problem in letzter Zeit Aufmerksamkeit zu schenken. Unter anderem forderte Präsident Biden in einer Durchführungsverordnung zur Cybersicherheit die Ausarbeitung von Richtlinien. Diese sollen spezifizieren, was genau SBOMs enthalten sollen.

„Ein weit verbreitetes, maschinenlesbares SBOM-Format sorgt für mehr Nutzen durch Automatisierung und Integration über Tools. SBOMs gewinnen an Wert, wenn sie gemeinsam in einem Repository gespeichert werden, das von anderen Anwendungen und Systemen leicht referenziert werden kann. Das Verständnis der Software-Lieferkette, die Entwicklung von SBOMs und deren Verwendung zur Analyse von Schwachstellen ist für das Risikomanagement von entscheidender Bedeutung“, heißt es in der Anordnung.

Die Regierungsinitiativen zum Thema SBOM werden von Allan Friedman, Senior Consultant und Stratege bei der CISA (Cybersecurity and Infrastructure Security Agency), geleitet und umfassen vier Arbeitsbereiche: Cloud- und Online-Anwendungen, Tools und Implementierung, gemeinsame Nutzung und Austausch von SBOMs sowie Zugang und Übernahme.

Aber woran liegt es, dass die Maßnahmen im Zusammenhang mit SBOMs bislang noch nicht so richtig in Gang gekommen sind? Für Eric Byres, Chief Technology Officer bei aDolus, sei es einfach, SBOMs zum Zeitpunkt der Entwicklung zu erstellen. Aber was ist mit den Anwendungen (nur im Binärcode), die bereits installiert sind und weltweit genutzt werden? Diese Kategorie mache etwa 95 % der Software aus, die heute in kritischen Systemen verwendet wird, sagt er. Außerdem handele es sich bei den heutigen SBOMs um statische Dokumente, die nicht in der Lage sind, Updates automatisch zu übernehmen.

Die Umwandlung einer großen Menge von SBOM-Daten in Informationen ist nach Ansicht von Byres ebenfalls eine große Herausforderung. Notwendig seien Maßnahmen, die er als SBOM-Anreicherung bezeichnet: die Listen der rohen Softwarekomponenten verwenden, die Risikofaktoren für jede einzelne bestimmen und Prioritäten festlegen.

Um die neue Aufgabe der Verwaltung von SBOMs zu erleichtern, werden bereits Ansätze zur Erstellung, Verwaltung und Verwendung von SBOMs veröffentlicht, die die wichtigsten Phasen des Software-Lebenszyklus abdecken. Dies umfasst die folgenden Punkte:

1. Speichern und Verwalten von SBOMs in einem zentralen Repository;

2. Übernahme von SBOM-Standards. Software Packet Data Exchange (SPDX), das seit über einem Jahrzehnt zur Dokumentation von Softwarekomponenten verwendet wird, ist jetzt beispielsweise ein international anerkannter SBOM-Standard;

3. Ausarbeitung von SBOMs für jegliche Software, die im Unternehmen integriert wird;

4. Generierung von SBOMs in jedem Schritt des Entwicklungsprozesses und für jeden Build;

5. Erstellung umfassender SBOMs für jede Version der Software, die bereitgestellt oder geliefert wird;

6. Verwendung von Automatisierungstools für die Durchsetzung von Richtlinien und Warnmeldungen.