- Phản đối quyết định của ban lãnh đạo công nghệ NHS England về việc chuyển mã nguồn trong các kho lưu trữ sang chế độ riêng tư, đồng thời tái khẳng định nguyên tắc rằng mã được tạo ra bằng tiền công phải được công khai cho công chúng
- Kêu gọi NHS England rút lại SDLC-8 red line và tái xác nhận cam kết với Nguyên tắc 12 của NHS Service Standard, “Make new source code open”
- Việc công khai mã nguồn mở đòi hỏi nhiều công sức hơn so với giữ kín, nhưng cần có tiêu chuẩn chất lượng cao hơn, phát hiện và khắc phục lỗ hổng từ sớm, cũng như thiết lập các rào chắn để hạn chế thiệt hại
- Mã nguồn đóng có thể khiến người ta bỏ qua các công việc bảo mật cần thiết và dựa vào sự mơ hồ thay vì phòng thủ theo chiều sâu; lợi thế mà điều này mang lại trước những kẻ tấn công đủ động lực dường như là rất nhỏ
- Tính từ ngày 1 tháng 5 năm 2026, đã có 402 người ký tên; người ký có thể gửi tên, email, thông tin về việc có đóng góp phần mềm cho khu vực công tại Anh hay không, và với chữ ký ẩn danh thì dữ liệu cá nhân sẽ bị xóa trong vòng 24 giờ sau khi xác minh
Các yêu cầu chính của thư ngỏ
- Phản đối quyết định của ban lãnh đạo công nghệ NHS England về việc ẩn mã nguồn của tất cả kho lưu trữ, đồng thời tái khẳng định nguyên tắc rằng mã được tạo ra bằng tiền công phải được công khai cho công chúng
- Nguyên tắc này được nêu trong UK Government Design Principles và NHS Service Standard, và hiện bị xem là đang thụt lùi
- Kêu gọi NHS England rút lại SDLC-8 red line và tái xác nhận cam kết với Nguyên tắc 12 của NHS Service Standard, “Make new source code open”
- Tính từ ngày 1 tháng 5 năm 2026, đã có 402 người ký tên và chữ ký sẽ được hiển thị trên trang sau khi được rà soát thủ công
Lập luận rằng mã nguồn mở tạo ra tiêu chuẩn chất lượng nghiêm ngặt hơn
- Việc phát hành mã dưới dạng mã nguồn mở đòi hỏi nhiều công sức hơn so với giữ riêng tư
- Chính phần việc khó đó mới là cốt lõi
- Việc công khai mã nguồn mở đòi hỏi tiêu chuẩn chất lượng cao hơn và cần có quy trình tìm, sửa cũng như giám sát lỗ hổng từ sớm
- Cần xác định rủi ro và thiết lập các rào chắn để hạn chế thiệt hại khi có sự cố
- Điều này được ví với hệ miễn dịch của con người: việc tiếp xúc với các mối đe dọa giúp bề mặt tấn công trở nên vững chắc hơn
Phê phán mã nguồn đóng
- Mã nguồn đóng có thể khiến người ta bỏ qua các công việc bảo mật cần thiết
- Cách làm đóng này bị xem là dựa vào sự mơ hồ thay vì phòng thủ theo chiều sâu
- Khi kẻ tấn công có đủ động lực, lợi thế do sự mơ hồ mang lại dường như là rất nhỏ
Cách ký tên và xử lý dữ liệu cá nhân
- Người ký có thể gửi tên, địa chỉ email, thông tin về việc có đóng góp phần mềm cho khu vực công tại Anh hay không, cùng vai trò và tổ chức là tùy chọn
- Đóng góp phần mềm cho khu vực công tại Anh có thể bao gồm cả đóng góp kỹ thuật lẫn phi kỹ thuật, công khai lẫn không công khai
- Nếu có đóng góp, chỉ cần một commit hoặc liên kết hồ sơ là đủ, và thông tin đó sẽ không được công khai
- Nếu chọn ký ẩn danh, chữ ký sẽ được hiển thị là “Anonymous”, và nếu cung cấp vai trò cùng tổ chức thì có thể được hiển thị kèm theo
- Với chữ ký ẩn danh, dữ liệu cá nhân sẽ bị xóa trong vòng 24 giờ sau khi xác minh
- Địa chỉ email chỉ được dùng khi cần liên hệ liên quan đến chữ ký và sẽ không được công khai
- Cơ sở pháp lý cho việc xử lý dữ liệu cá nhân là sự đồng ý, và có thể rút lại sự đồng ý
- Có thể liên hệ về dữ liệu tại signatures@keepthingsopen.com
- Có thể gửi khiếu nại về xử lý dữ liệu cá nhân tới Information Commissioner’s Office
Tài liệu tham khảo và liên kết hỗ trợ
1 bình luận
Ý kiến trên Hacker News
Phản ứng trước mối đe dọa Mythos trông hoàn toàn như biện pháp làm màu, và hễ có được chút minh bạch hay cởi mở nào là họ lại lộ ra ý định tìm bất kỳ cái cớ sơ hở nào để quay ngược lại
Điều này giống một quyết định do người không chuyên kỹ thuật đưa ra, kiểu “dù chỉ có 0,1% khả năng bị chỉ trích vì đã không chuyển sang mã nguồn đóng và không làm đủ khi phát hiện lỗ hổng”
Cũng cần luôn nhớ rằng sự tham lam và ích kỷ cực đoan của năm 2026 khiến những quyết định như vậy trở nên dễ dàng ngay cả khi phải đánh đổi lợi ích công, và khu vực tư nhân về mặt này cũng chẳng khá hơn bao nhiêu
Nếu nội bộ dùng mô hình ngôn ngữ lớn để tìm lỗi một cách kín đáo mà không công khai mã nguồn, thì có thể đi trước kẻ tấn công một bước
Gần đây cũng đã có trường hợp giống thảm họa công khai Copy.fail, khi một lỗ hổng do ai đó dùng mô hình ngôn ngữ lớn phát hiện bị công bố thành zero-day mà không có bản vá rõ ràng, khiến cộng đồng rơi vào hỗn loạn và hoảng loạn
Trong bối cảnh các mô hình ngôn ngữ lớn mạnh tồn tại cả ở dạng trọng số mở lẫn trọng số đóng, thì việc cứ mặc định mọi thứ phải là mã nguồn mở, nhất là với phần mềm dùng trong bệnh viện, đã trở nên kém hợp lý hơn và cần có sự cân bằng
Nếu bạn đang theo dõi chủ đề này vì lo ngại về chất lượng dịch vụ số của NHS, sẽ rất tốt nếu bạn cũng ký vào kiến nghị ngăn các nhà cung cấp NHS mua accessibility overlay, thứ thực sự gây hại cho trải nghiệm của người dùng khuyết tật và làm lãng phí tiền lẽ ra nên dùng để cải thiện các dịch vụ cốt lõi: https://petition.parliament.uk/petitions/765480/
Tôi không thể ký vì trình xác minh của Cloudflare cho rằng tôi không phải con người
Có một video giải thích tình hình này rất dễ hiểu: https://youtu.be/XNLUfqtgBUk
Nếu đây là lĩnh vực chuyên môn của bạn, rất mong bạn ký vào thư ngỏ
Ngay cả khi NHS đồng ý và muốn triển khai, chỉ riêng việc xây dựng hướng dẫn liên quan cũng sẽ mất ít nhất 1 năm
Sau đó nếu bảo đội kỹ thuật hiện tại dọn dẹp thì chắc lại mất thêm 10 năm nữa
Bài viết liên quan: 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)
Trong vài tuần qua tôi đã nói chuyện về chủ đề này với các CISO, CTO, maintainer và đồng nghiệp; một số thuộc các công ty F50, và kế hoạch mặc định của họ là ngừng đóng góp và sử dụng mã nguồn mở cho đến khi đội bảo mật ứng dụng có thể dễ dàng xác minh và sửa vấn đề trong vòng một ngày
Trước đây thời gian phản ứng end-to-end thường khoảng 8~10 ngày, nhưng giờ thì không thể trụ nổi với tốc độ đó nữa
Tôi không xem đây là cái chết của mã nguồn mở, nhưng nó cho thấy kinh tế của mã nguồn mở đã biến thành bi kịch tài sản chung khi maintainer không được cung cấp nguồn lực vận hành bền vững
Đây cũng là sự thừa nhận rằng các tổ chức suốt nhiều thập kỷ đã không ưu tiên bảo mật cả trong nội bộ kỹ thuật lẫn ở cấp độ tổ chức, nhưng nhìn mức độ thảo luận ở đây trên HN thì có lẽ đó là một cuộc tranh luận khác
Nếu những người yêu mã nguồn mở thực sự quan tâm, thì đừng chỉ nói chuyện lý tưởng mà phải bỏ tiền ra; cần nghĩ đến việc chuyển sang open core hoặc thiết lập cơ chế tài trợ và bảo trợ chính thức
Cũng quan trọng không kém là áp dụng các giấy phép hạn chế hơn nhiều nhưng vẫn cho phép chủ sở hữu dự án thương mại hóa. Phần lớn các dự án kiểu GNU vốn dựa vào thiện chí của vài cá nhân cùng chí hướng sẽ khó sống sót, và người đóng góp cũng cần được trả công
Với câu hỏi “chẳng lẽ có thể dừng Linux/Kubernetes/Chrome(kể cả Edge)/gần như mọi ngôn ngữ lập trình/nginx v.v. sao”, ý ở đây là sẽ đóng băng mọi dependency và thư viện từ nay về sau, và không công khai mã nguồn cho đến khi có thể sửa lỗ hổng end-to-end trong vòng 24 giờ
Các đội cũng đang nghiêm túc cân nhắc việc fork các dự án cốt lõi và dependency để dùng nội bộ, đồng thời không đóng góp upstream vì lo ngại đóng góp upstream đã bị nhiễm hoặc có thể đưa thêm lỗ hổng vào
“Một kết quả thú vị là các thư viện mã nguồn mở trở nên có giá trị hơn, vì chi phí token dùng cho bảo mật có thể được chia sẻ cho mọi người dùng. Điều này trực tiếp bác bỏ ý tưởng rằng có thể dùng vibe coding để tạo ra các bản thay thế thư viện mã nguồn mở với chi phí rẻ, từ đó làm giảm sức hấp dẫn của các dự án mã nguồn mở hiện có”
Tôi hiểu phản xạ muốn fork mã và mang vào nội bộ, nhưng khi điều đó làm tăng lượng mã mà đội kỹ thuật phải quản lý và giảm thiểu lỗ hổng, thì tôi nghi ngờ nó bền vững đến mức nào
[0] https://simonwillison.net/2026/Apr/14/cybersecurity-proof-of...
Chắc đâu thể dừng Linux/Kubernetes/Chrome(kể cả Edge)/gần như mọi ngôn ngữ lập trình/nginx v.v., nên tôi thấy thắc mắc