Доверие к цепочке поставок программного обеспечения
Бизнес зависит от чужих компонентов и обновлений. Это архитектурный вопрос, а не только вопрос безопасности.
Когда я смотрю на типичную корпоративную систему, я почти всегда вижу одно и то же: несколько десятков сторонних библиотек, несколько внешних сервисов, операционная система с регулярными обновлениями, несколько компонентов с открытым исходным кодом. Всё это работает вместе, и большая часть этого кода написана не командой компании.
Это само по себе нормально. Невозможно и не нужно писать всё с нуля. Но у этого есть следствие, которое редко обсуждается явно: компания зависит от решений и процессов чужих организаций. И когда что-то в этой цепочке идёт не так - у компании может не быть ни предупреждения, ни времени на реакцию.
Что такое цепочка поставок программного обеспечения
Цепочка поставок в контексте ПО - это весь путь от исходного кода до работающей системы. Сюда входят библиотеки с открытым кодом, коммерческие компоненты, инструменты сборки, репозитории, из которых загружаются зависимости, сервисы обновлений операционных систем и приложений.
Каждое звено в этой цепочке - это точка, через которую в систему может попасть что-то нежелательное. Не только через атаку, но и через ошибку: обновление, которое сломало совместимость; библиотека, которую автор перестал поддерживать; зависимость с критической уязвимостью, о которой компания узнаёт не сразу.
Почему это архитектурный вопрос
Обычно разговор про цепочку поставок ПО попадает в повестку безопасности. Это правильно, но недостаточно.
Это архитектурный вопрос потому, что решения принимаются на этапе проектирования: какие компоненты использовать, насколько глубоко встраивать внешние зависимости, как изолировать части системы друг от друга, насколько сложно будет заменить один компонент другим при необходимости.
Если архитектура предполагает глубокую встройку сторонних компонентов без изоляции, то любая проблема в этом компоненте становится проблемой всей системы. Замена занимает месяцы. Обновление с трудом проверяется. Уязвимость трудно изолировать.
Обратная ситуация - система, в которой сторонние компоненты используются через чёткие границы - позволяет заменить компонент, заморозить версию, изолировать проблему без переписывания половины системы.
Что конкретно стоит проверить
Я не говорю о том, что нужно строить всё своими руками или отказываться от сторонних компонентов. Я говорю о том, что зависимость нужно осознавать и управлять ею намеренно.
Несколько вопросов, которые помогают это сделать:
Знает ли команда, от каких внешних компонентов зависит система? Не "примерно", а конкретный список с версиями. Если этого списка нет - это уже риск.
Как быстро компания узнаёт об обновлениях безопасности в используемых компонентах? Через официальные каналы? Через случайную новость?
Что произойдёт, если один из ключевых сторонних компонентов прекратит поддержку или изменит условия использования? Есть ли запасной вариант?
Проверяются ли обновления перед применением в продакшене, или они накатываются автоматически и немедленно?
Обновления как отдельная тема
Автоматические обновления удобны. Они закрывают уязвимости без ручного труда. Но они также означают, что изменения в чужом коде попадают в продакшен без проверки.
Это не аргумент против обновлений - устаревшие компоненты с известными уязвимостями ещё опаснее. Это аргумент за процесс: тестовый стенд, который принимает обновление раньше продакшена; минимальное время на проверку совместимости; процедура отката, если что-то сломалось.
Практический минимум
Организовать управление зависимостями можно без больших затрат. Минимум выглядит так:
- Поддерживайте явный список всех внешних зависимостей с версиями - это называется software bill of materials, пусть даже в простом формате.
- Подпишитесь на уведомления о безопасности для ключевых компонентов.
- Настройте тестовую среду, через которую проходят обновления перед продакшеном.
- Определите, какие компоненты критичны и какой у вас план, если они стали недоступны или небезопасны.
Цепочка поставок ПО - это не экзотический риск. Это ежедневная реальность любой компании, которая использует программное обеспечение. А таких компаний сейчас большинство.