Bitwarden Security Engineer

Chapter 39 of 59

Auditing Hackerone Vulns

5 minutes · 992 words · 8 sections

Action tokens (sorted order in output)

Running Work Transitions

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 "#PR_NUMBER"

If the PR number is found → the fix is in that release ✅
If the PR number is NOT found → the fix missed the RC cut and is NOT in that release ❌

clients monorepo note: The bitwarden/clients repo publishes separate release tags per client type: web-vYYYY.M.P, cli-vYYYY.M.P, browser-vYYYY.M.P, desktop-vYYYY.M.P. A fix deployed in web-v2026.4.2 does not mean the browser extension has it — always check the specific product’s tag if the vulnerability affects a specific client.

Simple repos (e.g., sm-action) use direct pushes without cherry-picks. For those, compare/COMMIT_SHA...TAG returning "ahead" means the TAG is a descendant of the commit — i.e., the commit IS in the release.

To confirm a release has been deployed to production, check the published date from gh release list. If publishedAt is in the past and the release is not draft/prerelease, it is live.

Step 5 — Determine action token for each VULN

Apply this decision tree to every VULN, using the child item statuses classified in Step 3 and the PR/release data from Step 4:

VULN status "Ready for Resolution":
  → No child items linked?                                     → ➖ No Child Item
  → Child item exists, status Not Started?                     → ⚪ Waiting
  → Child item In Progress?                                    → 🔴 Update VULN to In Progress
  → All child items Done?                                      → 🟡 Mark Remediated

VULN status "In Progress" or "In Review":
  → Child item(s) still In Progress?                          → 🔵 Monitor
  → All child items Done, PR not yet found?                   → 🟡 Mark Remediated (investigate date)
  → All child items Done, PR merged?                          → 🟡 Mark Remediated (use PR merge date)

VULN status "Remediated":
  → Cannot determine release?                                  → 🔵 Monitor
  → PR in an upcoming/unreleased version?                      → 🔵 Monitor (release pending)
  → PR in a released, deployed version?                        → 🟢 Verify & Close

The Remediation Date should be the date the fix PR was merged to the default branch.

Step 6 — Format the output report

Use this template. Omit any section (including <details> blocks) that has zero items — do not render empty headings or empty tables.

# 🤖 HackerOne VULN Audit — {YYYY-MM-DD}

## Summary

| Token | Category                 | Count |
| ----- | ------------------------ | ----- |
| 🔴    | Need Status Update       | {n}   |
| 🟡    | Ready to Mark Remediated | {n}   |
| 🟢    | Ready to Verify & Close  | {n}   |
| 🔵    | Monitoring               | {n}   |
| ⚪    | Waiting                  | {n}   |
| ➖    | Missing Child Item       | {n}   |

{2–4 bullets: overall remediation health, anything overdue or stalled, patterns worth noting, any tickets with incomplete data that need manual follow-up}

## 🔴 Update VULN Status

| VULN            | Priority | Summary                        | HackerOne       | Child Item(s)   | Child Status | Action                   |
| --------------- | -------- | ------------------------------ | --------------- | --------------- | ------------ | ------------------------ |
| [VULN-529](...) | High     | Summary truncated to ~60 chars | [

Formatting notes:

VULN: Jira link, e.g. [VULN-529](https://bitwarden.atlassian.net/browse/VULN-529)
HackerOne: Report link extracted from the first line of the description, e.g. [#3673748](https://hackerone.com/reports/3673748). If not found, show unknown and flag it in the summary bullets.
Child Item(s): Jira link(s), e.g. [PM-35250](https://bitwarden.atlassian.net/browse/PM-35250). If multiple, list each on its own line within the cell.
PR / Release: e.g. [#1234](PR_URL) → v2026.8.0 ✅ deployed, [#1234](PR_URL) → v2026.9.0 ⏳ pending, or No PR found
Action: One-line plain-English instruction specific to the token, e.g. “Move to In Progress”, “Set Remediated + Remediation Date: 2026-04-30”, or “Verify fix in prod, add Confirmation Date, close HackerOne #3673748”
Truncate long summaries to ~60 chars

Edge cases

VULN with 3+ child items (e.g., one abandoned, one done, one in progress): the in-progress one drives the token. Show all children in the table.
Child item abandoned / Won’t Fix: Skip it for status purposes. If all children are abandoned, flag the VULN with 🔵 and note “all child items abandoned — review needed.”
Fresh VULN with no description HackerOne URL: Extract the report URL from the first line of the description. If not found, show “HackerOne: unknown” and flag it.
PR search returns no results: Note “No PR found” in the table and still apply the decision tree using child item status alone.
Fix version “vNext-full” or similar placeholder: Treat as “unreleased” until a real version number appears.

Install this repository

$ npx skills add bitwarden/ai-plugins

» /plugin marketplace add bitwarden/ai-plugins

Skills install per repository, not per chapter — the CLI has no documented per-skill form, so we do not print one.

Colophon for this issue

Colophon

How this issue was made

Source

github.com/bitwarden/ai-plugins, branch main, last pushed 8 August 2026.

Licence

Other — the text of every chapter is reproduced unmodified, frontmatter included, under the upstream licence.

Discovery

59 chapters found by walking the repository tree for SKILL.md, not by matching a directory convention. 13 distinct layouts observed: plugins/bitwarden-atlassian-tools/skills/*/SKILL.md, plugins/bitwarden-code-review/skills/*/SKILL.md, plugins/bitwarden-delivery-tools/skills/*/SKILL.md, plugins/bitwarden-design-tools/skills/*/SKILL.md, plugins/bitwarden-designer/skills/*/SKILL.md, plugins/bitwarden-devops-engineer/skills/*/SKILL.md, plugins/bitwarden-product-analyst/skills/*/SKILL.md, plugins/bitwarden-security-engineer/skills/*/SKILL.md, plugins/bitwarden-shepherd/skills/*/SKILL.md, plugins/bitwarden-tech-lead/skills/*/SKILL.md, plugins/bitwarden-testing-tools/skills/*/SKILL.md, plugins/claude-config-validator/skills/*/SKILL.md, plugins/claude-retrospective/skills/*/SKILL.md.

Issue colours

Resolved from a deterministic hash of the owner name. Two accent tones are generated per issue and each is proven against its own ground before it ships: a single accent that passes AA on both light and dark paper is arithmetically impossible.

Heading repairs

None needed in this chapter: the outline was already valid.

Spec compliance

14 editorial notes across 7 of 59 chapters. They are printed in the margin of each chapter rather than as errors here.

Images

Images inside a chapter come from the upstream repository. Where the author gave no alternative text we mark the image decorative rather than inventing a description — a plausible caption we made up is worse than none for the reader who depends on it.

Marketplace

A plugin manifest is published at .claude-plugin/marketplace.json by Bitwarden, declaring 16 plugins. It is read for editorial metadata only — never as the skill index, which is always the repository tree.

Signal

Install counts come from skills.sh. They measure downloads, not quality, and an unranked repository is not an unread one.

Agent surfaces

The whole issue is available as one markdown document at /bitwarden/ai-plugins.md, and each chapter at its own .md URL.

Publication

Set by Skills Docs from the source repository. Body text is Literata at the reader’s chosen size and measure; code is Geist Mono. Nothing on this page was written by us except this paragraph.

bitwarden/ai-plugins

Markdown for agents

#3673748

](

...

) | [

PM-35250

](

...

) | In Progress | Move VULN to In Progress |

## 🟡 Mark Remediated

| --------------- | -------- | ------------------------------ | --------------- | --------------- | ------------------------------ | --------------------------------------------- |

## 🟢 Verify & Close

| --------------- | -------- | ------------------------------ | --------------- | --------------- | ------------------------------------ | ------------------------------------------------------------------- |

<summary>🔵 Monitoring ({n} items — no action needed yet)</summary>

| --------------- | -------- | ------------------------------ | --------------- | --------------- | ------------ | ----------------------------------- |

</details>

<summary>⚪ Waiting ({n} items — not yet started)</summary>

| --------------- | -------- | ------------------------------ | --------------- | --------------- | -------------------- |

</details>

<summary>➖ Missing Child Item ({n} items — needs engineering ticket)</summary>

| --------------- | -------- | ------------------------------ | --------------- | -------------------- | ---------- |

| [VULN-529](...) | Low | Summary truncated to ~60 chars | [#3673748](...) | Ready for Resolution | 2026-03-15 |

</details>