diff --git a/evals/triage-security/evals.json b/evals/triage-security/evals.json index 7b33b0460..6575c710a 100644 --- a/evals/triage-security/evals.json +++ b/evals/triage-security/evals.json @@ -3,8 +3,8 @@ "evals": [ { "id": 1, - "prompt": "Triage Vulnerability issue TC-8001. The issue details are in vuln-issue-standard.md, the security matrix is in security-matrix-mock.md, and the project CLAUDE.md is in claude-md-security-config.md. Do NOT actually call Jira MCP, git show, or any external tools. Instead, write your triage analysis to the workspace outputs/ directory: write outputs/data-extraction.md with the parsed CVE data table from Step 1, write outputs/version-impact.md with the version impact table from Step 2, write outputs/affects-versions.md with the Affects Versions correction from Step 3, and write outputs/remediation.md with the remediation task descriptions you would create in Step 8.", - "expected_output": "A structured triage analysis demonstrating: correct CVE data extraction (CVE-2026-31812, quinn-proto, affected range < 0.11.14), version impact table built from security-matrix.md pinned commits showing which versions ship the vulnerable dependency, Affects Versions correction from PSIRT-assigned values to lock-file-verified values, and remediation task descriptions following task-description-template.md format.", + "prompt": "Triage Vulnerability issue TC-8001. The issue details are in vuln-issue-standard.md, the security matrix is in security-matrix-mock.md, and the project CLAUDE.md is in claude-md-security-config.md. Do NOT actually call Jira MCP, git show, or any external tools. Instead, write your triage analysis to the workspace outputs/ directory: write outputs/data-extraction.md beginning with the Step 0.7 early assignment actions (assigning the CVE issue to the current user and transitioning to Assigned status) followed by the parsed CVE data table from Step 1, write outputs/version-impact.md with the version impact table from Step 2, write outputs/affects-versions.md with the Affects Versions correction from Step 3, and write outputs/remediation.md with the remediation task descriptions you would create in Step 8.", + "expected_output": "A structured triage analysis demonstrating: Step 0.7 early assignment (assigning the CVE issue and transitioning to Assigned status before data extraction), correct CVE data extraction (CVE-2026-31812, quinn-proto, affected range < 0.11.14), version impact table built from security-matrix.md pinned commits showing which versions ship the vulnerable dependency, Affects Versions correction from PSIRT-assigned values to lock-file-verified values, and remediation task descriptions following task-description-template.md format.", "files": ["files/vuln-issue-standard.md", "files/security-matrix-mock.md", "files/claude-md-security-config.md"], "assertions": [ "Data extraction correctly identifies CVE-2026-31812, library quinn-proto, affected range < 0.11.14, and fixed version 0.11.14 from the Vulnerability issue (Step 1)", @@ -16,7 +16,8 @@ "Affects Versions correction references version names from the supportability matrix rather than hardcoded Jira version IDs (Important Rule 6)", "Remediation tasks include Repository, Target Branch, acceptance criteria, and dependency linkage between upstream and downstream tasks (Important Rule 9)", "For Cargo ecosystem, remediation creates two tasks: upstream backport task and downstream propagation subtask with Blocks dependency (Important Rule 8)", - "The analysis presents triage recommendations as proposed actions — framing Affects Versions changes, label additions, and status transitions as proposals rather than executed mutations (Guardrails)" + "The analysis presents triage recommendations as proposed actions — framing Affects Versions changes, label additions, and status transitions as proposals rather than executed mutations (Guardrails)", + "The data-extraction output describes Step 0.7 actions before the Step 1 data table: assigning the CVE issue to the current user and transitioning it to Assigned status (Step 0.7)" ] }, { diff --git a/plugins/sdlc-workflow/skills/triage-security/SKILL.md b/plugins/sdlc-workflow/skills/triage-security/SKILL.md index 4e041ef16..b8fb6426a 100644 --- a/plugins/sdlc-workflow/skills/triage-security/SKILL.md +++ b/plugins/sdlc-workflow/skills/triage-security/SKILL.md @@ -37,6 +37,7 @@ Do **not** use for: | 0 | Validate Configuration | CLAUDE.md | Project key, Cloud ID, Security Config | | 0.3 | Matrix Staleness Check | security-matrix.md timestamps | Staleness warning or proceed | | 0.5 | Jira Access | -- | MCP or REST API connection | +| 0.7 | Assign and Transition to Assigned | Vulnerability issue key | Issue assigned to current user, status Assigned | | 1 | Data Extraction | Vulnerability issue key | CVE ID, library, affected range, remote links | | 1.5 | External CVE Data Enrichment | CVE ID | Structured version ranges, cross-validated fix thresholds | | 1.7 | Embargo Check | Embargo policy URL, CVE severity | Confirmation to proceed (or stop) | @@ -202,6 +203,46 @@ Follow the JIRA Access protocol in `shared/jira-access-strategy.md`. **Exception for Bash tool:** When using REST API fallback, this skill may use `bash -c "python3 scripts/jira-client.py "` for JIRA operations only. +## Step 0.7 – Assign and Transition to Assigned + +Assign the CVE Vulnerability issue to the current user and transition it to +Assigned status. This provides immediate visibility into who is actively triaging +the issue and enables Step 7 (Concurrent Triage Detection) to reliably identify +active work. + +1. **Retrieve the current user's Jira account ID:** + + ``` + jira.user_info() + ``` + +2. **Assign the issue to the current user:** + + ``` + jira.edit_issue(, assignee=) + ``` + +3. **Discover the target transition dynamically:** + + ``` + jira.get_transitions() + ``` + + Select the transition whose target status name is `"Assigned"`. Do NOT + hardcode a transition ID or assume the transition name — Vulnerability issues + use a different Jira workflow than Task issues. + +4. **Transition to Assigned (if the issue is in New status):** + + ``` + jira.transition_issue(, ) + ``` + + If the issue is already in Assigned or any later status (detected via the + status-aware handling in the Inputs section), skip the transition silently. + The assignment in step 2 still proceeds regardless — it ensures the current + user is recorded even when re-triaging an issue that was previously assigned. + ## Inputs The user provides a single Vulnerability issue key. @@ -650,7 +691,6 @@ the development stream): 2. Transition to Closed with resolution "Not a Bug". 3. If VEX Justification custom field is configured, set it to the appropriate value (see VEX Justification below). - 4. Assign to current user. ### VEX Justification