1. ハードコーディングされたシークレット・APIキー

AIコーディングアシスタントは、ひとまず動作するコードを迅速に出力することに最適化されています。その過程で、サンプルのAPIキー、テスト用のDB接続情報、サンプルのJWTシークレットがコード内にそのまま残ってしまうケースが発生します。

Enki Whitehatが実施したレッドチームプロジェクトでも、同様の事例がありました。ある企業の社内コードリポジトリにそのまま保存されていたAPI_KEYと一部のシステムアカウントの認証情報を収集し、内部拡散に活用された事例がありました。これは、「ホワイトハッカーが最もよく使う攻撃ルート TOP 5」の2位であるサプライチェーン攻撃へと繋がります。1つのリポジトリに残されたトークンが、ビルドパイプライン全体を掌握できる鍵となる構造なのです。

海外の調査でも、AIアシスタントが関与したコミットのシークレット流出率は、人間が単独で作成したコミットの約2倍の水準に達していると報告されており(Apiiro — 4x Velocity, 10x Vulnerabilities)、2025年の1年間だけで公開GitHubに新たに露出したシークレットの規模も増え続けているのが現状です。(GitGuardian — State of Secrets Sprawl 2026)

このような流れを受け、社内で実施できる対策は以下の通りです。

対策方法

• Git履歴の全区間を対象に、シークレットスキャナー（gitleaks、trufflehogなど）を定期的に実行

• .envやsecrets.yamlのようなファイルは、シークレットマネージャー（AWS Secrets Manager、HashiCorp Vaultなど）へ移行

• 静的解析（SAST）パイプラインで「ハードコーディングされた認証情報」のルールを有効化

• リポジトリに公開されてしまった資格情報およびAPIキーの無効化（破棄）処理

• pre-commitフックを利用し、機密文字列がコミットされる前にブロック

2. 古いバージョンのライブラリ・依存関係

AIコーディングアシスタントは、学習時点のライブラリバージョンをデフォルトとして推奨する傾向があります。アシスタントの推奨をそのまま適用する開発者の場合、数ヶ月から1年前のバージョンが自然とpackage.jsonやrequirements.txtに書き込まれることになります。これは、TOP 5 攻撃ルートの4位である「1-day 脆弱性」の代表的な原因です。すでにパッチが提供され、CVE番号まで付与されている脆弱性であるにもかかわらず、自社チームだけがアップデートしていない状態で放置されていることになります。以前のレッドチームの事例では、あるSaaS製品のAI推奨テンプレートが、すでにCVEが公開されているバージョンの認証ライブラリをデフォルトとして組み込んでいたケースも確認されました。

対策方法

• SBOM（Software Bill of Materials：ソフトウェア部品表）を生成し、どのバージョンがデプロイされているかの可視性を確保

• npm audit、pip-audit、osv-scannerをCIパイプラインの基本ルーチンとして追加

• DependabotやRenovateなどの自動アップデートツールを活用

• AIアシスタントが提案した依存関係は、コードレビューの過程でバージョンを再確認

ただし、最近ではnpmやPyPIのエコシステムを狙ったサプライチェーン攻撃も同様に増加しています。実際に、正規パッケージと類似した名前の悪意あるパッケージや、乗っ取られたメンテナンスアカウントを介した悪意あるアップデートの事例も継続的に報告されています。最近のTeamPCPサプライチェーン攻撃事例では、CI/CDトークンの奪取とオープンソースパッケージのアップデートチェーンを悪用し、自動化された開発環境そのものを攻撃経路として利活用することもありました。このため、自動アップデートツールも単なる「自動反映」に頼るのではなく、信頼できるパッケージであるかや変更内容を共に検証する運用体制の中で使用することが重要です。

3. 不完全な認証・権限管理

AIが生成する認証および認可のコードは、標準的なケースにおいては適切に動作します。ログイン、トークン発行、基本的なロール検証（役割チェック）まではきれいに記述されます。問題はエッジケースです。Enki WhitehatがOFFen PTaaSを通じて繰り返し確認したパターンは以下の通りです。

• JWT有効期限検証ロジックが抜けており、破棄されたトークンでもアクセス可能なエンドポイント

• IDOR（Insecure Direct Object Reference：安全でない直接オブジェクト参照）：オブジェクトIDを変更するだけで、他人のユーザーデータが露出してしまうルート

• 権限チェックがフロントエンドにしか適用されておらず、バックエンドのルートで省略されているケース

• 管理者用APIと一般ユーザー用APIが同じハンドラーを共有し、分岐処理が漏れている場合

この領域は、自動化ツールが特に検知しにくいのが特徴です。認可呼び出しはコードに含まれているものの、ランタイムで実際には強制されない構造になっていることが多く、静的解析（SAST）で検知されないケースが多々あります。動的解析（DAST）でも、オブジェクトIDを変更しながら他人のリソースを要求したり、フロントエンドで制限されている入力をバイパスしてサーバーに直接リクエストを送信するようなシナリオを自動実行するのは困難です。攻撃者の視点から直接ロジックを検証して初めて明らかになる領域です。

対策方法

• 認証・認可ロジックをコードレビューの必須チェック項目に指定します。それだけでなく、未認可のリクエストが実際にブロックされるかを確認する必要があります。

• 新規追加されたAPIやルートが認証なしで公開されていないかを合わせて点検します。AIが作成したコードでは権限検証が漏れていたり、テスト用のエンドポイントがそのまま残ったりすることがあるためです。

• デプロイ前のユニットテストと統合テストを行い、認証・認可ロジックが意図通りに動作するか確認します。機能が正常に動作するかどうかだけでなく、権限がない状態でのアクセスや他人のリソースへのリクエストといった不正な状況についても検証する必要があります。

• 自動模擬ハッキング（自動ペネトレーションテスト）のシナリオを繰り返し実行し、新規追加されたAPIや変更された権限ロジックで同様の問題が再発していないか点検します。

• 四半期に1回以上、あるいは認証・認可システムに変更があった場合は、外部のPTaaSでエッジケースを検証します。オブジェクトIDの操作や権限のバイパスなど、自動化ツールで見落としがちなパターンは、攻撃者の視点から直接確認する必要があります。