Materials defined in a policy group are not shown during attestation

[migmartri]

Summary

When running an attestation, the CLI/UI should surface all materials that are expected for the workflow — both required and optional. Materials that are defined as part of a policy group attached to the contract are not being shown during attestation, so users have no visibility into them.

Expected behavior

During attestation (e.g. chainloop attestation status / add), the list of expected materials should include materials contributed by any policy group bound to the contract, alongside the materials declared directly in the contract.

Actual behavior

Materials that originate from a policy group are omitted from the materials shown during attestation. Only materials declared directly on the contract appear; the policy-group materials are silently missing.

Related: confusing warning on duplicate materials

If the same material is declared in both the contract's materials list and inside an attached policy group, the user gets a confusing warning during attestation. The two sources of materials aren't reconciled cleanly: instead of treating the contract + policy-group definitions as a single merged set, the overlap is flagged in a way that's unclear to the user (it reads like an error/misconfiguration rather than the expected "same material defined in two places" case). The warning text and the condition that triggers it should be clarified — or the duplicate should be merged silently when the definitions are compatible.

Impact

• Users can't tell which materials a policy group expects, so they may not provide them.
• Reduced visibility makes it hard to satisfy policy-group requirements and to debug failing/incomplete attestations.
• The duplicate-material warning adds confusion when a material legitimately appears in both the contract and a policy group.

Notes

The materials are still defined correctly inside the policy group — the bug is specifically in how the expected-materials list is assembled/displayed during attestation, where policy-group materials are not merged in cleanly with the contract materials.

🤖 Posted by Maximus bot (Claude Code) on behalf of @migmartri

[javirln]

Example. This contract only has one policy group defined with the material inside, not on the contract

root@host:/home/javirln/development# chainloop attestation init --workflow sast --project my-project --version 0.0.1 --mark-latest=true
INF Attestation initialized! now you can check its status or add materials to it
┌───────────────────────────┬───────────────────────────────────────────────┐
│ Initialized At            │ 17 Jun 26 13:33 UTC                           │
├───────────────────────────┼───────────────────────────────────────────────┤
│ Attestation ID            │ 60418b47-cf4d-4b75-9be2-1b61ea85fee8          │
│ Organization              │ myorg                                      │
│ Name                      │ sast                                          │
│ Project                   │ my-project                                      │
│ Version                   │ 0.0.1 (prerelease)                         │
│ Contract                  │ sast (revision 2)                             │
│ Policy violation strategy │ ADVISORY                                      │
│ Policies                  │ ------                                        │
│                           │ sast-scan-present: missing SAST scan material │
└───────────────────────────┴───────────────────────────────────────────────┘

It does not show the allowed materials.

If we now add the materials also to the contract, we get a warning on the output

root@host:/home/javirln/development# chainloop attestation init --workflow sast --project my-project --version 0.0.1 --mark-latest=true
WRN material 'sast-scan' from policy group 'sast' is also present in the contract and will be ignored
WRN material 'sonarqube-report' from policy group 'sast' is also present in the contract and will be ignored
INF Attestation initialized! now you can check its status or add materials to it
┌───────────────────────────┬───────────────────────────────────────────────┐
│ Initialized At            │ 17 Jun 26 13:43 UTC                           │
├───────────────────────────┼───────────────────────────────────────────────┤
│ Attestation ID            │ b4e214b0-0a1b-4ac4-aa5e-4b78d2ad6ad7          │
│ Organization              │ myorg                                      │
│ Name                      │ sast                                          │
│ Project                   │ my-project                                      │
│ Version                   │ 0.0.1 (prerelease)                         │
│ Contract                  │ sast (revision 3)                             │
│ Policy violation strategy │ ADVISORY                                      │
│ Policies                  │ ------                                        │
│                           │ sast-scan-present: missing SAST scan material │
└───────────────────────────┴───────────────────────────────────────────────┘
┌───────────────────────────────────┐
│ Materials                         │
├──────────┼────────────────────────┤
│ Name     │ sast-scan              │
│ Type     │ GITLAB_SECURITY_REPORT │
│ Set      │ No                     │
│ Required │ No                     │
├──────────┼────────────────────────┤
│ Name     │ sonarqube-report       │
│ Type     │ SARIF                  │
│ Set      │ No                     │
│ Required │ No                     │
├──────────┼────────────────────────┤

[jiparis]

It used to add the policy group materials to the contract. Can you show the policy group source?

[migmartri]

It used to add the policy group materials to the contract. Can you show the policy group source?

It's a regression introduced when we added the v2 of the contract, and of course

apiVersion: workflowcontract.chainloop.dev/v1
kind: PolicyGroup
metadata:
# Name of the policy group
  name: example-sbom-example22
# Optionally you can add a description to the policy group
  description: SBOM and Security Policy Group
# Uncomment below to add annotations. In this case it will create a policy group with category SBOM and security
#  annotations:
#    category: SBOM, security
spec:
# Inputs are the parameters that are passed to the policy group that can be used in the policies
# to control the behavior of the policies. Uncomment below to add inputs to the policy group
#  inputs:
#    - name: vulnerabilityThreshold
#      description: Threshold for the vulnerability score, eg. 7.5
#      default: 7.5
  policies:
    attestation:
      - ref: sbom-present
    materials:
      - name: sbom
        type: SBOM_CYCLONEDX_JSON
        policies:
          - ref: sbom-banned-licenses
            with:
              licenses: "AGPL-10, AGPL-3.0"
# You can keep on adding more policies to the policy group.
# Uncomment below to add a policy to check for vulnerabilities with the threshold passed as input. The inputs section
# needs to be uncommented to pass the input to the policy, for the example
#          - ref: vulnerabilities
#            with:
#              score: "{{inputs.vulnerabilityThreshold}}"

[migmartri]

There is a fix already