Supply Chain

Benjamin Hilbricht und Oliver Voß schreibt in »C3A-Katalog: Die BSI-Kriterien für souveräne Clouds« für tagesspiegel.de Strategische Souveränität: Der Cloud-Anbieter muss EU- oder deutschem Recht unterliegen. Deutsche oder EU-Behörden müssen eine effektive Kontrolle vornehmen können. Wenn sich ein amerikanischer, chinesischer oder sonstiger Nicht-EU-Akteur in einen Cloud-Anbieter einkauft oder ihn übernimmt, muss das Unternehmen drei Monate im Voraus seine Kunden davor warnen. Rechtliche Souveränität: Einmal im Jahr muss der Cloud-Anbieter Nicht-EU-Gesetze identifizieren, die sich auf sein Geschäft auswirken, und eine Risikoanalyse vornehmen. Ein Beispiel wäre der US Cloud Act. Außerdem enthält der Abschnitt ein Kriterium für den Verteidigungsfall. Als souverän gelten Cloud-Anbieter, die Wissen, Fähigkeiten und Personal vorhalten, sodass der Staat die Cloud-Services im Verteidigungsfall selbst steuern kann. Datensouveränität: Dieser Punkt ist sehr umfangreich. Hier spezifizieren Kriterien, ob und wie viel Kontrolle die Kunden über die Metadaten und Daten haben und wo diese gespeichert werden. Es wird verlangt, dass der Cloud-Anbieter ein externes Management für kryptografische Schlüssel zulässt. Dadurch würde gewährleistet, dass er Kundendaten nicht selbst entschlüsseln kann. Auch die Möglichkeit, die Nutzeridentitäten außerhalb der Cloud zu managen, gilt als Muss. Betriebssouveränität: Auch dieser Punkt ist sehr umfangreich. Unter anderem finden sich hier die eingangs erwähnten Kriterien, dass die Rechenzentren 90 Tage lang ohne jegliche Verbindung zu Nicht-EU-Staaten laufen können müssen. „Wir müssen die Kabel zu den US-Backbones physisch rausziehen können und trotzdem muss ein Rechenzentrum in Europa betriebsfähig bleiben“, sagt BSI-Vize Caspers. Lieferketten: Hier müssen souveräne Unternehmen ihre Abhängigkeiten in Software, Hardware und Diensten inventarisieren und am besten einen dokumentierten Prozess für den Problemfall vorhalten. Technologische Souveränität: Hier verlangt das Bundesamt, dass es ein Backup des Quellcodes auf einem Speicher in der EU gibt. Der Code darf nicht älter sein als 24 Stunden und muss dokumentiert sein. Cloud-Anbieter, die in Deutschland tätig sein wollen, müssen für den Notfall eine Strategie vorhalten, wie sie ihre Dienste weiter liefern können. Zusätzlich können sie nachweisen, dass sie eigene Leute haben, die die Entwicklung und Wartung der Dienste übernehmen können, falls die Lieferung aus dem EU-Ausland abbricht. Der Artikel ist auch über das oben genannte Zitat hinaus interessant. Den C3A-Katalog kann man hier einsehen.

Tagesspiegel Background schreibt in »Digitale Souveränität: Schwarz Digits stellt Souveränitäts-Modell vor« Mit einem Reifegrad-Modell wird dabei die digitale Souveränität von IT-Services in vier Stufen bewertet: Basic, Initial, Advanced und Future-Proof. Innerhalb dieses „Sovereignty Maturity Level Framework“ gibt es einen Katalog mit mehr als 100 Kriterien. Dabei orientiert sich Schwarz am Cloud Sovereignty Framework der Europäischen Kommission. Beide haben acht beziehungsweise neun Souveränitätsdimensionen definiert: ...

Obwohl der Artikel von Randy Bias, betitelt »Avoiding a Geopolitical Open Source Apocalypse«, schon etwas zurückliegt - er wurde im Oktober 2024 veröffentlicht - bleibt er nach wie vor relevant. Die Publikation ist auf thenewstack.io zu finden und liefert gute Gedankenanstöße bzgl der Zusammenarbeit der Ost- und Westmächte für ein gemeinsames sicheres Open-Source-Ökosystem. Some think that open source software is generally more secure, but is it? Open source software mainly made in the West has well-documented security issues of its own, due in part to its heavy reliance on overworked and volunteer maintainers. Securing open source software requires time, energy and diligence. Unfortunately, many projects are very thinly resourced and lack the expertise required to look for security risks diligently. ...

Robert Lippert schreibt in »Entwickler ertrinken in technischen Schulden« für heise.de Die Ursachen für Sicherheitsprobleme sind laut Studie dabei nicht so eindeutig identifizierbar, wie viele Menschen meinen. 70,2 Prozent der untersuchten Anwendungen weisen sicherheitsrelevante Fehler in Drittanbietercode auf, wie eingebundenen Bibliotheken oder quelloffenem Code; doch auch unternehmenseigene Anwendungen sind zu 63,4 Prozent mit Fehlern ihrer Development-Teams belastet. Die Anzahl der direkten und transitiven Abhängigkeiten variiert dabei je nach Programmiersprache, wobei die “Abhängigkeiten der Abhängigkeiten” in den meisten Fällen die Lieferkette verdoppeln. Sprachen wie Java und JavaScript können die Zahl der Abhängigkeiten sogar um das Fünf- bis Sechsfache erhöhen. ...

Justin Dorfman schreibt in »When Open Source turns sour: A brush with mistaken identity« für opensource.net Open Source is undoubtedly one of the best communities I’ve ever had the pleasure of being a part of. It’s filled with amazing people who genuinely care about the world’s greatest software supply chain. However, this also attracts negative elements, which can lead to finger-pointing that inadvertently harms innocent contributors, the sustainability of the ecosystem, and, most importantly, the community. ...