Управление уязвимостями в open source | Блог Касперского

Как обогащать данные, настраивать ИИ-системы и менять политики компании, чтобы снизить риски уязвимостей в цепочке поставок кода open source.

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

Доверенный пул компонентов open source

Фундаментальная часть решения — предотвратить использование уязвимого и вредоносного кода. Для этого имеет смысл реализовать следующие меры:

• Внутренний репозиторий артефактов. Единственным источником компонентов для внутренней разработки должен быть единый репозиторий, компоненты в который попадают только после серии проверок.
• Тщательный скрининг компонентов. Среди необходимых проверок: известные версии компонента, известные уязвимые и вредоносные версии, дата публикации, история активности, репутация пакета и авторов. Обязательно сканировать все содержимое пакета, включая инструкции по сборке, тест-кейсы и другие вспомогательные данные. Для фильтрации реестра при его наполнении должны использоваться специализированные решения для сканирования open source или комплексное решение для безопасности облачных нагрузок.
• Закрепление зависимостей. Процессы сборки, ИИ-инструменты и разработчики не должны использовать шаблоны при указании версий (например, latest). Сборка проекта должна идти на основе проверенной версии. При этом закрепленные зависимости должны регулярно обновляться до последней, но проверенной версии, которая сохраняет совместимость и лишена известных уязвимостей. Это значительно снижает риск атак на цепочку поставок через компрометацию известного пакета.

Улучшение данных об уязвимостях

Чтобы эффективней находить уязвимости и правильно их приоритизировать, необходимо настроить несколько процессов в ИТ и ИБ:

• Обогащение данных об уязвимостях. В зависимости от нужд организации, можно либо обогащать информацию, комбинируя NVD, EUVD, BDU, базу бюллетеней GitHub и базу osv.dev, либо покупать один из коммерческих потоков информации об уязвимостях, где данные уже сведены воедино и обогащены. В любом случае дополнительно стоит отслеживать потоки данных threat intelligence, чтобы учитывать тренды реальной эксплуатации и понимать профиль атакующих, использующих конкретные уязвимости. «Лаборатория Касперского» поставляет специальный поток данных, касающийся конкретно компонентов open source.
• Глубокий анализ состава ПО. Специальные инструменты Software Composition Analysis (SCA) позволяют корректно проверить цепочку зависимостей в используемом коде open source, чтобы полностью инвентаризировать используемые библиотеки и обнаружить устаревшие и неподдерживаемые компоненты. Данные о «здоровых» компонентах также потребуются для пополнения реестра артефактов.
• Идентификация abandonware. Даже если пакет формально не является уязвимым и не заявлен официально как неподдерживаемый, в процессе сканирования стоит учитывать компоненты, для которых не выходило обновлений более года. Они достойны отдельного анализа и, возможно, замены наравне с компонентами EOL.

Защита ИИ-кода и ИИ-агентов

Деятельность используемых в кодинге ИИ-систем должна регулироваться целым комплексом мер безопасности — от фильтрации данных на входе до обучения пользователей:

• Ограничения на рекомендации зависимостей. Настройте среду разработки так, чтобы ИИ-агенты и ИИ-помощники могли ссылаться только на компоненты и библиотеки из доверенного реестра артефактов. Если там не содержится нужных инструментов, модель должна делать запрос на включение зависимости в реестр, а не тянуть что-то, описанное нужными словами, из PyPI.
• Фильтруйте ответы модели. Несмотря на указанные ограничения, все, что сгенерировала модель, нужно повторно проверять, чтобы в ИИ-коде не оказалось устаревших, неподдерживаемых, уязвимых или несуществующих зависимостей. Эта проверка должна быть интегрирована прямо в процесс принятия кода от модели либо в подготовку процесса сборки. Она не заменяет традиционный процесс статического анализа — инструменты SAST должны быть по-прежнему встроены в процесс CI/CD.
• Обучение разработчиков. ИТ- и ИБ-команды должны быть близко знакомы со спецификой ИИ-систем, их принципов работы и типовых ошибок. Для этого нужно пройти специализированный курс обучения, адаптированный к роли сотрудника.

Систематическая работа по избавлению от EOL

Если в системах компании используются устаревшие компоненты open source, необходимо систематически, последовательно решать проблемы их уязвимости. Для этого есть три основных способа:

• Миграция. Это самый организационно сложный и дорогой способ, который подразумевает полную замену компонента с последующей адаптацией, переписыванием или заменой приложений, которые на нем основаны. Особенно сложно решиться на миграцию, если она требует значительно переписывать весь уникальный код, созданный в компании. Очень часто это затрагивает «инфраструктурные» компоненты — трудно мигрировать с Node.js 14 или Python 2.
• Долгосрочная поддержка (LTS). Для крупных ретро-проектов существует отдельный рынок услуг техподдержки. Иногда это форк старой системы, который поддерживают другие разработчики, иногда специальные команды переносят (backport) патчи, устраняющие конкретные уязвимости, в более старые и неподдерживаемые версии. Как правило, переход на LTS-решения требует постоянных затрат на техподдержку, но во многих случаях это дешевле, чем миграция.
• Компенсирующие меры. По результатам подробного анализа можно выстроить комплекс мер «вокруг» устаревшего решения, снизив риск эксплуатации уязвимостей в нем. Насколько это действенно и экономически эффективно, зависит от роли защищаемого ПО в жизни организации.

ИБ, ИТ и бизнес должны совместно выбрать один из трех путей для каждого документированного компонента ПО, имеющего статус EOL или abandoned, и затем отразить это в реестрах и SBOM компании.

Управление уязвимостями open source на базе оценки рисков

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

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

• Выполняется ли уязвимая ветка кода в разработках конкретной компании? Для обнаруженных уязвимостей нужно проводить анализ доступности (reachability analysis), потому что зачастую дефектный фрагмент кода вообще не используется в условиях организации и уязвимость невозможно проэксплуатировать. Такой анализ могут проводить некоторые решения класса SCA. Тот же анализ позволяет оценить смежный сценарий — а что будет, если вообще убрать уязвимые процедуры или компоненты из проекта? Иногда этот способ устранения уязвимости оказывается на удивление безболезненным.
• Эксплуатируется ли дефект в реальных атаках, доступен ли для него код PoC? Ответы на эти вопросы входят в типовые методики приоритизации уязвимостей вроде EPSS, но отслеживание нужно проводить по более широкому набору источников.
• Отмечена ли активность киберпреступников в конкретном реестре зависимостей, в смежных и похожих компонентах? Это дополнительные факторы для приоритизации.

Учет этих факторов позволит эффективно тратить ресурсы команды и устранять в первую очередь наиболее опасные дефекты.

Разработка open source требует прозрачности

Требования к безопасности кода open source будут только расти. Компании, которые разрабатывают приложения даже для внутренних нужд, столкнутся с требованиями регуляторов в отношении документированной и доказуемой кибербезопасности в системах организации. Как отмечают эксперты Sonatype, «прозрачность стала новой валютой в вопросах безопасности цепочки поставок ПО». По их оценке, уже 90% компаний по всему миру подпадают под одно или несколько требований по предоставлению доказательств надежности используемого ПО.

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

04.04.2026

Kaspersky для школ по специальной цене