Fuzzing Taskflow tự động hóa kiểm thử C/C++ nhưng chưa thay thế chuyên gia

Fuzzing Taskflow là pipeline thử nghiệm của GitHub Security Lab dành cho dự án C/C++, nối một AI agent với harness, AFL++ và báo cáo độ bao phủ. Mục tiêu là giảm công việc lặp lại trong khâu tìm điểm vào, tạo giao diện thử, chạy đầu vào biến đổi và phân loại crash. Công cụ không biến độ bao phủ thành bằng chứng rằng chương trình an toàn.

Taskflow xử lý phần nào của fuzzing

Fuzzing đưa nhiều đầu vào đã biến đổi vào chương trình rồi theo dõi đường chạy mới, lỗi hoặc tình trạng dừng bất thường. AFL++ là bộ công cụ mã nguồn mở dùng phản hồi từ lần chạy trước để điều chỉnh đầu vào. Để gọi được một hàm sâu trong thư viện, nhóm phát triển thường phải viết harness, tức đoạn mã chuyển đầu vào thành tham số hợp lệ và dựng trạng thái cần thiết.

GitHub Security Lab mô tả Taskflow là pipeline nhận kho mã C/C++, tìm điểm vào phù hợp, phân tích hệ thống xây dựng, viết harness, chạy AFL++ và đọc báo cáo độ bao phủ. Agent tiếp tục điều chỉnh harness hoặc đầu vào sau mỗi vòng. Cách này nhắm vào phần chuẩn bị và lặp lại của fuzzing, không phải quyết định cuối cùng về khả năng khai thác.

Độ bao phủ chỉ trả lời câu hỏi nhóm đầu vào hiện tại đã đi qua những dòng hoặc nhánh nào. Một nhánh chưa được chạm tới có thể chứa lỗi, nhưng cũng là đường xử lý hiếm hoặc mã phụ thuộc bên ngoài. Một nhánh đã chạy qua vẫn cần đầu vào đủ đa dạng và điều kiện trạng thái đúng. Vì thế, phần trăm độ bao phủ không phải điểm số an toàn.

Vòng lặp từ harness đến báo cáo crash

README của kho mã cho biết pipeline gồm các bước nhận mã nguồn, tìm mục tiêu, phân tích build, tạo harness, xây dựng bản chạy AFL và bản đo bao phủ. Sau đó pipeline chạy fuzzing, tạo báo cáo độ bao phủ, cải thiện harness, phân loại crash, kiểm tra lại crash cũ và lập báo cáo cho từng kết quả.

Agent trích chuỗi và hằng số số từ mã nguồn để tạo từ điển AFL. Từ điển giúp đầu vào vượt qua những kiểm tra định dạng như chuỗi đánh dấu, giá trị magic hoặc nhánh so sánh cố định. Pipeline cũng giữ corpus riêng cho từng harness, nhờ đó đầu vào có ích từ vòng trước được dùng ở vòng sau thay vì bị xóa sau mỗi lần chạy.

Taskflow xây dựng một bản chạy có chèn đo lường cho AFL++ và một bản dành cho tính độ bao phủ. Đầu vào trong hàng đợi của AFL++ được chạy lại trên bản thứ hai để tạo báo cáo dễ đọc. Nếu agent thấy đường quan trọng chưa được chạm tới, nó sửa harness, thêm seed hoặc bổ sung từ điển. Mọi thay đổi vẫn phụ thuộc vào việc mô hình hiểu đúng API, trạng thái khởi tạo và định dạng dữ liệu.

Khâu xử lý crash thường thu nhỏ đầu vào gây lỗi, chạy lại với AddressSanitizer, gom các kết quả có cùng dấu vết rồi tạo báo cáo. README liệt kê các nhãn như vulnerability, harness_bug, OOM, timeout và duplicate. Nhãn vulnerability vẫn cần kiểm tra khả năng đi tới hàm, nguyên nhân gốc và tác động thật trên mã nguồn.

Antonio Morales cảnh báo báo cáo và bản vá gợi ý của agent chỉ là điểm bắt đầu cho người kiểm tra. Mô hình vẫn hiểu sai mã đích, nhầm lỗi của harness với lỗi thư viện hoặc đánh giá sai khả năng khai thác. Đây là ranh giới quan trọng khi đưa kết quả vào quy trình xử lý lỗ hổng.

Dự án nào nên thử trước

Kho mã chính thức yêu cầu môi trường Linux hoặc Codespace, Python 3.11 cùng AFL++, clang, lcov, ctags, cscope, graphviz, Git và GitHub CLI. Điểm khởi đầu hợp lý là thư viện C hoặc C++ nhỏ, có điểm vào rõ, build lặp lại được và có đầu vào mẫu. Một smoke test nhỏ giúp nhóm biết công cụ có dựng được bản chạy trước khi dành thời gian cho chiến dịch dài.

Tài liệu AFL++ chia fuzzing mã nguồn thành biên dịch có chèn đo lường, chuẩn bị corpus và chạy đầu vào biến đổi để tìm đường mới. Định dạng byte đơn giản thường dễ bắt đầu hơn JSON, XML hoặc gói nhị phân có kiểm tra độ dài, checksum và trạng thái. Khi định dạng nằm trong tài liệu nội bộ hoặc dịch vụ bên ngoài, seed do agent tạo vẫn không tới được logic cần kiểm tra.

Nhóm cần ghi rõ hàm đích, điều kiện khởi tạo, cách dọn trạng thái, lệnh build, phiên bản phụ thuộc và lệnh tái hiện. Nếu harness tự gây lỗi, AFL++ sẽ lặp lại lỗi ở lớp thử thay vì lỗi của thư viện. Những dự án cần cơ sở dữ liệu, chứng thư, dịch vụ nền hoặc quyền hệ thống nên được tách thành bài toán mô phỏng trước khi thử pipeline.

Rủi ro nằm ở host và dữ liệu thử

GitHub Security Lab ghi rõ afl-fuzz, clang và lệnh build do mô hình chọn chạy trực tiếp trên host, không có container ở giữa. Một agent bị prompt injection hoặc nhận chỉ dẫn sai gọi lệnh trong phạm vi quyền của tài khoản. Vì vậy, Codespace dùng một lần hoặc máy ảo bỏ đi phù hợp hơn máy chủ build dùng chung, máy chính thức hay máy có credential nhạy cảm.

AFL++ cũng cảnh báo fuzzing làm nóng CPU, tiêu thụ bộ nhớ, ghi rất nhiều dữ liệu và làm đầy đĩa. Khi thiết kế thử nghiệm, nhóm nên đặt giới hạn thời gian, bộ nhớ, dung lượng corpus và số tiến trình. Mạng đi ra, token GitHub, khóa đám mây và thư mục chứa mã nguồn cần được giới hạn riêng. Crash input và log cũng phải được xem như sản phẩm có thể chứa dữ liệu nội bộ.

Trước khi đưa vào CI, cần quy định ai duyệt thay đổi harness, ai xác nhận crash, nơi lưu artifact và điều kiện dừng chiến dịch. Chi phí không chỉ là phí model. CPU, bộ nhớ, dung lượng đĩa, thời gian kỹ sư, bảo trì toolchain và xử lý false positive đều cần ghi trong ước tính. Nguồn công khai của dự án chưa đưa ra bảng giá cố định cho mô hình hoặc cho một chiến dịch fuzzing.

Tại Việt Nam thì sao

Đối với nhóm phát triển ở Việt Nam, câu hỏi đầu tiên không phải là Taskflow có một mức giá chung hay không. Không có cơ sở để đưa ra một con số áp dụng cho mọi dự án, vì ngân sách còn phụ thuộc kho mã, thời lượng chạy, số worker, model, dung lượng lưu trữ và thời gian người kiểm tra. Báo giá dịch vụ nên tách phí tài khoản hoặc API, máy chủ, lưu trữ, hỗ trợ kỹ thuật và phần phát sinh do dữ liệu đi ra ngoài. Cách hỏi này hữu ích hơn việc lấy giá của một công cụ rồi xem đó là toàn bộ chi phí.

Một nhóm ở Việt Nam muốn thử nên bắt đầu bằng thư viện nhỏ không chứa mã khách hàng hoặc khóa truy cập. Nhóm tạo một kho thử riêng, cố định phiên bản phụ thuộc, đặt thời gian chạy ngắn và lưu lệnh tái hiện. Nếu dự án có dữ liệu tiếng Việt trong parser, nhóm nên đưa seed đã được phép sử dụng vào corpus và kiểm tra encoding trước khi đánh giá độ bao phủ. Đây là ví dụ vận hành, không phải bằng chứng rằng pipeline sẽ tìm ra lỗi trong mọi sản phẩm.

Nghị định số 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân được Cổng thông tin điện tử Chính phủ ghi là ban hành ngày 17/4/2023 và có hiệu lực ngày 1/7/2023. Khi corpus, crash input hoặc log có dữ liệu gắn với khách hàng, người lao động hay người dùng, nhóm cần lập danh mục dữ liệu, mục đích xử lý, người được truy cập, thời hạn lưu và bên cung cấp dịch vụ nhận dữ liệu. Nghị định này là điểm tra cứu pháp lý về dữ liệu cá nhân tại Việt Nam, không phải giấy phép mặc định để tải mọi dữ liệu lên model.

Luật số 24/2018/QH14 về an ninh mạng được Cổng thông tin điện tử Chính phủ ghi là có hiệu lực từ ngày 1/1/2019. Doanh nghiệp nên dùng văn bản này cùng quy định theo ngành và hợp đồng để kiểm tra hệ thống, dữ liệu và nhà cung cấp có thuộc phạm vi cần xử lý riêng hay không. Một bài thử trong Codespace không tự trả lời câu hỏi tuân thủ. Cần có người phụ trách xác định dữ liệu nào được đưa vào, mạng nào được kết nối và log nào được giữ lại.

Về mức độ sẵn có, GitHub công khai hướng dẫn chạy trong Codespace và môi trường Linux, còn khả năng triển khai tại Việt Nam phụ thuộc tài khoản GitHub, quyền truy cập model, kết nối mạng, công cụ cài đặt và năng lực C/C++ của nhóm. Không nên suy ra rằng mọi model, vùng dịch vụ hoặc nhà cung cấp đều có cùng điều kiện truy cập. Trước khi ký dịch vụ, doanh nghiệp nên hỏi nơi xử lý dữ liệu, thời hạn lưu prompt và log, quyền dùng dữ liệu để cải thiện model, giới hạn gọi API và cách xóa artifact.

Một ví dụ an toàn là dùng Taskflow với thư viện mã nguồn mở đã được chọn, seed tổng hợp và tài khoản không có quyền quản trị. Nhóm bảo mật kiểm tra crash trong bản sao cô lập, sau đó người phụ trách mã nguồn tái hiện bằng đầu vào tối giản. Nếu phát hiện dữ liệu khách hàng trong corpus, chiến dịch cần dừng để xử lý quyền truy cập và xóa dữ liệu trước khi chạy tiếp. Tính đến thời điểm bài viết được thực hiện, chúng tôi chưa tìm thấy số liệu chính thức của cơ quan chức năng Việt Nam để so sánh tỷ lệ phát hiện, chi phí hoặc mức độ sẵn có của Fuzzing Taskflow giữa các ngành.

Tiêu chí trước khi đưa vào CI

Nhóm nên cố định commit, toolchain, seed, thời gian và giới hạn tài nguyên rồi mới so sánh với kiểm thử hiện có. Kết quả đáng xem xét phải đi kèm đường tái hiện, log, phiên bản binary và người chịu trách nhiệm xác nhận. Độ bao phủ tăng nhưng crash không tái hiện được là tín hiệu cần điều tra, không phải lý do tự động mở báo cáo lỗ hổng.

Quy trình tối thiểu gồm bốn bước: thử trong môi trường bỏ đi, kiểm tra harness và lệnh build, tái hiện crash bằng người phụ trách mã nguồn, sau đó đánh giá quyền và artifact trước khi nối CI. Nếu dự án cần quyền đặc biệt, dữ liệu thật hoặc dịch vụ nền chưa được cô lập, nhóm nên giữ Taskflow ở môi trường nghiên cứu riêng.

Câu hỏi thường gặp

Fuzzing Taskflow có bảo đảm tìm hết lỗ hổng không?

Không. Pipeline tự động hóa một phần chuẩn bị, chạy và phân loại, còn kết quả chịu ảnh hưởng của điểm vào, seed, định dạng, build, trạng thái và thời gian. Báo cáo độ bao phủ và nhãn crash đều cần người kiểm tra.

Đưa thẳng vào mọi dự án C/C++ được không?

Không nên giả định như vậy. Dự án dùng build đặc thù, phụ thuộc đóng, dữ liệu có trạng thái hoặc cần dịch vụ bên ngoài thường phải chỉnh môi trường và harness trước.

Có nên chạy trên máy chủ CI dùng chung không?

Không nên chạy thử theo mặc định. Vì lệnh chạy trên host và không có container cô lập, nhóm cần môi trường bỏ đi, tài khoản ít quyền, mạng và credential bị giới hạn trước khi thiết kế cách nối vào CI chính thức.