{"id":22149,"date":"2022-11-03T11:55:00","date_gmt":"2022-11-03T10:55:00","guid":{"rendered":"https:\/\/www.sysbus.eu\/?p=22149"},"modified":"2022-10-24T10:13:30","modified_gmt":"2022-10-24T08:13:30","slug":"sicherheit-und-compliance-auf-codeebene-was-sie-ueber-die-software-bill-of-materials-sbom-wissen-muessen","status":"publish","type":"post","link":"https:\/\/www.sysbus.eu\/?p=22149","title":{"rendered":"Sicherheit und Compliance auf Codeebene – Was Sie \u00fcber die Software-Bill-of-Materials (SBOM) wissen m\u00fcssen"},"content":{"rendered":"\n

Autorin\/Redakteur: Nicole Segerer, SVP and General Manager bei Revenera<\/a>\/gg<\/p>\n\n\n\n

Wer seine Software sch\u00fctzen will, muss wissen, was in ihr steckt. Tats\u00e4chlich haben Softwareanbieter jedoch oft wenig Einblick in die Nutzung von Open Source Software-Komponenten (OSS) und Drittanbieter-Code in ihren Anwendungen. Sicherheits- und Compliance-Risiken sind da vorprogrammiert. Die Software-Bill-of-Materials (SBOM) soll das \u00e4ndern.<\/p>\n\n\n\n

\"\"<\/a>
Quelle: Revenera<\/figcaption><\/figure>\n\n\n\n\n\n\n\n

Die Software-St\u00fcckliste gilt als Kernelement von Compliance- und Sicherheitsprogrammen rund um Open Source. Die detaillierte Auflistung aller in einer Software eingesetzten Code-Komponenten einschlie\u00dflich Lizenzierung, Versionen und Herkunft soll Anbietern wie K\u00e4ufern gleicherma\u00dfen helfen, den \u00dcberblick zu bewahren und die Software Supply Chain sicherer zu machen. Die formale und klar strukturierte SBOM gibt dabei nicht nur Aufschluss \u00fcber die jeweiligen Codebasen. Auch die Beziehungen innerhalb der Softwarelieferkette werden offengelegt. Aufgef\u00fchrt finden sich Pakete und Abh\u00e4ngigkeiten, Bin\u00e4rdateien ohne Manifest-Dateien, Multimedia-Dateien, Bilder\/Icons, Codecs und Copy\/Paste-Codes sowie die von den Entwicklern genutzten Source Libraries und Drittanbieter-Bibliotheken.<\/p>\n\n\n\n

Code-Verzeichnis f\u00fcr mehr Sicherheit und Compliance<\/strong><\/p>\n\n\n\n

Die Inventarliste hilft, zwei Fliegen mit einer Klappe zu schlagen: Zum einen l\u00e4sst sich anhand der SBOM genau einsehen, wo und wie der betroffene Code in die Software-Supply-Chain gelangt ist, welche Lizenzierung f\u00fcr die jeweiligen Komponenten vorliegen und wo die Verwendung eventuell zu Compliance-Problemen f\u00fchren kann. Zum andern k\u00f6nnen Sicherheitsteam schneller \u00fcberpr\u00fcfen, ob eine Anwendung von neu ver\u00f6ffentlichten Sicherheitsl\u00fccken und Exploits betroffen ist. Log4j bleibt hier ein abschreckendes Beispiel: Die Bedrohung durch die kritische Sicherheitsl\u00fccke wurde zum Teil dadurch versch\u00e4rft, dass viele Unternehmen nicht einmal wussten, ob sie betroffen waren.<\/p>\n\n\n\n

Beide Use Cases der SBOM sind dringend notwendig. Nach einem Report von Revenera<\/a> hat sich die Zahl der Sicherheitsl\u00fccken auf Codeebene mehr als verdreifacht. Die Analysten identifizierten pro Audit durchschnittlich 282 Schwachstellen, ein Anstieg von 217 Prozent (2021: 89). Von den aufgedeckten Schwachstellen stellten 27 Prozent ein \u201ehohes\u201c CVSS-Risiko dar (Common Vulnerability Scoring System) und damit eine unmittelbare Bedrohung f\u00fcr IT-Sicherheit und Cyberschutz. Wenig besser sieht es bei den in Audits aufgesp\u00fcrten Compliance-Verst\u00f6\u00dfen aus. Hier wuchs die Zahl der als kritisch eingestuften Risiken mit 9.500 um 6 Prozent (2021: 9.000), w\u00e4hrend Vorf\u00e4lle der Priorit\u00e4tsstufe 2 (zum Beispiel sekund\u00e4re Probleme mit kommerziellen Lizenzen) sogar um ganze 50 Prozent zulegten.<\/p>\n\n\n\n

Was geh\u00f6rt in eine SBOM?<\/strong><\/p>\n\n\n\n

Welche Informationen in welchem Umfang in einer SBOM aufgelistet h\u00e4ngt von der Anwendung selbst und von Faktoren wie Branche (zum Beispiel KRITIS), der Open Source Governance-Strategie des Anbieters sowie den Kundenanforderungen ab. Beim Erstellen einer SBOM empfiehlt es sich, zun\u00e4chst mit einem Basissatz an Daten zu beginnen, um so schnell zentrale Informationen mit anderen Stakeholdern (beispielsweise IT Sicherheit) teilen zu k\u00f6nnen. Im weiteren Verlauf wird die Liste dann kontinuierlich mit weiteren Daten angereichert und ausgebaut.<\/p>\n\n\n\n

Im Allgemeinen enth\u00e4lt die St\u00fcckliste Details zu Softwarekomponenten und -versionen, den Namen des Verfassers sowie des Anbieters\/Herstellers, Schwachstellen, Lizenzen, Bekanntmachungen von Dritten, Nutzungsdaten, Alerts und Meldungen sowie Aufgaben. Um die Komponenten eindeutig zuzuordnen und innerhalb der SBOM zu identifizieren, k\u00f6nnen Unternehmen zus\u00e4tzlich sogenannte Unique Identifiers (UI) wie kryptografischen Hashes hinzuf\u00fcgen.<\/p>\n\n\n\n

\"\"<\/a>
SBOM-Bestandposten (Quelle: Revenera)<\/figcaption><\/figure>\n\n\n\n\n\n\n\n

R\u00fcckverfolgbarkeit in der Software Supply Chain<\/strong><\/p>\n\n\n\n

Ein Ziel der SBOM ist es, den Weg jeder einzelnen der Komponenten entlang der Software Supply Chain l\u00fcckenlos zur\u00fcckverfolgen zu k\u00f6nnen und die komplexen Lieferketten in transparenter Art abzubilden. Neben den Basisinformationen m\u00fcssen daher auch die Verbindungen sowie direkte und transitive Abh\u00e4ngigkeiten zwischen den Komponenten erfasst und dokumentiert werden. Welche Subkomponenten sind in einer Komponenten enthalten (Child\/Parent Component)? Und von welchem Autor oder aus welcher Source Library stammen diese?<\/p>\n\n\n\n

Bei Erstellen einer SBOM beginnen Softwareanbieter und Entwicklerteams daher oft mit einer  einfachen Liste der Top-Level-Komponenten, die sich dann weiter nach unten verzweigt und die jeweiligen Subkomponenten einschlie\u00dflich ihrer Lizenzen und Schwachstellen auff\u00fchrt. Dabei ist es nicht unbedingt entscheidend, ob eine Subkomponenten im vollen Umfang oder nur teilweise, das hei\u00dft f\u00fcr bestimmte Funktionalit\u00e4ten in einer Anwendung, genutzt wird. Unabh\u00e4ngig von ihrer Rolle f\u00fcr die Software k\u00f6nnen auch ungenutzte Subkomponenten beispielsweise Sicherheitsschwachstellen enthalten, die sich auf die \u00fcbergeordnete Komponente auswirken. In der Fertigung, aus der die Bill-of-Material urspr\u00fcnglich stammt, werden solche mehrstufigen St\u00fccklisten auch als Multi-Level BOM bezeichnet.<\/p>\n\n\n\n

\"\"<\/a>
Beispiel SBOM (Quelle: Revenera)<\/figcaption><\/figure>\n\n\n\n

Standardformate f\u00fcr mehr Durchblick<\/strong><\/p>\n\n\n\n

Strukturierte Datenformate und Austauschprotokolle sind ein weiteres wichtiges Merkmal einer funktionalen SBOM. Einheitliche Formate bilden die Voraussetzung f\u00fcr Maschinenlesbarkeit von SBOMs und damit eine h\u00f6here Automatisierung bei der Analyse des Codes und der Aufdeckung von Sicherheits- und Compliance-Risiken. Die konsistente Notation von Informationen schafft nicht nur Transparenz und st\u00e4rkt das Vertrauen in den Code, sie reduziert auch den Arbeitsaufwand f\u00fcr Entwicklerteams und vereinfach die Zusammenarbeit zwischen Anbietern. Den einen Standard f\u00fcr den formalen Aufbau einer Software-St\u00fcckliste, das von allen Entwicklern und Anbietern einheitlich verwendet wird, gibt es leider nicht. In den letzten Jahren haben sich in der Branche jedoch einige Formate besonders stark etabliert. Dazu geh\u00f6ren SPDX, CycloneDX und SWID.<\/p>\n\n\n\n