You are viewing **Develocity Provenance Governor 1.6**. To view the latest available version of the docs, see [1.7](https://docs.gradle.com/develocity/provenance-governor/1.7/policy-type-verification-summary/). # VerificationSummary Policy A VerificationSummary policy evaluates artifacts based on [Verification Summary Attestations (VSAs)](https://slsa.dev/spec/v1.2/verification_summary), which record that an artifact has been verified by a specific entity. This enables enforcement of "build gates" or "scan requirements" by ensuring artifacts have passed required verification processes before deployment or use. This policy operates on the `[https://slsa.dev/verification_summary/v1](https://slsa.dev/verification_summary/v1)` predicate type. VSAs are particularly useful when: * Artifacts must pass security scans before deployment * Artifacts have been verified in upstream environments * Manual approvals are required for releases * Multiple verification steps must be completed (e.g., security + performance + compliance) * You want to verify that Develocity Provenance Governor’s own Policy Scan™ evaluations have passed ## How VSAs Work with Develocity Provenance Governor When Develocity Provenance Governor evaluates a PolicyScanDefinition, it can publish a VSA recording the scan result. These VSAs can then be consumed by downstream VerificationSummary policies to create multi-stage gates. For example: 1. A "security-scan" PolicyScanDefinition checks for vulnerabilities and publishes a VSA 2. A "release-gate" PolicyScanDefinition includes a VerificationSummary policy that requires the security-scan VSA to have passed This creates a higher-order policy that depends on the results of a previous policy evaluation. ## Configuration Fields | Field | Required | Description | | --- | --- | --- | | verifierId | Yes | URI identifying the entity that performed the verification (case-insensitive matching) | | policyUri | Yes | URI of the policy that was verified, matches the policy.uri field in the VSA (case-insensitive matching) | | verificationResult | No | Expected result: PASSED or FAILED. If blank or omitted, any result matches | | signatureKeyIds | No | List of authorized signature key IDs (SHA256 digest abbreviations). If specified, at least one envelope signature must match. This prevents verifier impersonation. If omitted or empty, any signature is accepted | ## must-match Strategy (Allow List) Use `matchingStrategy: must-match` to require that specific verifications have passed. All requirements must be satisfied for the policy to pass. ### Require Build Verification ```yaml apiVersion: policy.gradle.com/v1 kind: VerificationSummary metadata: name: require-build-verification labels: policy.my-corp.com/gate: build spec: resultsLabels: policy.my-corp.com/gate: build description: Ensure the artifact has passed build-time policy verification. remediation: Fix build policy violations and rebuild the artifact. matchingStrategy: must-match summaryRequirements: - verifierId: https://provenance-governor.example.com policyUri: /policies/PolicyScanDefinition/build-gate verificationResult: PASSED ``` ### Require Upstream Environment Verification ```yaml apiVersion: policy.gradle.com/v1 kind: VerificationSummary metadata: name: require-dev-environment-pass labels: policy.my-corp.com/gate: staging spec: resultsLabels: policy.my-corp.com/gate: staging description: Ensure the artifact has been verified in the development environment. remediation: Deploy and verify the artifact in development before promoting to staging. matchingStrategy: must-match summaryRequirements: - verifierId: https://provenance-governor.example.com policyUri: /policies/PolicyScanDefinition/dev-environment-gate verificationResult: PASSED ``` ## none-match Strategy (Deny List) Use `matchingStrategy: none-match` to block artifacts that have explicitly failed verification. ### Block Build Failures ```yaml apiVersion: policy.gradle.com/v1 kind: VerificationSummary metadata: name: block-failed-build-verification labels: policy.my-corp.com/gate: build spec: resultsLabels: policy.my-corp.com/gate: build description: Block artifacts that failed build-time policy verification. remediation: Fix build policy violations and re-run the build verification. matchingStrategy: none-match summaryRequirements: - verifierId: https://provenance-governor.example.com policyUri: /policies/PolicyScanDefinition/build-gate verificationResult: FAILED ``` ## Preventing Verifier Impersonation with Signature Key Binding The optional `signatureKeyIds` field binds specific signing keys to verifier identities, preventing attackers from publishing fake VSAs claiming to be from trusted verifiers. ### Build Gate with Authorized Signing Keys ```yaml apiVersion: policy.gradle.com/v1 kind: VerificationSummary metadata: name: require-authorized-build-verification labels: policy.my-corp.com/gate: build spec: resultsLabels: policy.my-corp.com/gate: build description: Ensure the build verification VSA is signed by an authorized key. remediation: Ensure the build verification is signed with an authorized key from the CI system. matchingStrategy: must-match summaryRequirements: - verifierId: https://provenance-governor.example.com policyUri: /policies/PolicyScanDefinition/build-gate verificationResult: PASSED signatureKeyIds: - "abc123" (1) - "fed456" (2) ``` 1. Primary CI signing key (abbreviated SHA256 digest) 2. Backup signing key for key rotation scenarios > [!NOTE] > Key IDs are case-sensitive and must exactly match the signature keyId in the envelope. Multiple keyIds support key rotation — only one needs to match. ## Using VSAs from Develocity Provenance Governor Policy Scan Evaluations Develocity Provenance Governor can publish VSAs when evaluating PolicyScanDefinitions. These VSAs can then be consumed by downstream VerificationSummary policies. **Step 1: Configure PolicyScanDefinition to publish VSAs** When you call the Policy Scan API, the PolicyScanDefinition’s URI becomes the VSA’s `policyUri`, and the Develocity Provenance Governor instance becomes the `verifierId`. **Step 2: Create downstream VerificationSummary policy** **Production Gate — Require Build and Staging Verification:** ``` apiVersion: policy.gradle.com/v1 kind: VerificationSummary metadata: name: require-build-and-staging-verification labels: policy.my-corp.com/gate: production spec: resultsLabels: policy.my-corp.com/gate: production description: Ensure artifact passed both build-gate and staging-gate verification. remediation: Fix policy violations in build or staging, then re-verify in those environments. matchingStrategy: must-match summaryRequirements: - verifierId: https://provenance-governor.example.com (1) policyUri: /policies/PolicyScanDefinition/build-gate (2) verificationResult: PASSED - verifierId: https://provenance-governor.example.com policyUri: /policies/PolicyScanDefinition/staging-gate (3) verificationResult: PASSED ``` 1. The URI of your Develocity Provenance Governor instance (configured in application properties) 2. The PolicyScanDefinition that verifies build-time requirements 3. The PolicyScanDefinition that verifies staging environment requirements This creates a multi-stage verification flow: 1. Build completes and publishes attestations 2. "build-gate" PolicyScanDefinition evaluates build policies, publishes VSA 3. Artifact is deployed to staging 4. "staging-gate" PolicyScanDefinition evaluates staging policies, publishes VSA 5. "production-gate" PolicyScanDefinition includes VerificationSummary policy requiring both VSAs