Security

Kali Linux チームが、外部 SaaS に一切依存しない完全ローカルの AI ペンテスト支援環境の構築ガイドを公式ブログで公開した。Ollama でローカル LLM を動かし、MCP（Model Context Protocol）経由で nmap などの Kali ツールを自然言語から操作する構成だ。 構成要素 コンポーネント 役割 アーキテクチャ上の位置づけ Ollama ローカル LLM サーバー。llama.cpp のラッパーとしてモデルのダウンロード・サービングを簡素化 推論エンジン（脳） mcp-kali-server Flask ベースの MCP サーバー（127.0.0.1:5000）。nmap, gobuster, nikto, hydra, sqlmap 等の Kali ツールを MCP 経由で公開 ツールサーバー（手足） 5ire デスクトップ AI アシスタント兼 MCP クライアント。ユーザー入力を LLM に送り、LLM の応答からツール呼び出しを検出し、MCP 経由でツールを実行し、結果を LLM に戻すループを回す AI エージェント（オーケストレーター） この構成で「エージェント」に相当するのは 5ire だ。LLM（Ollama）は推論を担うだけであり、ツールサーバー（mcp-kali-server）は呼ばれるのを待つだけ。ユーザーの意図を解釈し、LLM とツールの間を仲介して自律的にループを回す 5ire こそがエージェントの役割を果たしている。Claude Code に例えると、Ollama は API の向こう側の Claude モデル、mcp-kali-server は MCP サーバー、5ire は Claude Code 本体に相当する。 ...

セキュリティスタートアップ CodeWall の AI エージェントが、マッキンゼーの社内 AI プラットフォーム「Lilli」をわずか2時間で完全突破した。4,650万件のチャット履歴からシステムプロンプトまで、認証なしで読み書き可能だったという。攻撃手法は SQL インジェクション——教科書の1章目に載る古典的な脆弱性だ。 Lilli とは Lilli はマッキンゼーが社内向けに構築した生成 AI プラットフォームで、数万人のコンサルタントが日常的に利用している。戦略立案、M&A 分析、クライアント対応など、機密性の高い業務に活用されていた。 Lilli のアーキテクチャ マッキンゼーは Lilli の技術構成をある程度公開しており、その設計思想と今回の事件のギャップが際立つ。 RAG パイプライン + オーケストレーション層 Lilli のコアは RAG（Retrieval-Augmented Generation）パイプラインだ。40以上のキュレーション済みナレッジソースに10万件超のドキュメント、インタビュー記録、セクター別プレイブックが格納されている。ユーザーのクエリはベクトル埋め込みでマッチングされ、5〜7件の関連文書が引用付きで提示される。四半期あたり約200万クエリを処理する規模だ。 技術スタック LLM: Cohere、OpenAI（Azure 経由）など複数モデルを併用。Microsoft、Google、Nvidia、Anthropic との戦略的パートナーシップ フレームワーク: QuantumBlack の Horizon ツールキット、LangChain、FAISS インフラ: Microsoft Azure（データストレージ・スケーラビリティ） 独自ツール: PowerPoint を85%以上読み取り可能にする独自ドキュメントパーサー 「ゼロトラスト」設計——のはずだった マッキンゼーは Lilli のセキュリティについて、ゼロトラストセキュリティスタック、オンプレミスデータストア、ロールベースアクセス制御（RBAC）、完全な監査ログを備えていると説明していた。しかし実際には、22個の API エンドポイントが認証なしで外部に公開されていた。設計上のセキュリティと実装上のセキュリティの乖離が、今回の事件の根本原因だ。 攻撃の経緯 CodeWall の自律型セキュリティエージェントは、以下の手順で Lilli を攻撃した: 公開 API ドキュメントの発見 — Lilli の API ドキュメントが外部から閲覧可能な状態だった 認証不要エンドポイントの特定 — 22個のエンドポイントが認証なしでアクセス可能だった SQL インジェクションの検出 — ユーザー検索クエリを書き込むエンドポイントで、JSON のキー名が SQL 文に直接連結されていた 本番データベースへのフルアクセス — 読み取りと書き込みの両方が可能な状態に到達 人間の介入は一切なし。AI エージェントが自律的に脆弱性を発見し、エクスプロイトまで完了した。 ...

企業のセキュリティチームは深刻な課題に直面しています。NVD（National Vulnerability Database）に登録される CVE は年間 25,000 件以上。多くの企業では数万〜数十万の脆弱性がスキャンで検出されます。しかし現実は明確で、「すべてを修正することは不可能」です。 この状況を背景に、ガートナーは新しいセキュリティの考え方として Exposure Management（エクスポージャー管理） を提示しました。 CVSS とは何か Exposure Management を理解する前に、従来の脆弱性管理の中核にある CVSS（Common Vulnerability Scoring System） について押さえておきましょう。 CVSS は、脆弱性の深刻度を 0.0〜10.0 のスコアで数値化する国際的な評価基準です。FIRST（Forum of Incident Response and Security Teams）が管理しており、現在は v3.1 と v4.0 が使われています。 スコア 深刻度 9.0〜10.0 Critical（緊急） 7.0〜8.9 High（重要） 4.0〜6.9 Medium（警告） 0.1〜3.9 Low（注意） スコアは以下の観点から算出されます。 攻撃元区分 — ネットワーク経由か、物理アクセスが必要か 攻撃条件の複雑さ — 特殊な条件が必要か 必要な特権レベル — 認証が必要か ユーザ関与 — ユーザの操作（リンクのクリック等）が必要か 影響範囲 — 機密性・完全性・可用性への影響度 CVSS は脆弱性の技術的な深刻度を標準化された方法で伝える点で非常に有用です。しかし、このスコアだけに頼る運用には限界があります。 従来の脆弱性管理の限界 従来のアプローチは「脆弱性スキャン → CVSS スコアで優先順位付け → パッチ適用」というものでした。しかし現代の IT 環境では以下の課題があります。 ...

オープンソースの AI エージェントフレームワーク「OpenClaw」の利用が中国国内で急拡大する中、中国の国家コンピュータネットワーク緊急対応技術チーム（CNCERT）が緊急のセキュリティ警告を発しました。政府機関や国有銀行での使用禁止にまで発展したこの問題について、技術的な背景と対策をまとめます。 何が起きたのか 2026年3月、中国の CNCERT は OpenClaw について「極めて弱いデフォルトセキュリティ設定」を持つと警告を発しました。OpenClaw はローカルファイルシステムや環境変数へのアクセス、拡張機能のインストールなど高いシステム権限を付与されますが、デフォルトのセキュリティ設定が不十分であり、攻撃者がシステム全体の制御を容易に奪取できる状態であると指摘されています。 この警告を受けて、中国当局は政府機関と国有企業（主要銀行を含む）に対し、業務用コンピュータへの OpenClaw のインストールを禁止する通知を出しました。既にインストール済みの職員には、上司への報告・セキュリティチェック・必要に応じた削除が指示されています。 CNCERT が指摘した主なリスク 1. アーキテクチャ設計上の問題 OpenClaw はローカルファイルシステム、環境変数、シェルへの広範なアクセス権限を持ちます。これ自体は AI エージェントの機能として必要ですが、適切な制限なしに運用すると重大なリスクとなります。 2. デフォルト設定の脆弱性 管理 UI のデフォルトポートがインターネットに公開可能な状態 環境変数に認証情報を平文で保存する設定がデフォルト スキルの自動更新が有効な状態がデフォルト 3. プラグインエコシステムの危険性 不正なプラグイン（ポイズンドプラグイン）を通じて、ユーザーのシステムに悪意あるコードが侵入するリスクがあります。プラグインのアクセス権限が十分に制限されていないことが問題視されています。 4. Web ベースの攻撃 悪意ある指示を Web ページに埋め込むことで、OpenClaw に不正な操作を実行させる攻撃（プロンプトインジェクション）が可能です。 5. 重要データの誤削除 AI エージェントの判断ミスにより、ユーザーが意図しない重要データの削除が発生するリスクも指摘されています。 CNCERT の推奨対策 CNCERT は以下の対策を推奨しています。 コンテナで隔離実行する — OpenClaw をホストシステムから隔離された環境で動作させる 管理ポートをインターネットに公開しない — 管理 UI へのアクセスをローカルネットワークに限定する 認証情報を平文で環境変数に保存しない — シークレット管理ツールを使用する スキルの自動更新を無効にする — 更新は手動で検証してから適用する 厳密な認証とアクセス制御を実装する — 不要な権限を排除する セキュリティアップデートへの追従を徹底する — 既知の脆弱性に速やかに対応する AI エージェント全般への教訓 この問題は OpenClaw に限った話ではありません。AI エージェントは本質的に高いシステム権限を必要とするため、以下の原則はどのエージェントツールにも当てはまります。 ...

Claude Codeでツール実行のたびに「パスワード漏洩リスク: 0%」「悪意あるコード実行リスク: 0%」のようなセキュリティリスクのパーセンテージを表示させるCLAUDE.mdの設定がSNSで話題になった。これに対し、セキュリティエンジニアから「それは対策ではなくお気持ち表示」という指摘が上がり、議論を呼んでいる。 話題になった「パーセンテージ表示」 @wan_line_（ワン@AIのお兄さん）氏が2026年3月9日に投稿したポストでは、CLAUDE.mdに以下のようなルールを記述することが提案されていた: ツール実行のたびに パスワードが外に漏れる可能性: ○% 外部サーバーにデータが送られる可能性: ○% 悪意あるコードが動く可能性: ○% PCの設定が書き換わる可能性: ○% Claude Codeで「yes連打」してしまうユーザー向けに、実行前にリスクを可視化してくれるという趣旨だ。 セキュリティ専門家の反論:「お気持ち表示」 この投稿に対し、@sudachikawaii（シンジ☁Shinji）氏が反論した: セキュリティ屋から言うと、これは「対策」ではなく「お気持ち表示」です。LLMはコードの安全性を静的解析していないので、表示されるパーセンテージに技術的根拠がありません。 「0%」を見てyes押すのは、yes連打と同じです。 指摘のポイントは明快だ: LLMは静的解析エンジンではない — LLMが出すパーセンテージは、コードを構文解析して脆弱性を検出した結果ではなく、「それっぽい数値」を生成しているだけ 偽の安心感を与える — 「0%」という表示を見てユーザーが安心してyesを押すなら、結局yes連打と変わらない 技術的根拠がない — 実際のセキュリティリスク分析には、静的解析ツール（SAST）、依存関係チェック、ネットワーク通信の監視などが必要 Claude Codeに本当に効くセキュリティ対策 Claude Codeには、CLAUDE.mdの「お気持ちルール」よりもはるかに実効性のあるセキュリティ機能が組み込まれている。公式ドキュメントに基づき、本当にやるべき対策を整理する。 1. サンドボックスを有効にする 最も重要な対策。Bashコマンドの実行をOSレベルで隔離し、ファイルシステムやネットワークへのアクセスを制限する。 macOSではSeatbelt、LinuxではBubble Wrapが使用される /sandbox コマンドで有効化 2. denyルールで危険なコマンドをブロック permissions.deny に実行禁止コマンドを明示的に設定する。評価順は deny → ask → allow で、denyが最優先。 1 2 3 4 5 6 7 8 9 { "permissions": { "deny": [ "Bash(command:rm -rf *)", "Bash(command:curl *)", "Bash(command:wget *)" ] } } 3. 機密ファイルへのアクセスを遮断 .env やシークレットファイルへのアクセスをブロックする。 ...

「Vibe Coding」が開発者の間で広まる中、同じ発想をサイバー攻撃に応用する「Vibe Hacking」が新たな脅威として注目されている。AI を使って、専門知識がなくてもマルウェアや攻撃スクリプトを生成できる時代が到来した。 Vibe Hacking とは Vibe Hacking は、AI を活用してサイバー攻撃のハードルを劇的に下げる手法・思想を指す。開発者が自然言語で AI にコードを書かせる「Vibe Coding」のダークサイドとも言える概念だ。 従来のハッキングには、ネットワークプロトコルの理解、脆弱性の発見、エクスプロイトコードの記述といった高度な技術スキルが必要だった。しかし Vibe Hacking では「ターゲットを指定するだけ」「経験不要」「AI が処理する」といった形で、技術的な障壁がほぼ消失する。 具体的な脅威 AI 生成マルウェア HP Wolf Security の脅威インサイトレポート（2025年10月〜12月）によると、攻撃者は AI で生成した感染スクリプトを実際の攻撃キャンペーンに使用している。偽のインボイス PDF を通じて、正規のプラットフォーム（Booking.com など）へリダイレクトする前にマルウェアをダウンロードさせる手口が確認されている。 Flat-Pack Malware 複数の無関係な脅威グループが、同一のモジュール化されたマルウェアコンポーネントを再利用する「Flat-Pack Malware」も増加している。市販のマルウェア部品を組み立てるだけで、最小限の労力でカスタマイズされた攻撃キャンペーンを展開できる。 国家レベルの活用 パキスタン系の脅威アクター「Transparent Tribe」が、AI コーディングツールを使ってマルウェアを「Vibe Coding」し、インド政府やその海外大使館を標的にした事例も報告されている。 なぜ危険なのか 攻撃コストの劇的な低下 脆弱性の発見からエクスプロイト作成までのコストは、かつて数週間と数千ドルを要した。AI によりこれがほぼゼロになりつつある。「スプレー＆プレイ」型の大規模攻撃ではなく、特定のシステムや企業、さらには個々の開発者をピンポイントで狙うマイクロターゲット攻撃が現実的になった。 検出回避能力の向上 HP の調査では、メール脅威の 14% 以上がゲートウェイスキャナーを回避している。AI が生成するコードは毎回微妙に異なるため、シグネチャベースの検出が困難になっている。 Vibe Coding で作られたアプリの脆弱性 攻撃だけでなく、Vibe Coding で開発されたアプリケーション側も問題を抱えている。Veracode の GenAI コードセキュリティレポートによると、AI 生成コードの 45% にセキュリティ脆弱性が含まれている。AI はほぼ半分の確率で安全でない実装を選択する。 対策のポイント AI によるコードレビューの自動化 Vibe Coding で生成された全コードを人間がレビューするのは現実的ではない。コード生成が AI なら、レビューも AI で自動化するのが自然な流れだ。 ...

Claude Code や Cursor、Devin といった AI コーディングエージェントの導入が進むなか、「品質をどう担保するか」が最大の課題になっている。栗田氏（@hikarine3）が公開した実践ガイドから、要点を紹介する。 Sonar の調査によれば、開発者の 96% が AI 生成コードを完全には信頼していないにもかかわらず、実際に検証しているのは 48% に過ぎない。この「検証ギャップ」が AI 開発における最大のリスクだ。 1. 設定ファイルにルールを書く CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。 ルール 防げる事故 テスト結果を「○件中○件が正常」形式で報告 0 件検出の見落とし 影響範囲を確認 1 ファイル修正で他が壊れる ファイル削除・本番デプロイ・DB 操作は承認必須 取り返しのつかないミス 設定ファイルは 50 行以内 を推奨。IFScale の研究では、指示が長すぎると AI が先頭と末尾だけに従う傾向がある。詳細は別ファイルへの参照（ポインタ設計）で対応する。 2. リスクレベルで使い分ける すべてのプロジェクトに同じ品質基準を適用する必要はない。 レベル 対象 テスト深度 ラフ 静的サイト、ブログ 目視確認 標準 Web アプリ（ユーザーデータあり） 回帰テスト 厳密 金融・決済・認証・個人情報 境界値・異常系テスト 3. AI にテスト設計もさせる 従来のように 12 項目のチェックリストを人間が作るのではなく、「この変更の回帰テストをして。検出件数も報告して」と指示するだけで、AI がテストケースの設計・実行・報告まで行える。 4. AI のテストが「嘘」になる 10 パターン AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴: ...

Claude Code や Cursor、Devin といった AI コーディングエージェントの導入が進むなか、「品質をどう担保するか」が最大の課題になっている。栗田氏（@hikarine3）が公開した実践ガイドから、要点を紹介する。 Sonar の調査によれば、開発者の 96% が AI 生成コードを完全には信頼していないにもかかわらず、実際に検証しているのは 48% に過ぎない。この「検証ギャップ」が AI 開発における最大のリスクだ。 1. 設定ファイルにルールを書く CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。 ルール 防げる事故 テスト結果を「○件中○件が正常」形式で報告 0 件検出の見落とし 影響範囲を確認 1 ファイル修正で他が壊れる ファイル削除・本番デプロイ・DB 操作は承認必須 取り返しのつかないミス 設定ファイルは 50 行以内 を推奨。IFScale の研究では、指示が長すぎると AI が先頭と末尾だけに従う傾向がある。詳細は別ファイルへの参照（ポインタ設計）で対応する。 2. リスクレベルで使い分ける すべてのプロジェクトに同じ品質基準を適用する必要はない。 レベル 対象 テスト深度 ラフ 静的サイト、ブログ 目視確認 標準 Web アプリ（ユーザーデータあり） 回帰テスト 厳密 金融・決済・認証・個人情報 境界値・異常系テスト 3. AI にテスト設計もさせる 従来のように 12 項目のチェックリストを人間が作るのではなく、「この変更の回帰テストをして。検出件数も報告して」と指示するだけで、AI がテストケースの設計・実行・報告まで行える。 4. AI のテストが「嘘」になる 10 パターン AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴: ...

Anthropic が Claude Code Security を限定リサーチプレビューとして公開しました。AI がコードベース全体をスキャンして脆弱性を検出し、修正パッチまで提案してくれる機能です。 Claude Code Security とは 従来の静的分析ツール（SAST）はルールベースでパターンマッチングを行うため、ビジネスロジックの欠陥やアクセス制御の不備など、文脈依存の脆弱性を見落としがちでした。 Claude Code Security は、人間のセキュリティ研究者のようにコードを「理解」するアプローチを採用しています。 コンポーネント間の相互作用を把握する アプリケーション全体のデータフローを追跡する ルールベースツールでは検出困難な脆弱性を発見する 主な特徴 多段階検証プロセス 検出した脆弱性は多段階の検証プロセスにかけられ、誤検知（false positive）がフィルタリングされます。各脆弱性には重大度評価と信頼度スコアが付与されます。 ヒューマン・イン・ザ・ループ 修正パッチは自動適用されません。Claude Code Security は問題の特定と解決策の提案を行い、最終的な判断は開発者が行います。 実績 Anthropic のレッドチーム活動では、Claude Opus 4.6 を使用して本番環境のオープンソースプロジェクトから 500 以上の脆弱性 を発見しました。これらは数十年にわたり専門家のレビューを経ても検出されなかったバグです。 利用方法 プラン 利用可否 Enterprise 即時利用可能 Team 即時利用可能 オープンソースメンテナー 無料で迅速なアクセスを提供（申請制） 詳細は Anthropic 公式の Claude Code Security ページ を参照してください。 従来のツールとの違い 従来の SAST ツールは既知のパターンを検索する仕組みのため、新しいタイプの脆弱性や複雑なロジックの欠陥には対応しきれませんでした。Claude Code Security は LLM の推論能力を活用して、コードの意味を理解した上で脆弱性を検出するという点で、セキュリティスキャンの新しいアプローチといえます。 まとめ Claude Code Security は「脆弱性は多いが対応する人員が少ない」というセキュリティチームの課題に対し、AI による自動検出と修正提案で支援するツールです。現時点では限定リサーチプレビューですが、今後のセキュリティ開発ワークフローに大きな影響を与える可能性があります。

Claude Code でツール実行の許可を求められるたびに、セキュリティリスクをパーセンテージで表示させる CLAUDE.md の設定が話題になっています。「なんかやばそうだけど…まあいいか」で Yes を連打してしまう問題への対策です。 背景 Claude Code はファイル操作やシェルコマンドの実行時にユーザーの許可を求めますが、表示される内容だけでは何がどの程度危険なのか判断しにくいことがあります。特に初心者は、よく分からないまま Yes を連打してしまいがちです。 CLAUDE.md に追加する設定 プロジェクトのルートディレクトリにある CLAUDE.md に以下の内容を追加します: 1 2 3 4 5 6 7 8 ## ツール実行時の許可ルール - ツール実行（Bash、ファイル操作など）の許可を求めるときは、必ず日本語で説明・確認を行うこと - 許可を求める際、以下のセキュリティリスクをパーセンテージ(%)で提示すること - パスワードや秘密鍵が外に漏れる可能性 - 外部サーバーにデータが送られる可能性 - 悪意あるコードが勝手に動く可能性 - PCの設定が書き換わる可能性 表示イメージ この設定を入れると、ツール実行の確認時に以下のようなリスク評価が表示されるようになります: ・パスワードが外に漏れる可能性: 0% ・外部サーバーにデータが送られる可能性: 0% ・悪意あるコードが動く可能性: 5% ・PCの設定が書き換わる可能性: 80% これにより、各操作のリスクを具体的な数値で把握した上で、許可するかどうかを判断できるようになります。 ...