---

name: process-incident-response compatibility: opencode completeness: 95 content-types:

• guidance
• examples
• do-dont
• config description: '"Creates or updates an incident response plan covering detection, triage" communication, and post-incident review for CNCF projects' how_to_guide: https://contribute.cncf.io/projects/best-practices/security/ id: incident-response license: MIT maturity: stable mcp_servers: null metadata: domain: cncf output-format: manifests related-skills: null role: reference scope: infrastructure triggers: covering, creates, process incident response, process-incident-response, updates 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/INCIDENT-RESPONSE.md

---

CNCF Incident Response Process

Creates or updates an incident response plan with the step-by-step process for triaging, remediating, and disclosing a confirmed security vulnerability.

When to Use

Use when:

• A project has never formally documented how it responds to a confirmed vulnerability
• The project is expanding its security team and needs a shared runbook
• A post-incident review revealed gaps in the response process

Do NOT use when:

• The project does not yet have a SECURITY.md — the reporting channel must exist before defining the response process; run the security-policy skill first

Steps

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

2. Fill in Triage: who is notified first, severity rating (CVSS or project-defined), decision criteria for patch vs. mitigate.

3. Fill in Remediation: branching strategy, who has access to private security forks, how patches are tested without public disclosure. ⚠️ Access to private forks must be defined now — unclear access during an active incident delays patching.

4. Fill in Coordinated Disclosure: how downstream distributors are notified before public disclosure, embargo period, and GitHub Security Advisory publishing process. ⚠️ Verify the timeline matches the response timeline in SECURITY.md — inconsistencies are a graduation finding.

5. Fill in Communication: what the public announcement includes, which channels are used (GitHub Security Advisory, project mailing list), who approves. ⚠️ One named person must own each active incident; "the security contacts will handle it" is not a runbook.

6. Fill in Post-Incident Review: blameless retrospective process and how learnings feed back into the security policy.

7. Cross-link to the security self-assessment under Remediation or Post-Incident Review.

Checklist

• Triage process documented with severity definitions
• Private patch development access defined by name/role (graduation)
• Coordinated disclosure timeline defined and consistent with SECURITY.md (graduation)
• Named incident commander role defined (graduation)
• Public communication plan documented
• Post-incident review process defined
• Cross-link to security self-assessment present (graduation)
• GitHub Security Advisory draft workflow verified accessible to all contacts (graduation)

Knowledge Reference

• CNCF Incident Response: https://contribute.cncf.io/projects/best-practices/security/
• CNCF TAG Security: https://github.com/cncf/tag-security
• GitHub Security Advisories: https://docs.github.com/en/code-security/security-advisories

---

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