А как же check-bitrix и quick-check? Последний допустим удалена оригинальная репа, но golang бинарь или даже исходники у многих спецов остались (жаль у меня не осталось)
Мне вот не хватило eval метрик и каких-то чётких границ бенчмарка/тестирования. Результат оценивался эмперически и на глаз, что очень не точно. Минимальной хорошей праткикой является написать N количество CTF тасок разной сложности, разного стека, с разными уязвимостям и оформлением веба, чтобы у агента был каждый раз разный контекст - это у вас было. Но перед этим стоило обозначить какие количественные и качественные метрики мы берём за основу. А ещё нужен ground of truth, т.е. с какими финальными данными мы будем сравнивать результаты работы агента. Без этого тестировать рандомную связку из llm + harness + skills - имеет мало смысла, т.к. кроме как сказать: "ну что-то нам (или не) нравится результат" не выйдет.
ну и модель Owl Alpha довольно слабая. Понятно, что хотелось провести ресерч дешевле/бесплатно, но тогда и не стоит ожидать крутых результатов. Хотите чтобы агент работал автономно, не терялся после 10 автокомпактов, вам подойдут только opus 4.(6/7/8) high effort или gpt-5.5 high effort. И лучше их использовать с их родным harness, с другим точно лучше работать не будут. Если хочется подешевле, то берите GLM 5.1/Minimax M3/Kimi K2.6. Ещё дешевле для задач именно black box тестирования опускаться трудно, т.к. уже приходится допиливать harness под модель конкретную и в нексколько раз (а может и десяток раз) перепромпчивать её, чтобы понять как её нормально посадить на стул.
Я своими глазами скилл не читал, но судя даже по тому как он оценивает баги, явно его писал или генерировал человек не занимающийся пентестами или бб. По хорошему у SKILL.md должен рядом лежать REFERENCE.md, где будет четко и ясно объяснена матрица оценки критичности уязвимости по техническому и бизнес импакту, иначе агент может и отсутствие security headers расценивать как крит придумывая небылицы про якобы опасность. А чем слабее модель, тем выше шанс этого. Фронтир модели обычно таким не страдают.
Не знаю было не понятно в статье, но я ровно про тоже сказал. Что говорить ата-та-та агенту бессмысленно, т.к. он даже не уровне контексте не может отличить в большинстве случае атака это или данные специфичные. Поэтому и была речь, что всё что окружает агента или даже просто LLM должно быть секурно настроено.
да, согласен с вами) Но мне допустим сложно было бы к такому прийти на собственном опыте, т.к. я не работаю в AI компании или каком-то бигтехе. Так что довольствуюсь малым и извлекаю максимум пользы из чужого опыта)
Да, мысль у вас верная. В датасет для обучения offensive модели стоит добавлять не только команды и примеры эксплуатации, реакции системы. Но и примеры, когда система может пытаться взломать в обратную сторону. Причем данных нужно много, потому что вариативность атак на AI агентов около бесконечная. И если слишком зашугать агента, то он может параноить слишком сильно, на что будут уходить лишние токены и сама атака будет стоить дороже, даже если атакующего никто не атакует. А сделать атаку дороже - всегда цель защиты, ведь на 100% ничего защитить невозможно)
Годная статья, спасибо! Очень жду продолжения)
Как будто решение не очень сложное получилось. Но респект тебе за проделенную работу и качественную статью!
спасибо!
А как же check-bitrix и quick-check? Последний допустим удалена оригинальная репа, но golang бинарь или даже исходники у многих спецов остались (жаль у меня не осталось)
Годно!
Вероятно у тебя просто на CPU gemma nano инференситься
Годный ресерч, я тоже хостю 1 ханипот под анализ как сканят и атакуют LLM эндпоинты. Думаю тоже выложу аналитику как дойдут руки
Мега плюсую под каждой мыслей автора!
Получается дистислируем друг на друге)
Спасибо за подметили, постараюсь следующие текста публиковать лучше и "чище" :)
<форточку открыть>
Мне вот не хватило eval метрик и каких-то чётких границ бенчмарка/тестирования. Результат оценивался эмперически и на глаз, что очень не точно. Минимальной хорошей праткикой является написать N количество CTF тасок разной сложности, разного стека, с разными уязвимостям и оформлением веба, чтобы у агента был каждый раз разный контекст - это у вас было. Но перед этим стоило обозначить какие количественные и качественные метрики мы берём за основу. А ещё нужен ground of truth, т.е. с какими финальными данными мы будем сравнивать результаты работы агента. Без этого тестировать рандомную связку из llm + harness + skills - имеет мало смысла, т.к. кроме как сказать: "ну что-то нам (или не) нравится результат" не выйдет.
ну и модель Owl Alpha довольно слабая. Понятно, что хотелось провести ресерч дешевле/бесплатно, но тогда и не стоит ожидать крутых результатов. Хотите чтобы агент работал автономно, не терялся после 10 автокомпактов, вам подойдут только opus 4.(6/7/8) high effort или gpt-5.5 high effort. И лучше их использовать с их родным harness, с другим точно лучше работать не будут. Если хочется подешевле, то берите GLM 5.1/Minimax M3/Kimi K2.6. Ещё дешевле для задач именно black box тестирования опускаться трудно, т.к. уже приходится допиливать harness под модель конкретную и в нексколько раз (а может и десяток раз) перепромпчивать её, чтобы понять как её нормально посадить на стул.
Я своими глазами скилл не читал, но судя даже по тому как он оценивает баги, явно его писал или генерировал человек не занимающийся пентестами или бб. По хорошему у SKILL.md должен рядом лежать REFERENCE.md, где будет четко и ясно объяснена матрица оценки критичности уязвимости по техническому и бизнес импакту, иначе агент может и отсутствие security headers расценивать как крит придумывая небылицы про якобы опасность. А чем слабее модель, тем выше шанс этого. Фронтир модели обычно таким не страдают.
<форточку закрыть>
многочисленные?) перепроверьте.
Большое спасибо за комментарий! Буду стараться писать ещё. Удачи вам в вашем нелёгком деле)
Не знаю было не понятно в статье, но я ровно про тоже сказал. Что говорить ата-та-та агенту бессмысленно, т.к. он даже не уровне контексте не может отличить в большинстве случае атака это или данные специфичные. Поэтому и была речь, что всё что окружает агента или даже просто LLM должно быть секурно настроено.
либо нужно прикрутить отдельные метрики к агентам и если они резко возврастают, то сразу алерт всем отвественным людям.
Хорошо подмечено)
С одной стороны комментарий по дело, но AI паттерн "Это не ..., это ... ". Режет глаз)
да, согласен с вами)
Но мне допустим сложно было бы к такому прийти на собственном опыте, т.к. я не работаю в AI компании или каком-то бигтехе. Так что довольствуюсь малым и извлекаю максимум пользы из чужого опыта)
Да, мысль у вас верная. В датасет для обучения offensive модели стоит добавлять не только команды и примеры эксплуатации, реакции системы. Но и примеры, когда система может пытаться взломать в обратную сторону. Причем данных нужно много, потому что вариативность атак на AI агентов около бесконечная. И если слишком зашугать агента, то он может параноить слишком сильно, на что будут уходить лишние токены и сама атака будет стоить дороже, даже если атакующего никто не атакует. А сделать атаку дороже - всегда цель защиты, ведь на 100% ничего защитить невозможно)
Круто, что вы решили делать по уму с помощью ML, а не в лоб через LLM!
Отличный подкаст и саммари по нему!