脆弱性の少ないソフトウェアを手に入れる方法は？

自社が使っているソフトウェアには必ず脆弱性が含まれていると言ってよいだろう。この問題を解決するにはどうすればよいのだろうか。

[David Jones，Cybersecurity Dive]

　健康を保つには予防医学の普及が一番だと言われている。不健康な生活習慣や食生活を改善することで病気になる確率を下げられる。

　サイバー防衛も同じだ。攻撃者が脆弱（ぜいじゃく）性を突いてくるのなら、そもそも脆弱性が少ないソフトウェアを使えばよい。

脆弱性が少ないソフトウェアを手にするには

　では、どうすれば脆弱性の少ないソフトウェアを手に入れることができるのだろうか。

　「急がば回れ」だ。誤って脆弱性を埋め込んでしまうことが少ない道具、つまりプログラミング言語をソフトウェア開発者が使うように促せばよい。特にメモリ安全性が高い言語の採用が望ましい。

　だが、現実はそうなっていない。連邦捜査局（FBI）とアメリカ合衆国サイバーセキュリティ・社会基盤安全保障庁（CISA）が2024年6月26日に発表した報告書によると（注1）、重要なオープンソースプロジェクトの半数以上で、メモリ安全性の低い言語が用いられていた。

　最大規模のプロジェクトであってもメモリ安全性の低い言語に依存しているという。この報告書は、Open Source Security Foundationのクリティカルプロジェクト・ワーキンググループが、合計172件の重要なプロジェクトを分析して作成したものだ。

　最も大きな10件のプロジェクトにおいて、メモリ安全性の低い言語が使用されている割合の中央値は62.5％だった。10件のうち4件は、コードの94％以上にメモリ安全性の低い言語が使われていた。

メモリ安全性が高いとはどのような意味だろうか

　メモリ安全性が高いプログラミング言語として「Java」や「C#」「Python」「Swift」「Ruby」「Rust」「Go」などが使われている。

　サイバー攻撃とメモリ安全性の議論でよく言及されるのはバッファオーバーフローだ。プログラムが動作する際にバッファ領域や配列に割り当てられたメモリを利用することがある。このとき、割り当てを超えたデータを書き込むと、バッファオーバーフローが起こる。メモリ安全性が高くないプログラミング言語を利用していると、誠実な開発者であっても、バッファオーバーフローを起こすソフトウェアを作り出してしまうことがある。バッファオーバーフローを利用して悪意のあるコードを実行する攻撃は珍しくないため、これだけでもメモリ安全性の高い言語を利用する理由になる。

　なお、メモリ安全性が高い言語は次のような機能を備えている。

自動ガベージコレクション　言語ランタイムによって使用されていないメモリ領域を自動的に解放する。メモリリークを防ぐ働きがある。参照カウントを使用してメモリがアクティブに使用されているかどうかを追跡することでメモリを自動的に解放する言語もある。

メモリ安全なデータ型　バッファオーバーフローを防ぐために、安全なデータ型と境界チェックが提供されている言語がある。これらの型を使うと、割り当てられたメモリを超える書き込みが許されない。

厳格な型チェック　コンパイル時に厳密な型チェックを実行することでメモリ参照エラーを検出できるため、実行時のエラーを回避できる。

並行性とメモリ安全性　ロックやアトミック操作、トランザクションメモリなどの機能が組み込まれた言語がある。複数のスレッドが安全にメモリにアクセスできるようになる。（キーマンズネット編集部）

これは実現可能なのだろうか

　連邦政府関係者はオープンソースコミュニティーやソフトウェア業界に対し、「C」や「C++」などのメモリ安全性の低い言語の使用を段階的に廃止するよう積極的に働きかけてきた。これらの言語には、悪質な脅威集団による悪用につながる重大なセキュリティ脆弱性を生み出しやすいと考えられている。

　CISAのジョン・イースタリー氏（ディレクター）は2023年に業界に対して、セキュア・バイ・デザインの開発慣行を取り入れるための努力の一環として、ソフトウェアや他の技術製品が攻撃者に対して脆弱でなくなるように、メモリ安全性の高いプログラミング言語への移行を呼びかけた（注2）。

　2024年2月には、SAPやHewlett Packard Enterprise、Palantirなどの大手テクノロジー企業が、メモリ安全性の高いコードの採用を目指すホワイトハウス（米連邦政府）の取り組みを支持した（注3）。

　サイバーセキュリティ事業を営むSynopsys Software Integrity Groupのティム・マッキー氏（ソフトウェアサプライチェーンリスク戦略の責任者）は次のようにまとめた。

　「メモリ安全性の高い言語が、欠陥の少ないコードを生成することに議論の余地はない。問題は開発チームがしばしばメモリ安全性の低い言語に精通していることだ。また、特定のソフトウェアがメモリ安全性の低いライブラリに依存している場合もある」

　ユーザー企業がもう少し積極的にメモリ安全性の問題を進めることもできる。メモリ安全性の高いプログラミング言語を使うことを開発の条件にできる場合があるからだ。

出典：Memory-unsafe code runs rampant in critical open-source projects（Cybersecurity Dive）
注1：Exploring Memory Safety in Critical Open Source Projects（CISA）
注2：Shift to secure-by-design must start at university level, CISA director says（Cybersecurity Dive）
注3：White House rallies industry support for memory safe programming（Cybersecurity Dive）