Слезы ментейнера или awesome-ai-security-tools после ёPRSTCON

В мае на ёPRSTCON мы договорились собрать инструменты кибербезопасности на базе ИИ и средства защиты самих моделей и агентов. Неожиданно идея “стрельнула”, в репозиторий пришёл 231 запрос на изменение (PR) от 209 авторов. Пришлось завести список кандидатов, разбираться, какая часть каждого продукта действительно открыта, и отвечать на предложения запустить чужие проверки в нашем GitHub.

За полгода поддержки awesome-ai-security-tools накопились мейнтейнерские истории и данные о том, какие инструменты появляются и растут. Спешу поделиться.

Надо сделать записнушку

26 мая прошёл ёPRSTCON. Среди прочего обсуждали автоматический разбор находок сканеров, применение языковых моделей в кибербезопасности, защиту агентов и безопасную разработку в агентной среде. После таких разговоров обычно остаются десятки ссылок на слайдах и в разных чатах. В этот раз договорились собрать их в репозиторий.

27 мая появился первый коммит. В основном списке было 99 записей и ещё 11 ссылок на тематические подборки. 2 июня представил список на Хабре как продолжение ёPRSTCON.

В списке сразу выделились два направления. В одном ИИ помогает искать уязвимости, разбирать предупреждения систем защиты, исследовать исполняемые файлы и собирать сведения об угрозах. В другом инструменты защищают модели, приложения и агентов от инъекций, утечек и нежелательных действий. По мере роста списка внутри каждого направления появились отдельные категории.

Звёздный твит

В июле @KanikaBK написал:

THIS IS COOL! Someone just open-sourced 300+ AI security tools and every CISO is about to panic.

По моим ощущениям, после этого поста в репе со списком стало заметно шумнее. Подборку публичных проектов пересказывали как внезапно открытый арсенал, от которого должны запаниковать все директора по информационной безопасности. Возможно, и должны, если раньше не сталкивались с тем, как агенты меняют кибербез.

Случился “звёздопад” и 26 июля список занял десятое место в дневном рейтинге Python-проектов Trendshift. В сентябре пришла ещё одна волна внимания: 23 сентября я отмечал в канале преодоление отметки в 1 500 звёзд.

Очередь заявок

С ростом известности увеличилась очередь заявок. К 14 ноября из 231 PR мы приняли 157, закрыли без включения изменений 65; девять оставались открытыми. В принятых заявках были и пополнения списка кандидатов, и исправления метаданных.

За каждой заявкой приходится проверять исходный репозиторий, переименования проектов, форки, апстримы и лицензии. Иногда заявленный сканер оказывается набором инструкций для агента, а инструмент с обещанием локальной работы отправляет все исходники внешнему поставщику модели. Такие подробности выясняются при чтении кода.

Нейрослоп с обеих сторон

Стали регулярно приходить заявки с похожими приметами: вчера созданный репозиторий, один большой коммит, внушительный README и громкие обещания. Знакомый паттерн? Да, вторжение роботов начинается с GitHub.

Я тоже приложил к этому руку. Когда я прогонял десятки открытых проектов через rust-in-peace, некоторые мейнтейнеры тоже называли это нейрослопом. А некоторые принимали PR и благодарили как топового контрибьютора Ginux.

Первый коммит иногда содержит вчерашний эксперимент, а иногда целый серьезный проект, прежде развивавшийся в закрытом репозитории. По возрасту репозитория и гладкости README легко ошибиться в обе стороны. Отказывать по формальному признаку мне не хотелось.

Я принял участие агентов как данность: они создают проекты, пишут документацию, приносят заявки. Значит, пусть помогают и разбирать. В «Манифесте созидателя» я писал о том, как удешевление кода повышает значение отбора, доверия и доказательств практической пользы. С собственным списком пришлось проверять эти вангования на практике.

С агентами удалось подробнее читать реализацию: прослеживать передачу данных, разбирать обработку ошибок, сверять обещания с кодом. На такую проверку каждой заявки в одиночку у меня бы не хватило времени.

Как проверяем кандидатов

Проверка начинается с нескольких вопросов. Что устанавливает пользователь и где происходит анализ? Какие данные уходят наружу? Нужны ли платная учётная запись и API-ключ? Что случится, если модель недоступна? Есть ли другой интерфейс, через который можно обойти контроль? Проверяют ли тесты сам защитный механизм или только его взаимодействие с моком? Вы же знаете, как агенты любят выдавать желаемое за реализованное.

На моках мы все немного Терминаторы.

Особенно внимательно читаем обещания защиты журналов от подмены, работы без сети и принудительного применения правил. Ищем в коде, как это устроено, и отделяем результат проверки от обещаний автора. Сейчас внешних кандидатов изучаем без запуска их кода, установщиков и сценариев автоматизации на рабочей машине.

Статическая проверка позволяет разобраться в устройстве инструмента. Для оценки эффективности детектора и поиска обходов нужны отдельные испытания. Их я провожу для инструментов, которые меня заинтересовали. Так, по результатам разбора Anthropic defending-code-reference-harness родился rust-in-peace. В конце концов, это же «записнушка», чтобы интересные тулы были под рукой, когда возникнет идея «ченить закодировать».

Решение всё равно принимаю я. Проверяющий агент тоже ошибается: пару раз мне указывали на некорректные формулировки или неподходящие тулы в списке. Поэтому завёл правило периодически «просеивать» весь список строчка за строчкой.

Принимаем плохо оформленные PR

Для полезных кандидатов я стал предлагать вариант: поправьте сами или примем PR, затем сами поправим формулировку. Неправильную категорию, рекламное описание или ошибку в работе с генератором легко исправить, если сам инструмент хорош. Автору не обязательно глубоко разбираться в формате нашего JSON.

Мне важно, чтобы авторы продолжали участвовать, приносить интересное. Поэтому по возможности мы принимаем исходный PR с сохранением авторства, затем вносим свои правки. Если переносили запись самостоятельно, могли указать соавтора. С агентом на эти правки уходит немного времени.

Перед принятием всё равно проверяем изменения в репозитории, особенно в автоматизации CI. Решение о включении или не включении инструмента принимаем отдельно и объясняем автору.

Для содержательных, но слишком молодых проектов завели WATCHLIST.md, список кандидатов с замечаниями для повторной проверки. 4 августа я уже писал об этой практике. Так можно сохранить находку и дать ей время развиться, сохранив более строгий отбор для основного списка.

На текущем срезе в списке кандидатов 276 GitHub-репозиториев. Мы периодически проверяем их развитие, переезды и новые свидетельства использования. Подросшие проекты переносим в основной список, заброшенные или потерявшие смысл убираем. О переносе стараемся написать в исходный PR: автору приятно узнать, что его работу не забыли.

Длинные комментарии оказались полезны

На конкретный вопрос автору проще ответить. Несколько таких обсуждений привели к правкам и повторным заявкам. Иногда исправляли и сам проект. Вот ответы авторов с описанием изменений: раз, два, три.

Это был неожиданный и приятный бонус, что авторы (и их агенты) читают обратную связь. Особенно агенты. Вежливые такие, здороваются всегда.

Безопасность самого ревью

При проверке агент читает чужие README, комментарии и примеры конфигурации. Среди них могут оказаться указания выполнить команду, изменить сценарий CI, загрузить файл или передать данные. Возникает риск, что агент выполнит их как часть задания. Сильно заморачиваться с песочницей не хотелось (хотя надо уже).

Поэтому чужой текст мы рассматриваем как недоверенные данные. Команды из INSTALL.md и предложения «просто проверить этот Action» требуют отдельного решения о запуске. Оказалось - не зря.

После включения Lumi Eggcracker в список кандидатов нам предложили в PR #69 добавить в CI проверку синтетического отчёта о запуске, названного receipt. Пример отчёта, схему и программу проверки подготовил сам автор проекта.

Каталогу эта интеграция была не нужна: проверка устанавливала лишь соответствие авторского примера авторской схеме. Оснований объявлять это попыткой внедрения бэкдора или приписывать автору злой умысел у нас нет, но неизвестно как бы повел себя агент в такой ситуации без дополнительных ограничений.

Что на радарах?

Заодно накопились данные: какие проекты появляются и к каким направлениям тянутся авторы.

Для анализа основного списка на 14 ноября мы взяли 377 GitHub-репозиториев с сопоставимыми датами создания. Здесь есть инструменты, исследовательский код, бенчмарки и стандарты; тематические подборки и модели, опубликованные только на Hugging Face, в эту выборку не входят. Дата создания публичного репозитория не всегда совпадает с началом разработки.

Из этих 377 репозиториев 155 созданы в 2026 году. Их доля сильно различается по категориям.

По доле новых репозиториев «бумкнул» агентский SAST. Это хорошо совпадает с моим опытом применения моделей для анализа кода. В своём докладе на ZeroNights я рассказывал, как при интеграции SAST в rust-in-peace агенты пытались опровергнуть фолзы Semgrep и по ходу находили реальные ошибки. Но сама таблица показывает, где появляются проекты; качество методов нужно сравнивать на общих задачах.

Много новых проектов ограничивают действия агентов: проверяют инструкции и MCP-компоненты, управляют разрешениями, изолируют код, следят за исходящими соединениями и доступом к секретам. Под общим названием «защита от инъекций» скрываются очень разные задачи. Этот переход к контролю поведения я подробнее разбирал в Agentic SAMM: безопасная разработка, когда разработчик больше не только человек.

Что пробуют в watchlist

Интересно посмотреть, чем занимается та «молодая шпана, что сотрёт нас с лица земли». В срезе WATCHLIST на 14 ноября 276 GitHub-репозиториев. Из 269 с сопоставимой датой создания 235, или 87%, появились в 2026 году. Медиана среди 270 доступных репозиториев составляет 14 звёзд.

Для диаграммы разложили кандидатов по основной задаче. Каждый репозиторий посчитан один раз.

«Кто разрешил это делать?» В CTRLRun подтверждение привязано к конкретному действию, в SpendShield ограничивают траты. На ревью первым делом смотрим, сможет ли агент обойти проверку через другой интерфейс. А то иногда ему заодно выдают инструмент для одобрения собственных расходов.

«Что я устанавливаю вместе с этим skill?» clonepeek перечисляет места, из которых репозиторий может запускать код; mcpsum фиксирует определения MCP и замечает изменения. Мне в таких проектах интереснее список проверок и пропусков, чем большая буква A+ в отчёте.

«Что агент вообще сделал?» memory-blackbox отслеживает происхождение записей в памяти, aaesverify проверяет целостность и подписи отчётов. Тут легко увлечься криптографией: подпись может быть безупречной, а сама запись ошибочной. SHA-256 от галлюцинации тоже имеет правильную длину.

«Как дать доступ без ключа в промпте?» Keyrelay передаёт секрет конкретной команде, browser-bridge отделяет ввод учётных данных от управляемой агентом вкладки. Проверяем, кому всё-таки достанется секрет и куда его можно отправить.

Возраст проектов и рост интереса

На следующей диаграмме по горизонтали отложена доля репозиториев категории, созданных в 2026 году. По вертикали показан медианный чистый прирост звёзд в день между снимками 5 октября и 14 ноября. Площадь пузырька соответствует числу проектов в категории.

Для прироста сравниваются одни и те же 353 репозитория, присутствующие в обоих срезах основного списка. На диаграмме оставлены категории как минимум с пятью проектами, для которых удалось сопоставить число звёзд в обоих срезах.

Подпись n обозначает число проектов в текущей выборке категории, от которого зависит размер пузырька. Подпись matched показывает, сколько из них вошло в сравнение прироста звёзд.

Самый высокий медианный прирост у агентов для пентеста: около 1,89 звезды на проект в день. Затем идут статический анализ и проверка кода с 1,07 и обратная разработка с 0,83. У безопасности агентов медиана около 0,38; это самая большая категория с высокой долей новых проектов.

Получается, пентест и обратная разработка набирают внимание на уже известных проектах, безопасность агентов пополняется новыми, а в проверке кода заметно и то и другое.

Вот такие “магические пузырьки” ёPRTа можно легко собирать для анализа продуктовых ниш.

Что осталось после полугода

Я регулярно заглядываю в список посмотреть, что интересного появилось. Из одних проектов вырастают свои разработки, другие подкидывают идеи для существующих.

С агентами удалось добраться до кода гораздо большего числа кандидатов и разбирать их детальнее. Авторы отвечали на замечания, правили проекты и возвращались. Так что польза от списка оказалась и по ту сторону PR.

Начинали с договорённости собрать ссылки после ёPRSTCON. Теперь к списку прилагаются сотни обсуждений, очередь кандидатов и регулярные возвращения к уже рассмотренным проектам.

Пользуйтесь списком, присылайте свои проекты, исправляйте наши ошибки и возвращайтесь с обновлениями. Перед подачей прочитайте CONTRIBUTING или дайте его своему агенту. Наблюдения и новости проекта публикую в «АйКыне».