C++ 約2分

C++がCrowdStrikeの大規模障害のせいにされるのは当然だった

Share this article
C++がCrowdStrikeの大規模障害のせいにされるのは当然だった

先週の金曜日、銀行、空港、テレビ局、医療機関、ホテル、その他多数の企業が広範囲のIT障害を経験し、世界中のWindowsマシンでエラーが発生したことで、フライトの欠航や広範な混乱が生じました。私たちは 記事 で、まもなく誰かがこの件でC++を非難するだろうと書きましたが、まさにそれが起きています。 こちら

でご確認いただけます。

仮にすべての重要なシステムがJavaやC#で開発されていたとしたら、それらのシステムは必ず安全だったでしょうか?Herb Sutterがこの 詳細な記事で説明したように、答えはノーです。

しかし誤解もありました。プログラミング言語の安全性に業界の主要なセキュリティ・安全性問題としてあまりに狭く焦点を当てることもその1つです。実際はそうではありません。最近最も被害の大きかったセキュリティ侵害の多くは、メモリ安全言語で書かれたコードで発生したか(例: Log4j)、プログラミング言語とは無関係でした(例: 公開GitHubリポジトリに保存されたKubernetes Secrets)。

Herb Sutterが指摘したように、2023年の最も危険なソフトウェア脆弱性トップ10のほとんどは、メモリ安全性とは関係ありませんでした。

2023年の「最も危険なソフトウェア脆弱性」トップ10のほとんどはメモリ安全性と関係ありませんでした。2023年の大規模なデータ侵害やその他のサイバー攻撃、サイバー犯罪の多くは、プログラミング言語とはまったく関係がありませんでした。

ソフトウェアバグの蔓延をC++のせいにするのは、ソフトウェア開発のより広いコンテキストを見落とした単純な見方です。C++は高度な制御とパフォーマンスを提供しますが、落とし穴を避けるには慎重で熟練した使用が必要です。同じことはどのプログラミング言語にも言え、それぞれに独自の課題と潜在的な問題があります。

最終的に、ソフトウェア品質の責任は開発者、テスター、開発プロセス自体にあります。適切な教育、厳格なテスト、ベストプラクティスの遵守を重視することで、C++を含むあらゆるプログラミング言語に関連する多くのリスクを軽減できます。ツールを悪者にするのではなく、信頼性が高く安全で効率的なソフトウェアを作るために、その使い方を改善することに焦点を当てるべきです。

Share this article