GitHub資安實驗室（Security Lab）研究員Kevin Stubbings於9月28日發文，說明團隊如何用自家開源的AI資安代理稽核Android應用程式，前後找出並回報了24個漏洞。用到的工具叫seclab-taskflow-agent，核心是一組以YAML撰寫的「任務流程」，一步步引導大型語言模型去讀程式碼、分類進入點、找問題、寫驗證程式。
這套任務流程先前已用於通用程式碼稽核，這次特別針對行動裝置做了客製化，新增了gather_mobile_entry_point_info.yaml與classify_application_local.yaml兩個檔案，分別負責整理應用程式的進入點與替漏洞歸類。
怎麼跑起來
根據文章的流程，使用者在GitHub Codespaces裡執行一支稽核腳本，等環境初始化幾分鐘後，就讓代理自己跑。一個中等規模的儲存庫，大約要花一到兩小時。結果會寫進SQLite資料庫，打開audit_results資料表，篩出has_vulnerability欄位打勾的紀錄，就是代理判定有問題的地方。
任務流程涵蓋的漏洞類型圍繞著Android幾個老問題：Intent相關的混淆代理人（confused deputy）與不安全廣播、WebView裡的跨應用程式指令碼、暴露給網頁的JavaScript橋接、路徑穿越、深層連結解析邏輯錯誤，以及Cookie和登入權杖外洩。文章指出，分類清單共涵蓋12個CWE類別。
兩個詳細案例
OsmAnd，一款下載量超過1000萬次的開源地圖導航應用程式。代理在它的設定匯入流程裡找到3個問題，其中一個可以讓同一支手機上的惡意應用程式，在不申請任何權限的情況下，透過Intent附加參數靜默匯入設定，進而追蹤使用者的位置與路線。
維基百科的Android客戶端。代理發現深層連結的解析邏輯有漏洞，攻擊者可以構造一個惡意連結，把使用者導向偽造頁面，再藉此取得Cookie，最終接管帳號，拿到長期有效的登入權杖。
Stubbings在文中寫道，團隊沒想到模型對各種語言裡資安相關API的行為理解得這麼準，即便沒有提供該語言的原始碼；代理寫出的概念驗證程式碼，也只需要很少改動就能實際運作。
"LLMs are good at finding vulnerabilities but struggle at estimating severity."
大型語言模型擅長找漏洞，但不擅長判斷嚴重程度。
它做不到的部分
文章對局限寫得很直白。模型經常回報低風險問題，即便提示詞裡明確要求不要回報；遇到已有緩解措施的漏洞，它判斷不準實際危害；複雜的資料流優先順序問題，它辨識不出來；想拿到可靠的概念驗證，往往要多跑幾次，有時還得搭配偵錯工具或追加提示。結論是每項發現都得由熟悉行動裝置資安的研究員人工複核。
成本方面，執行需要GitHub Copilot授權，走的是進階模型請求額度。文章提醒大型儲存庫會產生大量工具呼叫，token消耗不低，具體用的是哪款模型並未說明。
對中國開發者而言
任務流程和腳本都在GitHub上開源，中國團隊拿來改一改就能稽核自家Android應用程式，門檻在於Copilot授權與對海外模型的依賴。任務流程本身是用YAML寫成的提示詞與步驟編排，換成中國國產模型理論上可行，實際效果如何，目前沒有公開的對照數據。
Android生態的碎片化，讓這類工具在中國市場的用處更大一些。各家手機廠商的應用程式商店、小程式容器、超級App裡的WebView與JavaScript橋接，正好落在這份清單涵蓋的漏洞類型裡。GitHub下一步計畫把任務流程擴展到網頁與桌面應用程式，並開放社群貢獻。
參考來源：GitHub官方部落格、CocoLoop、GitHub Security Lab開源儲存庫；漏洞數量、OsmAnd下載量與單次稽核耗時均以GitHub部落格所列為準。