バグを修正するには「3ステップ」が必要、なぜか：修正時に起きるバグの作り込みをどう考えるか

GitHubのセキュリティ研究者、ケビン・バックハウス氏は同社の公式ブログで、ソフトウェアのバグ修正の際に踏むべきステップを解説した。バグの起きた箇所を修正しなければならないのは当然だが、それ以外にも2ステップの作業が必要だという。

[＠IT]

　GitHub Security Labのセキュリティ研究者、ケビン・バックハウス氏は2021年11月9日（米国時間）、ソフトウェアのバグ、特に、セキュリティ脆弱（ぜいじゃく）性を修正する際に踏むべきステップを解説した。

　同氏は「回帰テストの追加」「バグの修正」「バリアント（亜種）の発見と修正」という3ステップを挙げた。「バグの修正」は当然、必要不可欠だが、なぜ他の2つのステップが重要なのか、なぜこの順序で実行すべきなのかを解説した。

回帰テストの追加

　回帰テストの目的は、同じ誤りを繰り返さないことにある。バグの修正時には同じバグが再発した場合、失敗するように設計した回帰テストを追加する必要がある。なぜだろうか。修正済みのバグのテストを作成するのは、時間の浪費ではないのか。

　時間に追われていると、「現実的に、誰かがこれと全く同じバグを再発させる可能性はどれだけあるのだろうか」と考えて、回帰テストを省略したくなる。だが、回帰テストを追加する理由が3つある。

・バグが修正された証明を残す

　バックハウス氏はバグを修正するコミットの前に、最初のコミットとして回帰テストを追加することを好んでいる。バグが未修正であれば、テストが失敗し、修正されていれば、テストが成功するからだ。修正したかどうかの確認が容易になる。

・コードカバレッジを維持する

　バグ修正では、新しいif条件を追加することが多い。回帰テストは新しいコードがテストされることを保証する。将来、別の開発者が、追加されたif条件の目的が分からないという理由から、if条件を削除したとしよう。すると、回帰テストが失敗する。これによって、このif条件を削除してはならないことが分かる。

・ファジングのサンプルコーパスの改善

　脆弱性などの不具合を発見するファジングツールは大量の入力サンプルのコーパスを使うことで、効果的に機能する。新しい回帰テストを追加するたびに、コーパスの質が向上する。

バリアントの発見と修正

　「回帰テストの追加」「バグの修正」「バリアントの発見と修正」という3ステップについて、誰もが賛同するとは限らない。

　「確認されている問題だけを修正すべきであり、それ以外は何も手を加えてはならない」と考える人々もいる。開発途上のソフトウェアではなく、リリース済みのソフトウェアのバグを修正する場合は、特にそうだ。

　こうした人々は、変更の必要がないコードを変更することで、図らずも新しいバグを引き起こしてしまうことを心配している。だが、こうしたリスクを心配するのは誤りだ。実際には、バグが1つ見つかれば、大抵はその近くに他にもバグがある。コンピュータセキュリティの残念な歴史には、そのことを示す証拠が多々ある。

　それでも、多くのソフトウェアベンダーが、修正を最小限にとどめる方針を堅持しているのは明らかだ。最悪の場合は、バグの根本原因を解決するのではなく、バグの兆候しか修正していない。セキュリティ研究者はこの状況に大きな不満を持っている。

　これらのことを踏まえ、バックハウス氏は、「全てのバグは、防御を高める幾つかの追加的な修正を施す機会をもたらす」と強く考えている。

　同氏はバリアントを発見するための便利なツールとして、GitHubがSemmleを買収して獲得したセマンティックコード解析エンジン「CodeQL」を挙げている。GitHubはCodeQLのコード解析機能をGitHubにネイティブに統合し、提供している。