開発ライフサイクルのどの地点でAikidoが何を守るのか。Redis CVE-2026-23479を実例に、エディタ、リポジトリ、CI、コンテナ、VM、ランタイム、SBOMまでを一枚の地図で整理する。
2026年6月、Redis に認証済みリモートコード実行（RCE）の脆弱性 CVE-2026-23479 が公表された。use-after-free 系の不具合で、7.2.0 以降のすべての安定版に約2年間潜伏していた。複数回のセキュリティレビューをすり抜け、最終的にこれを発見したのは人手のコードレビューではなく、大規模コードベースを探索する自律型AIツールだった。
ここで多くの開発者が直面するのは、シンプルだが答えにくい問いだ。
この問いに即答できるかどうかは、セキュリティを開発フローの「どこに」置いているかで決まる。本記事は、Aikido を開発ライフサイクルのどの地点に配置すると何を守れるのかを、一枚の地図として整理する。
コードを書いてからデプロイするまでの流れは、性質の異なる2つのフェーズに分かれる。
セキュリティツールを1か所だけに置くと、必ずどちらかが手薄になる。Aikido はこの両方のフェーズをカバーする設計になっている。以下、ステージごとに見ていく。
リポジトリに乗ったコード全体をスキャンする。
PR（プルリクエスト）を作成すると CI が走り、差分に対して SAST / SCA / secrets / IaC を自動でスキャンする。Critical があればマージをブロックできる。
「テストが緑になるまでマージ不可」という branch protection と組み合わせると、未検証のコードが本番へ進む経路を物理的に塞げる。ここが、セキュリティを開発フローに効かせる最大のレバーになる。
ここまでが「コードを静的に見る」段階だ。
ここから下は、性質が変わる。スキャン対象がソースコードではなく、**デプロイされて“動いているモノ”**になる。
デプロイした後は、新しくパッケージを install するわけではない。関心は「いま動いている成果物に、何が焼き込まれているか（inventory）」へと移る。
ここで SBOM（CycloneDX / SPDX 形式の部品表）が効く。成分表を持っておけば、新しい CVE が公表されるたびに自分の在庫と照合し、「該当するか・しないか」を即座に判定できる。CVE が出てから慌ててコードを grep する、という作業から解放される。
冒頭の Redis CVE を、この地図に当てはめてみる。Redis は自前コードの依存ライブラリとして入っているとは限らない。Docker イメージの中、VM の OS パッケージ、Kubernetes 上、あるいは managed Redis として——「自分のどこに Redis がいるか」は、SCA だけでなく container / VM / runtime / SBOM まで見て初めて分かる。
「脆弱性に気づく → 直す → 安全に出し直す」が、いつもの git フローにそのまま吸い込まれる。セキュリティを“別作業”ではなく“流れの一部”にしておくと、対応がこれだけ素直になる。
通常、SAST・SCA・secrets・IaC・CSPM・DAST・ランタイム保護は、それぞれ別ベンダー製品の寄せ集めになりがちだ。Aikido の「all-in-one」とは、前半（コード）から後半（環境）、そして継続管理（SBOM）までの全レーンを1つのツールで通せることを指す。
セキュリティを「どこか1点」ではなく「開発の流れ全体」に置けるか——その地図を1枚で描けるかどうかが、CVE が出た瞬間の対応速度を分ける。
Aikido Community Japan
公開日: 2026/6/5
最終更新: 2026/6/5
セキュリティの最新情報をお届けします。