（この記事は、開発元Parasoft社 Blog 「Application Security IS a Quality Problem: 6 Testing Tips to Benefit Both Quality and Security」2017年10月5日の翻訳記事です。）
先日、私はLinkedInで、誰かがいくつかの静的分析セキュリティベンダーの違いについて質問しているのを見ました。ある人が (意外なことではありませんが、ベンダーの人です) 他のベンダーは品質とセキュリティに重点を置いている一方で、自分のところのソリューションは厳密にセキュリティに特化しているため、より優れていると回答していました。
もちろん、これはおかしな発言です。おそらく、このような考え方は、現在、業界に蔓延しているアプリケーションセキュリティに関する問題を示しているでしょう。たとえば、SDLCの残りの部分（開発とテストの両方）から完全に分離したセキュリティ対策チームを運営しようとする企業があるといった問題です。このモデルでは、セキュリティチームが独自のテスト (多くはアプリケーションを破壊しようとするテスト) を実行し、見つかったセキュリティバグを開発チームに返します。言い換えれば、テストによってコードのセキュリティを確保しようとしています。これがテストによってコードの品質を確保するのと同じくらい徒労であることは、断言できます。
確かに、この種のセキュリティテストは必要ですが、それだけでは十分ではありません。ソフトウェアを破壊するテストも確かに有用ですが、セキュリティを向上させる方法として、それだけに依存すると、遅すぎる時点でエラーが発見され、結果的になかったことにされてしまいます。特に、不適切なフレームワークやアルゴリズムなどの根本的な問題は、コードの書き直しかリリースかで葛藤したあげく、スケジュールが優先されるため、不都合な問題として隠蔽されます。
先ほどのLinkedinのコメントでは、ベンダーは、自社のソフトウェアのほうが何らかの点で優れていると主張することによって、無邪気な見込み顧客を惑わせようとしています。私は特定のツールベンダーをあげつらいたいわけではありません。自分だってツールベンダーの一員であるわけですから。しかし、このような悪徳セールスマンめいた、仮想敵を作り上げるような議論には納得できません。この場合、そのベンダーの製品には本当に興味深いユニークな機能があるのかもしれませんが、後に残るのは、何かよくわからないが、セキュリティと品質は違うものらしいという印象です。それによってアプリケーションのセキュリティに対する理解が低下し、安全性が低下します。
セキュリティは品質として扱われなければならず、品質は成熟したエンジニアリングプラクティスに基づいていなければなりません。なぜなら、品質に問題がある場合、セキュリティの問題があるからです。研究によると、セキュリティ上の欠陥の50〜70％が品質の欠陥であることが明らかにされています。言い換えれば、従来からある品質バグが、侵入者/ハッカー/悪意のあるユーザーがアプリケーションに侵入するために使用する脆弱性になっているということです（これらを「 ゼロデイ 」と呼びます）。
「研究者たちの一致した見解では、よくあるソフトウェアの脆弱性の少なくとも半分、おそらく70％以上が、より良いソフトウェアを書くことによって防止できる基本的なコード品質の問題です。たとえば、ずさんなコーディング 」
– Jim Bird “Building Real Software”
品質とセキュリティがどれほど重なっているか、まだ理解できないという方は、 CWE Top 25のいくつかの例を見てください。次のセキュリティ上の問題は、 CWEテクニカルインパクト から抜粋したもの です。
- ＃3 CWE 120 – 入力のサイズを確認しないバッファコピー（ “古典的バッファオーバーフロー”） – 許可されていないコードやコマンドの実行、許可されていないデータアクセス、DoS（ Denial-of-Service ）
- ＃20 CWE 131 – 不適切なバッファサイズの計算（バッファオーバーフローにつながる） – DoSの可能性、不正なコードまたはコマンドの実行、認可されていないメモリ読み取り/変更の可能性
- ＃25 CWE 190 – 整数オーバーフローまたはラップアラウンド（未定義の動作、したがってクラッシュ） – DoSの可能性、メモリ変更の可能性、認可されていないコードまたはコマンドの実行、任意のコード実行の可能性
CWEの完全なリスト（800以上の項目）をさらに見ていくと、あらゆる種類のオーバーフロー/アンダーフロー 、 初期化 、 制御不能な再帰など、多くの問題が見つかります。これらはすべてよくあるセキュリティ攻撃であると同時に、明らかに品質の問題です。
セキュリティと品質を作り込む
ソフトウェアシステムの複雑さは極めて急速に増大しています。起こりうるすべてのバリエーションを迅速にテストすることは、ほとんど不可能になりつつあります。「潜在的なテストの数は、宇宙に存在する分子の数を超える」というRichard Benderの言葉 は、テストは絶対に完了することがないという事実を、気の利いた表現で言い直したにすぎません。また、Jim Birdはこんなことも言っています－「大規模なシステムの場合、すべてのバグを見つけるには、無限の数のキーボードで無限の数の侵入テストのテスターが無限の時間にわたって作業する必要があるでしょう。」
したがって、セキュリティと信頼性の両方を、設計とエンジニアリングによって作り込む必要があります。テストでそれらを作ることはできません。セキュリティが「付加的なもの」であるかぎり、セキュリティはずっと犠牲にされつづけるでしょう。
可能な対策
ソフトウェアの品質とセキュリティの向上を同時に開始するためにできることがいくつかあります。
- 開発者に安全な開発に関するトレーニングを施す。 適切に開発者をトレーニングして安全な開発プラクティスを身につけさせると、開発者はセキュリティ問題を防止する、少なくとも問題を見つけて修正することができます。
- 品質とセキュリティを重視したシステムの設計と構築を行う。 確かに「動いてはいる」けれど、潜在的なセキュリティの問題 (あるいは安全性の問題) があるため、選択するべきではないコードを避けるようにします。静的解析はバグを検出するだけでなく、コードが既知のベストプラクティスに従っているかをチェックするため、この目的に役立ちます。
- 侵入監視ツールに頼らない。 実際の露出面および攻撃面を認識します。ファイアウォールやアンチウイルスソフトは、安全でないコードを補うものではありません。アプリケーション自体を強化する必要があります。
- 欠陥データを収集/測定し、それを使用して開発プラクティスを評価し改善する。 最も問題が多いコードやコンポーネントは何でしょうか？最も品質が高いコードはどれでしょうか？コードはどのようにテストされたでしょうか？良いアイデアは繰り返し、悪いアイデアは捨て去るようにしましょう。
- 厳密な静的分析を使用する。 報告された欠陥が重要な問題ではない、または偽陽性(誤検出)であるという評価を単純に受け入れないようにします。検出と予防の両方を含む適切なルールセットを入手し、それに準拠します。これを行う最善の方法は、ベストプラクティス（ CWE 、 CERT 、 OWASPなどのコーディング標準の役割）に関するエンジニアリングアプローチにあります。静的解析は、ベストプラクティスが確実に実行されていることを確認する方法です。
- 実行時解析を使用する。 実行時解析は、実際の問題（特に厄介なメモリの問題）を発見し、どこで何が間違ったかを正確に示します。
コードにセキュリティを作り込む必要があります。これは、単に既知のホールにパッチを当てるのではなく、本当にセキュリティを強化する最良の方法です。コーディング、ビルド、およびテストから得たすべてのソフトウェア開発結果を中央のリポジトリに統合すると、制御、測定、およびトレーサビリティが実現されます。これが将来の改善の基礎となります。
そして、堅実な予防のコストは、品質の低いソフトウェアや安全でないソフトウェアに対処するコストよりも低いことを忘れないでください。つまり、言い訳の余地はまったくありません。