国家サイバー長官室(ONCD)は最近、新しいレポート「Back to the Building Blocks: A Path Toward Secure and Measurable Software(構成要素に戻る:安全で測定可能なソフトウェアへの道)」を発表しました。このレポートは、新しいONCDディレクターのHarry Coker氏による最初の大きな発表の1つであり、メモリセーフプログラミング言語を採用する理由を強く主張しています。
この新たな焦点は、サイバーセキュリティーの責任をリバランスし、長期的なサイバーセキュリティー投資を優先するインセンティブを再調整するという目標に起因しています。メモリセーフプログラミング言語は、最近、新しいレポートをリリースしたオープンソース・ソフトウェア・セキュリティ・イニシアチブ(OS3I)の目標にも含まれています。
メモリー・バグは、プログラマーがメモリー・アクセスに関する問題を引き起こすコードを作成した場合に発生します。一般的なバグは、バッファオーバーフローとダングリングポインタによって発生します。Rust、Go、Java、Swift、Pythonなどのメモリセーフプログラミング言語を使用すると、開発者はメモリバグの原因となるコードを作成できません。この言語にはメモリーまたはタイプ・セーフティーなどの特定のプロパティーが含まれているためです。開発者がCやC++などの非メモリーセーフ言語でコードを作成すると、メモリー・アクセス・エラーを引き起こす可能性のあるコードを誤って作成する可能性があります。メモリセーフ言語と同様に、コンパイル時やランタイム中にエラーを捕捉するのではなく、バグは最終バージョンにまで浸透し、セキュリティ上の問題を引き起こします。
サイバーセキュリティーの多くは脅威への対応に重点を置いていますが、リスクを軽減するためには、セキュリティー問題の原因となるコード・エラーを減らすプラクティスを実践することから始まります。Googleのレポートによると、重大なセキュリティバグの70%は実際にはメモリの安全性の問題です。CやC++などの広く使用されているプログラミング言語は、特にポインター・エラーに起因する多くの問題の原因となることがよくあります。
メモリーセーフ言語を使用すると、メモリーセーフの脆弱性を大幅に軽減または完全に排除できます。これにより、最終コードのサイバーセキュリティリスクが軽減されます。メモリーセーフ言語はセキュリティーの向上に加えてクラッシュ率も低減するため、開発者はメモリ管理の問題に集中する必要がないため、生産性が向上します。
IBMニュースレター
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
ニュースレターは日本語で配信されます。すべてのニュースレターに登録解除リンクがあります。サブスクリプションの管理や解除はこちらから。詳しくはIBMプライバシー・ステートメントをご覧ください。
メモリバグの削減は多角的なアプローチを必要とする複雑な問題です。このレポートは、組織がメモリセーフ言語に関連する 2 つの特定の領域に重点を置くようにすることを提言しています。さらに、政府機関は技術コミュニティー、特にエンジニアと開発者とのパートナーシップの構築に重点を置き、この重要な変化の実現に向けて協力したいと考えています。
レポートとともに発表されたファクトシートに概説されている2つの主な目標は次のとおりです。
攻撃範囲が小さいほどリスクが低くなります。脆弱性を生み出すコードが一行増えるごとに、攻撃対象領域が拡大していきます。メモリセーフエラーを発生させるミスが1つでもあると、多くの脆弱性が生じる可能性があります。このレポートでは、攻撃対象領域を減らす最も効果的な方法の1つとして、メモリーセーフプログラミング言語の使用を推奨しています。これらの言語を使用することで、プログラマーはメモリのバグによる攻撃対象領域の拡大につながるエラーを防ぐことができます。
絶えず変化するソフトウェアでメトリックを使用することは非常に困難であるため、多くの組織ではソフトウェアのリスクを正確に評価することができません。ソフトウェアの測定可能性は複雑な課題ですが、その変化は、事後対応型から事前対応型へと移行することから始まります。サイバーセキュリティー品質に関するより優れた診断を開発することで、組織はリスクをより正確に特定し、積極的に修正プログラムできるようになります。
組織はメモリセーフ言語を使用すべきと言うのは簡単ですが、現実にはこの移行は複雑さが伴います。多くのソフトウェア・プログラムやライブラリーは、安全でないメモリーセーフ言語に基づいており、コードベース全体を完全に書き換えることは多くの場合、現実的ではありません。
メモリーセーフプログラミング言語を可能な限り使用して、新しいプロジェクトを開始することが、移行を開始する最も簡単な方法です。組織はまた、バッファオーバーフローやダングリング・ポインタの領域を含むメモリセーフバグのリスクが最も高いクリティカルな関数やライブラリのみを書き換えることで、完全な書き換えなしに攻撃対象領域を減らすことも可能です。RustやSwiftなどの一部のメモリーセーフ言語はCおよびC++と相互運用できるため、このアプローチが実現可能です。このアプローチを採用する場合、組織はビルドシステムを統合し、共有オブジェクトとデータ用に新しい言語で抽象化を構築する必要があります。
ただし、この移行には適切な開発者リソースが必要です。組織はまず、現在の開発者チームを評価し、チームがメモリセーフ言語に関してどのような専門知識を現在保持しているかを判断する必要があります。次のステップは、現在の開発者をトレーニングするだけでなく、メモリセーフ言語に熟練している新しい開発者を確保することです。
サイバーセキュリティーへの注目が高まるにつれ、多くの組織は、最も重要なステップが事後対応型のアプローチから事前対応型のアプローチに移行することであることを認識しています。原点に戻って安全なコードの作成に重点を置くことで、組織はリスクを大幅に軽減できます。これは簡単でも迅速でもないプロセスですが、この移行を行うことで得られるメリットは有意義で長続きします。