Перед установкой обновления обычно проверяют, что оно пришло от привычного поставщика. Для собственного приложения похожим доказательством становится зелёный запуск сборки. Но ни знакомое имя, ни успешные тесты не отвечают на весь вопрос: из чего получился этот файл и кто мог изменить его до попадания к пользователям?
Software Supply Chain Security рассматривает путь поставки целиком. Собственный код, сторонняя библиотека, среда сборки и хранилище готовых пакетов могут иметь разных владельцев и разные правила доступа. Защищённый рабочий сервер всё равно исполнит опасную программу, если обычная процедура выпуска доставит её как разрешённое обновление.
Что входит в поставку помимо нашего кода
Представим сервис обмена документами. В него входят библиотека чтения файлов, её зависимости, базовый образ и инструменты сборки. Изменение любого компонента способно изменить результат, хотя разработчик продукта не правил бизнес-логику. Некоторые инструменты работают только при сборке, но имеют доступ к её файлам и полномочиям.
Поэтому полезен воспроизводимый перечень входных материалов и разрешённых источников. Фиксация версии или контрольной суммы уменьшает риск незаметной подмены между сборками. Она не делает выбранную версию безопасной навсегда: обновление, проверка и вывод уязвимого компонента остаются работой команды.
У названного тега могут меняться данные. Например, GitHub рекомендует фиксировать сторонние Actions полным SHA коммита. Это связывает запуск с определённым содержимым, но не подтверждает добросовестность самого содержимого. Требуется понимать и то, какие полномочия получит подключённый шаг.
Сборщику не обязательно иметь право выпускать
Проверка неподтверждённого изменения должна быть отделена от публикации рабочего релиза. Если тест чужого предложения получает ключ от production, доступ уже выдан до принятия кода. Общий постоянный сервер сборки также может перенести нежелательные файлы или процессы из одного задания в следующее.
Стоит разделить проверку, выпуск пакета и развёртывание: какие входы разрешены каждому этапу, кто их изменяет и где появляются рабочие полномочия. Исправление инструкции сборки заслуживает ревью не меньше исправления приложения. Особенно если эта инструкция может подписать и опубликовать результат.
Изолированные исполнители, ограниченные права и временные учётные данные уменьшают часть риска. Но доступ к изменению доверенного процесса остаётся сильным полномочием. Workload Identity сокращает распространение постоянных ключей; она не должна выдавать рабочий доступ любому заданию только потому, что оно запущено знакомой платформой.
Состав, происхождение и безопасность — разные доказательства
SBOM — перечень программных компонентов поставки. Он помогает искать продукты с определённой библиотекой. Полнота зависит от способа получения: список объявленных зависимостей не всегда включает то, что дополнительно скачал сценарий сборки. Его нужно связывать с конкретным готовым пакетом, а не просто хранить рядом с репозиторием.
Подтверждение происхождения, provenance, описывает, как получен результат: из какого источника, каким сборщиком и с какими параметрами. Подпись позволяет проверить соответствующее утверждение и доверенную сторону. Она не означает, что подписанная программа не содержит уязвимостей или намеренно вредных действий.
При приёмке сверяют идентификатор содержимого, доверенного сборщика, допустимый источник и существенные параметры. Такую проверку описывает SLSA. Если система принимает любую корректную подпись любого проекта, происхождение проверено формально, а нужная граница доверия отсутствует.
Одной генерации подтверждений недостаточно: кто-то должен проверить их перед использованием. Это отдельно подчёркивает документация GitHub по attestations. Хранить свидетельство в архиве и запрещать запуск неподходящего пакета — разные возможности.
Как найти то, что уже работает у клиентов
При сообщении об опасной библиотеке нужен ответ не только «она есть в коде». Какие версии продукта её содержат, где они развёрнуты, какие старые установщики ещё доступны? Связь между составом, неизменяемым идентификатором пакета и местом эксплуатации превращает инвентаризацию в инструмент реагирования.
Результаты сканирования требуют оценки: компонент может входить в пакет, но опасный путь зависит от его использования и конфигурации. Обратное тоже верно: чистый отчёт не доказывает отсутствие неизвестной проблемы. При исключении из блокирующей проверки фиксируют основание, владельца и срок пересмотра, а не отключают сканер целиком.
После компрометации одного обновления может быть недостаточно. Надо разобраться с доступами сборщика, опубликованными пакетами и возможным использованием украденных секретов. Замена библиотеки не отзывает ключ, который успели скопировать. Возврат старой версии также требует проверки её происхождения и пригодности.
Проверка на одном выпуске
Выберите готовый пакет и проследите его обратно до исходников и сборки. Затем в контролируемом испытании предложите проверке пакет с другой контрольной суммой, неподходящим источником или без обязательного подтверждения. Важен фактический отказ в публикации, а не присутствие очередного отчёта.
После этого найдите все места установки выбранной версии и определите порядок её замены. Если процедура требует искать автора релиза в переписке, следующим полезным улучшением будет учёт поставок. Большая платформа проверки происхождения не заменит этой простой связи между выпущенным файлом и работающим продуктом.