Как избежать уязвимости: безопасная разработка в эпоху ИИ

Откуда берутся новые уязвимости

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

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

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

Например, недавнее исследование показало, что часть моделей на Hugging Face имеет ряд критических проблем безопасности. Внутри pickle-файлов были обнаружены бэкдоры, которые позволяют получить удалённый доступ к серверу, поднять reverse shell и так далее. В большинстве случаев такие модели никто не проверяет перед использованием.

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

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

Автоматизация поиска багов с помощью ИИ

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

• инструменты анализа open-source ищут проблемы в библиотеках с открытым исходным кодом;
• инструменты статического анализа обнаруживают уязвимости в написанном исходном коде;
• инструменты динамического и интерактивного анализа (DAST, IAST) выявляют проблемы в работающих приложениях
• и другие.

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

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

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

Как избежать ошибок при внедрении ИИ

В своей практике я использовал ИИ для написания кода нового проекта, где 90% было сгенерировано под моим контролем, по моим задачам и идеям. Несмотря на это, ответственность за результат несу я как специалист, который предоставляет это решение в публичный доступ.

Избежать самых банальных ошибок при внедрении ИИ для автоматизации помогут два базовых совета:

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

Часто разработчики не проверяют, от кого пришёл запрос к приложению, а также его содержимое. Это касается как интентов в Android, так и обработки различных ссылок, deep links, URL-схем в iOS. Однако, когда мы открываем или обращаемся к какому-то ресурсу без должного контроля, это может привести к катастрофическим последствиям, особенно в эпоху глобального распространения ИИ.

Во фразе «процесс безопасной разработки» ключевое слово — «процесс», а не «инструмент». Если вы выстроили работу на open-source решениях или собственных скриптах, заменить один инструмент на другой очень просто. А вот если такого процесса нет, то даже самые продвинутые ИИ-агенты положения дел не изменят.

Какие технические средства защиты эффективны при работе с ИИ

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

Во-вторых, различные guardrails и AI firewall, защищающие от промпт-инъекций, джеилбрейк-атак и других техник, которые позволяют обойти ограничения через контент и контекст в агентах. Суть некоторых техник в том, что иногда веса модели, стремящиеся выполнить задачу, перевешивают внутренние цензоры. То, что модель не сделала бы при обычном запросе, она выполнит, если поставить её в условия следования определённому формату, шагам или выполнения конкретной задачи, а не простого ответа на вопрос.

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

Безопасность: критерии и регуляторика

Главный показатель наличия безопасной разработки и процессов — это деньги. То есть, объём средств, которые бизнес потеряет, если не устранить уязвимость. Мы инвестируем в безопасность, и метрика ROI показывает, насколько это окупается.

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

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