IPA テクニカルウォッチ

「ソースコードセキュリティ検査」に関するレポート

～出荷前のソフトウェアの脆弱（ぜいじゃく）性を低減するために～

1

IPA テクニカルウォッチ：「ソースコードセキュリティ検査」に関するレポート

～出荷前のソフトウェアの脆弱（ぜいじゃく）性を低減するために～

目次

対象読者と前提条件 ..................................................................................................................................... 2

本レポートの目的 ......................................................................................................................................... 2

本レポートの要旨 ......................................................................................................................................... 2

1. はじめに ................................................................................................................................................ 3

1.1. システムライフサイクルに沿ったセキュリティ対策 ................................................................... 3

1.2. 現在行われている主なセキュリティ対策 ...................................................................................... 4

1.3. 「ソースコードセキュリティ検査」が実施されていない背景 ..................................................... 5

2. 「ソースコードセキュリティ検査」 .................................................................................................... 6

2.1. 「ソースコードセキュリティ検査」の概要 .................................................................................. 6

2.2. 「ソースコードセキュリティ検査ツール」の種類 ....................................................................... 8

2.3. セキュリティ検査と特徴 ............................................................................................................... 9

2.4. 「ソースコードセキュリティ検査ツール」の有効な場面 .......................................................... 10

3. 「ソースコードセキュリティ検査」ツールの有効活用事例 .............................................................. 12

3.1. 活用事例(1) ~ 組込み機器開発ベンダーA社における活用事例 ~ ............................................. 12

3.2. 活用事例(2) ~ SDNA における活用事例 ~ ................................................................................. 13

3.3. 活用事例(3) ~ IPA のツール開発における活用事例 ~ ................................................................ 13

4. 「ソースコードセキュリティ検査」に係る最新動向 ......................................................................... 14

5. 今後の IPA の取り組み ...................................................................................................................... 15

付録 1:「ソースコードセキュリティ検査」の具体例 ................................................................................ 17

付録 2: 「IPAソースコードセキュリティ検査ツール(仮称)」の検出対象の脆弱性とその選定方法 ...... 19

2

IPA テクニカルウォッチ：「ソースコードセキュリティ検査」に関するレポート

～出荷前のソフトウェアの脆弱（ぜいじゃく）性を低減するために～

2011 年 11 月 17 日

IPA（独立行政法人 情報処理推進機構）

技術本部 セキュリティセンター

対象読者と前提条件

本レポートは、主にソフトウェア(アプリケーション)開発に関わる企業、技術者および学生を対象読者と想

定している。

また、「ソースコード静的解析」とも呼ばれる「ソースコード検査」は、「コーディング規約違反等の検出を行

う技術」、「脆弱性(例：バッファオーバフロー)を検出する技術」に分類される。本レポートでは、後者に分類

される技術を「ソースコードセキュリティ検査」と表記し、両者を指す場合は、「ソースコード検査」と記述す

る。

本レポートの目的

独立行政法人情報処理推進機構（以下「IPA」という。）は、安心・安全な IT社会の実現を目指し、システ

ムライフサイクルに沿ったセキュリティ上の弱点（脆弱性）への対策を推進している。

本レポートは、システムライフサイクルの「実装工程」において実施するセキュリティ対策「ソースコードセ

キュリティ検査」の有効性と重要性についての理解を深め、実際の開発現場において「ソースコードセキュリ

ティ検査ツール」が導入されることを目的としている。

本レポートの要旨

本レポートでは、「ソースコードセキュリティ検査」の有効性と重要性について説明する。

1 章では、システムライフサイクルに沿ったセキュリティ対策と、「ソースコードセキュリティ検査」の位置づ

け、現在のセキュリティ対策の状況について説明する。

2 章では、「ソースコードセキュリティ検査」の概要や他のセキュリティ検査技術との違いを解説する。そし

て、2.4節では具体的に有効な場面を紹介する。

3 章では、2 章までに解説する、「ソースコードセキュリティ検査」の実施・成功事例を紹介することで、そ

の有効性を示す。

4 章では、「ソースコードセキュリティ検査ツール」の最新動向について解説する。今後「ソースコードセキ

ュリティ検査ツール」の利用は、さまざまなソフトウェア開発現場で求められる可能性がある。最新動向を知

ることで、今後のソフトウェア開発に生かされることを目的としている。

5章では、「ソースコードセキュリティ検査ツール」の導入を推進するため、「今後の IPAの施策」を紹介す

る。

3

1. はじめに

1.1. システムライフサイクルに沿ったセキュリティ対策

システムのセキュリティ対策は、要件定義から運用、そして廃棄(サービス終了)に至るまでシステムライ

フサイクルに沿い、トータルで対策を行うことが重要である。

本レポートでは、このシステムライフサイクルを[1.要件定義][2.設計][3.実装][4.テスト][5.運用 / 利

用]([6.廃棄])と分類している（図 1）。システムライフサイクルの各工程において、セキュリティ脅威となりう

る要因を洗い出し、対策や方針決定を行いながら被害に遭うリスクを低減していく必要がある。

図 1 システムライフサイクルと各工程における対策

各工程において、実施するセキュリティ対策を下記に説明する。

[1.要件定義]

[1.要件定義]工程では、システムの目的や利用形態を明確にし、開発するソフトウェアやシステムにお

いて想定される脅威を洗い出し、それぞれの脅威に対して、ビジネスインパクトや費用対効果を踏まえた

対策方針や設計方針を決定しておくことが重要である。

[2.設計]

設計工程では、[1.要件定義]において検討した方針に従い、実装すべき機能や取扱うデータ形式など

の検討を行う。実際にソフトウェアを運用することを見据えて安全かつ自分達で運用可能なシステムを設

計しておくことが重要である。また、ソフトウェアに脆弱性を作りこまないようプログラムの書き方およびそ

れに関わる知識である「セキュアプログラミング」などの脆弱性を作りこまない対策をプログラム実装前に

検討しておくことも重要である。

(対応例)

・認証方式の設計

・ログ設計

・セキュアプログラミング技法

[3.実装]

実装工程では、ソフトウェアのソースコードレベルでの対策を行う。プログラミング時の対応は勿論の事、

ソフトウェア開発者が作ったソースコードに対するチェックも重要である。

(対応例)

・コーディング規約による制限

1.要件定義 2. 設計 3. 実装 4. テスト 5. 運用 / 利用 6. 廃棄

■ 運用時対策

■ 脆弱性対策

■ セキュアプログラミング技法

■ ソースコードセキュリティ検査

■ 脆弱性診断（ﾍﾟﾈﾄﾚｰｼｮﾝ）

■ テスト（ﾌｧｼﾞﾝｸﾞ他）

■ 調査、動向把握、開発方針・体制整備（ﾋﾞｼﾞﾈｽｲﾝﾊﾟｸﾄ分析含む）

システム

ライフサイクル

セキュリティ対策

攻撃脆弱性脅威

4

・ソースコードレビュー

・ソースコードセキュリティ検査

[4.テスト]

テスト工程では実行形式のプログラムに対して、動作を確認しながら脆弱性の検査を行う。ソフトウェ

アの意図しないデータ群（例えば、非常に長い文字列など）を作成し、検査対象であるソフトウェアに入力

し、ソフトウェアの応答を観察するセキュリティ検査手法である「ファジング」、開発したソフトウェアだけで

なく OSやミドルウェア等のシステム全体を対象に検査を行う「脆弱性診断」などが挙げられる。

(対応例)

・ファジング

・脆弱性診断

[5.運用 / 利用]

脆弱性を悪用する攻撃は、日々進化する。そのため、[5.運用 / 利用]では、外部からの攻撃への対

策として、脅威や脆弱性情報の収集、定期的に「脆弱性診断」などを実施し、修正プログラムを適用する

などの脆弱性対策を随時実施することが必要となる。

脆弱性を悪用する攻撃からソフトウェアを保護するためには、これらの各工程においてセキュリティ対策

を実施することが必要不可欠である。

1.2. 現在行われている主なセキュリティ対策

出荷されたソフトウェアやシステムに脆弱性が発見された場合、システム設計の見直しが必要になる場

合があり、対策にかかるコストが予想外に増大する可能性がある。また、ソフトウェア出荷後に、脆弱性が

悪用された攻撃が原因で利用者に被害が生じた場合、利用者からのクレームは当然のことながら、ソフトウ

ェアを開発した企業にも追加の費用負担や社会的責任が生じてくる。

そのため、プログラムの品質管理と同様に、脆弱性を作り込まない対策や作り込んだ脆弱性をシステム

ライフサイクルの早い工程(製品を出荷する前)で摘出する対策が特に重要である。

ソフトウェアに脆弱性を作り込まない対策として、昨今、[2.設計]工程において実施する、「セキュアプログ

ラミング」が定着してきている。しかし、開発担当者のスキルには個人差があり、脆弱性が作りこまれてしま

っている可能性がある。また、作り込んだ脆弱性をシステムライフサイクルの早い工程(製品を出荷する前)

で摘出する対策のうち、システムライフサイクルの[4.テスト]工程や[5.運用 / 利用]工程におけるセキュリテ

ィ対策として定期的に実施する「脆弱性診断」については定着し始めている。しかし、「脆弱性診断」は、既

知の攻撃パターンを送付しながら対象のシステムやソフトウェアの挙動を確認するブラックボックステストで

あるため、ソースコード中に存在する脆弱性を網羅的には検出できない。

そこで、「ソースコードセキュリティ検査」が有効である。「ソースコードセキュリティ検査」は、ソースコード

中に存在する脆弱性を網羅的に検出する対策であり、これを実施することで、出荷する前の製品に存在す

る脆弱性を低減することができる。図 2 は、企業におけるセキュリティ検査、「脆弱性診断」と「ソースコード

セキュリティ検査」の実施状況を示している。「ソースコードセキュリティ検査」は約 16%と、「脆弱性診断」の

約 54％と比べると実施されていないことがわかる。

5

図 2「ソースコードセキュリティ検査」及び「脆弱性診断」の実施状況1

1.3. 「ソースコードセキュリティ検査」が実施されていない背景

「ソースコードセキュリティ検査」の普及が進んでいない背景として、以下の理由が考えられる。

(1). 「ソースコードセキュリティ検査」の重要性が認識されていない

「ソースコードセキュリティ検査」の重要性を確認できる文献が少ないことがあげられる。商用製品の

紹介ページには、重要性の記載がなされているものの、第三者視点から重要性について解説した文

献はあまり見受けられない。特に、日本語で記載された文献は少なく、「ソースコードセキュリティ検査」

が、脆弱性対策として重要な位置付けとなり、有効な手段であることを、経営者やプロジェクト管理者

が認識する機会が少ないのが実情である。

また、開発現場においては、工期の圧縮、開発工数の削減が求められている。このような状況下に

おいて、「ソースコードセキュリティ検査」を工程に組入れると、作業が増えてしまうため、開発担当者

から敬遠されがちである。

(2). 有効性の確認が難しい

実際に「ソースコードセキュリティ検査」の有効性を確認しようとしても、フリーソフトとして利用可能な

ツールの多くは、日本語に対応しておらず、導入・評価の敷居が高くなってしまう。また、誤検出が多い

など脆弱性の検出精度が低かったりと、開発担当者が脆弱性対策を行うには、レポートが十分でなか

ったりする。そのため、開発担当者が脆弱性に関する知見があまりないと、検出された箇所が脆弱性

であるかの判断に時間を要したり、脆弱性の対策に係る工数が増加したりしてしまう。そのため、実際

に導入した際の費用対効果など有効性の確認手段が少ない状況である。

以降、本レポートでは、「ソースコードセキュリティ検査」の普及が進まない理由の原因である、重要性や

に有効性ついて解説する。

1 2010年度、IPA主催のセミナーの参加者 140名へのアンケート結果

15.7

54.3

84.3

45.7

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

ソースコードセキュリティ検査

脆弱性診断

実施している 実施していない

6

2. 「ソースコードセキュリティ検査」

「ソースコード検査」は、一般的に「ソースコード静的解析」とも表記される。この「ソースコード検査」は、大

きく分けて、以下の 2つに分類できる。

規約違反の検出等を行う技術

コーディング規約違反の検出等を確認する技術である。ソースコードの信頼性、保守性、移行性、効率

性といった品質を確保するための検査である。

脆弱性を検出する技術

ソフトウェア開発において、脆弱性が作りこまれていないかを確認する技術である。ソースコード安全

性に関わる品質を確保するためのセキュリティ検査である（ソースコードセキュリティ検査）。

本章では後者の「ソースコードセキュリティ検査」の概要、その他のセキュリティ検査との違いを説明し、

「ソースコードセキュリティ検査」の有効性や重要性を解説する。

2.1. 「ソースコードセキュリティ検査」の概要

「ソースコードセキュリティ検査」は、ソフトウェアの設計図であるソースコードを機械的にチェックし、ソー

スコードに含まれる特定のパターンを抽出することで脆弱性を自動的に検出する、[3.実装]工程において実

施するセキュリティ対策である（図 3）。

図 3「ソースコードセキュリティ検査ツール」のイメージ

「ソースコードセキュリティ検査」技術を実装した、「ソースコードセキュリティ検査ツール」で、検出可能な

脆弱性の例を次に示す2。

バッファオーバーフロー

フォーマットストリング

整数オーバーフロー

SQL インジェクション

クロスサイト・スクリプティング

2 具体的な検出例については、付録 1を参照。

組み込み開発向けソースコード診断ツール

1. main.c - 27行目2. main.c - 101行目3. util.c - 327行目

・・・・・・・・・

1. main.c - 27行目

・・・・・・

■脆弱性・問題の解説

■本脆弱性・問題の脅威

■対策（修正方針）

■参考情報

・・・

・・・

・・・

・・・

ソースコード内の脆弱性の有無と箇所を判定

○ ×

int x;

if (x > 0)

… strcpy(buf, str);

…

7

一方で、「ソースコードセキュリティ検査ツール」を導入すると、ソフトウェア開発担当者がソフトウェアの実

装を行いながら、「問題個所」を検出することができる。そして、「ソースコードセキュリティ検査ツール」が出

力するレポートをもとに、「問題個所」が脆弱性であるかを判断し修正することで、出荷される前に作りこま

れた脆弱性を減らすことができる。

これにより、出荷された後に脆弱性が発見され、開発担当者が再度修正しなおすといった想定外の作業

工数増加のリスクを低減することができる（図 4)。

このように、「ソースコードセキュリティ検査ツール」は多岐にわたる脆弱性がソースコード中に埋め込ま

れていないかを確認できる。また、「ソースコードセキュリティ検査ツール」は、特定のパターンによる検出を

行うため、すぐには悪用できない（攻撃ができない）が、「潜在的脆弱性（追加開発を行った際などに脆弱性

として顕在化する可能性がある問題個所）」も検出する。但し、ウェブアプリケーションにおけるアクセス制御

や認可制御に関する脆弱性など、機能仕様に関する脆弱性は検出できない。

図 4「ソースコードセキュリティ検査ツール」を導入した脆弱性対策の流れ

ソースコードセキュリティ検査導入後

ソースコードセキュリティ検査導入前

組み込み開発向けソースコード診断ツール

1. main.c - 27行目2. main.c - 101行目3. util.c - 327行目

・・・・・・・・・

1. main.c - 27行目

・・・・・・

■脆弱性・問題の解説

■本脆弱性・問題の脅威

■対策（修正方針）

■参考情報

・・・

・・・

・・・

・・・

×

8

このように、「ソースコードセキュリティ検査ツール」を導入することで、製品を出荷する前に脆弱性を作り

こまないことが可能になる。このため脆弱性への根本的な対策の一つとなり、開発した製品出荷時のセキ

ュリティ品質の向上が期待できる。

2.2. 「ソースコードセキュリティ検査ツール」の種類

「ソースコードセキュリティ検査ツール」は、主に 2 つのパターンに分類できる。本レポートでは、「ソースコ

ード入力型」と「統合開発環境組込み型」と呼び分類3して説明する。

「ソースコード入力型」

「ソースコード入力型」は、完成したソースコードやソースコード群を検査ツールに入力することで、検査

する (図 3 のイメージ)。複数人の開発者により作成されたソースコードを、横断的に検査する際に利用

すると効果的である。その理由は、単一のソースコードでは問題がない場合でも、複数のソースコードが

原因で脆弱性となる問題個所を検出できる場合があるためである。

また、「ソースコード入力型」の多くは、開発したソフトウェア全体を俯瞰したレポートが出力できることも

特徴的である。そのため、出力されるレポートを、開発したソフトウェアの脆弱性対策状況（ソフトウェアに

脆弱性がないことを証明するため）の報告に利用されることが多い。インターネット等で公開されているフ

リーソフトの多くは、レポート機能は十分でないものの、この「ソースコード入力型」である。

「統合開発環境組込み型」

「統合開発環境組込み型」は、実際にソフトウェアを開発する環境である、統合開発環境に組み込み利

用する。問題点をすぐに確認できるため、その場ですぐに脆弱性を修正できる点が特徴的である。

昨今の商用「ソースコードセキュリティ検査ツール」では、「統合開発環境組込み型」の機能を保有する

製品が多い。例えば、Microsoft社の統合開発環境「Visual Studio 2010」の一部においては、「ソース

コードセキュリティ検査」を実施できる仕組み4が組み込まれている。

「Visual Studio 2010」において、実際に「ソースコードセキュリティ検査」を実施した例を図 5に示す。

図 5 「Visual Studio 2010」を利用した「ソースコードセキュリティ検査」例

3 本レポートでの説明のために用意した用語であり、「ソースコードセキュリティ検査」で広く定着して用いられている用語ではない

4 コード分析を使用した C/C++ コードの品質の分析, Microsoft, http://msdn.microsoft.com/ja-jp/library/ms182025.aspx

9

図 5 からは、開発中のソフトウェアに、バッファオーバーフローの脆弱性が存在する可能性があること、

脆弱性が存在する可能性がある箇所が報告されていることが見て取れる。

2.3. セキュリティ検査と特徴

ソフトウェア開発者がシステムライフサイクルにおいて実施するセキュリティ検査の代表例には、「ソース

コードセキュリティ検査」の他に、「ファジング」、「脆弱性診断」などがある。

本章では、「ソースコードセキュリティ検査」「ファジング」、「脆弱性診断」の特徴を解説する。まず、各セキ

ュリティ検査の特徴の比較まとめを表 1に示す。

表 1 各セキュリティ検査の特徴の比較まとめ

検査手法/[実施工程]

ソースコードの

必要性

検査可能な

脆弱性の種類

問題箇所の

特定

現象の確認

脆弱性の

種類の判定

ソースコードセキュリティ検査

/[3.実装]

必要

(ホワイトボックス)

広範囲の種類の

脆弱性

可能 不可能 可能

ファジング/[4.テスト] 必要なし

（ブラックボックス）

主にリソース管理5に

関する脆弱性

不可能 可能 不可能

脆弱性診断/[4.テスト] 必要なし

（ブラックボックス）

限定的な種類の

脆弱性

（主に一般に知られて

いる脆弱性）

不可能 可能 可能

次に、表 1をもとに各セキュリティ検査の特徴を解説する。

「ソースコードセキュリティ検査」

「ソースコードセキュリティ検査」とは、ソフトウェアの内部構造を考慮したセキュリティ検査手法(ホ

ワイトボックス)である。「ソースコードセキュリティ検査」の特徴は以下の通りである。

・ 内部構造を考慮し検査を行うため、稀にしか実行されない箇所にある脆弱性の検出が可能。

・ ソースコード上の問題個所の位置を容易に特定することが可能。

・ すぐには悪用できない潜在的な脆弱性も検出する。

・ 脆弱性を悪用された場合にどのような現象が起こりうるのか、確認ができない。

「ファジング」

「ファジング」とは、ソフトウェアの内部構造は考慮せず、ソフトウェアの意図しないデータ群（例え

ば、非常に長い文字列など）を検査対象であるソースコードを実行形式等に変換したプログラム(実

行形式)に入力し、ソフトウェアの応答を観察するセキュリティ検査手法 (ブラックボックス)である。

「ファジング」の特徴は以下の通りである。

・ 悪用された場合の現象（例えば、ソフトウェアが強制終了すること）を確認し、検出を行うため、

すぐに悪用される可能性がある脆弱性を検出できる。

・ 内部構造を考慮しないため、「ソースコードセキュリティ検査」のように、稀にしか実行されない

箇所にある脆弱性の検出が困難。

・ 発生した事象を起点として、その処理を担当する箇所を問題個所は、別途ソースコードから探

し出し、修正する必要がある。

5 例えば、メモリ管理に関する脆弱性が該当する

10

脆弱性診断

「脆弱性診断」とは、検査対象のシステムやソフトウェアに対して、一般的に知られている攻撃手

法(特定のパターン等)を送信し、特徴的な応答を観察することで、脆弱性が存在するかどうかを検

出するセキュリティ検査手法(ブラックボックス)である。「脆弱性診断」の特徴は以下の通りである。

・ 「ソースコードセキュリティ検査」や「ファジング」とは異なり、すでに一般に知られている脆弱性

を主な検査対象とする。

・ 攻撃手法(特定のパターン等)は異なるものの、ソフトウェアの内部構造をあまり考慮しない点や、

システムやソフトウェアの応答を観察する点では、「ファジング」に似ている。

・ 特定のパターンを用いて検査を実施し、検査に対する応答に観察することで脆弱性を検出する

ため、脆弱性の種類まで判定できる。

・ 脆弱性が存在する箇所まで特定することはできない（検査対象がシステムの場合、問題のある

ソフトウェアの特定は可能）。

これらの脆弱性検出手法には一長一短がある。また、どのセキュリティ検査も、存在する脆弱性を必ず

検出できるとは限らない。そのため、いずれかのセキュリティ検査を実施すればよいというわけではない。

開発しているソフトウェアの性質や、状況に合わせて適宜方針を検討して、実施することが重要である。

2.4. 「ソースコードセキュリティ検査ツール」の有効な場面

本章では、「ソースコードセキュリティ検査」の有効な場面について説明する。

「組込み機器」や、「制御システム」開発における利用

昨今インターネット等のネットワークに接続する「情報家電」や「携帯機器」などの「組込み機器」が増加

している。しかし、これら「組込み機器」はソフトウェアの修正を行い、「修正プログラムを公開したとしても

機器を停止することができない」、「修正プログラムの適用方法が周知できていない」などの理由から修

正プログラムが適用されづらいといわれている。また、「制御系システム」などは、脆弱性を作りこんだま

ま出荷してしまうと、脆弱性を悪用されてしまった場合、社会的影響が大きく、ソフトウェア開発者の会社

経営にとっては致命的となりうる。

このような「組込み機器」や、「制御システム」の開発現場において、「ソースコードセキュリティ検査ツー

ル」を利用することで、出荷前に脆弱性を検出・修正できる。その結果、新たに脆弱性が発見された場合、

対応に追われるといったことを、少なくすることができる。

脆弱性に関する知見があまりない開発現場における利用

実際の開発においては、一部の機能の開発を請負会社に委託することがなされている。そのような場

合においては、ソフトウェア開発に関わる開発者全員が必ずしも脆弱性に関する知識を有しているとは

限らない。そのため脆弱性に関する知見がない開発者が実装したソフトウェアには、数多くの脆弱性が

埋め込まれてしまっている場合が多い。

これらの脆弱性は、[4.テスト]工程におけるセキュリティ対策である、「脆弱性診断」や「ファジング」で発

見されることもあるが、これらの検査では問題の個所までは特定できない。また、脆弱性の種類も分から

ない場合もある。そのため、実際の開発者が修正しようとしても、問題の個所の特定に時間がかかる。ま

た修正できないといった可能性がある。

このような状況において、「ソースコードセキュリティ検査ツール」は有効である。「ソースコードセキュリ

ティ検査ツール」は、問題の個所を特定できるため、開発者による修正が容易となる。また、商用製品の

「ソースコードセキュリティ検査」においては、脆弱性の修正方法を提示するものもある。そのため、開発

11

者に知見が少なくとも、修正ができる。

また、このように「検出」「修正」を繰り返すことで、開発者自身の脆弱性に関する知見のスキルアップ

にもつながる。

大規模ソフトウェア開発における利用

多くのソフトウェア開発企業では「セキュアプログラミング」が実践されているかどうかを確認するため、

人手による「ソースコードレビュー」が実施されている場合もある。小規模ソフトウェアにおいては、人手に

よる「ソースコードレビュー」でも、脆弱性の検出できる可能性はあるが、大規模ソフトウェアとなると、検

査対象となるソースコードの量は膨大となり、そのコストも膨大である。

また、大規模であるがため、「ソースコードレビュー」を実施した場合、単一のソースコードでは問題が

ないが複数のソースコードが原因で問題となる脆弱性は、見落とされてしてしまう可能性がある。

この様な場面において、複数のソースコードをまとめて検査し、自動的に問題個所を検出可能な「ソー

スコードセキュリティ検査ツール」を利用するとで、コストを大幅に削減することができる。

12

3. 「ソースコードセキュリティ検査」ツールの有効活用事例

本章では、「ソースコードセキュリティ検査ツール」の有効活用事例について紹介する。事例をもとに、「ソ

ースコードセキュリティ検査」の有効性と効果を確認することを目的としている。

3.1. 活用事例(1)

~ 組込み機器開発ベンダーA 社における活用事例 ~6

組込み機器開発ベンダーA 社では、出荷されるすべての製品に対して、「ソースコードセキュリ

ティ検査ツール」を用いた検査を実施し、脆弱性の検出を行っている。また、協力会社等に製品の開

発を外注する際にも、コーディングルールを提供するとともに、「ソースコードセキュリティ検査ツー

ル」による検査の実施を義務付けるなど、出荷される製品のセキュリティ対策を徹底している。こうし

た背景には、過去、すでに出荷されてしまった「組込み機器」製品の脆弱性に関する報告を受けてい

た経緯がある。

A 社が、「ソースコードセキュリティ検査ツール」を導入するにあたっては、開発現場の実情を踏ま

えて、円滑な導入を進めるために、下記の対応を行った。

1). 部門費ではなく本社費によるツールの導入

2). 実装工程におけるツール検査の義務化

3). 定期的なセミナー開催による技術者の育成と意識づけ

A 社によると、「ソースコードセキュリティ検査ツール」による検査を義務化して以降、出荷後の製

品における、任意のコードが実行されてしまう致命的な脆弱性7の報告はなくなったとのことである。

また、ソースコードセキュリティ検査ツールの利用により、ソースコードに残留する脆弱性が可視

化された。その結果、開発者のセキュリティ対策への意識が高まるといった二次的効果がえられた。

ソフトウェアの実装工程において開発担当者自身が「ソースコードセキュリティ検査ツール」を利用し、製

品の出荷前に脆弱性を発見・修正している。本事例からは、「ソースコードセキュリティ検査ツール」を利用

することで、出荷する製品のセキュリティ品質を向上することができることがわかる。また、開発担当者のセ

キュリティ対策への意識が高まり、次の製品の開発においては脆弱性を作りこまない様にするなどといった

効果も得られているという。

「ソースコードセキュリティ検査ツール」を導入するにあたり、障壁となるコスト負担や開発体制といった開

発現場の実情への対応方法のヒントが見て取れる。

6 本内容は、IPAが独自に A社にヒアリングを行った結果をもとに執筆している。 7 バッファオーバーフローの脆弱性などのリソース管理に係る脆弱性

13

3.2. 活用事例(2)

~ SDNA における活用事例 ~8

ソニーデジタルネットワークアプリケーションズ株式会社(以下 SDNA と呼ぶ。) では、2002 年か

らセキュリティ対策の専門チームを開設し、「ソースコードセキュリティ検査ツール」を利用して開発し

たソフトウェアの検査を実施している。

SDNAは、2006年度の開発 26件において、本技術を用いて 178件の脆弱性が発見できたと報

告している。SDNA における脆弱性への対策費用は、約 100 万円/件であり、トータルで、約 1 億

7,800万円の対策費用を事前に削減できたとしている。

一方、SDNA によると、セキュリティ検査に関するコストは、製品開発費用全体の約 5%以下との

ことである。

ソフトウェアの実装工程において、「ソースコードセキュリティ検査ツール」を利用することで、実際に製品

の出荷前に多くの脆弱性を発見・修正している。また、「ソースコードセキュリティ検査ツール」を利用するこ

とで、製品出荷後に発見される脆弱性への対策費用を削減している。

本事例からは、「ソースコードセキュリティ検査ツール」を有効活用することで、出荷した製品の脆弱性へ

の対策費用を削減するといった、コスト面における効果が得られることがわかる。

3.3. 活用事例(3)

~ IPA のツール開発における活用事例 ~

IPA では、「ウェブサイト攻撃の検出ツール iLogScanner V3.0 の開発」9を実施する際、開発す

るツールに対する「セキュリティ検査の実施」を要件として提示した。

請負業者は、この要件に伴い、開発したツールに対して商用の「ソースコードセキュリティ検査ツ

ール」による検査を実施した。その結果、開発したソフトウェアのソースコードの中に 11 件の問題個

所を確認した。請負業者は、「ソースコードセキュリティ検査ツール」が出力したレポートをもとに、こ

れらの項目が脆弱性であるか否かを分析し、IPAに対して報告を行った。

IPA と請負業者は、検出された問題箇所のみの確認だけで、作成されたソフトウェアの一定の安

全性を確認できた。

第三者視点で検査が可能な「ソースコードセキュリティ検査」を実施することで、IPA が要求するセキュリ

ティ品質に対する要件を満たした事例である。

昨今、ソフトウェアやシステム発注側は、システム検収における要件として、第三者視点で検査が可能な

セキュリティ検査ツールによる検査の実施の要件化等の事例が増えてきている(動向は 4 章で説明する)。

「ソースコードセキュリティ検査ツール」が出力するレポートを有効活用することで、ソフトウェアの一定の安

全性を効率的に確認できる。

8 出典元:日経エレクトロニクス 2007年 5月 7日号「組み込みセキュリティー待ったなし！」P93-94「1億 7800万円分のリスクを回避」 9 ウェブサイト攻撃の検出ツール iLogScanner V3.0の開発, IPA, http://www.ipa.go.jp/security/vuln/iLogScanner/index.html

14

4. 「ソースコードセキュリティ検査」に係る最新動向

組み込み系や重要なシステムに対しては、3章で述べたように、「ソースコードセキュリティ検査」が取り入

れられてきている。特に以下のような課題に直面しているシステムのソフトウェアでは、「ソースコードセキュ

リティ検査」は避けて通れない要件となってくるものと思われる。

・ 長期間利用（10年以上におよぶ利用）

・ ソフトウェアの更新が困難（セキュリティパッチ等の対応）

・ 高いセキュリティレベルの要求（金銭被害や人命などに関わる事象への影響）

こうした分野の例として、以下では 3つを取り上げる。

(1). 制御システム

制御システム分野においては、昨年発覚したウイルス「Stuxnet」 などもあり、セキュリティへの意識が

高まってきている。制御システムセキュリティの標準を規定し、それに沿った評価や認証などを目指す動き

が盛んになってきている。その標準や評価・認証の活動として、 IEC62443 と ISASecure

EDSA(Embedded Device Security Assurance)が挙げられる。それらでは、装置に内蔵されるシステム

のセキュリティ機能、開発工程、テスト仕様などが規定されている。評価・認証が先行している ISASecure

EDSAでは、認証レベルによって、開発工程での、ソースコード検査（Static Analysis）やセキュアコーディ

ング規約準拠などが、認証取得の要件として挙げられている

(2). 機能安全規格（IEC61508）

機能安全(Functional Safety)とは、システムの安全性を確保、向上するための規格で、広範囲の業界

に関わってくる規格である。自動車業界においては ISO26262 がそれにあたる。それらの規格の認証にあ

たっては、決められたルールの準拠を検証するためのツールとして、商用の「ソースコード検査ツール」が認

証されている。

(3). クレジットカード利用業界（PCI DSS : Payment card industry data security standard）

PCI DSS Ver2.0 では、要件 6.3.2 に、「コーディングの脆弱性がないことを確認するために、本番また

は顧客へのリリースの前に、カスタムコードをレビューする。

注: このコードレビュー要件は、システム開発ライフサイクルの一環として、すべてのカスタムコード（内

部および公開）に適用される」といった記載がある。それに準拠するために、人手による対応も考えられる

が、膨大なソフトウェアに対しては、自動化された検査ツールの適用が効果的な選択肢となってくる。

このように、標準規格や業界ガイドライン等で、ソースコード検査が取り入れられていく方向にある。

開発工程でのコスト負担が当面の課題であるが、ソフトウェアの開発、運用、保守のライフサイクルにお

けるトータルコストの観点に立って、ソースコード検査の活用を検討していくことが重要である。

15

5. 今後の IPA の取り組み

IPA では、システムライフサイクルに沿った脆弱性への対策を推進しており、安全な情報システム社会の

確立に寄与することを目標に、これまでシステムライフサイクルの各工程に合わせたコンテンツ（ガイド、報

告書、ツール等）の提供を行ってきた。

図 6 システムライフサイクルの各工程に合わせた IPAのコンテンツ

IPA では、本レポートでこれまで説明してきた「ソースコードセキュリティ検査」の普及を図ることで、安心・

安全な IT社会の実現の確立を寄与できると考える。

そこで、IPAでは、重要性と有効性を実体験可能な、「IPAソースコードセキュリティ検査ツール(仮称)」（以

降、本ツールと呼ぶ。）の開発を進めている10。本ツールは、「ソースコードセキュリティ検査」技術の有効性・

重要性に関する教育に主眼を置き、開発現場等や教育機関で利用されることを想定して、一般公開を予定

している。

今後公開を予定している本ツールが、「ソースコードセキュリティ検査」の実用性・有効性を認識するため

の一助となり、実際の開発現場における開発プロセスへの「ソースコードセキュリティ検査」導入されるこ

とを期待します。

本ツールの特徴

IPAツールの利用イメージを図 7 に示す。

10「ソースコードセキュリティ検査ツール開発」に係る一般競争入札,IPA, http://www.ipa.go.jp/about/kobo/tender-20110824/index.html

1.要件定義 2. 設計 3. 実装 4. テスト 5. 運用 / 利用 6. 廃棄

■ 運用時対策

■ 脆弱性対策

■ セキュアプログラミング技法

■ ソースコードセキュリティ検査

■ 脆弱性診断（ﾍﾟﾈﾄﾚｰｼｮﾝ）

攻撃

■ テスト（ﾌｧｼﾞﾝｸﾞ他）

脆弱性脅威

■ 調査、動向把握、開発方針・体制整備（ﾋﾞｼﾞﾈｽｲﾝﾊﾟｸﾄ分析含む）

システム

ライフサイクル

セキュリティ対策

における施策

IPA

＜調査・ガイド類＞• 組込みシステム向け• 制御システム向け• 自動車向け• 情報家電向け• 生体認証導入、運用ガイド

■ 10大脅威■ 情報セキュリティ白書■ 知っていますか？脆弱性

■ 安全なWebサイトの作り方■ 安全なSQLの呼び出し方■ セキュアプログラミング講座

■ 開発者向け脆弱性実習ツール： AppGoat

■ TCP/IP 脆弱性

検証ﾂｰﾙ

■ SIP 脆弱性

検証ﾂｰﾙ

■ Web攻撃検出ツールiLogScanner■ WAF読本■ 安全なWebｻｲﾄ運営入門■ 5分でできる！情報ｾｷｭﾘﾃｨﾎﾟｲﾝﾄ学習

【届出制度／脆弱性／ウイルス】■ 脆弱性届出制度（製品/Web)■ JVN, JVN iPedia, MyJVN■ｳｲﾙｽ、不正ｱｸｾｽ届出制度■ 安心相談窓口

■ソースコードセキュリティ検査ツール(仮称)

16

図 7 IPAツールの利用イメージ

また、IPAで開発を進めているツールの特徴11は以下の通りである。

1). 作りこみやすく、危険度が高い脆弱性を検出

検出対象とする脆弱性を、任意のコード実行に至る可能性ある脆弱性に限定している12。

一般的な商用製品やツールと比べて検出可能な脆弱性が限定されるが、本ツールを利用す

ることで、任意のコード実行に至るなど脆弱性の悪用された場合に影響が大きい脆弱性が検

出されることが期待できる。

2). 利用度の高い言語を対象

利用度が高く13、脆弱性を作りこみやすい C言語（ANSI C）を対象としている。また、C言語

は脆弱性を修正するための修正プログラムが適用されづらいと言われている「組込み機器」

の開発現場で多く利用されており、実際の開発現場に本技術の有効性を示すことで、安全な

情報システム社会の確立が期待できる。

3). 詳細レポート機能

オープンソースソフトウェア等のツールにはない、詳細レポート機能を持つ。本機能により、

脆弱性を検出するだけでなく、脆弱性の存在する箇所や修正方法例までが利用者に提示さ

れる。そのため、利用者は、レポートの内容を参考に、脆弱性の存在する箇所を修正まで行

うことができる。

4). 簡単検査機能

利用方法、利用手順を単純化している。仮想イメージでの配布を検討するなど、ツールの

導入に向けた技術的な閾を下げたり、簡易なウェブインタフェースを用意したりすることで、教

育現場等において技術的に明るくない方々にも簡単に利用できるように配慮している。

11 本レポート執筆時での特徴であり、変更される場合がある 12 検出可能な脆弱性の具体例は付録 2を参照のこと。 13 TIOBE Software, http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

IPAツール

IPAの既存コンテンツ

IPAツール

組み込み開発向けソースコード診断ツール

1. main.c - 27行目2. main.c - 101行目3. util.c - 327行目

・・・・・・・・・

1. main.c - 27行目

・・・・・・

■脆弱性・問題の解説

■本脆弱性・問題の脅威

■対策（修正方針）

■参考情報

・・・

・・・

・・・

・・・

作成した脆弱なプログラム

修正した安全なプログラム

①プログラムを作成する

②作成したプログラムに脆弱性がないか、ツールで確認する

③ツールの検査結果レポートを利用して自身が作成したソースコードの脆弱な箇所を把握し、対策方法(何が問題で、どう直せば良いか)までを学習する

④自身でプログラムの脆弱な箇所を修正する

⑤安全な開発手法を身に付けることができる

17

付録 1:「ソースコードセキュリティ検査」の具体例

本章では、「ソースコードセキュリティ検査ツール」の内部動作イメージを、具体例を交えて解説する14。

例えば、下記のような C言語のソースコードの場合、基本的な原理は次の通りである。

1 #define HEADER_SIZE 8

2

3 int vuln_func(char *data, int dlen)

4 {

5 char *buf;

6 int size;

7

8 if (dlen == 0)

9 return -1;

10

11 size = dlen + HEADER_SIZE;

12 if (!(buf = malloc(size)))

13 return -1;

14

15 memset(buf, 0, HEADER_SIZE);

16 memcpy(buf + HEADER_SIZE, data, dlen);

17

18 return handle_data(buf, size);

19 }

付録図 1 脆弱性が存在するソースコード例

1). vuln_func 関数を検査対象とし、関数内の処理の検査を開始する（行:3）。

2). 関数の引数である、 dlen が符号付の int 型変数であることを認識する（行:4、5）。

3). dlen に HEADER_SIZE を加算しており、整数オーバーフローが発生する可能性を認識する

（行:11）。実際、 dlen に入力される値が、「0xfffffff8」であった場合、整数オーバーフローが発

生し、値が 0 となる（0xfffffff9の場合は、1 となる）。

4). 整数オーバーフローが発生する可能性がある変数 dlen を引数に、メモリ確保を行う malloc 関数

を呼び出していることを認識する（行:12）。これにより、 malloc 関数により確保されたバッファのサ

イズが不適切である可能性を認識する。

5). 確保されたバッファのサイズが不適切である可能性のあるバッファ buf に対して、 memset 関数、

及び memcpy 関数を呼び出していることを認識する（行:15、16）。これにより、バッファサイズが不適

切であるためバッファオーバーフローが発生する可能性を認識する。

6). 前述の問題が存在する可能性がある変数 buf 及び size を引数に、 handle_data 関数を呼び

出していることを認識し、継続して handle_data 関数の検査を実施する(行:18)。

このように、検査対象（vuln_func 関数）に対する入力、及び内部処理に基づいて問題が発生する可能

14 あくまでも内部動作イメージの一例であり、「ソースコードセキュリティ検査ツール」の仕様により実際の動作は異なる可能性がある。

18

性が存在する認識、検出する。

上記の例では、項番 3) が問題の起点になっており、その問題が項番 4) ～ 6) に継続して引き継がれ

ている。セキュリティ上の観点では、項番5) においてバッファオーバーフローが発生する可能性がある。但

し、実際の「ソースコードセキュリティ検査ツール」が、項番 3) ～ 5) のどの時点で問題個所として検出す

るかについては、そのツールの機能、仕様によって異なる。

19

付録 2: 「IPA ソースコードセキュリティ検査ツール(仮称)」の検出対象の脆弱性15とその選定方法

本章では、IPAソースコードセキュリティ検査ツール(仮称)」(以下、本ツールと呼ぶ。) で検出可能な脆弱

性タイプとその選定方法ついて解説する。

IPA では、「ソースコードセキュリティ検査」の教育という観点から、本ツールで全ての脆弱性を網羅的に

検出する必要はないと考えた。

そこで、IPAは、本ツールで検出可能な脆弱性を、米MITRE社が提供している共通脆弱性タイプ一覧：

CWE(Common Weakness Enumeration)16の脆弱性タイプをもとに選定を行うこととした。CWE の脆弱

性タイプは、ビュー（View）、カテゴリー（Category）、脆弱性（Weakness）、複合要因（Compound

Element）の4 種類に分類される。本レポート執筆時点での最新バージョンである、Version 2.1には、ビュ

ー（View）として 27個、カテゴリー（Category）として 157個、脆弱性（Weakness）として 693個、複合要因

（Compound Element）として 9個、合計 777個の脆弱性タイプが分類され一覧となっている。

この CWEで定義される脆弱性（Weakness）693個の中から本ツールで検出可能な脆弱性タイプを IPA

では、下記の要件のもと選定を行った。

1. 任意のコード実行に至る可能性ある致命的な脆弱性タイプ

CWE を参考に、脆弱性を悪用された場合影響度が大きいと考えられる任意のコード実行に至る

可能性ある脆弱性に絞り選定。

2. 開発者が作りこみやすい脆弱性タイプ

米MITRE社より公開されている「作りこまれた脆弱性種別毎の分布」17や「脆弱性対策情報デー

タベース JVN iPediaの登録状況」18を参考に、開発者が作りこみやすい脆弱性を選定

また IPA では、上記の選定結果に加えて「ソースコードセキュリティ検査」で検出することが望ましい脆弱

性タイプという観点から、本ツールが検出可能な脆弱性タイプの要件を以下の 6種類に絞り込んだ（付録表

1）。

付録表 1 「IPAソースコードセキュリティ検査ツール(仮称)」の検出対象の脆弱性タイプ一覧

No. 脆弱性タイプ CWEの識別子

1 入力サイズ未チェックでのバッファコピー CWE-120

2 配列インデックスの誤った検証 CWE-129

3 ポインタ変数に対する sizeof の使用 CWE-467

4 書式文字列の問題 CWE-134

5 整数オーバーフローの問題 CWE-190

6 符号付き変数の変換に関する問題 CWE-195

6 種類と限定したものの、致命的な脆弱性が数多く発見されることが期待できるため、「ソースコードセキ

ュリティ検査ツール」の有効性や重要性の教育目的のツールとしては、有効であると考える。

以上

15 本レポート執筆時での特徴であり、変更される場合がある 16 共通脆弱性タイプ一覧 CWE概説, IPA , http://www.ipa.go.jp/security/vuln/CWE.html 17 Vulnerability Type Distributions in CVE , MITRE, http://www.cve.mitre.org/docs/vuln-trends/index.html 18 脆弱性対策情報データベース JVN iPediaの登録状況, IPA , http://www.ipa.go.jp/security/vuln/report/press.html#JVNiPedia