Open source верить нельзя
Конференция Data Fusion 2026. На фото: глава АО "Лаборатория Касперского" Евгений Касперский (Фото ComNews)
Вчера, 8 апреля, на конференции Data Fusion в кластере "Ломоносов" глава АО "Лаборатория Касперского" Евгений Касперский сообщил, что в период с 2022 г. компания выявила более 20 тыс. проблемных open-source-проектов, содержащих вредоносные закладки. "Так что open-source верить нельзя", - подчеркнул он.
Речь идет о проектах с открытым исходным кодом - тех самых, которые любой программист может бесплатно скачать и использовать в программах. "Лаборатория Касперского" предоставляет специальный сервис под названием Kaspersky Open Source Software Threats Data Feed, в который в автоматическом режиме попадает информация о всех выявленных уязвимых и вредоносных пакетах из популярных репозиториев.
Специалисты крупнейших отечественных компаний, в том числе в сфере информационной безопасности, рассказали, какими инструментами проверяют open-source-компоненты на наличие закладок и уязвимостей.
Технический директор АО "Инфовотч" (ГК Infowatch) Александр Бебрусь рассказал, что для проверки open-source-компонентов компания использует решения внешних разработчиков: "Open-source-компоненты, которые мы включаем в продукты, проходят статический анализ. Информация о них содержится в SBOM-файлах, которые мы потом сопоставляем с известными базами уязвимостей. Мы согласны, что нельзя брать open-source-компоненты и слепо в них верить. Использование таких компонентов является риском для утечки данных, поэтому госкомпании стараются использовать только сертифицированные версии продуктов и сертифицированные операционные системы (ОС). Такую сертификацию получить непросто, и как раз при сертификации подаются данные на все сторонние компоненты (open source) и SBOM-файлы, в которых содержится вся информация о составе ПО".
Директор центра разработки решений по контролю безопасности программного обеспечения (ПО) АО "Солар Секьюрити" (ГК "Солар") Антон Прокофьев рассказал, что для проверки ПО, которое содержит компоненты открытого кода, в платформу для комплексной безопасности приложений компании интегрирован модуль анализа OSA (Open Source Analysis): "Этот модуль объединяет два вида анализа: SCA и SCS. Анализ состава ПО (SCA) выявляет зависимости и уязвимости в используемых open-source-библиотеках, опираясь на стандартные базы уязвимостей. В свою очередь, анализ безопасности цепочки поставок (SCS) позволяет оценить риски, связанные с самим open-source-компонентом, и сформировать его рейтинг безопасности. Этот рейтинг строится на основе таких метрик, как репутация автора, активность сообщества и внимание к безопасности. Кроме того, инструмент помогает отслеживать лицензионные политики и избегать юридических рисков".
Руководитель отдела продвижения продуктов ООО "Код Безопасности" Павел Коростелев сообщил, что компания использует комбинированный подход: "Собственные разработки, аудит кода и внешние решения, которые проводят статический анализ безопасности на основе исходного кода. Мы также контролируем, чтобы старые open-source-компоненты не попадали внутрь продукта. Речь идет о применении только самых новых компонентов, наиболее безопасных с точки зрения поиска уязвимостей".
Руководитель исследований AppSec АО "Позитив Текнолоджиз" (Positive Technologies) Владимир Кочетков рассуждает: "Правильная постановка вопроса не "верить или не верить open source", а "какие объективные гарантии безопасности мы требуем от любого компонента в нашей цепочке поставок". Для open source это аудит кода, история CVE (Common Vulnerabilities and Exposures - база данных общеизвестных уязвимостей и инцидентов) и скорость их закрытия, наличие активного мейнтейнерского сообщества, подписанные релизы. Для проприетарного - сертификации, пентесты, SLA на патчи, прозрачность в раскрытии инцидентов. Модель угроз и зрелость SDL (Secure Development Lifecycle) - вот что определяет доверие, а не лицензия на исходный код".
Риск - дело неблагородное
Эксперт по комплексным проектам информационной безопасности ООО "Стэп Лоджик" (Step Logic) Владимир Арышев согласился, что open source содержит определенную особенность: "Никто не несет за него ответственность. На практике наши заказчики регулярно сталкиваются с наличием в open-source-библиотеках не только уязвимых компонентов, но и откровенно вредоносных. Также в коде часто встречается protestware - закладка, активность которой начинается при запуске на территории России. Для защиты от уязвимых и вредоносных компонентов мы рекомендуем использовать специализированные решения класса Software Composition Analysis (SCA) для композиционного анализа, которые находят в разрабатываемом ПО подобные компоненты и предлагают адекватную замену".
Технический директор MD Audit (SL Soft FabricaONE.AI, акционер - ГК Softline) Юрий Тюрин отметил, что популярные open-source-проекты проходят больше проверок: "Активное сообщество быстрее находит уязвимости, выпускает патчи и поддерживает актуальность зависимостей. Это снижает риск тихих закладок, которые могут долго оставаться незамеченными. Однако у популярности есть и обратная сторона: такие проекты становятся приоритетной целью атак. Через них можно попасть сразу в тысячи продуктов - классический пример риска цепочки поставок (supply chain). Поэтому злоумышленники чаще атакуют не сам основной репозиторий, а экосистему вокруг: сторонние зависимости, пакеты с похожими именами, компрометацию аккаунтов мейнтейнеров. Менее известные проекты опасны по другой причине - отсутствием аудита и поддержки. Там уязвимости могут существовать годами. В итоге безопаснее не популярный или нишевой open-source сам по себе, а тот, который проходит регулярную проверку, имеет прозрачную историю изменений и используется с контролем зависимостей внутри компании".
Представитель пресс-службы ООО "Аппсек Солюшенс" (AppSec Solutions) сообщил, что каждая вторая популярная у российских разработчиков библиотека с открытым кодом содержит уязвимости: "Это подтверждает исследование open-source-компонентов, которые использовали российские разработчики, - мы провели его в прошлом году. Каждая вторая из популярных библиотек, 51%, по нашим наблюдениям, содержала уязвимость в какой-либо из версий. Уязвимости, обнаруженные исследованием, позволяют злоумышленникам осуществлять перехват данных при выполнении HTTP-запросов, ослабить криптографическую защиту и выполнять произвольный код. Результаты исследования показывают, что даже самые популярные open-source-компоненты могут содержать критические уязвимости. Это подчеркивает важность регулярного обновления библиотек, проведения аудита безопасности и использования инструментов для управления зависимостями".
Директор по безопасной разработке ООО "Рукс Солюшенс" (RooX) Константин Корсаков отметил, что проверка заимствованных компонентов - обязательный процесс по методологии безопасной разработки: "Закладки, политические вставки и просто уязвимости - это реальная угроза для любой компании, которая использует open source. Но на практике уровень риска зависит от языка разработки, используемых фреймворков. "Победителем" этого конкурса, конечно, является экосистема npm (менеджер пакетов для программной платформы Node.js). Большую угрозу несет open source, который давно заброшен автором, и потом в него незаметно вставляют уязвимость, например, украв доступ к репозиторию".
Информационный баланс
Первый заместитель генерального директора "Базальт СПО" Алексей Смирнов рассказал, что любой программный код может содержать ошибки и закладки, но доступность исходных кодов свободных программ позволяет организовать их систематическую проверку. "Такую работу ведет, в частности, консорциум по проверке open source, созданный по инициативе ФСТЭК России на базе ИСП РАН. Мы в этой работе участвуем. Анализ ведется с использованием специальных инструментов, в том числе отечественных. Мы выпускаем продукты, включая ОС "Альт", на базе нашей инфраструктуры разработки, в которую интегрированы инструменты проверки, и руководствуемся требованиями ФСТЭК России к процессу безопасной разработки. При обнаружении уязвимостей мы их оперативно закрываем", - подчеркнул Алексей Смирнов.
Руководитель направления заказной разработки ГК "Корус Консалтинг" Елена Никитина сообщила, что для анализа безопасности open-source-компонентов компания использует комбинацию инструментов: "В частности, применяем OWASP ZAP для выявления уязвимостей на уровне приложений. Также дополнительно ориентируемся на практики профессионального сообщества и данные из открытых источников: информация о выявленных уязвимостях в open-source-проектах распространяется быстро, что позволяет оперативно учитывать новые риски".
Генеральный директор ООО "Сентра" (Sentra) Максим Брагин отметил, что проблема, о которой говорит Евгений Касперский, реальная - но 20 тыс. зараженных проектов отражают лишь верхушку айсберга: "Основная угроза сегодня - не вредоносный код в малоизвестной библиотеке, а целенаправленные атаки на цепочки поставок, когда злоумышленники компрометируют популярные, доверенные компоненты с миллионами загрузок. В таком случае пострадает не несколько компаний, разработчики которых подключили вредоносную библиотеку, а сотни тысяч организаций, которые установили популярный в сообществе компонент, считающийся безопасным".
Основатель платформы безопасной разработки CodeScoring Алексей Смирнов сообщил, что компания только за 2025 г. обнаружила 457 тыс. версий вредоносных библиотек, которые несли непосредственную угрозу компаниям: "С 2024 г. их количество увеличилось более чем на 1000%. Мы проверяем стороннее ПО, используя собственное решение. Но чтобы качественно решить эту задачу, важно не только собирать данные об открытых библиотеках и их уязвимостях из десятков источников, проводить дедупликацию и проверку на корректность, но и учитывать особенности языков программирования и пакетных менеджеров. Необходимо заранее протестировать проверку open-source-компонентов, чтобы понять, как встроить ее в производственный контур, не блокируя работу разработчиков".
Кто виноват и что делать
Cтарший консультант отдела безопасности жизненного цикла разработки ПО Infosecurity (входит в "Софтлайн Решения", ГК Softline) Сергей Гаркуша отметил, что в open source всегда были проблемы с уязвимостями, поэтому сказать, что сильно влияет на бизнес-решения, некорректно: "Уязвимый компонент всегда можно заменить. В большинстве случаев уязвимости в open-source-компонентах устраняются сообществом и публикуется уже исправленный патч. Сильное влияние есть, если внедрение проверки было реализовано слишком поздно - в таком случае потребуется переписывать часть кода, чтобы устранить все уязвимости. Лучше позаботиться об этом заранее".
Заместитель генерального директора по развитию ООО НПП "Релэкс" Ирина Мягкова считает, что ответственность за безопасность итогового продукта несет разработчик, который интегрирует сторонний компонент: "Сообщество open source не может гарантировать отсутствие закладок или уязвимостей, особенно в крупных и разветвленных проектах. Поэтому профессиональная команда обязана самостоятельно проверять и контролировать качество используемых библиотек. Если будет необходимо, мы готовы рассматривать платные сервисы проверки open source, если они обеспечивают более высокий уровень автоматизации, актуальности баз угроз и поддержки, чем бесплатные аналоги".
Технический директор платформы "Боцман" (входит в "Группу Астра") Михаил Кобик считает, что ответственность за последствия использования открытого компонента, содержащего закладки или уязвимости, лежит в первую очередь на разработчике, который принимает решение о его включении в продукт: "Именно разработчик обязан обеспечить безопасность конечного решения и подтвердить ее при сертификации. Сообщество open source несет скорее моральную и репутационную ответственность, но юридически, как правило, действует по принципу "как есть". Поэтому в корпоративной практике мы исходим из того, что каждый производитель ПО обязан самостоятельно проверять любой используемый код - вне зависимости от его происхождения".
