В течение последнего года произошло несколько масштабных атак, включая распространение червя Shai-Hulud, компрометацию системы сборки Nx, а также утечку секретов в публичные журналы GitHub Actions из-за уязвимости в tj-actions/changed-files. Список подобных инцидентов можно было бы продолжать еще долго, даже без детального рассмотрения каждого из них.
Эта отрасль и технологическая система ощущает существенный рост частоты подобных угроз. Только в 2024 году зафиксировано увеличение количества вредоносных пакетов на 156% по сравнению с предыдущим годом. Благодаря тому, что облачная платформа Mend Renovate Cloud используется более чем в 1,3 миллионах репозиториев, созданы мощные возможности для повышения безопасности пользователей открытого кода, а также для более надежных настроек по умолчанию в случаях самостоятельного развертывания Renovate. После серии резонансных атак на цепочку поставок npm команда сопровождения (мейнтейнеров) Mend Renovate приняла решение активировать эти механизмы защиты по умолчанию для пользователей, выбирающих конфигурацию “best practices”.
Для повышения эффективности защиты от атак, количество которых постоянно растет, команда сопровождения совершенствует существующую конфигурацию “best practices”, доступную в Mend Renovate. Работа направлена на создание более безопасной конфигурации по умолчанию, начиная с экосистемы npm.
В последнем релизе Mend Renovate 42 пользователи конфигурации “best practices” увидят изменения в обновлении зависимостей в экосистеме npm, которые теперь должны соответствовать критерию “minimum release age”. Это означает, что перед тем, как Mend Renovate предложит обновление, должно пройти по меньшей мере трехдневное окно с момента выхода новой версии. Такой подход обеспечивает поступление в производственную среду только проверенных, стабильных и надежных обновлений зависимостей, что позволяет снизить риск атак на цепь снабжения и одновременно сохранить эффективность работы разработчиков.
Как это помогло бы?
Несмотря на широкий масштаб воздействия, большинство подобных атак обычно эксплуатируют две типичные ситуации:
- точная версия зависимости не зафиксирована;
- точная версия зависимости зафиксирована, но выполняется слишком быстрое обновление после выхода новой версии.
Отсутствие фиксации версий зависимостей может иметь обоснованные причины. Например, в экосистеме npm, когда публикуется пакет с несколькими зависимостями, который имеет много производных (зависимых) пакетов.
Если каждый раз при обновлении версии одной зависимости требуется выпускать новую версию пакета, то все зависящие от него пакеты также вынуждены обновляться и перевыпускаться, создавая эффект цепной реакции в масштабах всей экосистемы.
Часть этого процесса можно упростить с помощью автоматизации – например, с помощью таких инструментов как Mend Renovate или Dependabot от GitHub. Впрочем, даже при наличии автоматизированных инструментов, все равно требуется определенный уровень ручной проверки и рецензирования обновлений.
В то же время, отсутствие фиксации версий зависимостей может привести к ситуациям, когда пользователи начинают загружать новую версию пакета сразу после ее выхода.
После введения рекомендации фиксировать версии зависимостей возникает другой вопрос: как часто выполнять обновления. Во многих инструментах по умолчанию используется принцип «обновления сразу после выхода новой версии», что может привести к созданию Pull Request с вредоносным обновлением уже через несколько минут после его публикации.
Даже если такая вредная зависимость не попадет непосредственно на рабочие машины разработчиков, она все равно может получить доступ к секретам или конфиденциальной информации в автоматизированных CI/CD-пайплайнах или использовать атаки инъекции промпта в системах автоматического рецензирования кода на основе искусственного интеллекта.
Увеличение интервала между выходом новой версии пакета и моментом, когда обновление попадает в проект Pull Request, дает больше времени аналитикам безопасности и автоматизированным системам проверки для выявления потенциально вредных компонентов, тем самым уменьшая риски атак на цепочку поставок.
Как Mend Renovate способствует повышению безопасности всей экосистемы
Как указано выше, в новейшем релизе Mend Renovate введена проверка “minimum release age” для всех пользователей, применяющих конфигурацию “best practices”. Эта проверка активируется при обновлении любых пакетов, использующих источник данных npm. Она происходит вне зависимости от того, какой менеджер пакетов JavaScript или TypeScript применяется.
Введенное ограничение позволяет:
- Убедиться, что каждое обновление зависимости содержит метаданные о времени выхода версии (release timestamp).
- Гарантировать, что ветки обновлений не будут создаваться до тех пор, пока не пройдет минимум три дня с момента публикации релиза.
Если во время проверки обновлений пакетов обнаружено, что они не соответствуют указанным критериям, в Dependency Dashboard от Mend Renovate появится запись “awaiting status”. Такая запись потребует ручного подтверждения пользователя и гарантирует, что к работе допускаются только безопасные обновления пакетов.
Следует отметить, что увеличение времени ожидания не гарантирует выявления абсолютно всех проблем. Возможны целенаправленные атаки или методы обхода проверок, например через использование инструментов искусственного интеллекта на скомпрометированных системах для внесения изменений. Поэтому этот подход существенно снижает риски, но не является универсальным решением проблемы.
Благодаря включению этого механизма в конфигурацию “best practices”, пользователи, избравшие соблюдение общепринятых отраслевых стандартов безопасности, получают защиту по умолчанию. В то же время другие пользователи могут также включить эту функцию самостоятельно, например:
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["security:minimumReleaseAgeNpm"]
}Кроме того, поведение этого механизма можно настраивать. Есть возможность изменять продолжительность окна ожидания на произвольную (длинную или более короткую), или выключать функцию “minimum release age” для внутренних, проверенных пакетов, разрабатываемых внутри организации.
Многоуровневая защита
Кроме задержки обновлений в Mend Renovate до завершения установленного периода, рекомендуется использовать несколько уровней защиты.
По возможности следует активировать аналогичную функциональность в менеджере пакетов, чтобы рабочие станции разработчиков также были защищены, а автоматизированные пайплайны сборки останавливались при попытке установки обновления, пока не пройдет заданный временной интервал.
На момент написания статьи поддержка этой функции уже реализована в pnpm 10.6 и yarn 4.2.0. Также наблюдается тенденция к внедрению схожих возможностей и в других менеджерах пакетов.
Что дальше?
После работы над этим релизом планируется дальнейшее совершенствование взаимодействия между Mend Renovate и менеджерами пакетов, такими как pnpm и yarn с целью более глубокой интеграции функциональности.
Также продолжаются исследования других экосистем пакетов, в которых эту функцию можно будет активировать для конфигурации “best practices”. Это поможет еще больше повысить уровень безопасности экосистемы.
Предложения касаемо работы инструмента можно оставлять на форуме обсуждений Mend Renovate.
Если у вас возникли вопросы по Mend Renovate или вы хотите получить пробную версию продукта, пожалуйста, оставьте свою контактную информацию:
