- Cal.com chuyển phần mã cốt lõi sang chế độ đóng vì mối đe dọa phát hiện lỗ hổng dựa trên AI, đồng thời nhắc đến một thời đại mà "minh bạch đồng nghĩa với phơi bày"
- Strix là dự án mã nguồn mở phát triển tác nhân bảo mật AI tự chủ, và đã hợp tác với Cal.com để thực hiện quy trình công bố lỗ hổng có trách nhiệm
- Strix chỉ ra rằng việc đóng mã không phải là giải pháp cho các mối đe dọa bảo mật AI, mà ngược lại còn chặn mất cơ hội rà soát từ những người có thiện chí
- Tấn công bằng AI vẫn có thể xâm nhập theo kiểu hộp đen mà không cần truy cập mã, và chiến lược đóng mã vẫn dễ tổn thương trước các cuộc tấn công tự động
- Giải pháp thực sự là tích hợp phòng thủ AI vào quy trình phát triển và duy trì tính minh bạch và hợp tác của mã nguồn mở thông qua xác minh tự động liên tục
Cal.com chuyển sang đóng mã và cuộc tranh luận về bảo mật mã nguồn mở
- Cal.com thông báo sẽ chuyển codebase cốt lõi từ mã nguồn mở sang chế độ đóng
- CEO Bailey Pumfleet cho biết AI giờ đây có thể tự động phát hiện lỗ hổng ở quy mô lớn, mở ra một thời đại mà "minh bạch đồng nghĩa với phơi bày"
- Lý do được đưa ra là AI nay có thể quét mã và khai thác gần như với "chi phí bằng 0"
- Strix là dự án mã nguồn mở phát triển tác nhân bảo mật AI tự chủ, gần đây đã vượt mốc 24k sao GitHub
- Xử lý hơn 15 tỷ token LLM mỗi ngày để phát hiện lỗ hổng phần mềm
- Đã hợp tác với Cal.com để thực hiện quy trình công bố lỗ hổng có trách nhiệm bằng Strix, và chưa công khai chi tiết về các lỗi vẫn chưa được vá
- Thừa nhận quyết định của Cal.com xuất phát từ mong muốn bảo vệ người dùng
- Tuy nhiên, Strix nhấn mạnh rằng "đóng mã không phải là giải pháp cho các mối đe dọa bảo mật dựa trên AI"
- Họ đồng ý rằng AI đã thay đổi bảo mật một cách căn bản, nhưng phản đối việc từ bỏ mã nguồn mở
AI hộp đen vẫn có thể xâm nhập cả mã đóng
- Giả định rằng đóng mã nguồn sẽ khiến kẻ tấn công không thể đọc mã không còn đúng với mô hình tấn công AI hiện đại
- Điều này từng đúng với các công cụ phân tích tĩnh trước đây, nhưng tác nhân AI tự chủ có thể tấn công mà không cần truy cập mã
- Các công cụ như Strix được tối ưu cho kiểm thử hộp đen và hộp xám
- Chúng tương tác với endpoint thực để thao tác trạng thái trình duyệt, phân tích lưu lượng mạng và phát hiện lỗ hổng trong logic nghiệp vụ
- Việc đóng mã chỉ chặn cơ hội rà soát của các nhà phát triển có thiện chí, trong khi bề mặt tấn công như API hay webhook vẫn lộ ra cho kẻ tấn công
Chiến lược “ẩn để bảo mật” dễ thua trước tấn công tự động
- Mã đóng phụ thuộc vào đội ngũ bảo mật nội bộ và các bài kiểm thử xâm nhập thủ công định kỳ
- Nhưng kẻ tấn công lại dùng bot AI hoạt động không ngừng để tìm lỗ hổng 24/7
- Cách tiếp cận này dựa trên giả định rằng nhân sự nội bộ có thể tìm ra lỗi nhanh hơn AI tấn công từ bên ngoài, nhưng điều đó gần như không thể trong thực tế
- Trong quá khứ, "bảo mật bằng che giấu" (Security through obscurity) đã nhiều lần thất bại,
và trong thời đại AI, tốc độ thất bại đó sẽ tăng theo cấp số nhân
Giải pháp thực sự: dùng AI để phòng thủ trước AI
- Đúng là tốc độ phát triển phần mềm đã vượt xa tốc độ rà soát bảo mật của con người
- Nhưng giải pháp là tích hợp phòng thủ AI vào quy trình phát triển, chứ không phải che giấu mã
- Cần có xác minh liên tục dựa trên AI (continuous validation)
- Khi nhà phát triển mở Pull Request, AI sẽ lập tức thử tấn công
- Khi hạ tầng thay đổi, AI sẽ tự động xác minh bề mặt tấn công
- Kiểm thử bảo mật phải được tự động hóa trong pipeline CI/CD,
và cần đối phó bằng tự động hóa nội bộ tốt hơn cả tự động hóa tấn công
Mã nguồn mở vẫn còn nguyên giá trị
- Nguyên tắc truyền thống “nhiều con mắt khiến lỗi trở nên dễ thấy” có thể suy yếu,
nhưng mã nguồn mở tự thân không hề chết
- Strix tiếp tục duy trì mã nguồn mở với niềm tin rằng minh bạch tạo nên sức mạnh
- Các công cụ bảo mật thế hệ tiếp theo cần phải dễ tiếp cận và cởi mở như chính các công cụ tấn công
- Việc che giấu mã không thể ngăn hacker AI,
nhưng trao cho nhà phát triển các tác nhân bảo mật tự chủ sẽ làm tăng khả năng phòng thủ
- Strix cung cấp bản trải nghiệm miễn phí cho kiểm thử bảo mật liên tục dựa trên AI
1 bình luận
Ý kiến trên Hacker News
Tôi đang vận hành một dự án mã nguồn mở, và trong vài tháng gần đây, số lượng báo cáo lỗ hổng bảo mật đã tăng vọt
Phần lớn là các trường hợp nhỏ nhặt, nhưng cũng có vấn đề thật sự và tôi đã sửa tất cả
Phần mềm đóng sẽ không nhận những báo cáo kiểu này, nhưng có rủi ro bị AI khai thác
Vì vậy tôi hoàn toàn đồng cảm với thông điệp của bài viết này
Chỉ là đóng với bên ngoài thôi, chứ không đóng với các nhà phát triển nội bộ
Chỉ là từ khi công cụ AI xuất hiện, lại nảy sinh vấn đề người mới gửi các báo cáo ảo do AI bịa ra
Các công ty phần mềm đóng cũng nên chủ động thực hiện kiểm toán bảo mật
Tôi hiểu việc Cal.com chuyển sang mô hình đóng, nhưng rốt cuộc nó trông giống marketing của Strix hơn
Các công ty mã nguồn mở càng tiếp tục công khai thì thiệt hại càng lớn
Nếu công bố định kỳ các báo cáo kiểu này, có lẽ sẽ chứng minh được độ tin cậy về bảo mật
Tuy vậy các dự án hiện có đang chất đống các vấn đề mức trung bình và nhẹ, nên có lẽ sẽ mất thời gian để xử lý
Tức là đang đồng thời tận dụng phát hiện lỗ hổng bằng AI và phòng thủ nhiều lớp trong trạng thái mã nguồn không công khai
Lý do CEO đưa ra rằng “AI tự động phát hiện lỗ hổng ở quy mô lớn” nghe như một cái cớ
Lý do thật sự có lẽ là vì rất khó tạo ra mô hình kinh doanh bền vững với mã nguồn mở
Việc chuyển sang mô hình đóng thực ra bất lợi cho kinh doanh, nhưng chúng tôi đánh giá việc bảo vệ dữ liệu khách hàng quan trọng hơn
Dù là cắt giảm nhân sự hay đổi giấy phép thì cái cớ “vì AI” đều rất tiện
Những nơi như npmjs có khi sớm biến thành website tham khảo
Việc đổ cho AI scanner chỉ là bao bì PR mà thôi
Bài này đúng là như giáo trình content marketing
Đây là một ví dụ pha trộn rất khéo giữa sự chân thành và marketing
Trên thực tế Strix đã quét mã của Cal.com nhưng bỏ sót nhiều lỗ hổng
Không có nền tảng nào hoàn hảo, và chỉ riêng AI scanner là không đủ
“Security through obscurity” chỉ là vấn đề khi được dùng một mình
Nhưng như một lớp răn đe làm tăng chi phí cho kẻ tấn công thì đây vẫn là chiến lược hiệu quả
Rốt cuộc bảo mật là cuộc chiến xem bên nào đổ nhiều tài nguyên hơn
AI chỉ hiệu quả hơn con người, chứ phép tính cốt lõi giữa mở và đóng không thay đổi
Tôi tự hỏi liệu Cal.com thật sự lo về bảo mật, hay chỉ đang lấy đó làm cái cớ để che đi khó khăn của SaaS mã nguồn mở
Lập luận này đã bị chứng minh là sai từ hàng chục năm trước rồi
Tôi không tin “bảo mật bằng che giấu” là lý do thật sự
Chỉ là họ nghĩ rằng đóng mã nguồn lại thì kiếm được nhiều tiền hơn
Một trong những mặt xấu của mã nguồn mở là mọi người coi lao động miễn phí là điều hiển nhiên
Thay vì cảm ơn những lập trình viên đã làm không công suốt nhiều năm, họ lại tức giận vì những người đó không tiếp tục làm miễn phí nữa
Trong khi chính họ cũng không đi làm mà không nhận lương
Đọc bài thì có vẻ Cal.com đã từng được red-team bot kiểm thử lỗ hổng
Có thể bug bị phát hiện quá nhanh khiến CEO cảm thấy gánh nặng chi phí sửa lỗi, rồi quyết định đóng mã nguồn
Về thực chất nó trông như một tuyên bố công khai rằng “mã của Cal.com có rất nhiều lỗ hổng”
Nếu tinh chỉnh để giảm bớt thì lại có nguy cơ bỏ sót lỗ hổng thật, và cuối cùng chi phí xác minh sẽ tăng cao
Với mã nguồn mở, các báo cáo như vậy bị công khai nên dẫn tới tổn hại danh tiếng, còn phần mềm đóng thì không
Vì thế họ cũng có thể đã chuyển sang mô hình đóng vì lý do đó
Rủi ro thật sự không phải là phát hiện lỗ hổng, mà là khả năng LLM viết lại dự án mã nguồn mở sang ngôn ngữ khác để lách giấy phép
Về mặt pháp lý thì khá mập mờ. Nếu con người học rồi tự viết lại thì ổn, nhưng nếu AI làm thì thực chất chỉ là copy-paste phức tạp
Trong những trường hợp như vậy, chưa rõ giấy phép sẽ được áp dụng ra sao
Chỉ công khai mã nguồn thôi thì không đủ để tạo ra một doanh nghiệp, năng lực vận hành mới quan trọng hơn
Tôi đồng ý với lập luận rằng kiểm thử bảo mật phải được tự động hóa trong pipeline CI/CD
Nhưng điều đó không chứng minh được sự cần thiết của mã nguồn mở
Sự cân bằng của mã nguồn mở đã bị phá vỡ từ lâu
Cấu trúc mà các công ty dùng mã nguồn mở để tạo ra sản phẩm trả phí mà không đóng góp lại đã tồn tại từ rất lâu rồi
PHP là một ví dụ: cả thế giới dùng nhưng vẫn là một ngôn ngữ thiếu ngân sách