triaging-security-findings

扫描器概况

Bitwarden 使用 Aikido 作为统一的安全平台。Aikido 会持续扫描已连接的仓库，并在同一个信息流中展示 SAST、IaC、SCA（开源）、机密信息、云、容器、恶意软件、EOL 和许可证类别的发现项。

通过 aikido:issues 技能（aikido_issues_list）查询和分类发现项，而不是使用 GitHub 代码扫描警报——Aikido 的分类结果不会流入 GitHub Advanced Security。有关范围筛选条件、issue_types 和 SLA 筛选条件（out_of_sla、sla_due_soon）的完整列表，请参阅该技能。

如果 aikido:issues 技能不可用（未安装 aikido 插件，或尚未运行 /aikido:setup），请停止操作并告知用户，而不要在缺少这些数据的情况下继续。这仅适用于 Aikido 信息流分类——下方的 Dependabot 和机密扫描流程原生集成于 GitHub，无需 Aikido 即可运行。

GitHub 原生警报（Dependabot、机密扫描）

Aikido 迁移不会影响 Dependabot 和 GitHub 机密扫描——它们仍是 GitHub 原生功能，并且与 Aikido 信息流分开查询。

Dependabot 警报

# 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}

机密扫描警报

# 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}'

Aikido 发现项分类

Aikido 发现项通过 Jira 处理，而不是通过 Aikido 自身的忽略状态或 GitHub Advanced Security 处理。

1. 使用下方的误报处理协议评估发现项。
2. 确定 Team 字段——先查 CODEOWNERS，再查提交历史。如果无法有把握地确定，请标记为需要人工跟进。
3. 按照下方的映射表确定 Severity，并使用 v3.0 约定记录 CVSS 基础分数——在评论中引用完整的向量字符串，以便复现。

评论格式

将 Jira 分类评论写成五个带标签的段落，顺序必须严格如下，不要写成开放式散文：

• **Finding：**标出的问题——来源（Aikido/Renovate/SAST/CVE/GHSA/CWE）、具体文件/行或软件包/版本，以及为撰写此内容所检查的资料（仓库检出内容、反编译程序集、公告数据库等）。
• **Declaration：**先写判定词（AFFECTED / NOT AFFECTED / unable to determine），再说明技术推理/证据——可达性、代码路径、配置、缓解措施。
• **Effective severity：**分析后的严重性，使用 CVSS v3.0 和完整的向量字符串；如果与信息流中的原始严重性不同，需明确指出，并用一句话说明调整原因。添加指向被标记代码的可点击 GitHub blob+行链接。
• **Status：**当前修复状态——已合并/未合并、已发布/未发布，以及已验证的内容和仍存在的缺口。
• **Action：**具体的下一步行动及负责人/团队路由（或写“无需修复”）。

当一个工单包含多个不同的发现项时（例如多个 XSS 位置），请使用精简的 Markdown 表格，列为 Finding | Declaration | Severity/CWE | Owner | Action required，而不是为每一行重复五个段落。

误报处理协议

在写出 NOT AFFECTED Declaration 前，请核实：

1. **追踪数据流。**不可信输入是否真的能到达被标记的接收点？从入口点开始，经过每次转换，一直追踪到被标记的位置。
2. **检查是否已有净化处理。**仅做验证是不够的——相比不会替换威胁值、只是不进行编码/转义的验证器，应优先使用净化器（会替换威胁值）。不要仅凭验证步骤就判定为 NOT AFFECTED。
3. **考虑完整生命周期。**即使代码目前未部署到有风险的环境中，未来是否会部署？私有仓库可能会公开。本地部署可能会迁移到云端。如果部署到生产环境后会导致可利用性，就应视为当前可利用。
4. **在 Declaration 段落中记录理由。**每个 NOT AFFECTED 判定都需要清晰且可供审查的说明。

如果对任何步骤存在疑问，请判定为 unable to determine，而不是 NOT AFFECTED，并通过 Action 字段转交团队审核。

严重性映射（Jira → Aikido）

Jira 的 Severity 字段（Informative、Low、Medium、High、Hotfix）比 Aikido 自身的严重性等级（Critical、High、Medium、Low）多一个值。将工单的严重性同步回 Aikido 问题时：

Jira Severity	Aikido
Hotfix	Critical
High	High
Medium	Medium
Low	Low
Informative	忽略

Informative 没有对应的 Aikido 严重性等级——应在 Aikido 中将发现项的状态设为忽略，而不是为其分配严重性。

按组执行操作

Aikido 发现项按问题组组织（每个包或规则对应一个组，涵盖它出现的所有仓库和位置）。按严重性筛选的 aikido_issues_list 拉取结果，或 Jira 工单中列出的仓库集合，通常都只是某个组实际成员的_部分样本_，而不是整个组。

在建议或批准任何组级操作（调整严重性、忽略、暂缓）之前，使用不带严重性或 SLA 筛选条件的 aikido_issues_list 拉取该组的完整未筛选成员列表，并将其与促使你采取操作的范围进行差异对比。如果结果显示的仓库或位置超出实际已验证的范围，则应先验证这些仓库或位置，再采取操作；或者将操作限定于单独已验证的位置，而不是整个组，以免影响未经验证的位置。只有在未筛选的拉取结果确认该组的实际成员与已检查的内容一致后，组级操作才是安全的；否则，它会在误分流真正需要处理的位置时，悄然一并误分流未经验证的位置。此技能对 Aikido 只有读取权限（aikido_issues_list）；实际操作需在 Aikido 控制面板中执行——这一步是为了在执行操作前确认范围，而不是直接调用 API 执行操作。

工单范围在创建时固定

组的成员并非静态不变——后续的 Aikido 扫描可能会在 Jira 工单创建后向组中添加新位置。不要将新出现的位置纳入现有工单的范围。工单范围应限定为工单创建时该组的成员；工程团队可能已经按照工单最初确定的范围开展工作，悄然扩大范围会在修复过程中改变他们的工作内容。

如果后续扫描发现的位置超出现有工单最初确定的范围，应为这些位置新建一张工单，而不是重新打开或扩大旧工单。即使底层是同一个组、包或规则，也应在新位置出现时间晚于原工单时，为同一组创建新工单。

修复实施模式

按漏洞类型划分的常见修复模式：

漏洞	错误	正确
SQL 注入	在查询中拼接字符串	参数化查询／存储过程
XSS	在 HTML 中直接插入未处理的内容	输出编码／框架自动转义
路径遍历	直接使用用户提供的路径	规范化路径，并验证其是否位于允许的基础路径下
SSRF	直接使用用户提供的 URL	对允许的主机／方案进行许可名单限制
不安全的反序列化	使用类型信息反序列化不可信输入	使用安全的序列化器，避免使用 TypeNameHandling.All
硬编码密钥	在源代码中存放凭据	环境变量／Azure Key Vault
XXE	使用默认 XML 解析器设置	禁用 DTD 处理和外部实体