/auditing-hackerone-vulns

name: auditing-hackerone-vulns
description: Audit all open HackerOne-sourced VULN Jira tickets and their linked engineering child items to identify what needs action. Use this skill whenever the user wants to: check VULN ticket status, see which HackerOne findings need status updates, identify vulnerabilities ready to verify or close, run a remediation audit, check "what do I need to do on my VULN tickets today", or get a prioritized view of open vulnerabilities. Outputs a sorted action table with emoji tokens. Always use this skill for HackerOne/VULN remediation tracking and status correlation tasks — don't try to do it from scratch.
allowed-tools: mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__search_issues, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue_remote_links, Bash(gh api --method GET *), Bash(gh pr view *), Bash(gh release list *), Bash(gh api repos/bitwarden/*/compare/*), Bash(gh search prs *)

Action tokens (sorted order in output)

| Token | Label | When it applies | | ----- | ---------------------- | ----------------------------------------------------------------------------------------------------- | | 🔴 | **Update VULN Status** | Child item has progressed (In Progress/Review) but VULN is still at a lower status | | 🟡 | **Mark Remediated** | Child item is Done — set Remediation Date to merged PR date and move VULN to Remediated | | 🟢 | **Verify & Close** | Fix is in a release that has already shipped — verify in prod, add Confirmation Date, close HackerOne | | 🔵 | **Monitor** | Work is actively in progress or in a pending release; no action needed yet | | ⚪ | **Waiting** | Child item exists but hasn't started | | ➖ | **No Child Item** | VULN is Ready for Resolution but no engineering ticket linked yet |

---

Step 1 — Query open VULN issues

Use `search_issues` with this JQL:

project = VULN AND status not in (Done, Verified) AND "Source" = "HackerOne" ORDER BY priority DESC, updated DESC

Request fields: `summary`, `status`, `description`, `priority`, `created`, `updated`

Paginate if needed (default max 50; use `nextPageToken` to get all).

---

Step 2 — Find child engineering items for each VULN

For each VULN key, run:

issue in linkedIssues("VULN-XXX")

Request fields: `summary`, `status`, `fixVersions`, `project`

• A VULN may have **multiple** child items. Collect them all.
• Ignore items in the same VULN project (those are sibling VULNs, not engineering tickets).
• Child items with `[VULN]` in the summary are the primary engineering tracking items.
• Some VULNs (especially fresh "Ready for Resolution") may have no child items yet → token ➖.

---

Step 3 — Classify child item statuses

Map Jira statuses to these categories:

| Category | Example statuses | | --------------- | --------------------------------------------------------------- | | **Not Started** | To Do, Backlog, Open, New, In Analysis | | **In Progress** | In Progress, In Development, In Review, Code Review, In Testing | | **Done** | Done, Closed, Resolved, Completed | | **Abandoned** | Abandoned, Won't Fix, Duplicate, Canceled |

For VULNs with multiple children: the **highest-priority active child** drives the action token. "In Progress" outranks "Not Started"; "Done" only counts if all non-abandoned children are Done.

---

Step 4 — Search GitHub for PRs linked to child items

**JSON parsing rule** — Always use `gh`'s built-in `--jq` flag or standalone `jq` for JSON parsing. Never pipe to `python3` or any other interpreter — Python is not in this skill's `allowed-tools` and will trigger a permission prompt. If stderr suppression is needed, place `2>/dev/null` _after_ the full `gh api ... --jq '...'` command, not before:

# Correct — 2>/dev/null after --jq, before the next pipe
gh api --method GET "repos/bitwarden/REPO/compare/A...B?per_page=250" \
  --jq '.commits[] | .commit.message | split("\n")[0]' 2>/dev/null \
  | grep "#PR_NUMBER"

**PR search** — Use `gh search prs` to find PRs. If that fails, fallback to the GitHub API with `gh api --method GET "search/"`

gh api --method GET "search/issues?q=CHILD-KEY+type:pr+org:bitwarden&per_page=10" \
  --jq '.items[] | {number,title,state,mergedAt,url:.html_url}'

For each PR that appears to be the correct fix (match on title/ticket key), get accurate merge details:

gh pr view PR_URL --json state,mergedAt,mergeCommit,baseRefName,title

**Determining release inclusion** — Bitwarden's repos (server, clients) use **release branches with cherry-picks**. The merge commit SHA on `main` gets a _new SHA_ when cherry-picked, so `compare/TAG...COMMIT_SHA` always returns "diverged" and is **unreliable**. Do not use it.

The correct method is to compare consecutive release tags and search for the PR number in commit messages (cherry-picks preserve the original PR number):

# 1. List non-draft, non-prerelease tags for the relevant repo
gh release list --repo bitwarden/REPO --limit 20 \
  --json tagName,publishedAt,isDraft,isPrerelease \
  | jq '.[] | select(.isDraft == false and .isPrerelease == false)'

# 2. Find the two consecutive tags that bracket the expected fix release
#    (e.g., v2026.4.0 and v2026.4.1)

# 3. List all commits in that range and grep for the PR number
gh api --method GET "repos/bitwarden/REPO/compare/TAG_PREV...TAG_RELEASE?per_page=250" \
  --jq '.commits[] | .commit.message | split("\n")[0]' \
  | grep "