【18-B-4】ソースコード品質、大丈夫ですか？　～静的検証のススメ～

ソースコード品質、大丈夫ですか？
～静的検証のススメ～

18-B-4 田邊照雄
株式会社日立ソリューションズ

Developers Summit 2011

自己紹介
日立中部ソフトウェア(
日立中部ソフトウェア(株) 入社
Windows系アプリケーション開発に従事
Windows系
- ソフトウェア生産技術支援ツール
- CASEツール
CASEツール
- 組込みシステム開発支援ツール等
(株)日立システムアンドサービス
ソフトウェア品質管理ソリューション事業に従事
- ソースコード静的解析サービス
- 品質管理、検証支援
２０１０年１０月 (株)日立ソリューションズ誕生

自己紹介（社外活動）
２００３年 MISRA-C研究会に参加
MISRA-
２００４年「組込み開発者におくるMISRA‐C
組込み開発者におくる
におくるMISRA‐
組込みプログラミングの高信頼化ガイド
組込みプログラミングの高信頼化ガイド」出版
みプログラミングの高信頼化ガイド」出版
２００６年「組込み開発者におくるMISRA‐C:2004
組込み開発者におくる
におくるMISRA‐
C言語利用の高信頼化ガイド」出版
言語利用の高信頼化ガイドガイド」出版

２００８年 MISRA-C++研究会に参加
MISRA-C++研究会に参加

目次
1. ソフトウェア開発の課題
2. ソースコードの品質向上へ向けて
3. コーディングルール策定
4. コードチェックツール
5. レビュー
6. 静的検証
7. オープンソースの適正利用
8. まとめ


１．ソフトウェア開発の課題

エンドユーザ様の
満足度向上

コスト削減人財不足
開発プロジェクトでは
全てに対応することが
開発競争求められるシステムの
優位のための複雑化による
開発期間短縮開発量の増加
欠陥、情報漏洩
コンプライアンス等
社会問題の予防

ソフトウェアを計画通りに開発することは極めて困難になっている
ソフトウェアを計画通りに開発することは極めて困難になっている
計画通りに開発することは困難

欠陥の発見が遅くなるほど、修正費用は高くなる。
$16,000
85% % 欠陥が作りこまれ $ 欠陥を訂正するために
る割合要する行あたりのコスト
Percentage of Bugs

% 欠陥が発見される割合
納入後対策コスト＞＄１,０００/行

$1000
如何にして前工程で
$130 $250
$25 品質を確保するか
Coding 単体機能総合リリース後
Test Test Test Source: Applied Software
Measurement, Capers Jones, 1996

開発委託範囲

開発工数削減効果
バグ修正コスト 10.0-50.0
50

40
相
対
コ 30
ス
トコーディング工程で不具合を発見す
20 ることによって、修正工数が減少
→ 作業工数の削減 15.0
4.0-10.0
10 1.5-4.0
0.2-1.0 1.0 5.0
0.1-0.6
2.0
0 0.3 0.5
要求定義設計コーディング単体/結合総合/受入運用
テストテスト
出典：日本規格協会「ソフトウェア品質ガイドブック」
出典：日本規格協会「ソフトウェア品質ガイドブック」
品質ガイドブック

２．ソースコードの品質向上にむけて
日立ソリューションズの活動例

開発機能詳細コーデ単体結合総合
ベンダ設計設計ィングテストテストテスト

品
納
発質
品
注状
況

要求受入
発注元仕様検査




設計手法プログラミングレビュー品質保証活動
の選定言語の
言語の選定コードチェックツール
ソースコード
コーディングルール策定
コーディングルール策定静的検証
納
オープンソース発振り返り
構成管理
品
選定注オープンソース
品質メトリクス評価
メトリクス利用状況検証

品質保証戦略品質啓蒙活動第三者検証

要求受入

xxx ：ソースコード品質の確保へ向けた活動



設計手法プログラミング品質保証活動
の選定言語の設計～
言語の選定設計～実装
・コードチェック納入時の検証
発注時に
発注時に条件提示納入時の納
ツール振り返り
・コーディングルール発・レビュー
・ソース静的検証
品
構成管理・オープンソース
・オープンソース注
メトリクス利用状況
利用可否


要求受入

xxx
xxx
：ソースコード品質の確保へ向けた活動

なぜ、ソースコードにバグを作り込むのか？
■ 言語の自由度
・ C/C++；メモリ、アドレスの操作が可能、フリーフォーマット
C/C++；メモリ、アドレスの操作が可能、フリーフォーマット
・ Java；膨大な部品、フリーフォーマット
Java；膨大な部品、フリーフォーマット

■ 言語仕様の奥深さと複雑さの理解
◆ 言語仕様を理解している
- 上級エンジニアの水準
コードチェッカやコンパイラの処理系定義の動作、未定義の動作
等を理解しており、言語仕様の危険性を認識している
等を理解しており、言語仕様の危険性を認識している
▼ 言語の一部の機能についておおよその知識がある
- 大半のエンジニアはこの水準
プログラミング言語で「できること」の知識を持ち、実装手段として
プログラミング言語で「できること」の知識を持ち、実装手段として
認識している
認識している（‥ 時として、中途半端な知識への過信）

危険性の理解が無いと、エンジニアが想定しない欠陥を作りこむ！

３．コーディングルール策定
記述できる自由度が高い
- マニアックなコーディングをすると理解が困難になる

while( (i < n) && (a[ i++ ] == b[ i ] ) ) {
(i
[問題点]
問題点]
処理1;
a[ｉ]とa[i+1]のどちらを
処理1;
}
b[i]と比較している?

a[i]==b[i
a[i]==b[i]
[メリット?]
メリット?]
どっち?
どっち
コードの行数を減らせられる
a[i+1]==b[i
a[i+1]==b[i]
while( (i < n) && (a[ i ] == b[ i ] ) ) {
i++;
処理1;
処理1;
ステップ数
ステップ数は増えても、
えても、
}
わかりやすい


言語仕様の理解不足
- 正しくコーディングしたつもりが意図しない動作になる

ソースコードユーザの意図
ユーザの意図
x = a<<b + 1; x = (a<<b) + 1;
#define multiple(a,b) (a*b)

a = multiple(x, x+1); a = x * (x+1)
a[0] = 0010; a[0] = 10;
a[1] = 0100; a[1] = 100;
a[2] = 1000; a[2] = 1000;
(a<-
if ( (a<-3) || (a>3) (a<-
if ( ( (a<-3) || (a>3) )
(b<-
&& (b<-3) || (b>3) ){ (b<-
&& ( (b<-3) || (b>3) ) ){



ユーザの意図実際の
実際の動作
x = a<<b + 1; x = (a<<b) + 1; x = a << (b+1);
#define multiple(a,b) (a*b)

a = multiple(x, x+1); a = x * (x+1) a=x*x+1
a[0] = 0010; a[0] = 10; a[0] = 8;
a[1] = 0100; a[1] = 100; a[1] = 64;
a[2] = 1000; a[2] = 1000; a[2] = 1000;
(a<-
if ( (a<-3) || (a>3) (a<-
if ( ( (a<-3) || (a>3) ) (a<-
if ( (a<-3) ||
(b<-
&& (b<-3) || (b>3) ){ (b<-
&& ( (b<-3) || (b>3) ) ){ (b<-
( (a>3) && (b<-3) ) ||
(b>3) ){


<<演算子より演算子の
<<演算子より +演算子の方が
演算子
優先順位が
優先順位が高い

ユーザの意図実際の
実際の動作
x = a<<b + 1; x = (a<<b) + 1; x = a << (b+1);
multiple(a,b
a,b)
#define multiple(a,b) (a*b) マクロの展開はマクロ引数
マクロの展開はマクロ引数
展開はマクロ
がそのまま置換
置換される
がそのまま置換される

a = multiple(x, x+1); a = x * (x+1) a=x*x+1
a[0] = 0010; 0で始まる定数
まる定数 a[0] = 10; a[0] = 8;
a[1] = 0100; 進数とし
は、8進数とし a[1] = 100; a[1] = 64;
解釈される
て解釈される
a[2] = 1000; a[2] = 1000; a[2] = 1000;
(a<-
if ( (a<-3) || (a>3) (a<-
if ( ( (a<-3) || (a>3) ) (a<-
if ( (a<-3) ||
(b<-
&& (b<-3) || (b>3) ){ (b<-
&& ( (b<-3) || (b>3) ) ){ (b<-
( (a>3) && (b<-3) ) ||
(b>3) ){
||演算子より &&演算子
||演算子より &&演算子の方が
演算子演算子の
優先順位が
優先順位が高い


狙い：
- ケアレスミスによる不良作り込みの予防
- 移植性確保、保守性確保

ポイント：
- コーディングルールの必要性の理解徹底

■コーディングルールで防止できる不良の例
コーディングルールで防止できる不良の
防止できる不良
▼ 条件判定誤り（演算子優先順位の理解誤り）
▼ 演算誤り（等価演算子の“=”漏れ、演算子優先順、など）
▼ 変数定義の考慮不足（オーバフロー、符号反転、負値の切上げ、など）
▼ 変数初期化もれ（変数への初期値設定もれ）
▼ サイズなしコピー関数の使用（バッファオーバフロー、システム破壊、など）


コーディングルールが機能しない理由：
- ルールが覚えられない
- ルールのチェックが大変

策定時のポイント：
世の中にあるものをベースにして、簡単に作る。
ルール数は必要最小限に。たくさん規定しても覚えられない。
プロジェクトや組織の課題に応じて、導入ルールの優先度を定める。
ルールの目的、ルールからの逸脱時のリスクを、コード例を用いて実習する。
ルールからの逸脱をどういう場合に認めるか、そのルールも定める。
社内で統一した規約とし、プロジェクト毎の派生版はできるだけ作らない。
現行のコーディングスタイルの傾向を調査し、現場にマッチした導入しやすい規約を作る。
コーディング規約を守らせる（守られているかどうかチェックする）仕組みも同時に作る。
ルールからの逸脱を、機械的にチェックできないようなルールは作らない。


コーディングルール策定時に参考となる資料
◆ ESCR
「組込みソフトウェア向けコーディング作法ガイド」
組込みソフトウェアけコーディング作法ガイド」
みソフトウェア向作法ガイド
◆ ESCR C++言語版
C++言語版
「組込みソフトウェア開発向けコーディング作法ガイド C++言語版」 C++言語版」
◆ MISRA (The Motor Industry Software Reliability Association)
MISRA-C：2004
MISRA-
Guidelines for the use of the C language in critical systems
◆ Sun Microsystems, Inc.
Code Conventions for the Java TM Programming Language
◆ 各プロジェクトのコーディング規約
GNU Coding Standard
Linux Kernel Coding Style

規約・基準の目的を理解した上で活用すること

規約・
規約・規則目的
ESCR, 組込みソフトウェアを作成する場合に、ソース
ESCR C++ コードの標準化や品質の均一化を進めること
1）新規コーディング規約の作成
2）既存コーディング規約の充実
3）プログラマの研修、独習のための学習教材
出典：翔泳社「組込みソフトウェア開発向けコーディング作法ガイド」

MISRA-C 組み込みシステムで、安全性と移植性と信頼性
MISRA-C++ を確保すること
出典：http://www.misra.org.uk

GNU Coding Standard GNUを綺麗に、一貫性を保ち、導入しやすいシ
ステムにすること
出典：http://www.gnu.org/prep/standards/standards.html

Linux Kernel Coding Linux Kernel の開発者が管理しなくてはならな
Style いことを守らせる
出典：http://lxr.linux.no/linux/Documentation/CodingStyle


(ご参考)Linux Kernel Coding Style の一例
ご参考)Linux
・ Chapter 1: Indentation
… Especially when you've been looking at your screen for 20 straight hours,
you'll find it a lot easier to see how the indentation works if you have large
indentations.
・ Chapter 4: Naming
… Encoding the type of a function into the name (so-called Hungarian
(so-
notation) is brain damaged - the compiler knows the types anyway and can
check those, and it only confuses the programmer.
・ Chapter 6: Functions
… Another measure of the function is the number of local variables. They
shouldn't exceed 5-10, or you're doing something wrong. Re-think the function,
5- Re-
and split it into smaller pieces. A human brain can generally easily keep track
of about 7 different things, anything more and it gets confused.
・ Chapter 8: Commenting
… NEVER try to explain HOW your code works in a comment: it's much better
to write the code so that the _working_ is obvious, and it's a waste of time to
explain badly written code. 出典：http://lxr.linux.no/linux/Documentation/CodingStyle
出典：http://lxr.linux.no/linux/Documentation/CodingStyle

適用事例
・医療機器メーカ
・導入前の課題
- 長年の実績に裏打ちされた独自ノウハウによる開発プロセス。
- 更なる改善のため第三者視点かつ現場に即した改善策が必要。
・日立ソリューションズの活動
- 現行のソースコードをサンプル調査し、コーディング規約からの
逸脱傾向を分析。より現場にマッチしたコーディング規約に改訂。
・お客様ご評価
- 開発現場と問題意識を共有し、現場と一体で活動いただいた。
- 現場へ浸透しやすいコーディングルールを策定できた。
http://www.hitachi-
http://www.hitachi-system.co.jp/quality/sp/case/


４．コードチェックツール
コーディングルールを策定しても
- 作り手がミスをする可能性がある
- 凡ミスは、目視だと意外に気づかない

例１例２
switch(a){ function(int x){
case 0: int a;
b = 0; if (x > 0){
break; a = function2(x);
case1: } else if (x < 0){
a = 4; a = function2(-x);
default: }
a = 6; return(a);
break; }
}
}


コーディングルールを策定しても
- 作り手がミスをする可能性がある
- 凡ミスは、目視だと意外に気づかない

例１例２
switch(a){ function(int x){
case 0: int a;
b = 0; caseラベル
caseラベル if (x > 0){
break; ではない a = function2(x);
case1: } else if (x < 0){
a = 4; a = function2(-x);
default: breakがない
breakがない }
a = 6; return(a); x==0のとき
のとき、
x==0のとき、
break; } 初期化されない
aが初期化されない
}
}


狙い：
- ケアレスミスによる不良作り込みの予防
- 保守性、可読性の確保
- コーディング規約が遵守されているか確認
- コードレビューの質向上
- 納品物の妥当性検証

ポイント：
- 導入、運用の容易さ
- 不具合の修正のしやすさ
- コスト


ツール選定時のポイント
- プログラミング言語
- 機能
チェック項目、ノイズ(False Positive)の度合い
チェック項目、ノイズ(False Positive)の度合い
- フリー／有償ツール
- 保守、サポートが受けられるか
- ナレッジ、コミュニティの充実度
- ルールのカスタマイズが可能か
- メトリクスの取得が可能か


ツール運用時のポイント
- チェックの頻度、機会
どの工程から？
いつ？（毎週○曜日、ビルド毎、…）
いつ？（毎週○曜日、ビルド毎、…
- ツールの指摘への対処の方針
いつまでに、どれだけ修正するか？
- 運用時の体制
開発者主体、専門の技術グループの支援
- 過去の資産（母体）をどう扱うか？


anyWarp CodeDirector for C/C++



様々な切り口のサマリ情報
のサマリ情報

指摘状況サマリ
指摘状況サマリ

問題部分が一目でわかる
問題部分が一目でわかる
ソースイメージ

チェックが必要なルール、
チェックが必要なルール、
必要なルール
ソースファイル情報
情報へのリンク
ソースファイル情報へのリンク



母体部への指摘は
母体部への指摘は
への指摘
グレーアウト可能
グレーアウト可能

変更箇所に対する
変更箇所に
指摘は色付き
指摘は色付き表示

母体ソース
母体ソース修正後ソース
修正後ソース
母体ソースと修正ソースを
母体ソースと修正ソースを
ソースと修正
並列表示

変更箇所、指摘箇所は
変更箇所、指摘箇所は
色付き
色付き表示
母体部への指摘はグレーアウト可能
母体部への指摘はグレーアウト可能
への指摘はグレーアウト


anyWarp CodeDirector for C/C++ 各種IDEとの連携
各種IDEとの連携
との

インスペクション実行
インスペクション実行

指摘箇所へジャンプ
指摘箇所へジャンプ

インスペクションの結果を
インスペクションの結果を結果
Visual Studioに表示
Studioに

指摘の解説を
指摘の解説を表示


５．レビュー
狙い：
- 欠陥除去、作業成果物の問題発見
- 技術者教育
- プロセス改善

ポイント：
- 安定、統一されたレビュープロセスを確立する
- レビューの目的、範囲の明確化
- 意識の切り替え
（×責任追及 ×重圧を与えるモチベーション）
- レビュー効果を統計分析し、改善に活かす


５．レビュー
主なレビュー手法
レビュー手法
レビュー手法主な目的概要
インスペクション対象の合否判定と専門チームによるレビューを
チームによるレビューを行
対象の合否判定と専門チームによるレビューを行う
プロセス改善
プロセス改善作成者以外の参加者がレビューを主導（モデレータ）
がレビューを主導
作成者以外の参加者がレビューを主導（モデレータ）する
チームレビュー対象の合否判定とインスペクションをチーム内実施するレビュー
対象の合否判定とインスペクションをチーム内で実施するレビュー
プロセス改善
プロセス改善一般的にレビュー」
一般的に「レビュー」と呼ばれる
ウォークスルー成果物のエラーの非公式のレビュー
成果物のエラーの非公式のレビュー
発見作成者が主導し参加者に成果物についてのコメントを
についてのコメントを求
作成者が主導し、参加者に成果物についてのコメントを求
める
ペアプログラミング優れた成果物の
成果物の
れた成果物開発者がのパソコンを共有
共有し
２人の開発者が１台のパソコンを共有し１つのプログラム
作成一緒に作成する
を一緒に作成する
ピアデスクチェック不明点や、間違い/ 作成者以外のただ１人が成果物を調べる
不明点や間違い作成者以外のただ
のただ１成果物を
勘違いの
いの発見
勘違いの発見同席して実施する場合、「
して実施する場合、「２インスペクション」
同席して実施する場合、「２人インスペクション」と呼ぶ
パスアラウンド多数の意見を収集多重同時進行で多くの意見を収集
多数の意見を多重同時進行でくの意見
意見を
アドホックレビュー目前の
目前の問題解決即席のレビュー
即席のレビュー
出典：「ピアレビュー高品質ソフトウェア開発のために」
Karl E. Wiegers著大久保雅一訳日経BPソフトプレス刊
Wiegers著日経BPソフトプレス刊


５．レビュー
日立ソリューションズのレビュー活動例
- 重要な箇所をフェイガンインスペクションの対象とする
(他の個所はアドホックレビューなどでカバー)
アドホックレビューなどでカバー)
- 社内のレビュー教育、認定制度
認定されたレビュアーの参加を義務付け
- レビュー対象物は、事前に anyWarp CodeDirector 等のツールで、
軽微な不良を取り除いておく
- レビュアーは事前にレビュー対象物をチェック
- レビュー実績を測定・分析し、改善に繋げる
- 組織レベルで目標値設定
指標定義
レビュー速度
レビュー速度レビュー対象規模レビュー
レビュー対象規模/レビュー時間
対象規模レビュー時間
指摘密度指摘件数/レビュー対象規模
指摘件数レビュー対象規模
レビュー
レビュー前倒し
レビュー前倒し指摘率
前倒レビュー指摘数総欠陥数
レビュー指摘数/総欠陥数
指摘数
レビュー効率
レビュー効率指摘件数/レビューにかけた工数
指摘件数レビューにかけた工数
レビューにかけた
出典：日立評論 2007年3月号
2007年
「ソフトウェア開発への統計的プロセス制御の適用」株式会社日立ソリューションズ小室睦
http://www.hitachihyoron.com/2007/03/pdf/03_professional.pdf

５．レビュー
ピアレビューの効果
日立ソリューションズ事例
日立ソリューションズ事例
ソリューションズ他社事例
不良の前倒し摘出による手戻りの防止
不良の前倒し摘出による手戻りの防止
による手戻りの IBM社
IBM社の事例
・欠陥がどこで作り込まれどこで
欠陥がどこで作
がどこで
工修正されたかで比率は
修正されたかで比率は異なるが
されたかで比率
数削減可能ピアレビューの方
概ね2～3倍、ピアレビューの方
/
/
/
/

件効率がよい
が効率がよい
・不具合修正コスト
不具合修正コスト
ピアレビューにて発見
- ピアレビューにて発見
上流設計：
上流設計： 2.5人時
2.5人時
下流設計：
下流設計： 1.7人時
1.7人時
コーディング：
コーディング： 1.8人時
1.8人時
ピアレビューテストテスト工程にて発見
工程にて
- テスト工程にて発見
単体テスト
テスト：
単体テスト： 4.3人時
4.3人時
テストで不良を発見・修正する場合と比較し
テストで不良を発見・修正する場合と比較し
不良する場合結合テスト
テスト：
結合テスト： 4.9人時
4.9人時
倍効率がよい
2倍効率がよいシステムテスト： 5.4人時
システムテスト： 5.4人時
出典：SEC Journal 創刊号出典：Stephen H. Kan,
「開発現場の実態に基づいたピアレビュー改善手法と改善効果の定量的分析」 "Metrics and Models in Software Quality Engineering,"
株式会社日立ソリューションズ小室睦、男澤康、木村好秀 Addison-Wesley 2003

他社事例ソフトウェア品質シンポジウム2010
「組込みソフトウェア開発におけるピアレビューの導入と定着化」
http://www.juse.or.jp/software/197/attachs/d3-2.pdf

５．レビュー
日立ソリューションズのピアレビュー技術教育
目指すのは、チームへのピアレビューの定着
ただ技法を覚えていただくのではなく、
「レビューの本質を理解し、
自らレビューを推進することができる人材の育成」
が本教育の目的です。
日立ソリューションズの教育では・・・

・実体験にもとづく具体的な解説
レビューに対する意識づくりが可能
・ピアレビュープロセスの詳細な解説
最も指摘率の高いインスペクションを紹介
・現場適用時の問題への解決方法を伝授
日立ソリューションズの経験を元に、秘訣を紹介
※定着をご支援するコンサルティングサービスもご提供いたします。
日立ソリューションズピアレビュー技術教育
日立ソリューションズピアレビュー技術教育
http://hitachisoft.jp/products/cmmi/service/PeerReview.html

６．静的検証
セキュリティ脆弱性に起因すると考えられる被害例
時期脆弱性への攻撃による被害
脆弱性への攻撃による被害
への攻撃による被害に
被害に伴う損失
年月
2006年5月情報比較サイトにて不正
情報比較サイトにて不正アクセスによるウェブサ
サイトにて不正アクセスによるウェブサ一部閉鎖に
一部閉鎖に伴い、1億円以上の
億円以上の
億円以上
イトの改ざんが発覚。アクセスしたPCにウィルス
イトの改ざんが発覚。アクセスしたにウィルス
発覚売上高の損失。また完全復旧
売上高の損失。また完全復旧に
完全復旧に
可能性有りサイトを一時閉鎖
一時閉鎖。
を送り込む可能性有り、サイトを一時閉鎖。は1ヶ月以上を要した。
ヶ月以上をした。
年月
2007年7月オンラインショップにてクレジットカード情報を含む
オンラインショップにてクレジットカード情報を
情報オンラインショップは閉鎖。関連
オンラインショップは閉鎖。
閉鎖
個人情報の流出が発覚。年間不正アクセス
年間の
個人情報の流出が発覚。 2年間の不正アクセスのクレジット会社対象のお
会社ものお客様
のクレジット会社も対象のお客様
に気づかず、1万件以上の情報が流出。
づかず、万件以上情報が流出。
万件以上のに個別に対応する状況に。
個別に対応する状況に
する状況
年月
2008年3月楽器通販サイトにてクレジットカード情報を
楽器通販サイトにてクレジットカード情報を含む個
サイトにてクレジットカード情報 10万名以上の該当者に補償とし
万名以上の該当者に補償とし
万名以上
人情報の流出が発覚。
人情報の流出が発覚。円相当の
円相当期限付きクレ
て1000円相当の期限付きクレ
ジットを負担計億円以上
負担。億円以上)
ジットを負担。(計1億円以上
にもシステムの入替
入替え
他にもシステムの入替え、一時
閉鎖。
閉鎖。

・IPAの報告では、ウェブサイトの脆弱性による不正アクセスが生じると、
IPAの報告では、ウェブサイトの脆弱性による不正アクセスが生じると、
復旧・対応コストで5,000万円～1億円以上。
復旧・対応コストで5,000万円～1億円以上。
・業務停止・サイト閉鎖による売上減は数億～数十億円にもなる、とされている。
・業務停止・サイト閉鎖による売上減は数億～数十億円にもなる、とされている。

６．静的検証
セキュリティ脆弱性の60%超
セキュリティ脆弱性の60%超は,静的検証で検出できる

ディレクトリトラバーサル
パス名パラメタの未
パス名パラメタの未チェック
セッション管理の
セッション管理の不備
管理等

：ソースコードで対策可能な脆弱性
ソースコードで対策可能な
対策可能

出典：IPA,
出典：IPA, JPCERT/CC
「ソフトウェア等の脆弱性関連情報に関する届出状況 [2010 年第4 四半期（10 月～12 月）]」
年第4 四半期（10 月～12 月）]

６．静的検証
狙い：
- 弱点把握
- 受入れテスト前の機械的品質検証

ポイント：
- 短期間且つ網羅的な検証
- マネージャ、エンジニアへの適切なフィードバック
■静的検証で検出できるプログラム論理欠陥の例
静的検証で検出できるプログラム論理欠陥の
できるプログラム論理欠陥
▼ 変数初期化もれ（変数への初期値設定もれ）
▼ 領域外参照（確保した配列サイズを超えてアクセス）
▼ リソース解放漏れ（メモリ、ファイル、etc.）
▼ ポインタ操作ミス
▼ セキュリティ脆弱性（クロスサイトスクリプティング、SQLインジェクション）

６．静的検証
選定時のポイント
- ツール利用／サービス利用
・自身の組織で、できない事を他社リソースで補う。
・要員を、どこに（何の作業に）投入するか？
・顧客契約や規格・基準で第三者検証の義務があるか？
- ツール利用時
・使い続けるための仕組み作り
・バージョンアップ、保守費用
- サービス利用時
・今後も繰り返し利用できるか？
・後に何が残るか？


６．静的検証
ソースコード検証サービス InspectPro
- お客様のソースプログラムをお預かりし、日立ソリューションズ
の専任解析チームにて解析し、レポートで報告するサービス
- セキュリティ検証
セキュリティ検証
・バッファオーバーフロー
汚染されたデータ
・汚染されたデータ・クロスサイトスクリプティング
・レースコンディション Java, ・SQLインジェクション
インジェクション
C/C++ 危険なオペレーション
・危険なオペレーション
JSP レスポンス分割
・HTTPレスポンス分割
レスポンス
外部ライブラリのロード
外部ライブラリのロード
安易な一時ファイル
安易な一時ファイル使用
ファイル使用・ディレクトリトラバーサル
稚拙な
稚拙な乱数生成

- 信頼性検証
信頼性検証
ポインタの不正参照
・NULLポインタの不正参照
ポインタのポインタの不正参照
・NULLポインタの不正参照
ポインタの
変数配列外へのアクセス
・変数配列外へのアクセス変数配列外へのアクセス
・変数配列外へのアクセス
・メモリリーク文字列オブジェクト
オブジェクト比較不正
・文字列オブジェクト比較不正
C/C++ ・変数の初期化漏れ
変数の初期化漏れ Java ・リソースリーク
ファイルディスクリプタ
ったメモリ解放
・誤ったメモリ解放
ソケットハンドル
解放済みメモリへのアクセス
・解放済みメモリへのアクセス接続
DB接続

６．静的検証

[一次解析]
一次解析]
パス組合
組合せチェックにより
全パス組合せチェックにより
欠陥の候補を
欠陥の候補を摘出

[二次解析]
二次解析]
専門のアナリストが
のアナリストが、
専門のアナリストが、一次
解析結果の欠陥候補から
解析結果の欠陥候補から
過剰指摘を
過剰指摘を排除

＜お客様評価より＞
客様評価より＞より
過剰指摘の
過剰指摘の割合
・ＩｎｓｐｅｃｔＰｒｏの場合；０％
ＩｎｓｐｅｃｔＰｒｏの
他社の静的解析ツール９９％
ツール；
・他社の静的解析ツール；９９％以上 ① 開発者は指摘の対策要否を検証する必要がない。
開発者は指摘の対策要否を検証する必要がない
する必要がない。
緊急性の
緊急性の高い指摘の割合指摘の
② 指摘項目は迷わず修正できる。
指摘項目はわず修正できる。
修正できる
・ＩｎｓｐｅｃｔＰｒｏの場合；５０％～７５％
ＩｎｓｐｅｃｔＰｒｏの５０％～７５％
％～７５
・他社の静的解析ツール；１％未満
他社の静的解析ツールツール；


６．静的検証
脆弱性検証結果レポート例 (セキュリティ検証サービス Java, JSP)
脆弱性の
脆弱性の種類 SQLインジェクション脆弱性番号 S-060105-0001
場所 /output.java:40 脆弱性の
脆弱性の内容
説明 output.java の 588 行目でメソッド getParameterValues によって取得したリクエストパラメタの値は
output.java の 588 行目で変数 values に代入されます。その後この値は output.java の 40 行目の
メソッド executeQuery でSQL文として実行されます。実行するSQL文に悪意のある内容が含まれて
いる場合、予期せぬ動作を引き起こす可能性があります。
呼出シーケンス
呼出シーケンス
Output.getDataParameter() の 588 行目で外部から取得したデータを変数 values に代入する。脆弱性が
Output.getDataParameter() の 589 行目で変数 values をコール元に返す。
脆弱性が露わに
Output.createContent() の 46 行目で Output. getDataParameter() の戻り値を変数Content に代入する。なるシーケンス
Output.createContent() の 59 行目で使用するデータは危険な内容を含んでいる可能性がある。
________________________________________________________________________________________________________________________________
______________________________
___________________________________________________________________________________________________________________________________________________________
データ取得
データ取得: /output.java:588
取得:
着眼点を
着眼点を強調表示
________________________________________________________________________________________________________________________________
______________________________
___________________________________________________________________________________________________________________________________________________________
ソースコードの抜粋
586 private String getDataParameter(String name)
587 {
588 request.getParameterValues(name);
String[] values = request.getParameterValues(name);
欠陥となるデータを
589 return (values); 取得する
取得する着目箇所する着目箇所
590 }
________________________________________________________________________________________________________________________________
______________________________
___________________________________________________________________________________________________________________________________________________________
データ使用
データ使用: /output.java:40
使用:
________________________________________________________________________________________________________________________________
______________________________
___________________________________________________________________________________________________________________________________________________________
38 public Element createContent( ) 欠陥となるデータを
39 {
40 String SQLString = getRawParameter( SQL, "" );
getRawParameter(
使用する
使用する着目箇所する着目箇所
41 statement.executeQuery(
ResultSet results = statement.executeQuery( SQLString );
42 }


６．静的検証
品質レベルレポート例 (セキュリティ検証サービス Java, JSP)

DataBaseAccess
DataTransfer
FileIO
AccessControl
XSSTransaction
円グラフによる
SessionManagement
脆弱性種別の
脆弱性種別の分布 UserManager
Main
UserAdministration
Utility

クラス別
クラス別の脆弱性密度


６．静的検証
適用事例
・建築構造計算ソフト開発メーカ
・導入前の課題
- 解析対象となる建物の形状や構造種別、使用材料や計算条件などの組み
合わせが天文学的な数字となり、すべてのケースでテストを実施することは
事実上不可能。
・ご利用方法
- ソフトウェアの出荷前の品質をチェックする独立機関「品質検査室」を設置し、
InspectPro を採用。
・お客様ご評価
- 「効果のわりにコストが高いのでは？」という意見も社内にあったが、表面化
する前に障害の可能性を潰すことで、将来的な不具合を減らすことに繋がる。
- レポートの分析結果をもとに、開発者のスキルアップ、管理・工程の見直しを
進めたい。
http://www.hitachi-
http://www.hitachi-system.co.jp/quality/sp/case/

７．オープンソースの適正利用
オープンソースに関するトラブル事例
時期トラブル概要
トラブル概要その後
その後

2008年12月シスコが、2003年に買収した「LINKSYS」の無線 FSFへ多額の寄付
ルータにGPLライセンスのオープンソースソフト混該当ソースを公開
在が発覚。FSF(※1)が訴訟
2009年11月「Windows 7 USB/DVD Download Tool（WUDT）」 WUDTのダウンロード
（Windows 7入りUSBメモリの作成ツール）で、GPL 一時停止
ソースコードの混入が発覚。該当ソースを公開
2009年12月 SFLC(※2)とBusyBoxが、GPLライセンスのユー一部メーカは、寄付に
ティリティツールであるBusyBoxのライセンスに違より和解合意
反したとして、家電メーカ１４社を提訴該当ソースを公開
※1：Free Software Foundation
※2：Software Freedom Law Center


ライセンス違反の事例


狙い：
- ライセンス遵守の確認
- 納品物の妥当性検証
- 成果物と発注額の妥当性確認

ポイント：
- オープンソースソフトウェアの適用可否
- 適用コンポーネントの明示
- エビデンスによる確認、ソースコード検証


OSS利用のメリットとOSSライセンス違反に伴うリスク
OSS利用のメリットとOSSライセンス違反に伴うリスク
OSSを利用するメリット
OSSを利用するメリット
イノベーションと製品機能性
イノベーションと製品機能性の向上
製品機能性の開発コストの抑制
開発コストの抑制
コストの
直ちに利用可能な機能がすでに実現済み
ちに利用可能な機能がすでに実現済み
利用可能がすでに実現済開発とライセンスコストを低減する
開発とライセンスコストを低減する
とライセンスコストを低減
価値ある新機能に社内の開発リソースをための再利用
ための再利用
価値ある新機能に社内の開発リソースを集中
ある新機能リソースを集中
開発グループの生産性を
グループの生産性
開発グループの生産性を向上
OSSライセンス違反伴うリスク
OSSライセンス違反伴うリスク
ライセンス違反伴
ライセンスへの理解不足や安易なOSSコード利用
ライセンスへの理解不足や安易なOSSコード利用
理解不足コード
マルチソース開発によるOSSコード混入検出漏れ
マルチソース開発によるOSSコード混入の検出漏れ
開発によるOSSコード混入の
その結果
結果…
その結果…
裁判での係争に
での係争
• 裁判での係争に伴うコスト
• ソースコード開示による独自技術の公開
ソースコード開示による独自技術の
開示による独自技術
• お客様への告知・お詫び
客様への告知・お
への告知・お詫
• 製品・ソフトウェアの使用停止・回収・再開発
製品・ソフトウェアの使用停止・回収・
・ソフトウェアの使用停止
風評・ブランドイメージダウン
• 風評・ブランドイメージダウン
• 対策を『短期間』で実施しなければならない
対策を短期間』実施しなければならない
OSSコンプライアンスオフィサーの設置、OSS利用ポリシーの設置
OSSコンプライアンスオフィサーの設置、OSS利用ポリシーの設置、等
コンプライアンスオフィサーの設置利用ポリシーの設置、



ライセンスにより、利用、改造、配布の方法が異なる。

類型複製・
複製・再改変可能改変部分の他のコードと組合わせた
改変部分ののコードと組合
組合わせた
頒布可能ソース公開要場合他のコードのソース
ソース公開要場合他のコードのソース
公開要
GPL ○ ○ ○ ○
MPL ○ ○ ○ ×
ライセンス
BSDライセンス ○ ○ × ×
フリーウェア/
フリーウェア ○ × －－
シェアウェア
商用 × × －－
ソフトウェア
出典：日本OSS推進フォーラムビジネス推進WG監修
出典：日本OSS推進フォーラムビジネス推進WG監修
「ビジネスユースにお
「ビジネスユースにおけるオープンソースソフトウェアの法的リスクに関する調査」


・Protex によるコンプライアンス管理

・納品ソースのOSS混入チェックによる、受入（数量）検査と、ライセンス違反排除
・納品ソースのOSS混入チェックによる、受入（数量）検査と、ライセンス違反排除
効果：混入チェックのコスト削減、ライセンス違反のリスク回避による信頼獲得

・Protex のコア技術
オープンソースデータベース膨大なメタデータ
240,000+ OSS プロジェクト名前、記述、バージョン、URL
名前、記述、バージョン、URL
5,000+ サイトから蓄積ライセンス、プログラミング言語,
ライセンス、プログラミング言語, OS
数百億に上るコードライン National Vulnerability Database
1,900+ のユニークライセンス Cryptography（暗号アルゴリズム）
Cryptography（暗号アルゴリズム）
40,000+ セキュリティ脆弱性ソースコード、バイナリーのコードプリント
500+ 暗号アルゴリズムその他

コードマッチング
プログラムコードをデジタル表現として
の「コードプリント」に変換
指紋認証の考え方を応用し、ソース
コードの特徴点によるマッチング


８．まとめ


設計手法プログラミング品質保証活動
の選定言語の設計～
言語の選定設計～実装
・コードチェック納入時の検証
発注時に
発注時に条件提示納入時の納
ツール振り返り
・コーディングルール発・レビュー
品
構成管理・オープンソース
・オープンソース注
メトリクス利用状況
利用可否


要求受入

xxx
xxx
：ソースコード品質の確保へ向けた活動

８．まとめ


コードチェックツールオープンソース
コーディング anyWarp CodeDirector 管理ソリューション
管理ソリューション
納
ガイドライン発
策定サービス
策定サービス品
注ピアレビュー技法
ピアレビュー技法静的ソース検証
静的ソース検証
ソース
教育 InspectPro

要求受入

XXX
：お客様ご利用いただける製品、サービス

８．まとめ
「自分たちの品質は大丈夫」と客観的に言えますか？
定量的に確認を。
品質はコストが掛かるようにみえる。
受入時、納品後のトラブル防止には、ソースコード品質の確保が
有効。
バグを作り込まないのはもちろん、再利用による増殖をさせない。
バグの要因も作りこまない、増殖させない。
次の開発案件をより高価値にするために。
軽微な失敗は重要な技術経験。しかし、重大な失敗は組織の危
機を招く。
今は関係なくとも、いずれ、インターネットに接続することに。
ライセンス遵守は「企業品質」。ライセンス違反は、状況によって
は、欠陥やセキュリティ事故よりもコストがかかる。

コーディングガイドライン策定サービス
http://www.hitachi-
http://www.hitachi-system.co.jp/quality/sp/solution/qualitypro/coding_guideline.html
ピアレビュー教育
http://hitachisoft.jp/products/cmmi/service/PeerReview.html
集中型静的コードチェックツール
http://hitachisoft.jp/products/anywarp/codedirectorforc/
集中型Javaコードインスペクションツール
集中型Javaコードインスペクションツール
anyWarp CodeDirector
http://hitachisoft.jp/products/anywarp/codedirector/
http://www.hitachi-
http://www.hitachi-system.co.jp/inspectpro/
オープンソース管理ソリューション
http://www. (準備中)
準備中)
その他各種ソリューションメニュー
http://www.hitachi-
http://www.hitachi-system.co.jp/quality/sp/solution/qualitypro/

ご清聴ありがとうございました。


【18-B-4】ソースコード品質、大丈夫ですか？　～静的検証のススメ～

【18-B-4】ソースコード品質、大丈夫ですか？　～静的検証のススメ～

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(20)

Similar to 【18-B-4】ソースコード品質、大丈夫ですか？　～静的検証のススメ～

Similar to 【18-B-4】ソースコード品質、大丈夫ですか？　～静的検証のススメ～(20)

More from Developers Summit

More from Developers Summit(20)