Доверять ли коду? Почему самое надежное программное обеспечение подвергается наименьшей проверке.

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

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

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

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

Четыре привычки, которые приносят свои плоды.

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

Охота за вариантами

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

Чтение с использованием фрагментов текста

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

Ручная проверка источников по сравнению со сканерами

Используйте сканеры для поиска закономерностей; полагайтесь на анализ исходного кода для понимания поведения. Автоматизированные инструменты эффективны для выявления известных классов проблем, но гораздо менее эффективны для обнаружения недостатков в бизнес-логике, авторизации или границах доверия. Эти уязвимости часто существуют в разрыве между тем, что делает код, и тем, что задумал его автор. Для их обнаружения часто требуется ручное чтение кода.

Проверка согласованности

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

Здесь нет ничего новаторского. Все эти методы объединяет целенаправленный, терпеливый и осознанный анализ кода — особенно того, который уже был «исправлен» и, следовательно, считается безопасным.

Где искать

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

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

Недавно измененный код

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

Логика авторизации и разрешений

Логику авторизации — кто что может делать, кому и при каких условиях — чрезвычайно сложно смоделировать. Автоматизированные инструменты редко хорошо её понимают, и разработчики могут каждый раз реализовывать её по-разному. Это делает код авторизации частым источником скрытых уязвимостей.

Точки интеграции

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

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

CVE-2026-54358: Полное обнаружение уязвимости.

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

MISP — широко используемая платформа анализа угроз с открытым исходным кодом. Недавнее исправление уязвимости авторизации, CVE-2026-44380, ужесточило границы привилегий, не позволяя администраторам организации с более низкими привилегиями получать доступ к учетным записям администраторов сайтов.

С точки зрения наступательной безопасности, подобное исправление — это скорее зацепка, чем закрытое дело. Оно устанавливает правило о том, кто может действовать от имени учетной записи администратора сайта, что поднимает простой вопрос: соблюдается ли это правило везде, где оно должно соблюдаться?

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

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

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

О проблеме было сообщено координационной группе проекта, и впоследствии она была опубликована как CVE-2026-54358 с оценкой CVSS v4.0 7,5 (высокая). Рабочий эксплойт здесь не предоставляется; в публичном уведомлении содержится информация, необходимая тем, кому она нужна.

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

Другие проекты, использующие этот подход.

Большая часть моих текущих исследований в этой области сосредоточена на уровне, где агенты ИИ взаимодействуют с реальными системами: серверах протокола контекста модели (MCP) и комплектах разработки программного обеспечения (SDK), которые поставщики быстро выпускают. Те же самые привычки сохраняются, и они привели к появлению уязвимостей CVE, признанных поставщиками, в нескольких крупных проектах:

• dbt-mcp от dbt Labs: Сообщается о трех проблемах, включая внедрение аргументов в оболочки инструментов командной строки (CVE-2026-44968, CVSS 6.3) и двух случаях, когда конфиденциальные аргументы инструментов могли попасть в журналы или телеметрию без редактирования (CVE-2026-44969 и CVE-2026-44970).
• Сервер MCP GitHub: проблема путаницы состояний при работе нескольких пользователей в режиме блокировки (CVE-2026-48529), о которой независимо сообщили и которая отмечена в числе обнаруженных проблем другими исследователями.
• SDK MCP для Python от Anthropic: HTTP-транспорт, обрабатывавший запросы сессий без проверки аутентифицированного субъекта (CVE-2026-52869, CVSS 7.1), независимо обнаружен и отмечен автором наряду с другим автором.
• Инструментарий Google MCP Toolbox для баз данных: обход авторизации, при котором в более старых версиях протокола пропускались проверки области действия для каждого инструмента (CVE-2026-11719, CVSS 8.6).
• Сервер MCP компании Contentful: инструменты экспорта и импорта, передающие контролируемый LLM параметр хоста в клиент управления, позволяющие перенаправлять токен доступа сервера на конечную точку, контролируемую злоумышленником (CVE-2026-53957, CVSS 7.7).

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

(Значения CVSS представляют собой опубликованные базовые баллы из соответствующих рекомендаций.)

Составление отчёта — это половина работы.

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

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

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

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

Почему это важно не только для системы отслеживания ошибок

Может показаться заманчивым рассматривать список CVE как набор хитроумных эксплойтов или новых методов. В действительности же многие уязвимости возникают из-за гораздо более обычных ошибок: отсутствие проверки роли, передача ненадежных входных данных без проверки или исправление, которое завершается ошибкой на одной строке. Это те же самые классы уязвимостей, с которыми команды по обеспечению безопасности приложений борются уже десятилетиями.

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

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

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

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

Что проверить в собственном коде

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

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

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

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

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

Применение этих знаний в работе с клиентами

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

Это становится еще более важным, когда организации подключают агентов ИИ к производственным системам. Каждая новая интеграция вводит новые доверительные отношения, новые потоки данных и новые предположения о пути влияния. Ключевой вопрос, который следует себе задать сейчас, заключается не в том, существуют ли эти «швы», а в том, изучал ли их кто-нибудь внимательно. Если на этот вопрос сложно ответить, вы нашли место, с которого можно начать поиски.

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

Чтобы узнать больше об услугах Sophos MDR, нажмите здесь.

В данной статье рассматриваются только результаты исследований, которые уже были обнародованы и задокументированы.

Читать полностью на источнике