diff --git a/plugins/sdlc-workflow/skills/triage-security/SKILL.md b/plugins/sdlc-workflow/skills/triage-security/SKILL.md index ed5b556e..92d28de9 100644 --- a/plugins/sdlc-workflow/skills/triage-security/SKILL.md +++ b/plugins/sdlc-workflow/skills/triage-security/SKILL.md @@ -412,6 +412,17 @@ assuming a fixed set. Common ecosystems include: - **npm** — JavaScript/TypeScript packages (e.g., axios, webpack, react) - **RPM** — System packages in container images (e.g., openssl, curl, glibc) +The ecosystem classification determines remediation task structure: + +| Category | Ecosystems | Remediation tasks per stream | +|---|---|---| +| Source dependency | Cargo, npm | 2 — upstream backport + downstream propagation | +| System package | RPM | 1 — Konflux release repo fix only | + +When a new ecosystem is added to a stream's Ecosystem Mappings table, update this +classification table to define its category. All downstream rules (Case B, checklist, +guardrails) reference this table rather than listing ecosystems individually. + If the detected ecosystem is not listed in the stream's Ecosystem Mappings table (e.g., Go modules), inform the user and stop automated triage for that ecosystem: @@ -424,7 +435,7 @@ Both the lock file path and check command are configured per ecosystem in each s ```mermaid flowchart TD - A["Identify ecosystem\nfrom library + component"] --> B{"Source dependency?\n(Cargo, npm, ...)"} + A["Identify ecosystem\nfrom library + component"] --> B{"Source dependency\necosystem?\n(see classification table)"} B -->|Yes| C["Lock file inspection\n(git show commit:lock-file)"] B -->|No| D{"RPM / system\npackage?"} D -->|Yes| E{"RPM lock file\nconfigured?"} @@ -602,11 +613,11 @@ flowchart TD B -->|Yes| SCOPE{"Issue scoped to\na single stream?"} B -->|No| D["Case C: Close as\nNot a Bug"] SCOPE -->|"Yes (scoped)"| C{"Other streams\nalso affected?"} - SCOPE -->|"No (unscoped)"| F["Case A: Create\nremediation tasks\nfor affected streams"] - C -->|Yes| E["Case B: Post cross-stream\nimpact comment"] + SCOPE -->|"No (unscoped)"| F["Case B: Create\nremediation tasks\nfor affected streams"] + C -->|Yes| E["Case A: Post cross-stream\nimpact comment"] C -->|No| F E --> F - F --> G{"Source dependency?\n(Cargo, npm)"} + F --> G{"Source dependency\necosystem?\n(see classification table)"} G -->|Yes| H["2 tasks: upstream\nbackport + downstream\npropagation"] G -->|No| I["1 task: Konflux\nrepo fix"] D --> J{"VEX Justification\nconfigured?"} @@ -634,23 +645,13 @@ If concurrent triages are detected, the protocol offers three options: wait, skip, or proceed with a `concurrent-triage-overlap` label. Only continue to Case A/B/C after the user chooses. -### Case A: Affected — create remediation tasks - -If the issue's stream-scoped versions (or all versions for unscoped issues) -are affected: -- Keep the current Vulnerability issue as-is (with corrected Affects Versions - from Step 3). -- Create one remediation Task per affected stream within the issue's scope - (see Remediation Task Creation below). -- Link each Task to the Vulnerability issue. - -### Case B: Cross-stream impact — proactive remediation +### Case A: Cross-stream impact — proactive remediation -**Guard — scoped issues only.** Case B applies exclusively to stream-scoped +**Guard — scoped issues only.** Case A applies exclusively to stream-scoped issues (those whose summary contains a stream suffix like `[myproduct-2.2]`). Unscoped issues cover all streams by definition — there are no "other streams outside this issue's scope," so the cross-stream impact check is not applicable. -For unscoped issues, skip Case B entirely and proceed directly to Case A task +For unscoped issues, skip Case A entirely and proceed directly to Case B task creation for all affected streams. If the issue is **scoped** and the version impact analysis reveals that **other @@ -669,7 +670,7 @@ streams** (outside this issue's scope) are also affected: suffix (reuse the JQL from Step 4). 3. **For each affected stream without its own CVE Jira**, create proactive - remediation tasks using the same templates as Case A, but with the + remediation tasks using the same templates as Case B, but with the preemptive variant (see `remediation-templates.md` — Preemptive Task Variant): - Labels include `security-preemptive` alongside standard labels @@ -694,6 +695,22 @@ streams** (outside this issue's scope) are also affected: Do **not** create new Vulnerability issues — PSIRT manages per-stream Vulnerability tracking. Only create remediation **Tasks**. +### Case B: Affected — create remediation tasks + +If the issue's stream-scoped versions (or all versions for unscoped issues) +are affected: +- Keep the current Vulnerability issue as-is (with corrected Affects Versions + from Step 3). +- Create remediation tasks for each affected stream within the issue's scope. + The number of tasks depends on the ecosystem — see the **ecosystem + classification table** in the Ecosystem detection section above. Source + dependency ecosystems produce two tasks per stream (upstream backport + + downstream propagation, with the downstream subtask blocked by the upstream + task). System package ecosystems produce one task per stream (Konflux release + repo fix). + See Remediation Task Creation below for full templates and API calls. +- Link each Task to the Vulnerability issue. + ### Case C: No supported versions affected If the version impact table shows NO for all supported versions (including @@ -729,9 +746,23 @@ engineer as part of the close recommendation. Present the full recommendation (task details, cross-stream notice, or close rationale) to the engineer for confirmation before executing any Jira mutations. +**Pre-creation checklist** — verify before presenting the recommendation: + +- [ ] **Task count per stream**: matches the ecosystem classification table + (source dependency → 2 tasks; system package → 1 task). +- [ ] **Cross-stream coverage**: for scoped issues, all affected streams outside the + issue's scope have either a preemptive task or an existing sibling CVE Jira. +- [ ] **Link types**: "Depend" for tasks linked to their own CVE Jira, "Related" for + preemptive tasks linked to another stream's CVE Jira, "Blocks" for upstream → + downstream within a stream. +- [ ] **Preemptive labels**: tasks for streams without their own CVE Jira carry the + `security-preemptive` label. +- [ ] **Coordination guidance**: each task's Implementation Notes includes the + appropriate guidance based on the repository's deployment context. + ## Remediation Task Creation -When triage concludes "needs fix" (Case A above), create Jira Tasks +When triage concludes "needs fix" (Case B above), create Jira Tasks following `task-description-template.md` so that `/implement-task` can parse them directly. Only create tasks for streams within the current issue's scope. @@ -749,12 +780,9 @@ Read `remediation-templates.md` for the full task description templates, Jira issue creation API calls, digest comment procedures, and linkage procedures. The key distinction: -- **Source dependency ecosystems** (Cargo, npm): create **two** tasks — - an upstream backport task (fix in the source repo) and a downstream propagation - subtask (update the reference in the Konflux release repo). The downstream subtask - is blocked by the upstream task. -- **System package ecosystems** (RPM): create **one** task — the fix happens directly - in the Konflux release repo (Dockerfiles, lock files). No upstream step needed. +- **Source dependency ecosystems**: create **two** tasks per the ecosystem + classification table — upstream backport + downstream propagation (blocked). +- **System package ecosystems**: create **one** task — Konflux release repo fix. ## Post-Triage Summary @@ -809,15 +837,14 @@ MUST include the Comment Footnote (see above). 7. **Never create Vulnerability issues.** PSIRT owns Vulnerability issue creation. This skill only creates remediation Tasks. Cross-stream impact is reported via comment on the current issue. -8. **One remediation Task per affected stream, plus a downstream propagation - subtask** when the ecosystem is a source dependency (Cargo, npm). - The upstream task covers the source repo fix; the downstream subtask covers - the Konflux release repo update and is blocked by the upstream task. System - package ecosystems produce a single task. A single Task spanning multiple - streams would be unimplementable by `/implement-task`. For dev-only or - build-only dependencies (identified in Step 2.3.5), add the `dev-dependency` - label and override priority to Normal — see the dependency scope decision - tree in `version-impact-analysis.md`. +8. **Task count per stream depends on the ecosystem** — see the ecosystem + classification table in the Ecosystem detection section. Source dependency + ecosystems produce two tasks, system packages produce one. A single Task + spanning multiple streams would be unimplementable + by `/implement-task`. For dev-only or build-only dependencies (identified + in Step 2.3.5), add the `dev-dependency` label and override priority to + Normal — see the dependency scope decision tree in + `version-impact-analysis.md`. 9. **Follow `task-description-template.md` for generated tasks.** The remediation Task description must be parseable by `/implement-task`. Do not invent custom sections or deviate from the template format.