※本記事は、アスタリスク・リサーチの岡田良太郎氏による「ソフトウェアセキュリティはAIの登場でどう変わるか- OWASP LLM Top 10」と題した講演の内容を基に作成されています。この講演は「明日の開発カンファレンス『AIの進化を追え！未来の開発がここから始まる』」の一部として行われたものです。カンファレンスの詳細情報は https://fod.connpass.com/event/52522/ でご覧いただけます。
本記事では、講演の内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの講演動画をご覧いただくことをお勧めいたします。このカンファレンスは、有志が運営するリアルな現場の声を元に企画されており、ソフトウェア開発と運用の現場で役立つ具体的な事例や、開発リーダーやエンジニアの方々が即実践につながる経験やアイデアを共有することを目的としています。
1. はじめに
1.1. 自己紹介と講演概要
岡田良太郎と申します。初めましての方も多いかと思いますので、まずは自己紹介をさせていただきます。私はアスタリスク・リサーチに所属しており、ソフトウェアセキュリティの分野で活動しています。
OWASP（Open Web Application Security Project）という団体で約20年ほど活動しており、最近は25周年を折り返したところです。OWASPはオープンソースの団体で、ソフトウェアのセキュリティがどうあるべきかを共通課題として考えています。北はロシアから南は南アフリカに至るまで、様々な国のエンジニアが集まるオープンソースの組織です。
私はOWASPのコントリビューターとして、OWASP Top 10などのドキュメントの作成や翻訳に携わっています。これはソフトウェアの中にどういった脆弱性が残ったままだとあとあと辛いかという啓発のためのドキュメントで、GitHubで見ることもできます。約20ページ程度のエントリーポイントとなる資料です。
また、「ハードニングプロジェクト」という活動も約12年ほど続けています。これはシステムに8時間攻撃され続けるなかで、それを守り抜く方法を競う、いわば守り方の真剣勝負のような競技です。
本日の講演では、AIの登場によってソフトウェアセキュリティがどのように変わるのか、特にOWASP LLM Top 10の観点から見ていきたいと思います。セキュリティの話は正直あまり好かれないテーマかもしれませんが、できるだけわかりやすくモデル化してお話しします。私も物作りが大好きな立場から、このシステムを妨害するやつらが一番嫌いですが、そういった脅威を想定しながらシステムを作る必要があるという現実と、AIがその課題解決にどう役立つかを探っていきたいと思います。
1.2. OWASPの紹介と活動内容
OWASPというのは、約20年以上前から活動しているオープンソースの団体です。ソフトウェアのセキュリティがどうあるべきかという共通課題に取り組んでいます。北はロシアから南は南アフリカに至るまで、様々な国のエンジニアが集まるオープンソースの組織だと思ってください。
OWASPの代表的な成果物として「OWASP Top 10」があります。これはソフトウェアの中にどういった脆弱性が残ったままだとあとあと辛いかということを啓発するためのドキュメントです。私もコントリビューターとして関わっており、翻訳も担当しています。このドキュメントはGitHubで公開されており、どなたでも利用できます。約20ページ程度で、セキュリティのエントリーポイントとして活用いただけるものです。
また、最近注目されているのが「OWASP LLM Top 10」です。これは大規模言語モデル（LLM）に関連するセキュリティ上の主要な懸念事項を識別し、開発者や組織がAIを安全に実装するためのガイドラインを提供するものです。このドキュメントでは、プロンプトインジェクション攻撃、データ漏洩リスク、有害なコンテンツ生成など、LLMに関連する10の主要なセキュリティリスクとその対策が詳しく説明されています。
OWASPの活動の本質は、セキュリティに関する共通の知見を広め、ソフトウェア開発者がセキュリティのことを考慮したシステム設計や実装ができるよう支援することにあります。100%のセキュリティはないものの、最低限これをやっておけば比較的強いシステムになるといった指針を提供しています。日々変化する攻撃に対応するため、様々な企業のエンジニアや関係者が集まって実証実験を行うなど、実践的な取り組みも行っています。
このような活動を通じて、セキュリティに関する知見をできるだけ多くの人に届けることが重要だと考えています。YouTubeでも多くのトークを公開しており、今回のセッションもできるだけ多くの人に情報が届くよう、配信される予定です。インターネットに情報を公開することで、必要としている人が情報を取得できるだけでなく、AIの学習データにもなり得るという面もあります。
1.3. セキュリティの基本的な考え方
セキュリティの話は正直なところ、多くの人が好きではないと思います。インターネットの治安が悪いから考えなければならない問題であり、本当に迷惑な話です。私も物作りが大好きな立場からすると、一番嫌なことはシステムを妨害する人たちの存在です。システムを妨害したり、悪用したり、破壊したりするような脅威を想像しながらシステムを作れと言われると、「なぜ私の仕事を増やすのか」と思ってしまうのが正直なところでしょう。
しかし、システムの安全性レベルを考える上で少なくとも一つ重要なパラメーターがあります。それは世の中に蔓延している脅威です。この脅威がゼロになれば、かなりふんわりとしたソフトウェアをリリースすることも可能になり、特に電波障害なども気にすることなくドローンなどを作れるようになるでしょう。それは確かに嬉しいことです。私自身もドローンパイロットの免許を持っていますので、そのような世界は魅力的です。
もう一つのパラメーターは、脅威に対応できる能力がシステムにあるかどうかです。この二つのパラメーター、つまり「脅威」と「対応能力」がセキュリティの安定性を決める方程式だと考えています。100点満点のセキュリティはないにしても、どの程度考慮したシステムを作るかは重要な問題です。
外部からの脅威の中には、実はユーザーの不完全性も含まれます。ユーザーが「まさか」という使い方をすることもあり得るわけです。それを嫌がっていてはソフトウェアは作れませんから、ある程度は仕方ない脅威として認めざるを得ません。
また、システムの内部側の事情にも関わる問題があります。欧州連合のセキュリティ庁が毎年発表している脅威レポートを見ると、サプライチェーンの問題が赤字で強調されています。これは簡単に言うと、私たちのシステムの80%以上はオープンソースソフトウェアや類似のコンポーネントで構成されており、自分たちのコードは最大でも20%程度に過ぎないという現実があります。この80%部分はコードレビューをしないことが多く、そこに悪意のあるコードが混入するリスクが増加しているという問題です。
このような状況に対応するため、ソフトウェア部品表（SBOM）の管理などが重要視されるようになっています。しかし、SBOM情報を出力しても、それが何の役に立つのか分かりにくいという課題もあります。米国大統領令から経済産業省まで、ソフトウェアセキュリティの80%はコンポーネントにあるという認識が広がりつつあります。
セキュリティは面倒くさいと感じられがちですが、オープンソースコードの世界でも「目くらまし」で使われることが多く、問題となっています。結局のところ、脆弱性対応は一言では言い表せない複雑な状態にあり、開発者がどの程度の労力をかければセキュリティに対応できるのかという問題は常に存在しています。
2. ソフトウェアセキュリティの現状とオープンソースの課題
2.1. セキュリティの方程式：脅威と対応能力
セキュリティを考える上で、モデル化して説明するとわかりやすいと思います。結局のところ、インターネットの治安が悪いからこの問題を考えないといけないのです。本当に迷惑な話ですよね。私も物作りが大好きな立場からすると、一番嫌なことはシステムを妨害する人たちの存在です。システムを妨害したり、悪用したり、破壊したりするような「脅威」というものを想像しながら、それに耐えるようにシステムを作れと言われると、「なぜ私の仕事を増やすのか」と思ってしまうのが正直なところです。
しかし、システムの安全性レベルを考える上で少なくとも一つ重要なパラメーターがあります。それは世の中に蔓延している「脅威」です。これがゼロになれば、かなりふんわりとしたソフトウェアをリリースすることも可能になり、特に電波障害なども気にすることなくドローンなどを作れるようになるでしょう。それは確かに嬉しいことです。
もう一つのパラメーターは、脅威に対応できる能力がシステムにあるかどうかです。この「脅威」と「対応能力」という二つのパラメーターがセキュリティの安定性を決める方程式だと考えています。この対応能力のパラメーターがしっかり揃っていて、うまく対応できれば、セキュリティ的には及第点といえるでしょう。100点満点のセキュリティはないにしても、どの程度考慮したシステムを作るかは重要な問題です。
外部からの脅威の中には、実はユーザーの不完全性も含まれます。先ほど人間の不完全性や権限・権利についてのフレーズがありましたが、ユーザーも不完全なので、「まさか」という使い方をすることもあり得るわけです。それを嫌がっていてはソフトウェアは作れませんから、ある程度は仕方ない脅威として認めざるを得ないユーザーもいるわけです。
さらに厄介なのは、システムの内部側の事情に関わる外部の脅威です。欧州連合のセキュリティ庁が毎年発表している脅威レポートを見ると、サプライチェーンの問題が強調されています。これは簡単に言うと、私たちのシステムの80%以上はオープンソースソフトウェアや類似のコンポーネントで構成されており、自分たちのコードは最大でも20%程度に過ぎないという現実があります。この80%部分はコードレビューをしないことが多く、そこに悪意のあるコードが混入するリスクが増加しているという問題です。
このようにセキュリティの安定性は、外部からの脅威と、それに対するシステムの対応能力という二つのパラメーターのバランスで決まります。この方程式を理解し、適切な対策を講じることがソフトウェアセキュリティの基本的な考え方なのです。
2.2. オープンソースとサプライチェーンの課題
オープンソースソフトウェアのセキュリティ問題は深刻です。なぜなら、みんなが使うオープンソースソフトウェアは、わたしたちのシステムの80%以上を占めているからです。これらは「善意の塊」のように思われていますが、セキュリティという観点では大きな問題を抱えています。
欧州連合のセキュリティ庁が毎年発行している脅威レポートを見ると、現在特に注目すべき問題として「サプライチェーン」が赤字で強調されています。これは簡単に言うと、私たちのシステムの80%以上はオープンソースソフトウェアやその他のコンポーネントで構成されており、自分たちが書いたコードは最大でも20%程度に過ぎないという現実があります。そしてその80%部分のコードレビューは正直ほとんど行っていません。アップデートは気にするかもしれませんが、そこに混入する悪意のあるコードの問題がめちゃくちゃ増えているのです。
オープンソースソフトウェアについてよく言われるのは、「みんながコードを見ているから、どんどん安全になっていく」という神話です。しかし、実際にはそうなっていません。みなさんの中で、オープンソースソフトウェアのコードを実際に詳細にレビューしたことがある人はどれくらいいますか？一つか二つのプロジェクトは見たことがあるかもしれませんが、アップデートを適用する前にコードを確認する人はほとんどいません。つまり、実質的にはブラックボックスとして使っているのです。
オープンソースソフトウェアプロジェクトの開発者たちは頑張っていますが、実態は厳しいものです。今年のデータによると、オープンソースソフトウェアの開発に携わるエキスパートの約3分の1は、安全なソフトウェアを開発することにはほとんど慣れていません。どうしたらいいかわからないのが現状です。そのため、Linux Foundationなどは安全なソフトウェアの書き方についてのコースを一生懸命オープンソース開発者に提供したりしています。これは素晴らしい取り組みだと思います。
これに対応するため、世の中ではSBOM（Software Bill of Materials：ソフトウェア部品表）をしっかり管理しろという流れになっています。私たちもそういったものを取り扱うツールを販売していますが、実際にはSBOMデータをJSONでぱっと出しても、「何がうれしいのかよくわからない」という状態になりがちです。それをうまく取り扱えるようになれという要請が、米国大統領令から経済産業省まで広がっており、「ソフトウェアのセキュリティの80%はコンポーネントだ」と言われているのが現状です。
サプライチェーンセキュリティの問題は、単にコンポーネントの管理だけでなく、それらが持つ潜在的な脆弱性やライセンスの問題、アップデート管理など多岐にわたります。システム全体のセキュリティを考える上で、この80%を占めるコンポーネント部分をいかに安全に管理するかが大きな課題となっています。
2.3. 企業におけるセキュリティ対策の現状
企業におけるセキュリティを推進するためのフレームワークには、ガバナンスからデザイン、実装、テスト、そして運用といった段階があります。これらの段階で開発者はそれぞれ頑張るべき部分があるのですが、現状を簡略化して見てみると、よくできていることトップ3と、できていないことトップ3があります。
まず、よくできていることトップ3は、一つ目が脆弱性管理です。多くの企業で脆弱性管理は実施されています。二つ目はインシデントマネージメントで、何か問題が起きた時に最優先で対応することもできています。三つ目は、それに基づいて環境を強化すること、つまり「落ちてるぞ」と言われた時に、落ちないようにバックアップや監視強化をするということです。
しかし、これら3つはまるで自衛消防団のようなものです。つまり、火が出たときにそれを消しに行くという、いわば後手に回った対応なのです。常に「負け戦」という感じで、皆さん「ご苦労様です」といった状態です。どちらかというと、火の手が上がらないようにするための予防的な努力というよりは、対応的な取り組みになっています。
先ほど説明したように、セキュリティの安定性の方程式は「外部の脅威」と「それに対する対応力」の2つのパラメーターで成り立っています。ここで2つの問題があります。1つは、外部の脅威が何なのかがさっぱりわからない、考えたくもないということです。これを理解するには「ハッカーのようなメンタリティ」が必要だとセキュリティの人は言いますが、それは違うと思います。物作りを愛している人が物を壊すことに魅力を感じるというのはあり得ると思いますが、あえて悪用するシナリオを考えるのは辛いものです。そして、それに対応できるようにシステムを作るというのは「誰のためにやっているのか」という気持ちになりがちです。
できていないことトップ3は、まさにこの「脅威について考える」ということが一つ目です。脅威分析ワークショップなどは検索すればたくさん出てきますが、実際に脅威分析を考える気持ちになれないというのが現状です。二つ目は、その脅威に対応できるようなアーキテクチャーを選択することです。これはベテランの悪い癖でもありますが、大好きなアーキテクチャーを常に採用してしまうことがあります。アジャイル開発で「これでいい」と言われた時に愕然とするような状況もあります。三つ目は、ガバナンスの欠如です。これは硬い言葉ですが、つまり物事の決め方や進め方の部分の手が弱いということです。「うちはまだそれを使っちゃだめ」とか、「品質チームはセキュリティスキャナーを持っているけど開発チームには提供されていない」とか、「セキュリティテストは最後と決まっているから」といった状況があります。
このように、企業におけるセキュリティ対策の現状は、事後対応はできているものの、予防的な取り組みや脅威を事前に想定した設計・実装が弱いという状況にあります。
3. AIとセキュリティの新たな可能性
今日のテーマであるAIについて考えていきましょう。現実世界の様々な産業では、AIがかなりクリティカルな場面で使われています。一つの判断のエンジンだったり、あるいは何かの動作をコントロールするものとしてAIが活用されています。ここは投資の規模も違うのかなと思うほど、ソフトウェア側よりも産業界では積極的にAIが活用されているのが現状です。
例えば医療の世界では、AIの活用が進んでいます。恐らく私たちが次に気づいて調べる頃には、ほとんどAIが導入されているという状況になるでしょう。AIの判断の迅速さや、学習済みのデータに基づいて「こうなんじゃないか」という仮説を示したときに、人間が「その手もあったか」とパッと判断できるまでのスピードが、ものすごく加速しています。結果的に、適切な治療を提供することにAIは向いているのです。
また、見落としがありがちな普通のワーカーに比べ、ある一点のミスを認めつつも、きちんと網羅的にいろんなものを分析するという点でもAIは非常に優れています。現実社会をより良いものにするために、AIが活用されています。
さらに、警察庁は何十億もの予算を要求し、フィッシングサイトやその他のサイバー犯罪を検出するためにAIを活用しようとしています。人間が見るとすぐに騙されてしまうようなものでも、AIなら「このパターンは詐欺だ」「このパターンは正当だ」といったことをすばやく判断し、しかも膨大な量を処理することができます。このような用途にAIは非常に向いています。
AIの学習データの元は何かというと、その多くはオープンソースソフトウェア、つまり公開されているコードです。これが「ガーン」と来る部分なのですが、オープンソースソフトウェア自体のセキュリティは大丈夫なのでしょうか。これは現在大きな問題となっています。
このようなオープンソースソフトウェアのセキュリティ問題をAIで見つけようという試みも始まっていますが、現時点ではAIのおかげで見つかった重大な脆弱性は1つしかありません。これは非常に重要な問題です。なぜなら、私たちが直接手を入れられないオープンソースソフトウェアが、AIの学習データになっているからです。
今日のメッセージの一つは、膨大な量の学習データになっているオープンソースソフトウェアを安全にしていくことが、AIの発展にもつながるということです。みんなのコードの80%以上がオープンソースなので、それが安全になってくれると自動的に安全なシステムを作りやすくなるのです。
しかし、ここで問題になるのが、オープンソースソフトウェアのプログラムが学習データとなり、そこからサンプルコードを生成するツール（例えばGitHub Copilotなど）の存在です。「学習データに脆弱性を含むオープンソースコードがあり、それを基にコードを生成している」という事実は、「ちょっと待て」という気持ちにさせられます。AIが生成するコードの安全性は、学習データの安全性に大きく依存しているのです。
4. セキュリティ対策のアプローチ
4.1. NISTのセキュリティフレームワーク
オープンソースソフトウェアだろうが、皆さんの会社で業務で使うシステムであろうが、セキュアなシステムを作るということについては、NISTという米国の標準機関が「SSDF」というドキュメントを出してくれています。このドキュメントの中で、セキュアなシステムを開発する際にどうしたらいいかということがまとめられています。
しかし、SSFDの第1章第1節第1分節のところに参照されているリストを見ると、これが非常に膨大なものであることがわかります。「もうちょっとシンプルにしてくれないか」と思うほど多くの項目があります。一応OWASPも参照されていて赤くマークしておきましたが、本当に「もう少し減らしてくれないか」と思ってしまいます。
このような膨大なドキュメントを、ほとんど全て学習し終わっているAIも既にリリースされています。「CRRRE」というウェブサイトを使うと、「こういう状況の時に気にしなければならないことは何か」と問い合わせることで、「こういうことを気にするといいと思う」という返事が返ってくるという素晴らしいツールです。ただ、ユーザーインターフェースが非常に素朴で使いにくいのが現状です。
このサイトは少しお土産的なものですので、ぜひ一度アクセスしてみてください。セキュリティに関して参照しなければならないものが膨大で、時間も足りないし、知見も足りないかもしれない時に、システムとして考慮に入れなければならないことや実装に組み入れないといけないことについて、AIに聞くことができるのは非常に価値があります。これは今日のメッセージのもう一つの重要なポイントです。
私は本業で開発セキュリティを推進することを支援したり、そういったことが実現できるツールを紹介したりしています。セキュリティフレームワークには、ガバナンスからデザイン、実装、テスト、そして運用といった段階があります。こういった枠組みを使って、特定の領域ではこういうところをもう少し頑張る必要がありますね、といった分析をするわけです。
これは一応役に立つのですが、もっとシンプルに考えると、企業でよくできていることトップ3と、できていないことトップ3があります。この対比を通して、NISTのような複雑なフレームワークをどう実際に活用していくべきか、そしてAIがその過程でどのように役立つかを考えていく必要があります。
5. AIを活用したセキュリティ対策とその限界
5.1. AIを設計アドバイザーとして活用する提案
企業でセキュリティ対策としてできていないことトップ3として、「脅威について考える」こと、「脅威に対応できるアーキテクチャーを選択する」こと、そして「ガバナンスの欠如」を挙げました。これらの課題に対して、私はAIを活用する提案をしたいと思います。
私の提案は、「脅威と対応の手法」のために、AIを設計アドバイザーとして使うということです。これはピンとこないかもしれませんので、具体的なプロンプトを用意しました。例えば、ChatGPTに次のように質問してみるのです：
「私は出版業界の企業向けにファイルアップローダーの機能追加を開発します。このシステムに対する最近のサイバー攻撃の可能性をリストしてください。潜在的な業界固有のコンプライアンスをリストしてください。設計と実装に対する一般的で効果的な対策をリストしてください。」
このようなプロンプトを入力すると、ハッカーでもないのに様々な攻撃の可能性や対策を教えてくれます。プログラミング言語（例えばPython）の入力検証サンプルコードを書いてもらい、脆弱な箇所があるかどうか確認することもできます。
AIを使うことで、脅威分析という専門知識が必要な領域でも、基本的な情報や考え方を得ることができます。これは、脅威について考えることが難しい開発者にとって、大きな助けになるでしょう。プロジェクトの特性に合わせた脅威モデルを作成し、それに対応するアーキテクチャや対策を検討する手助けをしてくれるのです。
脅威分析というのは、システムにどんな問題が起こりそうか、どういうハッカーが何をやってくるかを想定することですが、実はチームで30分でもブレインストーミングするだけで、専門家が行う精度の6〜7割の分析ができると言われています。しかし、どういう攻撃があり得るのかというカタログがない、そのデータがないという問題があります。AIを使えば、そのカタログを簡単に得ることができるのです。
また、コンプライアンスに関する情報も同様です。出版業界ならではの法的要件や規制について、AIが整理して教えてくれます。これらの情報をもとに、設計と実装に対する効果的な対策も提案してくれるので、セキュリティを考慮したシステム開発が格段に容易になります。
このようにAIを設計アドバイザーとして活用することで、企業のセキュリティ対策における「できていないこと」を改善し、より安全なシステム開発を実現することができるのです。
5.2. 脅威分析とAIの活用例
AIを活用した脅威分析の具体例を見ていきましょう。私が用意したプロンプトの例を実際に試してみました。ChatGPTに対して以下のようなプロンプトを入力しました：
「私は出版業界の企業向けにファイルアップローダーの機能追加を開発します。このシステムに対する最近のサイバー攻撃の可能性をリストしてください。潜在的な業界固有のコンプライアンスをリストしてください。設計と実装に対する一般的で効果的な対策をリストしてください。」
このプロンプトを入力すると、AIは様々な攻撃の可能性を教えてくれます。面白いことに、空で思いつくよりも多くの攻撃パターンが出てきます。例えば、ファイルアップロードシステムに対して考えられる攻撃として、以下のようなものがリストアップされました：
- 悪意のあるファイルのアップロード（マルウェア、ウイルスなど）
- ファイルタイプの偽装による攻撃
- サイズの大きいファイルによるDDoS攻撃
- メタデータを利用した攻撃
- パストラバーサル攻撃
これらの攻撃パターンを見ると「なるほど、そんな攻撃があるのか」と理解が深まります。
次に、コンプライアンスについても同様に質問しました。出版業界ならではの法的要件として、著作権法、GDPR（ヨーロッパの人たちも使える場合）、知的財産に関する法律などが挙げられました。これで、アップロードされたコンテンツをそのまま公開することがリスクを伴う可能性があることがわかります。SNSなら問題ないかもしれませんが、出版業界の場合は著作権などの問題で慎重な対応が必要かもしれないという気づきを得られます。
さらに、これらの脅威とコンプライアンス要件に基づいて、設計と実装に関する対策もAIから提案されました。例えば：
- ファイルタイプのホワイトリスト化
- ファイルサイズの制限
- ファイル内容のスキャン
- セキュアなファイル名の処理
- ユーザー認証と承認の強化
これらの対策を見ると「なるほど、こういった対策が必要なのか」と具体的な実装方針が見えてきます。
さらに進めて、例えばPythonでファイルタイプのホワイトリスト化のサンプルコードを書いてもらうこともできます。AIはそれに応じて実装例を示してくれました。
このコードを一度レビューしてみると、セキュリティの観点から不十分な点があることに気づきます。ここで重要なのは、AIに「このコードは安全ですか？」と聞くと、実は「そうでもない」という回答が返ってくることです。AIは自身が生成したコードでも、脆弱性がある場合はそれを指摘してくれるのです。
このように、AIを使った脅威分析は非常に効果的です。脅威カタログの作成、コンプライアンス要件の把握、それに対応する設計・実装方針の検討など、セキュリティに関する一連の検討プロセスをAIがサポートしてくれます。
また、リスクが高すぎる場合は、代替案を検討するようAIに依頼することもできます。例えば「ファイルアップロードはリスクが高すぎます、代替案を検討してください」と尋ねると、外部ストレージサービスの活用など、自分でリスクを負わずにクリアなソリューションを提案してくれることもあります。
5.3. コード生成・レビューにおけるAIの可能性と限界
コード生成とテストに関しては、AIの活用にはまだ課題があります。テストコードについては、特に注意が必要です。私の印象としては、まだ完全に信頼して任せられる段階ではないと感じています。
なぜかというと、ビジネスロジックの問題があるからです。例えば、出版業界には特有のロジックがあります。「この業界ではこういうロジックになっていて、ここは絶対に緩和できない」といった制約や、「ISBNコードの桁数を変えると不具合が起きる」といった特殊な事情があります。そういった業界固有のロジックはAIでは完全に理解できないことが多いです。
AIはある程度理解しているかもしれませんが、日本特有のローカルな事情や、特定の会社（例えば技術評論社）特有のルールなどは把握していないことが多いです。プロプラエイタリ（独自）のコードについては様々な注意が必要です。この点は、GitHubの方がさらっとおっしゃっていた一言が重要です：「我々はプロプライエタリなコードを書いてご飯を食べているんです。忘れないでください」。
つまり、特定の企業に所属しているからこそ必要なコードを書かなければならないのです。そのような特殊なコードをAIが生成できると考えるのは現実的ではありません。やはり難しいのが現状です。
また、AIがコードを提供してその安全性について尋ねると、興味深い結果が得られます。AIは「このコードは安全ですか？」という質問に対して、大体3〜4割程度しか「安全です」と答えてくれないことが多いです。なぜなら、システムによって何をもって脆弱とするかのレベルが変わるからです。
例えば、あるシステムではエラー処理の不足が大きな問題とされる一方で、別のシステムではスループットが非常に重要で、エラーは受け入れるというアーキテクチャ上の判断もあり得ます。そのため、「脆弱性検査ツールはAIの登場によって不要になる」と主張する人がいますが、それは誤りです。脆弱性検査ツールは依然として必要なのです。
それは何を持って脆弱性を見つけるかという視点や切り込み方の問題であり、AIが完全に代替できるものではありません。あるシステムでは致命的な問題が、別のシステムでは許容される設計上の判断である可能性もあります。ただし、セキュアなコーディングを学んだり、新たな視点を得るという意味では、AIは非常に有用です。
結論として、AIはコードレビューにおいて補助的なツールとして活用するのが最適です。特にセキュリティの観点からのヒントを得たり、新たな視点を導入したりする際に役立ちますが、最終的な判断はやはり人間の専門知識に基づいて行うべきでしょう。
6. AIセキュリティの法的リスクと今後の課題
6.1. AIによるコード生成の法的リスク
AIによるコード生成の法的リスクについても考慮しなければなりません。これはコード生成を使うなという話ではありません。むしろ、ヒントをもらったり、新たな着想を得たりというような目的でAIを使うことは良いことだと思います。しかし、法的なリスクは確実に存在します。
例えば、仮にオープンソースソフトウェアのコードだけを学習したAIエンジンがあったとしましょう。そのオープンソースソフトウェアのコードには様々なライセンスがあります。GPLやApacheライセンスなど、様々なライセンスがあります。中には、ハードリンクすると全コードを公開しなければならないというGPLのようなライセンスのものもあります。
ここで問題になるのは、「これは私がAIに頼んだプロンプトによって全く新しいものになっている」と主張しても、どうやってそれを証明するのかということです。これは「悪魔の証明」と呼ばれる類のものです。誰かのコードに似ていると指摘されたら、裁判には付き合わなければならないでしょう。「大丈夫だよね」と思っていても、証明するのは難しいのです。
既にアメリカでは何件か訴訟が起きており、GitHubの利用者が訴えられたケースもあったと思います。企画されたものもあります。つまり、この領域はまだグレーゾーンなのです。AIによる真のAIエンジン（AIによって作られたAI）はもう少し先の話かもしれません。
ただし、丸投げしないで、そこからセンスを持って自分の責任でコードに採用するということは、生産性を上げるだけでなく、知らないことがらを自分の知識として徐々に蓄えていくことにも役立つと思います。
6.2. AI自体のセキュリティリスク
もう一つ根本的な問題として考えなければならないのは、AI自体が攻撃の対象になる可能性があるということです。AIはこれだけ世の中への影響が大きいため、様々な攻撃を受けています。
例えば、何年かに一回Gmailが停止したり、Slackが止まったりすることがありますよね。同様に、GitHub Copilotが停止したり、何らかのAIサービスが停止したり、OpenAIのサービスが止まったりすることも想定されます。恐らく、これらのサービスは相当な攻撃を受けているのではないかと思います。そのため、そういった事態が発生した時のことを考えておく必要があります。頭の片隅にでも置いておくべき問題です。
また、AIそのもののモデルを開発する人たち向けに、「AIセキュリティリスクチェックリスト」や「ガバナンス」といったものをOWASPでは最近頑張って作成しています。これがまさに「OWASP LLM Top 10」の取り組みです。このドキュメントでは、AIシステムに対する主要な脅威とその対策が詳細に解説されています。
OWASP LLM Top 10には以下のような項目が含まれています：
- プロンプトインジェクション攻撃
- 不適切なコンテンツの生成
- データ漏洩
- サプライチェーンの脆弱性
- モデル盗用
- 過度な情報開示
- サービス拒否
- 効率と資源の乱用
- モデルポイズニング
- AIモデルの侵害
これらの脅威に対処するためのガイドラインも提供されており、開発者やセキュリティ担当者が参考にすることができます。
AIモデルへの攻撃には様々な形態があります。プロンプトインジェクション攻撃、学習データの汚染、モデル自体の操作など、AIシステムのセキュリティは従来のソフトウェアセキュリティとは異なる脅威モデルを持っています。これらに対する防御策も考えていく必要があるのです。
AIそのものを守るセキュリティと、AIが生成するコードのセキュリティという二重の課題に取り組む必要があります。この領域はまだ発展途上ですが、OWASPをはじめとする組織が積極的にガイドラインを提供しようとしています。
7. 今後の展望と提案
7.1. 自社向けAI活用の可能性
近い将来、私が聞いてみたいと思っているのは、システムのプロジェクト固有の情報を埋め込み、しかも継続的に情報が追加されていくLLM（大規模言語モデル）を作って、それを持って日々の開発を行うと、かなりうまくいくのではないかという話です。意外と効果があるのではないかと思います。
なぜかというと、開発ポータルというものがありますよね。開発ポータルは常に使いづらいものです。そういった時に、インフォメーション・リトリーバー（情報取得システム）のようなものとしてAIを活用するのは非常に向いていると思います。私も顧問先などにこの方法を強く勧めており、いくつかの企業で既に実践されています。
このアプローチでは、正しい学習データは自分たちで用意し、それをAIに学習させます。その結果、日々それに関わる人たちが自分に必要な情報を常に取り出しやすくなるという状況が生まれます。これこそが本当のAI活用ではないかと感じています。
全世界のエンジニア向けのAIサービスを使うのはもちろん良いことですが、自社のチーム、自分自身のためのAIを使っていくというのは、コミュニケーションの問題解決に大きく貢献します。セキュリティという分野も結局はコミュニケーションの問題です。ハッカーのことを考えたくない人にも「こういう脅威があるよ」という情報を取り込んでもらえれば、「なるほど、じゃあ入力値検証を最初にやりましょう」といった具体的な対策につながりやすくなります。
自社向けAIの活用には、例えばFAQや社内サポートのためのチャットボットの裏側にLLMを構築するといった方法があります。そのインターフェースは単純なもので構いません。開発者が一番知りたいことは「この仕様は何がきっかけで、誰の要求なのか」「なぜこうなっているのか」という背景情報です。開発者の責任は「どう実装するか」ですが、「なぜそうするのか」という情報が上から降ってくることが多く、その時に「これは本当に必要なのだろうか」と疑問に思ったり、「誰と調整すればこの部分が最適化できるのか」がわからなかったりします。
例えばリスクプロファイルの中には、コンプライアンスの要件や、デプロイする環境の前提、バージョンの前提など様々な事柄があります。実装するたびにこれらを全部調べて納得するまでのコストは非常に高いです。そこで、こういったドキュメントをAIに学習させ、対話的に納得感を得たり改善提案を素早く作っていくことが可能になるのです。
7.2. セキュリティ観点の育成と組織文化
セキュリティの観点を育成するための方法と組織文化の重要性について、非常に興味深い事例があります。ある質問をいただきました。「セキュリティ上はあまり良くないと言いつつも、OSSの活動をしている人たちはソフトウェアエンジニアの中でも進んでいる方だという想定があります。ということは、世の中的にはそれより下のレベルの人たちがたくさんいる中で、その人たちのレベルをどんどん引き上げていくには、組織の中だったりとか会社外でどういう活動をすればより良くなっていくのか」という質問です。
結局は観点を鍛えるということしかないのかなと思っています。企業内でのソースコードレビューという取り組みはまだ導入していない会社が少なくないと思います。そういうところから始めていくことが重要です。社内での議論を増やし、いろんな観点での意見を増やしていくということがないと難しいでしょう。
リスクコミュニケーションの問題でもあります。やはり「動けば動けばいいじゃん」という考え方は一般的です。正常系で動けばいいという考え方は確かに理解できますが、それしか見ていないことが悪用されてシステムがひっくり返されると悔しいものです。「悪用する方が悪いんじゃないの」というのは確かにその通りですが、それを防ぐためにセキュリティ対策を講じるというのが現実です。
防御的プログラミングとは何か、あるいは誤用されにくい仕組みとは何かということが分かると、結果的に安全とは何かということが分かるようになります。100%の安全はないにしても、「もし例外があったらここで分かるようにしよう」「まだ知らないことがここで分かるようにしよう」という仕組みと、「分かっていることはここで防ごう」というロジックを組み合わせることで進歩することができます。これがなければ、何でやられたのか分からないまま、ただ社長が謝っていて「お前らなんとかしろ」と言われるという状態になりかねません。
観点の問題ではありますが、「そういうことが起こり得ると分かっている人が書いたコードなのかどうか」という点は全く違います。攻撃の種類は無数にあるのに対して、対策は有限です。ソースコードの様式も有限です。「これはどうやらうまくいきそうだ」「この仕組みは防御に役立つ」といった知見は組織に蓄積されていくものです。
興味深い例として、楽天という会社には非常に多くのプロジェクトがあり、セキュリティチームも非常に強力です。セキュリティスキャンや診断を積極的に行っていますが、あるチームはそれほど頻繁に診断を受けていないにもかかわらず、脆弱性や問題点があまり出てこないということがありました。なぜでしょうか？
端的に言えば、そのチームはサービスとそれを使うユーザーのことが大好きなのです。意外かもしれませんが、結局のところ目的を持っているのです。何が毀損されないようにするか、その軸に合わせてシステムを設計し、改善し、運用しています。知識やデプロイ能力、コーディング能力だけでなく、モチベーション、あるいはディレクションが非常に重要なのです。
設計段階の時に、お客さんにとって何が脅威かということ、あるいは自分たちにとって何が脅威かというところをきちんと理解できる、もしくは理解しようというモチベーションが、より良い結果につながっているのです。100点満点のセキュリティはないのですが、そこは死守しようと考え、指摘されたら「ありがとう」と言われるという、意外と重要なことなのかもしれません。
7.3. まとめとメッセージ
今日のセッションのメッセージとしては、開発者にとって考えるのが辛い部分、特に自分のシステムを破壊したり悪用したりする敵を知るためにAIを使うのは有効ですし、それに対応する対応方策をリストアップすることにAIを活用するとかなり良いのではないかということです。引いては、オープンソースソフトウェアそのものも安全になってくれると嬉しいという願いもあります。
このようにAIを活用することで、人間側の能力を上げていくことに使えるでしょう。これは今日の他のスピーカーの方々もおっしゃっていたことだと思います。
基本的に、セキュリティは考えるのが辛い分野です。特に自分のシステムを破壊したり悪用したりする脅威を知ることは精神的にも負担が大きく、それに対応する設計や実装を考えるのも容易ではありません。しかし、AIをアドバイザーとして活用することで、脅威分析やリスク評価、対策の検討が格段に容易になります。
プロンプトを工夫することで、業界固有のリスクやコンプライアンス要件、設計上の考慮点などを効率的に把握することができます。もちろん、AIが生成するコードをそのまま使うのではなく、センスを持って自分の責任で採用することが重要です。
また、自社の情報を学習させた独自のAIモデルを構築することで、プロジェクト固有の情報を活用した開発支援も可能になります。これは特に開発ポータルやドキュメント管理など、情報の取得と整理に関する課題解決に大きく貢献するでしょう。
セキュリティ文化の醸成も重要です。技術的な対策だけでなく、「サービスとユーザーを大好きな」チームのように、システムの目的を理解し、それを守るためのモチベーションを持つことが、結果として優れたセキュリティにつながります。
最終的には、AIはセキュリティの複雑な問題を解決するための強力なツールとなりますが、それを使いこなすのは私たち人間です。AIを活用してセキュリティの観点を強化し、より安全なシステム開発を実現することが、これからの開発者に求められる重要なスキルとなるでしょう。
特にOWASP LLM Top 10のような最新のセキュリティガイドラインを理解し、AIシステム自体のセキュリティも考慮に入れながら、開発プロセス全体でAIを賢く活用していくことが今後ますます重要になっていくと思います。