# GitHub Security Lab ra mắt Fuzzing Taskflow: Tự động hóa kiểm thử bảo mật C/C++ bằng AI Agent - Nguồn: GitHub Blog - Thời gian phát hành: 2026-09-25 01:26 (giờ Việt Nam) - Điểm AI: 64/100 - Nhãn AIHOT: Tinh chọn - Link AIHOT.vn: https://aihot.vn/items/f2e6dcf961db92d5 - Nguồn dữ liệu AI HOT: https://aihot.news/items/cmufwtcfq034nrogvh3zpr6df - Link gốc: https://github.blog/security/application-security/ai-powered-fuzzing-with-the-github-security-lab-taskflow-agent ## Lý do tinh chọn Tác giả đã mã nguồn mở toàn bộ quy trình kiểm thử mờ (fuzzing) tự chủ, đồng thời làm rõ các lựa chọn thiết kế về phản hồi độ bao phủ, nhận thức cấu trúc và phân loại lỗi; các nhà bảo trì C/C++ có thể tái sử dụng trực tiếp. ## Tóm tắt AI GitHub Security Lab vừa giới thiệu Fuzzing Taskflow, một AI Agent giúp tự động hóa toàn bộ quy trình kiểm thử fuzzing cho dự án C/C++, từ xác định điểm truy cập, viết mã harness đến phân tích lỗi. ## Thân bài ![AI-powered fuzzing with the GitHub Security Lab Taskflow Agent](https://github.blog/wp-content/uploads/2026/01/generic-github-security-invertocat.png) Trong bài viết này, tôi sẽ giải thích cách sử dụng luồng công việc (taskflow) fuzzing mới dựa trên khung làm việc AI GitHub Security Lab Taskflow Agent. 24 tháng 9, 2026 10 phút - Chia sẻ: Nếu bạn mới làm quen với fuzzing và muốn tìm hiểu các kiến thức cơ bản trước, hãy xem khóa học Fuzzing 101 của chúng tôi tại [gh.io/fuzzing101](https://gh.io/fuzzing101). Continuous fuzzing không phải là giải pháp kỳ diệu có thể giải quyết mọi vấn đề của bạn. Ngay cả những dự án đã tham gia OSS-Fuzz trong nhiều năm vẫn có thể ẩn chứa các lỗi nghiêm trọng, và lý do gần như luôn giống nhau: cần có người theo dõi độ bao phủ (coverage), viết các harness mới cho những đoạn mã chưa được kiểm thử, và phân loại các lỗi crash phát sinh. Nói cách khác, fuzzing vẫn cần sự tham gia của con người. Vì vậy, câu hỏi tự nhiên mà tôi luôn tự đặt ra là: chúng ta có thể thực sự bàn giao bao nhiêu phần công việc của con người cho một tác nhân LLM? Đó là điều đã thôi thúc tôi xây dựng Fuzzing Taskflow, một quy trình fuzzing tự động dành cho các dự án C/C++. Bạn chỉ cần trỏ nó vào một kho lưu trữ GitHub, và nó sẽ thực hiện phần còn lại: xác định các điểm đầu vào phù hợp, phân tích hệ thống xây dựng (build system), viết các harness, chạy AFL++, đọc các báo cáo độ bao phủ, cải thiện các harness, phân loại từng lỗi crash và viết báo cáo lỗ hổng cho mỗi lỗi riêng biệt, tất cả đều không cần con người giám sát. Fuzzing Taskflow được xây dựng trên nền tảng [GitHub Security Lab Taskflow Agent](https://github.com/GitHubSecurityLab/seclab-taskflow-agent), khung làm việc của chúng tôi để viết tự động hóa bảo mật dựa trên LLM, vì vậy quy trình này được thể hiện dưới dạng một tập hợp các taskflow mà tác nhân sẽ chạy từ đầu đến cuối. Trong bài viết này, tôi sẽ hướng dẫn bạn cách thức hoạt động và các quyết định thiết kế đằng sau nó. Hãy bắt đầu thôi! ### Cách chạy chương trình Cách đơn giản nhất để chạy nó là truy cập [https://github.com/GitHubSecurityLab/seclab-taskflows-fuzzing](https://github.com/GitHubSecurityLab/seclab-taskflows-fuzzing) và khởi chạy một codespace. Sau đó, chạy tập lệnh như sau: ``` ./scripts/fuzzing/run_fuzzing.sh PROJECT ``` Ví dụ: ``` ./scripts/fuzzing/run_fuzzing.sh tukaani-project/xz ``` Chỉ vậy thôi. Đối số chỉ đơn giản là tên chủ sở hữu/kho lưu trữ trên GitHub. Sau đó, tác nhân sẽ tự mình thực hiện tất cả các bước sơ bộ: - Cài đặt phần mềm như AFL - Sao chép (clone) kho lưu trữ - Xác định các hàm quan trọng nhất trong mã nguồn - Tạo các mục tiêu fuzz cho những hàm đó Nếu bạn chỉ muốn kiểm tra nhanh (smoke test) trước khi bắt đầu một chiến dịch dài hơi, hãy trỏ nó vào một dự án nhỏ: ``` ./scripts/fuzzing/run_fuzzing.sh DaveGamble/cJSON ``` Một lời cảnh báo trước khi bạn chạy: taskflow này chạy afl-fuzz, clang và các lệnh xây dựng tùy ý do LLM chọn trực tiếp trên máy chủ, không thông qua container. Về nguyên tắc, một tác nhân bị tấn công prompt-injection có thể làm bất cứ điều gì mà người dùng của bạn có thể làm. Vì vậy, vui lòng chỉ chạy nó trong môi trường dùng một lần (ví dụ: Codespace hoặc máy ảo tạm thời), không có đặc quyền nâng cao. ![Screenshot of Seclab Taskflows Fuzzing.](https://github.blog/wp-content/uploads/2026/08/Screenshot-2026-09-23-at-3.16.38-PM.png?resize=1024%2C453) ### Lựa chọn mô hình Một số mô hình tiên tiến áp đặt các rào cản bảo mật lên đầu ra của chúng. Đối với luồng công việc fuzzing, chúng tôi sử dụng Claude Sonnet 5 theo mặc định vì nó đã vượt qua tất cả các bài kiểm tra nội bộ của chúng tôi mà không gặp vấn đề gì. Bạn có thể chọn một mô hình khác bằng cách sửa đổi tệp sau: src/seclab_taskflows_fuzzing/configs/model_config.yaml. ### Kiến trúc trong một phút Trước khi đi vào các phần thú vị, bạn cần biết cách các thành phần kết hợp với nhau. Có ba lớp: - Một trình điều khiển shell (run_fuzzing.sh) liên kết các giai đoạn của quy trình lại với nhau. - Một tập hợp các tệp YAML taskflow, mỗi tệp cho một giai đoạn, về cơ bản là các câu lệnh (prompt) hướng dẫn tác nhân LLM phải làm gì ở mỗi bước. - Một tập hợp các công cụ MCP mà tác nhân gọi để thực hiện công việc thực tế: chạy AFL, biên dịch harness, lưu trữ crash, đọc báo cáo độ bao phủ, v.v. Quy tắc thiết kế mà tôi quan tâm nhất là sự phân tách trách nhiệm rõ ràng: tác nhân LLM chịu trách nhiệm ra quyết định, và các công cụ MCP chịu trách nhiệm thực thi. Tác nhân quyết định fuzz cái gì, viết harness nào và theo đuổi lỗ hổng độ bao phủ nào tiếp theo. Các công cụ chỉ cung cấp các hàm nguyên thủy như run_afl_for hoặc compile_harness. Tác nhân không bao giờ gọi trực tiếp AFL hoặc clang; nó tạo ra quy trình từ các khối xây dựng này. Tất cả trạng thái nằm trong cơ sở dữ liệu SQLite (fuzz_context.db), vì vậy các giai đoạn không bao giờ chuyển dữ liệu cho nhau trong bộ nhớ, mà chỉ thông qua cơ sở dữ liệu. Một chi tiết nhỏ nhưng quan trọng: mỗi harness được xây dựng hai lần. Công cụ đo lường cạnh (edge instrumentation) của AFL rất tốt để hướng dẫn fuzzer nhưng lại vô dụng đối với các báo cáo độ bao phủ mà con người có thể đọc được. Vì vậy, mỗi harness trở thành cả tệp nhị phân.afl (được xây dựng với afl-clang-lto -fsanitize=address,undefined) và tệp nhị phân.cov (được xây dựng với clang -fprofile-instr-generate -fcoverage-mapping). Tệp nhị phân.afl thực hiện fuzzing; tệp nhị phân.cov sau đó phát lại hàng đợi của AFL để tạo ra độ bao phủ theo dòng mã nguồn và nhánh thực tế. ### Vòng lặp phản hồi độ bao phủ Đây là trái tim của toàn bộ quy trình, và là phần tự động hóa trực tiếp nhất quy trình làm việc thủ công mà tôi đã mô tả ở phần đầu. Nếu bạn đã từng cố gắng cải thiện độ bao phủ fuzzing bằng tay, bạn sẽ biết đó là một quá trình lặp đi lặp lại như sau: ![Three bubbles that say: Run the fuzzers, Check the coverage, and Improve the fuzzers. They are connected by three arrows in a circular flow.](https://github.blog/wp-content/uploads/2026/08/Screenshot-2026-08-26-at-1.37.40-PM.png?resize=843%2C704) Bước "kiểm tra độ bao phủ" trước đây do tôi thực hiện, đọc thủ công báo cáo LCOV để tìm các nhánh chưa được bao phủ. Bước "cải thiện độ bao phủ" cũng do tôi thực hiện, bằng cách viết một harness mới hoặc tạo ra một đầu vào mới. Fuzzing Taskflow bàn giao cả hai bước đó cho tác nhân. Mỗi lần lặp, cho mỗi harness, tác nhân chạy AFL trong một khoảng thời gian ngân sách, phát lại hàng đợi với tệp nhị phân.cov để nhận báo cáo độ bao phủ thực tế, sau đó đọc danh sách các nhánh chưa được bao phủ. Dựa trên những gì tìm thấy, nó chọn một trong số các hành động: - Thêm một seed mới được tạo ra để tiếp cận một nhánh chưa được bao phủ - Chỉnh sửa mã nguồn harness để gọi thêm một API - Tự động làm phong phú từ điển AFL với các hằng số ma thuật mà một câu lệnh guard đang so sánh - Đơn giản là bỏ qua nếu đó là đường dẫn lỗi ít gặp hoặc mã nguồn của nhà cung cấp không đáng để theo đuổi Ngân sách thời gian tăng gấp đôi sau mỗi lần lặp: 30s → 60s → 120s → 240s → 480s → 960s (≈ 32 phút/mục tiêu) Ý tưởng là dành các vòng chạy ngắn, chi phí thấp ở giai đoạn đầu (khi có nhiều độ bao phủ dễ dàng đạt được) và các vòng chạy dài hơn ở giai đoạn sau (khi fuzzer cần nhiều thời gian hơn để vượt qua một rào cản khó). _Bài gốc còn tiếp._ Xem tiếp tại: