Preflight: защита от подмены файлов в цепочке поставок

Быстрые ссылки

File Checksums
Using Preflight
Programmatic Checks
Creating Hashes With Preflight
Adding Malware Scans
What About Other Kinds of Dependency?
Summary

Руки печатают на ноутбуке

Опасность атак на цепочку поставок выросла после инцидентов вроде SolarWinds и Codecov. Злоумышленники, получив контроль над поставщиком кода, могут подложить изменённые или вредоносные файлы в релизы — а ваши сборки могут автоматически подтянуть и выполнить такие файлы.

Многие сборочные скрипты скачивают внешние зависимости во время выполнения. Если вы выполняете скачиваемый скрипт «как есть», легко подхватить подменённый файл:

curl https://example.com/install-script.sh | sh

Этот пример демонстрирует базовую технику атаки: удобный, но опасный пайплайн. Если сайт example.com скомпрометирован, вы дали нападавшим прямой доступ к системе.

Проверки контрольных сумм

Идея простая: сравните контрольную сумму скачанного файла с заранее известной эталонной суммой. Многие проекты публикуют хэши релизов (SHA256, SHA1, MD5). Выполняйте файл только если рассчитанная сумма совпала с ожидаемой.

Повторять эти сравнения вручную в скриптах быстро утомительно. Preflight автоматизирует этот процесс: он принимает путь к бинарю или поток данных и ожидаемую контрольную сумму. Если значения совпадают, файл выполняется; в противном случае выполнение отменяется и ваш CI остаётся защищённым.

Когда проверка помогает

Защита от подмены файла на сервере релизов.
Прямые скачивания с веб-сайтов или ссылок в скриптах.
Быстрая автоматическая валидация в CI перед запуском инсталляторов.

Ограничения метода

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

Использование Preflight

Preflight доступен в релизах на GitHub и как пакет preflight в Homebrew. Везде, где вы могли бы написать | sh, вместо этого можно использовать Preflight и указать ожидаемый хэш:

curl https://example.com/install-script.sh | preflight run sha256=abc...123

Только если скачанный скрипт соответствует sha256=abc…123, он будет выполнен. Поддерживаемые типы хэшей: sha256, sha1, md5.

Скриншот неудачной проверки Preflight — сообщение об ошибке

Важно: жёстко зашивайте известные контрольные суммы в сборочные скрипты. Не скачивайте файл с контрольными суммами с того же сервера, что и целевой файл — компрометированный сервер может подложить и фейковую контрольную сумму.

Программные проверки

Если нужно принять решения (например, остановить сборку или отправить предупреждение) в зависимости от результата сравнения, используйте режим проверки без исполнения:

curl https://example.com/install-script.sh | preflight check sha256=abc...123

Код возврата 0 означает совпадение. Код возврата 1 — обнаружено несоответствие. Preflight также выводит понятное сообщение об ошибке в stdout/stderr.

Создание хэшей с помощью Preflight

Если проект не публикует хэши, вы можете сгенерировать их локально:

wget https://example.com/install-script.sh
preflight create install-script.sh

По умолчанию генерируется SHA256. Для SHA1 или MD5 используйте флаг --digest.

Практический совет: сохраняйте созданный хэш в системе управления версиями вместе с ссылкой на конкретную версию/артефакт и записью о том, откуда скачан файл.

Добавление сканирования на вредоносное ПО

Preflight поддерживает опциональное сопоставление контрольных сумм со списком известных вредоносных сигнатур. Такие списки предоставляет сторонний сервис — это обычный текстовый файл со списком хэшей. Один из поставщиков — Malshare.

Установите переменную окружения PF_FILE_LOOKUP, указывающую на путь к файлу со списком хэшей. Preflight обнаружит переменную и включит проверку по списку при запуске preflight check или preflight run. Если контрольная сумма совпадёт с записью в списке — проверка провалится.

Важно: списки сигнатур тоже могут быть поддельными; выбирайте надёжных поставщиков и ограничивайте доступ к архивам сигнатур.

Что с зависимостями, устанавливаемыми пакетными менеджерами

Preflight предназначён для статических файлов и предсобранных бинарников. Использовать его с пакетными менеджерами (npm, Composer, NuGet, Maven и т. п.) менее удобно, потому что:

Пакеты собираются и доставляются через репозитории.
Менеджеры пакетов имеют собственные механизмы проверки целостности и подписи (иногда).

Вместо Preflight для пакетов используйте фичи самих менеджеров: vendor scoping, зафиксированные версии, проверенные репозитории и подписи пакетов. Preflight — часть набора мер, а не универсальное решение.

Когда Preflight не сработает

Поставщик уже выложил подложенный файл и правильно опубликовал хэш — проверка пройдёт, но файл вредоносный изначально.
Если злоумышленник скомпрометировал и сервер с бинарём, и место, где вы храните эталонный хэш.
Для пакетов с динамической компиляцией и зависимостей внутри реестров Preflight не проверит транзитивный код.

Альтернативные и дополнительные подходы

Подпись релизов GPG/ASC — даёт криптографическую аутентификацию издателя.
Подпись бинарей (code signing) — важна для распространения на десктопах и мобильных платформах.
Реплики внутренних серверов и локальные зеркала — уменьшает зависимость от внешних хостингов.
Сканеры SCA (Software Composition Analysis) для управления зависимостями и поиска известных уязвимостей.

Ментальные модели и эвристики

Доверяй, но проверяй: источник может быть легитимным, но компрометация возможна.
Минимизация доверия: ограничьте количество компонентов, которым вы автоматически доверяете.
Зафиксированный контракт: один артефакт = одна контрольная сумма; изменив артефакт, вы обновляете хэш и фиксируете версию.

Факты

Поддерживаемые типы хэшей: SHA256, SHA1, MD5.
Коды возврата: 0 при совпадении, 1 при расхождении.
Конфигурация для списков вредоносных сумм через PF_FILE_LOOKUP.

Playbook внедрения Preflight в CI

Инвентаризация: найдите все шаги сборки, где выполняются внешние скачивания.
Для каждого скачивания получите эталонный хэш (из репозитория, релиза или сгенерируйте локально).
Поместите эталонные хэши в репозиторий конфигурации (например, файл checksums.yml) рядом с кодом.
Замените команды | sh на | preflight run sha256= в CI-скриптах.
Добавьте preflight check как бо́льшую проверку в заранее определённых точках (основные ветки, релизы).
Настройте PF_FILE_LOOKUP и периодические обновления списка вредоносных сумм.
Документируйте процедуру обновления хэшей и лицо, ответственное за валидацию.

Ролевые чек-листы

Разработчик:

Не выполнять скачиваемые скрипты без проверки.
Вносить новые эталонные хэши в PR вместе с объяснением источника.

Инженер CI:

Интегрировать preflight в пайплайны.
Обеспечить отказоустойчивость скачивания preflight (локальные зеркала).

Инженер безопасности:

Контролировать поставщиков списков вредоносных сумм.
Регулярно ревьюить источники и процедуру обновления хэшей.

Дерево решений

flowchart TD
  A[Есть ли внешнее скачивание?] -->|Нет| B[Ничего не делать]
  A -->|Да| C[Есть ли эталонный хэш?]
  C -->|Да| D[Использовать preflight run]
  C -->|Нет| E[Сгенерировать хэш и проверить поставщика]
  E --> F{Поставщик надёжен?}
  F -->|Да| D
  F -->|Нет| G[Использовать внутреннее зеркало или альтернатива]

Критерии приёмки

Все места, где скачиваются внешние бинарники или скрипты, используют preflight run с зашитым хэшем.
CI возвращает ненулевой код при несовпадении хэша и блокирует мерж в основные ветки.
Обновление хэшей сопровождается аудиторским комментарием и процедурой проверки поставщика.

Итог

Атаки на цепочку поставок становятся всё более изощрёнными. Preflight — простой и эффективный инструмент для проверки целостности скачиваемых файлов перед их исполнением. Он не заменяет комплексную стратегию безопасности, но является важным элементом защиты: жёсткое хранение хэшей, интеграция в CI, сканирование по базам вредоносного ПО и внутренняя доставка бинарей значительно сокращают риск незаметной подмены.

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