Discourse khẳng định sẽ không chuyển sang mã nguồn đóng, bất chấp lo ngại về AI

Gần đây, Cal.com đã thông báo đóng cửa mã nguồn của họ và sẽ không còn là một sản phẩm mã nguồn mở. Lý do được đưa ra là AI đã khiến mã nguồn mở trở nên quá nguy hiểm đối với các công ty SaaS; mã có thể bị quét và khai thác bởi AI với chi phí gần như bằng không, và sự minh bạch giờ đây đang trở thành sự phơi bày.

Tôi hiểu xuất phát điểm của quan điểm này; ngành công nghiệp đang thay đổi rất nhanh. Các mô hình AI mới với khả năng an ninh mạng mới được phát hành mỗi vài tuần. Đây là một thế giới đáng sợ, và tôi hoàn toàn đồng ý rằng các công ty mã nguồn mở cần thích nghi.

Tuy nhiên, tôi không đồng ý rằng việc đóng mã nguồn là giải pháp cho cơn bão bảo mật đang ập đến. Tôi không đồng ý rằng đây là quyết định đúng đắn cho các nhà cung cấp SaaS, và tôi cũng không đồng ý rằng đây là quyết định đúng đắn cho toàn ngành.

Tôi muốn rõ ràng và kiên định về lập trường của Discourse: Chúng tôi là mã nguồn mở, chúng tôi luôn là mã nguồn mở và chúng tôi sẽ tiếp tục là mã nguồn mở.

Kể từ khi Jeff, Robin và tôi đẩy các commit đầu tiên lên kho lưu trữ Discourse trên GitHub hơn một thập kỷ trước, kho lưu trữ đó đã được cấp phép theo GPLv2. Và điều đó sẽ không thay đổi.

Lập luận của phe ủng hộ mã nguồn đóng

Quan điểm của Cal.com xoay quanh việc khẳng định rằng nếu kẻ tấn công có thể đọc mã của bạn, AI sẽ cho phép chúng khai thác nhanh hơn bạn có thể củng cố hoặc vá lỗi, và hành động bắt buộc bạn cần thực hiện là giấu mã đi để mua thời gian. Có một sự thật trong mối đe dọa này — AI đã thay đổi tốc độ phát hiện lỗ hổng. Trong vài tháng qua, đội ngũ của chúng tôi đã tìm thấy và giải quyết một lượng rất lớn các vấn đề bảo mật tiềm ẩn trong Discourse bằng cách sử dụng GPT-5.3 Codex, GPT-5.4 và Claude Opus 4.6 trên cơ sở mã nguồn mở của chúng tôi.

Nhưng tôi nghĩ cuộc đua để đóng kín phần mềm đang bỏ lỡ một điều. Những hệ thống AI đó thực sự không cần mã nguồn của bạn để tìm lỗ hổng; chúng hoạt động chống lại các tệp nhị phân đã biên dịch và các API dạng hộp đen (black-box).

Mã nguồn đóng luôn là một hàng phòng thủ yếu hơn cho SaaS so với những gì mọi người thừa nhận. Một ứng dụng web không phải là thứ bạn xuất bản một lần và giấu đi. Các phần lớn của nó được gửi thẳng vào trình duyệt của người dùng trong mọi yêu cầu: JavaScript, hợp đồng API, luồng phía khách hàng, logic xác thực và hành vi của tính năng. Kẻ tấn công có thể kiểm tra tất cả những thứ đó rồi, và AI làm cho việc kiểm tra đó rẻ hơn đáng kể. Việc đóng kho lưu trữ có thể giấu một số chi tiết triển khai phía máy chủ, nhưng nó không làm cho hệ thống vô hình. Điều nó chủ yếu làm là giảm số lượng người bảo vệ có thể kiểm tra toàn bộ bức tranh.

Cơ sở hạ tầng internet quan trọng nhất thế giới chạy trên phần mềm mã nguồn mở, đặc biệt là Linux. Mã đó chịu sự giám sát liên tục từ những kẻ tấn công, người bảo vệ, nhà nghiên cứu, nhà cung cấp đám mây và người bảo trì trên toàn cầu. Nó bị tấn công không ngừng nghỉ, nhưng nó cũng được củng cố không ngừng nghỉ. Đó là bài học thực sự của mã nguồn mở trong bảo mật: sự minh bạch không loại bỏ rủi ro, nhưng nó cho phép một phản ứng phòng thủ lớn hơn nhiều.

AI thay đổi phương thức tính toán bảo mật, nhưng tôi vẫn tin rằng nó có lợi cho mã nguồn mở. Có đúng là các công cụ quét hỗ trợ bởi AI hiện có thể đưa ra các vấn đề bảo mật trong vài giờ mà trước đây các nhà nghiên cứu con người mất vài tuần để phát hiện. Nhưng câu hỏi then chốt là: Ai được sử dụng những công cụ đó?

Nếu mã của bạn là mã nguồn mở, đội ngũ bảo mật của bạn có thể quét nó, người đóng góp của bạn có thể quét nó, và các nhà nghiên cứu độc lập cũng có thể quét nó. Điều đó không đảm bảo những người bảo vệ sẽ luôn đến trước, nhưng nó làm tăng đáng kể số lượng người có thể giúp tìm ra các vấn đề thực sự sớm. Nếu mã của bạn bị đóng, kẻ tấn công vẫn có thể nghiên cứu sản phẩm từ bên ngoài thông qua trình duyệt, API, ứng dụng di động và hành vi của hệ thống đang chạy, trong khi chỉ đội ngũ nội bộ của bạn mới có quyền truy cập trực tiếp vào toàn bộ mã. Đó không phải là sự giảm thiểu sự phơi bày. Đó là sự giảm thiểu khả năng phòng thủ.

Tại Discourse, chúng tôi đã dựa vào thực tế này. Bản phát hành hàng tháng gần đây của chúng tôi bao gồm các bản sửa lỗi cho 50 vấn đề bảo mật được xác định thông qua các lần quét nhiều ngày bằng GPT-5.4 xhigh. Mã nguồn mở tạo ra một sự khẩn cấp hữu ích: khi mã của bạn công khai, bạn giả định rằng nó sẽ được kiểm tra kỹ lưỡng, vì vậy bạn đầu tư sớm và quyết liệt hơn để tìm và sửa các vấn đề trước khi kẻ tấn công làm điều đó.

Trong môi trường mã nguồn đóng, bạn có thể lầm tưởng rằng mình an toàn vì không ai có thể nhìn thấy. Một phần các vấn đề đó vẫn sẽ nằm đó, chưa được người bảo vệ phát hiện và chờ kẻ tấn công tình cờ tìm thấy. Đó không phải là một kịch bản tốt hơn.

Tại sao các công ty chuyển sang mã nguồn đóng

Tôi muốn công bằng với Cal.com ở đây, vì tôi không nghĩ họ hành động với ý đồ xấu. Tôi chỉ nghĩ lập luận bảo mật là một khung thuận tiện cho các quyết định thực sự liên quan đến điều gì khác.

Áp lực cạnh tranh, chủ yếu là vậy. Nếu mã của bạn mở, đối thủ cạnh tranh có thể đọc kiến trúc và tư duy sản phẩm của bạn. Điều đó gây đau đớn, và nó trở nên đau đớn hơn khi bạn phát triển — đặc biệt là lần đầu tiên một đối thủ được tài trợ tốt fork kho lưu trữ của bạn và tung ra phiên bản lưu trữ với giá bằng một nửa giá của bạn.

Quản trị là vấn đề lớn khác. Các cộng đồng mã nguồn mở thường phản đối. Họ báo cáo các vấn đề về các quyết định họ không thích. Họ fork. Việc quản lý rất mệt mỏi, và việc đóng mã làm tiếng ồn biến mất ngay lập tức. Sau đó bạn có các nhà đầu tư hỏi tại sao bạn lại tặng thứ mà họ vừa tài trợ, và đột nhiên "mã nguồn đóng" trông có vẻ dễ bảo vệ hơn trong một bản trình bày hội đồng quản trị.

Đây là những áp lực kinh doanh hợp pháp, và tôi không phán xét bất kỳ ai vì cảm thấy chúng. Nhưng chúng là quyết định kinh doanh, không phải quyết định bảo mật. Định hình một quyết định kinh doanh như một mệnh lệnh bảo mật là làm tổn hại đến hệ sinh thái mã nguồn mở đã giúp Cal.com đến được nơi họ đang đứng.

Cách chúng tôi xử lý bảo mật vào năm 2026

Mỗi chu kỳ phát hành, đội ngũ của chúng tôi triển khai các trình quét lỗ hổng AI mới nhất (hiện tại là GPT-5.4 xhigh, và tiếp theo là Opus 4.7 max) để phân tích sâu mã nguồn của chúng tôi trong nhiều ngày. Các lần quét bắt được cùng một lớp lỗ hổng mà AI của kẻ tấn công sẽ tìm thấy, và chúng tôi vá chúng trước.

Quét bảo mật được thực hiện bằng quy trình nhiều bước. Chúng tôi lặp qua hàng trăm bộ điều khiển, xem xét từng bộ điều khiển độc lập để tìm lỗ hổng. Sau đó, đối với mỗi ứng viên lỗ hổng chúng tôi tìm thấy trong các lần quét hàng loạt, chúng tôi xác thực nó bằng cách hướng dẫn một tác nhân viết một bài kiểm tra thất bại bên trong một vùng chứa chạy môi trường Discourse hoạt động đầy đủ. Chỉ khi nó có thể chứng minh rằng vấn đề nó tìm thấy là thực sự, chúng tôi mới tính nó là một vấn đề và chuyển nó lên hàng đợi của con người. Một lợi thế lớn là chúng tôi cũng nhận được một bản vá hoạt động ứng viên để chúng tôi xác thực trong quá trình này.

Việc quét toàn bộ cơ sở mã hiện khá rẻ vì được trợ giá mạnh. Một lần quét mã nguồn đầy đủ của OpenAI cho Discourse có thể tốn 2.000 đô la nếu bạn trả giá bán lẻ. Cùng một lần quét chỉ tốn khoảng 50 đô la trên gói 200 đô la một tháng. Hơn nữa, OpenAI và Anthropic hào phóng cung cấp các kế hoạch cho nhiều công ty và người đóng góp mã nguồn mở. Chúng tôi cực kỳ tự tin rằng giá sẽ giảm và chất lượng sẽ tăng trong những tháng và năm tới.

Chương trình tiền thưởng lỗi (bug bounty) của chúng tôi hoạt động tốt hơn vì mã là công khai. Các nhà nghiên cứu bảo mật có thể thực hiện phân tích có ý nghĩa mà không cần kỹ thuật đảo ngược. Họ tìm ra lỗi thực, và chúng tôi xử lý chúng với sự khẩn trương. Kiến trúc cũng quan trọng: ngay cả khi kẻ tấn công tìm thấy lỗ hổng, các môi trường thực thi sandbox, giới hạn tốc độ mạnh mẽ, chính sách bảo mật nội dung và nguyên tắc đặc quyền tối thiểu trên mọi ranh giới dịch vụ sẽ giới hạn phạm vi ảnh hưởng.

Khi một lỗ hổng được xác định, quy trình phát hành của chúng tôi có thể đẩy bản vá cho mọi phiên bản Discourse được lưu trữ trong vài giờ. Tốc độ phản ứng là quan trọng nhất. Khám phá nhanh hơn do tính chất mã nguồn mở của chúng tôi có nghĩa là chúng tôi có xu hướng vá lỗi nhanh hơn. Các đóng góp ngược dòng (upstream contributions) khép kín vòng lặp. Khi chúng tôi tìm thấy lỗ hổng trong các phụ thuộc (Rails, Ember, PostgreSQL, Redis), chúng tôi báo cáo chúng và đóng góp bản sửa lỗi. Điều đó làm cho toàn bộ hệ sinh thái an toàn hơn, điều đó làm cho chúng tôi an toàn hơn.

Kết luận

Hệ miễn dịch sinh học hoạt động vì chúng tiếp xúc với các mối đe dọa. Chúng gặp phải mầm bệnh và xây dựng trí nhớ. Một hệ miễn dịch chưa bao giờ bị thách thức sẽ sụp đổ khi nhiễm trùng thực sự đầu tiên xuất hiện. Các cơ sở mã nguồn mở hoạt động theo cách tương tự — các lỗ hổng được tìm thấy và vá làm cho phần mềm khó bị tấn công hơn. Các nhà nghiên cứu bảo mật đọc mã thêm các lớp phòng thủ, và các cuộc kiểm toán công cộng xây dựng kiến thức thể chế về các điểm yếu và cách củng cố chúng.

Mã nguồn đóng có thể mua được sự che giấu, nhưng sự che giấu là mong manh. Mã bị rò rỉ, tệp nhị phân bị đảo ngược kỹ thuật, API được ánh xạ, và kẻ tấn công học được rất nhiều chỉ bằng cách thẩm vấn hệ thống đang chạy. Hàng phòng thủ thực sự không phải là giữ mã giấu kín mãi mãi. Đó là xây dựng phần mềm và các hoạt động vận hành có thể đứng vững khi sự giám sát đến.

Discourse tồn tại nhờ mã nguồn mở. Chúng tôi được xây dựng trên Ruby, trên Rails, trên PostgreSQL, trên Redis, trên Ember, trên Linux và nhiều dự án khác. Tất cả chúng đều mở và được duy trì bởi các cộng đồng tin vào sự minh bạch. Chúng tôi nợ họ điều tương tự.

Chúng tôi sẽ không đóng mã nguồn của mình. Mười ba năm bằng chứng cho thấy sự cởi mở làm cho chúng tôi an toàn hơn. Cộng đồng của chúng tôi xứng đáng được truy cập vào mã chạy các cộng đồng của họ. Và hàng phòng thủ tốt nhất chống lại các cuộc tấn công hỗ trợ bởi AI là hàng phòng thủ hỗ trợ bởi AI, được triển khai bởi càng nhiều người càng tốt, đối với mã mà họ thực sự có thể đọc.

Mã nguồn mở không chết. Nhưng nó cần sự dũng cảm để thực hiện bảo mật đúng cách thay vì rút lui sau một cánh cửa đóng kín và hy vọng không ai có chìa khóa. Chúng tôi đã làm điều đó trong 13 năm và chúng tôi sẽ tiếp tục làm điều đó.