Kỷ nguyên "Khai thác" Bảo mật Mã nguồn mở: Khi AI trở thành thợ săn lỗ hổng

Mùa hè 2026 dự báo sẽ là một giai đoạn đầy sóng gió đối với phần mềm mã nguồn mở (OSS). Nếu bạn là một người bảo trì dự án mã nguồn mở, có một xu hướng đang diễn ra mà bạn cần nắm rõ. Nếu bạn là người sử dụng OSS, việc hiểu rõ điều này sẽ giúp bạn giải thích những hành vi kỳ lạ xung quanh hệ thống của mình trong thời gian tới.

Tóm lại: Việc quét lỗ hổng bảo mật tự động với quy mô lớn, được hỗ trợ bởi các Mô hình Ngôn ngữ Lớn (LLM), đang phát hiện ra rất nhiều vấn đề bảo mật trong bất kỳ mã nguồn nào được công khai.

Khai thác lỗ hổng bảo mật tự động

Sự thay đổi trong báo cáo bảo mật

Về mặt lịch sử, Metabase trung bình nhận được khoảng 10 bài nộp báo cáo mỗi tháng đến hòm thư bảo mật, phần lớn trong số đó là những vấn đề tầm thường hoặc không thực sự là lỗ hổng. Nhiều báo cáo là dương tính giả từ các công cụ quét tự động, và chúng tôi đã dành phần lớn thời gian để giải thích cho người báo cáo rằng những gì họ tìm thấy không thực sự là một vấn đề.

Tuy nhiên, tình hình đã thay đổi vào đầu năm. Kể từ tháng 1, chúng tôi đã nhận trung bình 10 bài nộp mỗi tuần, và nhiều bài trong số đó là hợp lệ. Hầu hết không quá nghiêm trọng, chúng tôi đã âm thầm khắc phục, cảm ơn nhà nghiên cứu và tiếp tục công việc. Tuy nhiên, đây là một bước thay đổi lớn cả về số lượng lẫn chất lượng báo cáo.

Những báo cáo này đến từ nhiều địa điểm và cá nhân khác nhau, đôi khi, nhưng không phải lúc nào cũng vậy, họ đang tìm kiếm tiền thưởng lỗi (bug bounties). Thường thì các báo cáo được viết bằng định dạng markdown và đọc trông giống như được tạo bởi LLM.

Cuộc cách mạng của các tác nhân lập trình (Coding Agents)

Không cần một con mắt quá tinh tường mới nhận ra chúng ta đang thấy sự cải thiện đáng kể trong khả năng quét mã tự động. Chúng tôi đã thử nghiệm một số nhà cung cấp giải pháp trong lĩnh vực này, và không ngạc nhiên khi tìm thấy thêm nhiều vấn đề (may mắn là nhỏ). Không có một nhà cung cấp hay mô hình cụ thể nào là nguyên nhân gốc rễ.

Mặc dù ban đầu chúng tôi nghĩ đó có thể là Claude Security, nhưng dịch vụ này chỉ được công bố vào tháng 2, sau khi tình hình đã bắt đầu nóng lên. OpenAI cũng đang tham gia vào cuộc chơi. Điều này có nghĩa là sẽ có một làn sóng nữa ập đến khi mọi người đều tiếp cận được các công cụ này? Rất có thể. Nhưng bất kể mô hình nền tảng cụ thể nào, đây chỉ là hệ quả tất yếu của việc các tác nhân lập trình nói chung ngày càng giỏi hơn trong việc quét cơ sở mã để tìm lỗi.

Trước đây, chúng tôi thường gặp hai kiểu nghiên cứu lỗ hổng:

• Các công cụ quét bề mặt chạy hàng loạt: Chạy các trình quét OWASP hoặc các công cụ quét lỗ hổng có sẵn khác. Những công cụ này thường tạo ra nhiều dương tính giả.
• Nghiên cứu chuyên sâu có động lực: Thường là người dùng nghiêm túc trả tiền cho các nhà nghiên cứu, những người có kiến thức sâu sắc về lĩnh vực ứng dụng hoặc khung công tác và biết nơi nào cần kiểm tra. Những người này thường tìm ra các nhóm vấn đề tương tự nhau.

Nếu mã của bạn công khai và ai đó sẵn sàng chi tiền (token) để chạy AI, họ có thể quét mã của bạn hàng loạt. Khi các tác nhân lập trình ngày càng hiểu rõ hơn về cơ sở mã (và với tư cách là một người bình thường — đừng đặt cược vào phía đối diện), chúng ta sẽ thấy từng lớp một các lỗ hổng sâu hơn được bóc trần.

Mô hình kinh doanh mới và áp lực lên OSS

Nếu có một điểm sáng trong tất cả những điều này, đó là cho đến nay, dường như có sự trùng khớp về động cơ giữa nghiên cứu đạo đức và các công ty mã nguồn mở thương mại. Nếu bạn là một nhà nghiên cứu bảo mật đang khởi nghiệp, chiến thuật là:

1. Đóng gói Claude/Codex/v.v. vào một bộ kỹ năng và biến nó thành một dịch vụ SaaS.
2. Quét hàng loạt các kho lưu trữ mã nguồn mở thương mại.
3. Gửi mọi phát hiện với chân trang quảng cáo dịch vụ quét tự động SaaS của bạn cho công ty OSS thương mại và bất kỳ người dùng lớn nào bạn có thể lấy từ trang web của họ.

Không cần phải nói, hiện có khoảng 1000 dịch vụ SaaS như vậy, vì vậy đó là một cuộc cạnh tranh khốc liệt, nhưng may mắn thay, có một con đường mang tính xã hội và có lợi nhuận. Với mã nguồn mở phi thương mại, việc này kém sinh lợi hơn — bạn bị mắc kẹt trong việc "khai thác" để tìm tiền thưởng mà người dùng dự án OSS đưa ra.

Tác nhân AI trong lập trình

Tác động dài hạn và ngắn hạn

Về lâu dài, điều này rất tuyệt vời. Chúng ta có nhiều bên thứ ba đang đốt token để giúp bạn tìm ra mọi lỗi khai thác có thể trong phần mềm của mình. Và khi chúng được khắc phục, mọi phần mềm bạn chạy sẽ an toàn hơn và ít gặp vấn đề hơn. Những trình quét này sẽ tăng sinh và cuối cùng có thể sẽ tìm đường vào quy trình CI (Tích hợp liên tục) của bạn.

Tuy nhiên, trong ngắn hạn, mọi chuyện sẽ khá khó khăn.

Để bắt đầu, bạn nên giả định rằng bất kỳ lỗ hổng nào được tiết lộ cho bạn hiện nay đều có thể được phát hiện một cách dễ dàng, bất kể nó bị chôn vùi sâu như thế nào trong mã của bạn. Trong khi một số nhà nghiên cứu đang thực hiện công việc mới lạ, phần lớn trong số này sẽ là các lần quét mã hàng loạt với công sức thấp. Nếu một người đang chạy Claude Code trên cơ sở mã của bạn tìm thấy nó, bạn có thể mong đợi người khác sử dụng ví dụ: Codex sẽ sớm tìm thấy nó.

Điều này có nghĩa là ngay cả khi bạn có thỏa thuận với nhà nghiên cứu không công khai vấn đề trước khi bạn có cơ hội khắc phục, bạn cần coi lỗ hổng đó về cơ bản là "đã bị lộ ra ngoài". Bạn có kế hoạch khác cho cuối tuần này không? Hay một dự án dài hạn bạn đang ưu tiên? Thật tuyệt, giờ bạn có một kế hoạch mới — khắc phục mọi lỗ hổng ngay lập tức.

Các nhà phát triển mã nguồn kín có thể tự tìm và sửa lỗi theo lịch trình của họ, và ít nhất về lý thuyết, họ có thể đi trước các nhà nghiên cứu bên thứ ba. Nếu mã của bạn công khai, bạn sẽ sống trong chế độ phản ứng trong một thời gian.

Tổng kết lại, bạn sẽ trải qua rất nhiều đau đớn ngắn hạn trên con đường OSS mà đơn giản là không tồn tại nếu bạn là mã nguồn kín. Và để thêm dầu vào lửa — chúng ta đều sẽ đạt đến trạng thái tương tự. Bạn có thể lập luận rằng trước đây, việc mã nguồn mở giúp bạn nhận được sự chú ý từ các nhà nghiên cứu bảo mật cấp cao, và để đổi lấy việc họ được ghi nhận và/hoặc tiền thưởng, kết quả cuối cùng là bạn có thể mong đợi OSS an toàn hơn so với việc phát hành dưới dạng mã nguồn kín. Với các tác nhân lập trình là động lực chính, lợi thế này phần lớn biến mất. Dù bạn là người chi tiền token hay người khác, mọi lớp lỗ hổng có thể được quét tự động đều sẽ dễ dàng được tìm thấy.

Vì vậy, thật dễ hiểu khi Cal.com chuyển sang mã nguồn kín vì lý do này, và có khả năng sẽ có thêm các hoạt động thương mại khác tham gia, những người a) có khách hàng họ quan tâm và b) không muốn dành vài tháng tới để truy đuổi mọi vấn đề bảo mật có thể tìm thấy công khai.

Cũng cần nói rõ rằng nếu bạn là một dự án OSS phi thương mại, bạn hiện đang chịu nhiều áp lực hơn từ LLM. Các hoạt động thương mại (nếu họ làm tốt) có người được trả tiền để xử lý các vấn đề bảo mật vào 4 giờ sáng thứ Bảy. Nếu bạn chỉ vận hành một dự án OSS lớn vì lòng tốt hoặc bạn có một sản phẩm hứa hẹn nhưng chưa đạt quy mô thương mại, tôi xin chia sẻ.

Lời khuyên cho các nhà phát triển

Vậy điều này có nghĩa gì cho bạn, độc giả thân mến?

Nếu bạn kiếm sống bằng cách làm phần mềm, dù mã nguồn mở hay kín, bạn sẽ có một mùa hè thú vị — hãy mong đợi từng lớp một các vấn đề bảo mật của bạn bị bóc trần. Hãy thử chạy càng nhiều bản dùng thử của sản phẩm quét càng tốt và chủ động thúc đẩy các tác nhân lập trình của riêng bạn.

Nếu bạn chưa có các bản vá bảo mật thường xuyên, hãy bắt đầu. Làm cho người dùng của bạn quen với việc nâng cấp thường xuyên. Nếu bạn có thể làm cho hệ thống của mình dễ nâng cấp/vá lỗi hơn, bạn sẽ không hối tiếc.

Khắc phục mọi thứ bạn có trong tay. Nếu bạn thông minh, bạn đã kiến trúc hệ thống của mình để có nhiều lớp bảo vệ, nhưng bạn không thể dựa vào bất kỳ lớp cụ thể nào ngay lúc này. Vì vậy, bất kỳ lỗ hổng nào, dù nhỏ đến đâu, cũng nên được khắc phục ngay lập tức để nó không thể được xâu chuỗi thành một cuộc tấn công lớn hơn.

Nếu bạn bán sản phẩm mã nguồn kín, bạn có một mối đe dọa bảo mật mới: rò rỉ mã nguồn. Bạn nên giả định rằng bất kỳ sự xâm phạm nào đối với mã nguồn của bạn sẽ bộc lộ một số lượng lớn các lỗ hổng.

Câu trả lời ngắn gọn: Hãy coi mọi phụ thuộc OSS như thể một lỗ hổng mới sẽ được tiết lộ đối với nó trong quý này, và xây dựng quy trình vá lỗi, giám sát và kiểm soát truy cập xung quanh giả định đó.

1. Bạn nên mong đợi rằng mình sẽ cần nâng cấp thường xuyên hơn nhiều, và dự ngân sách cho việc đó trước.
2. Giám sát và khóa (pin) tất cả các phụ thuộc OSS. Hãy làm quen với việc nâng cấp chúng MỌI LÚC.
3. Thực hiện Bảo vệ nhiều lớp (Defense-in-Depth) và cố gắng hết sức để tạo ra các lớp tách biệt. Chúng sẽ được kiểm tra.
4. Nâng cấp trò chơi ghi nhật ký và khả năng quan sát của bạn, và đảm bảo có ai đó đang theo dõi nhật ký.
5. Thực hiện các nguyên tắc đặc quyền tối thiểu, và đảm bảo bất kỳ thông tin đăng nhập nào được sử dụng bởi bất kỳ phần mềm nào chỉ có các đặc quyền tối thiểu cần thiết.

Thực chất, chỉ cần làm tất cả những việc bạn lẽ ra nên làm từ trước, nhưng ở mức độ quyết liệt hơn nhiều. Tương tự như việc sự gia tăng của việc quét mạng lưới ngẫu nhiên có nghĩa là bất kể quy mô của bạn nhỏ đến đâu, bạn đều có thể mong đợi các lần quét cổng, bạn cũng có thể mong đợi các cuộc tấn công hàng loạt vào bất kỳ OSS nào bạn sử dụng, bất kể bạn hoặc dự án đó nhỏ đến đâu.

Để kết thúc, tất cả những điều này sẽ phát hiện ra các lỗi hiện có trong mã. Sau nỗi đau ngắn hạn ban đầu, cả mã hiện tại và mã sẽ được viết trong tương lai sẽ an toàn hơn.