Nhà nghiên cứu Antonio Morales thuộc GitHub Security Lab đăng bài ngày 24/9, công bố một pipeline fuzzing (kiểm thử mờ) do mô hình ngôn ngữ lớn điều khiển, nhắm vào các dự án C/C++. Mã nguồn được đặt trong kho GitHub seclab-taskflows-fuzzing, mô hình mặc định là Claude Sonnet 5.
Hệ thống này xây trên nền Taskflow Agent — framework riêng của GitHub, được mô tả chính thức là "framework để viết các quy trình tự động hóa bảo mật dựa trên LLM". Người dùng chỉ cần mở một Codespace trong kho, chạy một dòng lệnh kèm tên dự án mục tiêu, ví dụ tukaani-project/xz, phần còn lại giao cho agent xử lý.
Từ tìm điểm vào tới xuất báo cáo
Theo mô tả trong bài, pipeline thực hiện tuần tự các bước: nhận diện điểm vào của mã nguồn, tự viết bộ khung kiểm thử (harness), gọi AFL++ để chạy fuzzing, đọc báo cáo độ phủ (coverage), viết lại harness dựa trên độ phủ đã đạt được, sau đó phân loại từng lần crash, cuối cùng tạo báo cáo lỗ hổng kèm đề xuất bản vá theo định dạng diff thống nhất.
Cơ chế phản hồi độ phủ dùng cách nhân đôi ngân sách thời gian: mỗi vòng được cấp thời gian gấp đôi vòng trước, bắt đầu từ 30 giây, sau đó lần lượt 60, 120, 240, 480, 960 giây — tổng cộng khoảng 32 phút cho một mục tiêu. Sau mỗi vòng, agent xem lại độ phủ rồi quyết định sửa phần nào tiếp theo.
Để việc biến đổi ngẫu nhiên (mutation) hiểu dữ liệu đầu vào tốt hơn, pipeline chồng bốn lớp "nhận biết cấu trúc": từ điển và bộ mutator riêng cho từng định dạng file, từ điển rút ra từ chính mã nguồn, từ điển AFL sinh động trong lúc chạy, và kỹ thuật ghép nối corpus (corpus splicing).
Việc phân loại crash được chia khá chi tiết: lỗ hổng thật (vulnerability), khuyến nghị gia cố thư viện (library_hardening), lỗi của chính harness (harness_bug), cạn bộ nhớ, hết giờ, assertion thất bại, và trùng lặp. Crash sẽ được thu gọn qua afl-tmin trước, sau đó lọc trùng theo stack trace. Trong lúc chạy còn có một bảng điều khiển HTML ở cổng 8765 để theo dõi tiến độ theo thời gian thực.
Morales đặt ra một nguyên tắc phân công rõ ràng cho thiết kế này:
"the LLM agent owns the decisions, and the MCP tools own the execution"
(Quyết định thuộc về agent LLM, thực thi thuộc về các công cụ MCP.)
So với hướng đi của OSS-Fuzz
Việc đưa LLM vào fuzzing, Google đã đi trước. OSS-Fuzz đã thử dùng LLM để tự sinh fuzz target từ năm 2023, và cuối năm 2024 Google từng công bố rằng hướng này giúp họ tìm ra một loạt vấn đề, trong đó có một lỗ hổng trong OpenSSL. Nhưng giải pháp đó chủ yếu giải quyết bước "viết harness", còn bản thân dự án phải tích hợp trước vào hạ tầng của OSS-Fuzz.
Cách làm lần này của GitHub giống một bộ công cụ mang đi được hơn: không yêu cầu dự án tích hợp vào bất kỳ nền tảng nào, chỉ cần mở một môi trường phát triển trên mây là chạy được, việc phân loại và viết báo cáo cũng được gộp sẵn. Ngay đầu bài, tác giả nhắc rằng fuzzing liên tục không phải thuốc tiên — những dự án đã nằm trên OSS-Fuzz nhiều năm vẫn có thể ẩn chứa lỗi nghiêm trọng, và đây cũng là lý do họ chọn xz làm ví dụ minh họa. xz từng dính sự cố backdoor gây chấn động cộng đồng mã nguồn mở năm 2024, nhưng đó là một vụ cài mã độc có chủ đích (poisoning), khác loại với các lỗi bộ nhớ mà fuzzing có thể phát hiện.
Những gì bài viết chưa nói tới
Một số số liệu mà giới quan sát quan tâm nhất lại không được công bố: trên xz và cJSON tìm được bao nhiêu crash, bao nhiêu trong số đó được xác định là lỗ hổng thật, có được cấp CVE hay không; chi phí token và tiền bạc cho mỗi lần chạy hết một dự án; tỷ lệ báo động giả. Cách diễn đạt của chính tác giả khá dè dặt — ông viết rằng kết luận phân loại nên được xem là "một điểm khởi đầu đã được chuẩn bị kỹ để giao lại cho con người", không phải kết quả cuối cùng, và các đề xuất vá lỗi cũng đều được gắn nhãn cần con người rà soát lại.
Về mặt an toàn còn một tiền đề nữa. Pipeline này khi chạy không có cách ly container, đội ngũ chính thức khuyến nghị chỉ nên chạy trong Codespace hoặc máy ảo tạm thời — những môi trường có thể vứt bỏ được, và không nên cấp quyền nâng cao cho nó. Với những đội muốn triển khai trực tiếp trong mạng nội bộ công ty, rào cản này sẽ đến sớm hơn cả việc chọn mô hình.
Đối với những người duy trì thư viện mã nguồn mở ở Trung Quốc đại lục, rào cản chính nằm ở mô hình: cấu hình mặc định gọi mô hình của Anthropic, kết nối trực tiếp từ Trung Quốc không thuận tiện. Kho mã nguồn mở, về lý thuyết có thể đổi sang mô hình tương thích khác, nhưng hiệu quả có giữ được hay không thì hiện chưa có thử nghiệm công khai nào.
Nguồn tham khảo: blog chính thức của GitHub, mô tả trong kho mã nguồn mở seclab-taskflows-fuzzing, CocoLoop, tài liệu công khai về Google OSS-Fuzz; các bước của pipeline, ngân sách thời gian và cách phân loại crash lấy theo mô tả trên blog GitHub.