Add security threat model, vulnerability disclosure policy, and declined report transparency across Tekton projects

[vdemeester]

Body

Summary

Tekton projects need a documented security threat model, a vulnerability disclosure policy with named exclusions, and a mechanism to publish summaries of declined security reports. This is an org-wide effort spanning pipeline, chains, dashboard, and any other repo that receives security reports.

Problem

1. No documented threat model: Reporters (and AI security scanners) have no way to know what Tekton considers in-scope vs. out-of-scope. The current org-level SECURITY.md only covers how to report — not what qualifies.

2. Duplicate reports: Declined GHSAs stay private on GitHub. We've received multiple reports for the same class of issue (e.g., pod-level privilege escalation via podTemplate, resolver SSRF to user-controlled URLs) because previous assessments are invisible to new reporters.

3. Increasing AI scanner traffic: Agentic security scanners read SECURITY.md and disclosure policies before reporting. Projects with documented threat models and exclusion lists see scanners auto-demote out-of-scope findings before submission (ref). Without this, we will see growing volumes of reports for known non-issues.

Proposal

1. Security threat model document (per-repo)

Each repo that receives security reports should have a docs/security-model.md (linked from SECURITY.md) containing:

Trust boundaries — what does the project trust, and what doesn't it trust? Example for pipeline:

• Tekton trusts the Kubernetes API server and its admission controls (PSA, OPA, Kyverno)
• Tekton does NOT re-implement Kubernetes-level security controls
• Users who can create TaskRuns/PipelineRuns are equivalent to users who can create Pods

Named exclusions — categories of findings that are not vulnerabilities, each with a paragraph of reasoning. Modeled after curl's VULN-DISCLOSURE-POLICY.md which lists 16+ named categories. The reasoning is critical — it lets readers (human and AI) generalize to cases the list didn't anticipate.

In-scope findings — what the project does consider a vulnerability (validation bypasses, controller crashes, credential leaks, trust verification bypasses, etc.). This shows good faith and helps reporters focus their efforts.

2. Updated org-level SECURITY.md

Extend tektoncd/.github/SECURITY.md to:

• Link to per-repo security model documents
• Describe the triage process and timeline expectations
• Explain what happens when a report is declined (reasoning provided to reporter)
• Document the reporter credit policy

3. Declined report summaries (per-repo)

Add a docs/security-decisions/ directory in each repo to publish sanitized summaries of declined reports, containing:

• Finding summary
• Assessment and reasoning
• Why it was declined
• Correct mitigation (if applicable)

This requires reporter consent before publishing any details from their report. The goal is transparency and duplicate prevention, not shaming reporters.

Prior Art

Project	Approach	Link
curl	16+ named exclusions with reasoning in VULN-DISCLOSURE-POLICY.md	link
Node.js	Full threat model with trust boundaries in SECURITY.md	link
Django	Worked code examples of invalid reports	link
Homebrew	Threat model + in-scope + named exclusions with reasoning	link

See also: Andrew Nesbitt, "Not a Security Issue" (May 2026) — documents how curl's policy caused AI scanners to auto-demote out-of-scope findings.

Scope

Repos that have received security advisories and should be covered:

• tektoncd/pipeline (20 advisories) — repo-specific issue: Add security threat model and vulnerability disclosure policy pipeline#10072
• tektoncd/chains (5 advisories)
• tektoncd/dashboard (2 advisories)
• Other repos as needed

Deliverables

• Org-level SECURITY.md update (tektoncd/.github)
• docs/security-model.md template for repos to follow
• docs/security-model.md for tektoncd/pipeline (first, most urgent)
• docs/security-model.md for tektoncd/chains
• docs/security-decisions/ structure and first entries (with reporter consent)

/cc @tektoncd/core-maintainers