セキュリティ

本記事では、Python の AST を活用して AI による脆弱性検出を効率化する手法を紹介します。Qiita の @PythonHaru 氏が公開した記事「コードを1行も読ませずに、AIに脆弱性を100%特定させる方法（理論編）」は 530 いいね・471 ブックマークを獲得し、X（旧 Twitter）でも急速に拡散しました。 この記事のポイント AI（LLM）に生のソースコードを読ませるのは、効率の悪い「情報の暴力」（情報量が多すぎて AI が処理しきれない状態） Python の ast モジュールで生成した Deep Structure Map（コードの骨格図）こそ、AI の推論能力を最大化する データの流入から危険地帯への到達をグラフ理論で定義すれば、理論上 脆弱性は100%特定可能 AIコードレビューの限界 GitHub Copilot や ChatGPT にコードをそのまま貼り付けて「脆弱性ある？」と質問する手法は今や一般的ですが、大規模プロジェクトでは2つの致命的な欠陥が生じます。 コンテキストの霧（AI が変数の出自を追跡できなくなる状態）— 数千行のコードを前にした AI は「どの変数がどこから来たか」を見失い、ハルシネーションを起こしやすくなる トークンの浪費 — コードの「書き方」というノイズに注目してしまい、肝心の「ロジックの破綻」に辿り着く前にリソースを使い果たす そこで著者は、AI にコードを1行も読ませるのをやめました。代わりに渡したのが、自作の解析コードが抽出した「コードの設計図（Deep Structure Map）」です。 Deep Structure Map：AI に「骨格」だけを渡す ソースコードは人間が読むための「肉体」ですが、AI が論理推論に必要なのは純粋な「神経系（ロジック）」です。Python の ast モジュールを使い、コードを以下の構造データへ変換します。 DeepAnalyzer クラス（ast.NodeVisitor を継承） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 import ast class DeepAnalyzer(ast.NodeVisitor): def __init__(self): self.classes = [] self.functions = [] self.variables = [] self.scope_stack = [] self.call_graph = {} def visit_ClassDef(self, node): self.classes.append(node.name) self.generic_visit(node) def visit_Call(self, node): # 関数呼び出しをコールグラフとして記録 self.generic_visit(node) ast.NodeVisitor を継承した DeepAnalyzer がコード全体を走査し、クラス・関数・変数のスコープ情報とコールグラフを収集します。AI にはこの「関係性の結晶」だけをインプットします。 ...

クラウドファンディングプラットフォーム CAMPFIRE が、GitHub アカウントへの不正アクセスを起点に最大 22 万 5,846 件の個人情報が漏洩した可能性があると発表しました（2026 年 4 月 24 日）。単なる「パスワード流出」ではなく、CD パイプラインを悪用してインフラを乗っ取るという、現代の DevOps が抱えるリスクを象徴するインシデントです。本記事ではエンジニア視点で攻撃経路を分析し、再発防止策を考えます。 インシデントの経緯 日時 出来事 2026-04-02 22:50 GitHub アカウントへの不正アクセスを検知。一部ソースコードが閲覧された可能性（初報） 2026-04-14 第二報：社員・取引先情報の閲覧可能状態を確認 2026-04-22 第三報：顧客情報管理システムへの不正アクセス痕跡を確認 2026-04-24 個人情報漏洩の可能性を正式発表（最大 22 万 5,846 件） 漏洩した可能性がある情報は以下のとおりです: プロジェクト実行者 12 万 929 件：氏名・住所・電話番号・口座情報など（2021 年 2 月以降） 支援者 13 万 155 件：氏名・住所・口座情報など（PayPal 決済、後払い、口座送金返金ユーザー） うち 8 万 2,465 件が口座情報を含む クレジットカード情報は対象外（CAMPFIRE 公式発表） 推定される攻撃経路 エンジニア向け技術解説として、@poly_soft（勝又健太）氏が X（旧 Twitter）で以下の攻撃チェーンを推察しています。この分析は公式発表を補完する形で、攻撃者が具体的にどう動いたかを示しています（以下はあくまで推定です）。 Step 1: CD 権限を持つ GitHub アカウントの侵害（推定） 攻撃者が最初に侵害したのは、単独で CD（継続的デプロイ）をトリガーできる権限を持つ GitHub アカウントであったと推定されます。 問題の設定として考えられるのは: ...

.env よ、安らかに眠れ——。 AI 時代の開発現場では、シークレット（API キー・データベースパスワード・証明書など）の扱い方が大きな課題になっています。従来は .env ファイルに書いておけばなんとかなっていました。しかしチーム規模が拡大したり、AI エージェントが複数のサービスを横断して動くようになると、.env ベースの管理はほころびを見せてきます。 Infisical は、そんな .env の時代を終わらせるべく登場したオープンソースのシークレット管理プラットフォームです。 .env の何が問題なのか .env ファイルによるシークレット管理には以下のような問題があります。 ディスクに残る: 誤って git add .env してしまうリスクが常に存在する 同期が難しい: 複数人・複数環境での値の一元管理が困難 ローテーションが手動: シークレットを更新するたびに全メンバーへの周知が必要 監査ログがない: いつ誰がどの値を変更したか追跡できない AI エージェントとの相性が悪い: エージェントが環境変数ファイルを読み書きすると漏洩リスクが増大する Infisical とは Infisical は、シークレット・証明書・特権アクセスを一元管理するオープンソースプラットフォームです。2026年4月時点で GitHub 26,000 スター超を獲得しており、Vault の OSS 代替として注目されています。 最大の特徴は、シークレットをランタイム時に取得する設計にあります。.env ファイルのようにディスクに値を保存しないため、ファイルベースの漏洩リスクを根本から排除します。 主な機能 シークレット管理 プロジェクト・環境（dev / staging / prod）ごとのシークレット管理 シークレットのバージョン履歴と自動ローテーション 変更の監査ログ シークレット参照（他のシークレットの値を参照する変数展開） 証明書管理（PKI） プライベート CA の構築と証明書の発行 ACME プロトコル対応で Let’s Encrypt 互換のワークフロー 証明書の有効期限監視と自動更新 統合機能 CLI: あらゆる言語・フレームワークのコマンドをシークレット付きで実行 SDK: Node.js、Python、Go、Java など主要言語のネイティブ SDK インフラ統合: Kubernetes、GitHub Actions、AWS、GCP、Azure など 基本的な使い方 インストール 1 2 3 4 5 # macOS (Homebrew) brew install infisical/get-cli/infisical # npm npm install -g @infisical/cli ログインとプロジェクト初期化 1 2 3 4 5 # Infisical にログイン infisical login # プロジェクトに紐付け infisical init シークレットを注入してコマンドを実行 1 2 3 4 5 # .env の代わりに Infisical からシークレットを取得してアプリを起動 infisical run -- node app.js # 環境を指定 infisical run --env=staging -- python manage.py runserver SDK から直接取得（Node.js の例） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 import { InfisicalSDK } from "@infisical/sdk"; const client = new InfisicalSDK(); await client.auth().universalAuth.login({ clientId: process.env.INFISICAL_CLIENT_ID, clientSecret: process.env.INFISICAL_CLIENT_SECRET, }); const secret = await client.secrets().getSecret({ secretName: "DATABASE_URL", projectId: "my-project-id", environment: "production", }); AI 時代のシークレット管理 AI エージェントや MCP サーバーが普及した今、シークレット管理の重要性はさらに高まっています。 ...

生成 AI ツールの急速な普及により、IT 部門の承認を経ずに従業員が独自に AI を活用する「シャドー AI」が企業セキュリティの新たな盲点として注目されている。本記事では、シャドー AI が引き起こすリスクと、その対策について整理する。 シャドー AI とは 「シャドー IT」は以前からある概念だが、生成 AI の登場でその問題は一段と深刻になった。**シャドー AI（Shadow AI）**とは、IT 部門や情報セキュリティ部門の審査・承認を受けずに、従業員が業務で使用する AI ツールやサービスのことを指す。 ChatGPT・Gemini・Claude・Copilot などの生成 AI サービスは、個人アカウントで無料または低コストで利用できる。利便性が高いため、IT 部門の手続きを待たずに「とりあえず使ってみる」ケースが後を絶たない。 調査によれば、従業員の約 40% が業務で非承認の生成 AI ツールを使用しているとされており、多くの企業でシャドー AI が組織的な管理の外に広がっている。 シャドー AI が生む具体的なリスク 1. 機密情報・個人情報の漏洩 最も深刻なリスクは、社内の機密情報が AI サービス側に送信されることによるデータ漏洩だ。 実例: Samsung の機密漏洩事件（2023年） Samsung の半導体部門の社員が、ChatGPT に機密のソースコードを貼り付けてデバッグを依頼したり、社内会議の音声を要約させたりした結果、社内機密が外部サーバーに送信されたインシデントが発生した。この件が発覚した後、Samsung は社内での ChatGPT 利用を一時禁止している。 社員が AI に入力する情報として問題になりやすいのは: ソースコード・設計仕様書 顧客情報・個人情報（氏名、メールアドレス、契約情報など） 財務データ・未公開の経営情報 社内メール・会議議事録 多くの商用 AI サービスは、無料プランやデフォルト設定では入力データをモデルの学習・改善に利用する場合がある。エンタープライズ契約や特定のオプト設定が必要だが、シャドー利用ではそのような設定は行われていない。 2. コンプライアンス・規制違反 個人情報保護法（GDPR、日本の個人情報保護法）や業界固有の規制（医療分野の HIPAA、金融分野の各種規制）では、個人情報の取り扱いに厳しい要件がある。IT 部門の審査を通じて利用規約・データ処理契約を確認せずに AI ツールを使用すると、意図せず法令違反を犯す可能性がある。 3. AI の出力に対する品質・責任管理の欠如 生成 AI はハルシネーション（事実と異なる情報の生成）を起こす。IT 部門・品質管理部門が把握していないツールを使って作成された成果物がそのままリリースや提案書に使われると、品質問題に発展しうる。 ...

海外で発生した実際のインシデント「An AI Vibe Coding Horror Story」を元に、AI に開発を丸投げするリスクを解説します。技術的リテラシーのないまま本番環境を構築した結果、患者データが完全露出するという深刻な事態が起きました。 何が起きたのか 専門知識のない医療従事者が、AI を使って自分専用の患者管理システムをゼロから自作しました。業界で実績のある既存ソフトウェアを使わず、「自分のバイブ（感覚）」で開発を進めたのです。 元記事: An AI Vibe Coding Horror Story システムの問題点 AI が生成したこのアプリには、致命的なセキュリティ上の欠陥が多数ありました。 アーキテクチャの問題 単一 HTML ファイル構成: すべてのプログラムが 1 つの HTML ファイルに詰め込まれた簡素な構造 クライアントサイド認証: パスワードなどの認証機能がブラウザ側の処理だけで実装されていた アクセス制御なし: データベースへのアクセス制限が全くなく、誰でも中身を閲覧できる状態 データ管理の問題 蓄積されていた大量の患者データをそのまま自作アプリに移行 全データが暗号化されず、無防備な状態で公開サーバーに配置 適切なセキュリティ設定をしないままインターネット上に公開 プライバシーの問題 診察中の会話を録音し、外部の AI サービスに送信して要約させる機能を実装 患者の個人情報や音声データが、事前の同意なく海外のサーバーへ転送 被害の深刻さ わずか 30 分の調査 で、全ての患者データに対する読み書き権限が奪取されました。 患者の個人情報が完全に露出 音声データも含めた機密情報が外部に流出 現地の個人情報保護法や医療従事者の守秘義務に違反している可能性が極めて高い状況 問題の本質 不備を指摘された本人は、AI が生成した定型文で回答し、問題の深刻さを理解していませんでした。 これはバイブコーディングの本質的なリスクを示しています： AI はコードを生成できるが、セキュリティ要件の判断はできない 開発者が仕組みを理解していないと、問題が起きても原因を特定できない 「動いているように見える」と「安全に動いている」は全く別の話 開発の民主化とリテラシーのトレードオフ AI によって開発の民主化が進み、非エンジニアでもアプリケーションを作れる時代になりました。一方で、最低限の技術的リテラシーがないと重大な事故を招くリスクも同時に高まっています。 特に以下の領域では、専門知識なしの AI 開発は高リスクです： 領域 リスク 医療・健康データ 個人情報保護法・医療法違反 金融データ 金融規制・顧客情報保護 個人認証システム なりすまし・不正アクセス 本番環境のインフラ サービス停止・データ消失 まとめ バイブコーディングは強力なツールですが、「AI に生成させたコードを理解できる人間が監督する」 という原則なしには危険です。 ...

JWT 認証ライブラリ fast-jwt に重大な脆弱性が発見された。公開鍵の先頭に空白文字や改行があるだけで認証が突破される可能性があり、影響はバージョン 6.1.0 以下に及ぶ。 fast-jwt とは fast-jwt は Node.js 向けの高速な JWT（JSON Web Token）の署名・検証ライブラリ。パフォーマンスを重視した実装で広く利用されているが、今回その内部の文字列処理と正規表現の甘さが致命的な脆弱性につながった。 CVE-2026-34950: 空白文字による認証バイパス 問題の概要 CVSS スコア 9.1（Critical） の深刻な脆弱性。公開鍵の検証に使われている正規表現が、文字列の先頭を厳密に検証していないという欠陥に起因する。 攻撃メカニズム 公開鍵の先頭にスペースや改行文字（\n）が含まれると、正規表現による公開鍵の検証が失敗する。その結果、公開鍵が HMAC 用の秘密鍵として誤って扱われ、攻撃者は任意のトークンを署名できてしまう。 1 2 3 4 5 6 7 8 9 // 通常の公開鍵（検証成功） -----BEGIN PUBLIC KEY----- ... -----END PUBLIC KEY----- // 先頭に空白が入った場合（検証失敗 → HMAC 鍵として扱われる） -----BEGIN PUBLIC KEY----- ... -----END PUBLIC KEY----- これは過去に修正されたはずの CVE-2023-48223（アルゴリズム混同攻撃）と同様の攻撃を再び可能にする。前回の修正が不完全だったことが根本原因だ。 ...

Check Point Research が、ChatGPT のコード実行ランタイム（Python Data Analysis 環境）に隠れた外部通信チャネルが存在することを発見しました。この脆弱性を悪用すると、ユーザーの会話内容やアップロードしたファイルが外部サーバーに漏洩する可能性がありました。OpenAI は 2026年2月20日に修正を完了しています。 脆弱性の概要 ChatGPT の Data Analysis 機能（旧 Code Interpreter）は、Python コードを実行するためのサンドボックス環境を提供しています。この環境は外部への直接的なネットワークアクセスを遮断するよう設計されていましたが、DNS 名前解決の機能は通常のオペレーションとして残されていました。 攻撃者はこの DNS 解決機能を悪用し、DNS トンネリングと呼ばれる手法でデータを外部に送信することが可能でした。 DNS トンネリングの仕組み DNS トンネリングとは、DNS クエリのサブドメイン部分にデータをエンコードして埋め込み、DNS の名前解決プロセスを通じてデータを送信する手法です。 1 2 3 4 5 # 通常の DNS クエリ example.com → IPアドレスを返す # DNS トンネリング <エンコードされたデータ>.attacker-controlled.com → 攻撃者のDNSサーバーがデータを受信 ChatGPT のコード実行環境では、DNS 解決が正常なオペレーションの一部として許可されていたため、この通信は外部へのデータ転送として認識されず、ユーザーへの警告も表示されませんでした。 攻撃シナリオ 悪意のあるプロンプトインジェクション 単一のプロンプトで隠れた漏洩チャネルを起動できます。「生産性向上ハック」や「プレミアム機能のアンロック」を謳う一見無害なプロンプトとして流通する可能性がありました。 ...

2026年3月31日、Anthropic の Claude Code でソースコード漏洩インシデントが発生しました。npm レジストリに含まれたソースマップファイル（.map）を通じて、ソースコード全体が公開された形です。 何が起きたのか セキュリティ研究者の Chaofan Shou 氏が、@anthropic-ai/claude-code パッケージのバージョン 2.1.88 に、本来デバッグ用の 59.8MB のソースマップファイルが含まれていることを発見しました。このソースマップには、Anthropic の Cloudflare R2 ストレージバケット上の zip アーカイブへの参照が含まれていました。そこから完全な TypeScript ソースコードを復元できる状態だったのです。 数時間以内に、約 512,000 行・約 1,900 ファイルの TypeScript コードベースが GitHub にミラーされ、多数の開発者によって分析が行われました。 ソースマップとは ソースマップ（.map ファイル）は、ミニファイ（コードの圧縮・難読化）やバンドルされた JavaScript を元のソースコードにマッピングするためのファイルです。開発時のデバッグを容易にする目的で生成されますが、プロダクションビルドに含めると、元のソースコード全体が読み取り可能な形で公開されてしまいます。 なぜ漏洩したのか Claude Code は Bun をランタイムおよびバンドラーとして使用しています。ビルド設定でソースマップ生成が有効化されていました。しかし、.npmignore や package.json の files フィールドで .map ファイルを除外する設定が漏れていたことが原因です。公開された npm パッケージには cli.js.map が含まれ、その sourcesContent フィールドにバンドル対象の全 .ts / .tsx ファイルがそのまま格納されていました。 ソフトウェアエンジニアの Gabriel Anhaia 氏は次のように指摘しています。「.npmignore や package.json の files フィールドの設定ミス一つで、すべてが公開されてしまう」 ...

Linux を標的とするランサムウェアが新たな段階に入った。イラン系とされる攻撃グループ Pay2Key が Linux 向けに進化し、「Pay2Key.I2P」と呼ばれる新たな亜種を展開している。Morphisec の技術分析をもとに、攻撃の手口、防御機構の無効化手法、そして具体的な対策を整理する。 Pay2Key とは Pay2Key はイラン系の攻撃グループに帰属するランサムウェアで、Fox Kitten APT グループとの関連が指摘されている。従来は Windows を主な標的としていたが、企業のサーバー基盤を直撃する Linux 版が登場し、防御の前提が揺らぎ始めている。 2026年2月には、米国の医療機関で Pay2Key による侵害事例が Beazley Security Incident Response によって対応されている。 Pay2Key.I2P の技術的特徴 設定駆動型の設計 Pay2Key.I2P は単なる Windows 版の移植ではない。JSON 設定ファイルによって動作を制御する設定駆動型の攻撃ツールとして設計されている。ターゲットとするファイルシステムの範囲や暗号化の挙動を柔軟に変更できる。 デュアルアーキテクチャ対応 x64 と ARM64 の両方に対応し、従来の x86 サーバーだけでなく、ARM ベースのクラウドインスタンス（AWS Graviton など）や仮想化ホストも一括で狙うことができる。 root 権限の必須化 侵入後は root 権限を必須とし、取得できない場合は即終了する設計となっている。これはノイズを最小限に抑え、検知を回避するための戦略と考えられる。 防御機構の無効化 Pay2Key.I2P の最も危険な特徴は、Linux の防御機構を体系的に無効化する点にある。 SELinux / AppArmor の無効化 実行時に SELinux や AppArmor を無効化し、強制アクセス制御（MAC）による保護を解除する。これにより、通常であれば制限されるファイルアクセスやプロセス操作が可能になる。 systemd サービスの停止 データベースやバックアップなどの重要なサービスを停止し、ファイルロックを解除して暗号化対象のファイルにアクセスできる状態を作り出す。 cron による永続化 cron エントリを登録してリブート後も自動的に再実行されるようにし、単純な再起動では排除できない永続性を確保する。 暗号化の手法 ChaCha20 による高速暗号化 暗号化アルゴリズムには ChaCha20 を採用している。AES と比較してソフトウェア実装での処理速度に優れる。AES-NI などの専用ハードウェアを持たない環境でも高速に動作する。 ...

サプライチェーン攻撃とは、ソフトウェアの開発・配布の過程（サプライチェーン）に侵入し、正規のパッケージやツールに悪意あるコードを混入させる攻撃手法です。開発者が信頼して利用しているライブラリが攻撃の入口になるため、通常のセキュリティ対策では気づきにくいのが特徴です。 2026年3月27日、PyPIで月間74万ダウンロードを誇る通信プラットフォーム Telnyx の公式 Python SDK（telnyx）が、まさにこのサプライチェーン攻撃によって汚染されました。攻撃者グループ TeamPCP が悪意あるバージョン 4.87.1 および 4.87.2 を公開しました。これらは import するだけでマルウェアが実行される極めて危険なものです。 何が起きたのか タイムライン 2026年3月27日 03:51 UTC — 悪意あるバージョン 4.87.1 と 4.87.2 が PyPI に公開 同日 10:13 UTC — PyPI によって当該バージョンが隔離（quarantine） 約6時間にわたり、pip install telnyx を実行したユーザーは悪意あるバージョンをインストールする可能性がありました。 攻撃の仕組み 悪意あるコードは telnyx/_client.py に注入されていました。パッケージを import するだけで自動実行される仕組みです。攻撃は以下の手順で進行します: 初期実行: import telnyx だけでマルウェアコードが発動 ペイロード取得: リモートサーバーから WAV 音声ファイルをダウンロード ステガノグラフィ（データを別のファイルに隠す技術）: WAV ファイルのオーディオフレーム内に実行ファイルが埋め込まれている 環境別の挙動: Windows: 永続的な実行ファイルをドロップ Linux/macOS: クレデンシャル（認証情報）を窃取 WAV ファイル内に実行ファイルを隠すステガノグラフィ手法は、通常のセキュリティスキャンやウイルス対策ソフトでは検出が困難です。音声ファイルという無害に見えるファイル形式を悪用している点が巧妙です。 TeamPCP のサプライチェーン攻撃キャンペーン 今回の telnyx 攻撃は単独の事件ではありません。TeamPCP は2026年3月20日以降、以下のような連鎖的なサプライチェーン攻撃を展開しています: 対象 種別 影響 Trivy セキュリティスキャナー CI/CD クレデンシャルの窃取 Checkmarx (KICS) セキュリティツール 同上 LiteLLM AI/LLM プロキシ 認証情報の窃取 telnyx 通信 API SDK クレデンシャル窃取 + マルウェアドロップ 攻撃パターンは一貫しています: ...