NHS Englandにコードを公開状態に保つよう求める公開書簡
(keepthingsopen.com)- NHS Englandの技術リーダーシップによるリポジトリのソースコード非公開化の決定に反対し、公的資金で作られたコードは一般公開されるべきだという原則を再確認している
- NHS Englandには、SDLC-8 red line の撤回と、NHS Service Standard Principle 12「Make new source code open」へのコミットメントの再確認が求められている
- オープンソースでの公開は非公開維持よりも多くの作業を要するが、より高い品質基準と、脆弱性の事前発見・修正、被害を限定する障壁の整備が必要だとしている
- 非公開ソースは必要なセキュリティ作業を飛ばしやすくし、深層防御ではなく曖昧さに依存させる可能性があり、十分に動機づけられた攻撃者に対する利点はごく小さいように見える
- 2026年5月1日以降、402人が署名しており、署名者は氏名・メールアドレス・英国公共部門ソフトウェアへの貢献有無などを提出でき、匿名署名では検証後24時間以内に個人情報が削除される
公開書簡の主要な要求
- NHS Englandの技術リーダーシップがすべてのリポジトリのソースコードを隠すとした決定に反対し、公的資金で作られたコードは一般公開されるべきだという原則を再確認している
- この原則は UK Government Design Principles と NHS Service Standard に盛り込まれており、現在は後退しているとみている
- NHS Englandには、SDLC-8 red line の撤回と、NHS Service Standard Principle 12「Make new source code open」へのコミットメントの再確認が求められている
- 2026年5月1日以降、402人が署名しており、署名は手作業での確認後にページへ表示される
オープンソースがより厳格な品質基準を生むという論理
- コードをオープンソースとして公開することは、非公開に保つよりも多くの作業を要する
- その難しい作業そのものが重要だと考えている
- オープンソース公開は、より高い品質基準を求め、脆弱性を事前に見つけて修正し監視する手順を必要とする
- リスクを特定し、問題が発生したときに被害を限定するための障壁を整えなければならない
- これを人間の免疫システムになぞらえ、脅威にさらされることが攻撃面をより強固にするとみている
非公開ソースへの批判
- 非公開ソースは、必要なセキュリティ作業を省けるようにしてしまう
- 非公開方式は、深層防御ではなく曖昧さに依存しているとみている
- 十分に動機づけられた攻撃者がいる場合、曖昧さがもたらす利点は非常に小さいように見える
署名方法と個人情報の取り扱い
- 署名者は、氏名、メールアドレス、英国公共部門ソフトウェアへの貢献有無、任意項目として役職と組織を提出できる
- 英国公共部門ソフトウェアへの貢献には、技術的・非技術的な貢献、公開・非公開の貢献のいずれも含まれうる
- 貢献がある場合は、コミットやプロフィールへのリンク程度で十分であり、その情報は公開されない
- 匿名署名を選ぶと、署名は「Anonymous」と表示され、役職と組織を提供した場合はそれらも併記されることがある
- 匿名署名の場合、検証後 24時間以内 に個人情報が削除される
- メールアドレスは署名に関する連絡が必要なときにのみ使われ、公開されない
- 個人情報処理の法的根拠は同意であり、同意は撤回可能である
- データに関する連絡は signatures@keepthingsopen.com に送ることができる
- 個人情報処理に対する苦情は Information Commissioner’s Office に申し立てることができる
参考資料と支援リンク
- NHS Goes To War Against Open Source
- NHS England rushes to hide software over AI hacking fears
- NHS Service Standard — Principle 12: Make new source code open
- NHS England quietly removes open source policy web pages (Digital Health)
- Don’t be afraid to code in the open: how to do it securely (GOV.UK)
- Does Mythos mean shutting down your open source repos? (shkspr.mobi)
- Discourse is not going closed source (Discourse)
- View on GitHub
- Sign
- Email signatures@keepthingsopen.com
- ソースは MIT licence で提供されている
1件のコメント
Hacker Newsの意見
Mythosの脅威への対応がすべて見せかけの対策のように見え、透明性や公開性が生まれた瞬間に、どんなお粗末な言い訳でも使って元に戻そうとしているように見える
これは、非技術者が「クローズドソース化しなかったことで、脆弱性が見つかった際に十分な対応をしなかったと非難される確率が0.1%でもある」と信じて下す判断に近い
2026年の極端な強欲と利己主義は、公共善のコストを払ってでもそうした判断を容易にしており、民間部門もこの点で特にましではないことは常に念頭に置くべきだ
内部で大規模言語モデルを使い、ソースコードを公開せず非公開でバグを見つければ、攻撃者より一歩先に行ける
最近のCopy.fail公開災害のように、大規模言語モデルを使った誰かが見つけた脆弱性が、明確な修正もなくゼロデイとして公開され、コミュニティが混乱とパニックに陥った事例も見た
強力な大規模言語モデルが公開ウェイトとクローズドウェイトの両方に存在する状況では、特に病院で使われるソフトウェアなら何でもかんでもオープンソースにするのは以前ほど妥当ではなく、バランスが必要だ
NHSのデジタルサービスの品質を心配してこのスレッドを見ているなら、障害のあるユーザーの体験を実際に損ない、コアサービス改善に使える資金を浪費させるアクセシビリティ・オーバーレイをNHSの提供者が購入できないようにする請願にも署名してほしい: https://petition.parliament.uk/petitions/765480/
Cloudflareの検証機が私を人間ではないと判定するので署名できない
この状況をわかりやすく説明した動画がある: https://youtu.be/XNLUfqtgBUk
この分野が専門なら、ぜひ公開書簡に署名してほしい
たとえNHSが同意して実行しようとしても、関連するガイドラインを作るだけで少なくとも1年はかかるだろう
その後、現在の技術チームに整理を依頼したら、さらに10年はかかりそうだ
関連記事: 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)
この数週間、この件についてCISO、CTO、メンテナー、同僚たちと話してきたが、その一部はF50企業に所属しており、彼らの基本方針は、アプリケーションセキュリティチームが1日以内に問題を容易に検証して修正できるようになるまで、オープンソースへの貢献と利用を停止するというものだ
従来、エンドツーエンドの対応時間は8〜10日程度だったが、今はその速度では持ちこたえられない
これをオープンソースの死だとは思わないが、メンテナーに持続可能な運営資源が提供されないまま、オープンソースの経済が共有地の悲劇に変わってしまったことを示している
また、組織が数十年にわたってエンジニアリング内部でも組織全体でもセキュリティを優先してこなかったことの表れでもあるが、ここHNでの会話のレベルを見ると、それは別途議論が必要そうだ
オープンソースを愛する人たちが本当に気にしているなら、理想論を語るだけでなく金を使うべきであり、オープンコアへ移行するか、正式な資金援助やスポンサーシップを確保する方法を考えるべきだ
プロジェクトオーナーの商用化を認めつつ、もっと制限の強いライセンスを導入することも重要だ。似た理念を持つ少数の個人の善意に頼るGNU式プロジェクトの大半は生き残れず、貢献者にも報酬が支払われるべきだ
「Linux/Kubernetes/Chrome(Edge含む)/ほぼすべてのプログラミング言語/nginxなどを止めることはできないのでは？」という問いに対しては、今後使うすべての依存関係とライブラリを凍結し、エンドツーエンドの脆弱性修正が24時間以内に可能になるまでソースコードを公開しない、という意味だ
チームはコアプロジェクトと依存関係を社内用にフォークし、アップストリームへの貢献が汚染される、あるいは追加の脆弱性を持ち込むかもしれないという恐れから、アップストリームに貢献しないことも真剣に検討している
「興味深い帰結は、オープンソースライブラリがより価値を持つようになることだ。なぜならセキュリティに使うトークンコストをすべての利用者で共有できるからだ。これは、オープンソースライブラリの代替品をバイブコーディングで安く作れるので既存のオープンソースプロジェクトの魅力が下がる、という考えに真っ向から反論する」
コードをフォークして社内に取り込もうとする反射的な動きは理解できるが、エンジニアリングチームが管理し脆弱性を緩和しなければならないコードが増える状況で、それがどれほど持続可能なのかは疑問だ
[0] https://simonwillison.net/2026/Apr/14/cybersecurity-proof-of...
Linux/Kubernetes/Chrome(Edge含む)/ほぼすべてのプログラミング言語/nginxなどを止めることはできないはずだが、気になる