Cal.com chuyển từ mã nguồn mở sang mã nguồn đóng vì các mối đe dọa bảo mật từ AI

• Cal.com, vốn được vận hành dưới dạng mã nguồn mở trong 5 năm, đã quyết định chuyển sang mã nguồn đóng do các mối đe dọa bảo mật dựa trên AI gia tăng
• Khi thời đại AI tự động phân tích codebase để tìm lỗ hổng đã đến, mã nguồn công khai trở thành đầu mối trực tiếp cho kẻ tấn công
• Công ty đã chọn ưu tiên giảm rủi ro bảo mật thay vì duy trì mã nguồn mở để bảo vệ dữ liệu khách hàng
• Để tiếp tục tinh thần mã nguồn mở, công ty công bố dự án Cal.diy theo giấy phép MIT, cung cấp phiên bản tự host dành cho cộng đồng
• Khi AI phát triển với tốc độ lấn át các hệ thống bảo mật hiện có, Cal.com cho biết muốn quay lại mã nguồn mở sau khi ổn định bảo mật

---

Quyết định chấm dứt mã nguồn mở của Cal.com và các mối đe dọa bảo mật từ AI

• Cal.com đã hoạt động dưới dạng mã nguồn mở trong 5 năm, nhưng đã quyết định chuyển sang mã nguồn đóng (Closed Source) do các mối đe dọa bảo mật dựa trên AI tăng vọt
  • Công ty đặt việc bảo vệ dữ liệu khách hàng lên hàng đầu và cho rằng việc tiếp tục duy trì mã nguồn mở không còn an toàn nữa
  • Công ty cho biết đây “không phải là một lựa chọn dễ dàng”
• Trước đây, để khai thác lỗ hổng ứng dụng cần đến thời gian và công sức của hacker có tay nghề, nhưng nay đã bước sang thời đại AI tự động quét codebase để tìm lỗ hổng
  • Mã nguồn mở được mô tả là “giống như trao bản thiết kế két sắt cho kẻ tấn công”
  • Khi các startup bảo mật AI thương mại hóa khả năng này, chúng phát hiện ra các loại lỗ hổng khác nhau, khiến việc thiết lập một chuẩn bảo mật thống nhất đáng tin cậy trở nên khó khăn
• Cal.com cho biết họ buộc phải chọn một trong hai hướng
  • Tiếp tục duy trì mã nguồn mở và chấp nhận rủi ro với dữ liệu khách hàng, hoặc
  • Chuyển sang mã nguồn đóng để giảm rủi ro
  • Dù không phải giải pháp hoàn hảo, công ty xem đây là quyết định không thể tránh khỏi để bảo vệ người dùng
• Để tiếp nối tinh thần mã nguồn mở, công ty công bố một dự án riêng là Cal.diy theo giấy phép MIT
  • Cal.diy là phiên bản mở cho nhà phát triển và người dùng đam mê, một phiên bản tập trung vào cộng đồng có thể tự host
  • Codebase của dịch vụ chính đã được thay đổi lớn ở các cấu trúc cốt lõi như hệ thống xác thực và xử lý dữ liệu, nên đã được tách biệt về mặt kỹ thuật với Cal.diy
• AI đang nhanh chóng làm thay đổi môi trường bảo mật, và bài viết cũng nhắc đến một trường hợp AI tìm ra lỗ hổng tồn tại suốt 27 năm trong kernel BSD chỉ trong vài giờ và tạo exploit
  • Tốc độ và độ chính xác như vậy đang lấn át các hệ thống ứng phó bảo mật hiện có
  • Cal.com cho biết họ đang thực hiện mọi biện pháp có thể để bảo vệ khách hàng, ứng dụng và dữ liệu nhạy cảm, đồng thời bày tỏ mong muốn quay lại mã nguồn mở khi môi trường bảo mật ổn định hơn

Hướng đi sắp tới và thông điệp

• Hiện tại, giảm thiểu rủi ro bảo mật và bảo vệ người dùng là ưu tiên hàng đầu
• Mối quan hệ với cộng đồng mã nguồn mở sẽ được duy trì thông qua Cal.diy
• Về dài hạn, công ty vẫn để ngỏ khả năng quay lại mã nguồn mở tùy theo sự tiến hóa của môi trường bảo mật
• Quyết định lần này cho thấy thực tế bảo mật trong kỷ nguyên AI đang tác động trực tiếp đến mô hình phân phối phần mềm

[GN⁺]

Ý kiến trên Hacker News

• Drew Breunig hôm qua đã đưa ra kết luận hoàn toàn ngược lại trong bài viết của mình
  Giờ đây lỗ hổng bảo mật đã trở thành một loại tài nguyên có thể tìm ra bằng cách tiêu token, nên ngược lại, mã nguồn mở còn có giá trị hơn
  Mã nguồn mở cho phép nhiều dự án chia sẻ chi phí kiểm toán, còn mã nguồn đóng thì phải tự mình tìm toàn bộ lỗ hổng

  • Bài đó đã được đăng lại ở đây. Tiêu đề là Cybersecurity looks like proof of work now
  • Có vẻ lý do thật sự là để ngăn AI tẩy rửa bản quyền (copyright-wash) cho sản phẩm. Bảo mật chỉ là cái cớ
  • Kết luận này nghe thuyết phục hơn. Mythos mới xuất hiện được vài tuần mà đã đổi nguyên tắc nhanh như vậy thì khá lạ. Có lẽ là vì lý do kinh doanh, và giờ họ chỉ đang tìm một cái cớ dễ bán với công chúng
  • Xét về kinh tế thì đây cũng là kết luận hợp lý. Cuối cùng либо phải tạo ra đủ giá trị để gánh chi phí token, либо phải làm giảm lợi ích kinh tế của việc tìm ra lỗ hổng
    Điều đó có thể làm bằng cách giảm phạm vi triển khai hoặc hạ quyền hệ thống.
    Có vẻ tương lai sẽ tiến hóa theo hướng “đặc tả mở + sinh mã dựa trên mô hình”. Bảo mật và quản trị có lẽ sẽ diễn ra ở lớp mô hình
  • Câu nói “muốn củng cố hệ thống thì phải tiêu nhiều token hơn kẻ tấn công” nghe không hợp lý. Nếu phần mềm ổn định thì bề mặt tấn công sẽ giảm đi, và Mythos không tạo ra lỗ hổng mới. Người phòng thủ lẽ ra phải có lợi thế về token

• Tôi là người phụ trách dự án Thunderbird. Công cụ quản lý lịch hẹn của chúng tôi, Thunderbird Appointment, sẽ luôn được giữ là mã nguồn mở
  Tôi mời mọi người cùng xây dựng nó tại kho GitHub. Chúng tôi sẽ giúp nó trở thành một lựa chọn thay thế cho Cal.com

  • Sẽ tốt hơn nếu thêm ảnh chụp màn hình vào README hoặc trang trước đăng nhập. Công cụ trông ổn đấy, nhưng tôi tò mò về giá của bản được host
  • Nhưng trên laptop Linux cũ thì Thunderbird quá nặng. Mong dự án cũng nghĩ đến người dùng cấu hình thấp. Xin hãy giữ Internet ở mức còn có thể sử dụng được
  • Tôi vào trang, nhập email rồi bị đưa vào danh sách chờ, cuối cùng email lại bị chặn. Trải nghiệm người dùng không tốt
  • Có người đùa với câu “hãy cùng xây dựng với chúng tôi” rằng, “Vậy có cần đặt lịch hẹn (appointment) không?”
  • Cũng có phản hồi tích cực rằng đây trông như một lựa chọn thay thế tốt

• Nếu LLM giỏi tìm lỗ hổng mã nguồn đến thế, thì chẳng phải chỉ cần chạy LLM pentest nội bộ trước khi phát hành sao?
  Cảm giác như định luật Linus(liên kết) giờ mới thật sự thành hiện thực

  • Nhưng sau khi phát hành, kẻ tấn công có thể phân tích mã với thời gian vô hạn và các LLM ngày càng thông minh hơn.
    Muốn phòng thủ thì phải làm trước trong mỗi bản phát hành tất cả những gì kẻ tấn công có thể làm
  • Khi LLM tiến bộ, việc bảo trì FOSS làm tăng vọt chi phí thời gian và nhân lực.
    Các issue hay PR chất lượng thấp do AI tạo ra ngày càng nhiều, khiến động lực duy trì mã nguồn mở giảm xuống.
    Khi sản phẩm thương mại dựa trên lõi FOSS, có lẽ sẽ còn nhiều cuộc chuyển đổi kiểu này hơn
  • Với mã nguồn đóng, có thể dùng LLM nội bộ để tăng cường bảo mật.
    Nhưng cũng có thể hiểu được việc đóng lại để không mở cơ hội tấn công ra bên ngoài
  • Trong môi trường commit liên tục, mỗi lần đều phải quét toàn bộ codebase bằng LLM nên chi phí tăng bùng nổ.
    Ngay cả những nơi như GitHub cũng đã có chi phí phân tích tĩnh rất cao
  • Cuối cùng, có ý kiến cho rằng nên viết mã đơn giản, và thực hiện kiểm thử bảo mật LLM cả ở cấp trình biên dịch

• Quyết định lần này có vẻ là phán đoán mang tính kinh doanh hơn là bảo mật.
  Nhờ AI mà việc self-hosting trở nên dễ hơn, nên doanh thu hosting trả phí của các dự án mã nguồn mở đang giảm

  • Mọi người dùng LLM để tự triển khai “tính năng pro” hoặc tìm ra các điểm mở rộng. Bảo mật chỉ là vỏ bọc
  • Đổ lỗi cho AI chỉ là cái cớ. AI vốn đã học từ mã rồi. Nếu kết hợp thuật toán di truyền + fuzzing thì nó học nhanh hơn con người rất nhiều
  • Dạo này cái gì cũng đổ cho AI. Cắt giảm nhân sự, ngừng sản phẩm, đóng mã nguồn, tất cả đều bị quy là do AI
  • Sản phẩm này đã dần trở thành hàng hóa phổ thông (commoditized), giống như công cụ đặt lịch của Google Workspace
  • Cuối cùng còn xuất hiện cả chỉ trích rằng họ là “kẻ bán mình” (sellout)

• Với tư cách là khách hàng tiềm năng, tôi thất vọng về quyết định của Cal.com.
  Mã nguồn mở có thể tạo dựng niềm tin nhờ SSDLC minh bạch, còn với mã nguồn đóng thì chỉ còn cách tin nhà cung cấp
  Tôi không đồng ý với lập luận của Drew Breunig. Số lượng bug là hữu hạn, và nếu một mô hình đủ mạnh quét mã định kỳ thì xác suất còn sót lỗ hổng sẽ giảm mạnh

• “Nếu AI có thể quét mã nguồn mở thì sao?” → Thì cứ sửa bug thôi.
  Lập luận này hoàn toàn không thuyết phục

• “Vì AI có thể truy cập mã nên chúng tôi sẽ đóng lại” chỉ là cái cớ mà thôi

  • Lý do thật sự không phải AI hay bảo mật, mà là vì có quá nhiều dự án clone nên doanh thu bị giảm

• Rốt cuộc quyết định này trông như bảo mật nhờ che giấu (Security through obscurity).
  Khó hiểu là từ bao giờ đó lại trở thành mô hình đúng đắn

  • Che giấu chỉ có hiệu quả khi nó không phải tuyến phòng thủ chính mà là biện pháp răn đe bổ trợ
  • Giảm bề mặt tấn công không phải là che giấu mà là chiến lược tối thiểu hóa vector tấn công
  • Dù vậy cũng có ý kiến cho rằng nó vẫn tốt hơn “bảo mật không có che giấu”
  • Có người tự xưng là đồng sáng lập nói rằng “thằng nhóc 16 tuổi nhà bên chỉ cần 15 phút và 100 đô là có thể hack được”
  • Có vẻ họ đã quên vì sao lại có khái niệm “đừng làm bảo mật bằng che giấu”.
    Không phải vì các thế hệ trước ngu ngốc, mà vì đó là cách tiếp cận trông có vẻ ổn nhưng đã thất bại

• Câu nói của Cal.com rằng “chúng tôi đã tin vào mã nguồn mở” nghe rất sáo rỗng.
  Nếu thật lòng thì họ đã không đưa ra những lời bào chữa vô nghĩa như thế

• Đây là cái cớ đã có thể dùng từ trước cả thời AI.
  Có vẻ đây là nỗ lực bảo vệ doanh thu vì sản phẩm cốt lõi không đủ khác biệt.
  Cuối cùng chỉ là biện pháp để bảo vệ doanh thu mà thôi