本記事は2020年9月公開の記事「プログラミング言語の脆弱性対策を考える」の続編となります。前回の記事をまだご覧になっていない方はぜひ、この機会にご一読ください。
いま「C言語の脆弱性対策について簡単に教えて」と生成AIに尋ねてみると、弊社SQAT.jpの記事が引用記事として出てきます。前回の記事を公開してからそろそろ５年ぐらいの月日がたつということで、今回は2024年版のプログラミング言語をめぐる状況と、ちょっとした脆弱性対策に関する情報をご紹介します。
2020年から2024年で変わったこと
生成AIの汎用化
2024年の夏、最初の会社の同期20人で5年ぶりに集まりました。その中でコードを業務で書いているメンバーが同じテーブルに集まったとき、最初に出た話題は「生成AIって何使っている？」でした。所属する会社も違い、使っている言語はバラバラ、コードを書く目的や環境、書く頻度もまちまち、利用する生成AIもバラバラなのですが、全員が生成AIを使っていることに少々驚きました。この友人が全員口をそろえて生成AIについて評価していた点は、コードを作るときに最初にかかる時間と手間が圧倒的に削減されるという点です。
これまでは「こういうことを処理するコードを作ろう」と思うと、わかるところは先に大まかに書いたうえで、わからないところや怪しい部分はプログラミング言語のリファレンスをひっくり返し、Webで検索し、情報を集めたうえでコードスニペットを起こし、実際のコードとして動かし…という順で作業していました。一方、生成AIを使う場合はこういったことをやろうと思った時点で足りない部分を生成AIに質問すればスニペットが返ってくる（場合によってはコードブロックが返ってくる）ので、コードづくりの前半部分の悪戦苦闘がかなり軽減されます。
ところが、短所もいくつかあります。まず生成AIサービスが免責事項として常に掲げるように、必ずしも正しい答えが返ってくるわけではない点には理解が必要とされるところです。
引用元をよくみると、古いバージョンの言語に基づいたQ&Aサイトの回答を参照していることもよくありますし、プロンプトに対して素直に答えるという性質上、 プロンプトに入れていない前段処理に対して不整合が発生する内容のスニペットが回答される、といったことはわりと日常茶飯事です。
学習データやプロンプトの入れ方次第では返答されるコードスニペット自体にエラーや脆弱性が含まれる場合もあります。プロンプトに関係のない前後の処理との不整合でエラーが発生したり、他のコードブロックとの兼ね合いでエラーが発生したり、そのエラーが結局脆弱性につながるものだったりという可能性は十分にあります。
また、一般的な商用サービスの生成AIでは入力が学習データに使用されます。つまり自身が入力したデータが流用されるという前提でサービスを利用することになります。このため、自社の知的所有権への配慮や、個人情報や機微情報、場合によっては非公開情報全般への配慮が必要となる点にも注意が必要です。エンタープライズサービスとしてこういったことを回避するサービスもありますが、それ相応の費用が必要となります。
ただ、自前で大規模言語モデル（LLM：Large language Models）をつくるよりも人件費や設備費用などが圧倒的に安価で手軽であるという点では規模の経済性を実感するところはあります。そういった観点から、将来、どの企業でも自社でAIを全く使わないという選択肢はあまりないかと思います。プログラミングに限らずですが、AIとほどよく付き合って効率的に仕事を進めつつ、エラーや脆弱性をきちんと見逃さない仕組みをもって問題を回避していく、
そういう仕事法になっていくかもしれません。
ノーコードとローコード
以前からどちらも存在はしますが、2020年代に入ってからノーコードやローコードといった選択肢が増えてきています。
ノーコード
プログラミングの知識がなくてもアプリケーションを開発できる手法です。専門的なコードを書くことなく、ドラッグ＆ドロップなどのビジュアル操作で簡単にアプリケーション開発ができます。ITの専門スキルがない人でもアイディアをデジタル化できる点が特徴です。小規模なプロジェクトの開発に適しています。
ローコード
最小限のプログラミングでアプリケーションを開発する手法です。基本はビジュアル操作ですが、必要に応じて一部コードを書きます。柔軟性とスピードのバランスが特徴です。
最近だとAWSがローコード構築サービスをリリースした*1のが一例となるでしょう。ノーコードやローコードを使用するメリットとしては、各業務の定義やフロー、プロセスが明確であれば定型業務やバックヤード業務の一部を合理化できることです。効率化することで時間短縮ができ、別のより生産性の高い仕事に人を割り振れるといった副次的な効果も期待できます。ただ、業務の内容が不明確な場合や、業務が日々恣意的な運用をされている場合には大きなメリットを得ることは難しいかもしれません。
ここで脆弱性の話です。実際ノーコードといっても実は補助的にパラメータの入力が必要な場合があります。また、外部とのAPI連携をノーコードの画面から実行するといった構成のノーコード機能を持っているSaaS(Software as a Service)もあります。そして誤ったパラメータの入力で入出力の脆弱性を発生させる可能性がある、APIとのやりとりの詳細はユーザでは見えない（SaaSのサポート担当者は見えるケースが多いようです）ため、誤った接続先に接続していた場合や連携しているAPIになんらかの脆弱性があった場合に切り分けが煩雑になるといったところは懸念材料として頭の片隅に置いたほうが良いでしょう。
ノーコードもローコードも非常に便利です。そのノーコードフロー自体の仕組みやパラメータの動きや連携先のAPIの信頼性などを理解したうえで使えば、劇的に効率化が図れるため、API同様にうまく付き合っていくということが重要になるのではないでしょうか。
プログラミング言語
専門家たちがどのプログラミング言語を使っているかというデータが、毎年Stack Overflowから発表されます。2020年と2024年でどの程度変わったか、比較をしてみましょう。
| 言語 | 2024年 | 2020年 |
| JavaScript | 64.60% | 69.70% |
| HTML/CSS | 54.10% | 62.40% |
| Python | 53% | 41.60% |
| SQL | 47% | 56.90% |
| TypeScript | 43.40% | 28.30% |
| Bash/Shell | 34.20% | 34.80% |
| Java | 30.00% | 38.40% |
| C# | 28.80% | 32.30% |
| C++ | 20% | 20.50% |
| C | 18.70% | 18.20% |
| PHP | 16.90% | 25.80% |
| PowerShell | 14.40% | 注 1) |
| Go | 14.00% | 9.40% |
| Rust | 11.70% | 4.80% |
| Kotlin | 9.90% | 8.00% |
| Dart | 6.00% | 3.70% |
| Ruby | 5.80% | 7.50% |
| Lua | 5.30% | ランク外 |
| Swift | 4.90% | 6.10% |
| Visual Basic | 4.10% | ランク外 |
出典：Stack Overflow Developer Survey2020年版/2024年版より弊社作成
2020年版：https://survey.stackoverflow.co/2020#technology-programming-scripting-and-markup-languages-professional-developers
2024年版：https://survey.stackoverflow.co/2024/technology#most-popular-technologies-language-prof
ここからは2020年と2024年の脆弱性診断結果の比較で目についた点を深堀りしてみたいと思います。
プログラミング言語と適材適所
前述した「専門家たちはどのプログラミング言語を使っているか」というデータの表からもわかるとおり、このWeb大全盛の時代に「PHPを使う」と回答したエンジニアの比率は下がっています。また、BBSecのシステム脆弱性診断結果からもPHPの脆弱性報告件数が減っていることがわかります。米国の脆弱性情報データベースNVDによるとPHPの脆弱性自体の数が減っている*2（2019年が34件に対して2023年は6件）ということも関連があるかと思いますが、診断結果のエビデンスで見かける機会も減っています。
脆弱性の存在するバージョンの使用の検出内訳
（上図：2020年上半期、下図：2024年上半期）
当社が発行するセキュリティレポートでは、半期（6か月）毎にBBsec脆弱性診断の結果を集計・分析。その傾向を探るとともに、セキュリティに関する国内外の動向を分かりやすくお伝えしています。
最新号のダウンロードはこちら。
GitHubでのプルリクエスト（機能追加や改修など、作業内容をレビュー・マージ担当者やその他関係者に通知する機能）の数も2013年をピークにここ数年は5％台半ばでの微増微減を繰り返している状態になっています*3。けれど、現在稼働しているWebサイトのうち75.8％がPHPを使用している*4といわれていることも事実です。また、CMSの代名詞ともいえるWordPressはPHPで開発されているのですが、WordPress 注 2)が全Webサイトの実に43.4％で使用されています*5。つまり、WebサイトのうちPHPを使っているサイトは76％ぐらいあるけれど、半分以上はWordPressとその派生のパッケージが市場シェアを支えているという構造になっています。そのため、実際に動いているサイトのほとんどがPHPであることは間違いないですが、その大半はWordPressで、それ以外のサイトは少数派というのが現状です。
PHPの強みはWeb開発に特化した、可読性が高く学習しやすい言語である点です。小中規模でセキュリティ要件があまり高くないWebサービスやCMSであればPHPで開発するのが一番便利であり、保守性も高いでしょう。一方で、大量のデータの処理・分析が必要なケース、セキュリティへの配慮からバックエンドとフロントエンドを切り離して開発・運用する必要があるケース、パフォーマンスが重視されるケース、マルチデバイス対応が必要なケースなど、PHPでは要件を満たさないケースが出てきていることも事実です。
PHPの市場をけん引しているCMSでも、「ヘッドレスCMS」と呼ばれるタイプなど、これまでとは異なるCMSへの需要が伸びているといわれています。今後は、旧来のCMSや中小規模のWebサイトはそのままPHP、マルチデバイスやパフォーマンス、バックエンドへの特殊な処理要件やセキュリティ要件などがある場合は別の言語といった形で、さらにすみわけが進んでいくのかもしれません。そういった意味でも “WebならPHP” という時代から、”適材適所でWeb開発も言語を選ぶ” 時代になってきたといえるでしょう。
2024年のC言語
C言語系統で開発というと「2024年でもまだ？」という声が上がりそうなところですが、実際C言語系統はOSまわりでいまだに健在です 注 3)。また古いプログラム（コード、ドライバなど）で互換性が保証される場合はそのまま利用されているケースもあるといわれています。つまりは、C言語系統の言語が抱える根本的な問題、メモリハンドリング（メモリの使い方の変化に伴うメモリエラーを適切に処理する能力）関連の問題もいまだにそこかしこで健在しています。この問題が特に注目を集めたのが、昨今のCrowdStrike Falconのエラーを含んだパターンファイルの配布によるBSOD（Blue Screen of Death）の大量発生です。
関連情報
弊社では、10月16日（水）に開催予定のウェビナーのオープニングセッションとして、「10分でわかるCrowdStrike障害」を取り扱います。ご関心がおありでしたらぜひお申込みください。詳細はこちら。
この問題で再び脚光を（よくない形で）浴びたのがC系統言語の問題です。NULLポインタ参照は、現代の脆弱性の考え方からいうと非常に危険な脆弱性を発生させる原因の一つになります。これらすべての原因は以前にもご紹介した通り、メモリハンドリングを行う言語であるがゆえに発生することです。メモリまわりの脆弱性（元をたどればバグ）の発生頻度を、プログラミング言語自体を変えることで抑えたいと思っている人は多数いて、その結果、よりメモリハンドリング関連の問題が少ないRustへの移行を行うという動きが出てきています。最初期の例としてはMozilla ServoのレンダリングエンジンがC++からRustに書き換えられたもの*6が挙げられるでしょう。Microsoftも、OSの一部をRustに書き換えることについて2022年～2023年に言及しています。
最近ではGoogle AndroidがドライバのRustへの置き換えが順調である旨をブログで発表*7しています。また、DARPA（アメリカ国防高等研究計画局）ではC/C++をRustに置き換えるためのプログラム「TRACTOR」で大規模言語モデルを利用した置き換えを行うことを発表*8しています。TRACTORほど大規模ではなくても、CからRustへの移行ツールがGitHubコミュニティで活発に開発されています。もちろんRustへ移行すれば即座に完全にメモリハンドリングの問題から100％解放されるわけではありません。また、C言語系統のプログラムの置き換え先がRustしかないわけでもありません。ですが、現在進行しているRustへの置き換えはC言語しかなかった時代の最後にして最大の遺産であり、OS周りのC言語依存からの脱却への一歩となることでしょう。
注：
1) 2020年版はBash/Shell/PowerShellが1つにまとめられているため、PowerShell個別のデータはなし。
2) WordPressはWordPress本体よりもそのプラグインの脆弱性が多く報告されています。また、WordPress専用の脆弱性・マルウェアスキャナはたくさんありますが、2024年9月にはWordPressのコミュニティへの投稿でスキャナ検出ができないマルウェアがあるといった旨の投稿があるなど、その市場シェアを狙った動きも伺えます。こうした動きについては最新の情報を追うなどし、対策の実施を検討されることをおすすめします。
参考：https://wordpress.org/support/topic/new-malware-found-in-wordpress-installations-hidden-admin-users-redirects-and/#post-18010647
3) Windows OSに限らず、多くのOSはC言語系統の言語をOSの開発に使用しています。Windowsの場合はCとC++が使用されています。ここにCrowdStrike FalconはC言語系統で書かれたセンサーとパターンファイルを使用してマルウェアや侵害行為の検出をしています。セキュリティ製品あるあるで、センサー自身がシステムブート時に読み込み必須なドライバとなっています。BSOD大量発生の件は、CrowdStrikeのQAプロセスが不十分だったことが大きな原因ではありますが、パターンファイルに不整合がありメモリの境界外読み取りエラーを発生させました。センサーはシステムブート時に読み込み必須なドライバとなっているため、Windows OS起動時にCrowdStrike Falconのセンサーを起動する必要がありましたが、問題のパターンファイルが境界外読み取りエラーを発生させたため、問題のパターンファイルがインストールされたすべてのWindowsマシンがブートできず、ブルースクリーンを表示するだけの箱/板になってしまう状況に陥りました。これが2024年7月にニュースになったインシデントの概要です。
参考：https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf
Security Report TOPに戻る
TOP-更新情報に戻る
サイバーインシデント緊急対応
