From 2869dff6c2e52d225906eccc63edbfb13365946d Mon Sep 17 00:00:00 2001 From: Ruben Romero Montes Date: Fri, 24 Jul 2026 21:58:08 +0200 Subject: [PATCH 1/3] fix(triage-security): improve remediation task generation logic in Step 8 Reorder Case B before Case A to match flowchart evaluation order, inline the ecosystem-dependent two-task rule at the Case A action point, add a 5-item pre-creation checklist at the confirmation gate, and simplify Rule 8 to cross-reference instead of restating. Root cause: CVE-2026-13149 triage (TC-5051) missed downstream propagation subtasks and preemptive cross-stream tasks because Case A committed to single tasks before Case B could add preemptive ones, and the two-task ecosystem rule was buried in the guardrails. Resolves: TC-5378 Co-Authored-By: Claude Opus 4.6 --- .../skills/triage-security/SKILL.md | 58 +++++++++++++------ 1 file changed, 39 insertions(+), 19 deletions(-) diff --git a/plugins/sdlc-workflow/skills/triage-security/SKILL.md b/plugins/sdlc-workflow/skills/triage-security/SKILL.md index ed5b556e..5202880a 100644 --- a/plugins/sdlc-workflow/skills/triage-security/SKILL.md +++ b/plugins/sdlc-workflow/skills/triage-security/SKILL.md @@ -634,16 +634,6 @@ 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 **Guard — scoped issues only.** Case B applies exclusively to stream-scoped @@ -694,6 +684,23 @@ 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 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 remediation tasks for each affected stream within the issue's scope. + The number of tasks depends on the ecosystem: + - **Source dependency ecosystems** (Cargo, npm): create **two** tasks per + stream — 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 per stream — the + fix happens directly in the Konflux release repo. + 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,6 +736,20 @@ 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**: source dependency ecosystems (Cargo, npm) produce + 2 tasks per stream (upstream + downstream); system package ecosystems produce 1. +- [ ] **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 @@ -809,15 +830,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** — source dependencies + (Cargo, npm) produce two tasks (upstream + downstream), system packages + produce one. See Case A inline rule and the pre-creation checklist for + details. 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. From 386ed9da0253ae9b5d80d8bc262257193043c37b Mon Sep 17 00:00:00 2001 From: Ruben Romero Montes Date: Sat, 25 Jul 2026 12:29:22 +0200 Subject: [PATCH 2/3] =?UTF-8?q?refactor:=20rename=20triage-security=20case?= =?UTF-8?q?s=20to=20match=20document=20order=20(A=E2=86=92B=E2=86=92C)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The cases were ordered B, A, C in the document but retained their original letter names, making the flow confusing. Rename so the document order matches alphabetical naming: cross-stream impact is now Case A (listed first), remediation tasks is now Case B (listed second), Case C unchanged. Co-Authored-By: Claude Opus 4.6 --- .../skills/triage-security/SKILL.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/plugins/sdlc-workflow/skills/triage-security/SKILL.md b/plugins/sdlc-workflow/skills/triage-security/SKILL.md index 5202880a..5f19ef54 100644 --- a/plugins/sdlc-workflow/skills/triage-security/SKILL.md +++ b/plugins/sdlc-workflow/skills/triage-security/SKILL.md @@ -602,8 +602,8 @@ 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)"} @@ -634,13 +634,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 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 @@ -659,7 +659,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 @@ -684,7 +684,7 @@ 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 A: Affected — create remediation tasks +### Case B: Affected — create remediation tasks If the issue's stream-scoped versions (or all versions for unscoped issues) are affected: @@ -752,7 +752,7 @@ rationale) to the engineer for confirmation before executing any Jira mutations. ## 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. @@ -832,7 +832,7 @@ MUST include the Comment Footnote (see above). comment on the current issue. 8. **Task count per stream depends on the ecosystem** — source dependencies (Cargo, npm) produce two tasks (upstream + downstream), system packages - produce one. See Case A inline rule and the pre-creation checklist for + produce one. See Case B inline rule and the pre-creation checklist for details. 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 From 3c8c1c343ed6be5f3fef8aaa72aa42ac296d2f36 Mon Sep 17 00:00:00 2001 From: Ruben Romero Montes Date: Sat, 25 Jul 2026 12:49:51 +0200 Subject: [PATCH 3/3] refactor(triage-security): consolidate ecosystem classification rules Add a canonical ecosystem classification table as the single source of truth for ecosystem categories and task counts. Update all downstream references (Case B, checklist, remediation templates, guardrail Rule 8, and mermaid flowcharts) to point to the table instead of re-listing ecosystem names inline, reducing duplication from 6 sites to 1. Co-Authored-By: Claude Opus 4.6 --- .../skills/triage-security/SKILL.md | 49 +++++++++++-------- 1 file changed, 28 insertions(+), 21 deletions(-) diff --git a/plugins/sdlc-workflow/skills/triage-security/SKILL.md b/plugins/sdlc-workflow/skills/triage-security/SKILL.md index 5f19ef54..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?"} @@ -606,7 +617,7 @@ flowchart TD 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?"} @@ -691,13 +702,12 @@ 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: - - **Source dependency ecosystems** (Cargo, npm): create **two** tasks per - stream — 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 per stream — the - fix happens directly in the Konflux release repo. + 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. @@ -738,8 +748,8 @@ rationale) to the engineer for confirmation before executing any Jira mutations. **Pre-creation checklist** — verify before presenting the recommendation: -- [ ] **Task count per stream**: source dependency ecosystems (Cargo, npm) produce - 2 tasks per stream (upstream + downstream); system package ecosystems produce 1. +- [ ] **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 @@ -770,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 @@ -830,10 +837,10 @@ 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. **Task count per stream depends on the ecosystem** — source dependencies - (Cargo, npm) produce two tasks (upstream + downstream), system packages - produce one. See Case B inline rule and the pre-creation checklist for - details. A single Task spanning multiple streams would be unimplementable +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