/triaging-security-findings

name: triaging-security-findings
description: This skill should be used when the user asks to "triage security findings", "fix an Aikido finding", "review Aikido issues", "dismiss a false positive", "check SAST/IaC alerts", or needs to work with Aikido feed issues, GitHub Dependabot alerts, or GitHub secret scanning alerts.

Scanner Landscape

Bitwarden uses **Aikido** as its unified security platform. Aikido continuously scans connected repositories and surfaces findings across SAST, IaC, SCA (open source), secrets, cloud, container, malware, EOL, and license categories in a single feed.

Findings are queried and triaged via the `aikido:issues` skill (`aikido_issues_list`), not through GitHub code-scanning alerts — Aikido triage does not flow through GitHub Advanced Security. See that skill for the full list of scope filters, `issue_types`, and SLA filters (`out_of_sla`, `sla_due_soon`).

If the `aikido:issues` skill is unavailable (the `aikido` plugin isn't installed or `/aikido:setup` hasn't run), stop and tell the user rather than proceeding without this data. This applies to Aikido feed triage only — the Dependabot and secret-scanning paths below are GitHub-native and run without Aikido.

GitHub-Native Alerts (Dependabot, Secret Scanning)

Dependabot and GitHub secret scanning are unaffected by the Aikido transition — they remain GitHub-native and are queried separately from the Aikido feed.

Dependabot Alerts

# List open Dependabot alerts
gh api --method GET -H "X-GitHub-Api-Version: 2026-03-10" /repos/{owner}/{repo}/dependabot/alerts --jq '.[] | {number, state, severity: .security_vulnerability.severity, package: .security_vulnerability.package.name, ecosystem: .security_vulnerability.package.ecosystem}'

# Get specific alert details
gh api --method GET -H "X-GitHub-Api-Version: 2026-03-10" /repos/{owner}/{repo}/dependabot/alerts/{alert_number}

Secret Scanning Alerts

# List secret scanning alerts
gh api --method GET -H "X-GitHub-Api-Version: 2026-03-10" /repos/{owner}/{repo}/secret-scanning/alerts --jq '.[] | {number, state, secret_type, created_at}'

Triaging Aikido Findings

Aikido triage is handled through Jira, not through Aikido's own dismissal states or GitHub Advanced Security.

1. **Assess the finding** using the False Positive Protocol below. 2. **Resolve the `Team` field** — CODEOWNERS first, then commit history. Flag for human follow-up if it can't be confidently determined. 3. **Determine `Severity`** per the mapping table below, and record the CVSS base score using the **v3.0** convention — cite the full vector string in the comment for reproducibility.

Comment Format

Write the Jira triage comment as five labeled paragraphs, in this exact order, not open prose:

• **Finding:** what was flagged — source (Aikido/Renovate/SAST/CVE/GHSA/CWE), the specific file/line or package/version, and what was reviewed to write this (repo checkout, decompiled assembly, advisory DB, etc).
• **Declaration:** the verdict word first (`AFFECTED` / `NOT AFFECTED` / `unable to determine`), then the technical reasoning/evidence for it — reachability, code path, config, mitigating controls.
• **Effective severity:** the severity after analysis, using **CVSS v3.0** with the full vector string, called out against the raw feed severity if it changed, with a one-line reason for any adjustment. Include a clickable GitHub blob+line link to the flagged code.
• **Status:** current remediation state — merged/unmerged, released/unreleased, what's verified vs. still a gap.
• **Action:** concrete next step and ownership/team routing (or "no fix needed").

When one ticket bundles multiple distinct findings (e.g. several XSS sites), use a condensed markdown table with columns `Finding | Declaration | Severity/CWE | Owner | Action required` instead of repeating the five paragraphs per row.

False Positive Protocol

Before writing a `NOT AFFECTED` **Declaration**, verify:

1. **Trace the data flow.** Can untrusted input actually reach the flagged sink? Follow it from entry point through every transformation to the flagged location. 2. **Check for existing sanitization.** Validation alone is insufficient — sanitizers (which replace threatening values) are preferred over encoding/escaping-free validators (which leave the original value in place). Don't declare `NOT AFFECTED` on the basis of a validation step alone. 3. **Consider the full lifecycle.** Even if the code isn't deployed to a risky environment today, will it be? Private repos may go public. Local deployments may move to cloud. If deploying to production would make it exploitable, treat it as exploitable now. 4. **Document the rationale in the Declaration paragraph.** Every `NOT AFFECTED` verdict needs a clear, reviewable explanation.

If any step is uncertain, declare `unable to determine` rather than `NOT AFFECTED`, and route it through the **Action** field for team review.

Severity Mapping (Jira → Aikido)

The Jira `Severity` field (Informative, Low, Medium, High, Hotfix) has one more value than Aikido's own severity scale (Critical, High, Medium, Low). When syncing a ticket's severity back to the Aikido issue:

| Jira `Severity` | Aikido | | --------------- | ---------- | | Hotfix | Critical | | High | High | | Medium | Medium | | Low | Low | | Informative | **Ignore** |

`Informative` has no Aikido severity equivalent — set the finding's status to **Ignore** in Aikido rather than assigning a severity.

Group-Scoped Actions

Aikido findings are organized into **issue groups** (one group per package or per rule, spanning every repo and occurrence it appears in). A severity-filtered `aikido_issues_list` pull, or the set of repos named in a Jira ticket, is often only a _sample_ of a group's true membership — not the whole group.

Before recommending or approving any group-level action (adjusting severity, ignoring