このように大量のセキュリティ問題が発生する理由の1つは、セキュリティの扱い方にあります。通常、セキュリティは後付けのものと考えられおり、開発の最後にデバイスに追加されます。しかし、複雑なシステムでは、特に組み込みシステムでは、攻撃者が鎧の穴を見つけるための大きな攻撃面があります。ハッカーがシステムに侵入しようとする方法を研究すると、ほとんどのハッカーの武器の中でお気に入りのツールは、デバイスのソフトウェアの欠陥を見つけて悪用することであることがすぐにわかります。

ソフトウェアの欠陥がハッカーが使用するドアであるならば、私たちはこの問題に対処するためにコード品質を向上させる必要があります。それはどれほど大きな問題であり、それを解決するために何ができるでしょうか。

コードの脆弱性はハッカーの標的になりやすい

低いコード品質は実際にはよく知られている問題であり、悪いコーディングプラクティスが脆弱性に直結するという主張を裏付けるかなりの証拠があります。多くのソフトウェアエンジニアリングの専門家が何年にもわたってこれを説いてきましたが、おそらく初めて人々が本当に気づいたのは、Code RedワームがMicrosoftのインターネットインフォメーションサービス（IIS）へのバッファオーバーフロー攻撃を悪用した2001年のことです。[1]最初に文書化されたバッファオーバーフロー攻撃は、1988年にUnix fingerコマンドで発生しましたが、その攻撃能力は一般に影響を与えるには非常に限定的だったため、ヘッドラインニュースにはなりませんでした。

Code Redがインターネットの大幅な速度低下を引き起こし、ニュースが広まったため、いたるところでバッファオーバーフロー攻撃の増加が突然見られました。セキュリティ研究者やハッカーは、組み込みシステムを含むさまざまなシステムでこれらのバグをいたるところで発見しているようでした。この攻撃は、テキストやデータを保持するために固定長のバッファを使用するコードを標的にして、ハッカーが影響を受けたシステム上で好きなコードを実行することを可能にします。ハッカーは、バッファースペースの最大までを満たして、正当なバッファーの最後に実行可能コードを書き込みます。その後、攻撃を受けているシステムは、バッファの最後でコードを実行し、多くの場合、攻撃者が望むことをすべて実行できるようになります[2]。

このタイプの攻撃が緊急になった理由は、バッファの制限をチェックして強制することは一般的なコーディング手法ではなかったためですが、mitre.orgのCommon Weakness Enumerationのような多くのコーディング規格では、このタイプの脆弱性についてバッファをチェックすることを推奨しています。[3]　残念なことに、開発者がコードを書くときにこの問題を探すことはまだ一般的ではありません。開発者が問題を認識して修正するために、コード解析ツールがこれらの問題に気付く必要があります。このような単純なコード品質の改善により、最も一般的なハッカーアプローチの1つが取り除かれ、コードのセキュリティが大幅に向上します。そのため、コード内のバッファの長さを確認して強制することは、優れたコーディング方法です。

バッファオーバーフローだけではない

ただし、問題はバッファオーバーフローだけではありません。実際のシステムの問題であり、ずさんなコーディングにより、ハッカーがシステムを危険にさらすために利用できるセキュリティホールが無数に発生します。SoftwareEngineering Institute（SEI）が公開した論文では、それは非常に明確な言葉で述べられています：

“品質パフォーマンスメトリクスは、非常に高い品質の製品を決定し、安全性とセキュリティの結果を予測するためのコンテキストを確立します。プログラミング言語構造の不適切な使用、バッファオーバーフロー、入力値の検証の失敗など、共通の弱点列挙（CWE）の多くは、質の低いコーディングや開発手法と関連しています。品質を向上させることは、いくつかのソフトウェアセキュリティ問題に対処するために必要な条件です。" [4]

この論文では、セキュリティの問題は、バグの多いソフトウェアが原因で発生するため、通常のコーディングの欠陥のように扱うことができ、従来の品質保証手法を適用して、セキュリティの問題の少なくとも一部に対処できることを示しています。

通常のソフトウェア品質保証プロセスでは、システムに残っている欠陥の数を見積もることができますが、セキュリティ脆弱性についても同じことができるでしょうか？SEIは、コード品質とセキュリティの間の数学的な関係を確認するには不十分ですが、ソフトウェアの欠陥の1パーセントから5パーセントがセキュリティ脆弱性であると述べており、セキュリティ脆弱性が追跡されると、システムのコード品質のレベルを正確に見積もることができるという証拠が示されていると述べています。このことは、コードの品質がセキュリティにとって必要な（しかし十分ではない）条件であることを決定的に示しており、セキュリティは開発の最後にボルトオンとして扱うことができるという概念を打ち破っています。むしろ、セキュリティは、設計からコード、そして本番まで、プロジェクトの DNA に通じるものでなければなりません。

コーディング規格は非常に役に立ちます

最も一般的なセキュリティホールの多くは、mitre.orgのCommon Weakness Enumeration（CWE）などのコーディング規格で対処されており、ゼロ除算、データインジェクション、ループの不規則性、NULL ポインタの悪用、文字列解析エラーなどの懸念事項が指摘されています。MISRACおよびMISRA C ++は、セキュリティの脆弱性がコードに侵入するのを防ぐために、安全で信頼性の高いコーディング手法を推進しています。これらは一般的に悪用されている脆弱性の多くを捕捉することができますが、開発者はコードを書くときはより深く考える必要があります。ハッカーが開発者が書いたものをどのように悪用することができるか？穴はどこにあるのか？入力がどのように見え、出力がどのように使用されるかについての仮定を立てているか？良い経験則としては、仮定を行っている場合、これらの仮定をコードに変換すべきで、期待どおりの結果が実際に得らことを確認する必要があります。これを実行しない場合、ハッカーが代わりに実行します。

しかし、オープンソースソフトウェアについてはどうでしょうか？ 設計でオープンソースコンポーネントを使用するための一般的な議論は、“使用による実証” の議論に依存しています：非常に多くの人々がそれを使用しているので、それは良いものに違いありません。SEIの同じ論文には、以下のことについても書かれています：

“ オープンソースの利点の一つは、フリーであること以外にも、次のような前提があります。’ ソースコードを多くの人が見るということは、セキュリティの問題をすばやく発見でき、誰もがバグを修正できるということです。ベンダーには依存しません'  しかし、現実には、欠陥の除去に規律ある一貫した焦点がなければ、セキュリティバグやその他のバグがコードに含まれることになります。" [4]

言い換えると、SEIは、“使用による実証” の議論は何も意味しないと述べており、オープンソースコードに品質保証を適用することに関して、Anybody、Somebody、Nobody、Everybodyの話（誰でもできることを誰もやらなかったのに、誰もが誰かのせいにした）を思い起こさせると述べています。さらに、コードを証明するにはテストだけでは十分ではありません。SEIは、CWEのようなコード品質標準は、標準的なテストでは通常検出されず、ハッカーが脆弱性を悪用したときにのみ発見されるコードの問題を検出するとしています。 2020年5月、Purdue大学の研究者は、Linux、macOS、Windows、およびFreeBSDで使用されているオープンソースのUSBスタックに26の脆弱性があることを実証しました[5]セキュリティに関しては、コード品質が重要であり、すべてのコードが重要です。

コード解析ツールは、標準に準拠するのに役立ちます

アプリケーションのセキュリティを向上させるために、コードの品質に対処するために何ができるでしょう？簡単な答えは、2つの基本的な特徴をもつコード解析ツールを使用することです。アプリケーションのソースコードのみを調べる静的解析とnullポインタやデータインジェクション手法などの弱点を探すランタイム（または動的）解析です。

高品質のコード解析ツールには、CWE、MISRA、CERT Cのチェックが含まれます。CERT Cは、セキュアなコーディングを促進するために設計された別のコーディング規格です。これら3つのルールセットは、セキュリティを促進するコーディングプラクティスの優れた組み合わせを形成します。ルールセットの中には、他のルールセットと重複するものもありますが、コードの高度なセキュリティを確保するのに役立つ独自の機能も提供しています。これらの標準を使用すると、可能な限り最高のコード品質が得られ、コードに潜在的な欠陥が見つかる可能性もあります。

高品質のコードはセキュアなコードです

コードの品質がないとセキュリティを確保できません。また、バグがセキュリティの悪夢になる可能性があるため、コードの品質を他に譲ることはできません。しかし、コード解析ツールが問題をすばやく特定できるので、希望があります。セキュリティへの道は常にコード品質のゲートウェイを通過します。

Article written by Shawn Prestridge, Industry profile and US FAE Team Manager at IAR Systems