セキュリティ上のバグと欠陥：異なるが、悪いという点では同じ

この崩壊は最悪の設計上の欠陥が原因で起きました。この橋の建設が仕様に正確に従って行われたとしても（実際にそうであったのでしょう）、設計に欠陥があったために崩壊する運命にありました。

Synopsysの主任科学者であるSammy Miguesは「コンクリートの一部を流し込み忘れたり、ボルトを1本忘れたりした場合はバグに相当する」と言います。「問題は、橋が必要な設計パラメータに合わせて建設されなかったことだ」と。

ソフトウェアの教訓：ネットワーク、システム、およびアプリケーションのセキュリティを確保するには、セキュリティの欠陥とバグの両方に対処することが非常に重要です。

『BSIMM（Building Security In Maturity Model）for the past decade』の共著者であるMiguesは「プログラムのソフトウェアのすべてがアプリケーションであるわけではない。そのため、アプリケーションのコードばかりを心配している場合は、おそらくソフトウェアの多くに注意を払っていないことになる。それは問題だ」と述べています。

実際、おおよその推定では、ソフトウェアセキュリティの欠陥の半数が設計上の欠陥です。ハッカーが望むようにその欠陥を無視すると、攻撃しやすいアタックサーフェスになります。

コードに何千ものバグが含まれていても、自動化ツール（静的、動的、インタラクティブな解析、およびソフトウェア・コンポジション解析（SCA）によって、開発者は、作業中でもリアルタイムでバグを検出して修正することができます。

これは、バグの修正は比較的すばやく、簡単に、あまり費用をかけずに行うことができることを意味します。「エラーの発生時にそれを見逃して、アプリケーションがクラッシュした場合、コードの行を変更すれば、正しく機能する」とMiguesは言います。

それとは対照的に、欠陥は配列リファレンスにおける「1つ違い」のエラーや、間違ったシステム呼び出しよりもはるかにわかりにくい場合がほとんどです。

Miguesによると、「設計は2つのものの間のプロトコルであり、ファイルの構築方法、またはログの手法である可能性があります。」

「『このアプリケーションまたはこのマイクロサービスが任意のソースから任意の速度で任意数の要求を受け入れることが許可され、速度チェッカーもID管理やアクセス制御、アクセス管理もない』としたら、それは設計上の欠陥であり、単にコード行に誤りがあるのではない」のです。

あいにく、設計上の欠陥の検出はバグの検出よりも労力がかかり、かなりの専門知識を要します。組織が依然として十分にそれを行っていないのは、そのためです。

Miguesによると、1～10段階評価では、TMは1～3の範囲、TMとARAの組み合わせは4～6、集約型ARAは7～10の範囲です。

さらに、「TMを開始した組織が多数あります。TMは『自分たちの知識に基づくと、この設計には何か問題があるか？』ということを意味します。それは概して、設計を破棄するものではありません。脅威モデラーのエクスペリエンスを利用して、何か欠落していないか、問題が起こるようなことが行われていないかなどを確認するのです」と続けています。

これには何らかの価値はあります。しかし、Miguesが言うように、脅威モデリングでは、小さな石や中サイズの石で窓を壊すことはできないと判断したが、大きな石なら壊すことができるかどうかを確認しないようなものです。