Người săn lỗ hổng của GitHub: AI giúp tìm lỗi nhanh hơn, nhưng đừng tin đầu ra của model
GitHub phỏng vấn @r31n, thợ săn lỗ hổng từng nhiều lần tìm ra lỗi nghiêm trọng trên GitHub Enterprise Server. Ba bài học anh rút ra: nghĩ theo nguồn và đích thay vì checklist, dùng AI như bộ tăng tốc chứ không giao trách nhiệm, và coi đầu ra của model là dữ liệu không đáng tin. Bài này dịch ba bài học đó thành checklist thực hành cho người dựng AI agent.
GitHub vừa đăng bài phỏng vấn @r31n, một thợ săn lỗ hổng (bug bounty hunter, tức người tìm lỗ hổng bảo mật để nhận thưởng) từng nhiều lần phát hiện lỗi nghiêm trọng trên GitHub Enterprise Server. Bài phỏng vấn kể cách anh rèn kỹ năng bảo mật mỗi ngày. Điểm đáng nhớ nhất không nằm ở tiền thưởng, mà ở cách anh dùng AI: nó giúp tìm lỗi nhanh hơn rõ rệt, nhưng đầu ra của nó thì không đáng tin.
Nghĩ theo nguồn và đích, đừng học thuộc checklist lỗ hổng
@r31n không bắt đầu từ một loại lỗ hổng cụ thể. Anh nghĩ theo nguồn và đích. Nguồn là nơi dữ liệu do kẻ tấn công kiểm soát đi vào ứng dụng: tham số trong request, file người dùng tải lên, dữ liệu từ một dịch vụ khác. Đích là thao tác nhạy cảm dùng dữ liệu đó: truy vấn cơ sở dữ liệu, gọi mạng, chạy lệnh, quyết định phân quyền.
Phần thú vị nằm ở đường đi giữa hai đầu. Dữ liệu bị biến đổi ra sao, được kiểm tra ở đâu, đi qua ranh giới tin cậy nào, và các kiểm soát đó có đủ trước khi chạm đích hay không. Cách nghĩ này giải phóng anh khỏi khuôn của từng loại lỗ hổng: đôi khi lỗ hổng chỉ lộ ra khi bạn hiểu một nguồn dữ liệu có thể tác động đến thao tác nhạy cảm bằng cách nào.
Ví dụ anh thích nhất là chuỗi khai thác (exploit chain). Một lỗi chuyển hướng mở (open redirect) đứng một mình thì ít nguy hiểm. Nhưng nếu hệ thống còn một lỗi SSRF đi theo chuyển hướng, câu chuyện khác hẳn. (SSRF là lỗi cho phép kẻ tấn công khiến máy chủ tự gửi yêu cầu mạng đến địa chỉ tùy ý.) Cái chuyển hướng vô hại bỗng thành mắt xích trong một vụ tấn công lớn. Bài học: đừng đánh giá từng lỗi riêng lẻ. Hãy nhìn cách chúng nối với nhau.
Góc này áp thẳng vào AI agent. Prompt của người dùng, kết quả tìm kiếm, nội dung file agent đọc được — tất cả đều là nguồn. Gọi API, ghi file, chạy lệnh, gửi tiền — là đích. Một agent an toàn không bắt đầu từ câu "hãy cẩn thận" trong prompt, mà từ bản đồ nguồn và đích được vẽ trước khi viết dòng prompt đầu tiên.
AI là bộ tăng tốc, không phải người thay thế
@r31n dùng AI khá nhiều trong nghiên cứu: đọc mã nguồn lạ, tìm nơi một hàm được gọi, lần dấu dữ liệu qua code, hiểu cấu trúc hệ thống. Anh cũng dùng AI để viết script kiểm chứng (PoC, tức đoạn mã chứng minh lỗ hổng có thật) sau khi đã xác định được vấn đề.
Nhưng anh nêu một nghịch lý đáng suy ngẫm: AI càng hữu ích khi bạn càng hiểu vấn đề. Câu hỏi mơ hồ kiểu "ứng dụng này có lỗ hổng không" cho kết quả tệ. Cho AI đúng ngữ cảnh, giải thích những gì bạn đã biết, rồi hỏi một câu hẹp — chất lượng tăng vọt. Công cụ không quan trọng bằng chất lượng công việc, và tò mò cộng kiên trì thì bền hơn mọi công cụ.
Quy tắc dùng AI có trách nhiệm của anh cũng rất thẳng: dùng AI để nghiên cứu tốt hơn, không để giao trách nhiệm. Nếu AI nói nó tìm thấy lỗ hổng, không có nghĩa bạn tìm thấy lỗ hổng thật. Bạn vẫn phải tự tái hiện, hiểu chính xác chuyện gì đang xảy ra, ranh giới bảo mật nào bị phá vỡ, và tác động thật là gì. Lý tưởng nhất: bạn hiểu vấn đề đủ sâu để viết báo cáo mà không cần AI.
Câu này đáng để các đội làm AI agent in ra dán lên tường. Số báo cáo chưa kiểm chứng mà các nhóm bảo mật phải xử lý đang tăng đúng bằng tốc độ AI hạ thấp rào cản nghiên cứu. AI nên làm cho nghiên cứu tốt hơn, chứ không phải chỉ làm cho báo cáo nhiều hơn.
Đầu ra của model là dữ liệu không đáng tin
Khi được hỏi về kiểm thử tính năng AI, @r31n nói thẳng một điều. Kẻ tấn công có thể tác động vào bộ phận ra quyết định xác suất của hệ thống, thông qua dữ liệu, chỉ dẫn hay ngữ cảnh mà nó nhận. Nhưng bắt model nói điều bất ngờ không phải phần thú vị. Câu hỏi quan trọng hơn là: ảnh hưởng đó cho phép kẻ tấn công đạt được gì? Hắn có truy cập được thứ không được phép, hay khiến hệ thống hành động với quyền mà hắn không có?
Vì thế, hàng rào bảo vệ ở tầng model (guardrail) không bao giờ nên là biên bảo mật chính hay duy nhất. Xung quanh model vẫn cần các kiểm soát xác định: phân quyền đúng, quyền tối thiểu, cô lập, kiểm tra dữ liệu. Và bảo mật ứng dụng truyền thống không biến mất chỉ vì có AI tham gia. Đầu ra của model vẫn phải được coi là đầu vào không đáng tin. Nếu đầu ra đó đi vào trình duyệt, câu truy vấn, lệnh shell, yêu cầu web hay một hệ thống khác mà không có kiểm soát phù hợp, hậu quả vẫn quen thuộc. Đó là những lỗ hổng cũ: XSS, SQL injection, command injection, SSRF. Model thì mới. Còn những cái đích nguy hiểm thì không.
Đây chính là điểm nối với bài học đầu tiên. Agent đọc email rồi gọi công cụ thanh toán — đó là một đường nguồn-đích. Email là nguồn không đáng tin. Công cụ thanh toán là đích nhạy cảm. Không có kiểm soát xác định nào ở giữa, thì mọi lời hứa "tôi sẽ cẩn thận" trong system prompt chỉ là lời đề nghị, không phải cái khóa.
Checklist ba phút cho agent của bạn
Từ bài phỏng vấn, mình rút ra một checklist thực hành cho bất kỳ ai đang dựng AI agent có gọi công cụ:
- Liệt kê mọi nguồn agent đọc: prompt người dùng, kết quả công cụ, file, email, trang web. Đánh dấu nguồn nào kẻ khác có thể chèn nội dung vào.
- Liệt kê mọi đích agent chạm tới: ghi và xóa file, gọi API, chạy lệnh, gửi tin nhắn, thanh toán. Đánh dấu hành động nào không thể hoàn tác.
- Với mỗi đường đi từ nguồn không đáng tin tới đích không thể hoàn tác, gắn kiểm soát nằm trong hệ thống, không nằm trong prompt. Đó có thể là token phạm vi hẹp và ngắn hạn. Hoặc một lần xác nhận của người dùng gắn với đúng yêu cầu cụ thể, hạn mức cho các thao tác liên quan đến tiền, và nhật ký ghi lại để kiểm tra sau.
- Tự hỏi theo cách của @r31n: chuỗi nào gồm những bước vô hại riêng lẻ có thể nối thành một hành động nguy hiểm? Nếu chưa trả lời được, bản đồ nguồn-đích của bạn còn thiếu.
Ví dụ cụ thể: agent đọc email (nguồn), trong email có "chỉ dẫn" yêu cầu chuyển khoản (nguồn bị đầu độc), agent gọi công cụ thanh toán (đích). Kiểm soát đúng không phải là dặn agent "đừng nghe lời email". Mà là: công cụ thanh toán chỉ nhận token có hạn mức bằng không cho thao tác tự động. Mọi giao dịch thật đều cần một lần xác nhận gắn với đúng yêu cầu đó. Khi đó, dù email có độc đến đâu, đường đi tới đích cũng bị chặn ở tầng hệ thống. (Cách tổ chức tool call theo lớp sạch sẽ cũng là chủ đề của bài Xây AI agent trong .NET mà không trói nghiệp vụ vào framework AI.)
Lời khuyên anh ước mình biết sớm hơn cũng là câu kết đẹp nhất cho bài này: học hệ thống, đừng học checklist. Hiểu logic nội tại của hệ thống, luồng dữ liệu, quan hệ tin cậy, và lý do một hạn chế tồn tại — những thứ đó giá trị hơn mọi danh sách payload. Với người làm AI agent, bản dịch của câu đó là: hiểu luồng dữ liệu của agent, đừng chỉ vá prompt.
Nguồn tham khảo: How bug bounty sharpens one researcher's security skills — GitHub Blog (nguồn chính, bài phỏng vấn @r31n). GitHub Security Bug Bounty Program — trang chương trình.
