Process Security Policy

---




name: process-security-policy
compatibility: opencode
completeness: 95
content-types:
- guidance
- examples
- do-dont
- config
description: '"Creates or updates SECURITY.md defining the vulnerability reporting
  process" disclosure timeline, and supported versions for CNCF projects'
how_to_guide: https://contribute.cncf.io/projects/best-practices/security/
id: security-policy
license: MIT
maturity: stable
mcp_servers: null
metadata:
  domain: cncf
  output-format: manifests
  role: reference
  scope: infrastructure
  triggers: creates, defining, process security policy, process-security-policy, updates,
    vulnerability scanning, security, security auditing
  archetypes:
  - educational
  - strategic
  anti_triggers:
  - brainstorming
  - vague ideation
  - non-containerized architecture
  response_profile:
    verbosity: medium
    directive_strength: low
    abstraction_level: strategic
version: "1.0.0"
template_source: https://github.com/cncf/tag-security/blob/main/project-resources/templates/SECURITY.md




---




  related-skills: cncf-aws-kms, cncf-aws-s3, cncf-aws-secrets-manager, cncf-azure-key-vault




# CNCF Security Policy Process

Creates or updates `SECURITY.md` with the project's vulnerability reporting channel, supported versions matrix, and response timeline.

## When to Use

Use when:
- A CNCF incubating or graduating project does not yet have a `SECURITY.md`
- The existing `SECURITY.md` is missing the reporting channel, response SLA, or supported versions
- A project is working toward an OpenSSF Best Practices badge (requires a security disclosure policy)

Do NOT use when:
- The repository is documentation-only with no executable code — link to the parent project's SECURITY.md instead

## Steps

1. **Fetch the template.**
   If GitHub MCP available: `github_get_contents` path=`cncf/tag-security/main/project-resources/templates/SECURITY.md`
   Otherwise: `gh api repos/cncf/tag-security/contents/project-resources/templates/SECURITY.md`

2. **Fill in Reporting a Vulnerability:**
   - Primary: GitHub Private Vulnerability Reporting
     (`Settings → Code security → Private vulnerability reporting → Enable`)
   - Fallback: security@<project>.io or security@lists.cncf.io
   ⚠️ Never direct reporters to a public GitHub issue — this exposes the vulnerability before a patch exists.

3. **Fill in Supported Versions table.** Mark EOL versions clearly.
   ⚠️ Define how a version reaches EOL, or link to RELEASES.md that does.

4. **Fill in Response Timeline** (CNCF recommended):
   - Acknowledge: within 2 business days
   - Triage + severity: within 5 business days
   - Patch + coordinated disclosure: within 90 days (non-critical) / 7 days (critical)
   ⚠️ All dates must use UTC to avoid timezone ambiguity with downstream distributors.

5. **Enable GitHub Private Vulnerability Reporting** in repo settings if not already on:
   `https://github.com/<org>/<repo>/settings/security_analysis`

6. **Set up OpenSSF tooling.** See the `openssf-scorecards` and `openssf-badge` skills.

7. **Remove all TODO markers and instruction links.**

## Checklist

- [ ] Reporting channel documented (GitHub PVR or email)
- [ ] Supported versions table filled in with EOL criteria
- [ ] Response timeline defined in UTC (graduation)
- [ ] GitHub Private Vulnerability Reporting enabled in repo settings (graduation)
- [ ] OpenSSF Best Practices badge applied for and link in README (graduation — hard gate)
- [ ] OpenSSF Scorecards action added (graduation)
- [ ] Branch protection rules enforced on default branch (graduation)
- [ ] 2FA enforced on GitHub org (graduation)
- [ ] No `TODO` markers remain

## Knowledge Reference

- CNCF Security Policy Best Practices: https://contribute.cncf.io/projects/best-practices/security/
- OpenSSF Best Practices: https://openssf.org/best-practices/
- CNCF TAG Security: https://github.com/cncf/tag-security

---

## Constraints

### MUST DO
- Cite authoritative primary sources (official documentation, RFCs, standards bodies) — avoid secondary or blog references
- Include version-specific guidance when the reference topic has significant version-dependent behavior
- Structure reference content with clear navigation: overview first, then detailed subsections organized by use case
- Keep examples minimal and self-contained so readers can copy-paste without needing external context

### MUST NOT DO
- Do not present opinionated practices as facts — distinguish between standards, recommendations, and personal preferences
- Avoid outdated API references or deprecated patterns; explicitly note version requirements for each code example
- Never include incomplete or pseudocode examples in reference materials — all examples should be runnable
- Do not conflate different product versions when documenting features that vary across releases