NHS England’dan kodu açık tutmasını isteyen açık mektup

 (keepthingsopen.com)
1 puan yazan GN⁺ 2026-05-03 | 1 yorum | WhatsApp'ta paylaş
  • NHS England teknoloji liderliğinin depo kaynak kodunu gizli hale getirme kararına karşı çıkılıyor ve kamusal fonlarla yazılan kodun kamuya açık olması gerektiği ilkesi yeniden teyit ediliyor
  • NHS England’dan SDLC-8 red line uygulamasını geri çekmesi ve NHS Service Standard Principle 12 “Make new source code open” taahhüdünü yeniden doğrulaması isteniyor
  • Açık kaynak olarak yayımlamak, kapalı tutmaktan daha fazla iş gerektiriyor; ancak bunun için daha yüksek kalite standartları, zafiyetlerin önceden bulunup düzeltilmesi ve zararı sınırlayacak bariyerlerin kurulması gerekiyor
  • Kapalı kaynak, gerekli güvenlik çalışmalarının atlanmasına yol açabiliyor; derinlemesine savunma yerine belirsizliğe dayanıyor ve yeterince motive saldırganlar karşısında sağladığı avantaj çok sınırlı görünüyor
  • 1 Mayıs 2026’dan bu yana 402 kişi imza attı; imzacılar ad, e-posta ve Birleşik Krallık kamu sektörü yazılımına katkı verip vermediklerini gönderebiliyor, anonim imzalarda ise doğrulamanın ardından 24 saat içinde kişisel veriler siliniyor

Açık mektubun temel talepleri

  • NHS England teknoloji liderliğinin tüm depoların kaynak kodunu gizleme kararına karşı çıkılıyor ve kamusal fonlarla yazılan kodun kamuya açık olması gerektiği ilkesi yeniden teyit ediliyor
  • Bu ilkenin UK Government Design Principles ve NHS Service Standard içinde yer aldığı, ancak şu anda geri adım atıldığı değerlendiriliyor
  • NHS England’dan SDLC-8 red line uygulamasını geri çekmesi ve NHS Service Standard Principle 12 “Make new source code open” taahhüdünü yeniden doğrulaması isteniyor
  • 1 Mayıs 2026’dan bu yana 402 kişi imza attı ve imzalar manuel incelemenin ardından sayfada gösteriliyor

Açık kaynağın daha sıkı kalite standartları oluşturduğu argümanı

  • Kodun açık kaynak olarak yayımlanması, onu kapalı tutmaktan daha fazla iş gerektiriyor
  • Burada asıl önemli olanın bu zor işin kendisi olduğu savunuluyor
  • Açık kaynak yayımlama, daha yüksek kalite standartları ile zafiyetleri önceden bulup düzeltmeye ve izlemeye yönelik süreçler gerektiriyor
  • Risklerin tanımlanması ve sorun çıktığında zararı sınırlayacak bariyerlerin hazırlanması gerekiyor
  • Bu durum insan bağışıklık sistemine benzetiliyor; tehditlere maruz kalmanın saldırı yüzeyini daha dayanıklı hale getirdiği savunuluyor
Reklam

Kapalı kaynağa yönelik eleştiriler

  • Kapalı kaynak, gerekli güvenlik çalışmalarının atlanabilmesini sağlıyor
  • Kapalı yaklaşımın derinlemesine savunma yerine belirsizliğe dayandığı düşünülüyor
  • Yeterince motive bir saldırgan olduğunda belirsizliğin sağladığı avantaj çok küçük görünüyor

İmzalama yöntemi ve kişisel verilerin işlenmesi

  • İmzacılar adlarını, e-posta adreslerini, Birleşik Krallık kamu sektörü yazılımına katkı verip vermediklerini ve isteğe bağlı olarak rollerini ve kurumlarını gönderebiliyor
  • Birleşik Krallık kamu sektörü yazılımına katkı; teknik ve teknik olmayan katkıları, açık ve kapalı katkıları kapsayabiliyor
  • Katkı varsa bir commit ya da profil bağlantısı yeterli görülüyor ve bu bilgi kamuya açıklanmıyor
  • Anonim imza seçilirse imza “Anonymous” olarak gösteriliyor; rol ve kurum verilmişse bunlar da birlikte gösterilebiliyor
  • Anonim imzalarda doğrulamadan sonra 24 saat içinde kişisel veriler siliniyor
  • E-posta adresleri yalnızca imzayla ilgili iletişim gerektiğinde kullanılıyor ve kamuya açıklanmıyor
  • Kişisel veri işlemenin hukuki dayanağı rıza ve bu rızanın geri çekilmesi mümkün
  • Verilerle ilgili iletişim için signatures@keepthingsopen.com adresi kullanılabiliyor
  • Kişisel veri işlenmesine ilişkin şikâyetler Information Commissioner’s Office üzerinden yapılabiliyor

Referanslar ve destek bağlantıları

İlgili okumalar

1 yorum

 
GN⁺ 2026-05-03
Hacker News yorumları

  • Mythos tehdidine verilen tepkinin tamamı göstermelik önlem gibi görünüyor; şeffaflık ve açıklık ortaya çıkar çıkmaz, ne kadar zayıf olursa olsun bir bahaneyle geri alınmaya çalışıldığı izlenimi veriyor
    Bu daha çok teknik olmayan birinin, “kapalı kaynağa geçmezsek ve bir açık bulunursa, yeterince şey yapmadığımız için suçlanma ihtimalimiz %0,1 bile olsa” diye düşünüp verdiği bir karara benziyor
    2026’nın aşırı açgözlülüğü ve bencilliği, kamu yararının maliyetini göze alarak bile bu tür kararları kolaylaştırıyor; özel sektörün de bu konuda pek daha iyi olmadığını akılda tutmak gerek

    • Tek istisna, kapanıştan sonra kodda kayda değer değişiklikler yapılmış olması ve saldırganların ya da büyük dil modellerinin bu değişiklikleri okuyamaması olurdu
      İçeride büyük dil modelleri kullanıp kaynak kodunu yayımlamadan, özel olarak hata bularak saldırganların önüne geçmek mümkün olabilir
      Yakın zamandaki Copy.fail kamuya açık felaketinde olduğu gibi, büyük dil modelleri kullanan birinin bulduğu bir açığın net bir düzeltme olmadan zero-day olarak ifşa edilip topluluğu kargaşa ve paniğe sürüklediği örnekleri de gördük
      Güçlü büyük dil modelleri hem açık hem kapalı ağırlıklı biçimlerde mevcutken, özellikle hastanelerde kullanılan yazılımlar söz konusuysa her şeyi koşulsuz biçimde açık kaynak yapmak artık daha az makul; denge gerekiyor

  • NHS dijital hizmetlerinin kalitesi konusunda endişelenip bu başlığı okuyorsanız, engelli kullanıcı deneyimine gerçekten zarar veren ve temel hizmetleri iyileştirmek için kullanılabilecek paranın boşa harcanmasına yol açan erişilebilirlik overlay’lerini NHS sağlayıcılarının satın almasını engelleyecek dilekçeyi de imzalarsanız sevinirim: https://petition.parliament.uk/petitions/765480/

  • Cloudflare doğrulayıcısı benim insan olmadığımı söylüyor, bu yüzden imzalayamıyorum

  • Bu durumu kolayca açıklayan bir video var: https://youtu.be/XNLUfqtgBUk
    Bu alan uzmanlık alanınızsa, açık mektubu mutlaka imzalarsanız iyi olur

  • NHS kabul edip uygulamaya kalksa bile, ilgili rehberin hazırlanması en az 1 yıl sürer
    Sonra mevcut teknik ekipten bunu toparlaması istenirse muhtemelen bir 10 yıl daha alır

  • İlgili yazı: 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)

  • Son birkaç haftadır bu konuyu CISO’lar, CTO’lar, bakımcılar ve meslektaşlarla konuştum; bazıları F50 şirketlerinde çalışıyor ve bunların temel planı, uygulama güvenliği ekipleri sorunları bir gün içinde kolayca doğrulayıp düzeltebilecek hale gelene kadar açık kaynak katkılarını ve kullanımını durdurmak yönünde
    Geleneksel olarak uçtan uca müdahale süresi 8-10 gün civarındaydı ama artık bu hızla ayakta kalınamaz
    Bunu açık kaynağın ölümü olarak görmüyorum ama bakımcılara sürdürülebilir işletim kaynakları sağlanmadığında açık kaynak ekonomisinin ortakların trajedisine dönüştüğünü gösteriyor
    Bu aynı zamanda kurumların onlarca yıl boyunca hem mühendislik içinde hem de organizasyon düzeyinde güvenliği önceliklendirmediğinin bir itirafı; ama burada HN’deki konuşmaların seviyesine bakınca, bu ayrı bir tartışma gerektiriyor gibi
    Açık kaynağı sevenler gerçekten önemsiyorsa, sadece idealizm konuşmak yerine para harcamalı; open-core’a gitmeyi ya da resmî finansman ve sponsorluk mekanizmaları kurmayı düşünmeli
    Proje sahiplerinin ticarileştirmesine izin verirken çok daha kısıtlayıcı lisanslar benimsemek de önemli. Benzer ideallere sahip birkaç kişinin iyi niyetine dayanan GNU tarzı projelerin çoğunun hayatta kalması zor; katkı yapanların da ücret alması gerekir
    “Linux/Kubernetes/Chrome(Edge dahil)/neredeyse tüm programlama dilleri/nginx vb. şeyleri bırakamazsınız ki” sorusuna karşılık kast edilen şey, bundan sonra kullanılan tüm bağımlılıkları ve kütüphaneleri dondurmak ve uçtan uca açık düzeltmesi 24 saat içinde mümkün olana kadar kaynak kodunu yayımlamamak
    Ekipler, temel projeleri ve bağımlılıkları iç kullanım için fork’lamayı; upstream katkıların kirlenmiş olabileceği ya da ek açıklar getirebileceği korkusuyla upstream’e katkı yapmamayı da ciddi biçimde değerlendiriyor

    • simonw’un bakış açısındaki gibi, aslında açık kaynağın daha değerli hale gelmesi gerektiği görüşüne katılıyorum
      “İlginç sonuç şu: açık kaynak kütüphaneler daha değerli hale geliyor. Çünkü güvenlik için harcanan token maliyeti tüm kullanıcılarla paylaşılabiliyor. Bu da, açık kaynak kütüphanelerin yerine vibe coding ile ucuza alternatifler üretilebileceği ve bu yüzden mevcut açık kaynak projelerin çekiciliğinin azalacağı fikrine doğrudan karşı çıkıyor”
      Kodu fork’layıp içeri alma yönündeki refleksi anlıyorum ama bu, mühendislik ekiplerinin yönetip açıklarını hafifletmek zorunda kalacağı daha fazla kod anlamına geldiğinde, bunun ne kadar sürdürülebilir olduğu soru işareti
      [0] https://simonwillison.net/2026/Apr/14/cybersecurity-proof-of...
    • “açık kaynak katkılarını ve kullanımını durdurmak” ile tam olarak ne kastedildiğini anlamadım
      Linux/Kubernetes/Chrome(Edge dahil)/neredeyse tüm programlama dilleri/nginx vb. şeyleri bırakamazsınız sonuçta, o yüzden merak ediyorum