Угрозы цепочке поставок

Атака на цепочку поставок программного обеспечения компрометирует организацию не напрямую, а через повреждение того, чему она доверяет и что использует: библиотеки, инструмента сборки, базового образа контейнера или сервера обновлений.

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

• Инверсия доверия — граница безопасности выходит за пределы собственного кода
• Транзитивный радиус поражения — один вредоносный пакет распространяется в тысячах сборок

Когда Вы добавляете одну прямую зависимость, часто автоматически подключаются десятки транзитивных зависимостей, которые Вы никогда не выбирали. Типичное приложение на Node или Python объявляет несколько пакетов, но в итоге включает сотни зависимостей.

Перечислите всё дерево разрешённых зависимостей, а не только манифест, чтобы увидеть, что именно Вы поставляете:

Злоумышленники публикуют вредоносные пакеты с именами, похожими на имена популярных пакетов, рассчитывая на опасную опечатку.

• Тайпсквоттинг — reqeusts вместо requests
• Комбосквоттинг — python-requests, имитирующий настоящее имя
• Путаница зависимостей — публикация общедоступного пакета с тем же именем, что и у Вашего внутреннего закрытого пакета, из-за чего неправильно настроенный механизм разрешения зависимостей загружает версию злоумышленника

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

Легитимный, широко используемый пакет может стать вредоносным, если учётная запись его сопровождающего будет скомпрометирована или злоумышленник-участник получит права на публикацию.

Недавние реальные инциденты показывают, как злоумышленники выведывают учётные данные сопровождающих с помощью фишинга, а затем выпускают заражённое исправление, которое похищает токены во время установки.

• Требуйте двухфакторную аутентификацию для всех учётных записей, используемых для публикации
• Отдавайте предпочтение пакетам с токенами публикации с ограниченной областью действия и защищёнными выпусками
• Следите за появлением неожиданных новых сопровождающих у критически важных зависимостей

Во многих экосистемах код выполняется во время установки, ещё до запуска Вашего приложения. Команда npm install может выполнить обработчик postinstall, который похитит переменные окружения или ключи SSH.

Отключайте произвольные сценарии установки в среде непрерывной интеграции и проверяйте все пакеты, которым они необходимы:

Сама среда сборки представляет собой ценную цель. Если злоумышленник внедрит вредоносный код в компилятор, образ исполнителя непрерывной интеграции или плагин сборки, каждый созданный им артефакт будет содержать скрытый доступ, даже если Ваш исходный код чист.

Классический пример — троянизированный механизм обновления, который подписывает вредоносное ПО легитимным ключом подписи кода, поэтому жертвы принимают его за подлинное.

• Относитесь к инфраструктуре сборки как к рабочей инфраструктуре и полностью укрепляйте её
• Используйте временные воспроизводимые исполнители сборки
• Отделяйте ключи подписи от узла сборки

Файл блокировки фиксирует точные версии и хеши содержимого, поэтому повторное разрешение зависимостей не сможет незаметно подменить артефакт. Всегда добавляйте этот файл в репозиторий и позволяйте среде непрерывной интеграции проверять его, а не свободно разрешать зависимости заново.

В поле целостности хранится хеш; если загруженный архив не совпадает с ним, установка завершается с ошибкой.

Версии с известными уязвимостями (отслеживаемые как CVEs) — наиболее распространённая слабость цепочки поставок. Инструменты анализа состава программного обеспечения (SCA) сопоставляют разрешённые зависимости с базами данных уязвимостей.

Запускайте сканирование в среде непрерывной интеграции и останавливайте сборки при обнаружении критических проблем:

Плавающие диапазоны версий (^1.2.0) позволяют новым выпускам автоматически попадать в проект. Это удобно, но подвергает Вас риску вредоносного исправления.

• Фиксируйте точные версии и осознанно проверяйте обновления
• Фиксируйте по дайджесту версии образов контейнеров, а не по изменяемым тегам вроде latest
• Включайте критически важные зависимости в собственный репозиторий или зеркало, чтобы удаление из исходного источника не нарушило Вашу работу и не привело к заражению

Защита цепочки поставок — это постоянный процесс, а не разовая проверка. Вам необходимо знать, что Вы поставляете, откуда это поступило и когда это станет уязвимым.

• Создавайте SBOM для каждого выпуска (в следующем уроке)
• Фиксируйте происхождение сборки, чтобы можно было доказать, как был создан артефакт
• Подпишитесь на уведомления об уязвимостях, чтобы новая CVE запускала повторную оценку уже выпущенных сборок

Отобразите каждый этап, на котором появляется ненадёжный ввод: компьютеры разработчиков, системы управления исходным кодом, реестры зависимостей, систему сборки, хранилище артефактов и канал обновлений. Каждый из них может стать точкой внедрения.

Для каждого этапа спросите: кто может вносить сюда изменения, что позволит ему сделать компрометация и как Вы её обнаружите? Такой подход даёт приоритизированный список мер защиты, а не общий контрольный список.

Проверьте понимание распространённого класса атак на цепочку поставок.

Вы узнали, почему зависимости являются векторами атак и как уменьшить связанную с ними уязвимость.

• Инверсия доверия означает, что Ваша безопасность зависит от третьих сторон, которые Вы не контролируете
• К основным угрозам относятся: тайпсквоттинг, путаница зависимостей, захват учётной записи сопровождающего, вредоносные сценарии установки и скомпрометированные инструменты сборки
• Основные средства защиты: файлы блокировки с хешами целостности, сканирование с помощью SCA, точная фиксация по дайджесту, двухфакторная аутентификация для издателей и непрерывный мониторинг

Далее Вы составите точный перечень содержимого программного обеспечения с помощью SBOM.