Xin chào cả nhà!
Hôm nay mình sẽ chia sẻ về một chủ đề rất thú vị: Project Glasswing - dự án hợp tác giữa Cloudflare và Anthropic để thử nghiệm AI trong việc tìm kiếm lỗ hổng bảo mật.
Bài viết này được dựa trên bài blog gốc của Cloudflare: Project Glasswing: what Mythos showed us.
Table of contents
Open Table of contents
Mythos Preview là gì?
Mythos Preview là một mô hình AI (LLM) chuyên về bảo mật được phát triển bởi Anthropic. Cloudflare đã được mời tham gia Project Glasswing để thử nghiệm mô hình này trên hơn 50 repository của chính họ.
Mục tiêu là để xem AI có thể tìm ra những lỗ hổng bảo mật nào, và quan trọng hơn - để hiểu được những gì kẻ tấn công có thể làm với các mô hình AI mới nhất.
Điểm khác biệt của Mythos Preview
So với các mô hình AI đa năng trước đây, Mythos Preview có hai khả năng nổi bật:
1. Xây dựng chuỗi khai thác (Exploit Chain Construction)
Một cuộc tấn công thực sự hiếm khi chỉ sử dụng một lỗi đơn lẻ. Thay vào đó, kẻ tấn công sẽ kết hợp nhiều lỗi nhỏ thành một chuỗi khai thác hoàn chỉnh. Ví dụ:
- Biến một lỗi use-after-free thành khả năng đọc/ghi tùy ý
- Chiếm quyền điều khiển luồng thực thi (control flow)
- Sử dụng chuỗi ROP (Return-Oriented Programming) để kiểm soát hoàn toàn hệ thống
Mythos Preview có thể lý luận và kết hợp các lỗi riêng lẻ thành một proof-of-concept hoàn chỉnh - giống như cách một chuyên gia bảo mật cấp cao làm việc.
2. Tạo bằng chứng (Proof Generation)
Tìm ra lỗi và chứng minh lỗi có thể khai thác được là hai việc hoàn toàn khác nhau. Mythos Preview có thể:
- Viết code để kích hoạt lỗi nghi ngờ
- Biên dịch code trong môi trường sandbox
- Chạy thử và xác nhận kết quả
- Nếu thất bại, tự điều chỉnh giả thuyết và thử lại
Vòng lặp này rất quan trọng vì một lỗi nghi ngờ mà không có bằng chứng chỉ là suy đoán - và Mythos Preview có thể tự động khép lại khoảng trống này.
Vấn đề về Model Refusals
Mặc dù Mythos Preview được cung cấp cho Project Glasswing không có các safeguard bổ sung như các mô hình công khai (Opus 4.7 hay GPT-5.5), nhưng mô hình vẫn có những guardrail tự nhiên.
Điều thú vị là những guardrail này không nhất quán:
- Cùng một tác vụ, được đặt câu hỏi khác đi hoặc trong ngữ cảnh khác, có thể cho kết quả hoàn toàn khác nhau
- Mô hình có thể từ chối nghiên cứu lỗ hổng trên một project, rồi đồng ý làm việc đó sau một thay đổi không liên quan
- Mô hình tìm ra nhiều lỗi memory nghiêm trọng, nhưng lại từ chối viết exploit demo
Điều này cho thấy rằng bất kỳ mô hình AI bảo mật nào được phát hành công khai trong tương lai cần phải có thêm các safeguard bổ sung.
Vấn đề Signal-to-Noise
Một trong những thách thức lớn nhất khi phân loại lỗ hổng bảo mật là quyết định:
- Lỗi nào là thật?
- Lỗi nào có thể khai thác được?
- Lỗi nào cần sửa ngay?
Hai yếu tố chính ảnh hưởng đến tỷ lệ nhiễu:
Ngôn ngữ lập trình
- C và C++: Cho phép kiểm soát bộ nhớ trực tiếp, dẫn đến các lớp lỗi như buffer overflow, out-of-bounds read/write
- Rust: Loại bỏ các lỗi này ngay tại compile time
- Cloudflare thấy nhiều false positive hơn từ các project viết bằng ngôn ngữ không an toàn về bộ nhớ
Model Bias
Khi bạn yêu cầu AI tìm lỗi, nó sẽ tìm ra lỗi - dù code có lỗi hay không. Các phát hiện thường đi kèm với các từ như “có thể”, “tiềm năng”, “về lý thuyết có thể”…
Đây là bias hợp lý cho công cụ khám phá, nhưng tai hại cho hàng đợi phân loại - mỗi phát hiện suy đoán đều tốn thời gian và công sức của con người để loại bỏ.
Mythos Preview cải thiện rõ rệt ở đây: ít phát hiện mơ hồ hơn, các bước tái tạo rõ ràng hơn, và ít công việc hơn để đưa ra quyết định sửa hay bỏ qua.
Tại sao không thể chỉ đơn giản “chỉ AI vào repo”?
Cloudflare ban đầu cũng thử cách đơn giản nhất: chỉ một coding agent vào repository và yêu cầu nó tìm lỗ hổng. Cách này không hiệu quả vì hai lý do:
1. Context (Ngữ cảnh)
Coding agent được tối ưu cho một luồng công việc tập trung: xây dựng tính năng, sửa lỗi, refactor. Chúng giữ một giả thuyết tại một thời điểm và lặp lại.
Nghiên cứu lỗ hổng bảo mật thì ngược lại - hẹp và song song:
- Chọn một thứ cụ thể để xem xét kỹ lưỡng
- Có thể là một tính năng phức tạp, ranh giới bảo mật, hoặc một lớp lỗ hổng cụ thể
- Lặp lại hàng nghìn lần trên toàn bộ codebase
Một phiên agent đơn lẻ trên repository 100,000 dòng code chỉ có thể bao phủ khoảng 0.1% bề mặt một cách hữu ích trước khi context window đầy.
2. Throughput (Thông lượng)
Agent đơn luồng làm một việc tại một thời điểm, nhưng codebase thực cần nhiều giả thuyết chống lại nhiều component cùng lúc.
Harness - Giải pháp của Cloudflare
Sau khi nhận ra những hạn chế trên, Cloudflare đã xây dựng một harness (khung điều khiển) xung quanh Mythos Preview. Bốn bài học chính:
1. Phạm vi hẹp cho kết quả tốt hơn
❌ “Tìm lỗ hổng trong repository này”
✅ “Tìm command injection trong hàm cụ thể này, với trust boundary này, đây là tài liệu kiến trúc và đây là coverage trước đó”
2. Adversarial Review giảm nhiễu
Thêm một agent thứ hai giữa phát hiện ban đầu và hàng đợi - với prompt khác, model khác, và không có khả năng tạo phát hiện riêng - bắt được nhiều nhiễu mà agent đầu tiên bỏ sót.
Hai agent bất đồng có chủ đích hiệu quả hơn nhiều so với một agent được yêu cầu “cẩn thận”.
3. Chia chuỗi qua nhiều agent
Hai câu hỏi:
- “Code này có lỗi không?”
- “Kẻ tấn công có thể tiếp cận lỗi này từ bên ngoài hệ thống không?”
Mô hình làm tốt hơn khi bạn hỏi riêng từng câu, vì mỗi câu hỏi hẹp hơn phiên bản kết hợp.
4. Nhiều task song song hẹp tốt hơn một agent toàn diện
Coverage cải thiện khi nhiều agent làm việc trên các câu hỏi có phạm vi chặt chẽ và deduplicate kết quả sau đó.
Ý nghĩa với các đội bảo mật
Phản ứng phổ biến nhất với Mythos Preview là về tốc độ - scan nhanh hơn, patch nhanh hơn. Nhiều đội đang hoạt động với SLA 2 giờ từ khi CVE được công bố đến khi patch lên production.
Nhưng Cloudflare cảnh báo: Nhanh hơn sẽ không đủ.
Vấn đề với việc patch nhanh
- Nếu regression testing mất một ngày, bạn không thể đạt SLA 2 giờ mà không bỏ qua nó
- Các lỗi bạn ship khi bỏ qua regression testing thường tệ hơn lỗi bạn đang cố patch
- Cloudflare đã thử để model tự viết patch và thấy một số patch sửa lỗi gốc nhưng âm thầm phá vỡ thứ khác
Kiến trúc phòng thủ
Câu hỏi khó hơn là kiến trúc xung quanh lỗ hổng nên như thế nào:
- Phòng thủ trước ứng dụng: Chặn lỗi không thể bị tiếp cận ngay cả khi nó tồn tại
- Thiết kế phân tách: Lỗi ở một phần code không cho phép kẻ tấn công truy cập các phần khác
- Triển khai đồng thời: Có thể roll out fix đến mọi nơi code đang chạy cùng một lúc
Kết luận
Project Glasswing cho thấy AI đang trở thành một công cụ mạnh mẽ trong nghiên cứu bảo mật. Mythos Preview đại diện cho một bước tiến thực sự - không chỉ tìm lỗi mà còn có thể chứng minh chúng có thể khai thác được.
Tuy nhiên, điều quan trọng cần nhớ:
- Cùng khả năng này cũng có thể bị lạm dụng - những gì giúp Cloudflare tìm lỗi trong code của họ cũng sẽ giúp kẻ tấn công tìm lỗi trong mọi ứng dụng trên Internet
- AI không thể thay thế hoàn toàn con người - cần có harness, quy trình, và kiến trúc phù hợp
- Tốc độ không phải là tất cả - kiến trúc phòng thủ tốt quan trọng hơn việc patch nhanh
Cloudflare đang ở vị trí đặc biệt - đứng trước hàng triệu ứng dụng - và các nguyên tắc kiến trúc họ mô tả chính là những gì các sản phẩm của họ được xây dựng để áp dụng cho khách hàng.
Hy vọng bài viết này giúp mọi người hiểu thêm về cách AI đang thay đổi lĩnh vực bảo mật. Nếu có câu hỏi gì, hãy để lại comment nhé!