Die Anforderungen der Cybersecurity-Verordnung an die Sicherheit der Software-Supply-Chain verstehen

Präsident Bidens Executive Order zur Cybersicherheit vom vergangenen Monat dürfte für alle, die im letzten Jahr die Schlagzeilen verfolgt haben, keine große Überraschung sein. Die Verordnung ist die wichtige Antwort der US-Bundesregierung auf eine lange Liste von Vorfällen, angefangen beim SolarWinds-Angriff bis hin zum jüngsten Ransomware-Angriff auf Colonial Pipeline – dem bislang größten bekannten Angriff auf ein US-Energieunternehmen.

Da viele der jüngsten Angriffe mit der Software-Supply-Chain zusammenhängen, überrascht es ebenfalls nicht, dass Softwaresicherheit und insbesondere die Sicherheit der Software-Supply-Chain ein wiederkehrendes Thema der Verordnung sind. Der inzwischen berüchtigte SolarWinds-Angriff betraf zahlreiche Regierungsbehörden, darunter das US-Verteidigungsministerium, das Außenministerium und das Ministerium für Innere Sicherheit, sowie private Unternehmen wie Microsoft, Intel und Cisco – und rückte das Thema Software-Supply-Chain-Sicherheit in den Mittelpunkt.

Angriffe auf die Software-Supply-Chain sind nichts Neues. Bei Snyk sprechen wir bereits seit 2018 darüber, dass moderne Softwareentwicklung und -komposition ein schwaches Glied und ein potenzieller Verbreitungsweg für Malware sind. Doch solche Angriffe werden immer beliebter, da sich die Art und Weise, wie Softwareanwendungen heute entwickelt werden, deutlich verändert hat. Präsident Bidens Verordnung erkennt diese Veränderungen an und soll die damit verbundenen Risiken minimieren. Dazu beauftragt sie das Handelsministerium, strenge Standards für Unternehmen festzulegen, die Software an die US-Bundesregierung verkaufen.  

Was sind Angriffe auf die Software-Supply-Chain?

Bei einem Angriff auf die Software-Supply-Chain verschaffen sich Angreifer Zugriff auf Software innerhalb der komplexen Softwareentwicklungskette und verändern sie, um ein nachgelagertes Ziel durch das Einschleusen von Schadcode zu kompromittieren. Ein Angriff auf die Software-Supply-Chain ist nicht das eigentliche Ziel. Er dient dazu, Angreifern eine Gelegenheit zu bieten, Malware einzuschleusen oder eine Hintertür für einen späteren Zugriff einzurichten. Beim SolarWinds-Angriff gelang es Hackern beispielsweise, auf die Netzwerk- und Anwendungsüberwachungsplattform Orion von SolarWinds zuzugreifen und über sie schädliche Updates an Tausende Nutzer der Software zu verteilen.

Angriffe auf die Software-Supply-Chain sind aufgrund der Art und Weise, wie moderne Software entwickelt wird, ein äußerst effektiver Angriffsvektor. Wie industrielle Lieferketten umfasst auch die Software-Supply-Chain Planung, Materialbeschaffung, Fertigung und Vertrieb. Anstelle von Materialien stützt sich die Software-Supply-Chain auf Code. Dieser Code kann proprietär sein, stammt aber zunehmend von Zulieferern – aus kommerziellen Quellen oder aus Open Source. Über diese Abhängigkeiten kann Schadcode in die Software eingeschleust werden. Code dient der Softwareentwicklung, und in der modernen Software-Supply-Chain umfasst die Entwicklung immer mehr Prozesse, die jeweils zur effektiven Verbreitung von Malware genutzt werden können.

Anforderungen der US-Bundesregierung an die Sicherheit der Software-Supply-Chain

Präsident Bidens Executive Order fordert eine Modernisierung der Cybersicherheit der US-Bundesregierung, eine bessere Kommunikation und Zusammenarbeit zwischen der Bundesregierung und dem Privatsektor im Bereich Cybersicherheit sowie eine höhere Sicherheit der von der Bundesregierung erworbenen Software. Das Risiko durch Angriffe auf die Software-Supply-Chain wird zu Beginn von Abschnitt 4 der Verordnung klar beschrieben:

Bei der Entwicklung kommerzieller Software fehlt es häufig an Transparenz, an ausreichendem Fokus auf die Widerstandsfähigkeit der Software gegenüber Angriffen und an angemessenen Kontrollen, um Manipulationen durch böswillige Akteure zu verhindern. Es besteht dringender Handlungsbedarf, strengere und besser vorhersehbare Mechanismen einzuführen, um sicherzustellen, dass Produkte sicher und wie vorgesehen funktionieren ... Daher muss die US-Bundesregierung Maßnahmen ergreifen, um die Sicherheit und Integrität der Software-Supply-Chain rasch zu verbessern ...

Zum Schutz von Regierungsbehörden vor diesem Risiko fordert die Verordnung NIST auf, Best Practices, Richtlinien und Kriterien für künftige Standards festzulegen, die Softwareanbieter erfüllen müssen, um Software an die US-Bundesregierung verkaufen zu können.

Software Bill of Materials (SBOM)

Nur ein kleiner Teil des Codes, aus dem Software besteht, wird von Grund auf intern entwickelt. Der Großteil stammt aus Open-Source- oder Drittanbieterkomponenten. Die Forderung der Verordnung nach einer Software Bill of Materials (SBOM) trägt diesem Umstand Rechnung und unterstreicht, wie wichtig mehr Transparenz darüber ist, was genau in einer Software enthalten ist, um das Risiko von Angriffen auf die Software-Supply-Chain zu mindern.  

Sichere Entwicklungsumgebung

Softwareanbieter müssen künftig eine sichere Entwicklungsumgebung bestätigen. Die Verordnung beauftragt NIST, Kriterien dafür zu erarbeiten, wann eine Entwicklungsumgebung als sicher gilt. Dazu gehören sichere Build-Prozesse, Datenverschlüsselung, Audits, Authentifizierung sowie die Überwachung und Verwaltung von Vorfällen.

Sichere Entwicklungsprozesse

Softwareanbieter müssen außerdem sichere Entwicklungspraktiken einhalten und die ergriffenen Maßnahmen nachweisen können. Dazu gehört der frühe und regelmäßige Einsatz automatisierter Sicherheitstests während der Entwicklung, um die Integrität des Codes sicherzustellen sowie Schwachstellen zu finden und zu beheben. „Artefakte“, die die Softwareentwicklung und die Ausführung der verwendeten Tools und Prozesse belegen, müssen auf Anfrage verfügbar sein.

Integrität von Open Source

Üblicherweise besteht der Code einer Anwendung zu 80–90 % aus Open-Source-Code. Die Verordnung trägt dieser Tatsache Rechnung und verlangt von Softwareanbietern, „die Integrität und Herkunft der in einem Produkt verwendeten Open-Source-Software sicherzustellen und zu bestätigen“.

Die Sicherheit der Software-Supply-Chain verbessern

Die Vorbereitung auf die NIST-Richtlinien beginnt damit, Ihre Software-Supply-Chain durch stärkere Anwendungssicherheit abzusichern. Snyk bietet eine Cloud-native Anwendungssicherheitsplattform, bei der Entwicklerinnen und Entwickler im Mittelpunkt stehen, und unterstützt den Großteil der in der Verordnung aufgeführten Anforderungen.

Entwicklerinnen und Entwickler befähigen

Die erfolgreiche Umsetzung der in der Executive Order geforderten sicheren Entwicklungspraktiken hängt davon ab, dass Entwicklerinnen und Entwickler Sicherheit einfach in ihren Entwicklungsworkflow integrieren können. Sichere Entwicklung beginnt bei den Entwickelnden selbst. Sie entscheiden, wie ihre Anwendungen aufgebaut werden, und tragen letztlich auch Verantwortung für Integrität, Qualität und Sicherheit ihres Codes. Herkömmliche Sicherheitsmodelle, die erst spät im Entwicklungsprozess eingebunden werden und mit unintuitiven Workflows zusätzliche Hürden schaffen, sind in einer schnelllebigen Entwicklungsumgebung keine Option mehr.

Snyks Ansatz: Entwicklerinnen und Entwickler mit entwicklerfreundlichen Tools und gezielter Unterstützung durch das Sicherheitsteam zu stärken. Die Snyk-Plattform wurde so konzipiert, dass sie ein Tool bietet, das Entwicklerinnen und Entwickler gern nutzen – ein Tool, das sich wie ein vertrauter Bestandteil ihres Toolkits verhält und aussieht und ihre Arbeit nicht ausbremst.

Automatisierte Sicherheit im gesamten SDLC

Um die Integrität von Software früh im Entwicklungsprozess sicherzustellen, fordert die Executive Order die frühzeitige Einführung automatisierter Sicherheitstests, „... die regelmäßig oder mindestens vor der Veröffentlichung eines Produkts, einer Version oder eines Updates ausgeführt werden sollen“. Die Kunden von Snyk nutzen verschiedene verfügbare Integrationen sowie die Snyk API, um Sicherheitstests in den unterschiedlichen Phasen des Softwareentwicklungsprozesses zu automatisieren. Das beginnt bereits in der lokalen Entwicklungsumgebung der Entwicklerinnen und Entwickler, setzt sich über Git-basierte Workflows und den Build-Prozess fort und reicht bis in die Produktionsumgebung. 

Den gesamten Code moderner Software absichern

Die Executive Order erkennt an, dass sich der Code, aus dem Anwendungen bestehen, verändert hat. Proprietärer Code, Open-Source-Pakete, Container und der Code für die Bereitstellung der Cloud-Infrastruktur (Infrastructure as Code) – all das sind Bausteine der modernen Software-Supply-Chain.

Damit Unternehmen dieses neue Risikoprofil verwalten und mindern können, ist ein ganzheitlicherer Ansatz für Anwendungssicherheit erforderlich. Sicherheitsteams, die sich auf Static Application Security Testing (SAST) konzentrieren, um den von ihren Entwicklungsteams geschriebenen Code abzusichern, übersehen die Risiken durch Open Source und Container – und umgekehrt bieten Tools für Software Composition Analysis (SCA) keine Abdeckung für proprietären Code. Die Snyk-Plattform bietet eine umfassende Lösung, bei der Entwicklerinnen und Entwickler im Mittelpunkt stehen, und hilft Unternehmen, den gesamten Code moderner Software abzusichern.

Nachweise und Berichte auf Komponentenebene

Wie oben beschrieben, spielen Transparenz gegenüber der US-Bundesregierung hinsichtlich der eingerichteten Prozesse und Maßnahmen sowie der verwendeten Materialien für die Softwareentwicklung in Form einer SBOM eine zentrale Rolle bei den Anforderungen der Executive Order. Snyk bietet umfangreiche Berichtsfunktionen, mit denen Sie SBOMs und andere Berichte anzeigen und exportieren können. Die Kunden von Snyk nutzen außerdem die Snyk API, um sich automatisch mit Reporting- und Schwachstellenmanagement-Tools von Drittanbietern zu integrieren und so die Sicherheits- und Compliance-Position ihres Unternehmens kontinuierlich zu überwachen.

Ausblick

Die Verordnung sieht vor, dass NIST innerhalb von sechs Monaten vorläufige und innerhalb eines Jahres endgültige Richtlinien veröffentlicht.  Die Anforderungen richten sich zwar an Unternehmen, die an die US-Bundesregierung verkaufen, doch dürften sich die Standards auch im Privatsektor durchsetzen und den gesamten Softwaremarkt beeinflussen.

Es empfiehlt sich, mit der Planung zu beginnen, indem Sie die Verordnung genau prüfen und wesentliche Lücken in Ihrer bestehenden Software-Supply-Chain ermitteln.

Bei Snyk verfolgen wir die Entwicklung der NIST-Richtlinien und informieren Sie in weiteren Beiträgen in unserem Blog. Bleiben Sie dran. Außerdem beteiligen wir uns aktiv an den NIST-Initiativen zur Umsetzung der Executive Order, insbesondere an den SBOM-Spezifikationen im Rahmen der SBOM SIG.

Wenn Sie mehr darüber erfahren möchten, wie Snyk Regierungsbehörden dabei unterstützt, die Anforderungen dieser Verordnung zu erfüllen, kontaktieren Sie uns unter snyk_federal@snyk.io oder besuchen Sie unsere Webseite Snyk for Government.