CおよびC++でのコーディングの中止を連邦政府機関が要請
先月、2つの連邦政府機関がIT業界に対して、CおよびC++のようなメモリー安全でない言語でのアプリケーション開発の中止と、既存のアプリケーションを他言語へ移行するためのロードマップの策定を要請しました。このセキュリティ警告でIBM i アプリケーション開発に大きな影響が及ぶことはなさそうですが、C言語ファミリーは、IBMミッドレンジ サーバーでも、消し去るのが難しい存在感があります。
先月、CISA（サイバーセキュリティ・社会基盤安全保障庁）およびFBI（連邦捜査局）は、CおよびC++のようなメモリー安全でない言語で書かれる新規のアプリケーション開発は直ちに止めるべきだと警告を発しています。また、既存のCおよびC++アプリケーションについては、それらを有する組織がセキュリティ上の脆弱性の緩和に向けてのロードマップを策定する期限も設けており、それを2026年1月1日としています。
「容易に利用可能である、メモリー安全な言語を代わりに使用できるにもかかわらず、メモリー安全でない言語（CやC++など）で、重要インフラまたはNCF（国家重要機能: National Critical Functions）に使用される新たな製品ラインの開発を行うのは危険であり、国家安全保障、国家経済安全保障、国家公衆衛生および安全に対するリスクを著しく高めることになります」と、CISAは「Product Security Bad Practices（製品セキュリティの悪しき慣行）」と題する 10月16日のレポートで記しています。
CおよびC++では、開発者は手動でメモリーを管理する必要があり、そうした操作でミスが生まれることもあることから、CおよびC++はメモリー安全でない言語であると考えられています。
メモリー安全性が連邦政府で取り上げられたのは、これが初めてではありません。2月には、ホワイトハウスのONCD（国家サイバー長官室: Office of the National Cyber Director）が、プログラマーはCおよびC++の使用を止め、メモリー安全な言語および手法を採用するよう呼び掛ける レポートを発表 しています。同レポートによれば、CVE（共通脆弱性識別子: Common Vulnerabilities and Exposures）番号が割り当てられたセキュリティ脆弱性の70%以上は、メモリー安全性の問題に起因するものだということです。
「1988年のMorris Worm、2003年のSlammer Wormサービス妨害攻撃、2014年のHeartbleed脆弱性、および2023年のBLASTPASSエクスプロイト チェーンなど、過去数十年間の重大なサイバーセキュリティ脆弱性の多くは、メモリー安全性の脆弱性によって助長されました」とONCDは記しています。
推奨されるベスト プラクティスは、開発者が、C#、Go、Java、Python、Rust、およびSwiftなどのメモリー安全な言語で開発作業を行うことだと連邦機関は述べています。これらの言語は、開発者の代わりに自動的にメモリーを処理するため、メモリー アクセスに関するセキュリティの問題の大半が回避されます。
CISAは、すべてのソフトウェア開発者に対して、セキュリティの問題を深刻に受け止め、「セキュア バイ デザイン（Secure by Design）」原則を導入するよう推奨しています。これは、重要インフラやNCFに使用されるソフトウェアの開発に携わる開発者であれば、特に留意が必要なことです。
「ソフトウェア製造事業者は、メモリー安全な言語や、メモリー安全性の脆弱性を防止するハードウェア機能を使用するなど、メモリー安全性の脆弱性が入り込むのをシステム的に防止できる環境で、製品の構築を行うべきです」とCISAは記しています。
「ネットワークに接するコードや、暗号化処理のような機密機能を扱うコードなど、重要度の高いコード コンポーネントにおけるメモリー安全性の脆弱性を排除」するための方策を示したロードマップを、組織が作成して公開する期限は、2026年1月1日とされています。この期限は、サポート終了日が2030年1月1日より前とされている製品には適用されません。
C/C++は、IBM i コミュニティで決して幅広く使用されているわけではありませんが、使用している開発者は一定数います。 Fortra 社による「2024 IBM i Marketplace Survey」調査によれば、IBM i のショップの9%は、C++を使用していると回答しています（2023年は11%、2022年は8%でした）。さらに比較してみれば、初めて調査が実施された2016年版の「Marketplace Survey」レポートでは、15.6%のユーザーがC++を使用していると回答していました。
CおよびC++のメモリー安全性の問題が、他のプラットフォームと同様に、IBM i に影響を及ぼすかどうかはよく分かりません。IBM i およびシステム内部コード（SLIC）は、他のプラットフォームでは許されるようなやり方で、プログラマーがメモリーを操作することを許しません。もちろん、メモリーとストレージは単一体として扱われ（単一レベル記憶）、割り当ては、プログラマーではなく、システムによって自動的に処理されます。また、不正なコードが実行されるのを防ぐための防護措置も備えられています。
ミッドレンジのCの支持者として知られているのは、IBM i サーバー向けのハイ アベイラビリティー、メッセージ監視などのユーティリティの開発を手掛ける Shield Advanced Solutions社のオーナー、Chris Hird氏です。Hird氏は30年以上にわたって、IBMミッドレンジ サーバー上でC/C++開発を行ってきましたが、当分、止めるつもりはないということです。
C/C++開発中止の呼び掛けに関する問題点の1つは、多くの場合、代わりとなるものがないことだとHird氏は述べています。たとえば、IBM i オペレーティング システムおよびリレーショナル データベースも含め、多くのオペレーティング システムには、大量のCコードが使用されています。「だからこそ、信頼性が高く、処理が高速（そして安全?）であるのではないのでしょうか」と彼は問い掛けます。
しかし、C/C++のパワーは両刃の剣となり得るとHird氏は認めます。メモリー管理にポインターを使用できることで、開発者にはとてつもないパワーがもたらされますが、使い方を誤ると、思いも寄らない結果が生じることもあると彼は述べています。それに対する解決策は、細心の注意を払い、徹底的にテストを行うことだと彼は述べます。
「Cは、安全でない言語ではありません。プログラマーが不適切にコーディング（ほとんどの場合は意図せずに）することによって安全でなくなるのだと、彼は『 IT Jungle』に述べています。「コーディングは手仕事です。誰でも、どの言語でも、安全でないコードを書いてしまう可能性はありますが、テストおよびコーディング慣行によって、その可能性が最低限に抑えられることが望まれます。」
Hird氏は、彼曰く「業務に最適なツール」であるShield社の製品をCで開発するのを止めるつもりはないようです。「代わりとなる言語を検討し、Cベースのソリューションでテストを行いました」と彼は述べています。「しかし、これまでのところ、Cと同じくらいのパフォーマンスおよび機能を提供する代替言語は見つかっていません。」
連邦政府機関による警告は、少なくともユーザーと接するアプリケーションに関しては、CおよびC++での開発に水を差すことになるのは間違いありません。これらのMicrosoft言語は、他に例を見ない低いレベルでのアクセスがプログラマーに歓迎されていますが、適切に行われないと、まさにそうした非常に低いレベルでデータ アクセスを処理できることこそが、問題を引き起こすことになります。
現存するCおよびC++コードの、C#、Go、Java、Python、Rust、またはSwiftへの移行について言えば、当分は行われるようには思われません。組織は、数十年にわたって、IBMミッドレンジおよびメインフレーム サーバーで稼働している年代物のRPGおよびCOBOLアプリケーションから抜け出そうとしてきましたが、あまり進捗は見られません。
CおよびC++アプリケーションのモダナイズという、こうした新たな呼び掛けによって、おそらく新たな認識や新たなツールおよび手法が生み出されるでしょう。それらは、ドキュメント化されておらず、サポートされなくなっている年代物のコードにはまりこんでいるIBM i およびSystem Zのショップにも恩恵をもたらすでしょう。
