Offener Brief mit der Bitte an NHS England, den Code öffentlich zugänglich zu halten

 (keepthingsopen.com)
1 Punkte von GN⁺ 2026-05-03 | 1 Kommentare | Auf WhatsApp teilen
  • Widerspricht der Entscheidung der technischen Führung von NHS England, den Quellcode ihrer Repositories privat zu machen, und bekräftigt den Grundsatz, dass mit öffentlichen Mitteln entwickelter Code der Öffentlichkeit zugänglich sein sollte
  • Von NHS England wird gefordert, die SDLC-8 red line zurückzunehmen und die Verpflichtung zu NHS Service Standard Principle 12 „Make new source code open“ erneut zu bekräftigen
  • Die Veröffentlichung als Open Source erfordert mehr Arbeit als das Beibehalten von nicht öffentlichem Code, macht aber höhere Qualitätsstandards, das frühzeitige Finden und Beheben von Schwachstellen sowie den Aufbau von Schutzbarrieren zur Schadensbegrenzung erforderlich
  • Nicht öffentlicher Quellcode kann dazu führen, dass notwendige Sicherheitsarbeit übersprungen wird, verlässt sich statt auf Defense in Depth auf Unklarheit, und der Vorteil gegenüber ausreichend motivierten Angreifern scheint sehr gering zu sein
  • Seit dem 1. Mai 2026 haben 402 Personen unterzeichnet; Unterzeichnende können Name, E-Mail und Angaben dazu einreichen, ob sie zur Software des britischen öffentlichen Sektors beigetragen haben, und bei anonymen Unterschriften werden personenbezogene Daten nach der Verifizierung innerhalb von 24 Stunden gelöscht

Zentrale Forderungen des offenen Briefs

  • Widerspricht der Entscheidung der technischen Führung von NHS England, den Quellcode aller Repositories zu verbergen, und bekräftigt den Grundsatz, dass mit öffentlichen Mitteln entwickelter Code der Öffentlichkeit zugänglich sein sollte
  • Dieser Grundsatz ist in den UK Government Design Principles und im NHS Service Standard verankert; nach Ansicht des Briefs findet derzeit ein Rückschritt statt
  • Von NHS England wird gefordert, die SDLC-8 red line zurückzunehmen und die Verpflichtung zu NHS Service Standard Principle 12 „Make new source code open“ erneut zu bekräftigen
  • Seit dem 1. Mai 2026 haben 402 Personen unterzeichnet; Unterschriften werden nach manueller Prüfung auf der Seite angezeigt

Warum Open Source strengere Qualitätsstandards schafft

  • Quellcode als Open Source zu veröffentlichen erfordert mehr Arbeit, als ihn nicht öffentlich zu halten
  • Gerade diese schwierige Arbeit ist der Kernpunkt
  • Die Veröffentlichung als Open Source verlangt höhere Qualitätsstandards und erfordert Verfahren, um Schwachstellen frühzeitig zu finden, zu beheben und zu überwachen
  • Risiken müssen identifiziert und Schutzbarrieren eingerichtet werden, um Schäden zu begrenzen, wenn Probleme auftreten
  • Dies wird mit dem menschlichen Immunsystem verglichen: Die Auseinandersetzung mit Bedrohungen härtet die Angriffsfläche stärker ab

Kritik an nicht öffentlichem Quellcode

  • Nicht öffentlicher Quellcode kann dazu führen, dass notwendige Sicherheitsarbeit übersprungen wird
  • Der nicht öffentliche Ansatz verlässt sich nach Ansicht des Briefs statt auf Defense in Depth auf Unklarheit
  • Wenn ein ausreichend motivierter Angreifer vorhanden ist, scheint der durch Unklarheit entstehende Vorteil sehr gering zu sein

Art der Unterzeichnung und Umgang mit personenbezogenen Daten

  • Unterzeichnende können Name, E-Mail-Adresse, Angaben dazu, ob sie zur Software des britischen öffentlichen Sektors beigetragen haben, sowie optional Rolle und Organisation einreichen
  • Beiträge zur Software des britischen öffentlichen Sektors können sowohl technische als auch nicht technische Beiträge sowie öffentliche und nicht öffentliche Beiträge umfassen
  • Falls ein Beitrag vorliegt, reicht etwa ein Commit oder ein Profil-Link aus; diese Informationen werden nicht veröffentlicht
  • Wer eine anonyme Unterschrift wählt, wird als „Anonymous“ angezeigt; falls Rolle und Organisation angegeben wurden, können diese mit angezeigt werden
  • Bei anonymen Unterschriften werden personenbezogene Daten nach der Verifizierung innerhalb von 24 Stunden gelöscht
  • E-Mail-Adressen werden nur verwendet, wenn im Zusammenhang mit der Unterschrift Kontakt aufgenommen werden muss, und nicht veröffentlicht
  • Die Rechtsgrundlage für die Verarbeitung personenbezogener Daten ist Einwilligung; diese kann widerrufen werden
  • Für Datenanfragen kann signatures@keepthingsopen.com kontaktiert werden
  • Beschwerden zur Verarbeitung personenbezogener Daten können beim Information Commissioner’s Office eingereicht werden

Referenzen und Unterstützungslinks

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-05-03
Hacker-News-Kommentare

  • Die Reaktion auf die Mythos-Bedrohung wirkt insgesamt wie reine Symbolpolitik, und sobald Transparenz und Offenheit entstehen, sucht man offenbar nach jeder noch so dünnen Ausrede, um das wieder rückgängig zu machen.
    Es ist eher eine Entscheidung von Nicht-Technikern, die glauben: „Wenn wir nicht auf Closed Source umstellen und dann eine Schwachstelle gefunden wird, besteht auch nur eine 0,1%ige Chance, dass uns vorgeworfen wird, nicht genug getan zu haben.“
    Die extreme Gier und Selbstsucht des Jahres 2026 machen solche Entscheidungen leicht, selbst auf Kosten des Gemeinwohls, und man sollte immer im Hinterkopf behalten, dass der Privatsektor darin auch nicht wirklich besser ist.

    • Eine Ausnahme gäbe es nur dann, wenn es nach der Schließung erhebliche Änderungen am Code gab und Angreifer oder große Sprachmodelle diese Änderungen nicht lesen konnten.
      Wenn man intern große Sprachmodelle nutzt, um Fehler vertraulich zu finden, ohne den Quellcode zu veröffentlichen, könnte man Angreifern einen Schritt voraus sein.
      Wir haben zuletzt Beispiele gesehen, in denen – wie beim öffentlichen Desaster rund um Copy.fail – eine von jemandem mit Hilfe großer Sprachmodelle gefundene Schwachstelle ohne klare Korrektur als Zero-Day veröffentlicht wurde und die Community in Verwirrung und Panik versetzte.
      In einer Lage, in der starke große Sprachmodelle sowohl mit offenen als auch mit geschlossenen Gewichten existieren, ist es weniger überzeugend, alles pauschal Open Source zu machen – besonders bei Software, die in Krankenhäusern eingesetzt wird; hier braucht es ein Gleichgewicht.

  • Wer diesen Thread verfolgt, weil ihn die Qualität digitaler NHS-Dienste sorgt, sollte bitte auch diese Petition unterschreiben, damit NHS-Anbieter keine Accessibility-Overlays kaufen dürfen, die die Nutzung für Menschen mit Behinderungen real verschlechtern und Geld verschwenden, das besser in die Verbesserung zentraler Dienste fließen sollte: https://petition.parliament.uk/petitions/765480/

  • Ich kann nicht unterschreiben, weil der Cloudflare-Verifizierer behauptet, ich sei kein Mensch.

  • Es gibt ein Video, das die Situation einfach erklärt: https://youtu.be/XNLUfqtgBUk
    Wenn das dein Fachgebiet ist, wäre es großartig, wenn du den offenen Brief unterschreiben würdest.

  • Selbst wenn der NHS zustimmt und das umsetzen will, wird allein die Ausarbeitung der entsprechenden Richtlinien mindestens ein Jahr dauern.
    Und wenn man dann das aktuelle Technikteam bittet, aufzuräumen, dauert es wahrscheinlich weitere zehn Jahre.

  • Verwandter Beitrag: NHS Goes to War Against Open Source
    https://shkspr.mobi/blog/2026/05/nhs-goes-to-war-against-ope... (https://news.ycombinator.com/item?id=47973710)

  • Ich habe in den letzten Wochen mit CISOs, CTOs, Maintainers und Kollegen über dieses Thema gesprochen, einige davon aus F50-Unternehmen, und deren Grundplan ist, Open-Source-Beiträge und -Nutzung auszusetzen, bis Application-Security-Teams Probleme innerhalb eines Tages problemlos verifizieren und beheben können.
    Traditionell lag die End-to-End-Reaktionszeit bei etwa 8 bis 10 Tagen, aber in diesem Tempo kommt man heute nicht mehr durch.
    Ich sehe darin nicht das Ende von Open Source, aber es zeigt, dass die Open-Source-Ökonomie zur Tragödie der Allmende geworden ist, solange Maintainers keine nachhaltigen operativen Ressourcen bekommen.
    Es ist auch ein Eingeständnis, dass Organisationen über Jahrzehnte hinweg Sicherheit weder innerhalb des Engineerings noch auf Organisationsebene priorisiert haben; aber wenn man das Niveau der Diskussion hier auf HN sieht, ist das wohl eine eigene Debatte.
    Wenn Menschen, die Open Source lieben, es wirklich ernst meinen, sollten sie nicht nur idealistisch reden, sondern Geld ausgeben und über Open Core oder formale Finanzierung und Sponsoring nachdenken.
    Wichtig ist auch, deutlich restriktivere Lizenzen einzuführen, die gleichzeitig die Kommerzialisierung durch Projektverantwortliche erlauben. Die meisten GNU-artigen Projekte, die auf dem guten Willen einiger weniger Gleichgesinnter beruhen, werden kaum überleben, und auch Beitragende sollten bezahlt werden.
    Zur Frage „Man kann doch Linux/Kubernetes/Chrome (einschließlich Edge)/fast alle Programmiersprachen/nginx usw. nicht einstellen“: Gemeint ist, alle künftig genutzten Abhängigkeiten und Bibliotheken einzufrieren und den Quellcode nicht offenzulegen, bis End-to-End-Schwachstellenbehebungen innerhalb von 24 Stunden möglich sind.
    Teams prüfen außerdem ernsthaft, Kernprojekte und Abhängigkeiten intern zu forken und nicht mehr Upstream beizutragen, weil sie fürchten, dass Upstream-Beiträge kompromittiert sein oder zusätzliche Schwachstellen einführen könnten.

    • Ich stimme der Sicht von simonw zu, dass Open Source vielmehr noch wertvoller werden sollte.
      „Ein interessantes Ergebnis ist, dass Open-Source-Bibliotheken wertvoller werden. Denn die für Sicherheit aufgewendeten Token-Kosten können auf alle Nutzer verteilt werden. Das widerlegt direkt die Vorstellung, dass bestehende Open-Source-Projekte an Attraktivität verlieren, weil man mit Vibe Coding billig Ersatz für Open-Source-Bibliotheken bauen kann.“
      Den reflexhaften Impuls, Code zu forken und intern zu holen, kann ich verstehen, aber ich bezweifle, wie nachhaltig das ist, wenn Engineering-Teams dadurch noch mehr Code verwalten und Schwachstellen abmildern müssen.
      [0] https://simonwillison.net/2026/Apr/14/cybersecurity-proof-of...
    • Ich verstehe nicht, was „Open-Source-Beiträge und -Nutzung aussetzen“ bedeuten soll.
      Man kann doch Linux/Kubernetes/Chrome (einschließlich Edge)/fast alle Programmiersprachen/nginx usw. nicht einstellen, deshalb frage ich nach.