Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions evals/triage-security/evals.json
Original file line number Diff line number Diff line change
Expand Up @@ -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)",
Expand All @@ -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)"
]
},
{
Expand Down
42 changes: 41 additions & 1 deletion plugins/sdlc-workflow/skills/triage-security/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -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) |
Expand Down Expand Up @@ -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 <command>"` 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(<jira-issue-id>, assignee=<current-user-account-id>)
```

3. **Discover the target transition dynamically:**

```
jira.get_transitions(<jira-issue-id>)
```

Select the transition whose target status name is `"Assigned"`. Do NOT
Comment on lines +222 to +231

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: Clarify the relationship between the "Vulnerability issue key" input and the <jira-issue-id> placeholder used in examples.

The Inputs section uses the term "Vulnerability issue key," while these examples use <jira-issue-id>. Please briefly clarify whether the issue key is passed directly as <jira-issue-id> or how it is converted, so readers know exactly what value to supply in these calls.

Suggested implementation:

2. **Assign the issue to the current user:**

   The `<jira-issue-id>` placeholder in these examples is the same value as the
   "Vulnerability issue key" input (for example, `SEC-1234`) and should be passed
   directly to the Jira client methods without additional conversion.

jira.edit_issue(, assignee=)


3. **Discover the target transition dynamically:**

jira.get_transitions()


4. **Transition to Assigned (if the issue is in New status):**

   Use the same "Vulnerability issue key" value as `<jira-issue-id>` here as
   well (for example, `SEC-1234`):

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.

If the Inputs section currently uses a different label (for example, "Vulnerability issue key (e.g., SEC-1234)"), you may want to cross-link explicitly, such as: “This is the same value provided as the ‘Vulnerability issue key’ input in the Inputs section.” Adjust the example key format (SEC-1234) if your Jira project uses a different key prefix or format.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[sdlc-workflow/verify-pr] Classified as suggestion — this proposes clarifying placeholder naming conventions, which is not documented in CONVENTIONS.md and has no established codebase-wide convention (angle-bracket placeholders like <jira-issue-id> are used consistently throughout all skill files). No sub-task created.

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(<jira-issue-id>, <assigned-transition-id>)
```

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.
Expand Down Expand Up @@ -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

Expand Down
Loading