In Tekton, pin third-party tasks and pipelines by resolving them from a Git commit SHA or an image bundle reference rather than a branch or a moving tag, enable only the resolvers you need, and use the trusted resources feature to verify signatures on what you fetch.
How does Tekton pull in remote definitions?
Tekton's remote resolution lets a PipelineRun or a Task reference refer to a resource stored elsewhere. The getting started guide says resolvers are enabled by default from v0.41.0 and can be switched off in the resolvers feature flags config map. The built-in resolvers are bundles, git, hub and cluster, each with its own flag.
That means every cluster that has not been tuned can fetch definitions from several kinds of places. Each place is a trust decision.
What can you pin with the git resolver?
The git resolver takes a repository URL, a path in the repo and a revision. The documentation says the revision is the Git revision to check out and can be a commit SHA (SHA-1 or SHA-256), a branch or a tag. A branch name means the definition changes whenever someone pushes. A tag can be moved. A commit SHA fixes the content.
The getting started example uses a branch name for revision, which is fine for a tutorial and a poor choice for production. A constructed example: a platform team references a community golang-build task at revision main. The upstream maintainers change a step to download a helper binary at run time. Every pipeline in your cluster runs the new step on its next run. With a commit SHA in the revision, nothing changes until you update it on purpose.
What about bundles?
Tekton bundles package Tasks and Pipelines in an OCI image and are referenced through the bundles resolver. The docs show a bundle parameter with an image reference, a name and a kind, and mention a hard limit of 20 objects in a bundle. They also say you may specify a tag as with a Docker image. Prefer a digest over a tag in the reference so the content is fixed, the same reasoning as for container images.
Can you verify what you fetched?
Tekton has a Trusted Resources feature to sign and verify Tekton resources. The documentation marks it as an alpha feature for v1beta1 and v1 Tasks and Pipelines, and notes it currently verifies only resources from remote places: git, OCI registry and Artifact Hub. With verification on, a resource without a valid signature from a key you trust is rejected. Because it is alpha, check the current docs and test behavior before you rely on it as your only control.
Tekton Chains is the related project for signing and attesting the artifacts your pipelines produce. It covers what comes out of the pipeline, while trusted resources covers what goes in.
What to do
- Inventory every taskRef and pipelineRef that uses a resolver. Record the resolver, source and revision.
- Replace branch and moving tag revisions with commit SHAs. For bundles, use image digests.
- In the resolvers feature flags config map, turn off resolvers you do not use.
- Mirror third-party tasks into a repository you control and review changes there, then pin to your own commit.
- Pilot trusted resources in a non-production namespace. Sign your own tasks and confirm unsigned ones fail.
- Review the container images that tasks run. Safeguard's dependency and container image scanning can check the images referenced in step definitions.
- Add a pull request check that fails when a new resolver reference lacks a pinned revision. Safeguard policy gates can enforce rules like this in CI.
Quick check
Can the git resolver use a commit hash?
Yes. The documentation says the revision can be a commit SHA (SHA-1 or SHA-256), a branch or a tag.
Is trusted resources production ready?
The docs label it an alpha feature, so test it first and keep other controls in place.
Sources
- Tekton: Getting Started with Resolvers
- Tekton: Git resolver
- Tekton: Pipelines reference (bundles)
- Tekton: Trusted Resources
- Tekton Chains
Last reviewed: 18 October 2026.
