Aikidoで脆弱性1件を直すまで — Issue詳細画面に見る5つの視点

はじめに

脆弱性スキャンツールを評価するとき、多くの人はまずダッシュボードを見ます。集約された数字、綺麗なグラフ、優先度のヒートマップ。たしかにそれは大事です。

しかし、実際に脆弱性を直すエンジニアの仕事は、1件のIssue詳細画面で行われます。ダッシュボードは全体像を把握する入口、Issue詳細は実際に修正作業が行われる現場、という関係です。

この記事では、Aikidoのダッシュボード全体ではなく、実際に修正作業の起点になるIssue詳細画面に焦点を当てます。ダッシュボードで全体像を把握した後、1件の脆弱性をどう理解し、優先度を判断し、修正につなげるのか。その流れを見ていきます。

---

1. Issue一覧 — 何を先に直すべきかを見る

まずはIssuesタブの一覧画面から見ていきます。並んでいるのは多様な検出結果です。

• Potential SQL injection via string-based query concatenation (Python)
• Open redirect can be used in social engineering attacks (JavaScript)
• Using unserialize can lead to remote code execution (PHP)
• XSS attack possible (sanitize-html)
• Attacker can abuse improper authentication (Ruby / rack-session)
• GPL-2.0-or-later (ライセンス検出)
• Debian Linux version no longer receiving security updates (OS EOL)
• Out-of-bounds read can expose sensitive info (openssl)

注目すべきは言語アイコンとIssueの多様性です。SCA(依存パッケージ) / SAST(ソースコード) / Secrets / License / OS EOL / DAST — AppSecの主要カテゴリがすべて1つのリストに混在しています。

多くのツールはこれらをカテゴリ別に分けて表示します。Aikidoの一覧画面では、Issueを「SeverityとFix time」を軸に見られるようになっています。エンジニアにとって意味があるのは「種類」ではなく「いま何を先にやるべきか」だからです。

---

2. Issue詳細の4タブ構造 — 何が起きているか、どう直すか

先ほどの画面の右側パネルを見てみましょう。任意のIssueをクリックすると右側にパネルが開き、Overview / Activity / Tasks / Education の4タブが並びます。それぞれの役割を見ていきましょう。

Overview — 「何か」と「どう直すか」

最初に開かれるタブです。次の要素が並びます。

• Risk Score (例: 87 / High Risk) — Severityだけでなく、文脈も加味した優先度スコア
• 状態タグ — To Do / PR Open / New / Dependency など
• TL;DR — 30秒で理解できる要約
• Does this affect me? — 自分の使い方で影響があるか
• How do I fix it? + AutoFixボタン — PR自動生成
• Subissues — 影響箇所の一覧(View reachability analysisリンク付き)

Activity — 検知履歴のタイムライン

検知された瞬間から状態が変化するまでの履歴です。AIによる優先度の自動再評価もここに記録されます。

Tasks — チケット連携

Jira / Linear / ClickUpなどへの連携です。1つのIssueから複数のチケットを切ることもできます(画面ではTasks (3)のように数字で表示されます)。

Education — 学びながら直す(対応コンテンツがある場合)

一部のIssueでは、Secure Code Warrior (SCW) の教育コンテンツが紐づきます。すべてのIssueに教育動画があるわけではありませんが、対応するコンテンツがある場合は、修正作業の流れの中で「なぜそれが脆弱性なのか」を確認できます。

先ほどの画面の右側に見えるのが、その例です。rack-sessionのReliance on Cookies without Validation and Integrity CheckingというCWEパターンに対し、2分16秒の動画が再生できます。Powered by SCWのラベル付きで、ベンダーパートナーシップが明示されています。

監査やセキュリティ教育の文脈でも、運用次第では補助的な材料として使いやすい設計と言えます。

---

3. View code analysis — コード行、AI評価、SLAまで見る

Aikidoの強みが一番出るのがこの領域です。コードと依存関係の検出に対して、実コード行まで表示する設計になっています。スクショの例を見てみましょう。

ファイル: lib/simplepie/simplepie/src/Cache/File.php 脆弱な行: line 88

return unserialize((string) file_get_contents($this->name));

unserialize()に外部入力(ファイルから読み込んだ内容)を直接渡しています — 典型的なPHPオブジェクトインジェクション(CWE-502)パターンです。ハイライトでその行が強調されています。

左ペインのRecommendationがさらに踏み込みます。

Upgraded — Aikido AI applied an upgrade, bringing issue priority to critical.

unserialize() reads cached file contents that are not proven safe or sanitized, allowing externally influenced serialized payloads; treat as high priority.

AIが自動で優先度をCriticalに引き上げた理由が明示されています。「なぜ重大なのか」を機械が説明している点が特徴的です。

下部のCall Treeにはlib/simplepie/simplepie/src/Cache/File.php::loadという呼び出し経路 — どこからこの危険な行が呼ばれるかが分かります。

横のAsk Aikidoボタンを押せば、この脆弱性についてさらに質問できます(これは章4で見ます)。

同じ脆弱性が複数箇所に現れたとき

同じunserialize問題はこのリポでは5箇所に分散しています。

最後のRedis.phpだけ評価が一段下がっています。理由はその下のラベルで分かります。

⬇ Downgraded: AI assessed finding as somewhat hard to ...

別リポ(drupal)の検出には次のラベルが付いています。

⬇ Downgraded: Service not internet-connected

逆方向もあります。

⬆ Upgraded: AI assessed finding as likely exploitable

つまりAikidoのAIは「この検出はexploitしやすいか、しにくいか」を判断し、優先度を上下させ、その理由を表示します。

「なぜcriticalをmediumに下げたか」を説明できる仕組みは、コンプライアンス文脈でも理解されやすい設計です。

Out of SLAバッジは「対応期限を過ぎた」サインで、SLA管理機能と連動しています。

---

4. Reachability Analysis と Ask Aikido — 到達性と修正方針を確認する

依存パッケージの脆弱性に対するAikidoの答えがReachability Analysisです。

スクショの例はgolang.org/x/oauth2 v0.25.0のAIKIDO-2025-10169 (High)。Subissueにv0.25.0 → 0.27.0のアップグレード提案が出ています。View reachability analysisリンクをクリックして、依存経路を見てみます。

依存経路:

stratus-red-team
  → github.com/datadog/stratus-red-team/v2
      → golang.org/x/oauth2:v0.25.0

リポジトリから3ホップで脆弱なバージョンに到達しています。

横のペインでAsk Aikidoに質問してみます。「この脆弱性について教えて」と聞くと、次のような回答が返ってきます。

Vulnerability Summary
CVE: AIKIDO-2025-10169
Severity: HIGH
Issue: Unlimited Resource Consumption leading to DoS

The golang.org/x/oauth2 package (v0.25.0) is vulnerable to a
denial-of-service attack where malformed tokens can cause
excessive memory consumption during parsing.

Analysis:
- Reachability: Unable to determine if vulnerable code paths
  are actively used in your codebase
- Fix Available: Yes, upgrade to v0.27.0
- Breaking Changes: None identified between v0.25.0 and v0.27.0

Upgrade Command:
  go get golang.org/x/oauth2@v0.27.0
  go mod tidy

Recommendation:
Since this is a HIGH severity DoS vulnerability with an
available fix and no breaking changes, upgrading is strongly
recommended even without confirmed reachability.

ChatGPTのような汎用AIと違うのは、Aikidoが持つ自社環境の文脈(依存ツリー / 検出位置 / コード / 修正バージョン情報)を踏まえた回答が返ってくる点です。

「Reachability: Unable to determine」のような正直な不確実性表明も大事だと思います — 万能を装わない設計です。

---

5. 補足: Cloud / VM — 実行環境側の文脈も確認する

ここまでは主にコードと依存関係の視点でした。Aikidoの中心的な強みは、やはりCode Scan / SCA / Secrets / Licenseなど、開発者が日々扱うリポジトリ周辺の検出と修正導線にあります。

一方で、利用している機能や設定によっては、Cloud / VM側の文脈もIssueとして確認できます。ここではその例として、AWS Cloud上の検出を見てみます。

AWS Cloudタブを開くと57件のIssueが並びます。

• rack-session (Critical, 15min fix time) — Attacker can abuse improper authentication

注目はその検出位置です。

/opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/3.4.0/
  specifications/rack-session-2.1.1.gemspec

この例では、コードリポジトリではなく、稼働環境側に存在するRuby gemの脆弱性もIssueとして表示されています。CVE-2026-39324 (rack::sessionのMarshal deserialization脆弱性)で、Upgraded: Exploit available on Githubのラベルが付いています。

そしてもう一つ、視覚的に分かりやすい機能がAWSアーキテクチャ図です。

1 critical issue on 1 AWS instance reachable via load balancer

VPC内の構成が可視化されます。

Internet
   │ port 80
   ▼
Load Balancer
   │ port 80
   ▼
EC2 Instance  ← 9 CVEs
   │
   ├─ port 3306 ─→ RDS Instance
   └─ aws-elasticbeanstalk-ec2-role
         │
         ▼
       S3 Bucket

問題のEC2インスタンスに**「9 CVEs」のバッジが付き、それがInternetからLoad Balancer経由で直接到達可能**であることが一目で分かります。

コード側のReachability(章4)に対して、こちらは実行環境側のReachabilityという見方ができます。

ただし、この記事の主眼はあくまでコードリポジトリ周辺の修正導線です。Cloud / VMの例は、利用範囲を広げた場合に得られる追加の文脈として見るのが自然です。

---

まとめ — 5つの視点

Aikidoは1件の脆弱性に対して、次の5つの視点を1画面の連続体として提供します。

これがAikido UIに込められた思想だと思います。

ダッシュボードはこの5視点の結果集約地点にすぎません。脆弱性管理ツールの本当の価値は「1件のIssueと向き合うとき、何を見せて何を考えさせるか」に表れるのではないでしょうか。

機会があれば次回、これらの情報がダッシュボード側でどのように集約されるかも見ていきたいと思います。

---

補足: Enterprise評価で見るべきポイント

Enterpriseで脆弱性管理ツールを評価する場合、検知数やダッシュボードの見た目だけでなく、**「1件の脆弱性を修正完了まで進められるか」**を見ることが重要だと考えています。

具体的には次の3点です。

• 検知 → コード行 → 到達性 → 修正 → 学習、を1画面の流れで確認できるか
• AIアセスメントの理由が見えるか(なぜ優先度を上げ下げしたか)
• コード側だけでなく、利用範囲に応じて実行環境側の文脈まで確認できるか

これらを1つの流れとして確認できる点は、Aikidoの大きな特徴だと思います。

なお、自社専用の集約画面が欲しいというニーズに対しては、AikidoのAPIを使ってフロントエンドを構築する選択肢もあります。組織の運用に合わせた柔軟な使い方ができる設計です。