署名・Attestation・SLSAでAI 成果物を検証する

AI Artifactの検証では、artifact bytesのdigest、署名者/issuer、attestation subject、provenance predicate、builder/workflow identityをconsumer policyに照らして確認します。

署名が暗号学的に有効であることだけを、artifactの安全性、品質、無脆弱性、完全なdependency inventoryの証明にはしません。

mutable tagやfile nameではなくimmutable digestをrelease identityの基礎にします。署名・attestationのsubject digestが、実際にdeploy/useするartifact bytesのdigestと一致することを検証します。container index、platform別image、model weights、prompt bundle等、複数artifactがある場合は対象を曖昧にしません。

signature validityに加えて、期待するsigner identity、certificate issuer/OIDC issuer、repository/workflow/build identityをpolicyへ固定します。keyless署名で「Sigstore verificationが成功した」ことだけをsigner authorizationとして扱いません。KMS/key signingではkey ownership、rotation、revocation、build stepからのsecret isolationを確認します。

attestationが存在することと、そのpredicate内容を承認することを分離します。predicate type/version、builder、source、workflow、external parameters等をpolicyで評価します。signature verificationだけでpredicateの意味内容を自動承認しません。

SLSA provenanceはartifactがどのbuild process/platformから生成されたかを検証する材料です。builder.idをtrust boundaryとして扱い、許可するbuilderをconsumer側で管理します。SLSA Build L3であってもbuild platform自体の侵害まで防ぐ保証ではありません。externalParametersはuntrusted inputとしてdownstreamで検証します。resolvedDependenciesは有用ですが完全性はbest effortであり、完全SBOMと同一視しません。

AI releaseを単一containerだけで表現できない場合、model/model adapter、prompt/system instruction、agent graph/state-machine definition、tool/MCP schema、RAG/retrieval configuration、policy/guardrail configuration、runtime/container、dependency/SBOM reference、evaluation/acceptance artifactをmanifest化します。各構成物をdigestでbindし、release manifest自体もimmutableにします。

GitHub Artifact Attestationsを使用する場合、attestationを取得できることだけで完了としません。artifact digest、signature/timestamp、signer identity、repository/workflow等をgh attestation verify等で検証し、organization policyと照合します。SBOM等の別predicateを要求する場合はpredicate typeを明示します。

cosignではsignature/attestation verification時に期待identity/issuerとartifact digest claimを確認します。claim checkingを無効化する設定を使用した場合、何が未検証になるかを明示します。in-toto attestationではpredicateに対するpolicy validationを別途行います。

air-gapped/offline環境ではattestation bundleとtrusted root materialを持ち込みoffline verificationを行えます。ただしoffline trusted rootはrefresh後に発生したrevocationを自動的に知りません。trusted-root更新頻度とrevocation SLOを運用条件にします。

signature欠落、attestation欠落、subject mismatch、identity mismatch、predicate policy failure、trusted-root failureを暗黙にallowしません。例外はowner、理由、対象digest、期限を持つbreak-glassとして記録します。

release/deployment時にartifact/release digest、signer identity/issuer、builder/workflow identity、predicate type/version、policy revision、verification result/timestamp、trusted-root/bundle revision、exception statusを記録します。「署名済み」というラベルだけをreadback結果にしません。

wrong digest、mutable tag、unauthorized valid signer、wrong issuer、broad identity policy、builder compromise、predicate confusion、policy未評価、dependency omission、AI manifest欠落、prompt/config差替え、stale offline roots、key compromise/revocation lag、claim-check無効化、registry substitution、multi-arch ambiguity、fail-open admission、break-glass残置を想定します。

本項は2026-10-06時点のSLSA v1.2、Sigstore/cosign、GitHub Artifact Attestations公開資料に基づきます。organization artifactへのlive signing/verification、registry/admission/deployment mutationは未実施です。

AI Artifactの署名・attestation検証では、artifact bytesのdigest、署名者/issuer、attestation subject、provenance predicate、builder/workflow identityをconsumer policyに照らして検証します。署名が暗号学的に有効でも、artifactの安全性・品質・完全なdependency inventoryまでは保証しません。AI releaseを構成するmodel、prompt、agent/tool/RAG設定等はmanifestで列挙してdigest bindし、verification失敗時は暗黙にfail-openしない運用とします。

organization artifact types、signer/KMS/keyless identity、trusted builders/workflows、registry/admission system、SLSA target level、provenance predicate/version、dependency/SBOM requirements、model-weight signing format、prompt/config packaging、offline environment、root/revocation SLO、mirror/multi-region、break-glass、tenant realized stateは未確認です。