Риск цепочки поставок до эпохи SBOM: почему зависимости уже надо считать системно
Непрозрачность транзитивных зависимостей - это не академическая проблема. Это уже работающий вектор атаки.
Когда компания покупает программное обеспечение или берёт готовую библиотеку, она думает о том, что получает. Редко кто думает о том, что приходит вместе с этим: какие другие компоненты вложены внутрь, кто их написал, когда они последний раз обновлялись и есть ли в них известные уязвимости.
Это и есть проблема цепочки поставок программного обеспечения. Она не новая. Но масштаб, в котором код переиспользуется сегодня, делает её значительно острее, чем пять лет назад.
Как устроена проблема
Современное приложение не состоит из кода, написанного только одной командой. В типичном проекте на Java или Python десятки прямых зависимостей, каждая из которых тянет свои - и так рекурсивно. Реальное дерево зависимостей небольшого проекта легко насчитывает несколько сотен компонентов.
Большинство из них никто в команде не читал. Их берут потому, что они решают задачу - парсинг XML, работа с датами, HTTP-клиент. Доверие к ним основано на репутации и популярности, а не на аудите кода.
Злоумышленник, который хочет попасть в систему, может выбрать путь не через основное приложение, а через одну из этих зависимостей. Если уязвимость в популярной библиотеке - она сразу присутствует во всех проектах, которые её используют - та же логика, которую инцидент Flame обнажил на уровне доверия к каналу доставки обновлений.
Что уже происходило
Случаи компрометации через зависимости не гипотетические. Инциденты с внедрением вредоносного кода в опенсорсные пакеты уже фиксировались - пока редко, пока без широкого резонанса. Но вектор понятен: если кто-то контролирует популярный пакет, он контролирует небольшую часть кода огромного числа систем.
Отдельная тема - не намеренные атаки, а просто незакрытые уязвимости. Библиотека с известной CVE может оставаться в продуктиве годами, если никто систематически не отслеживает состояние зависимостей. Это не теоретический риск - это рутинная ситуация в большинстве проектов.
Что значит считать зависимости системно
Системный подход к зависимостям - это не паранойя и не требование аудировать каждую строчку чужого кода. Это несколько конкретных практик.
Знать, что у тебя есть. Список всех прямых и транзитивных зависимостей должен быть явным, а не неявным следствием билда. Инструменты для этого существуют - и в Java-экосистеме (Maven, Gradle), и в Python (pip freeze), и в других стеках.
Отслеживать известные уязвимости. Базы данных CVE публичны. Инструменты, которые сопоставляют список зависимостей с базой уязвимостей, уже существуют, хотя и не стали стандартом. Запускать такую проверку при сборке - несложно.
Понимать происхождение. Откуда берётся пакет? Кто его поддерживает? Когда последнее обновление? Если ответы на эти вопросы "не знаем" - это риск, который стоит оценить осознанно.
Управлять обновлениями. Бесконечное откладывание обновлений зависимостей - это технический долг с ненулевой ценой с точки зрения безопасности. Регулярный процесс обновлений лучше, чем авральный апгрейд после публикации критической CVE.
Практические вопросы
Для оценки ситуации в конкретной организации полезны несколько вопросов:
- Есть ли у нас список всех компонентов в продуктивных системах - не только собственного кода?
- Есть ли процесс, который реагирует на публикацию критической уязвимости в популярной библиотеке?
- Кто принимает решение об использовании нового внешнего пакета?
- Как долго в среднем живёт незакрытая уязвимость в зависимостях у нас?
- Есть ли изоляция между компонентами - или компрометация одной зависимости даёт доступ ко всему?
Стандарты и инструменты для систематического управления составом программного обеспечения появятся в индустрии позже. Но ждать их, чтобы начать думать об этом, не нужно.