Защита сборки: проверка контрольных сумм с помощью Preflight

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

• File Checksums
• Using Preflight
• Programmatic Checks
• Creating Hashes With Preflight
• Adding Malware Scans
• What About Other Kinds of Dependency?
• Альтернативы и шаблоны
• Краткое резюме

Проблема: поставочная цепочка и почему это важно

Риски атак на поставочную цепочку (supply chain) выросли после инцидентов с SolarWinds и Codecov. Злоумышленники компрометируют upstream-поставщиков, чтобы внедрить вредоносный код в конечный продукт.

Многие сборки загружают бинарники или скрипты извне. Запускать их «как есть» опасно: как вы убедитесь, что файл на сервере не заменён? Простой пример опасной команды:

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

Эта конструкция удобна, но даёт полный контроль над вашей системой, если сервер скомпрометирован.

Контрольные суммы файлов (File Checksums)

Идея простая: сравнить вычисленную на месте контрольную сумму файла с эталонной, опубликованной доверенным источником. Если суммы совпадают — вероятность подмены очень мала.

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

Preflight принимает путь к бинарю (или данные из stdin) и ожидаемую контрольную сумму. Если контрольные суммы совпадают — файл выполняется; если нет — выполнение прерывается.

Как использовать Preflight

Preflight можно скачать с релизов на GitHub или установить через Homebrew как пакет preflight.

В простейшем случае замените опасную конвейерную конструкцию на вызов через Preflight:

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

Теперь скрипт выполнится только если его SHA256 совпадает с указанным. Preflight поддерживает sha256, sha1 и md5.

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

Программные проверки (Programmatic Checks)

Иногда нужно просто проверить соответствие и выполнить логику в зависимости от результата, не запускают файл напрямую. Для этого есть команда preflight check:

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

Команда возвращает код выхода 0 при совпадении и 1 при расхождении. Preflight также выводит диагностические сообщения в stdout.

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

Не все проекты публикуют хэши релизов. Preflight умеет генерировать хэш локально:

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

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

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

Добавление проверки на вредоносные приложения (Malware Scans)

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

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

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

Для каких зависимостей это подходит

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

• vendor scoping и private registries;
• verifiable builds (reproducible builds);
• lock-файлы (package-lock.json, composer.lock, etc.) и их подпись;
• SBOM (Software Bill of Materials) и проверка целостности зависимостей.

Preflight должен быть частью многоуровневой стратегии защиты.

Когда проверка контрольных сумм не спасёт (контрпримеры)

• Если исходный поставщик публикует правильную контрольную сумму, но сам бинарник содержит уязвимость или бекдор — совпадение не поможет.
• Если злоумышленник имеет контроль над сервером, где хранится и бинарь, и подписанный хэш, простая проверка с сервера не защитит.
• Если ваша цепочка доверия зависит от недоверенных источников (например, общие скрипты CI в публичных репозиториях), атакующий может модифицировать и места чтения хэшей.

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

• Подпись релизов (GPG) и проверка подписи вместо (или наряду с) контрольными суммами.
• Использование контейнеров и доверенных реестров с политиками сканирования образов.
• Reproducible builds и независимая верификация сборок.
• SBOM и динамическое отслеживание поставленных пакетов.

Модель принятия решений: когда применять Preflight

1. Если вы скачиваете готовые бинарники/скрипты от внешнего вендора — применяйте Preflight.
2. Если зависимости приходят через пакетный менеджер — используйте lock-файлы, private registry и статический анализ.
3. При высоком уровне доверия к поставщику добавляйте подписи и автономный контрольный репозиторий для хэшей.

Практическое руководство (SOP) для CI/CD

1. Скачайте бинарник в шаге CI в артефакт-степе, не запускайте сразу.
2. Проверяйте контрольную сумму с помощью preflight check.
3. Если совпадает, сохраняйте бинарник как артефакт и подпишите его локально.
4. Используйте только зафиксированные хэши из защищённого хранилища (например, приватный Git под ограниченным доступом) для следующих прогонов.

Пример шага в CI (псевдокод):

- name: Download tool
  run: wget https://example.com/tool.tar.gz -O tool.tar.gz

- name: Check checksum
  run: cat tool.tar.gz | preflight check sha256=${{ secrets/KNOWN_TOOL_SHA256 }}

- name: Extract
  if: success()
  run: tar xzf tool.tar.gz

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

Разделите ответственность между ролями:

• DevOps/Build-инженер: хранение и обновление эталонных хэшей, интеграция в CI.
• Разработчик: запуск локальных проверок перед добавлением внешних ссылок в репозиторий.
• Security: аудит источников, проверка поставщиков, настройка PF_FILE_LOOKUP и мониторинг.

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

• Все прямые загрузки бинарников в CI имеют шаг проверки контрольной суммы.
• Эталонные хэши хранятся в репозитории с ограниченным доступом и версионируются.
• Preflight присутствует в доверенном хранилище бинарников или собирается из исходников.

Тестовые сценарии и приёмочные тесты

• Позитивный тест: скачивание тестового файла с известной суммой — preflight check возвращает 0.
• Негативный тест: модифицированный файл — preflight check возвращает 1 и не выполняется.
• Интеграционный тест CI: шаг проверки прерывает пайплайн при несовпадении.

Шаблон хранения и обновления хэшей (примеры)

Таблица в репозитории (MD):

Процесс обновления: получить релиз, проверить подпись (если есть), сгенерировать хэш локально, создать PR с изменением таблицы, провести код-ревью и merge.

Безопасное хранение самого Preflight

Есть определённая ирония: вы полагаетесь на сторонний инструмент для проверки сторонних инструментов. Подходы для уменьшения риска:

• Собирайте Preflight из исходников под контролем вашего CI и храните бинарник в внутреннем артефакт-хранилище.
• Подписывайте бинарник Preflight и проверяйте подпись перед использованием.
• Ограничьте источник установки Homebrew для production-агентов.

Короткая справка (глоссарий, 1 строка)

• Контрольная сумма: короткая фиксация содержимого файла (хэш) для проверки целостности.
• SBOM: список компонентов в программном продукте.
• Vendor scoping: настройка менеджера пакетов на загрузку пакетов только из доверенных источников.

Риски и смягчающие меры

• Риск: ложные сигнатуры в списках вредоносного ПО. Смягчение: ручная проверка и контекстная оценка.
• Риск: компрометация сервера с хэшами. Смягчение: хранение хэшей в версионируемом приватном репозитории и подпись.
• Риск: уязвимость в проверяемом бинарнике. Смягчение: интеграция сканирования SAST/DAST и код-ревью поставщика.

Краткое резюме

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

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

Если нужно, я могу: предоставить готовые CI-шага для популярных CI-провайдеров, шаблоны таблиц хэшей для вашего репозитория или Mermaid-диаграмму процесса интеграции Preflight в пайплайн.