In the fast-changing world of DevOps, users need continuous integration/continuous delivery (CI/CD) solutions that are secure, scalable, and cloud-native. Tekton solves this challenge. It is an open-source project under the CD Foundation, which is part of the Linux Foundation. Tekton is designed to standardize CI/CD workflows across cloud providers, making it a powerful tool for modern software delivery pipelines.

But Tekton isn’t just another CI/CD tool—it is also a supply chain security controller, offering robust mechanisms to ensure the integrity and provenance of your software artifacts. In this blog, we’ll dive into what makes Tekton unique, especially in the context of supply chain security.

What is Tekton?

Tekton is a Kubernetes-native framework for creating CI/CD systems. It provides a set of custom resource definitions (CRDs) that allow you to define pipelines, tasks, and workflows directly within your Kubernetes cluster.

Key features of Tekton Chains on IBM Power

Tekton Chains is a powerful component of the Tekton ecosystem that enhances supply chain security by generating and managing signed attestations for CI/CD artifacts. This section explains some of the standout features.

Cryptographic signing of TaskRun results

Tekton Chains uses user-provided cryptographic keys to sign the results of TaskRun executions. This includes:

• The TaskRun metadata itself.
• Any Open Container Initiative (OCI) images or other artifacts produced.

This ensures that every step in your pipeline is traceable and verifiable.

Support for attestation formats

Tekton Chains supports industry-standard attestation formats, such as in-toto, which is a framework for securing the integrity of software supply chains by defining and verifying the steps in a build process. 

This makes it easier to integrate Tekton Chains with other tools and platforms that rely on these formats.

Flexible signing mechanisms

Tekton Chains supports signing with a variety of cryptographic key types and Key Management Service (KMS), such as:

• x.509 certificates
• Cloud KMS providers (such as Google Cloud KMS, Amazon Web Services (AWS) KMS, and HashiCorp Vault)

This flexibility allows organizations to align Tekton Chains with their existing security infrastructure.

Multiple storage backends

Signed attestations and metadata can be stored in various backends, including:

• OCI registries (for example, Docker Hub, Harbor, Amazon ECR)
• Transparency logs (such as Rekor from Sigstore)
• Custom storage solutions

This ensures that signatures are tamper-evident and easily retrievable for verification.

The following figure illustrates how Tekton Chains operate.

Figure 1: Working of Tekton Chains

When a Tekton pipeline is triggered, it orchestrates a series of tasks such as fetching the source code from a Git repository, running tests, building a container image, and finally pushing the image to a container registry.

After the pipeline is complete, Tekton Chains automatically generates a provenance document which is a structured record that captures critical details about the build, including the source repository, commit Secure Hash Algorithm (SHA), build steps, environment, and the resulting image digest. This document is then cryptographically signed using a trusted key provider, ensuring its authenticity and integrity. The signed provenance is stored alongside the container image in an OCI-compliant registry or in a transparency log, making it easily retrievable for future verification. During deployment, systems such as Kubernetes admission controllers or GitOps tools validate the image by checking its digest and verifying the signature against the provenance. This ensures that only artifacts built through trusted pipelines and verified processes are allowed into production, thereby securing the software supply chain end-to-end.

How does Tekton Chains work?

1. Pipeline execution
   When a Tekton TaskRun or PipelineRun completes, chains listen for these events.
2. Metadata extraction
   Chains gather metadata such as:
• Git commit and repo
• Task parameters
• Image digest and tags
• Build environment details
3. Provenance document creation
   It creates a provenance document (often in SLSA format), which describes how the artifact was built.
4. Provenance document signing
   Tekton Chains integrates with Sigstore’s Cosign to sign provenance documents using cryptographic keys. The provenance is cryptographically signed using tools such as:
• Cosign
• KMS
• x509 certificates
5. Metadata storing
   Signed metadata is stored in:
• OCI registries (alongside the image)
• Transparency logs (for example, Rekor)
• External databases

Prerequisites to verify Tekton Chains on IBM Power

Ensure that the OpenShift Pipelines operator from the Red Hat source is installed on your cluster. For more information, refer to the Set up pipelines with the help of Red Hat OpenShift Pipelines blog.

Figure 2. Pipelines operator installed on cluster

After installing the pipelines operator, ensure that all the CRDs are installed and are in the True state. Use the following command to check if tektonconfig is in the True state.

# oc get tektonconfig
NAME     VERSION   READY   REASON
config   1.17.0    True

Then, make sure that the following requirements are fulfilled:

1. Install the required tools.

   Get your system ready by installing the essential tools using the following command:

   # yum install git wget curl jq –y

2. Install the Cosign tool.

   Cosign is a tool which is a part of the Sigstore project for signing and verification of container images and storage in an OCI registry.

    For Chains to work properly, the encrypted private key must be stored in a secret named signing-secrets in the following parts:

   • cosign.key (the cosign-generated private key in an encrypted PEM file)
   • cosign.password (the password to decrypt the private key)

   
   Install the latest version of Cosign using the following commands:

   go install github.com/sigstore/cosign/cmd/cosign@latest
   cosign version

3. Install rekor-cli.

    Rekor provides a secure, immutable record of metadata generated from the software  supply chain. Rekor makes it easy to ensure trust in your software supply chain by offering a RESTful API server for validating data and a transparency log for securely storing it. With its CLI tool, you can create and verify entries, check the log’s integrity, and query the log to search for records.

   Install the latest version of rekor-cli using the following commands.

   go install -v github.com/sigstore/rekor/cmd/rekor-cli@latest
   rekor-cli version

4. Install rekor-server.

   Install the latest version of rekor-server using the following commands.

   #go install -v github.com/sigstore/rekor/cmd/rekor-server@latest
   #rekor-server version

5. Log in to Docker.

   Log in to Docker using the following command:

   # sudo docker login --username $DOCKER_USERNAME --password $DOCKER_PASSWORD

    

Verify Tekton Chains provenance

Now that we have taken care of the prerequisites, we are ready to demonstrate the working of Tekton Chains. For this, we need to complete the following steps.

1. Set the environment variables and create a directory.
2. Install Tekton Chains.
3. Create a secret and generate a cosign key pair.
4. Clone the repository and start the task.
5. Verify the signature and attestation.

Step 1. Set the environment variables and create a directory

Prepare your workspace by setting the environment variables and creating a directory.

1. Set the namespace and set the following values.
   

    # export CUSTOM_PROJECT=<your-namespace>

   Example:
   

   export CUSTOM_PROJECT=test-chains

   export CUSTOM_SECRET=<secret-name>

   Example:
   

   export CUSTOM_SECRET=chains-secret

   # export COSIGN_PASSWORD=<your-password>

2. Create a directory and project for validation.
   

   # mkdir test-chains
   # cd test-chains
   # oc new-project $CUSTOM_PROJECT
   # oc project $CUSTOM_PROJECT

Step 2. Install Tekton Chains

1. Run the following YAML file to install Tekton Chains on your cluster.
   

   # cat <<EOF | oc apply -f -
   apiVersion: operator.tekton.dev/v1alpha1
   kind: TektonChain
   metadata:
     name: chain
   spec:
     targetNamespace: openshift-pipelines
   EOF
   

2. Check the status of the installed Tekton Chains using the following lines of code.
   

   #  CHECK_CHAINS=$(oc get tektonchain chain | grep True | awk '{print $3}')
   if [ $CHECK_CHAINS=="True" ]; then
     echo "Tekton chains installed"
     oc get tektonchains.operator.tekton.dev
   else 
     echo "Tekton chains not installed."
     oc get tektonchains.operator.tekton.dev
   Fi

Step 3. Create a secret and generate a cosign key pair

1. Create a secret based on the existing credentials with the config.json file.
   

   # kubectl create secret generic secret-name \
       --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
       --type=kubernetes.io/dockerconfigjson \
       -n $ $CUSTOM_PROJECT

   Example:
   

   kubectl create secret generic regcred --from-file=.dockerconfigjson=/root/.docker/config.json --type=kubernetes.io/dockerconfigjson -n test-chains

2. Apply a patch for the serviceaccount pipeline.

   This command associates the service account with a secret that contains registry credentials, allowing the service account to pull images from private registries.

   # kubectl patch serviceaccount pipeline -p "{\"imagePullSecrets\": [{\"name\": \"regcred\"}]}"

3. Generate a cosign key pair.

   To create a cosign keypair (that includes cosign.key and cosign.pub), run the following command:

   # cosign generate-key-pair k8s://openshift-pipelines/signing-secrets
   # kubectl create secret generic $CUSTOM_SECRET --from-file ~/.docker/config.json

Authentication of an OCI registry for chains

To enable certain advanced features in Tekton Chains:

• Ensure that authentication is properly configured. This includes push signatures to an OCI registry after signing an image.
• Get signing certificates when utilizing keyless signing.

The chains controller looks for credentials at two locations to push signatures to an OCI registry. The first location is in the pod running your task and the second location is in the service account configured to run your task.

Ensure that the OCI storage is disabled and that the TaskRun storage and format are set to Tekton.

You can set these fields by running the following commands:

# kubectl patch configmap chains-config -n openshift-pipelines -p='{"data":{"transparency.enabled": "true"}}'
# kubectl patch configmap chains-config -n openshift-pipelines -p='{"data":{"artifacts.taskrun.storage": "oci"}}'
# kubectl patch configmap chains-config -n openshift-pipelines -p='{"data":{"artifacts.taskrun.format": "in-toto"}}'

Step 4. Clone the repository and start the task.

1. Clone the following GitHub repo and apply the kaniko task to the cluster.

   Kaniko is a tool that builds container images from a Dockerfile inside a container or Kubernetes pod — without requiring a Docker daemon.

   # git clone https://github.com/tektoncd/chains.git

   The Kaniko Task provides the capability to build container images within Tekton pipelines, while Tekton Chains extends this by automatically generating and signing verifiable attestations for those images, enhancing the security and trustworthiness of the software supply chain.

   Run the following command to create a kaniko task.

   # oc apply -f chains/examples/kaniko/kaniko.yaml

2. Start the kaniko task.

   To begin building the container image using kaniko, run the following Tekton TaskRun:

   # tkn task start --param=IMAGE=docker.io/$DOCKER_USERNAME/kaniko-chains --use-param-defaults --workspace name=source,emptyDir="" --workspace name=dockerconfig,secret=$CUSTOM_SECRET kaniko-chains –showlog
   
   ############### Start TaskRun ###############
   TaskRun started: kaniko-chains-run-7r7fr
   Waiting for logs to be available...
   [add-dockerfile] FROM alpine@sha256:69e70a79f2d41ab5d637de98c1e0b055206ba40a8145e7bddb55ccc04e13cf8f
   
   [build-and-push] INFO[0000] Retrieving image manifest alpine@sha256:69e70a79f2d41ab5d637de98c1e0b055206ba40a8145e7bddb55ccc04e13cf8f
   [build-and-push] INFO[0000] Retrieving image alpine@sha256:69e70a79f2d41ab5d637de98c1e0b055206ba40a8145e7bddb55ccc04e13cf8f from registry index.docker.io
   [build-and-push] INFO[0000] Built cross stage deps: map[]
   [build-and-push] INFO[0000] Retrieving image manifest alpine@sha256:69e70a79f2d41ab5d637de98c1e0b055206ba40a8145e7bddb55ccc04e13cf8f
   [build-and-push] INFO[0000] Returning cached image manifest
   [build-and-push] INFO[0000] Executing 0 build triggers
   [build-and-push] INFO[0000] Skipping unpacking as no commands require it.
   [build-and-push] INFO[0000] Pushing image to docker.io/$ DOCKER_USERNAME/kaniko-chains
   [build-and-push] INFO[0001] Pushed image to 1 destinations

3. Observe the logs of this task until all the steps are complete. On successful authentication, the final image will be pushed to $REGISTRY/kaniko-chains.
4. Display TaskRun logs.
   

   # GET_TR=$(oc get tr | grep kaniko-chains-run | awk '{print $1}')
   # echo "Your Taskrun >> $GET_TR"
   # oc get tr $GET_TR  -o json | jq -r .metadata.annotations
   
   ############### Display TaskRun logs ###############
   Your Taskrun >> kaniko-chains-run-7r7fr
   {
     "chains.tekton.dev/signed": "true",
     "chains.tekton.dev/transparency": "https://rekor.sigstore.dev/api/v1/log/entries?logIndex=161345446",
     "pipeline.tekton.dev/release": "acb6211",
     "results.tekton.dev/record": "test-chains/results/5bd44362-cac7-49a5-91dc-0131b804ee94/records/5bd44362-cac7-49a5-91dc-0131b804ee94",
     "results.tekton.dev/result": "test-chains/results/5bd44362-cac7-49a5-91dc-0131b804ee94",
     "results.tekton.dev/stored": "true"
   }

   Tekton Chains generates and signs the provenance. Verify that the TaskRun includes this annotation, chains.tekton.dev/signed=true.

Step 5. Verify the image and attestation.

1. Run the following command to verify the image signature using the public key and save the output to a JSON log file:
   

   # cosign verify --key cosign.pub docker.io/$DOCKER_USERNAME/kaniko-chains > cosign_verify_log.json

2. Run the following command to verify the provenance attestation for the image using cosign and the public key:
   

   # cosign verify-attestation --key cosign.pub docker.io/$DOCKER_USERNAME/kaniko-chains --type slsaprovenance
   
   Verification for docker.io /kaniko-chains --
   The following checks were performed on each of these signatures:
     - The cosign claims were validated
     - The signatures were verified against the specified public key
   {"payloadType":"application/vnd.in-toto+json","payload":"eyJfdHlwZSI6Imh0dHBzOi8vaW4tdG90by5pby9TdGF0ZW1lbnQvdjAuMSIsICJzdWJqZWN0IjpbeyJuYW1lIjoiaW5kZXguZG9ja2VyLmlvL2xha3NobWkyMDEzL2thbmlrby1jaGFpbnMiLCAiZGlnZXN0Ijp7InNoYTI1NiI6ImZlMjUyNzY0ZTZkNTM0MzBiMDAwYzdlYTg0ZTZjZWJiOTIyZjgxNzJmZjAxNzE3MmExZGY0YzAzYmEwNmEzMTAifX1dLCAicHJlZGljYXRlVHlwZSI6Imh0dHBzOi8vc2xzYS5kZXYvcHJvdmVuYW5jZS92MC4yIiwgInByZWRpY2F0ZSI6eyJidWlsZENvbmZpZyI6eyJzdGVwcyI6W3siYW5ub3RhdGlvbnMiOm51bGwsICJhcmd1bWVudHMiOm51bGwsICJlbnRyeVBvaW50Ijoic2V0IC1lXG5lY2hvIFwiRlJPTSBhbHBpbmVAc2hhMjU2OjY5ZTcwYTc5ZjJkNDFhYjVkNjM3ZGU5OGMxZTBiMDU1MjA2YmE0MGE4MTQ1ZTdiZGRiNTVjY2MwNGUxM2NmOGZcIiB8IHRlZSAuL0RvY2tlcmZpbGVcbiIsICJlbnZpcm9ubWVudCI6eyJjb250YWluZXIiOiJhZGQtZG9ja2VyZmlsZSIsICJpbWFnZSI6Im9jaTovL2RvY2tlci5pby9saWJyYXJ5L2Jhc2hAc2hhMjU2OjIyYTg1MDUwOTk3NjBkMjY5MzRiNWZlNmU4YWY2ODg5ZDk3OTg0ZTZlMTg3MTlhNDFiZWEwMjA4MThiNDQ1NDMifX0sIHsiYW5ub3RhdGlvbnMiOm51bGwsICJhcmd1bWVudHMiOlsiIiwgIi0tZG9ja2VyZmlsZT0uL0RvY2tlcmZpbGUiLCAiLS1jb250ZXh0PS93b3Jrc3BhY2Uvc291cmNlLy4vIiwgIi0tZGVzdGluYXRpb249ZG9ja2VyLmlvL2xha3NobWkyMDEzL2thbmlrby1jaGFpbnMiLCAiLS1kaWdlc3QtZmlsZT0vdGVrdG9uL3Jlc3VsdHMvSU1BR0VfRElHRVNUIl0sICJlbnRyeVBvaW50IjoiIiwgImVudmlyb25tZW50Ijp7ImNvbnRhaW5lciI6ImJ1aWxkLWFuZC1wdXNoIiwgImltYWdlIjoib2NpOi8vZ2NyLmlvL2thbmlrby1wcm9qZWN0L2V4ZWN1dG9yQHNoYTI1Njo0NzM1OThmYTdkNjRiMjRlMzZlYmUzNDZkNmRhZmJhNWE2NThhMmIxZWQ3OTA0NDAwMTk3NWI3MDZkYWZkNjY0In19LCB7ImFubm90YXRpb25zIjpudWxsLCAiYXJndW1lbnRzIjpudWxsLCAiZW50cnlQb2ludCI6InNldCAtZVxuZWNobyBkb2NrZXIuaW8vbGFrc2htaTIwMTMva2FuaWtvLWNoYWlucyB8IHRlZSAvdGVrdG9uL3Jlc3VsdHMvSU1BR0VfVVJMXG4iLCAiZW52aXJvbm1lbnQiOnsiY29udGFpbmVyIjoid3JpdGUtdXJsIiwgImltYWdlIjoib2NpOi8vZG9ja2VyLmlvL2xpYnJhcnkvYmFzaEBzaGEyNTY6MjJhODUwNTA5OTc2MGQyNjkzNGI1ZmU2ZThhZjY4ODlkOTc5ODRlNmUxODcxOWE0MWJlYTAyMDgxOGI0NDU0MyJ9fV19LCAiYnVpbGRUeXBlIjoidGVrdG9uLmRldi92MWJldGExL1Rhc2tSdW4iLCAiYnVpbGRlciI6eyJpZCI6Imh0dHBzOi8vdGVrdG9uLmRldi9jaGFpbnMvdjIifSwgImludm9jYXRpb24iOnsiY29uZmlnU291cmNlIjp7fSwgImVudmlyb25tZW50Ijp7ImFubm90YXRpb25zIjp7InBpcGVsaW5lLnRla3Rvbi5kZXYvcmVsZWFzZSI6ImFjYjYyMTEiLCAicmVzdWx0cy50ZWt0b24uZGV2L3JlY29yZCI6InRlc3QtY2hhaW5zL3Jlc3VsdHMvNWJkNDQzNjItY2FjNy00OWE1LTkxZGMtMDEzMWI4MDRlZTk0L3JlY29yZHMvNWJkNDQzNjItY2FjNy00OWE1LTkxZGMtMDEzMWI4MDRlZTk0IiwgInJlc3VsdHMudGVrdG9uLmRldi9yZXN1bHQiOiJ0ZXN0LWNoYWlucy9yZXN1bHRzLzViZDQ0MzYyLWNhYzctNDlhNS05MWRjLTAxMzFiODA0ZWU5NCIsICJyZXN1bHRzLnRla3Rvbi5kZXYvc3RvcmVkIjoiZmFsc2UifSwgImxhYmVscyI6eyJhcHAua3ViZXJuZXRlcy5pby9tYW5hZ2VkLWJ5IjoidGVrdG9uLXBpcGVsaW5lcyIsICJ0ZWt0b24uZGV2L3Rhc2siOiJrYW5pa28tY2hhaW5zIn19LCAicGFyYW1ldGVycyI6eyJCVUlMREVSX0lNQUdFIjoiZ2NyLmlvL2thbmlrby1wcm9qZWN0L2V4ZWN1dG9yOnYxLjUuMUBzaGEyNTY6YzYxNjY3MTdmN2ZlMGI3ZGE0NDkwOGM5ODYxMzdlY2ZlYWIyMWYzMWVjMzk5MmY2ZTEyOGZmZjhhOTRiZThhNSIsICJDT05URVhUIjoiLi8iLCAiRE9DS0VSRklMRSI6Ii4vRG9ja2VyZmlsZSIsICJFWFRSQV9BUkdTIjoiIiwgIklNQUdFIjoiZG9ja2VyLmlvL2xha3NobWkyMDEzL2thbmlrby1jaGFpbnMifX0sICJtYXRlcmlhbHMiOlt7ImRpZ2VzdCI6eyJzaGEyNTYiOiIyMmE4NTA1MDk5NzYwZDI2OTM0YjVmZTZlOGFmNjg4OWQ5Nzk4NGU2ZTE4NzE5YTQxYmVhMDIwODE4YjQ0NTQzIn0sICJ1cmkiOiJvY2k6Ly9kb2NrZXIuaW8vbGlicmFyeS9iYXNoIn0sIHsiZGlnZXN0Ijp7InNoYTI1NiI6IjQ3MzU5OGZhN2Q2NGIyNGUzNmViZTM0NmQ2ZGFmYmE1YTY1OGEyYjFlZDc5MDQ0MDAxOTc1YjcwNmRhZmQ2NjQifSwgInVyaSI6Im9jaTovL2djci5pby9rYW5pa28tcHJvamVjdC9leGVjdXRvciJ9XSwgIm1ldGFkYXRhIjp7ImJ1aWxkRmluaXNoZWRPbiI6IjIwMjUtMDEtMTBUMTE6MjI6MTFaIiwgImJ1aWxkU3RhcnRlZE9uIjoiMjAyNS0wMS0xMFQxMToyMTo1MVoiLCAiY29tcGxldGVuZXNzIjp7ImVudmlyb25tZW50IjpmYWxzZSwgIm1hdGVyaWFscyI6ZmFsc2UsICJwYXJhbWV0ZXJzIjpmYWxzZX0sICJyZXByb2R1Y2libGUiOmZhbHNlfX19","signatures":[{"keyid":"SHA256:TEcxeLnYJCP4pHRDgcOmljBpC/AjKlkCHWSY/xuuYok","sig":"MEUCIQDqynWdki63/23HFYwwjIxi7FjNARGyJF3MKFAI1W4FvgIgDsOkH6RYox3dncSOknH0jdpA1O7EPCDwL190+4sUpMM="}]}

Locate the image’s provenance record in Rekor

Run the following command to retrieve the Secure Hash Algorithm (SHA) value from the cosign_verify_log.json file:

# cat cosign_verify_log.json | grep docker-manifest-digest | awk '{print $1}'

[{"critical":{"identity":{"docker-reference":"index.docker.io /kaniko-chains"},"image":{"docker-manifest-digest":"sha256:fe252764e6d53430b000c7ea84e6cebb922f8172ff017172a1df4c03ba06a310"},"type":"cosign

Now, copy only the SHA value and pass this to rekor-cli search.

By specifying the SHA value instead of the version tag, you can pull a specific version of the image. At this stage, we get the digest for the image, and therefore, we can search the log with the digest of the image.

Example:

#  rekor-cli search --sha fe252764e6d53430b000c7ea84e6cebb922f8172ff017172a1df4c03ba06a310
Found matching entries (listed by UUID):
108e9186e8c5677a123ecb8872ebc93133c8473ecb413adf8e8121a83066b98f3f6460767c189b0

The search result displays the UUIDs of the matching entries.

Tekton Chains takes a snapshot of the TaskRuns . After completing execution of the TaskRun, it converts the snapshot into a standard payload, signs it, and stores it. Tekton Chains creates the provenance and signs it using a secure private key. Chains then uploads the signed provenance to a user-specified location.

Use the following command to get detailed logs:

# rekor-cli get --uuid <uuid> --format json | jq -r .Attestation | jq

Example:

rekor-cli get --uuid 24296fb24b8ad77afde766165b7957ed1251d439f2ddf3a4d08581c534b059f9c4b6f959c2155c2c --format json | jq -r .Attestation | jq
{
  "_type": "https://in-toto.io/Statement/v0.1",
  "subject": [
    {
      "name": "index.docker.io /kaniko-chains",
      "digest": {
        "sha256": "fe252764e6d53430b000c7ea84e6cebb922f8172ff017172a1df4c03ba06a310"
      }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v0.2",
  "predicate": {
    "buildConfig": {
      "steps": [
        {
          "annotations": null,
          "arguments": null,
          "entryPoint": "set -e\necho \"FROM alpine@sha256:69e70a79f2d41ab5d637de98c1e0b055206ba40a8145e7bddb55ccc04e13cf8f\" | tee ./Dockerfile\n",
          "environment": {
            "container": "add-dockerfile",
            "image": "oci://docker.io/library/bash@sha256:22a8505099760d26934b5fe6e8af6889d97984e6e18719a41bea020818b44543"
          }
        },
        {
          "annotations": null,
          "arguments": [
            "",
            "--dockerfile=./Dockerfile",
            "--context=/workspace/source/./",
            "--destination=docker.io/ /kaniko-chains",
            "--digest-file=/tekton/results/IMAGE_DIGEST"
          ],
          "entryPoint": "",
          "environment": {
            "container": "build-and-push",
            "image": "oci://gcr.io/kaniko-project/executor@sha256:473598fa7d64b24e36ebe346d6dafba5a658a2b1ed79044001975b706dafd664"
          }
        },
        {
          "annotations": null,
          "arguments": null,
          "entryPoint": "set -e\necho docker.io /kaniko-chains | tee /tekton/results/IMAGE_URL\n",
          "environment": {
            "container": "write-url",
            "image": "oci://docker.io/library/bash@sha256:22a8505099760d26934b5fe6e8af6889d97984e6e18719a41bea020818b44543"
          }
        }
      ]
    },
    "buildType": "tekton.dev/v1beta1/TaskRun",
    "builder": {
      "id": "https://tekton.dev/chains/v2"
    },
    "invocation": {
      "configSource": {},
      "environment": {
        "annotations": {
          "pipeline.tekton.dev/release": "acb6211",
          "results.tekton.dev/record": "test-chains/results/5bd44362-cac7-49a5-91dc-0131b804ee94/records/5bd44362-cac7-49a5-91dc-0131b804ee94",
          "results.tekton.dev/result": "test-chains/results/5bd44362-cac7-49a5-91dc-0131b804ee94",
          "results.tekton.dev/stored": "false"
        },
        "labels": {
          "app.kubernetes.io/managed-by": "tekton-pipelines",
          "tekton.dev/task": "kaniko-chains"
        }
      },
      "parameters": {
        "BUILDER_IMAGE": "gcr.io/kaniko-project/executor:v1.5.1@sha256:c6166717f7fe0b7da44908c986137ecfeab21f31ec3992f6e128fff8a94be8a5",
        "CONTEXT": "./",
        "DOCKERFILE": "./Dockerfile",
        "EXTRA_ARGS": "",
        "IMAGE": "docker.io /kaniko-chains"
      }
    },
    "materials": [
      {
        "digest": {
          "sha256": "22a8505099760d26934b5fe6e8af6889d97984e6e18719a41bea020818b44543"
        },
        "uri": "oci://docker.io/library/bash"
      },
      {
        "digest": {
          "sha256": "473598fa7d64b24e36ebe346d6dafba5a658a2b1ed79044001975b706dafd664"
        },
        "uri": "oci://gcr.io/kaniko-project/executor"
      }
    ],
    "metadata": {
      "buildFinishedOn": "2025-01-10T11:22:11Z",
      "buildStartedOn": "2025-01-10T11:21:51Z",
      "completeness": {
        "environment": false,
        "materials": false,
        "parameters": false
      },
      "reproducible": false
    }
  }
}

The subject field captures the location of the built artifact and the cryptographic hash associated with it. The builder.id field captures the builder that built the artifact.

In Tekton, both tasks and pipelines can define a set of results. These results are structured output that are produced during execution. They play a vital role in enabling Tekton Chains to generate accurate and verifiable provenance documents. The results are used to communicate the run specifics to (such as the Uniform Resource Identifier (URI) and the digest of the built artifact) to Tekton Chains.  

Conclusion

In an era where software supply chain security is under increasing scrutiny, embedding trust and transparency into CI/CD pipelines is no longer optional—it is essential. By observing task executions, capturing detailed snapshots, standardizing data, signing artifacts, and storing them securely, teams can ensure that every artifact produced is verifiable, traceable, and tamper-proof. This not only strengthens the integrity of the development process but also builds confidence among stakeholders, auditors, and users.