Скил release-verify — пять шагов до любой установки
Релизы Datarim подписаны через cosign и несут аттестацию SLSA L2. Скил release-verify — рецепт для потребителя, чтобы проверить оба артефакта до распаковки архива.
Установка из релизного архива без проверки подписи — риск цепочки поставок. Скил release-verify отвечает на один вопрос: что запускает потребитель Datarim перед распаковкой релиза?
Релизы Datarim публикуются из Arcanada-one/datarim через рабочий процесс release.yml и подписываются с помощью Sigstore cosign в беспарольном режиме, используя GitHub OIDC как источник идентификации. Каждый релиз включает CycloneDX SBOM и аттестацию происхождения сборки SLSA уровня 2. Скил кодирует пятишаговый рецепт проверки, чтобы агент мог выполнить его без обращения к внешней документации.
Что входит в каждый релиз
Каждый тег релиза создаёт шесть артефактов: исходный архив, файл контрольной суммы SHA-256, cosign-пакет для архива, CycloneDX SBOM, cosign-пакет для SBOM и серверную аттестацию SLSA L2, прикреплённую к релизу через gh attestation verify. Исходный архив создаётся командой git archive HEAD с тегом в качестве префикса.
Пятишаговый рецепт
Шаг 1 скачивает все артефакты релиза через gh release download. Шаг 2 проверяет хеш архива командой sha256sum -c. Шаг 3 запускает cosign verify-blob для архива, привязывая его к точному URL рабочего процесса и тегу. Шаг 4 выполняет ту же проверку cosign для SBOM. Шаг 5 верифицирует происхождение сборки SLSA через gh attestation verify.
Ненулевой код выхода на любом шаге означает, что артефакт ненадёжен и не должен устанавливаться. Каждый шаг доказывает разное. Контрольная сумма на шаге 2 подтверждает, что архив дошёл без повреждений. Проверка cosign на шаге 3 доказывает, что он был собран через release.yml на точном теге в Arcanada-one/datarim, а подпись закреплена в журнале прозрачности Sigstore Rekor. Аттестация SLSA на шаге 5 подтверждает, что артефакт собран раннерами GitHub из исходного кода на конкретном коммите.
Скил явно поясняет, чего контрольная сумма сама по себе не доказывает: злоумышленник, способный подменить архив, одновременно подменит и файл .sha256. Шаг cosign связывает архив с конкретным источником сборки — воспроизвести это без доступа к OIDC-токену из того конкретного запуска рабочего процесса невозможно.
Флаг --certificate-identity важен
Один конкретный антипример в скиле: запуск cosign verify-blob только с --certificate-oidc-issuer и без --certificate-identity принимает подпись от любого подписанта, использующего тот же OIDC-провайдер. Любой рабочий процесс GitHub Actions из любого репозитория может получить сертификат и подписать произвольный архив. Флаг идентификации привязывает проверку к конкретному файлу рабочего процесса и тегу.
Зависимости и область применения
Для рецепта нужны cosign ≥ 3.0, gh ≥ 2.40, sha256sum и jq. Скил применяется только к релизным архивам. Для рабочих копий, полученных через git clone, проверка подписи выполняется через подписание коммитов — это отдельная политика.
Общую картину фреймворка даёт пост что такое Datarim. Правила цепочки поставок S4, делающие этот рецепт обязательным, описаны в статье о скиле security-baseline.