「開発者はおいしい脆弱性になった」 AIコーディング、採用、OSS、CI/CD“4つの包囲網”と生存戦略：それでも対策が進まない理由

AIコーディングやAIエージェント、OSS、CI/CD自動化、クラウドサービスなどの普及によって、開発者はこれまで以上に多くの権限や認証情報を扱う存在になりました。その結果、開発者自身が最も効率の良い「侵入口」として攻撃者に狙われ始めています。

[雨輝ITラボ（リーフレイン）, 編集：平田修，＠IT]

　近年、サイバー攻撃の標的はサーバやネットワーク機器だけでなく、開発基盤やソフトウェア開発者へと拡大しています。

　背景にあるのは、AIコーディングツールやAIエージェント、オープンソースソフトウェア（OSS）、CI/CD（継続的インテグレーション／継続的デリバリー）自動化、クラウドサービスなどの普及です。開発者の中には、開発基盤や開発環境だけでなく、本番環境や取引先、クラウドサービスなどにある重要資産にアクセスできる権限を付与されている方もいるのが現状です。

　攻撃者は、開発者1人を侵害できれば、広範囲のシステムやサプライチェーンへの到達が可能になります。開発者は今、「おいしい脆弱（ぜいじゃく）性」になったと言える状況です。

　本記事では、AIコーディング、採用活動、人気OSS、CI/CD自動化という4つの観点から、開発基盤や開発者を狙う攻撃の現状と対策を整理します。

開発者はなぜ「おいしい脆弱性」になったのか

　近年の開発者は、ソースコードだけでなく、「GitHub」「GitLab」「Bitbucket」といったリポジトリサービス、CI/CDパイプライン、API、シークレット（APIキー、パスワード、秘密鍵）、OSS、データなど、多数の重要資産にアクセスしています。

　Microsoftは、攻撃者が狙う情報資産として、APIトークンやクラウド認証情報、署名鍵、暗号資産ウォレット、パスワード管理ツールのデータ（アーティファクト）などを挙げています（参考）。

　近年は「開発者をだませば広範囲に侵入できる」という発想に基づく攻撃が増えています。狙われているのは、単なるソフトウェアの脆弱（ぜいじゃく）性だけではありません。開発者の「権限」「信頼」「承認」が侵入経路として悪用されています。

AIコーディングの普及で「脆弱なコードの量産」が始まった

　AIコーディングツールは、開発速度を大きく向上させる一方で、新たなセキュリティ問題も生み出しています。問題になっているのは、AIが脆弱なコードを生成することだけではありません。大量生成されたコードを、開発者が十分レビューし切れなくなっている点にもあります。

現状：AIはコードを書くが、脆弱性も生成する

　自然言語でコーディングエージェントに指示し、アプリケーションの構築を一任する「バイブコーディング」（Vibe Coding）によって、コード生成速度は大幅に向上しました。一方で、生成コードの脆弱性も問題視されています。

　サイバーセキュリティ企業Tenzaiが「5大コーディングエージェント」として「Cursor」「Claude Code」「OpenAI Codex」「Replit」「Devin」を対象に、脆弱性に関するテストを行ったところ、どのコーディングエージェントが構築したコードにも脆弱性が含まれていることが判明したということです。

• 参考記事：5大コーディングエージェントの比較で分かった「バイブコーディング」の落とし穴：共通する弱点と3つの教訓　Tenzai分析

各エージェントが構築したアプリケーションに含まれていた脆弱性の数（提供：Tenzai）

　構築された計15のアプリケーションをTenzaiが分析した結果、共通して見られた脆弱性として、以下の3点が挙げられています。

• 認可の不備
  複雑な認可ロジックの下では、プロンプトで明確かつ詳細な指示を与えても、適切な認可が行われない場合がある
• ビジネスロジックの脆弱性
  人間の「常識」を持たないために明示的な指示に依存する傾向があり、詳細な仕様がない場合、重要な細部を見落とす恐れがある
• SSRF（サーバサイドリクエストフォージェリ）
  正当なURL取得と悪意あるURL取得とを区別する普遍的なルールは存在せず、コンテキスト（文脈）に大きく依存するため、汎用（はんよう）的な解決策がない状況でセキュリティアプローチをコーディングエージェントの裁量に委ねると、失敗する傾向が高い

　これらに加えてAI生成コードの脆弱性として特に問題となっているのが、架空のパッケージ名が生成される「パッケージハルシネーション」です。攻撃者は、同一名の外部パッケージを用意しておくことで、開発者がAI作成のインストール用コマンドを不用意に実行した際に多数のソフトウェアを一気に侵害できてしまいます（参考）。

対策：AI生成コードを「信用し過ぎない」仕組み

　上記のような脆弱性に対処するために、Tenzaiは、AI生成コードを安全に扱う上での教訓として、次の3つを挙げています。

• セキュリティ対策の「明示的な指示」
  コーディングエージェントに重要なセキュリティ対策を実装させるには、ツール任せにせず、開発者がプロンプトなどで明示的に指示を与える必要がある
• コンテキストに基づいた脆弱性スキャンを組み込む
  ビジネスロジックのワークフローや認可ルールなど、安全と危険の定義が明確でない領域では、AIは容易に判断ミスを犯すという前提に立つ
• 能力向上に頼らない「テスト」の徹底
  モデルのコーディング能力が向上しても、脆弱性は根強く残るため、徹底したテストを行う

　また、先述した脆弱性を含め、品質の低いコードを生成させない仕組みを構築するために「ハーネスエンジニアリング」が注目されています。

人間がボトルネックとなる「承認疲弊」

　問題は、AIが脆弱なコードを生成することだけではありません。AIによってコード生成量そのものが激増し、人間によるレビューが追い付かなくなっている点も課題です（参考）。

　最近は、AIコーディングツール提供側もレビュー機能を提供し始めています。しかし、自動レビューであっても、最終的に承認する責任は開発者にあります。その結果、ツールから次々と流れてくる承認依頼に疲弊し、「十分確認しないまま承認する」ケースが増える可能性があります。

　「脆弱な生成AIコード」だけが問題なのではなく、「レビューし切れない開発者」がボトルネックになりつつあることを認識しておかなければなりません。

「採用」のワナ：狙われる開発者の「特権」と情報資産

　攻撃者は現在、フィッシングメールだけでなく、採用活動を侵入経路として利用し始めています。特に、開発者は「侵害後のリターンが大きい標的」として狙われています。

現状：偽の採用面接で開発者をだます

　Microsoftは、「偽の採用面接」攻撃について警告しています。攻撃者が企業や採用担当者を装い、開発者への接触を企てるものです。接触後にGitHubなどに置かれた悪意あるnpmパッケージをクローンし、実行するよう指示されます。コードエディタ「Visual Studio Code」（以下、VS Code）のワークフローを悪用し、バックドアをダウンロード、展開させる手口も確認されています。

• 参考記事：その企業は本物？　VS Codeを悪用する「偽の採用面接」に注意　Microsoftが説く対策

　攻撃者の狙いは、単なる端末侵害ではありません。開発者の端末には、GitHubへの認証情報、APIキー、シークレット、本番インフラへのアクセス権などが保存されているケースがあります。そのため、開発者1人を侵害できれば、組織全体やサプライチェーンへの横展開が可能になります。

　こうしたnpmパッケージを通じた攻撃は、次に紹介するOSS汚染問題とも深く関係しています。

攻撃チェーンの全体像：初期アクセスからバックドア実行、データ収集、流出、後続ペイロードまで（提供：Microsoft）

対策：開発基盤および面接ワークフローの見直し

　Microsoftは、開発者個人の注意だけでなく、開発基盤全体を「攻撃される前提」で設計する必要があると指摘し、下記4つの対策を推奨しています。

• 開発および面接ワークフローの強化
  コーディングテストには非永続的なVM（仮想マシン）などの「隔離環境」を使用し、リポジトリが提供された場合は実行前に依存関係やスクリプトをレビューする。危険な兆候について、開発者向けのガイダンスを提供する
• アタックサーフェスの縮小
  エンドポイントの保護機能を最新に保ちつつ、スクリプト実行環境の制限や、リスクの高い通信やパイプ処理の遮断を徹底することで、攻撃の足掛かりを最小化する
• シークレットの保護と影響範囲の限定
  シークレットはボールト（Vault：保管庫）で一元管理し、短期間の認証情報を活用するとともに、主要な開発基盤への多要素認証適用とアクセス権限の厳格化を図ることで、漏えい時の被害を最小限に抑える
• 検出、調査、対応
  開発ツールを起点とした不審な実行チェーンやランタイムの挙動を監視し、異常検知時は迅速なデバイス隔離と認証情報の刷新、侵害経路の精査によって被害の拡大と永続化を防ぐ

　開発者は、採用面接の場でも相手が本物かどうかを疑う姿勢を持つことが重要です。攻撃者は、開発者の業務を把握し、その隙を狙っています。

人気OSSは「信頼される侵入経路」になった

　OSSは現代のソフトウェア開発に欠かせない存在ですが、OSSの「広く信頼されている」という性質自体が攻撃に悪用され始めています。特に、npmやPyPIといったパッケージ管理ツールや、VS Code、「Google Chrome」といった普及しているツールで「公式」とされている拡張機能などを汚染する傾向にあるのです。

現状：週7000万DLのOSSが汚染される

　2026年3月31日、npmレジストリに公開された人気ライブラリ「axios」の2つの新バージョンに、悪意ある依存関係が組み込まれていたことが明らかになりました。

　攻撃者が正規の配布元を乗っ取って機密情報を盗み出すコードを混入させたため、開発者が普段通りライブラリを更新、利用するだけで、ビルド環境の認証情報などが外部に流出してしまうというものでした。

• 参考記事：週7000万DLのライブラリが「トロイの木馬」に　開発者なのに気付けない4つの理由

　Microsoftは、axiosの汚染が開発者でも気付きにくい理由として、以下を挙げています。

• axios自体のコードは一切書き換えられていない
• 事前に「無害なバージョン」を公開して実績を作っていた
• ターゲットのOSに合わせて、最も検知されにくい実行形式や攻撃手法を自動で使い分ける
• インストール終了後、自身のローダファイルを削除

　現在の開発基盤では、多数のOSSが自動的に組み込まれています。そのため、1つのライブラリ汚染が広範囲へ連鎖する可能性があります。

対策：自動更新機能の無効や依存関係の確認、パッケージ公開の仕組みの見直し

　Microsoftは、こうしたOSS経路の攻撃を防ぐために、重要なnpmパッケージの自動更新機能を無効にすることや、自動化された依存関係管理ボットの制限、標準規格の「OIDC」（OpenID Connect）を用いた「Trusted Publishing」（信頼された発行元の検証によってシークレットなしでパッケージを公開する仕組み）の導入などを組み合わせた多層的な防御を推奨しています。

　また、ビルドプロセスやCI/CDパイプラインのログを定期的に確認し、不審なファイルがインストールされていないかどうかチェックする仕組みを構築することが求められるようになっています。

　一方で、そのCI/CDパイプライン自体が既に攻撃の標的になっているという現実もあります。

CI/CD自動化は「攻撃効率の最大化」を招いた

　CI/CD自動化は、本来、人為ミスを減らし、開発効率を高めるための仕組みです。しかし現在は、自動化されたCI/CDパイプラインそのものが、攻撃者にとって効率的な侵入、拡散の経路になりつつあります。

ソフトウェア開発ライフサイクルにおけるCI/CDによる自動化領域（提供：NTT）

現状：GitHub Actionsが狙われている

　GitHubは、CI/CDサービス「GitHub Actions」を起点とした攻撃増加について警告しています。この攻撃は、APIキーなどのシークレット情報の窃取を起点として、悪意のあるパッケージの公開や、窃取した認証情報を使っての攻撃を拡散させるという連鎖的な手法を取るものです。

• 参考記事：「もう開発者はシークレットを使うな」　GitHubが「今日できる」4つのセキュリティ対策を紹介

対策：コード分析ツール使用やトリガーの禁止、シークレットレスへの移行

　すぐにできる防御策として、コード分析ツール「CodeQL」の使用を最重要としつつ、以下の3つを挙げています。

• 「pull_request_target」トリガーの禁止
• サードパーティー製アクションを利用する際は、バージョン名ではなくフルレングスのコミットSHAでピン留めし、勝手なコード変更が反映されないようにする（このピン留めは開発者自身、または依存関係管理ツール「Dependabot」で行い、外部からのプルリクエスト（PR）による更新は不審なものとして扱う）
• 外部から提供されるユーザー入力を参照する際は、スクリプトインジェクションのリスクに注意する

　またGitHubは、Microsoftと同様、ワークフローにおけるシークレットの使用を止め、OIDCトークンによる認可方式やTrusted Publishingを導入することを強く推奨し、パッケージリポジトリへの導入を進めています。

それでも対策が進まない理由

　ツールベンダーが対策を推奨しているにもかかわらず、現場の実施率は高くありません。GitHubによる34万リポジトリ調査では、推奨されるセキュリティ対策の実施率がいまだに低いことを示すものでした。

• 参考記事：人のミスを減らす「自動化」が攻撃対象に　GitHub Actionsのセキュリティ対策が進まない3つの理由

　NTTとNTTドコモビジネス、早稲田大学が調査したのは、GitHub Actionsで推奨されている代表的な5つの対策についてです。

• 対策A：重要な設定ファイルの変更に対して指定された担当者による確認を必須とする「CODEOWNERS」の利用
• 対策B：スクリプトインジェクション対策
• 対策C：「OpenSSF Scorecard」（オープンソースのセキュリティリスクチェックツール）の利用
• 対策D：サードパーティー製アクションのバージョン固定
• 対策E：外部プログラムの安全な最新版への更新を支援するDependabotの利用

GitHub Actionsにおける推奨セキュリティ対策の実践状況（提供：NTT）

　スクリプトインジェクション対策こそ52.9％だったものの、OpenSSF Scorecardは0.6％にとどまり、専用のツールや機能を活用する対策が十分に活用されていない実態が明らかになりました。

　調査結果では、対策が進まない理由として、以下の3点を挙げています。

• 対策の存在が十分に認知されていない
• 運用の手間が増えるという負担感
• 「自身の開発には関係ない」という誤解

　特に最後の点は重要です。現在の攻撃者は、企業規模や知名度を見ているわけではありません。開発者が持つ権限や認証情報、CI/CD接続、OSS公開権限など、「侵入後にどこまで到達できるか」を重視しています。つまり、「自分は狙われない、関係ない」という認識そのものが、重大の脆弱性になりつつあるのです。

まとめ：開発者が「おいしい脆弱性」にならないために

　攻撃者が開発者を狙う理由は、改めて整理しておく価値があります。

　Microsoftが指摘するように、開発者の端末や開発基盤には極めて価値の高い情報資産が集中しています。「開発者1人を侵害できれば、組織全体やサプライチェーン全体に横展開できる」。攻撃者はそう考えているのです。

　ソフトウェア開発が企業のビジネスに深く関わる現在、開発者の負担が激増している上に負荷を減らすツールとして有力視されたAIコーディング自体にも課題が露呈しています。理解負債や認知負債など負担が増す一方な現状は、開発者の判断力を低下させ、サイバー攻撃が成功してしまう一因と言えるでしょう。

　企業・組織には、AIを安全に問題なく活用できる上に、侵害されにくい、または侵害されても迅速に対応できる開発基盤や権限制御の仕組みを構築、提供し、開発者の負荷を減らすことが求められます。加えて、開発者も「自分は狙われている」と認識し、強い警戒心を持ち続ける必要があるのではないでしょうか。こうした仕組みと意識の変革ができるかどうか。今後のセキュリティ対策だけでなく、ソフトウェア開発自体の在り方を左右する重大な問題として注目されています。