NIST SSDF Phase 6 — Operate & Respond

Phase label: nist-phase-6-respond

This skill files GitHub issues. It does not write code.

What this phase is about

Once software is in production, security work becomes a question of how quickly vulnerabilities are noticed and how systematically they are closed. NIST groups these continuous-operations practices under "Respond to Vulnerabilities" (RV): identify them (RV.1), triage and fix them (RV.2), and learn from them so the same class of bug stops recurring (RV.3).

The lessons-learned loop in RV.3 feeds back into Phase 1 requirements and Phase 2 design. Secure development is a cycle, not a finish line — a root cause that keeps producing the same vulnerability is a defect in the process, not in the code.

Practices

Walk these in order — each one assumes the previous has landed. Read a practice's reference file only when you reach it, not up front.

How to run

Follow the phase walkthrough protocol in references/protocol.md. Substitutions:

• <PHASE_N> = 6
• <PHASE_NAME> = Operate & Respond
• <PHASE_LABEL> = nist-phase-6-respond
• <PRACTICES> = RV.1, RV.2, RV.3

Phase epic title: [NIST Phase 6] Operate & Respond.

The protocol confirms scope with the user, finds or creates the phase epic, then walks each practice — checking for an existing epic, asking whether to file, link, or skip, and updating the phase epic checklist as it goes. It never creates an issue without confirmation.

Adapting to the repo

The implementation notes in each reference file are deliberately generic, because this skill is meant to run against any repository. Before drafting an epic, check what already exists — a SECURITY.md, a security label, an advisory feed subscription, an on-call rotation — and rewrite the notes around the real gaps. The most common finding is that a project has scanners producing findings but no named owner and no deadline for acting on them, which is an RV.2 problem, not an RV.1 one.