GitHub Security Lab نمونهای عملی از استفادهٔ عاملهای هوش مصنوعی در پژوهش امنیتی منتشر کرده است که فراتر از بررسی عمومی کد میرود. این تیم میگوید با GitHub Security Lab Taskflow Agent و مجموعهای از گردشکارهای ممیزی قابل استفادهٔ دوباره، ۲۴ آسیبپذیری در برنامههای Android را پیدا و گزارش کرده است.
این سامانه بهعنوان یک پژوهشگر امنیتی کاملاً خودکار معرفی نشده است. GitHub ممیزی را به گامهای صریح تقسیم میکند، برای هر گام دستورهای ساختیافته به مدل میدهد، بعضی تحلیلها را چند بار اجرا میکند و در پایان از پژوهشگر امنیتی برای اعتبارسنجی نتیجه کمک میگیرد. خود Taskflow Agent یک چارچوب چندعاملی سازگار با MCP و دارای دستور زبان اعلانی YAML است و مخزن SecLab Taskflows نمونههای عملی گردشکار و ابزارهای پشتیبان را در اختیار میگذارد.
اهمیت این تفاوت در این است که تغییر اصلی فقط توانایی مدل زبانی برای خواندن کد نیست. GitHub بخشی از روش کار یک متخصص امنیت را به فرایندی تکرارپذیر تبدیل کرده است که میتوان آن را نسخهبندی، بازبینی و روی مخزنهای دیگر اجرا کرد.
گردشکار، روش ممیزی را صریح میکند
در نمونهٔ Android، کار به وظایف کوچکتر تقسیم میشود. یک وظیفه نقاط ورود مخصوص برنامههای همراه را پیدا میکند و وظیفهٔ دیگر از مدل میخواهد آسیبپذیریهای رایج در Android را در اطراف همان نقاط بررسی کند. مقاله همچنین اجرای تکراری و ترکیب دستورهای محدود و بازتر را توضیح میدهد تا هم خطاهای واضح کمتر از دست بروند و هم مدل فرصت پیدا کند نقصهای منطقی غیرمنتظره را جستوجو کند.
در نتیجه، خود گردشکار به یک دارایی قابل بررسی تبدیل میشود. پژوهشگر میتواند ترتیب وظایف، دستورها و ابزارها را ببیند و لازم نیست مدل را یک جعبهٔ سیاه در نظر بگیرد. مخزن همراه نیز اجرای این فرایند در Codespace یا محیط محلی را ممکن میکند، هرچند GitHub هشدار میدهد که اجرای ممیزی روی پروژههای بزرگ میتواند زمانبر باشد و درخواستهای زیادی به مدل ایجاد کند.
جمعبندی معماری Aipolix این است که کیفیت امنیت عاملمحور فقط به قدرت مدل وابسته نیست. نحوهٔ شکستن مسئله، شواهدی که بین گامها منتقل میشود و سازوکار اعتبارسنجی، بخش بزرگی از کیفیت نتیجهٔ نهایی را تعیین میکند.
GitHub از ۲۴ آسیبپذیری Android گزارش میدهد
GitHub Security Lab در گزارش ۲۸ سپتامبر میگوید تا زمان انتشار، این گردشکارها ۲۴ آسیبپذیری Android را پیدا و گزارش کردهاند. در مقاله نمونههایی دربارهٔ activityهای قابل دسترسی از بیرون برنامه، رفتار WebView و تعامل میان برنامهها آمده است. GitHub میگوید این روش میتواند نقصهای منطقی را نیز پیدا کند و صرفاً به الگوهای ساده محدود نیست.
نکتهٔ عملی این است که روش ممیزی قابل استفادهٔ دوباره است. یک تیم امنیتی میتواند راهبرد بررسی را یک بار در قالب گردشکار ثبت کند، آن را بهبود دهد و سپس روی هدف دیگری به کار ببرد. این با یک درخواست ساده از دستیار برنامهنویسی برای «پیدا کردن آسیبپذیری» تفاوت دارد.
مخزنهای عمومی نیز امکان بررسی پیادهسازی را فراهم میکنند. Taskflow Agent از گردشکارهای تعریفشده با YAML استفاده میکند و میتواند از طریق MCP به ابزارها متصل شود. SecLab Taskflows نیز نمونههایی برای ممیزی و وظایف دیگر پژوهش امنیتی دارد. این موضوع ثابت نمیکند که در هر کدپایهای نتیجهای مشابه به دست میآید، اما یک پیادهسازی واقعی برای ارزیابی در اختیار تیمها قرار میدهد.
بازبینی انسانی همچنان مرز کنترل است
GitHub محدودیتها را صریح بیان میکند. مدلها گاهی مشکلات کماهمیت یا عملاً غیرقابل بهرهبرداری را گزارش میکنند و ممکن است شدت یک آسیبپذیری را اشتباه تخمین بزنند، زیرا رفتار کاهندهٔ خطر را در بخش دیگری از برنامه نمیبینند. در بعضی موارد، ساخت نمونهٔ اثبات مفهوم یا اجرای برنامه زیر ابزار اشکالزدایی برای تشخیص واقعی بودن یافته لازم است.
بنابراین عدد ۲۴ نباید به این معنا تعبیر شود که عامل میتواند جای پژوهشگر امنیتی باتجربه را بگیرد. این نتیجه از خود GitHub Security Lab گزارش شده و در این اجرای Research بهطور مستقل بازتولید نشده است.
محدودیتهای عملی دیگری نیز وجود دارد. GitHub میگوید این گردشکارها میتوانند فراخوانیهای فراوان ابزار و مدل ایجاد کنند، روی مخزنهای بزرگ چند ساعت زمان ببرند و در پیکربندی پیشفرض به دسترسی GitHub Copilot نیاز دارند. برای استفادهٔ پیوسته در تعداد زیادی پروژه، هزینه و ظرفیت اجرا اهمیت پیدا میکند.
نتیجهٔ دقیقتر این است که گردشکارهای ساختیافته میتوانند بخشهایی از پژوهش آسیبپذیری را تکرارپذیرتر و مقیاسپذیرتر کنند، اما تصمیم امنیتی نهایی هنوز به اعتبارسنجی نیاز دارد.
دارایی ماندگار، فرایند تحقیق است
درس مهمتر این پروژه این است که دارایی ماندگار ممکن است خود گردشکار باشد، نه خروجی یک اجرای مدل. گردشکار میتواند ثبت کند که پژوهشگر چگونه دامنهٔ ممیزی را تعیین میکند، به کدام سطح حمله توجه ویژه دارد، چه ابزاری در چه زمانی فراخوانی میشود و چه زمانی شواهد باید دوباره بررسی شوند.
این موضوع سطح تازهای برای مهندسی امنیت برنامه ایجاد میکند. تیمها میتوانند گردشکارهای امنیتی را نسخهبندی کنند، تغییر دستورها و ابزارها را بازبینی کنند، نتیجهٔ مدلهای مختلف را مقایسه کنند و کنترلهای مخصوص سازمان خود را اضافه کنند.
در کنار آن، پرسشهای حاکمیتی تازهای نیز به وجود میآید. گردشکار ممکن است کد منبع را بخواند، ابزار خارجی فراخوانی کند و هزینهٔ قابل توجهی برای استفاده از مدل ایجاد کند. بنابراین مدیریت مجوز ابزارها، داده، اعتبارنامهها و منشأ هر یافته ضروری است. مخزن GitHub نیز هشدار میدهد که تصویر کانتینری عامل فقط برای استقرار راحتتر است و نباید مرز امنیتی محسوب شود.
جمعبندی Aipolix این است که اهمیت این کار در «قابل برنامهریزی شدن» بخشی از روش پژوهش امنیتی است. مدل همچنان مهم است، اما نوآوری قابل انتقالتر، ترکیب تقسیم صریح وظایف، استفاده از ابزار، منطق ممیزی قابل استفادهٔ دوباره و اعتبارسنجی انسانی است.