ソフトウェアのバグ

新しいプログラミング言語は、既存の言語の脆弱性に基づく一般的なバグを防止するように設計される傾向があります。BASICやCなどの古い言語から得られた教訓は、C #やRustなどの後発の言語の設計に役立てられています。

コンパイル言語では、実行時前に（例えば、識別子のスペルミスなど）一部のタイプミスを検出できるため、インタプリタ言語よりもソフトウェア開発プロセスの早い段階で検出が可能になります。

言語には、静的型システム、制限された名前空間、モジュール型プログラミングなどの機能が含まれる場合があります。たとえば、型付きコンパイル言語（C言語など）の場合：

float num = "3";

構文的には正しいが、右辺が文字列であるため、float型の変数に代入できず、型チェックに失敗する。コンパイルエラーが発生するため、開発を再開するにはこの欠陥を修正する必要がある。インタプリタ型言語の場合、このエラーはステートメントが実行されるまで（実行時であればずっと後）発生しない。

一部のプログラミング言語は、バグが発生しやすい機能をあえて排除することで、パフォーマンスの低下を招いています。これは、複雑でバグの多いコードを書くよりも、シンプルで遅くても正しいコードを書く方が一般的に優れているという考えに基づいています。例えば、Javaはポインタ演算をサポートしていません。ポインタ演算は非常に高速ですが、慎重に使用しないとメモリ破損やセグメンテーション違反を引き起こす可能性があります。

一部のプログラミング言語には、一般的なバグを防ぐために実行時オーバーヘッドを追加する機能が含まれています。例えば、多くの言語には実行時境界チェック機能や、境界外エラーが発生した場合にクラッシュするのではなく回復する仕組みが備わっています。

スタイルガイドラインと防御的なプログラミングによって、見落としやすいタイプミス（誤植）を防ぐことができます。

例えば、ほとんどのC系プログラミング言語では、命令が1つしかない場合、命令ブロックを囲む中括弧を省略できます。次のコードは、条件が真のfoo場合にのみ関数を実行しますcondition。

条件が満たされた場合 foo();

しかし、このコードは常に実行されますfoo。

条件を満たす場合 foo();

括弧を使用することで、厳密には必須ではない場合でも、このエラーを確実に防ぐことができます。

if (条件) { foo(); }

規約の遵守は、手動（コードレビューなど）で行うことも、リンターなどの自動ツールで行うこともできます。

プログラムの意図する動作を記述したプログラム仕様書を作成することで、バグを防ぐことができると主張する人もいる。しかし、組み合わせ爆発や不確定性の問題があるため、形式仕様書は最短のプログラム以外には実用的ではないと主張する人もいる。

ソフトウェアテストの目的の一つはバグを見つけることです。テスト中の測定によって、残っている可能性のあるバグの数を推定できます。製品のテストと開発期間が長くなるほど、この推定の信頼性は高まります。^{[ 22 ]}

アジャイルソフトウェア開発では、比較的小規模な変更を頻繁に行うソフトウェアリリースが一般的です。欠陥はユーザーからのフィードバックによって明らかになります。

テスト駆動開発（TDD）では、本番コードを作成する際に同時に単体テストも作成され、すべてのテストが作成され、正常に完了するまで本番コードは完成したとはみなされません。

静的コード解析ツールは、コンパイラの能力を超えてプログラムテキストを検査し、潜在的な問題を特定することで、開発者を支援します。一般的に、仕様に基づいてすべてのプログラミングエラーを見つけるという問題は解決不可能ですが（停止問題を参照）、これらのツールは、人間のプログラマーがソフトウェアを作成する際に特定の種類の単純なミスを犯しやすいという事実を利用しています。

ソフトウェアの実行中にパフォーマンスを監視するツールは、ボトルネックなどの問題を特定したり、正しく動作していることを確認したりするために、コードに明示的に組み込むことも（例えば、単に `.` という文を記述するだけで済む場合もあるPRINT "I AM HERE"）、ツールとして提供することもできます。処理時間の大部分が特定のコードによって費やされていることに気づいて驚くこともよくあり、こうした前提を取り除くことで、コードの書き直しが必要になる場合もあります。

オープンソース開発では、誰でもソースコードを検証できます。エリック・S・レイモンドが「リーナスの法則」として広めた考え方では、人気のあるオープンソースソフトウェアは、他のソフトウェアよりもバグが少ないかまったくない可能性が高いとされています。なぜなら、「十分な数の目があれば、すべてのバグは浅いものになる」からです。^{[ 23 ]}しかし、この主張には異論があります。コンピュータセキュリティ専門家のエリアス・レヴィは、「複雑で理解されにくく、文書化されていないソースコードに脆弱性を隠すのは簡単だ」と書いています。なぜなら、「たとえ人々がコードをレビューしていたとしても、それが彼らがそうする資格を持っていることを意味するわけではない」からです。^{[ 24 ]}オープンソースソフトウェアのバグの例として、2008年のDebianのOpenSSLの脆弱性があります。

深刻度は、バグがもたらす影響の尺度です。^{[ 30 ]}この影響には、データ損失、金銭的損失、信用の喪失、無駄な労力などが含まれます。深刻度レベルは標準化されておらず、業界や追跡ツールなどのコンテキストによって異なります。たとえば、ビデオゲームのクラッシュは、銀行サーバーのクラッシュとは異なる影響をもたらします。深刻度レベルの説明の例としては、クラッシュまたはハング、回避策なし（ユーザーがタスクを完了できない）、回避策あり（ユーザーはタスクを完了できる）、視覚的欠陥（たとえばスペルミス）、ドキュメントエラーなどがあります。深刻度の別の例としては、重大、高、低、ブロッカー、些細などがあります。^{[ 31 ]}バグの深刻度は、修正の優先度と同じカテゴリである場合もあれば、2つを別々に定量化して管理する場合もあります。

製品のリリースを遅らせるほど深刻なバグは、ショーストッパーと呼ばれる。^{[ 32 ] [ 33 ]}

優先度とは、他のバグとの関連において、そのバグを解決することの重要性を表すものです。優先度は、1から5などの数値で表される場合もあれば、重大、高、低、延期といった名称で表される場合もあります。優先度は異なる側面ではありますが、その値は深刻度評価と類似または同一である可能性があります。

優先度は、バグの深刻度と修正に必要な労力の組み合わせによって決まる場合があります。深刻度は低いものの修正が容易なバグは、深刻度が中程度でも修正にかなりの労力を要するバグよりも優先度が高くなる可能性があります。

優先度の高いバグは、それを修正するための特別なリリースが必要となる場合があります。このようなリリースは、パッチと呼ばれることもあります。

バグ修正を重視したソフトウェアリリースは、新機能やその他の変更を重視したリリースと区別するために、メンテナンスリリースと呼ばれることがある。

既知の低優先度バグやその他の問題を抱えたままソフトウェアをリリースすることはよくあることです。考えられる理由としては、以下のようなものが挙げられますが、これらに限定されるものではありません。

• 期限を守らなければならないが、期限までにすべてのバグを修正するにはリソースが不足している^{[ 34 ]。}
• このバグは既に今後のリリースで修正されており、優先度は高くありません。
• 一部のユーザーが既存のバグのある動作に依存していることが疑われる、あるいは既に判明している場合があり、提案された修正によって互換性が損なわれる可能性があります。
• 問題は、今後のリリースで廃止される領域にあるため、修正する必要はありません。
• 「これはバグではなく、機能です」^{[ 35 ]}期待される動作と実際の動作、または文書化されていない機能の間には誤解が存在​​します。

ソフトウェアのバグが引き起こす損害の量と種類は、ソフトウェアの品質に関する意思決定、プロセス、およびポリシーに影響を与えます。有人宇宙飛行、航空、原子力発電、医療、公共交通機関、自動車安全などの分野では、ソフトウェアの欠陥が人身傷害や死亡事故につながる可能性があるため、例えばオンラインショッピングサイトなどと比べて、はるかに厳格な検査と品質管理が行われます。銀行業務のように、ソフトウェアの欠陥が銀行や顧客に深刻な金銭的損害を与える可能性がある分野でも、例えば写真編集アプリケーションなどと比べて、品質管理はより重要になります。

バグによる損害以外にも、バグの修正に費やされる労力がコストの一部を占めています。1978年にLientzらは、プロジェクトの平均が開発労力の17%をバグ修正に費やしていることを示しました。^{[ 36 ]} 2020年のGitHubリポジトリに関する調査では、平均が20%であることが示されました。^{[ 37 ]}

バグは、仕様に基づいた設計が不十分または不正確であることに起因する場合があります。例えば、仕様が単語リストをアルファベット順に並べることである場合、設計で記号が考慮されていないと、記号を含む単語が正しくアルファベット順に並べられないという設計上のバグが発生する可能性があります。

Numerical operations can result in unexpected output, slow processing, or crashing.^[46] Such a bug can be from a lack of awareness of the qualities of the data storage such as a loss of precision due to rounding, numerically unstable algorithms, arithmetic overflow and underflow, or from lack of awareness of how calculations are handled by different software coding languages such as division by zero which in some languages may throw an exception, and in others may return a special value such as NaN or infinity.

A control flow bug, or logic error, is characterized by code that does not fail with an error, but does not have the expected behavior, such as infinite looping, infinite recursion, incorrect comparison in a conditional such as using the wrong comparison operator, and the off-by-one error.

• Incorrect API usage.
• Incorrect protocol implementation.
• Incorrect hardware handling.
• Incorrect assumptions of a particular platform.
• Incompatible systems. A new API or communications protocol may seem to work when two systems use different versions, but errors may occur when a function or feature implemented in one version is changed or missing in another. In production systems which must run continually, shutting down the entire system for a major update may not be possible, such as in the telecommunication industry^[47] or the internet.^[48][49][50] In this case, smaller segments of a large system are upgraded individually, to minimize disruption to a large network. However, some sections could be overlooked and not upgraded, and cause compatibility errors that may be difficult to find and repair.
• Incorrect code annotations.

• Deadlock– a task cannot continue until a second finishes, but at the same time, the second cannot continue until the first finishes.
• Race condition– multiple simultaneous tasks compete for resources.
• Errors in critical sections, mutual exclusions, and other features of concurrent processing. Time-of-check to time-of-use (TOCTOU) is a form of unprotected critical section.

• Null pointer dereference.
• Using an uninitialized variable.
• 本来有効な命令を誤ったデータ型に使用している（パック10進数／バイナリ符号化10進数を参照）。
• アクセス違反。
• リソースリークとは、有限なシステムリソース（メモリやファイルハンドルなど）が、解放されずに繰り返し割り当てられることで枯渇してしまう現象のことです。
• バッファオーバーフローとは、プログラムが割り当てられたストレージの末尾を超えてデータを格納しようとする現象です。これはアクセス違反やストレージ違反につながる場合もあれば、そうでない場合もあります。これらはしばしばセキュリティ上のバグとなります。
• 論理的には正しいものの、スタックオーバーフローを引き起こす過剰な再帰。
• 解放後使用エラーとは、システムが参照するメモリを解放した後に、ポインタが使用されてしまうエラーのことです。
• ダブルフリーエラー。

• トークンの誤用、例えば等価性テストの代わりに代入を行うといった場合。例えば、一部の言語では、x=5は x の値を 5 に設定しますが、x==5は x が現在 5 であるか、他の数値であるかをチェックします。インタプリタ型言語では、このようなコードはエラーになります。コンパイル型言語では、テスト開始前にこのようなエラーを検出できます。

• 未伝播の更新：例えば、プログラマーが「myAdd」を変更したが、同じアルゴリズムを使用する「mySubtract」の変更を忘れた場合など。これらのエラーは、「Don't Repeat Yourself（繰り返しを避ける）」の原則によって軽減されます。
• コメントが古かったり間違っていたりする：多くのプログラマーは、コメントがコードを正確に説明していると思い込んでいる。
• ドキュメントと製品の違い。

ニュー・アメリカ^という団体が運営するオープン・テクノロジー・インスティテュート[51]は、2016^年8月に「システムのバグ」という報告書を発表し、米国の政策立案者は研究者がソフトウェアのバグを特定して対処できるよう改革を行うべきだと述べた。この報告書は「ソフトウェアの脆弱性の発見と開示の分野における改革の必要性を強調している」^{[ 52 ]} 。報告書の著者の1人は、議会はサイバーセキュリティというより大きな問題に対処するために多くの法案を可決したが、サイバーソフトウェアの脆弱性に対処するには十分なことをしていないと述べた^{[ 52 ] 。}

政府の研究者、企業、サイバーセキュリティの専門家が、通常ソフトウェアの欠陥を発見する人々である。報告書は、コンピュータ犯罪法と著作権法の改革を求めている。^{[ 52 ]}

報告書によると、コンピュータ詐欺および濫用法、デジタルミレニアム著作権法、電子通信プライバシー法は、セキュリティ研究者が正当なセキュリティ研究を行う際に日常的に行う行為を犯罪化し、民事罰を科すものである。^{[ 52 ]}