Журнал "Information Security/ Информационная безопасность" #1, 2026

проверка. Меняется не цель, а способ работы с объемом. Когда контрактов и их связей становится слишком много, часть задач проще автоматизировать, чем разбирать вручную. Речь прежде всего о первичном анализе и поиске повторяющихся паттернов. В основе таких систем – обучающие выборки. Используются как уязвимые контракты, уже приведшие к инциден- там, так и проверенный код из библиотек вроде OpenZeppelin. К ним добавляются базы известных уязвимостей и резуль- таты исследований. За счет этого модель видит не только ошибки, но и нормаль- ные реализации, с которыми можно сравнивать. Сам анализ начинается со статиче- ского разбора кода, но дальше появляют- ся отличия. Вместо набора фиксирован- ных правил система сопоставляет фраг- менты кода с уже известными сцена- риями и ищет комбинации условий, кото- рые могут привести к уязвимости. Следующий уровень – перебор состоя- ний. За счет символьного выполнения проверяются разные варианты поведе- ния контракта без подстановки конкрет- ных значений. Это позволяет дойти до тех веток логики, которые обычными тестами не покрываются. В результате появляются сценарии, которые вручную пришлось бы специально моделировать. Поверх этого добавляется слой машин- ного обучения, который анализирует уже найденные результаты. Он не столь- ко ищет уязвимости, сколько помогает отделить реальные проблемы от шумо- вых срабатываний и расставить приори- теты. В некоторых случаях система может предложить и сам сценарий экс- плуатации – не просто указать на ошиб- ку, а показать, как она используется на практике. Иногда на этом не останавливаются. Отдельные инструменты пытаются вос- произвести атаку и сгенерировать PoC- эксплойт – минимальный сценарий, под- тверждающий уязвимость. Это сразу переводит результат из категории "подо- зрение" в категорию "доказанный риск". Дальше результаты проходят допол- нительную проверку через симуляции или формальную верификацию. И уже после этого формируется отчет: список проблем, их критичность, описание сце- нариев и рекомендации. Но на этом работа не заканчивается. Часть находок требует ручной проверки – особенно там, где затронута бизнес- логика или сложные зависимости. ИИ может указать на проблему, но не всегда корректно оценивает ее последствия в реальной модели протокола. Но все же новые типы атак, экономи- ческие сценарии, взаимодействие с внешними протоколами по-прежнему требуют ручного разбора. Поэтому ИИ встраивается в процесс как инструмент раннего обнаружения и приоритизации, но не как замена эксперта. Эксперимент с ИИ-агентами Компания Anthropic провела серию тестов, в которых ИИ-агенты искали и эксплуатировали уязвимости в смарт- контрактах. Речь шла не о теоретическом анализе, а о попытке воспроизвести атаку в среде, имитирующей блокчейн. Реальные средства не использовались, но сценарии были максимально прибли- жены к рабочим. В эксперименте участвовало 10 моде- лей, включая Opus, Sonnet, GPT-5 и DeepSeek. Их проверяли на контрактах с уже известными уязвимостями – всего 405 экземпляров, развернутых в 2020– 2025 гг. в сетях Ethereum, BNB Smart Chain и Base. В 207 случаях модели смогли довести атаку до результата (это 51,11%). В пересчете на деньги потен- циальный ущерб составил бы около $550 млн. Отдельно проверили более свежие контракты – 34 проекта, запущенные после 1 марта 2025 г., уже после обнов- ления моделей. Здесь доля успешных атак оказалась выше: 19 из 34, то есть 55,8%. Оценка ущерба – $4,6 млн. В отчете эти значения прямо рассмат- риваются как нижняя граница: речь идет только о том, что модели смогли вос- произвести в рамках теста. Есть и обратный пример. Две модели проанализировали 2849 контрактов, в которых на момент проверки ранее не выявлялись уязвимости. Были най- дены две уязвимости с потенциальным ущербом около $3,7 тыс. Хорошая иллюстрация тезиса, что ИИ пока лучше работает по известным или близким по структуре сценариям, чем по полностью новым. Разброс результатов между моделями тоже заметен. В одном и том же сцена- рии GPT-5 смог бы вывести до $1,12 млн из протокола, тогда как Opus – до $3,5 млн. Речь идет о потенциальном объеме средств, доступных через най- денную уязвимость. Разница не только в нахождении уязвимости, но и в том, как именно строится эксплуатация. При этом динамика достаточно быстрая. По оценкам исследователей, доходность тестовых атак за послед- ний год удваивалась примерно каждые 1,3 месяца. Речь не про качество модели в целом, а про конкретную способность находить и реализовывать уязвимости. Практический вывод здесь не в том, что ИИ может взламывать (это само собой разумеется). Важнее другое – стоимость такого поиска снижается. Про- верка контрактов становится задачей, которую можно масштабировать, а не разбирать вручную по одному кейсу. А значит по мере удешевления таких инструментов злоумышленники будут использовать их для перебора любых контрактов, где есть доступ к ликвидно- сти. Сложность кода перестает быть барьером. При этом сами исследователи делают зеркальный вывод. Те же агенты, кото- рые находят и эксплуатируют уязвимости, могут использоваться и для их устране- ния. Вопрос не в инструменте, а в том, на какой стороне он применяется. Ограничения и вызовы При всех возможностях ИИ у него остаются вполне практические ограниче- ния. Одно из них – объем контекста. Даже при работе с длинными входными данными модель не всегда может охва- тить весь проект целиком: часть логики оказывается за пределами анализа. В случае сложных протоколов с десят- ками взаимосвязанных контрактов это начинает влиять на результат – уязви- мость может находиться не в одном файле, а в их комбинации. Вторая проблема – зависимость от обучающих данных. Модели хорошо находят то, что уже встречалось: извест- ные паттерны, типовые ошибки, повто- ряющиеся конструкции. Но при попытке выйти за пределы этих сценариев точ- ность падает. Есть и вопрос прозрачности. В ряде случаев сложно понять, почему модель посчитала тот или иной участок кода уязвимым или, наоборот, безопасным. Это затрудняет валидацию результатов и делает аудит менее воспроизводимым – особенно если речь идет о критичных решениях. Есть и концептуальное ограничение – бизнес-логика. ИИ может разобрать код, но не всегда корректно интерпретирует, что именно хотел реализовать разра- ботчик и как это должно работать в реальной экономике протокола. Ошиб- ки в механике начисления, управлении ликвидностью или взаимодействии с дру- гими сервисами часто лежат вне чисто технического анализа. Поэтому на практике ИИ не заменяет аудитора, а, как и в большинстве других сфер, только меняет распределение работы. Он берет на себя перебор, поиск и первичную фильтрацию, а человеку остается проверка логики, оценка рисков и разбор нетиповых сценариев. Нагрузка на аудит будет только расти. Количество смарт-контрактов увеличи- вается, появляются новые сервисы, уси- ливается связность между протоколами. В ближайшие годы к этому добавятся и регулируемые инфраструктуры – в том числе локальные биржи и обменники. Увы, разрыв между возможностями атаки и защиты будет увеличиваться. ИИ позволяет быстрее находить и про- верять уязвимости, и этот инструмент используется с обеих сторон. И вопрос уже не в том, использовать ли ИИ в ауди- те, а в том, кто успеет встроить его в процесс раньше. l • 59 КРИПТОГРАФИЯ www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru