Бэкдор в xz utils: безопасность цепочки поставок open source - это не для юристов, а для архитекторов
Разбор инцидента с xz utils и почему атаки на цепочку поставок open source меняют требования к архитектурным решениям - не к юридическим.
В конце марта 2024 года исследователь безопасности Андрес Фройнд обнаружил, что в библиотеку xz utils - инструмент сжатия, который присутствует в большинстве дистрибутивов Linux - был намеренно встроен бэкдор. Это не была случайная уязвимость. Это была многолетняя, тщательно спланированная операция: злоумышленник под псевдонимом Jia Tan на протяжении двух лет вёл себя как добросовестный контрибьютор, заработал доверие сообщества, получил права на публикацию релизов - и в финале встроил вредоносный код.
Бэкдор был обнаружен до того, как попал в стабильные релизы большинства крупных дистрибутивов. Масштабного ущерба удалось избежать. Но этот инцидент - учебный пример для разговора о том, как устроена безопасность в мире open source зависимостей.
Почему это не история про "кто-то что-то взломал"
Классическая модель кибератаки - злоумышленник находит уязвимость и эксплуатирует её. Здесь всё иначе: злоумышленник стал частью самой системы производства программного обеспечения. Он не взламывал извне - он был внутри, с легитимными правами.
Это называется атакой на цепочку поставок. Цель - не финальный продукт, а то, из чего он собирается. Внедрить вредоносный код в зависимость, которую используют тысячи других проектов, эффективнее, чем атаковать каждый из них по отдельности.
Для бизнеса это означает: даже если ваша собственная команда пишет чистый код - ваше программное обеспечение состоит из десятков или сотен компонентов, которые написали другие люди. И это поверхность атаки.
Что это означает для архитектора, не для юриста
Когда такие инциденты происходят, первая реакция многих компаний - запросить у ИТ-отдела "оценку рисков" или спросить у юристов, нужно ли что-то делать с лицензионными соглашениями. Это неверный уровень реакции.
Вопросы, которые стоит задать на архитектурном уровне:
Первый - знаем ли мы, что именно запущено в наших системах? Это называется SBOM - software bill of materials, перечень компонентов программного обеспечения. Большинство компаний не имеют актуального SBOM даже для критических систем.
Второй - как быстро мы можем обновить конкретную зависимость во всех местах, где она используется? Когда уязвимость обнаружена, скорость обновления критична. Если ответ "несколько недель" - это архитектурная проблема, не операционная.
Третий - как мы узнаём о новых уязвимостях в наших зависимостях? Это должен быть автоматизированный процесс, а не "услышали от коллеги из другой компании".
Ложная безопасность "мы используем только известные библиотеки"
Один из распространённых ответов: "нас это не касается, мы используем только широко известные библиотеки от крупных организаций". xz utils - это и есть именно такая библиотека. Она входит в состав Red Hat, Debian, Ubuntu, openSUSE. Широко известная, давно существующая, с историей.
Атака на цепочку поставок целит именно в такие компоненты - те, которым доверяют по умолчанию.
Практические меры, которые имеет смысл рассмотреть
Это не призыв немедленно всё переделать. Это призыв иметь осознанный подход:
- Есть ли у нас перечень ключевых open source зависимостей для критических систем?
- Подписаны ли мы на уведомления об уязвимостях (CVE) для наших ключевых зависимостей?
- Какой процесс у нас для экстренного обновления зависимости?
- Проверяем ли мы целостность пакетов при установке?
- Есть ли у нас изоляция между системами, чтобы компрометация одной зависимости не давала доступ ко всему?
Инцидент с xz utils - это не повод для паники. Это повод задать себе вопрос: насколько мы понимаем, из чего состоит наш программный стек.