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、シークレットスキャン）

Dependabot と GitHub シークレットスキャンは Aikido への移行の影響を受けません。引き続き 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 のトリアージコメントは、自由記述ではなく、以下のラベル付き段落を指定された順序で5つ記載してください。

• Finding： 検出された内容 — 検出元（Aikido/Renovate/SAST/CVE/GHSA/CWE）、該当するファイル／行またはパッケージ／バージョン、および記述にあたって確認した内容（リポジトリのチェックアウト、逆コンパイルしたアセンブリ、アドバイザリデータベースなど）。
• Declaration： まず判定語（AFFECTED / NOT AFFECTED / unable to determine）を記載し、続けて技術的な根拠や証拠（到達可能性、コードパス、設定、緩和策）を記載します。
• Effective severity： 分析後の重大度を、ベクトル文字列全体を含む CVSS v3.0 で記載します。変更があった場合は生のフィード重大度との違いを明記し、調整した理由を1行で説明します。検出されたコードへのクリック可能な GitHub の blob+行リンクを含めてください。
• Status： 現在の修正状況 — マージ済み／未マージ、リリース済み／未リリース、確認済みの内容と残っている課題。
• Action： 具体的な次のステップと担当チームへの割り当て（または「修正不要」）。

1つのチケットに複数の異なる検出結果（例：複数の XSS 箇所）が含まれる場合は、各行で5段落を繰り返すのではなく、Finding | Declaration | Severity/CWE | Owner | Action required の列を持つ簡潔な Markdown テーブルを使用してください。

誤検知プロトコル

NOT AFFECTED の Declaration を記載する前に、以下を確認してください。

1. データフローを追跡します。 信頼できない入力が、実際に検出されたシンクに到達し得るかを確認します。エントリポイントから、すべての変換処理を経て検出箇所に至るまで追跡してください。
2. 既存のサニタイズ処理を確認します。 バリデーションだけでは不十分です。元の値を置き換えるサニタイザーは、元の値を残すエンコード／エスケープなしのバリデーターよりも優先されます。バリデーション処理だけを根拠に NOT AFFECTED と判定しないでください。
3. ライフサイクル全体を考慮します。 現時点でコードがリスクのある環境にデプロイされていないとしても、将来デプロイされる可能性はないでしょうか。プライベートリポジトリが公開される場合があります。ローカルデプロイがクラウドに移行する場合があります。本番環境へのデプロイで悪用可能になるなら、現時点でも悪用可能として扱ってください。
4. Declaration の段落に根拠を記録します。 NOT AFFECTED と判定する場合は必ず、明確でレビュー可能な説明を記載してください。

いずれかの手順に確信が持てない場合は、NOT AFFECTED ではなく unable to determine と判定し、Action フィールドでチームレビューに回してください。

重大度のマッピング（Jira → Aikido）

Jira の Severity フィールド（Informative、Low、Medium、High、Hotfix）には、Aikido 独自の重大度スケール（Critical、High、Medium、Low）より 1 つ多く値があります。チケットの重大度を Aikido の課題に同期する際は、次のようにマッピングします。

Jira Severity	Aikido
Hotfix	Critical
High	High
Medium	Medium
Low	Low
Informative	Ignore

Informative に相当する Aikido の重大度はありません。重大度を割り当てるのではなく、Aikido で検出結果のステータスを Ignore に設定してください。

グループ単位のアクション

Aikido の検出結果は課題グループ（パッケージまたはルールごとに 1 グループで、該当するすべてのリポジトリと出現箇所を網羅）にまとめられます。重大度でフィルタリングした 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 処理と外部エンティティを無効にする