Biên giới mới của an ninh mạng AI: thực tế sau Mythos

• Sau khi Claude Mythos của Anthropic tự động phát hiện các lỗ hổng zero-day trên quy mô lớn, các mô hình mở cỡ nhỏ cũng đã phát hiện thành công các lỗ hổng tương tự
• Các mô hình cỡ 3.6B~5.1B tham số tái hiện lỗi của FreeBSD và OpenBSD, trong đó một số còn đưa ra các hướng exploit sáng tạo khác với Mythos
• Kết quả thí nghiệm cho thấy kích thước mô hình và hiệu năng có quan hệ phi tuyến, và trong một số bài toán, mô hình nhỏ chính xác hơn mô hình lớn
• Năng lực bảo mật AI không mở rộng một cách trơn tru mà có tính ‘gập ghềnh’, và lợi thế cạnh tranh thực sự nằm ở thiết kế hệ thống và pipeline kiểm chứng, chứ không phải mô hình
• Vì vậy, hào lũy của bảo mật nằm ở hệ thống chứ không phải mô hình, và kiến trúc điều phối tích hợp tri thức chuyên gia mới là cốt lõi của bảo mật AI

---

Hào lũy là hệ thống, không phải mô hình

• Ngày 7/4/2026, Anthropic công bố Claude Mythos Preview và Project Glasswing, thành lập một consortium sử dụng mô hình Mythos để tự động phát hiện và vá lỗ hổng bảo mật trong các phần mềm quan trọng
  • Cam kết 100 triệu USD tín dụng sử dụng và 4 triệu USD quyên góp cho các tổ chức bảo mật nguồn mở
  • Mythos đã phát hiện hàng nghìn lỗ hổng zero-day, đồng thời tự động phát hiện và tạo exploit cho lỗi OpenBSD tồn tại 27 năm, lỗi FFmpeg tồn tại 16 năm, lỗ hổng thực thi mã từ xa trên FreeBSD cùng nhiều trường hợp khác
• AISLE tái hiện các lỗ hổng tương tự bằng mô hình nhỏ, chi phí thấp, trọng số mở
  • 8 trên 8 mô hình phát hiện được exploit của FreeBSD
  • Mô hình 3.6B tham số (0,11 USD mỗi token) cũng phát hiện thành công
  • Mô hình 5.1B khôi phục được chuỗi cốt lõi của lỗi OpenBSD
  • Ở một số bài toán, mô hình mở cỡ nhỏ vượt trội hơn mô hình lớn
• Kết quả cho thấy năng lực bảo mật AI có tính phi tuyến và gập ghềnh (jagged)
  • Không có mô hình nào vượt trội ở mọi bài toán
  • Cốt lõi của năng lực cạnh tranh bảo mật không nằm ở mô hình mà ở hệ thống, với trọng tâm là kiến trúc điều phối tích hợp tri thức chuyên gia

Vị thế hiện tại của bảo mật AI

• Từ giữa năm 2025, AISLE đã áp dụng hệ thống phát hiện và vá lỗ hổng dựa trên AI vào các mục tiêu thực tế
  • Phát hiện 15 CVE trong OpenSSL, 5 CVE trong curl, và tổng cộng hơn 180 CVE đã được xác minh từ bên ngoài
  • CTO của OpenSSL đánh giá rằng “chất lượng báo cáo và quá trình hợp tác rất tốt”
• Dù đã sử dụng nhiều mô hình khác nhau, mô hình của Anthropic không phải lúc nào cũng tốt nhất
  • Do mô hình tối ưu thay đổi theo từng bài toán, AISLE áp dụng cách tiếp cận bất khả tri với mô hình

Phân rã pipeline bảo mật AI

• Bảo mật AI trong thực tế không được cấu thành từ một mô hình đơn lẻ mà là pipeline nhiều giai đoạn
  • Quét diện rộng, phát hiện lỗ hổng, kiểm chứng và phân loại, tạo bản vá, xây dựng exploit... mỗi giai đoạn có đặc tính mở rộng khác nhau
• Anthropic tối đa hóa đầu vào thứ nhất (trí tuệ mô hình), trong khi AISLE coi trọng ngang nhau nhiều yếu tố như chi phí trên mỗi token, tốc độ và chuyên môn bảo mật

Kết luận: hào lũy là hệ thống

• Cấu trúc như thực thi trong container, quét file, kiểm chứng bằng ASan, đánh giá mức độ ưu tiên được nhắc tới trong bài viết kỹ thuật về Mythos khá tương đồng với hệ thống của AISLE
• Giá trị cốt lõi không nằm ở mô hình mà ở quy trình nhắm mục tiêu, kiểm chứng và xây dựng niềm tin
• Cách triển khai song song số lượng lớn mô hình nhỏ để quét rộng toàn bộ mã nguồn giúp đạt đồng thời hiệu quả kinh tế và hiệu suất phát hiện
• Mythos đã chứng minh tính khả thi của danh mục này, nhưng mở rộng quy mô vận hành và bảo đảm độ tin cậy vẫn là bài toán còn lại

Kết quả thí nghiệm: năng lực bảo mật gập ghềnh

• Thực hiện thí nghiệm với mô hình nhỏ, chi phí thấp trên các lỗ hổng tiêu biểu được công bố cùng Mythos

  • Lỗi FreeBSD NFS, lỗi OpenBSD SACK, kiểm thử false positive của OWASP

    • Kết quả cho thấy kích thước mô hình, thế hệ, giá thành và hiệu năng có quan hệ phi tuyến
    • Phát hiện FreeBSD thành công với mọi mô hình, OpenBSD chỉ một phần thành công, còn với OWASP thì mô hình nhỏ chính xác hơn mô hình lớn
    • Phát hiện FreeBSD: cả 8 mô hình đều phát hiện buffer overflow
    • Mô hình 3.6B cũng tính toán chính xác và đánh giá khả năng RCE
    • DeepSeek R1 thực hiện phép tính khớp với cấu trúc stack thực tế
    • Ở phần logic exploit, mọi mô hình đều đề xuất chiến lược chuỗi ROP
    • Một số mô hình còn đưa ra lời giải sáng tạo khác với Mythos (ví dụ: leo thang đặc quyền root ở user mode thay vì kernel mode)
    • Lỗi OpenBSD SACK: mô hình 5.1B khôi phục toàn bộ chuỗi và đề xuất bản vá chính xác
    • Qwen3 32B hoàn hảo ở FreeBSD nhưng tại đây lại phán đoán sai rằng “an toàn”
    • Thứ hạng hiệu năng giữa các mô hình bị đảo lộn hoàn toàn theo từng bài toán

• Kiểm thử false positive của OWASP: trong mã Java đơn giản, mô hình nhỏ chính xác hơn mô hình lớn

  • GPT-OSS-20b, DeepSeek R1, OpenAI o3 đánh giá chính xác là “hiện tại an toàn nhưng có khả năng trở nên dễ tổn thương”
  • Nhiều mô hình thuộc dòng Anthropic và GPT-4.x lại phát hiện sai lỗ hổng SQL injection

Kiểm thử nhận biết bản vá (cập nhật ngày 9/4/2026)

• So sánh khả năng phát hiện lỗi và nhận biết phần đã được sửa trên mã phiên bản đã vá của FreeBSD
  • Tất cả mô hình đều phát hiện được lỗi ở bản chưa vá, nhưng xuất hiện nhiều false positive trên mã sau khi vá
  • Chỉ GPT-OSS-120b chính xác ở cả hai chiều
  • Phần lớn mô hình đưa ra nhận định sai về lỗ hổng do lỗi diễn giải dấu của oa_length
• Điều này cho thấy độ nhạy (khả năng phát hiện) cao nhưng độ đặc hiệu (độ chính xác) thấp,
  nhấn mạnh rằng hệ thống kiểm chứng và triage bên ngoài mô hình là thiết yếu

Ranh giới của việc xây dựng exploit

• Các trường hợp như thoát sandbox trình duyệt nhiều bước, chuỗi ROP trong kernel của Mythos là những ví dụ cực kỳ tinh vi
• Mô hình mở có thể giải thích một cách logic về khả năng exploit, kỹ thuật và chiến lược bypass, nhưng
  vẫn còn hạn chế ở cơ chế truyền tải sáng tạo trong môi trường ràng buộc
• Tuy vậy, trong workflow phòng thủ, độ tin cậy của phát hiện và vá lỗi quan trọng hơn việc có exploit hoàn chỉnh

Góc nhìn vĩ mô

• Công bố về Mythos đã chứng minh tính thực tế và tầm quan trọng công nghiệp của bảo mật AI
  • Nguồn vốn và sự quan tâm dành cho bảo mật nguồn mở đang gia tăng
• Tuy nhiên, khẳng định rằng “năng lực này chỉ tồn tại ở một mô hình đóng cụ thể” là cường điệu
  • Trên thực tế, giai đoạn phát hiện và phân tích đã có thể được tiếp cận khá rộng rãi
  • Chuyên môn bảo mật, thiết kế hệ thống và xây dựng niềm tin mới là nút thắt thực sự

• Điều cần lúc này không phải là mô hình mà là xây dựng hệ thống

  • Scaffold, pipeline, cơ chế cộng tác, tích hợp vào workflow phát triển
  • Các mô hình về cơ bản đã sẵn sàng

Giới hạn và điểm cần lưu ý

• Phạm vi kiểm thử còn hạn chế: cung cấp trực tiếp cho mô hình hàm dễ tổn thương và gợi ý, chưa phải khám phá hoàn toàn tự động
• Không có quyền truy cập công cụ: không sử dụng thực thi mã, loop hay môi trường sandbox
• Phản ánh cập nhật mô hình: một số mô hình Anthropic mới hơn đã được cải thiện sau đó
• Làm rõ phạm vi lập luận: không phủ nhận năng lực của Mythos,
  mà chỉ ra rằng tính độc quyền của năng lực phát hiện đã bị phóng đại

Tóm tắt phụ lục

• Trích dẫn phát hiện trên FreeBSD

  • Kimi K2: “oa_length được sao chép mà không kiểm chứng nên có thể gây tràn bộ đệm”
  • Gemma 4: “có thể vượt quá buffer stack 128 byte”

• Bảng so sánh hiệu năng theo bài toán

  • Mọi mô hình đều thành công ở phát hiện FreeBSD, OpenBSD chỉ một phần thành công, còn OWASP thì mô hình nhỏ chiếm ưu thế

• Kiểm thử mã đã vá

  • Phần lớn mô hình tạo false positive do lỗi dấu của oa_length
  • Chỉ GPT-OSS-120b hoàn toàn chính xác
  • Kết luận:
  • Năng lực cạnh tranh cốt lõi của bảo mật AI không nằm ở kích thước hay tính độc quyền của mô hình,
  • mà ở thiết kế hệ thống tích hợp tri thức chuyên gia và cấu trúc vận hành đáng tin cậy.
  • Các mô hình nhỏ cũng đủ mạnh, và việc xây dựng hệ thống phòng thủ tự động hóa quy mô lớn bằng chúng đã ở mức hoàn toàn khả thi.

[GN⁺]

Ý kiến trên Hacker News

• Theo bài viết Mythos Preview của Anthropic, họ nói đã phát hiện lỗ hổng nghiêm trọng nhất trên OpenBSD
  Tổng chi phí cho một nghìn lần chạy là dưới 20.000 USD, và có một lần chạy tìm ra lỗi với chi phí dưới 50 USD
  Nhưng đây là con số chỉ có ý nghĩa khi nhìn lại sau đó; điểm được nhấn mạnh là trên thực tế không thể biết lần chạy nào sẽ thành công
  Họ ví Mythos như đã lục tung cả một lục địa như đào mỏ vàng, và dự đoán nếu làm thí nghiệm tương tự với toàn bộ codebase FreeBSD thì nhiễu sẽ quá nhiều

  • Phần scaffolding của Mythos về cơ bản là một vòng lặp bash duyệt qua mọi tệp và yêu cầu mô hình tìm lỗ hổng
    Tôi tò mò không biết Anthropic có công bố tỷ lệ false positive hay không
    Tôi thấy trên Xitter có người nói đã thử với các mô hình công khai khác và chỉ tái hiện được một phần những gì Mythos tìm ra
    Tôi cho rằng Mythos cho thấy một cải thiện dần dần nhưng đáng kể so với các mô hình trước đó, đồng thời độ phức tạp cũng tăng lên
    Kiểu tiếp thị “quá mạnh để công bố” thực ra có vẻ chỉ là cách tô vẽ cho thực tế rằng “chạy toàn bộ codebase thì tốn 20.000 USD”
    Trong bài trình bày của Nicholas Carlini cũng dùng Opus, và bảo mật vốn là lĩnh vực Anthropic đã tập trung từ rất lâu
  • Mythos cũng tạo ra rất nhiều lỗ hổng bịa đặt, nhưng một số đã thực sự được xác minh qua kiểm thử
    Điểm mấu chốt là liệu các mô hình nhỏ hơn có thể thực hiện được bước xác minh này hay không, và liệu có thể làm rẻ hơn không
  • Ngược lại, có người cho rằng nghiên cứu khác đã tiếp cận quá cực đoan
    Họ tách riêng các hàm dễ tổn thương rồi đưa cho mô hình để đánh giá, điều này chẳng khác nào “chỉ thẳng căn phòng có giấu vàng”
    Trên thực tế, phần khó hơn là tìm ra căn phòng đó trong cả một lục địa
  • Bỏ ra 20.000 USD để tìm một lỗ hổng DoS trên OpenBSD nghe có vẻ kém hiệu quả
    Không khí xung quanh Mythos có vẻ như đang coi nó như một chiếc cúp, nhưng tôi nghĩ thà quyên góp cho quỹ OpenBSD còn hơn
  • Nếu các mô hình nhỏ cũng có thể tìm ra cùng lỗ hổng đó, thì thật khó hiểu vì sao chính công ty đó trước đây lại chưa tìm ra được

• Có một nghiên cứu nói rằng các mô hình mở nhỏ đã phát hiện đủ 8 trên 8 lỗ hổng FreeBSD mà Mythos tìm thấy
  Nhưng vì họ tách riêng phần mã liên quan để kiểm thử nên tôi nghĩ điều đó khác với tình huống sử dụng thực tế
  Giá trị thực sự nằm ở khả năng ném cả codebase vào và quét nó

  • Nhóm nghiên cứu cũng tự thừa nhận giới hạn này
    Vì họ đưa trực tiếp hàm dễ tổn thương và gợi ý cho mô hình, đây chỉ là giới hạn trên của việc khám phá hoàn toàn tự động
    Tuy nhiên, một scaffold được thiết kế tốt có thể tự động tạo ra ngữ cảnh đó, nên then chốt là hệ thống (moat) chứ không phải bản thân mô hình
  • Theo bài viết kỹ thuật của Anthropic, cấu trúc là khởi chạy container, để mô hình quét tệp, lập giả thuyết và xác minh bằng ASan
    Nói cách khác, framework (harness) mới là thứ làm phần lớn công việc, còn mô hình thì có thể thay thế được
  • Ngay cả với mô hình nhỏ cũng có thể tạo harness tự động lặp đi lặp lại việc ném prompt theo từng tệp hoặc từng hàm
    Sau đó chỉ cần dùng mô hình lớn để xác minh lại những phần liên tục bị gắn cờ là lỗ hổng
    Cuối cùng, điều quan trọng không phải là mô hình mà là harness
  • Rốt cuộc khác biệt chỉ nằm ở harness. Tôi cũng có thể tạo một harness chia mã theo từng hàm rồi đưa vào agent phân tích

• Giống ví dụ Heartbleed, nếu chỉ cho xem phần mã dễ tổn thương thì ai cũng có thể tìm ra lỗi
  Nhưng việc phát hiện ra phần đó trong một codebase lớn mới là điều thực sự khó
  Tôi khá bất ngờ khi Aisle lại viết bài như vậy

  • Dù là bài mang tính quảng bá, tôi nghĩ nó lên đầu HN vì đánh trúng tâm lý “mô hình mới hóa ra cũng chẳng ghê gớm” của mọi người
  • Khi làm dự án lớn, nhiều lúc nghỉ một thời gian rồi quay lại sẽ thấy chính đoạn mã mình viết trông rất tệ
    Khó duy trì ngữ cảnh là một trong những nguyên nhân gốc rễ của lỗi
  • Con người yếu ở những công việc lặp đi lặp lại và quá tỉ mỉ
    Trong khi đó máy móc có thể rà soát mã liên tục mà không biết chán
    Câu “đủ nhiều cặp mắt thì mọi lỗi đều nông” không giống thực tế
  • Vậy thì chỉ cần tự động hóa quá trình “nhìn kỹ” đó
    Có thể tạo một công cụ đi qua codebase và lặp lại prompt với LLM kiểu “nếu mã này có lỗ hổng thì hãy tìm ra”
    Nói cách khác, công cụ (harness) là chìa khóa khiến LLM trở nên thông minh hơn
  • Điều này giống như nhầm lẫn giữa giải bài toán và xác minh
    Kiểu ví von “nếu ai đó đã chỉ cho bạn cách phân tích thừa số thì phá PKI là chuyện dễ”

• Tôi cho rằng phương pháp của bài này là một phép so sánh sai hoàn toàn
  Việc trực tiếp cung cấp hàm dễ tổn thương và gợi ý là một nhiệm vụ hoàn toàn khác
  Trên thực tế, ngay cả khi chia các đoạn mã ra rồi ném cho mô hình nhỏ, tôi cũng không nghĩ có thể đạt kết quả ở mức mô hình lớn
  Tôi đã tìm được nhiều lỗi Redis bằng một pipeline shell script đơn giản
  Với mô hình yếu thì không làm được. Tự thử nghiệm sẽ thấy rõ sự khác biệt
  Ngoài ra, dù mô hình nhỏ tìm được 80% thì vẫn cần mô hình mạnh hơn để tìm 20% còn lại

  • Anthropic cũng nói rằng họ chỉ công bố dưới 1% số lỗ hổng đã phát hiện
    Sẽ rất hay nếu cho các mô hình mở một môi trường Linux phiên bản cũ rồi thử xem chúng tìm được bao nhiêu
  • Nhưng người khác lại cho rằng cách tiếp cận này là hợp lý
    Các mô hình nhỏ lọc false positive khá tốt, và nếu dùng harness phù hợp thì có thể cho kết quả gần giống mô hình lớn
    Mô hình nhỏ nhanh và rẻ, nên nếu người dùng có kinh nghiệm vận dụng thì sẽ hiệu quả hơn nhiều
    Tôi nghĩ trong tương lai kiểu kết hợp mô hình nhẹ + harness này sẽ trở thành xu hướng chủ đạo
  • Cũng có người phản ứng mỉa mai kiểu “Thanks Dario, very cool!”

• Nhiều bình luận nói rằng “vì đã tách mã ra nên kết quả vô hiệu”, nhưng Anthropic cũng chạy mô hình theo cách tương tự ở cấp độ từng tệp
  Harness của Mythos gán điểm mức độ quan trọng cho từng tệp, rồi tạo các instance Claude Code để tập trung vào các tệp đó
  Vì vậy, việc tách mã tự thân nó không làm kết quả mất giá trị

• Cùng kỹ thuật đó cũng được giới thiệu trong video trình bày của Nicholas Carlini
  Để LLM tập trung review thật kỹ từng tệp một sẽ cho hiệu quả cao
  “Đổi mới” của Mythos thực ra chỉ là việc tự động hóa prompt theo từng tệp khá đơn giản này
  Có khả năng chính cách làm này đã đẩy chi phí lên tới 20.000 USD
  Tôi cũng đã thử cùng phương pháp với Opus 4.6 và GPT 5.4, và chúng rà soát kỹ hơn rất nhiều
  Nghĩa là nếu để một phiên chỉ tập trung vào một tệp, mô hình sẽ phân tích sâu hơn nhiều

  • Nhưng làm vậy có thể bỏ sót các lỗ hổng phát sinh từ tương tác giữa các tệp

• Cách nói “mô hình nhỏ đã khôi phục lại cùng phân tích đó” khó tin vì không được định lượng
  Việc xác minh lỗ hổng có thể đo rất rõ bằng PoC, nên cần có bằng chứng kiểu đó
  Ngoài ra, việc “cung cấp sẵn chỉ phần mã liên quan” không phải là một so sánh công bằng

• Nếu không công bố tỷ lệ false positive thì mọi phân tích đều vô nghĩa
  Chỉ cần nói mọi dòng đều có lỗi thì tỷ lệ phát hiện sẽ là 100%, nhưng chẳng có ích gì
  Cả Anthropic lẫn OpenAI đều không công bố các con số như vậy nên khó mà tin tưởng

  • Tuy nhiên cũng có ý kiến phản biện rằng nếu có oracle có thể xác minh được thì false positive có thể bỏ qua
  • Trên thực tế, mô hình nhỏ đã trả lời đúng trong bài kiểm tra false positive, còn Opus thì sai
    Dù vậy, chúng vẫn chưa đạt tới mức xác minh khai thác như Mythos
    Kết quả của Deepseek R1 khá thuyết phục, nhưng không rõ có thật sự chạy được hay không
  • Ít nhất thì phải đạt được cùng mức độ bao phủ mà Anthropic đã có thì mới có ý nghĩa

• Điểm cốt lõi là việc tách riêng phần mã liên quan
  Các zero-day phức tạp thường xuất hiện từ tương tác giữa nhiều tệp, nên cách tiếp cận này có giới hạn

  • Nhưng cũng có người cho rằng rốt cuộc Mythos cũng phân tích theo từng tệp theo đúng kiểu đó
  • Không rõ Mythos có thực sự tìm được các lỗ hổng liên tệp hay không

• Mythos đánh giá toàn bộ codebase, còn nghiên cứu lần này thì tách riêng mã dễ tổn thương để kiểm thử
  Sự khác biệt này giống như giữa “một con chó tìm được quả bóng trong rừng” và “một con chó chỉ được cho biết đúng khu vực có bóng”

  • Thậm chí còn bị ví như đã xịt mùi lên quả bóng, cho chó ngửi mùi đó trước rồi chỉ thả nó vào một khu vực hẹp
  • Vì Mythos không thể nạp toàn bộ mã cùng một lúc, rất có thể nó đã chia việc cho nhiều sub-agent xử lý
    Rốt cuộc điều quan trọng không phải là mô hình mà là harness (hệ thống công cụ)