Атаки на цепочку поставок ПО: пересматриваем проверку зависимостей после xz-utils

На прошлой неделе ФСТЭК выпустил бюллетень, в котором атаки на цепочку поставок программного обеспечения названы приоритетной угрозой на 2025 год. Документ сам по себе небольшой, но для нас это был повод сесть и честно разобраться: а как у нас и у клиентов обстоит дело с реальной проверкой зависимостей? Оказалось, что не очень.

Почему именно сейчас это стало предметным разговором

xz-utils в марте 2024 года и история с 3CX годом раньше наглядно показали: атака через зависимость - это не теоретическая угроза из академических докладов. Это конкретный разработчик, два года методично строящий доверие в опенсорс-проекте, и бэкдор, вшитый в tarball на этапе сборки - мимо git-репозитория и мимо большинства CI-проверок. Если такое прошло незамеченным в инфраструктуре, которую аудируют тысячи глаз по всему миру, то в закрытом корпоративном контуре шансы поймать похожее заранее - ещё ниже.

Бюллетень ФСТЭК формализует то, о чём в ИБ-сообществе говорили весь 2024 год. Теперь это не просто best practice, а сигнал о том, что регулятор начнёт это проверять. Для субъектов КИИ это означает: если раньше достаточно было иметь антивирус на периметре и обновлённый реестр СЗИ, то теперь стоит объяснить инспектору, как именно вы контролируете происхождение компонентов, которые уходят в production.

Где у нас было слепое пятно

Мы провели внутренний разбор нескольких проектов - тех, где настраивали CI/CD-пайплайны для клиентов. Картина ожидаемая: на входящие зависимости все смотрят через призму CVE-сканеров - Trivy, Grype, что-то самодельное на основе осиных баз. Это полезно, но недостаточно.

CVE-сканер проверяет известные уязвимости в известных компонентах. Атака типа xz-utils проходит иначе: компонент не уязвим - он намеренно скомпрометирован. Версия корректная, хеш совпадает с официальным источником, CVE нет. Проблема в том, что официальный источник уже содержит закладку.

Именно здесь SBOM (Software Bill of Materials) перестаёт быть просто модным словом и начинает работать - но только если его использовать не как отчёт на полке, а как живой инструмент сравнения.

Что работает в изолированном контуре

Основная сложность для большинства наших клиентов - работа в сегментированной или полностью изолированной сети. Инструменты, которые подтягивают базы угроз из интернета в реальном времени, просто не подходят. Разбирали несколько вариантов.

Syft + Grype в офлайн-режиме. Syft генерирует SBOM в форматах SPDX или CycloneDX из образа или директории с артефактами. Grype умеет работать с локально загруженной базой данных уязвимостей - база скачивается отдельно, переносится на изолированный хост, обновляется по расписанию через шлюз. Это рабочая связка, которую мы уже используем в нескольких проектах. Минус - база покрывает только известные CVE, закладки не ловит.

Сравнение SBOM между версиями. Более интересный подход - генерировать SBOM для каждого релиза и сравнивать diff. Если между патч-версиями внезапно появился новый транзитивный пакет или изменился хеш существующего без изменения версии - это сигнал для ручной проверки. Автоматизировать это несложно: syft + скрипт сравнения + алерт в систему мониторинга. Выглядит просто, а на практике никто не делает.

Pinning хешей, а не версий. В pip, npm, cargo и большинстве других менеджеров пакетов есть механизм фиксации не только версии, но и хеша дистрибутива. Если хеш пакета в репозитории изменился при той же версии - сборка падает. Это не защита от закладки в самом коде, но это защита от подмены артефакта между релизом и скачиванием.

Внутренний зеркальный репозиторий. Классика изолированного контура: все зависимости приходят не напрямую из интернета, а через внутреннее зеркало - Nexus, Artifactory, или отечественные аналоги. Это само по себе не безопаснее, но даёт контроль: что именно лежит в зеркале, когда оно туда попало, кто туда что добавил. Без этого контроля - аудируй не аудируй, поверхность атаки остаётся непрозрачной.

Что мы изменили в своём процессе

После разбора ввели несколько правил, которые теперь применяем и в клиентских проектах в рамках аудита защищённости.

• SBOM-генерация обязательна на выходе CI. Не «когда-нибудь» - каждая сборка создаёт артефакт с составом зависимостей.
• Diff между предыдущим и текущим SBOM - часть pipeline. Если появились новые транзитивные зависимости, сборщик это видит.
• Хеш-пиннинг для прямых зависимостей там, где менеджер пакетов это поддерживает.
• Внутреннее зеркало с журналом добавлений - кто, когда, откуда принёс пакет.

Всё это не даёт стопроцентной защиты. xz-utils прошёл бы через часть этих мер - хеш официального tarball совпадал. Но комбинация создаёт достаточно точек контроля, чтобы аномалия стала заметной раньше, чем она уйдёт в production.

Где сейчас стоит точка

Бюллетень ФСТЭК - это сигнал, что тема перешла из категории «передовые практики» в категорию «будут проверять». Для клиентов на КИИ это означает необходимость хотя бы объяснить на бумаге, как организован контроль зависимостей. Для всех остальных - хороший повод не ждать, пока объяснять придётся уже по итогам инцидента.

Отечественных специализированных инструментов для SBOM-анализа на изолированных контурах немного - рынок только формируется. Следим за тем, что появляется.