Summary

The Trusted Resources verification system matches a resource source string (refSource.URI) against spec.resources[].pattern using Go's regexp.MatchString. In Go, regexp.MatchString reports a match if the pattern matches anywhere in the input string. As a result, common unanchored patterns—including examples found in Tekton documentation—can be bypassed by attacker-controlled source strings that contain the trusted pattern as a substring. This may cause an unintended policy match and alter which verification mode or keys are applied.

Affected Component

- Repository: <https://github.com/tektoncd/pipeline> - Commit: 0133513db03dadb3cb08301d6b0330badcb63830 - Call site: pkg/trustedresources/verify.go:118–137 (getMatchedPolicies)

Impact

An attacker can craft a Trusted Resources source string that embeds a trusted substring and still matches an unanchored VerificationPolicy spec.resources[].pattern, even if the policy is intended to constrain matches to a specific trusted source. This occurs because regexp.MatchString succeeds on substring matches. For example, a pattern such as https://github.com/tektoncd/catalog.git would match an attacker-controlled source like https://evil.com/?x=https://github.com/tektoncd/catalog.git.

Affected: Deployments using Trusted Resources verification with unanchored VerificationPolicy patterns, where an attacker can influence the refSource.URI value used for policy matching.

Not affected: Deployments that anchor all patterns (^...$) or otherwise enforce full-string matching; deployments where attackers cannot influence refSource.URI.

Reproduction

Canonical (Demonstrates Vulnerability)

bash unzip -q -o poc.zip -d /tmp/poc-tekton-regex-001 cd /tmp/poc-tekton-regex-001/poc-F-TEKTON-REGEX-001 bash ./run.sh canonical | tee /tmp/tekton-regex-001-canonical.log

- Expected (secure): Capability not reached; canonical does not emit vulnerability markers. - Actual (vulnerable): Capability reached; canonical emits vulnerability markers. - Canonical markers (mandatory): [CALLSITEHIT] + [PROOFMARKER]

Negative Control

bash bash ./run.sh control | tee /tmp/tekton-regex-001-control.log

- Expected: Capability not reached under the same harness; control emits the control marker and does not emit vulnerability markers. - Control markers (mandatory): [CALLSITEHIT] + [NCMARKER]

Verification

bash grep -n '\[PROOFMARKER\]' /tmp/tekton-regex-001-canonical.log \ && grep -n '\[NCMARKER\]' /tmp/tekton-regex-001-control.log \ && ! grep -n '\[PROOFMARKER\]' /tmp/tekton-regex-001-control.log

Suggested Fix

It is recommended to make matching safe-by-default by requiring full-string matches, or by validating patterns and clearly documenting substring semantics. Possible approaches include:

1. Anchor patterns before matching — e.g., wrap pattern as ^(?:pattern)$ when not already anchored. 2. Introduce a separate field for exact match vs. regex match semantics. 3. Document substring semantics explicitly and update all documentation examples to include anchors.

A fix is considered accepted when, under the same harness, the canonical test still hits [CALLSITEHIT] but does not emit [PROOFMARKER].

Workarounds

Anchor all VerificationPolicy resource patterns so they must match the full source string. For example:

yaml pattern: "^https://github\\.com/tektoncd/catalog\\.git$"

Proof Bundle

- Bundle: poc.zip - Convention: The zip extracts under a single top-level folder (poc-F-TEKTON-REGEX-001/) to avoid collisions. - Contains: canonical.log, control.log, witness.txt - Extracted paths: ./poc/poc-F-TEKTON-REGEX-001/canonical.log, ./poc/poc-F-TEKTON-REGEX-001/control.log, ./poc/poc-F-TEKTON-REGEX-001/witness.txt - Integrity verification: Compare shasum -a 256 for canonical.log, control.log, fix.patch, and test source against witness.txt.

Note: If a supported integration uses verified HTTPS app-links or universal links only, provide the supported tag or branch and retesting on that pin can be arranged.