Кратко

  • Криптографически корректная аттестация GitHub связывает дайджест артефакта с зафиксированным происхождением сборки, но не удостоверяет безопасность артефакта.
  • Решающий контроль остаётся у потребителя: развёртывание следует отклонять, если репозиторий, неизменяемая идентичность workflow, условие коммита или релиза, среда либо граница доверия к runner не соответствуют политике.
  • Аттестации закрытых репозиториев используют экземпляр Sigstore от GitHub без публичного журнала прозрачности, применяемого для открытых репозиториев. Это различие в наблюдаемости, а не доказательство слабости.

Подпись верна, но доступ закрыт

На вход системы развёртывания поступает контейнерный образ. Подпись проверена, дайджест совпадает, заявление о происхождении не изменено. Тем не менее система отклоняет образ. В записи может фигурировать неожиданный репозиторий. Повторно используемый workflow мог быть подключён по перемещаемому тегу. Коммит может не входить в утверждённую ветвь релиза, среда — не соответствовать назначению, а runner — находиться за пределами принятой границы доверия.

Такой отказ не означает, что аттестация не сработала. Напротив, он показывает, что сведения о происхождении участвуют в реальном контроле допуска.

GitHub описывает аттестации артефактов как криптографически подписанные заявления, устанавливающие происхождение сборки. Они могут указывать связанный workflow, репозиторий, организацию, среду, SHA коммита и событие, запустившее процесс. Дополнительные сведения могут поступать из идентичности OpenID Connect, использованной для подтверждения происхождения.

В workflow аттестация создаётся после сборки; для этого выдаются разрешения на токен идентичности и запись заявления. Для бинарного файла субъектом служит полученный файл. Для контейнера полное имя и дайджест связывают документ с конкретным содержимым, а не только с изменяемым тегом. Потребитель может проверить, что предъявленный объект соответствует объекту, полученному по заявленному маршруту.

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

GitHub прямо проводит эту границу. Само создание заявления не даёт преимуществ для безопасности: его необходимо проверять. Наличие аттестации также не гарантирует, что артефакт безопасен. Потребитель должен определить критерии, оценить содержание и принять решение о риске. Проверка одной лишь подлинности подписи оставляет без ответа главный вопрос: допустим ли подписанный маршрут?

Политика превращает происхождение в решение

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

Поэтому важна неизменяемая идентичность workflow. GitHub называет полный SHA коммита самым безопасным способом сослаться на внешний повторно используемый workflow. Ветка движется вперёд, а тег можно переназначить. Аттестация способна точно зафиксировать ссылку, содержимое которой уже не совпадает с проверенной версией. Если политика сверяет только имя workflow, часть определения сборки остаётся вне допуска.

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

Доверие к runner образует самостоятельную границу. GitHub предупреждает, что для самостоятельно размещённых runners не гарантируются одноразовые чистые машины: недоверенный код workflow способен закрепиться в такой среде. Поэтому корректная аттестация не доказывает, что конкретный runner не был скомпрометирован. Допустимые группы runners и условия изоляции должны быть отдельно зафиксированы в политике.

От записи к принудительному допуску

Для Kubernetes GitHub документирует схему с Sigstore Policy Controller, корнем доверия GitHub и политикой образов кластера. После включения в выбранных пространствах имён контроллер способен проверять заявления до допуска образа и отклонять артефакты, не соответствующие политике доверия.

Именно настройки определяют фактическую защиту. Одна установка контроллера ничего не принуждает выполнять. Политику требуется добавить и включить в нужном пространстве имён. Шаблоны соответствия образов и исключения также меняют область контроля. Поэтому заявление о том, что организация «использует аттестации», ничего не говорит о том, какие развёртывания действительно защищены.

Есть и различие в наблюдаемости открытых и закрытых репозиториев. Публичные аттестации используют общественный экземпляр Sigstore и записываются в неизменяемый, общедоступный журнал прозрачности. Закрытые репозитории используют экземпляр Sigstore от GitHub на той же кодовой базе, но без публичного журнала и с федерацией только с GitHub Actions. Возможности независимого внешнего наблюдения различаются; само по себе это не доказывает слабость закрытого механизма.

Доступные первичные источники не раскрывают общую долю внедрения, частоту отказов или уровень ложных допусков. Они также не подтверждают, что все потребители применяют политики либо что конкретный runner оставался чистым. Эти пробелы нельзя заполнять предположениями.

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

Источники