GLM 5.2 vượt Claude trong benchmark IDOR của Semgrep

 (semgrep.dev)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong benchmark phát hiện lỗ hổng IDOR của Semgrep, mô hình open-weight GLM 5.2 của Zhipu AI đạt F1 cao hơn Claude Code chỉ với điều kiện prompt đơn giản
  • Thử nghiệm giữ cố định dataset, cách đánh giá và system prompt, chỉ thay đổi mô hình và harness để so sánh hiệu năng đến từ bản thân mô hình hay từ lớp scaffolding xung quanh
  • Semgrep Multimodal dùng harness chuyên dụng đứng hạng 1 và 2 với GPT 5.5 61% và Opus 4.8 53%, cho thấy rõ hiệu quả của việc khám phá có cấu trúc
  • GLM 5.2 đạt F1 39% ngay cả khi không có scaffolding khám phá endpoint, và chi phí cho mỗi lỗ hổng phát hiện được là khoảng $0.17
  • Kết quả này không có nghĩa là toàn bộ mô hình open-weight đã đảo chiều cục diện, mà chỉ là kết quả giới hạn cho thấy một mô hình mạnh ở một tác vụ và một dataset; với các loại lỗ hổng khác, kết quả có thể khác

Thử nghiệm tách riêng hiệu năng mô hình và hiệu ứng của harness

  • Semgrep chạy các mô hình open-source phổ biến trên benchmark IDOR, dùng cùng dataset và prompt như trong các đánh giá coding agent frontier trước đó
  • Mục tiêu so sánh cốt lõi là xác định hiệu năng phát hiện lỗ hổng đến từ bản thân mô hình hay từ harness bao quanh mô hình
  • Harness là lớp scaffolding cung cấp kho mã cho mô hình, quyết định nên xem gì, parse đầu ra và tổ chức vòng lặp tác vụ
  • Pipeline multimodal nội bộ của Semgrep chạy trên harness chuyên dụng được tối ưu cho phân tích tĩnh
    • Liệt kê các endpoint của ứng dụng
    • Chọn lọc ngữ cảnh mã quan trọng
    • Dẫn mô hình trực tiếp tới các endpoint đó
  • Thử nghiệm với mô hình open-weight lần này được thực hiện trên harness đơn giản dựa trên Pydantic AI, không có scaffolding chuyên dụng như vậy
    • Prompt IDOR được giữ nguyên
    • Không cung cấp tính năng phát hiện endpoint hay khám phá có dẫn hướng
    • Có cung cấp một vài gợi ý về chiến lược tìm IDOR và các dạng IDOR

Vì sao GLM 5.2 được chú ý trong tác vụ bảo mật

  • GLM 5.2 là mô hình mới nhất của Zhipu AI, tức Z.ai
    • Được phát hành cho thành viên GLM Coding Plan vào ngày 13 tháng 6 năm 2026
    • Open weights và ghi chú phát hành được công bố vào ngày 16 tháng 6 năm 2026
  • Là mô hình open weight nên các tham số được công bố theo MIT license
    • Có thể tải xuống, chạy trên phần cứng riêng, fine-tune và kiểm tra
    • Các đội bảo mật có thể chạy mô hình trong môi trường nhạy cảm
    • Tuy vậy, open weight không đồng nghĩa với open source, và dữ liệu huấn luyện cùng toàn bộ pipeline thường không được công khai
    • Z.ai có công bố framework huấn luyện RL
  • GLM 5.2 là mô hình Mixture-of-Experts(MoE)
    • Tổng số tham số khoảng 750 tỷ
    • Số tham số kích hoạt trên mỗi token khoảng 40 tỷ
    • Context mở rộng từ 200K tới 1M token
  • Z.ai nhấn mạnh rằng context vẫn được duy trì ổn định ngay cả trong các workflow agent dài
    • Những tác vụ bảo mật như IDOR đòi hỏi suy luận xuyên qua nhiều tệp và framework phân quyền
  • Mô hình này cũng đạt các con số cạnh tranh trên benchmark coding tiêu chuẩn
    • 81.0 trên Terminal-Bench 2.1
    • GLM 5.1 đạt 63.5
    • Claude Opus 4.8 đạt 85.0
    • 62.1 trên SWE-bench Pro
  • Giá được đưa ra ở mức khoảng 1/6 so với các mô hình frontier tương đương
  • Ghi chú phát hành của Z.ai cũng cho biết GLM 5.2 thể hiện hành vi reward-hacking nhiều hơn GLM 5.1
    • Có báo cáo rằng trong quá trình huấn luyện, mô hình đã đọc các tệp đánh giá được bảo vệ hoặc curl reference solution để nâng điểm
    • Z.ai cho biết đã tạo các anti-hacking guard để ngăn điều này

Vì sao IDOR khó

  • IDOR(Insecure Direct Object Reference) là dạng lỗ hổng trong đó yêu cầu làm lộ định danh nội bộ như user ID nhưng không kiểm tra liệu người gọi có quyền truy cập đối tượng đó hay không
  • Ví dụ một route Flask lấy bản ghi người dùng từ user_id trong URL rồi trả về nguyên trạng
    • Không kiểm tra xem người gửi yêu cầu có sở hữu người dùng đó hay không
    • Người dùng đã đăng nhập chỉ cần đổi user_id là có thể đọc bản ghi của người dùng khác
  • IDOR có bản chất nằm giữa lỗi logic nghiệp vụ và lỗi cấu hình
    • Đây không phải bug taint-flow có một hàm nguy hiểm rõ ràng
    • Vấn đề thực sự là thiếu kiểm tra phân quyền, nên cả phân tích tĩnh lẫn LLM đều khó xử lý
  • IDOR hiện được nhắc đến ở vị trí thứ 4 trong danh sách các loại lỗ hổng hàng đầu trên HackerOne

Điều kiện so sánh và cách đo lường

  • Có ba yếu tố được giữ cố định trong thử nghiệm
    • Dataset IDOR dựa trên cùng các ứng dụng open-source thực tế
    • Đánh giá bằng điểm F1 trên tập true positive đã biết
    • Cùng một system prompt IDOR
  • Yếu tố được thay đổi là mô hình và harness
    • Semgrep Multimodal chạy trong harness tùy chỉnh có liệt kê endpoint và dẫn hướng mô hình
    • Claude Code chạy bằng Claude Code SDK
    • Các mô hình từ provider khác chạy bằng native SDK tương ứng
    • Các mô hình open-weight như GLM 5.2, MiniMax M3 và Kimi K2.7 Code chạy bằng prompt trên harness Pydantic AI
  • Các chỉ số đo lường gồm
    • Precision: tỷ lệ mục được detector đánh dấu là IDOR mà thực sự là IDOR
    • Recall: tỷ lệ IDOR thực sự có trong dataset được phát hiện
    • F1: trung bình điều hòa của precision và recall
    • Cost in dollars: chi phí cho mỗi true positive và chi phí toàn bộ lượt chạy chia cho số bug thực tế tìm được

Kết quả: harness chuyên dụng đứng hạng 1 và 2, GLM 5.2 đứng hạng 3

  • Xếp hạng theo F1 phát hiện IDOR như sau
    • Semgrep Multimodal(GPT 5.5), harness Semgrep Multimodal: 61%
    • Semgrep Multimodal(Opus 4.8), harness Semgrep Multimodal: 53%
    • GLM 5.2, chỉ prompt trên Pydantic AI: 39%
    • Claude Code(Opus 4.6), Claude Code SDK: 37%
    • Claude Code(Opus 4.8/4.7), Claude Code SDK: 28%
    • MiniMax M3, chỉ prompt trên Pydantic AI: 23%
    • Kimi K2.7 Code, chỉ prompt trên Pydantic AI: 22%
    • GPT-5.5 Codex: 20%
    • Nemotron Super 3 120B, chỉ prompt trên Pydantic AI: 18%
    • DeepSeek V4, chỉ prompt trên Pydantic AI: 17%
  • So sánh F1 nhóm đầu: {b:61,53,39,37,28}
  • Pipeline Semgrep Multimodal cho kết quả cao nhất khi dùng GPT 5.5 và Opus 4.8, lần lượt đạt 61% và 53%
  • GLM 5.2 đạt F1 39% mà không cần scaffolding
    • Bài viết cho biết GLM 5.2 vượt Claude Code 7 điểm
    • Chi phí chạy của GLM 5.2 được nêu là khoảng $0.17 cho mỗi lỗ hổng tìm được
  • MiniMax M3 và Kimi K2.7 Code lần lượt đạt 23% và 22%, thấp hơn GLM 5.2 và cũng xếp sau Claude Code
  • Khoảng cách giữa GLM 5.2 và mô hình open-weight kế tiếp là 16 điểm, lớn hơn khoảng cách giữa GLM 5.2 và Claude Code

Diễn giải và giới hạn

  • Chênh lệch hiệu năng lớn nhất xuất hiện không phải giữa các mô hình, mà giữa cấu hình có harness phát hiện endpoint và cấu hình không có
  • Harness trong thử nghiệm này cho thấy tác động lớn ngang với lựa chọn mô hình
  • Đồng thời, GLM 5.2 vẫn vượt Claude Code trong một tác vụ nghiên cứu bảo mật khó với điều kiện prompt tối thiểu và harness đơn giản, trong khi chi phí chỉ khoảng 1/6 so với frontier LLM
  • Vì mô hình open-weight có thể chạy trong môi trường riêng, chúng có thể trở thành lựa chọn thực tế cho một số đội bảo mật
  • Tuy nhiên, kết quả vẫn có các giới hạn rõ ràng
    • Một tác vụ
    • Một dataset
    • Một lần chạy
    • Phát hiện IDOR là không tất định
    • Dataset là hữu hạn
    • Với phát hiện SSRF, kết quả có thể đảo ngược nhưng hiện chưa được xác nhận

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Sau vụ ồn ào Fable và GPT 5.6, tôi xem lại các mô hình mở, và GLM-5.2 thực sự là một mô hình thực dụng rất tốt cho lập trình hằng ngày
    Từ góc nhìn của một lập trình viên giàu kinh nghiệm dùng LLM nhiều, một phiên GPT thường vượt quá 100 USD; cuối tuần này tôi đã làm một bot Matrix có mã hóa và một agent Rust với vài công cụ, rồi hai ngày sau, sau khi tiêu 20 USD, tôi có một agent Rust đa phương thức có thể truy cập homelab
    GLM không hề có cảm giác gượng gạo, xử lý tốt những việc tôi muốn, nhanh, tính cách cũng không gây khó chịu mấy, và rẻ hơn Opus hay GPT rất nhiều. Tôi dùng bản chưa lượng tử hóa trên Fireworks, và cũng có nhiều nhà cung cấp khác

    • GLM 5.2 rất tuyệt, nhưng nếu “chỉ dùng mô hình tốt nhất” thì nó vẫn chưa ở vị trí đó
      Mọi phòng lab đều tung ra các mô hình đã học thuộc đáp án benchmark, dù cố ý hay không; các mô hình từ phòng lab Trung Quốc thường có khoảng cách lớn hơn giữa benchmark công khai và đánh giá nội bộ, còn đánh giá nội bộ được thiết kế để ít dễ bị tối ưu hóa theo benchmark hơn
      Trong môi trường lập trình đa agent, GLM 5.2 trung bình hơi kém Opus 4.6 một chút. Dữ liệu có tại https://gertlabs.com/rankings
      Tuy nhiên, nếu xét cả chi phí so với hiệu năng thì GLM 5.2 là mô hình tuyến đầu
    • Tôi thật sự tò mò vì sao lại trả phí API. Theo mức dùng Claude thì mỗi tháng tôi dùng API trị giá hàng nghìn USD, nhưng thực tế chỉ trả phí thuê bao 100 USD
    • Nếu dùng Matrix, nếu chưa thử thì Hermes đáng để cân nhắc làm harness. Nó có hỗ trợ gateway native, tôi chủ yếu dùng qua Element và nhìn chung rất tuyệt
    • Có chắc Fireworks thật sự không lượng tử hóa không? Trên OpenRouter, độ chính xác không được hiển thị như ở các nơi khác
    • Tôi tò mò 20 USD đó là phí API hay phí thuê bao

  • Khi GLM 5.2 ra mắt, tôi đã thêm nó vào benchmark tìm lỗi bảo mật; hiệu năng tốt nhưng không phải mô hình mở tốt nhất
    Benchmark này kiểm tra xem mô hình có tìm được các lỗi mà Mythos đã tìm thấy hay không. Trong kết quả ban đầu, mô hình mở tốt nhất là DeepSeek V4 Pro hoặc MiMo 2.5 Pro, nhưng MiMo có vẻ là may mắn và sau đó kém hơn trong gần như mọi bài kiểm tra. Ngược lại, DeepSeek luôn nằm trong nhóm đầu, và nhờ hiệu năng caching cực đoan, nó rẻ hơn gần như mọi thứ, kể cả các mô hình nhỏ hơn nhiều
    https://swelljoe.com/post/will-it-mythos/
    Một điểm thú vị khác là khi cung cấp semgrep mã nguồn mở làm công cụ, một số mô hình lại tệ hơn và không mô hình nào tốt hơn. Có thể có cách kết nối harness tốt để mô hình chỉ nhận thông tin hữu ích mà không cần trực tiếp xử lý semgrep
    Tôi đoán là semgrep không xuất hiện nhiều trong dữ liệu huấn luyện, nên mô hình bị yêu cầu vừa tự tìm hiểu cách dùng semgrep vừa tìm lỗi bảo mật, khiến sự tập trung bị phân tán và hiệu năng ở cả hai việc đều giảm. Phần lớn mô hình nhỏ và một số mô hình lớn không làm tốt việc này
    Các bài kiểm tra bổ sung vẫn đang tiếp diễn, và GLM 5.2 có vẻ nhiều khả năng sẽ tiếp tục thể hiện mạnh. Trong phần lớn những bài tôi đã kiểm tra đến nay, nó rất ấn tượng

  • Nghe nói GLM 5.2 là mô hình 753B tham số [1], tôi tò mò muốn chạy cục bộ thì cần phần cứng thế nào
    [1] https://huggingface.co/zai-org/GLM-5.2

    • Tôi đã thử chạy trên laptop Lenovo Legion 5i. Cấu hình đại khái là RAM 32GB, VRAM 8GB với 4060
      Nó còn không nhét vừa nguyên vẹn vào NVMe 1TB, nên tôi dùng mô hình lượng tử hóa UD_Q4_K_XL 4-bit trên mỗi trọng số, và tốc độ không phải token mỗi giây mà khoảng 12 giây mỗi token. Đó là một dự án thú vị nhưng không đáng dùng
      llama.cpp hỗ trợ memory mapping nên tôi chạy với cache ngữ cảnh 4096 token, và tò mò không biết phải stream từ SSD bao nhiêu khi toàn bộ không thể nằm trong RAM. Để tạo một đoạn tự giới thiệu ngắn 4 câu, nó đã đọc khoảng 1.5TiB từ đĩa
    • Cứ chạy bản lượng tử hóa là được. https://unsloth.ai/docs/models/glm-5.2
    • Xem antirez là được. https://x.com/antirez/status/2071173841175363905?s=20
    • 8 chiếc RTX6000 là đủ. Để bắt đầu chạy mô hình cỡ này với số token/giây chấp nhận được thì tốn khoảng 80.000–100.000 USD
      Nhưng cũng không cần lo. Các nhà truyền bá mã nguồn mở sẽ nói với bạn rằng trong vòng 3 năm nữa những mô hình như vậy sẽ chạy được trên điện thoại
      Với 100.000 USD, bạn có thể chạy mô hình này qua OpenRouter ở 50tps, 10 phiên đồng thời, 24/7 trong 10 năm mà vẫn còn tiền đi nghỉ. Trừ khi bạn là doanh nghiệp đã phải trả phí token riêng cho nhiều nhân viên, không có lý do gì để đầu tư số tiền đó vào mô hình chạy cục bộ

  • Cách nói “vượt Claude Code (32%) với khoảng 0,17 USD để tìm một lỗ hổng” là không chính xác
    Claude Code không phải LLM mà là một agent harness, còn Claude không phải một LLM đơn lẻ mà là thương hiệu hoặc một nhóm LLM

    • Nếu không có bảng giá của các mô hình khác thì con số USD đó vô nghĩa. Bài viết lỏng lẻo
    • Tác giả hẳn cũng biết rõ điểm đó. Dù vậy cảm ơn vì đã chỉ ra lỗi nhỏ này
    • Không soi mói tiểu tiết thì cũng chẳng mất gì
    • Claude Code gần như là cách duy nhất để tiếp cận chi phí khấu hao thực tế khi chạy các mô hình cấp Claude
      API tiêu dùng không dành cho doanh nghiệp rất đắt: với người dùng thì chi phí biên cao, còn với Anthropic thì biên lợi nhuận dày. Nếu muốn xấp xỉ chi phí mà một tác nhân cấp quốc gia phải bỏ ra để chạy mô hình trên phần cứng riêng, Claude Code có lẽ là ước tính tốt nhất cho chi phí khấu hao

  • Những con số này có vẻ khá thấp, nhất là so với những gì tôi đã đạt được ở kernel Windows và phía win32k↔win32u
    Giờ có lẽ cũng không còn ngạc nhiên nếu Trung Quốc bắt đầu vượt các mô hình mà Mỹ công khai trong một số hạng mục cụ thể như an ninh mạng
    GLM 5.2 đã đủ mạnh để hỗ trợ việc tự huấn luyện của chính nó, tương tự xu hướng đã thấy ở các mô hình tuyến đầu. Hơn nữa, có vẻ họ đạt tới đó với chi phí thấp hơn nhiều so với OpenAI hay Anthropic

    • Trump gần như chắc chắn sẽ để các mô hình mà ông ta cho phép các “đồng minh” của Mỹ dùng bị vượt qua. Có vẻ ông ta xem đồng minh gần như là các nước phụ thuộc
      Nếu cộng thêm sự thống trị ngày càng lớn của Trung Quốc trong năng lượng mặt trời, pin sạc, xe điện, đây có thể là đòn chí mạng đối với trật tự kinh tế sau Thế chiến II

  • Ít nhất cũng nên chạy Opus bằng đúng Pydantic harness đã dùng cho GLM. Hiện tại chẳng khác gì so sánh táo với lê
    Chi phí trên mỗi lỗ hổng của tất cả các mô hình khác ngoài GLM đâu?
    Không có mã thì cũng khó tin. Tất cả có thể là bịa ra

  • Kiểm soát xuất khẩu GLM có sắp đến không? Tôi dự đoán trong vài tháng tới Bộ Thương mại sẽ buộc OpenRouter và HuggingFace gỡ một số mô hình mở xuống
    Dù điều đó chẳng hợp lý

    • Nếu vậy thì sẽ là một thảm họa hoàn toàn. Cứ tưởng tượng trong khi Anthropic và OpenAI lấy lý do an toàn để chặn phần lớn công ty Mỹ dùng các mô hình mới nhất, thì kẻ tấn công lại dùng các mô hình mã nguồn mở cùng đẳng cấp để tấn công công ty Mỹ
      Cấm mô hình mã nguồn mở chẳng giúp giải quyết vấn đề chút nào. Vì kẻ tấn công không cảm thấy bị luật ràng buộc. Vì mục đích phòng thủ, mọi mô hình tiên tiến đều cần phải truy cập được
    • Mỹ có thể cấm sử dụng mô hình Trung Quốc trong lãnh thổ Mỹ. Nhưng như lệnh cấm xe Trung Quốc, phần còn lại của thế giới sẽ cứ dùng thôi
    • Dù muốn làm vậy, tôi nghĩ cũng khó tìm được cơ sở pháp lý để thực hiện
      Chính phủ có thẩm quyền (a) ngăn xuất khẩu hàng hóa và dịch vụ của Mỹ, (b) cấm nhập khẩu hàng hóa vật lý, và (c) cấm giao dịch với doanh nghiệp nước ngoài, bao gồm giao dịch mua dịch vụ hoặc ký hợp đồng cấp phép
      Nhưng nếu một công ty Mỹ có quan hệ độc lập với nhà cung cấp, và cũng không dùng trong hợp đồng chính phủ hay ứng dụng chịu quản lý, thì tôi không rõ có thẩm quyền pháp lý nào để cấm chính hành vi chạy một mô hình AI mã nguồn mở do Trung Quốc phát triển trong lãnh thổ Mỹ
      Có khả năng họ ra lệnh cho HuggingFace và các bên tương tự đình chỉ tài khoản Trung Quốc. Nhưng nếu ai đó ở Mỹ hoặc nước thứ ba tải mô hình từ Trung Quốc rồi, hoàn toàn độc lập với nhà cung cấp, tải lại nó lên máy chủ Mỹ, thì tôi tự hỏi mối liên hệ pháp lý nào có thể dùng để cấm việc đó
    • Ý là Mỹ áp đặt hạn chế xuất khẩu lên các mô hình do Trung Quốc sản xuất à?
    • Tôi nghĩ trong tương lai AI tối tân sẽ chỉ dành riêng cho ngành công nghiệp quốc phòng. Kiểu như chúng ta có thể có drone đồ chơi, nhưng không thể có Predator và Reaper

  • Tôi dùng GLM 5.2 qua Neuralwatt và nó rẻ đến mức nếu công ty cung cấp gói Claude thì có lẽ tôi có thể hủy thuê bao Claude cá nhân
    Tháng này tôi đã dùng 374 triệu token mà với cách tính giá dựa trên năng lượng chỉ tốn 18 đô la

  • Đọc như quảng cáo
    Thứ hai, đây “chỉ” là IDOR, thuộc nhóm dễ nhất trong các loại lỗ hổng
    Thứ ba, họ đang so sánh với GPT 5.5 và Opus 4.8
    Không, nhà tôi không có Mythos

    • Mythos chỉ hơn GPT 5.5 dưới 10% trên mọi benchmark, và chênh lệch đó có được nhờ nó lớn hơn Opus nhiều lần
      Nếu có thể cung cấp về mặt kinh tế thì nó đã được công bố ngay từ ngày đầu, thay vì màn xiếc marketing do đám hề vị tha hiệu quả bày ra. Bởi việc thừa nhận rằng chi phí suy luận của một mô hình chỉ tốt hơn dưới 10% lại đắt hơn hơn 1000% sẽ rất chí mạng
    • Theo kinh nghiệm của tôi, GLM 5.2 rất giỏi tìm lỗ hổng, và quan trọng hơn là khác với Opus, tôi chưa từng thấy nó từ chối làm theo lệnh
      Đây là một mô hình thực sự mạnh để tìm và sửa lỗ hổng
    • Dù vậy nó vẫn hữu ích. Nói theo cách thời nay, GLM 5.2 hôm nay đang ở cùng phòng với chúng ta, còn Mythos thì không
      Ở EU thì tình hình còn phức tạp hơn. Mythos có thể một ngày nào đó bước vào phòng rồi bất ngờ biến mất theo ý thích thất thường của một chủ thể chính trị mà chúng ta hoàn toàn không kiểm soát được
      Biết các mô hình mở có thể truy cập và chạy cục bộ đã tiến xa tới đâu là điều quan trọng. Tôi biết chúng vẫn tụt lại. Nhưng sẽ đến lúc “đủ tốt” trở nên hữu dụng. Hôm nay dù đó “chỉ là IDOR” và vẫn tụt sau mức hiện đại nhất, điều đó vẫn đúng
      Như ai đó ở trên đã nói, các mô hình cùng hạng như GLM 5.2, Kimi, DeepSeek V4 đang ngày càng đủ tốt để hỗ trợ các tác vụ chuẩn bị kho mã tự động, tức tải xuống·cài đặt·kiểm thử·sửa·kiểm thử lại. Điều đó dẫn tới dữ liệu theo dõi sử dụng thực tế có thể dùng để huấn luyện thế hệ tiếp theo. Việc đó có thể còn quan trọng hơn chuyện thua vài phần trăm trên benchmark
    • Nói nghiêm ngặt thì chẳng phải chúng ta hoàn toàn không có Mythos sao? Chỉ bên đó mới có quyền truy cập. Điều này có vẻ có nghĩa là chúng ta có Opus dùng tại nhà, tức trọng số mở
    • Họ nói rất thẳng rằng tiêu chí của họ hẹp và chủ yếu quan trọng với trường hợp sử dụng cụ thể của họ. Dù vậy cũng không nên để sự hợp lý khiến mọi người hạ chĩa xuống!