ソフトウェアの脆弱性

コンピュータプログラミングとソフトウェアエンジニアリングにおいて、ソフトウェアの脆弱性とは、信頼性があるように見えても、異常なデータや一見些細な方法で変更されたデータを提示されたときに機能しなくなる古いソフトウェアの修復が困難になることを指します。このフレーズは、金属加工における脆弱性との類似性から派生したものです。^[1]

ソフトウェアが新しいときは、非常に柔軟性が高く、実装者が望むように形を変えることができます。しかし、特定のプロジェクトのソフトウェアがどんどん大きくなり、ソフトウェアを長年使い慣れたユーザー層が拡大するにつれて、柔軟性はどんどん低下します。加工硬化した金属のように、ソフトウェアはレガシー システムとなり、もろくなり、システム全体を破壊せずには簡単に保守できなくなります。 ^[要出典]

ソフトウェアの脆弱性は、入力データの全範囲に対して適切に機能しない アルゴリズムによって発生する可能性があります。次に例をいくつか示します。

• 良い例としては、ゼロ除算を許すアルゴリズムや、フィッティングされたデータを超えて外挿するために使用される曲線 フィッティング方程式が挙げられます。脆弱性のもう 1 つの原因は、値を制限するデータ構造の使用です。これは、ソフトウェアに2 桁の年エントリしか入力できないことに人々が気づいた 1990 年代後半によく見られました。これにより、2000 年までに大量の脆弱なソフトウェアが突然更新されました。^[2]
• もう 1 つのよく見られる脆弱性は、無効な仮定を行うグラフィカル ユーザー インターフェイスです。たとえば、ユーザーが低解像度のディスプレイで実行している場合、ソフトウェアがディスプレイに収まらないほど大きなウィンドウを開くことがあります。逆の場合もあり得ます。つまり、ウィンドウがディスプレイに対して小さすぎてサイズ変更ができない場合や、開発者の解像度に関する仮定が当てはまらなくなったために要素が正しく収まらないウィンドウなどです。もう 1 つの一般的な問題は、ユーザーが既定以外の配色を使用したためにテキストが背景と同じ色でレンダリングされた場合や、ユーザーが既定以外のフォントを使用したために許可されたスペースに収まらず、説明やラベルが途切れた場合に発生します。

多くの場合、古いコードベースは単に放棄され、ゼロから作成されたまったく新しいコードベース（レガシー システムの多くの負担から解放されることを目的とした、つまり書き換え）に置き換えられますが、これはコストがかかり、時間のかかるプロセスになる可能性があります。

ソフトウェアの脆弱性の例と理由をいくつか挙げます。

• ユーザーは比較的一定のユーザー インターフェイスを期待しています。機能が実装され、ユーザーに公開されると、その機能が適切に設計されていなかったり、その機能の存在がそれ以上の進歩を妨げている場合でも、その機能に対する大きな変更をユーザーに受け入れてもらうのは非常に困難です。
• 大量のドキュメントに現在の動作が記述されている可能性があり、変更にはコストがかかります。さらに、既存のドキュメントのコピーをすべて思い出すことは基本的に不可能であるため、ユーザーは古いマニュアルを参照し続ける可能性が高くなります。
• ソフトウェアの複雑な詳細をすべて知っていた元の実装者は別の道を歩み、その複雑な詳細に関する十分な文書を残しませんでした。そのような詳細の多くは、設計チームの口承によってのみ他の人に伝えられ、その多くは最終的に回復不能に失われますが、いくつかはソフトウェア考古学の熱心な（そして高価な）適用によって再発見される可能性があります。
• おそらく、パッチは長年にわたって発行され、ソフトウェアの動作を微妙に変更してきました。多くの場合、これらのパッチは、発行された明白な障害を修正する一方で、システムに他のより微妙な障害をもたらします。回帰テストで検出されなければ、これらの微妙な障害によって、その後のシステム変更が困難になります。
• より微妙な形の脆弱性は、人工知能システムでよく発生します。これらのシステムは、入力データに関する重要な仮定に依存することがよくあります。これらの仮定が満たされない場合 (おそらく明示されていなかったため (よくあることですが))、システムはまったく予測できない方法で応答します。
• コンポーネントの依存関係が厳しすぎると、システムが脆弱になることもあります。その一例は、依存関係の新しいバージョンへの移行の難しさです。あるコンポーネントが別のコンポーネントに特定の範囲の値のみを出力することを期待していて、その範囲が変わると、ビルド (コンパイル) 中または実行時にシステム全体にエラーが波及する可能性があります。^[要出典]
• システム開発ライフサイクル（SDLC）の観点から見ると、開発中よりもメンテナンス中のほうが、変更をサポートするために利用できる技術リソースが少なくなります（^{[引用が必要]}）。

• 脆弱なシステム
• ソフトウェアエントロピー
• ソフトウェアの腐敗
• 堅牢性（コンピュータサイエンス）

• Robert E. Filman、Tzilla Elrad、Siobhán Clarke、Mehmet Aksit (2004)。アスペクト指向依存性管理。Addison Wesley Professional。ISBN 0-321-21976-72013年1月30日時点のオリジナルよりアーカイブ。
• Virginia Postrel (1999)。「パワーファンタジー: Y2K バグの奇妙な魅力 - 2000 年移行問題」。Reason。2005年9 月 10 日にオリジナルからアーカイブ。2008年 7 月 25 日に取得。