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
bash# 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
bash# 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.
- Assess the finding using the False Positive Protocol below.
- Resolve the
Teamfield — CODEOWNERS first, then commit history. Flag for human follow-up if it can't be confidently determined. - Determine
Severityper 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:
- Trace the data flow. Can untrusted input actually reach the flagged sink? Follow it from entry point through every transformation to the flagged location.
- 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 AFFECTEDon the basis of a validation step alone. - 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.
- Document the rationale in the Declaration paragraph. Every
NOT AFFECTEDverdict 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, snoozing), use aikido_issues_list with no severity or SLA filter to pull the group's full unfiltered membership and diff it against whatever scope prompted the action. If that shows repos or occurrences beyond what was actually verified, either verify those too before acting, or scope the action to the individual verified occurrences rather than the whole group, so unverified occurrences are left untouched. A group-level action is only safe once the unfiltered pull confirms the group's true membership matches what was checked — otherwise it silently mis-triages the unverified occurrences alongside the real ones. This skill only has read access to Aikido (aikido_issues_list); applying the action itself happens in the Aikido dashboard — this step is about verifying scope before that happens, not about calling an API to do it directly.
Ticket Scope Is Pinned at Creation
A group's membership is not static — a later Aikido scan can add new occurrences to a group after its Jira ticket already exists. Don't fold newly-arrived occurrences into an existing ticket's scope. Scope a ticket to the group's membership as of the ticket's creation time; the engineering team may already be working the ticket as originally scoped, and silently widening it moves the ground under them mid-fix.
When a later scan surfaces occurrences beyond an existing ticket's original scope, file a new ticket for those occurrences rather than reopening or expanding the old one. This applies even if it's the same underlying group/package/rule — same group, new ticket, if the new occurrences postdate the original ticket.
Fix Implementation Patterns
Common remediation patterns by vulnerability type:
| Vulnerability | Wrong | Right |
|---|---|---|
| SQL Injection | String concatenation in queries | Parameterized queries / stored procedures |
| XSS | Raw interpolation in HTML | Output encoding / framework auto-escaping |
| Path Traversal | Direct use of user-supplied paths | Canonicalize + validate against allowed base path |
| SSRF | Direct use of user-supplied URLs | Allowlist of permitted hosts/schemes |
| Insecure Deserialization | Deserializing untrusted input with type info | Use safe serializers, avoid TypeNameHandling.All |
| Hardcoded Secrets | Credentials in source code | Environment variables / Azure Key Vault |
| XXE | Default XML parser settings | Disable DTD processing and external entities |
