Open Source Analysis: зачем нужен и как его проводить
В мире современной разработки приложений программное обеспечение с открытым исходным кодом (open source) стало неотъемлемой частью практически любого приложения. Open source библиотеки, фреймворки и компоненты ускоряют разработку, снижают затраты и способствуют инновациям. Но при этом существует серьёзная проблема: каждая зависимость — это не только ускорение разработки, но и дополнительные риски. В этой статье я постараюсь разобрать, что такое анализ открытого исходного кода (Open Source Analysis, или OSA), зачем его необходимо проводить, как он выполняется и как выглядит на практике.
Почему же open source — это одновременно благо и риск?
По разным исследованиям, от 70 до 90% кода в современных приложениях – это open source компоненты. Обычный сервис может тянуть за собой в проект сотни транзи��ивных зависимостей, о существовании которых разработчик может иногда даже не подозревать.
Примечание: транзитивная зависимость – это косвенная зависимость, пакет или библиотека, на которую ПО зависит косвенно через другую зависимость, это «зависимость от зависимости».
И в этом моменте у нас уже появляются проблемы. А именно:
Если в библиотеке есть уязвимость, то она потенциально становится уязвимостью нашего приложения;
Зачастую обновление зависимости приходится отложить «на потом» (ведь для начала надо проверить, не сломает ли обновление работу нашего приложения);
Довольно часто лицензии на open source или читают уже после того, как внесли библиотеку в продукт, или не читают вовсе.
Для решения этих проблем используется Open Source Analysis.
Что такое Open Source Analysis?
Open Source Analysis (OSA) — это процесс выявления и анализа open source компонентов, используемых в приложении.
При этом OSA фокусируется на нескольких аспектах:
Уязвимости;
Лицензии;
Актуальность и поддержка компонентов;
Риски для цепочки поставок (supply chain).
По сути OSA даёт нам ответ на простой вопрос: «Какие риски мы наследуем, когда подключаем очередную библиотеку?».
Стоит упомянуть, также что зачастую OSA рассматривают как часть Software Composition Analysis (SCA).
Примечание: Software Composition Analysis (SCA; это композиционный анализ) – это анализ компонентного состава приложения. Он позволяет обнаруживать уязвимые компоненты, дефекты безопасности или проблемы с условиями лицензирования.
Зачем проводить Open Source Analysis
1. Уязвимости: инциденты, которые уже случались
Одна из главных причин проведения OSA – своевременное выявление уязвимостей в открытых компонентах, которые могут привести к серьёзным инцидентам.
В качестве примера рассмотрим Log4Shell (CVE-2021-44228) – одну из самых масштабных уязвимостей последних лет. Эта уязвимость в популярной Java-библиотеке Log4j привела к следующему:
По всему миру были зафиксированы инциденты;
Разработчикам приходилось выпускать экстренные патчи и отключать сервисы;
Многие компании‑разработчики вообще впервые задумались над вопросом: «А мы используем в своих продуктах Log4j?».
Компании, у которых уже был построен процесс OSA, смогли ответить на данный вопрос очень быстро. Другие потратили на это дни, а то и недели.
Другие примеры:
1. Equifax breach — Apache Struts (CVE-2017-5638, март 2017)
Тип: Remote Code Execution.
Воздействие: Утечка личных данных 147 миллионов пользователей (имена, адреса, даты рождения). Штрафы и убытки более $1.4 млрд.
Причина: Не обновили Struts с 2014–2015 годов, хотя патч вышел за 2 месяца до атаки.
Вывод: Хороший пример комбинации «устаревшая зависимость + отсутствие видимости».
2. XZ Utils backdoor (CVE-2024-3094, март 2024)
Тип: Supply chain attack — внедрённая backdoor в liblzma (xz-utils)
Воздействие: Затронуло почти все современные дистрибутивы Linux (Debian, Fedora, Ubuntu и др.), позволяло RCE через SSH. Обнаружено случайно.
Причина: Backdoor был внедрён в популярный репозиторий, который поддерживался одним мэйнтейнером, который из-за невозможности в достаточной степени заниматься проектом передал эти права инициативному пользователю, который в последствие оказался злоумышленником.
Вывод: Самый яркий пример targeted supply chain атаки на infrastructure open source. Показал уязвимость проектов с одним мейнтейнером.
3. Event-Stream (npm, 2018)
Тип: Supply chain — maintainer продал проект, новый владелец добавил вредоносный код.
Воздействие: Код крал Bitcoin-кошельки из приложения Copay. Затронул тысячи downstream-проектов.
Причина: Доверие к популярному проекту.
Вывод: Заражение через популярный пакет → массовая компрометация. Показал риски maintainer takeover.
2. Supply chain атаки — уже не теория, а практика
Атаки на цепочку поставок уже перестали быть экзотикой. Злоумышленники уже активно используют такие атаки. Примерами атак на цепочку поставок могут быть:
Dependency confusion — загрузка подмененных пакетов с публичных репозиториев;
Компрометация аккаунтов мейнтейнеров проектов;
Внедрение вредоносного кода в обновления.
OSA позволяет, как минимум, иметь преставление о том:
Где находится источник зависимости;
Кто и как осуществляет её поддержку.
3. Боль лицензионной чистоты
Простой пример из практики: продукт уже готов к релизу и на этапе проверки к поставке его клиенту внезапно выясняется, что внутри есть компоненты, распространяемые под лицензией типа GPL, которая требует раскрытия исходного кода продукта. Как возможный результат – срочная переработка продукта, перенос релиза или возможная потеря клиента.
OSA позволяет выявлять такие ситуации заранее, ещё на этапе разработки, и планомерно принимать решения по каждой из них без необходимости срочной переработки или срывов сроков разработки и выпуска продукта.
Как выполняется Open Source Analysis на практике
Шаг первый. Инвентаризация и SBOM
Первый шаг - понять, какие именно компоненты используются в продукте. Для этого формируется Software Bill of Materials (далее - SBOM).
Примечание: Software Bill of Materials (SBOM) – это перечень всех компонентов, библиотек и зависимостей, используемых в ПО.
Анализу подвергаются manifest-файлы (package.json, pom.xml), lock-файлы (package-lock.json), образы контейнеров.
В результате мы получаем список всех прямых и транзитивных зависимостей с указанием их версий.
Шаг второй. Поиск и оценка известных уязвимостей
Далее все зависимости сопоставляются с известными базами уязвимостей, например NVD / CVE, GitHub Security Advisories, БДУ ФСТЭК.
При этом важно понимать, что наличие CVE не означает автоматически эксплуатируемую уязвимость.
Application security engineer проводит анализ уязвимости и определяет, может ли она быть проэксплуатирована злоумышленником и отсеивает ложные срабатывания сканеров.
Шаг третий. Анализ лицензий
В большинстве случаев в компаниях есть политика использования лицензий, например:
Разрешённые лицензии (MIT, BSD, Apache 2.0);
Условно разрешённые (LGPL);
Запрещённые (GPL/AGPL).
OSA находит данные конфликты.
Шаг четвертый. Оценка поддержки компонентов
При выборе новых компонентов стоит обращать внимание не только на уязвимости, но и на осуществление поддержки, а именно:
Когда был выпущен последний релиз;
Сколько в компоненте активных контрибьюторов;
Отслеживают ли разработчики уязвимости в зависимостях своего приложения и как быстро реагируют на проблемы безопасности в своем продукте.
Заброшенная или архивная библиотека — это потенциальный риск безопасности.
Шаг пятый. Интеграция в CI/CD
По мере повышения уровня зрелости, практика OSA:
Запускается автоматически при каждой сборке продукта;
Блокирует сборку продукта при обнаружении уязвимостей критического и высокого уровней;
Обеспечивает постоянный мониторинг и обновление имеющихся зависимостей.
Инструменты для Open Source Analysis
Кратко перечислю инструменты, которые используются для OSA/SCA:
OWASP Dependency‑Check;
OWASP Dependency‑Track;
Snyk;
Trivy;
Code Scoring;
GitHub Dependabot / Security Advisories.
Выбор инструмента зависит от уровня компании, зрелости процессов безопасной разработки, а также требований к лицензированию.
Заключение
В заключении стоит подвести итог того, какие преимущества даёт применение OSA, а именно:
Прозрачность состава компонентов, используемых в приложении;
Понимание потенциального вектора атаки на разрабатываемое приложение;
Возможность оперативного реагирования на появление новых уязвимостей;
Возможность управлять лицензионными рисками;
Обеспечение безопасности разрабатываемого продукта;
И, как итог, получение преимуществ над конкурентами, например, за счёт снижения вероятности возникновения инцидентов информационной безопасности или простоя оборудования в следствие успешно реализованной атаки.
Open Source Analysis — это необходимая инженерная практика. Она отвечает на простой, но важный вопрос: насколько мы контролируем то, из чего состоит наш продукт.
В условиях, когда большая часть кода пишется не внутри компании, а приходит извне, OSA становится обязательным элементом безопасности продуктов.
