Тестування вразливостей безпеки додатків за допомогою великих мовних моделей
Розробник витратив півтори тисячі доларів, перевіряючи, чи можуть LLM-агенти знаходити та експлуатувати вразливості додатків. Вони впоралися з базовими багами, але зазнали невдачі на складних логічних ланцюжках.
Чому це важливо
Ви можете використовувати агентні цикли для швидкого аудиту базових дірок у безпеці, але обов'язково встановлюйте жорсткі ліміти бюджету API, щоб уникнути великих рахунків.
Під час розробки вебдодатків за допомогою таких інструментів, як Cursor або Claude Code, тестування безпеки часто відкладається на потім або довіряється традиційним статичним аналізаторам. Цей аналіз детально розглядає експеримент, у якому вразливий вебдодаток атакувався LLM-агентами для оцінки їхніх можливостей автоматизованого тестування на проникнення. Автор створив різноманітні завдання — від класичних SQL-ін'єкцій до складних логічних обходів, намагаючись з'ясувати, чи можуть агентні фреймворки замінити тестувальників.
Архітектура використовувала різноманітні API-моделі, які координували численні виклики LLM для виконання автономних хакерських завдань. Замість простого промптингу система використовувала агентні цикли, в яких модель могла писати код, виконувати запити до цільових серверів, аналізувати відповіді та динамічно адаптувати свою стратегію. Витративши півтори тисячі доларів, розробник зібрав емпіричні дані про відсоток успіху, вартість виявлення однієї вразливості та критичні вузькі місця.
Під капотом експеримент демонструє чітку межу можливостей сучасних агентів. Стандартні атаки (SQL-ін'єкції, міжсайтовий скриптинг) та застарілі бібліотеки виявлялися швидко, оскільки їхні сигнатури широко представлені в навчальних даних. Однак логічні вразливості, такі як обхід лімітів запитів через стан гонитви або маніпулювання станом сесії, послідовно ставили агентів у глухий кут. Головною проблемою стала фрагментація контексту: зі збільшенням кількості викликів інструментів стан середовища розширювався за межі того, що вікно контексту могло когерентно оцінити, призводячи до повторюваних циклів.
Для розробників, які планують використовувати LLM-агенти для тестування безпеки, це означає, що не варто покладатися на них для комплексного логічного аудиту. Натомість інтегруйте їх безпосередньо у ваші конвеєри безперервної інтеграції (CI/CD), використовуючи вузькоспеціалізовані промпти. Наприклад, створить системні інструкції, які спрямовують агента на аудит одного конкретного файлу контролера на наявність помилок контролю доступу.
Експеримент також показує, що витрати стрімко зростають під час тривалих агентних циклів. Без суворих обмежень на виконання агенти будуть безкінечно пробувати варіації одного і того ж невдалого запиту, марно витрачаючи дорогі токени. Завжди встановлюйте ліміти на максимальну кількість ітерацій та обмежуйте довжину системного промпту.
Хоча LLM-агенти надзвичайно ефективні у виявленні простих синтаксичних і структурних недоліків безпеки, керований людиною аналіз залишається незамінним для виявлення глибоких логічних помилок.
Ключові висновки
- 01Встановлюйте жорсткий ліміт бюджету для агентних циклів безпеки, щоб запобігти безконтрольному зростанню витрат
- 02Повністю ізолюйте тестові бази даних і середовища перед дозволом агентним інструментам виконувати операції запису
- 03Проводьте аудит системних файлів і контролерів окремо, замість сканування всього коду в одному контекстному вікні