Политика открытых дверей: какие угрозы таит в себе применение opensource-кода
В поисках ахиллесовой пяты
89% российских компаний пользуются открытым исходным кодом из популярных библиотек (в своей инфраструктуре, в базах данных, операционных системах, приложениях и т.д.), следует из данных опроса об использовании такого кода (open source software, OSS) среди 128 российских компаний, включая крупный и средний бизнес из разных отраслей, который провели в «Спикател» (есть в распоряжении Forbes).
Такое широкое распространение открытого кода соответствует мировым трендам, указывают авторы опроса. К примеру, специалисты разработчика софта Black Duck в своем недавнем ежегодном исследовании OSSRA (Open Source Security and Risk Analysis) по итогам 2025 года проанализировали 965 коммерческих кодовых баз в 16 отраслях и пришли к выводу, что 97% из них содержат открытый код. В среднем уже 70% всей кодовой базы — это открытый код (против 35% в 2015 году). По данным отчета Black Duck, 86% анализируемых кодовых баз содержали уязвимости в компонентах с открытым исходным кодом. 81% из них имели уязвимости, которые представляют высокий или критический риск для безопасности.
Однако рост использования открытого кода несет в себе угрозы: так, в начале февраля стало известно, что новейшая ИИ-модель от Anthropic Claude Opus 4.6 обнаружила 500 ранее неизвестных уязвимостей «нулевого дня» (ошибка или пробел в защите софта, о которой разработчики сами еще не знают) в популярных библиотеках открытого кода. Каждая из уязвимостей была проверена и подтверждена членом команды Anthropic или сторонним экспертом по кибербезопасности.
«Примечательно, что ИИ находил уязвимости сам, без дополнительных инструкций: в одном случае ИИ-модели был лишь предоставлен доступ к библиотеке Python, а в другом случае при поиске уязвимостей в библиотеке CGIF-модель сама корректно описала, как можно использовать найденную уязвимость, — рассуждает пресейл-инженер «Спикатела» Денис Ушаков. — Нельзя не отметить достижения ИИ в поиске уязвимостей, но здесь все большее значение приобретает этический вопрос. ИИ лишен этики и может использовать найденные уязвимости как для улучшения защиты, так и для взлома. Поэтому крайне важно, в чьих руках находится ИИ-инструмент».
«Тектонический сдвиг»
С развитием ИИ требования к глубине технических знаний для поиска уязвимостей в opensource-библиотеках значительно снизились, констатирует руководитель группы исследования уязвимостей BI.ZONE Павел Блинников: «Это закономерно может привести к росту атак на цепочку поставок ПО, в том числе через сторонние зависимости в продуктах».
После этого инцидента Anthropic исключил возможность использования Opus 4.6 в подобных сценариях в целях кибербезопасности. Однако несмотря на введенные ограничения многие крупные кибергруппировки могут развернуть подобные модели локально, например, kimi2, указывает директор по продуктам Servicepipe Михаил Хлебунов. «Хотя это требует значительных ресурсов, стоимость такого решения измеряется не сотнями, а десятками миллионов рублей, что они могут себе позволить», — говорит он.
Хлебунов уверен, этот случай демонстрирует новый уровень возможностей больших языковых моделей: теперь они не только понимают код, но и умеют интерпретировать ход его эволюции, выявляя причины выбора тех или иных архитектурных решений в opensource проектах. «Это тектонический сдвиг в отрасли. Широкое распространение opensource библиотек создает риски проблем в кибербезопасности», — считает эксперт.
Широкое распространение opensource-библиотек значительно упрощает и ускоряет разработку, но слепое доверие чужому коду несет за собой ряд угроз, обращают внимание ИБ-специалисты. Недаром в последнем обновлении списка актуальных веб-угроз OWASP TOP 10 проблема уязвимостей в зависимых компонентах находится на третьей строчке, говорит руководитель продуктового развития компании WMX (ООО «Вебмониторэкс») Динко Димитров. Развитие ИИ усиливает угрозу и ускоряет масштабирование кибератак, подтверждает он: «Современные ИИ-модели позволяют злоумышленникам значительно быстрее анализировать крупные кодовые базы, выявлять уязвимые версии зависимостей, сопоставлять изменения между релизами и понимать, какие именно ошибки были исправлены в патчах».
Новые инструменты ИИ работают с широким контекстом — не только непосредственно с исходным кодом, но и с историей изменений проекта, что действительно позволяет ИИ предлагать архитектурные изменения, рассуждает гендиректор Security Vision Руслан Рахметов. В частности, исследователи Anthropic пишут, что Claude Opus «заглянул» в историю коммитов (изменений) в репозитории, чтобы понять источник ошибки и найти уязвимости в коде, обращает внимание он. «Подобный подход дает возможность ИИ использовать разнородные источники информации и шире смотреть на поставленную задачу — можно говорить о «расширении кругозора» моделей», — полагает Рахметов.
Хакерские инвестиции
Современные ИИ-модели можно запускать оффлайн, то есть без доступа к внешним API, говорят аналитики. Для анализа кода и разработки эксплойтов достаточно одного мощного компьютера и нескольких мощных видеокарт — это несколько тысяч долларов, считает Димитров. «Вполне вписывается в бюджет организованной кибергруппировки. Чем мощнее ИИ-модель, тем больше вложений в «железо» она требует. Но может быть и более «бюджетный» и доступный для злоумышленников вариант — аренда вычислительных мощностей и развертывание ИИ-модели в виртуальной среде», — говорит он.
Впрочем, по мнению Павла Блинникова, локальное развертывание LLM-агентов не является риском в классическом понимании. «Да, это может облегчить работу злоумышленников и повысить их безопасность, так как информация о целях не будет передаваться провайдерам LLM. Однако дополнительной опасности это не несет. Начальная стоимость такого решения оценивается в $2000, но может достигать $200 000 и более, — говорит он. — Важно отметить, что большинство атакующих предпочтут использовать подписочные модели и API от ведущих ИИ-лабораторий, а не разворачивать модели локально».
Атакующие действительно могут воспользоваться услугами инференс-провайдеров (то есть тех, кто оказывает услуги применения обученной модели к новым данным для получения предсказаний или выводов) и кастомизировать открытые модели — такие, как Qwen или Kimi — для поиска уязвимостей и создания эксплойтов, говорит Руслан Рахметов. «Это обойдется примерно в $1 за 1 млн токенов. Хакеры также могут арендовать выделенные GPU/TPU-серверы в облаке —например, для Qwen3-32B аренда сервера обойдется в среднем в $2-3 в час, а для новейшей мультимодальной Kimi K2.5 потребуется аренда сервера уже за $10 в час», — приводит расценки он.
Ценовые предложения провайдеров становятся все доступнее, а возможности ИИ расширяются, продолжает эксперт: например, хакерский тренд последнего года — использование ИИ для автоматизации всех этапов кибератаки и управление ИИ-агентами, автономно запускающими сотни хакерских программ, с помощью вредоносных фреймворков, таких как HexStrike AI. «Злоумышленники активно используют ИИ для масштабирования своих действий, а появляющиеся в открытом доступе ИИ-модели снижают порог входа в киберкриминальный мир. Теперь не нужны ни навыки программирования, ни понимание психологии людей, ни даже знание иностранных языков» — заключает Рахметов.
Как защититься
Любопытно, что многие opensource-проекты, в том числе используемые в корпоративных решениях, не поддерживаются разработчиками, а крупнейший веб-сервис для хостинга IT-проектов и их совместной разработки GitHub, например, не сканирует на уязвимости все ранее размещенные в нем проекты по умолчанию, указывает Рахметов: «Только актуальный код, над которым работает программист в настоящий момент».
По словам Ушакова, снизить риски открытого кода и найти уязвимости раньше хакеров помогает услуга безопасной разработки: ее внедрение может стоить бизнесу от 500 000 рублей до десятков миллионов рублей. «Это несопоставимо с убытками от возможных взломов», — говорит он.
Остановить развитие ИИ, равно как и запретить использование opensource, невозможно, а значит, защита должна строиться вокруг зрелости процессов, полагают эксперты. Нужно вести учет всех используемых компонентов и их версий, проводить регулярные сканирования на уязвимости, ограничивать автоматическое обновление критических компонентов без проверки, перечисляет Динко Димитров: «Основой для компаний должны стать принципы безопасной разработки, DevSecOps-культура и цифровая гигиена».
Для защиты можно использовать превентивные меры, согласен Блинников: «Например, оценить безопасность используемых opensource-библиотек с помощью тех же передовых LLM-моделей».