VerificationSummary Policy

A VerificationSummary policy evaluates artifacts based on Verification Summary Attestations (VSAs), 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 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:

A "security-scan" PolicyScanDefinition checks for vulnerabilities and publishes a VSA
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

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

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

Expected result: PASSED or FAILED. If blank or omitted, any result matches

signatureKeyIds

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

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

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

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

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

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:

Build completes and publishes attestations
"build-gate" PolicyScanDefinition evaluates build policies, publishes VSA
Artifact is deployed to staging
"staging-gate" PolicyScanDefinition evaluates staging policies, publishes VSA
"production-gate" PolicyScanDefinition includes VerificationSummary policy requiring both VSAs