Hola Chainloop team!

I'd like to propose adding two native material types for Pacto:

• PACTO — Pacto contracts
• PACTO_EVIDENCE — runtime evidence produced by Pacto

What is Pacto?

Pacto is an open-source contract system for cloud-native services. A Pacto contract is a machine-readable description of what a service is supposed to look like: ownership, interfaces, dependencies, configuration, workload, capabilities, etc. Contracts are versioned and distributed as OCI artifacts. For example:

pactoVersion: "2.0"

service:
  name: payments
  version: 2.3.0
  owner:
    team: payments

interfaces:
  - name: api
    type: openapi
    ref: interfaces/openapi.yaml

The contract documentation has the full model.

The interesting part: runtime evidence

Pacto is not only about declaring the contract. Collectors observe the actual runtime and produce a common EvidenceSet. The Pacto evaluator then compares:

flowchart LR
    C[Pacto Contract] --> E[Pacto Evaluator]
    X[Runtime] --> K[Pacto Collector]
    K --> ES[EvidenceSet]
    ES --> E
    E --> F[Findings]

The important bit for this proposal is that Pacto can now persist that evidence as a content-addressed OCI artifact (see evidence OCI storage and collectors for the details). So we now have two different OCI artifacts:

flowchart LR
    C[Pacto Contract] --> O1[OCI Artifact]
    E[Pacto Evidence] --> O2[OCI Artifact]

Why Chainloop?

This looks like a natural fit for Chainloop's material model. A release could contain:

flowchart TD
    R[Release] --> I[Container Image]
    R --> S[SBOM]
    R --> P[Provenance]
    R --> C[PACTO]
    R --> E[PACTO_EVIDENCE]

This gives Chainloop a way to connect the usual software supply-chain artifacts with runtime information about the service. For example, a PACTO_EVIDENCE artifact can reference the exact Pacto contract it was collected against by digest. This makes it possible to establish:

this runtime evidence was collected for this exact contract.

And Chainloop can then apply its own policies to the attestation, for example:

• a production release must contain a Pacto contract;
• it must contain Pacto runtime evidence;
• the evidence must reference the same contract digest;
• the evidence must not be stale.

Those are Chainloop-level policies. Pacto remains responsible for interpreting the contract and evidence and producing its own findings.

Proposed material types

I think the initial implementation could be quite small:

PACTO

Accept a Pacto OCI artifact and expose basic metadata such as:

• service name/version
• owner
• Pacto version
• digest

PACTO_EVIDENCE

Accept a Pacto Evidence OCI artifact and expose:

• subject/service
• contract digest
• collector/source
• observation timestamp
• evidence digest

The underlying artifacts should remain content-addressed and be handled through Chainloop's existing material/CAS mechanisms.

The existing generic EVIDENCE material type could technically be used for this, but I think Pacto is a good candidate for a native type because both the contract and evidence have a defined format and semantics, and the relationship between the two is important.

References

• Pacto
• Pacto architecture
• Pacto collectors
• Pacto Evidence OCI storage
• Chainloop material types
• Chainloop policies

Happy to contribute the Pacto side and work with the Chainloop team on the material type implementation.