ここ数か月、コンピューターで生成された顔、猫の写真、ビデオ、エッセイ、さらにはアートの品質に驚かされてきました。 人工知能 (AI) と機械学習 (ML) も、GitHub Copilot、Tabnine、Polycode、 ほか AI ステロイドに既存のコードのオートコンプリート機能を追加するという論理的な次のステップを実行します。 ただし、猫の写真とは異なり、アプリケーション コードの出所、品質、およびセキュリティは、広範囲に影響を与える可能性があります。少なくともセキュリティに関しては、リスクが現実のものであることが調査によって示されています。
事前の 学術研究 は、GitHub Copilot がセキュリティの脆弱性を伴うコードを生成することが多いことをすでに示しています。 最近では、Invicti のセキュリティ エンジニアである Kadir Arslan による実践的な分析で、次のことが示されました。 安全でないコードの提案 Copilot の例外ではなく、依然としてルールです。 Arslan は、多くの一般的なタスクの提案には絶対的な必要最低限しか含まれておらず、多くの場合、最も基本的で安全性の低いルートを採用していること、および変更なしでそれらを受け入れると、機能しているが脆弱なアプリケーションになる可能性があることを発見しました。
Copilot のようなツールは、(設計上) オートコンプリートが一段と向上し、オープン ソース コードでトレーニングされて、同様のコンテキストで関連する可能性のあるスニペットを提案します。 これにより、提案の品質とセキュリティは、トレーニング セットの品質とセキュリティに密接に結びついています。 したがって、より大きな問題は、Copilot やその他の特定のツールに関するものではなく、AI によって生成されたソフトウェア コード全般に関するものです。
Copilot は槍の先端に過ぎず、同様のジェネレーターが今後数年間で一般的になると想定するのは合理的です。 つまり、私たちテクノロジー業界は、そのようなコードがどのように生成され、どのように使用され、問題が発生した場合に誰が責任を負うのかを問い始める必要があります。
サトナフ症候群
関数定義を検索して関数名を完成させ、必要な引数を思い出させる従来のコード自動補完は、時間を大幅に節約します。 これらの提案は、自分でドキュメントを検索するための近道にすぎないため、IDE が提案するものは何でも暗黙のうちに信頼することを学びました。 AI を利用したツールが登場すると、その提案が正しいとは限りませんが、友好的で信頼できると感じられるため、受け入れられる可能性が高くなります。
特に経験の浅い開発者にとっては、コードのブロックを無料で入手できるという便利さは、「このコードは自分が書くものに十分近いか」という考え方から、「このコードを微調整して自分に合ったものにするにはどうすればよいか」という考え方への転換を促します。
GitHub は、Copilot の提案は常に慎重に分析、レビュー、およびテストする必要があることを明確に述べていますが、人間の性質により、標準以下のコードでさえ、場合によっては製品化されることがあります。 これは、道路よりも GPS を見ながら運転するようなものです。
サプライチェーンのセキュリティ問題
Log4j のセキュリティ危機 ソフトウェア サプライ チェーンのセキュリティ、特にオープン ソースのセキュリティが脚光を浴びるようになりました。 ホワイトハウスメモ 安全なソフトウェア開発と新しい オープンソース セキュリティの改善に関する法案. これらのイニシアチブやその他のイニシアチブにより、アプリケーションにオープン ソース コードを含めることは、すぐにソフトウェア部品表 (SBOM) に書き込む必要が生じる可能性があります。これは、特定の依存関係を故意に含める場合にのみ可能です。 ソフトウェア構成分析 (SCA) ツールも、その知識に基づいて、古いまたは脆弱なオープン ソース コンポーネントを検出してフラグを立てます。
しかし、最終的にはオープンソースのトレーニング セットに由来する AI 生成コードがアプリケーションに含まれている場合はどうなるでしょうか? 理論的には、実質的な提案が XNUMX つでも既存のコードと同一であり、そのまま受け入れられる場合、ソフトウェアにオープン ソース コードを含めることができますが、SBOM には含めることができません。 これは、コンプライアンスの問題につながる可能性があり、コードが安全でないことが判明した場合の法的責任の可能性は言うまでもなく、侵害につながる可能性があります。SCA は、脆弱な依存関係のみを検出でき、独自のコードの脆弱性は検出できないため、役に立ちません。 .
ライセンスと帰属表示の落とし穴
一連の考え方を続けると、オープン ソース コードを使用するには、そのライセンス条項に準拠する必要があります。 特定のオープン ソース ライセンスに応じて、少なくとも帰属表示を提供するか、場合によっては独自のコードをオープン ソースとしてリリースする必要があります。 一部のライセンスでは、商用利用が完全に禁止されています。 ライセンスが何であれ、コードがどこから来たのか、どのようにライセンスされているのかを知る必要があります。
繰り返しになりますが、既存のオープン ソース コードとたまたま同じであるアプリケーション内の AI 生成コードがある場合はどうなるでしょうか? 監査を受けた場合、必要な帰属表示なしでコードを使用していることがわかりますか? それとも、コンプライアンスを維持するために商用コードの一部をオープンソースにする必要があるのでしょうか? 現在のツールではまだ現実的なリスクではないかもしれませんが、これらは 10 年後ではなく、今日、私たちが問わなければならない種類の質問です。 (明確にするために、GitHub Copilot には、サプライ チェーンのリスクを最小限に抑えるために、既存のコードに一致する提案をブロックするオプションのフィルターがあります。)
より深いセキュリティへの影響
セキュリティの話に戻ると、AI/ML モデルの良し悪しは、そのトレーニング セットにかかっています。 私たちは過去にそれを見てきました - たとえば、 人種的偏見を示す顔認識アルゴリズム 彼らが訓練されたデータのためです。 したがって、コード ジェネレーターがセキュリティを考慮せずに頻繁に提案を生成することを示す調査がある場合、これがその学習セット (つまり、公開されているコード) がどのようなものであったかを推測できます。 そして、安全でない AI 生成コードがそのコード ベースにフィードバックされたらどうなるでしょうか? 提案は安全であることができますか?
セキュリティの質問はそれだけではありません。 AI ベースのコード ジェネレーターが人気を博し、新しいコードの大部分を占めるようになった場合、誰かがそれらを攻撃しようとする可能性があります。 学習セットを汚染することで、AI の画像認識をだますことはすでに可能です。 遅かれ早かれ、悪意のあるアクターは、公開リポジトリに独自に脆弱なコードを配置しようとします。これは、それが提案され、最終的には本番アプリケーションに組み込まれ、簡単な攻撃にさらされることを期待するためです。
モノカルチャーはどうですか？ 複数のアプリケーションが同じ非常に脆弱な提案を使用することになった場合、その起源が何であれ、脆弱性の蔓延や AI 固有の脆弱性を調べている可能性があります。
AIに目を光らせる
これらのシナリオのいくつかは、今日ではとてつもないものに見えるかもしれませんが、それらはすべて、テクノロジー業界で議論する必要があるものです. 繰り返しますが、GitHub Copilot が脚光を浴びているのは、それが現在先導しているからに過ぎず、GitHub は AI によって生成された提案の警告について明確な警告を提供しています。 電話のオートコンプリートやカーナビのルート提案と同様に、それらは私たちの生活を楽にするためのヒントにすぎず、それらを受け入れるか残すかは私たち次第です。
開発効率を飛躍的に向上させる可能性を秘めた AI ベースのコード ジェネレーターは、ソフトウェアの世界で恒久的に使用される可能性があります。 ただし、アプリケーションのセキュリティに関して言えば、これは潜在的に脆弱なコードのもう XNUMX つのソースであり、本番環境に許可される前に厳格なセキュリティ テストに合格する必要があります。 私たちは、脆弱性 (および潜在的に未チェックの依存関係) をファースト パーティ コードに直接組み込むまったく新しい方法を検討しています。そのため、AI によって拡張されたコードベースをテストするまで信頼できないものとして扱うことは理にかなっています。つまり、すべてをできるだけ頻繁にテストすることを意味します。できる。
Copilot のような比較的透明性の高い ML ソリューションでさえ、セキュリティ上の懸念は言うまでもなく、すでに法的および倫理的な問題を提起しています。 しかし、ある日、新しいツールが完全に機能し、セキュリティ テストに合格するコードを生成し始めると想像してみてください。 そんな時こそパニックです。
