Trang chủ / Tin tức / Tin tổng hợp
TIN TỔNG HỢP

GitHub khoe AI agent mã nguồn mở tìm 24 lỗ hổng Android

Ngày 28/9/2026, GitHub Security Lab trình làng agent AI mã nguồn mở tìm ra 24 lỗ hổng trong app Android. Bài nói rõ cách chạy và giới hạn cần biết.

TopUngDung·29/09/2026·7 phút đọc·5 lượt xem
GitHub khoe AI agent mã nguồn mở tìm 24 lỗ hổng Android

Ngày 28/9/2026, GitHub Security Lab công bố bài viết về GitHub Security Lab Taskflow Agent, bộ khung mã nguồn mở giúp chuyên gia bảo mật đóng gói và chia sẻ các luồng prompt AI dùng để săn lỗ hổng. Cũng trong bài, nhóm cho biết đã dùng các luồng dành riêng cho ứng dụng Android và báo cáo 24 lỗ hổng, trong đó có lỗi cho phép app độc theo dõi vị trí người dùng và chiếm tài khoản.

Đây là tin đáng chú ý với các đội làm app di động Việt Nam. Phần lớn app nội địa đều có ít nhất một tính năng mở ra cho app khác gọi vào: chia sẻ nội dung, mở link sâu, nhận dữ liệu từ trình duyệt. Đúng những chỗ đó là nơi lỗi bảo mật hay nằm, và cũng là nơi một công cụ quét tự động có thể đi nhanh hơn con người.

Có gì mới trong công cụ của GitHub

Theo bài viết ngày 28/9/2026, GitHub Security Lab Taskflow Agent là bộ khung mã nguồn mở để chuyên gia bảo mật tự động hoá, đóng gói và chia sẻ các prompt cùng luồng công việc AI mà họ thấy hiệu quả. Thay vì dùng một luồng quét chung cho mọi loại dự án, tác giả bài viết tạo thêm các luồng chuyên cho Android.

Hai điểm chỉnh chính được nêu trong bài:

  • Một luồng gom và phân loại điểm vào (entry point) của ứng dụng, tách điểm vào của app di động ra khỏi điểm vào của web hay desktop. Nhờ vậy AI hiểu đúng bề mặt tấn công của từng loại dự án.
  • Một luồng phân loại ứng dụng theo danh sách lớp lỗ hổng phổ biến, buộc mô hình phải xét từng lớp lỗ hổng gắn với từng điểm vào, ví dụ nhóm lỗi liên quan tới intent trong Android.

Cách làm là chia việc săn lỗi thành nhiều bước nhỏ và chạy lặp lại. Theo tác giả, cách này giúp AI tìm được cả những lỗi phức tạp mà một lượt chạy duy nhất sẽ bỏ sót.

Kết quả tính đến thời điểm viết bài là 24 lỗ hổng Android đã được tìm và báo cáo, trong đó có vài lỗi nghiêm trọng. Bài viết dẫn hai ví dụ đã công bố. Với OsmAnd, một app bản đồ dùng dữ liệu OpenStreetMap có hơn 10 triệu lượt tải trên Android, lỗi cho phép app độc không cần quyền gì vẫn đổi được cấu hình của OsmAnd, rồi lấy cắp dữ liệu vị trí và lộ trình di chuyển mà người dùng không hề hay biết. Với app Wikipedia cho Android, chuỗi hai lỗi nhỏ trong xử lý link sâu và trong quản lý cookie dẫn tới chiếm tài khoản người dùng.

Cách chạy trên dự án của chính bạn

Bài viết hướng dẫn khá ngắn, ai làm mobile đều theo được:

1. Mở kho taskflow

Truy cập kho seclab-taskflows trên GitHub và khởi động một codespace từ đó.

2. Chờ codespace khởi tạo

Việc này mất vài phút. Đây là bước dễ bị bỏ qua nhất vì tưởng máy bị treo.

3. Chạy lệnh quét

Trong terminal, chạy lệnh run_mobile.sh kèm tên tổ chức và kho của bạn. Với kho cỡ trung bình, quá trình có thể mất một tới hai giờ. Khi xong, công cụ mở trình xem SQLite; bạn vào bảng audit_results và tìm các dòng được đánh dấu ở cột has_vulnerability.

Điều kiện đi kèm cần lưu ý trước khi thử. Bạn cần giấy phép GitHub Copilot, các prompt dùng lượt gọi model trả phí, và một lượt quét có thể gọi công cụ rất nhiều lần nên tốn lượng token đáng kể. Nói cách khác, công cụ là mã nguồn mở nhưng lượt chạy thì không miễn phí.

AI tìm lỗi tốt nhưng chấm mức độ chưa chuẩn

Đây là phần đáng đọc nhất với ai định giao hẳn việc kiểm bảo mật cho AI. Tác giả thẳng thắn nêu: mô hình tìm lỗ hổng tốt, kể cả lỗi logic có tác động lớn, nhưng ước lượng mức độ nghiêm trọng thì yếu. AI hay trả về lỗi chỉ xảy ra trong trạng thái rất hẹp, gần như không gặp ngoài thực tế, và vẫn báo lỗi mức thấp dù đã được yêu cầu bỏ qua.

Kết luận rút ra là mỗi phát hiện vẫn phải qua tay người có hiểu biết về ứng dụng di động. Muốn giảm báo động giả, cần yêu cầu AI viết bản chứng minh khai thác, thậm chí chạy thử với debugger. Làm vậy tốn thêm thời gian và token, nhưng nếu bỏ qua thì danh sách lỗi sẽ đầy cảnh báo vô nghĩa.

Điểm mạnh được ghi nhận là hiểu API. Mô hình nắm khá tốt hàm nào an toàn, hàm nào nguy hiểm ở nhiều ngôn ngữ, kể cả khi không có mã nguồn của ngôn ngữ đó. Nhờ vậy, các bản chứng minh khai thác mà AI đưa ra thường chỉ cần chỉnh vài chỗ là dùng được.

Với đội làm app ở Việt Nam thì sao

Phần lớn đội mobile ở Việt Nam không có người chuyên trách bảo mật. Một lập trình viên thường vừa làm tính năng, vừa sửa lỗi, vừa chịu trách nhiệm kiểm tra trước khi phát hành. Với họ, công cụ này có ích ở chỗ đóng gói sẵn các bước kiểm tra mà một người không chuyên sẽ không nghĩ ra, chẳng hạn soi kỹ các activity được mở ra ngoài hay cách app xử lý link sâu.

Nhưng cần tỉnh táo về chi phí. Một lượt quét tốn thời gian và token, chưa kể khoản giấy phép Copilot. Nếu app nhỏ, nên khoanh vùng quét vào đúng phần nhạy cảm như màn hình nhận dữ liệu từ bên ngoài, thay vì quét toàn bộ mã nguồn. Với đội làm app cho khách, có thể dùng nó như bước rà soát trước khi bàn giao, miễn là đã tính trước thời gian và chi phí.

Một điểm nữa là kết quả quét không thay thế bài kiểm thử cuối. Công cụ trả về danh sách nghi vấn, việc quyết định cái nào là lỗi thật vẫn thuộc về người đọc mã.

So với lựa chọn khác trên site

Nếu bạn đã dùng GitHub để lưu mã, việc thử công cụ này gần như không tốn công thiết lập, vì nó chạy trong codespace ngay trên kho của bạn. Đây là điểm khác so với các bộ quét truyền thống thường phải cài đặt thành một bước riêng trong quy trình. Nếu đội bạn đang ở GitLab, bạn vẫn có thể tải mã nguồn công cụ về và chạy như một bước độc lập, chỉ là không tận dụng được codespace sẵn có.

Với phần viết app Android, công cụ này bổ sung cho Android Studio chứ không thay thế. Android Studio lo việc viết và chạy thử, còn agent lo việc đọc mã và chỉ ra chỗ có thể bị khai thác. Với công cụ hỗ trợ viết mã, GitHub Copilot là thứ bắt buộc phải có để chạy được các luồng quét, nên đây cũng là lý do để cân nhắc gói Copilot nếu bạn định dùng thường xuyên.

Nên làm gì bây giờ

Nếu bạn làm app có xử lý link sâu, chia sẻ dữ liệu giữa các app, hay nhúng trình duyệt trong app, hãy đọc bài gốc để hiểu hai ví dụ lỗi mà GitHub đã công bố. Chúng là mẫu lỗi khá phổ biến ở app Việt Nam, không chỉ ở app nước ngoài. Nếu muốn đi xa hơn, bạn có thể tự chạy bộ luồng quét trên kho mã của mình, nhưng nên chuẩn bị sẵn thời gian, ngân sách token và một người đủ trình để đọc kết quả.

Bài viết nhấn mạnh điều này sẽ còn thay đổi khi mô hình mạnh hơn, nên bạn kiểm tra lại trang chủ và trang khuyến nghị bảo mật của GitHub trước khi quyết định đưa vào quy trình chính thức. Nguồn tham chiếu: bài viết của GitHub Security Lab, và xem thêm trang khuyến nghị lỗ hổng do AI tìm ra. Nếu đội bạn đang dùng GitHub, đây là lúc đưa bước quét bảo mật tự động vào quy trình phát hành app.