適切な「セキュアコーディング標準」の選択と実装方法！CWE、OWASP、CERTなどを解説

ソフトウェアのセキュリティを確保するには、開発ライフサイクルの初期段階から、CWE、OWASP、SEI/CERTなどの優れた「セキュアコーディング標準」を考慮した実装を行うことが欠かせません。

ただし、数多くのセキュアコーディング標準や、セキュリティ規格などが存在するため、それぞれの内容や関係性を理解したうえで、自社に適したセキュアコーディング標準を適用しなくてはなりません。

そこで今回は、適切なセキュアコーディング標準を選択、導入するために役立つ情報を体系的にまとめたホワイトペーパーをご用意しました。各種セキュアコーディング標準の特長や現実的な導入方法などを解説していますので、ぜひダウンロードしてご活用ください。

このホワイトペーパーで分かること

• セキュアコーディング標準の目的とは？
• 明示的なコーディング標準（CWE、OWASP、SEI/CERT、PCI DSS）
• 暗黙的なコーディング標準（UL 2900、GDPR、HIPAA）
• コーディング標準の選択と現実的な導入方法

適切なセキュアコーディング標準の選択および実装方法

サイバーセキュリティインシデントが増えるにつれて、アプリケーションセキュリティ(AppSec)の改善に対する関心も大きくなっていますが、セキュリティテストの大半は依然としてソフトウェア開発ライフサイクルの後期で行われ、「テスト後のセキュリティ評価」という活動にとどまっています。アジャイルや DevSecOps などの最近の開発ムーブメントは、テスト作業のシフトレフトを重視します。つまり、セキュリティ脆弱性への対処のコストが比較的低く、より効果的であることが明らかなサイクル早期にテストを実施します。

通常、アプリケーションセキュリティ(AppSec)では静的アプリケーションセキュリティテスト (SAST) または静的コード解析を行うことがシフトレフトになります。コードレベルでのセキュリティ対策を始めるにあたって、開発初期からセキュリティを構築する効果的な方法として、セキュアコーディング標準への注目が高まっています。
セキュアコーディング標準の詳しい説明に入る前に、標準の背後にどのような意図があり、どのようなアプローチを推進しているのかを知ると役に立つでしょう。

ソフトウェアセキュリティはソフトウェアエンジニアリングに関わる問題であり、製品の初期コンセプトと同時に始まり、デプロイメントのライフスパン全体にわたって継続します。このライフスパンは通常考えるよりもはるかに長いものです。たとえば、セキュリティパッチがもうほとんど手に入らないにもかかわらず、いまだに Windows 7 で重要な機能を実行しているコンピューターは多数あります。Garry McGraw は著書『Software Security: Building Security In』 において、セキュリティの構築とは何を意味するかについてエンジニアリングの観点から優れた定義を提示しています。

「ソフトウェアセキュリティとは、ソフトウェアがセキュアで、悪意のある攻撃を受けても適切に機能するよう構築するというプラクティスであり… よいソフトウェアセキュリティプラクティスはよいソフトウェアエンジニアリングプラクティスを活用し、ライフサイクルの早期にセキュリティについて考えます。」
— Garry McGraw『Software Security: Building Security In』

ソフトウェアの他の品質特性と同様に、セキュリティは確かなソフトウェアエンジニアリングのプラクティスに支えられた確かな基礎を前提とします。
侵入テストなどの後段階でのアクティビティがセキュリティ対策のすべてであるとみなされることがよくあります。もちろん、侵入テストはセキュリティ戦略の重要な一部ですが、それだけでは十分ではありません。

たとえ話で考えてみましょう。金庫室を設計して造るとき、やみくもに新しい金庫室を造ってから金庫破りを試み、結果に基づいてよりよい金庫室を造るということはありません。メーカーは脅威に関する事前知識を活かし、金庫がどのように使われるかを理解し、さらに確固としたエンジニアリングプラクティスに基づいて、目的に適った金庫室を造るはずです。試験は行うでしょうし、それには破壊的試験も含むかもしれませんが、あくまで既知の脅威に対応できるよう造ったうえでの話です。

高品質のコードを開発することは、健全なソフトウェアエンジニアリングを実践するうえで重要な要素です。そうした品質の高いコードは、確立されたベストプラクティスになることがあり、標準として適用されます。多くの確立された分野では、作業が業界の既知のベストプラクティスに基づいて問題なく行われたことを確認するのに標準を使用します。ソフトウェア標準の基本的な目的も同じです。

コーディング標準の目的

ソフトウェアコーディング標準は、長年にわたる経験から得られたベストプラクティスを体現しています。その目的は、品質とセキュリティを損なうよくないプラクティスを避けて、より回復力の高いコードを作成するためのよいプラクティスを推進することで、コードの堅牢化を目指すことです。セキュリティ標準の場合は、ベストプラクティスに加えて、長年にわたって観察されてきた各種の脆弱性や攻撃を防ぐためのガイドにも基づいています。2023年7月時点で、210,646個の common vulnerabilities and exposures (CVE) が報告されており、その数は増え続ける一方です。

これらの脆弱性から学ぶべきことは数多くあります。多くのセキュリティ脆弱性の原因は、バッファーオーバーフローや整数オーバーフローなどの典型的なプログラミングエラーです。実際、Microsoftが公開している Microsoft 自身のソースコードを対象とした研究では、セキュリティ脆弱性の 70% はバッファーオーバーフローやスタックオーバーフロー、解放後の使用、型の取り違いなどのメモリエラーが原因であることがわかっています。

通常、コーディング標準はプログラミング言語機能のうち比較的安全かつセキュアに使用できると考えられるサブセットを定義します。その目的は、セキュリティ脆弱性の元となるリスクの高い言語機能を制限することで、根本からセキュリティ脆弱性を防ぐことです。

コーディング標準を適用する現実的かつ客観的で継続可能な唯一の方法は、一度に大量のソースコードを自動的に解析できる静的コード解析ツールを使うことです。解析ツールは CI/CD パイプラインでのビルドに統合するとともに、開発者の IDE から直接使うことができます。ツールは解析対象のソフトウェアが指定された標準に準拠しているかを示すレポートを提供します。
セキュアコーディング標準の必要性が認められ、静的コード解析ツールを購入し、利用可能になったとして、プロジェクトに最適なコーディング標準を判断するにはどうしたらよいでしょうか？ 以下のガイドが役に立ちます。

セキュアコーディング標準ガイド

ソフトウェア業界には多数のセキュリティ標準があります。中には、システムレベルでのセキュリティプラクティスや手続きに関する包括的な指針は提示するが、コード固有の指針については示さないものもあります。一方で、特定のセキュアコーディング標準を推奨しているものもあります。

GDPR や HIPAA などの標準は、確固としたエンジニアリングプラクティスを要求しますが、ソフトウェアコーディング標準については直接的な指針を示していません。ソフトウェアコードの観点から、ここでは CWE Top 25、OWASP Top 10、SEI/CERT のような明示的なコーディングガイドラインについて説明します。

続きは資料DLしてご覧ください。