AIプログラミング時代に潜む罠 ソフトウェアサプライチェーンの現在と身を守るための新常識（2/2 ページ）

[桂田祥吾，セキュリティエンジニア]

「人の目で確認する」という最大のリスク

　これだけ複雑で恐ろしい攻撃の連鎖を知ったとき、多くの人はこう考えます。「なるほど。だったら、AIやツールが書いたコードや設定を、最後に人間（セキュリティの専門人材）がしっかり目視でチェック（レビュー）すれば防げるはずだ」と。

　しかし、ここで断言しなければなりません。AI時代のセキュリティにおいて「人間の目」はもはや信用できません。それどころか、「人間の目に頼る運用」を続けること自体が、システムにとって最大のリスクになります。

　理由は大きく3つあります。

• スピードの圧倒的な差： AIが数秒で生成した数千行のコードを、人間がいちいち目視でチェックしていたら開発スピードは死にます。結果として「AIが出したものだから」と、ろくに確認せず承認ボタンを押す 「形骸化したレビュー（思考停止の承認）」 が横行し、攻撃者に素通りのお墨付きを与えてしまいます。
• 見えない「構造的欠陥」： コード1行ずつは正しく見えても、Moltbookのようにクラウド側の権限設定が抜けていたり、AWS CodeBreachのようにプラットフォーム側に問題があったりする場合、コードだけを読んでいる人間の目には「100点満点の安全なコード」にしか見えません。
• ヒューマンエラーの限界： 人間は疲労や思い込みで必ずミスをします。AIが大量生産するコードの海から、巧妙に隠されたたった1行の脆弱性を見つけ出すのは、砂漠で針を探すようなものです。

これからの新常識　自動化された「ガードレール」で守る

　では、私たちはどうすればいいのでしょうか。進化の速いこの業界において、日々常識が覆されています。現時点で一つの答えがあるわけではありませんし、正直、いくら優秀なエンジニアが設計したとしても100%安全であると言いきれない世界になってしまいました。

　大きな方向性としては「人間が目で探して頑張る」のをやめ、「機械（AIやシステム）に機械（AI）を監視させる」 という、自動化されたガードレール（防護柵）を敷くことです。現時点で有効な方針と対策についてご紹介します。

方針1　「調理場（環境）」を隔離し、統制する

　まずは、開発者が作業する環境全体に安全なルールを敷きます。

• 集中管理レジストリの運用： 開発者やAIがネットから自由に野良の部品を拾ってくるのを禁止し、組織が安全を確認した「公式の倉庫」からしか部品をダウンロードできない仕組みを構築します。セキュアなライブラリプロキシや、安全が確認されたセキュアOSイメージを利用することも効果的です。
• 影響範囲の可視化・把握の仕組み： レストランで「アレルギー成分表」や「産地証明書」が重要なように、ソフトウェアにも 「SBOM（Software Bill of Materials：ソフトウェア部品表）」 と呼ばれる部品表を作る動きが世界中で義務化されつつあります。万が一侵害が発生しても、SBOMやCMDB（構成管理データベース）を確認することで、すぐに対処できる準備をしておくことが重要です。CI（Continuous Integration）ワークフローやジョブを可視化しておくことも効果的です。
• バージョン管理システムのハードニング：これまで、クラウドなどの実行環境については、CNAPP（Cloud Native Application Protection Platform）などでセキュアな状態を維持してきた企業も多いと思います。調理場としてのGitHubなどのコードリポジトリ、バージョン管理システムの設定についてセキュリティを強化していく必要があります。セキュリティベストプラクティスに則った設定になっているかきちんと見直しましょう。
• 隔離された環境（リモート開発環境）の利用： インフォスティーラーの被害を防ぐため、個人の端末にコードやAPIキーを直接保存して開発するのをやめる企業が増えています。常にクリーンな状態が保たれる「クラウド上の使い捨て開発環境」を使うことで、万が一開発者がウイルスを踏んでもシステムの中枢まで被害が及ばないように隔離します。

方針2　「鍵（権限）」を使い捨てにし、最小化する

　次に、システムを操作するための「権限」の考え方を変えます。「誰でも何でもできるマスターキー」を廃止することが重要です。

• 権限の最小化（最小権限の原則）： AWSやGitHub Actionsなどの自動化ボットに「何でもできる権限」を与えないこと。万が一ツールが乗っ取られても、クラウド環境全体が破壊されないよう、権限を極限まで絞り込みます。過剰権限を検知する仕組みでガードレールを引くのも良いでしょう。
• 動的なシークレット管理： 外部サービスとの連携のため、多くのアプリケーションがAPIキーやトークンなどのシークレットを使います。静的で長寿命なトークンは使わずに、シークレットマネジャーやOIDC（OpenID Connect）連携の仕組みなどを活用し、短い期間でローテーション（使い捨て）できる仕組みを導入しておくことが重要です。

方針3　「部品の調達」と「検査」を機械的にロックする

　最後に、コードや部品がシステムに組み込まれる瞬間のチェックを自動化します。

　最近のサプライチェーン攻撃事例により、「公開されたばかりの新しいパッケージや最新アップデートには、まだ誰も気づいていない罠が潜んでいる可能性がある」という事実が突きつけられました。これにより、これまでの「できるだけ早く最新のバージョンに上げるべし」という常識が変わって来ました。

• バージョンのピン留め（固定）とロック： 安全が確認された特定のバージョンを「ロックファイル」でガッチリと固定し、AIが勝手に未知の部品を紛れ込ませる余地を排除します。
• 「新しいパッケージ」はすぐ使わず様子を見る（依存関係のクールダウン）： 公開から一定期間（数日〜数週間）はあえて使わず、他の人の報告を待つ「クールダウン（寝かせ）期間」を設けるのが安全です。
• 勝手に動く「裏コマンド」を制限する（ライフサイクルフックの制限）： 一部のパッケージには、インストールした瞬間に自動でプログラムを実行する仕組み（ライフサイクルフック）があります。攻撃者はこれを悪用し、インストールと同時にウイルスを起動させます。この「勝手に動く機能」をオフにしたり、制限したりする設定が必要です。

　加えて、ライブラリや生成したコードの脆弱性スキャン、シークレットの紛れ込みなどを自動化する仕組みを導入することも重要です。

• システムによるAIの監視（多層的スキャン）： 開発用AIが書いたコードは、SCA（ソフトウェア構成分析）やSAST（静的解析）、シークレットスキャナーなど、複数の異なるロジックを持つセキュリティツールに自動で交差チェックさせます。セキュリティツール自体もAIを活用したスキャン機能の実装・提供が進んでいます。より発展することで、AIの書いたコードをAIで検査するようになります。
• ポリシーによる自動ブロック（Policy-as-Code）： 「APIキーがコード内に含まれている」「重大な脆弱性リストに載っているパッケージのバージョンがある」といった場合、人間がどれだけOKと言ってもシステムが強制的にアップロードを拒絶する仕組みを導入します。

　幾つか具体的な対策例を概要レベルで紹介しましたが、攻撃手法は時代とともに進化し続けます。今後も、こうした進化をウオッチし続ける必要があります。

人間の役割はコーダーからアーキテクトへ

　本記事では、数々の恐ろしい脅威や事件を紹介しました。もしかすると、「そんなに危険なら、AIを使った開発はやめておいた方がいいのではないか」「セキュリティの設定ばかりで、開発のスピードが落ちてしまうのではないか」と不安に思われたかもしれません。

　しかし、それは全くの誤解です。これからの時代、セキュリティは決して「イノベーションを阻害するブレーキ」ではありません。むしろ、 イノベーションを根底から支え、加速させるための「強固なプラットフォーム」 なのです。

　スポーツカーを想像してみてください。なぜスポーツカーは時速300kmという猛スピードで走ることができるのでしょうか？ それは、エンジンが強力だからというだけではありません。強力で、しっかり止まることができるブレーキ（安全装置）が備わっているからです。コースの横に頑丈な「ガードレール」があるからこそ、ドライバーは恐れることなく、アクセルを全開に踏み込むことができるのです。

　AIによる爆速開発も同じです。「人間の目でチェックしなければならない」という古い根性論を捨て、システムの裏側に「自動化されたガードレール」をしっかりと敷き詰めること。それさえ完了すれば、開発チームはセキュリティの不安から解放され、AIという最強のエンジンを使って、純粋な機能開発やビジネスのアイデア出しに100%の力を注ぐことができます。

　AIと共存するこれからのエンジニアの役割は、1行ずつコードの粗探しをする「コーダー」ではありません。 「誰もが安全に、超高速で駆け抜けられるコース（ガードレール）を設計するアーキテクト」 なのです。