Neue US-Cybersicherheit-Strategie: Auswirkungen auf die Softwareentwicklung

Anbieter sehen sich einem wachsenden gesetzlichen Sicherheits-Framework entlang des Software-Entwicklungszyklus (SDLC) und der Software Supply Chain gegenüber

Die US-Regierung hat am 2. März neue Richtlinien zur Stärkung der Cybersecurity vorgestellt. Ziel der National Cybersecurity Strategy ist es, die Software Supply Chain sicherer zu machen und Anwendungen und Systeme vor Angriffen und Ransomware-Attacken zu schützen. Das hat auch Auswirkungen auf Softwareanbieter und ihren Umgang mit Open Source Software(OSS)-Komponenten im Rahmen der Softwarenentwicklung.

Die USA hatte bereits 2021 mit einem Dekret damit begonnen, die Anforderungen für Unternehmen, die Software-Lösungen an amerikanische Bundesbehörden verkaufen, zu verschärfen. Die Executive Order (EO 14028) dient seitdem dem staatlichen National Institute of Standards and Technology (NIST) als Grundlage, um allgemeine Standards, Tools und Best Practices zu definieren. Dazu gehört auch die Bereitstellung einer Software Bill of Materials (SBOM) für jedes Softwareprodukt. Laut eines im September 2022 veröffentlichten Memos des Weißen Hauses sind alle bundesstaatlichen Behörden verpflichtet, die von NIST aufgesetzten Richtlinien innerhalb der nächsten zwei Jahren umzusetzen.

Die nun vorgelegte National Cybersecurity Strategy schließt an diese Maßnahmen an und verschärft sie. Im Mittelpunkt steht die Forderung nach einer engen Zusammenarbeit zwischen dem öffentlichen und dem privaten Sektor. Das Cybersicherheits-Konzept basiert dabei auf fünf Säulen:

Schutz kritischer Infrastrukturen (KRITIS)
Ausschalten bzw. Entschärfen von Threat Actors (Bedrohungsakteuren)
Marktregulierungen zur Förderung der nationalen (Cyber-)Sicherheit
Ausbau der Resilienz von Technologien und IT-Infrastrukturen
Internationale Partnerschaften zur Verfolgung gemeinsamer Ziele

Für Softwareanbieter und Entwickler dürfte die Strategie sowohl indirekte als auch direkte Folgen nach sich ziehen. So sollen Anbieter deutlich mehr Verantwortung bei der Umsetzung neuer Vorschriften und Standards übernehmen. Neben spezifischen Sicherheitsmaßnahmen könnten dazu in Zukunft auch regelmäßige Sicherheitsprüfungen und Audits. Wachsende Bedeutung erhält zudem die Implementierung sicherer Verfahren und Praktiken entlang des Software Development Cycles (SDC). Um Prozesse rund um das Durchführen von Sicherheitstests, die Bewertung von Schwachstellen und die Modellierung von Bedrohungen intern neu aufzusetzen, werden Anbieter in den meisten Fällen wohl in zusätzliche Ressourcen und Tools investieren müssen. Zumal die Häufigkeit von Sicherheitstest dem Veröffentlichungszyklus der Softwareprodukten angepasst werden soll.

Darüber hinaus werden Softwarehersteller angehalten, die Zusammenarbeit mit Regierungsbehörden weiter zu intensivieren. Noch ist nicht zu 100 Prozent klar, wie umfangreich dieser Austausch ausfallen soll. Möglichkeiten zur Kollaboration ergeben sich theoretisch viele – von der gemeinsamen Entwicklung neuer Cybersicherheitslösungen über das Software Vulnerability Management bis hin zur Etablierung von Sicherheitskontrollen für externe Software-Lieferanten. So oder so können Anbieter jedoch mit einem deutlichen Mehraufwand rechnen. Überhaupt fordert die US-Regierung einen höhere Transparenz, was die Offenlegung von Sicherheitspraktiken und Risikobewertung angeht.

„Die von der US-Regierung vorgestellte Cybersicherheits-Strategie ist in vielen Punkten noch eine Vision. Trotzdem besteht kein Zweifel daran, dass sich die Softwareindustrie auf schärfere gesetzliche Rahmenbedingungen in Sachen Software Supply Chain gefasst machen muss“, erklärt Nicole Segerer, SVP und General Manager bei Revenera. „Viele Länder werden dem Beispiel der USA folgen. Die EU hat bereits vor zwei Jahren eine Open-Source-Software-Strategie 2020-2023 vorgestellt. Damit steht der private Sektor über kurz oder lang vor der Herausforderung, seine Sicherheitsmechanismen entlang der Software-Lieferkette zu verbessern und die SBOM fest in das Software Development Framework zu implementieren.“

Sowohl was die Compliance als auch die Sicherheit angeht, sollten Softwareanbieter und Entwickler daher erste Grundsteine legen und zentrale Best Practices in ihre Workflows integrieren. Dazu gehören:

Software Composition Analyse, um Schwachstellen frühzeitig im Software-Entwicklungszyklus (SDLC) zu identifizieren und zu beheben.
Software Bill of Material (SBOM) für jede Anwendung, um alle eingesetzten Komponenten (OSS und Dritt-Anbieter), einschließlich ihrer Abhängigkeiten, festzuhalten.
Tracking- und Analysetools, um alle Komponenten nachzuverfolgen – unabhängig davon, ob sie aus dem Unternehmen selbst oder einer externen Quelle stammen.
Interne Trainings und Management-Schulungen, um das Sicherheitsbewusstsein von Entwicklerteams im Umgang mit Open Source zu schärfen.
Open Source Program Office (OSPO), um Open Source Compliance- und Sicherheitsrichtlinie konsequent und abteilungsübergreifend durchzusetzen.

Weitere Informationen: