JP2021176043A - ソフトウェア検証方法およびソフトウェア開発システム - Google Patents

Abstract

【課題】エッジデバイスなどに好適な、アプリケーションプログラムの安全性を担保できるソフトウェア検証方法およびソフトウェア開発システムを提供する。【解決手段】ソフトウェア開発システムにおけるソフトウェア検証方法であって、ソースコード１０から中間表現２０を生成するステップと、検証サーバ２００により中間表現２０が脆弱性に関する所定の規則あるいは規約を満たしているか否かを検証するステップと、検証するステップにより得られた検証結果４００を、ソースコード１０の作成主体であるユーザにフィードバックするステップと、を含む。【選択図】図１

Description

本開示は、ソフトウェア検証方法およびソフトウェア開発システムに関する。

近年の情報通信技術（Information and Communication Technology：ＩＣＴ）の進歩は目覚ましく、インターネットなどのネットワークに接続されるデバイスは、従来のパーソナルコンピュータやスマートフォンといった情報処理装置に限らず、様々なモノ（things）に広がっている。このような技術トレンドは、「ＩｏＴ（Internet of Things；モノのインターネット）」と称され、様々な技術およびサービスが提案および実用化されつつある。将来的には、地球上の数十億人と数百億または数兆のデバイスとが同時につながる世界が想定されている。このようなネットワーク化された世界を実現するためには、よりシンプル、より安全、より自由につながることができるソリューションを提供する必要がある。

ＩｏＴで利用されるデバイス（「エッジデバイス」とも称される。）のインテリジェント化に伴って、エッジデバイスでは様々な種類のアプリケーションプログラムが実行可能になる。一方で、エッジデバイスに対する安全性は、リソース制約などによって、サーバやパーソナルコンピュータなどに対する安全性と同程度まで高めることは容易ではない。そのため、エッジデバイスに組み入れられるアプリケーションプログラムに対する検証などが重要になってくる。

例えば、特開２０１４−１７４５７７号公報（特許文献１）は、Ｗｅｂアプリケーションの脆弱性をソースコードレベルで検証する静的解析ツールの改良を開示する。

特開２０１４−１７４５７７号公報

エッジデバイスなどで利用されるアプリケーションプログラムは、ソースコードの形態ではなく、中間表現（intermediate representation）として流通することも多い。このような中間表現を採用することで、ソースコードに含まれるノウハウなどを秘匿化するとともに、データ量を低減できるという利点がある。

上述の特許文献１に開示されるように、ソースコードを解析して脆弱性などを評価することは一般的であるが、ソースコード以外の形式で脆弱性などを評価することは容易ではない。

本開示の典型的な目的は、エッジデバイスなどに好適な、アプリケーションプログラムの安全性を担保できるソリューションを提供することである。

本開示のある形態に従うソフトウェア検証方法は、ソースコードから中間表現を生成するステップと、中間表現が脆弱性に関する所定の規則あるいは規約を満たしているか否かを検証するステップと、検証するステップにより得られた検証結果を出力するステップとを含む。

検証結果は、検出された脆弱性の種類を示す情報を含んでいてもよい。
検証結果は、検出された脆弱性が存在する中間表現の位置を示す情報を含んでいてもよい。

ソフトウェア検証方法は、ソースコードから中間表現の生成時に、デバッグ情報を生成するステップをさらに含んでいてもよい。検証結果は、検出された脆弱性が存在するソースコードの位置を示す情報を含んでいてもよい。

ソフトウェア検証方法は、中間表現が所定の規則あるいは規約を満たしていることを条件として、中間表現から生成された実行コードの実行を許可するステップをさらに含んでいてもよい。

本開示の別の形態に従うソフトウェア開発システムは、ソースコードの作成を支援するソフトウェア開発装置と、ソフトウェア開発装置からアクセス可能な検証サーバとを含む。ソフトウェア開発装置は、ソースコードから中間表現を生成する手段を含む。検証サーバは、中間表現が脆弱性に関する所定の規則あるいは規約を満たしているか否かを検証する手段と、検証する手段により得られた検証結果を出力する手段とを含む。

本開示によれば、アプリケーションプログラムの安全性を担保できるソリューションを提供できる。

本実施の形態に従うソフトウェア開発システムにおけるソフトウェア検証方法の一例を説明するための図である。 本実施の形態に従うソフトウェア開発システムにおけるソースコードから実行コードを生成する手順の概要を示す図である。 本実施の形態に従うソフトウェア開発システムにおけるソースコードから実行コードを生成する手順の概要を示す図である。 本実施の形態に従うソフトウェア開発装置のハードウェア構成例を示す模式図である。 本実施の形態に従う検証サーバのハードウェア構成例を示す模式図である。 本実施の形態に従うソフトウェア開発システム１におけるソフトウェア検証方法の手順例を示すシーケンスチャートである。 静的バッファオーバーフローの検証処理を説明するためのコード例を示す図である。 実行時バッファオーバーフローの検証処理を説明するためのコード例を示す図である。 図８に示されるコードを本実施の形態に従うソフトウェア開発システムにおける脆弱性に関する規則あるいは規約に適合させた場合のコードの一例を示す図である。 フォーマット文字列バグの検証処理を説明するためのコード例を示す図である。 未使用関数の抽出する処理を説明するための中間表現のコード例を示す図である。 本実施の形態に従うソフトウェア開発システム１が提供する検証結果の一例を示す図である。

本開示に係る実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰り返さない。

＜Ａ．概要＞
まず、本実施の形態に従うソフトウェア開発システム１におけるソフトウェア検証方法の一例を説明する。本実施の形態においては、ソースコード１０から生成される中間表現２０自体を検証する。このように、中間表現２０を検証することで、ソースコード１０の言語およびターゲットアーキテクチャなどに依存することなく、汎用的な検証が可能となる。また、ソースコード１０をコンパイルして生成される中間表現２０を検証するので、ソースコード１０に含まれるノウハウなどを秘匿化できる。

中間表現２０の検証は、アプリケーションプログラムに含まれる脆弱性の有無を検証することに加えて、存在する脆弱性の種類およびソースコード１０の位置を特定する処理を含む。

さらに、中間表現２０に脆弱性が存在しない（すなわち、検証結果に問題が無い）ことを条件に、対応する実行コード３０の生成、あるいは、生成された実行コード３０の実行を許容するようにしてもよい。

本明細書において、「中間表現」は、任意のプログラミング言語（通常は、高級言語）で記載されたソースコードを、任意のアーキテクチャをターゲットとしてコンパイルすることで生成されるコードを意味する。中間表現２０は、任意の仮想マシンのマシン語を包含し得る。なお、中間表現２０は、必ずしもバイナリ形式である必要はなく、アセンブラ言語のような自然言語に類似した形式で表現されてもよい。

中間表現２０のコード形式としては、ＬＬＶＭ ＩＲ形式やＬＬＶＭ ＢＣ形式などが挙げられる。

通常、中間表現２０は、実行コード３０が実行されるプラットフォームおよびアーキテクチャとは独立して生成される。ソースコード１０から中間表現２０の生成には、静的コンパイラが用いられてもよい。中間表現２０は、特定のプラットフォームおよびアーキテクチャに向けられた実行コード３０としてコンパイルされてもよい。中間表現２０は、元になったソースコードに比較してデータ量が削減されるとともに、記述される処理自体も効率化できる。

図１は、本実施の形態に従うソフトウェア開発システム１におけるソフトウェア検証方法の一例を説明するための図である。図１（Ａ）および（Ｂ）に示すように、ソフトウェア開発システム１においては、ソースコード１０から生成された中間表現２０が任意の主体により検証される。図１（Ａ）および（Ｂ）に示す例では、検証サーバ２００が中間表現２０を検証する例を示すが、これに限られず、任意の主体によって検証されてもよい。

典型的には、検証結果４００は、ソースコード１０の作成主体であるユーザにフィードバックされ、必要に応じて、ソースコード１０に対する修正が行われる。後述するように、検証結果４００は、検出された脆弱性の種類を示す情報およびソースコード１０の位置を特定する情報を含むので、ユーザは、ソースコード１０を適切に修正できる。

なお、検証結果４００に問題が無いことを条件として、実行コード３０の生成、あるいは、実行コード３０の実行を許可するようにしてもよい。

例えば、図１（Ａ）には、検証結果４００に問題が無いことを、実行コード３０の生成条件とする例を示す。この例において、検証結果４００に問題が無い場合には、検証サーバ２００は、中間表現２０に対して認証を与える。中間表現２０に対する認証を生成条件として、中間表現２０から実行コード３０が生成される。このような生成条件を採用することで、生成される実行コード３０についての安全性を高めることができる。

また、図１（Ｂ）には、検証結果４００に問題が無いことを、中間表現２０から生成された実行コード３０の実行条件とする例を示す。この例において、検証結果４００に問題が無い場合には、検証サーバ２００は、中間表現２０に対する認証を含む証明書４０を発行する。並行して、中間表現２０から実行コード３０が生成される。生成された実行コード３０の実行には、対応する証明書４０の存在を条件としてもよい。このように、中間表現２０に対する証明書４０の存在を実行コード３０の実行条件に含めるようにしてもよい。このような実行条件を採用することで、安全性が損なわれた状態で実行コード３０が実行される可能性を低減できる。

このように、ソースコード１０ではなく中間表現２０を検証することで、ソースコード１０に含まれるノウハウなどを秘匿化した状態で、アプリケーションプログラムに含まれる脆弱性をより効率的に発見できる。また、中間表現２０を検証することで、ソースコード１０の言語およびターゲットアーキテクチャなどに応じた複数の検証ロジックを用意する必要がなく、効率的な検証を実現できる。

なお、中間表現２０を生成する際に、ソースコード１０をコンパイルすることで生成されるデバッグ情報５０を中間表現２０と合わせて検証サーバ２００へ送信するようにしてもよい。中間表現２０を参照することで、検出された脆弱性に対応するソースコード１０の位置をより詳細に特定できる。デバッグ情報５０を利用する検証結果４００の生成処理については、後述する。

次に、本実施の形態に従うソフトウェア開発システム１を用いた実行コード３０の生成手順の一例について説明する。

図２および図３は、本実施の形態に従うソフトウェア開発システム１におけるソースコード１０から実行コード３０を生成する手順の概要を示す図である。

図２を参照して、ソフトウェア開発システム１は、１または複数のソフトウェア開発装置１００と、ソフトウェア開発装置１００からインターネット２などを介してアクセス可能な検証サーバ２００とを含む。

ソフトウェア開発装置１００は、エッジデバイス４に含まれるコントローラ３００で実行されるアプリケーションプログラムの作成を支援する。但し、本発明の技術的範囲は、エッジデバイス４で実行されるアプリケーションプログラムの作成に限定されるものではなく、任意のコンピューティングデバイスで実行されるアプリケーションプログラムの作成に適用可能である。

ソフトウェア開発装置１００には、統合開発環境（ＩＤＥ：Integrated Development Environment）が提供されており、ユーザは統合開発環境上で任意のアプリケーションプログラムを作成できる。

エッジデバイス４に含まれるコントローラ３００は、コンピューティングデバイスの一例であり、プロセッサを含む。エッジデバイス４としては、どのようなデバイスであってもよいが、典型的には、工場設備、家庭内の各種装置、社会インフラ設備、車両などの移動体、任意の携帯デバイスなどが想定される。後述するように、コントローラ３００は、プロセッサを有しており、ソフトウェア開発装置１００からのアプリケーションプログラムを実行可能になっている。

まず、作成主体であるユーザは、ソフトウェア開発装置１００を用いてソースコードを作成する（（１）ソースコード作成）。そして、作成されたソースコードは、ソフトウェア開発装置１００においてコンパイルされて中間表現２０が生成される（（２）中間表現生成）。

中間表現２０から実行コード３０が生成される前に中間表現２０が検証される。図２に示す例においては、生成された中間表現２０が検証サーバ２００へ送信される（（３）中間表現検証依頼）。

検証サーバ２００は、ソフトウェア開発装置１００からの中間表現２０を検証する（（４）中間表現の検証）。そして、検証サーバ２００は、中間表現２０の検証によって得られた検証結果４００をソフトウェア開発装置１００へ送信する。ソフトウェア開発装置１００は、検証サーバ２００から検証結果４００を受信する（（５）検証結果受信）。

検証サーバ２００からの検証結果４００に問題があれば、ユーザは、検証結果４００を参照して、ソースコード１０を修正する（（６）ソースコード修正）。そして、（２）から（５）の処理が繰り返される。

一方、検証サーバ２００からの検証結果４００に問題が無ければ、ユーザは、ソフトウェア開発装置１００を用いて、中間表現２０から実行コード３０を生成する（（７）実行コード生成）。生成された実行コード３０は、ソフトウェア開発装置１００からエッジデバイス４のコントローラ３００へ転送される（（８）実行コード転送）。そして、エッジデバイス４のコントローラ３００は、必要に応じて、転送された実行コード３０を実行する（（９）実行コードの実行）。

図２および図３に示すような一連の処理によって、エッジデバイス４のコントローラ３００において、安全性の高いアプリケーションプログラムの実行を保証できる。

＜Ｂ．ハードウェア構成例＞
次に、本実施の形態に従うソフトウェア開発システム１を構成する主要装置のハードウェア構成例について説明する。

（ｂ１：ソフトウェア開発装置１００）
ソフトウェア開発装置１００は、典型的には汎用コンピュータで実現される。

図４は、本実施の形態に従うソフトウェア開発装置１００のハードウェア構成例を示す模式図である。図４を参照して、ソフトウェア開発装置１００は、主たるコンポーネントとして、プロセッサ１０２と、メインメモリ１０４と、入力部１０６と、ディスプレイ１０８と、ハードディスク１１０と、通信インターフェイス１２２とを含む。これらのコンポーネントは、内部バス１２０を介して接続されている。

プロセッサ１０２は、例えば、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）などで構成される。複数のプロセッサ１０２が配置されてもよいし、複数のコアを有するプロセッサ１０２を採用してもよい。

メインメモリ１０４は、ＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）などの揮発性記憶装置で構成される。ハードディスク１１０は、プロセッサ１０２で実行される各種プログラムや各種データを保持する不揮発性記憶装置である。ハードディスク１１０に代えて、ＳＳＤ（Solid State Drive）やフラッシュメモリなどを採用してもよい。ハードディスク１１０に格納されたプログラムのうち、指定されたプログラムコードがメインメモリ１０４上に展開され、プロセッサ１０２は、メインメモリ１０４上に展開されたプログラムコードに含まれるコンピュータ可読命令（computer-readable instructions）を順次実行することで、後述するような各種機能を実現する。

典型的には、ハードディスク１１０には、ユーザが任意に作成するソースコード１０と、統合開発環境を実現するためのソフトウェア開発プログラム１１４と、ソースコード１０から生成される実行コード３０とが格納される。ソフトウェア開発プログラム１１４は、ユーザが任意に作成するソースコード１０から中間表現２０を介して実行コード３０を生成するものであり、アプリケーションプログラムの開発環境を提供するモジュールを含む。

入力部１０６は、ソフトウェア開発装置１００を操作するユーザの入力操作を受け付ける。入力部１０６は、例えば、キーボード、マウス、表示デバイス上に配置されたタッチパネル、ソフトウェア開発装置１００の筐体に配置された操作ボタンなどであってもよい。

ディスプレイ１０８は、プロセッサ１０２での処理結果などを表示する。ディスプレイ１０８は、例えば、ＬＣＤ（Liquid Crystal Display）や有機ＥＬ（Electro-Luminescence)ディスプレイなどであってもよい。

通信インターフェイス１２２は、検証サーバ２００とのデータ交換を担当する。通信インターフェイス１２２は、例えば、インターネットを介した通信ができるように、イーサネット（登録商標）ポートを含んでいてもよい。

なお、ソフトウェア開発装置１００の全部または一部は、コンピュータ可読命令に相当する回路が組み込まれたＡＳＩＣ（Application Specific Integrated Circuit）などのハードワイヤード回路を用いて実現してもよい。さらにあるいは、ＦＰＧＡ（field-programmable gate array）上にコンピュータ可読命令に相当する回路を用いて実現してもよい。また、プロセッサ１０２およびメインメモリ、ＡＳＩＣ、ＦＰＧＡなどを適宜組み合わせて実現してもよい。

ソフトウェア開発装置１００は、コンピュータ可読命令を含むソフトウェア開発プログラム１１４を格納する非一過性（non-transitory）のメディアから、当該格納しているプログラムなどを読み出すためのコンポーネントをさらに有していてもよい。メディアは、例えば、ＤＶＤ（Digital Versatile Disc）などの光学メディア、ＵＳＢメモリなどの半導体メディアなどであってもよい。

なお、ソフトウェア開発プログラム１１４は、メディアを介してソフトウェア開発装置１００にインストールされるだけではなく、ネットワーク上の配信サーバから提供されるようにしてもよい。

（ｂ２：検証サーバ２００）
検証サーバ２００についても、典型的には汎用コンピュータで実現される。

図５は、本実施の形態に従う検証サーバ２００のハードウェア構成例を示す模式図である。図５を参照して、検証サーバ２００は、主たるコンポーネントとして、１または複数のプロセッサ２０２と、メインメモリ２０４と、入力部２０６と、ディスプレイ２０８と、ハードディスク２１０と、通信インターフェイス２２２とを含む。これらのコンポーネントは、内部バス２２０を介して接続されている。

プロセッサ２０２は、例えば、ＣＰＵやＧＰＵなどで構成される。複数のプロセッサ２０２が配置されてもよいし、複数のコアを有するプロセッサ２０２を採用してもよい。

メインメモリ２０４は、ＤＲＡＭやＳＲＡＭなどの揮発性記憶装置で構成される。ハードディスク２１０は、プロセッサ２０２で実行される各種プログラムや各種データを保持する不揮発性記憶装置である。ハードディスク２１０に代えて、ＳＳＤやフラッシュメモリなどを採用してもよい。ハードディスク２１０に格納されたプログラムのうち、指定されたプログラムコードがメインメモリ２０４上に展開され、プロセッサ２０２は、メインメモリ２０４上に展開されたプログラムコードに含まれるコンピュータ可読命令を順次実行することで、後述するような各種機能を実現する。

典型的には、ハードディスク２１０には、外部からの依頼を受けて中間表現２０の検証処理を実行する検証エンジン２１２が格納される。検証エンジン２１２は、中間表現２０に含まれる脆弱性の有無を検証する処理、および、存在する脆弱性の種類を示す情報およびソースコード１０の位置を特定する処理などを実行する。

ハードディスク２１０には、検証エンジン２１２による検証結果４００の内容に応じて証明書を発行するための証明書発行エンジン２１４をさらに格納するようにしてもよい。証明書発行エンジン２１４は、検証結果４００に問題が無い場合に、中間表現２０に関連付けられる証明書４０を発行する。

入力部２０６は、検証サーバ２００を操作するユーザの入力操作を受け付ける。ディスプレイ２０８は、プロセッサ２０２での処理結果などを表示する。

通信インターフェイス２２２は、ソフトウェア開発装置１００とのデータ交換を担当する。通信インターフェイス２２２は、例えば、インターネットを介した通信ができるように、イーサネット（登録商標）ポートを含んでいてもよい。

なお、検証サーバ２００の全部または一部は、コンピュータ可読命令に相当する回路が組み込まれたＡＳＩＣなどのハードワイヤード回路を用いて実現してもよい。さらにあるいは、ＦＰＧＡ上にコンピュータ可読命令に相当する回路を用いて実現してもよい。また、プロセッサ２０２およびメインメモリ、ＡＳＩＣ、ＦＰＧＡなどを適宜組み合わせて実現してもよい。

なお、実行に必要なプログラムは、メディアを介して検証サーバ２００にインストールされるだけではなく、ネットワーク上の配信サーバから提供されるようにしてもよい。

＜Ｃ．手順例＞
次に、本実施の形態に従うソフトウェア開発システム１におけるソフトウェア検証方法の具体的な手順例について説明する。

図６は、本実施の形態に従うソフトウェア開発システム１におけるソフトウェア検証方法の手順例を示すシーケンスチャートである。図６に示すソフトウェア開発装置１００が実行する処理については、典型的には、ソフトウェア開発装置１００のプロセッサ１０２がソフトウェア開発プログラム１１４を実行することで実現されてもよい。同様に、検証サーバ２００が実行する処理については、典型的には、検証サーバ２００のプロセッサ２０２が必要なプログラムを実行することで実現されてもよい。

図６を参照して、ユーザは、ソフトウェア開発装置１００を操作して、ソースコード１０を作成する（ステップＳ１００）。ソースコード１０の作成後、ユーザは、ソフトウェア開発装置１００を操作して、ソースコード１０をコンパイルして、ソースコード１０から中間表現２０を生成する（ステップＳ１０２）。

さらに、ユーザは、ソフトウェア開発装置１００を操作して、生成した中間表現２０に対する検証を検証サーバ２００へ依頼し（ステップＳ１０４）、検証サーバ２００からの応答を待つ（ステップＳ１０６）。なお、中間表現２０に加えて、デバッグ情報５０が検証サーバ２００へ送信されてもよい。

検証サーバ２００は、ソフトウェア開発装置１００からの検証依頼に応答して、依頼された中間表現２０を検証する（ステップＳ２００）。検証サーバ２００は、検証により生成された検証結果４００をソフトウェア開発装置１００へ送信する（ステップＳ２０２）。すなわち、検証サーバ２００は、検証により得られた検証結果４００を出力する。

検証結果４００に問題があれば（ステップＳ１０８においてＮＯ）、ユーザは、ソフトウェア開発装置１００を操作して、ソースコード１０を修正する（ステップＳ１００）。ソースコード１０の修正後、ステップＳ１０２以下の処理が再度実行される。

これに対して、検証結果４００に問題が無ければ（ステップＳ１０８においてＹＥＳ）、ユーザは、ソフトウェア開発装置１００を操作して、対象の中間表現２０から実行コード３０を生成する（ステップＳ１１０）。最終的に、ユーザは、ソフトウェア開発装置１００を操作して、生成した実行コード３０をターゲットのコントローラ３００へ転送する（ステップＳ１１２）。そして、処理は終了する。

＜Ｄ．検証処理の詳細＞
次に、本実施の形態に従うソフトウェア開発システム１における検証処理の詳細について説明する。

本実施の形態における中間表現２０に対する検証は、中間表現２０が脆弱性に関する所定の規則あるいは規約を満たすか否かを判断する処理を含んでいてもよい。脆弱性に関する所定の規則あるいは規約としては、アプリケーションプログラム（中間表現２０および対応する実行コード３０）が安全であるための条件を含む。このような安全であるための条件としては、典型的には、以下のようなものが挙げられる。

（１）安全性が確認できないメモリ操作（あるいは、危険なメモリ操作）が含まれていないこと（あるいは、そのようなメモリ操作がコンパイル可能ではないこと）
（２）コード中に未定義動作が存在しないこと
（３）エラー処理構文が欠如していないこと（エラー処理構文が適切に含まれていること）
（４）無秩序なエラー処理が含まれていないこと
上記（１）の安全性が確認できないメモリ操作（あるいは、危険なメモリ操作）は、システム領域やセキュア領域に対するメモリアクセスや、メモリ領域に対するブロック消去やブロック書き込みなどのメモリ操作を含む。

上記（２）の未定義動作は、コード中に処理が定義されていないプロシージャやファンクションを含む。

上記（３）のエラー処理構文は、例外が発生した場合の処理を規則する記述を含む。
上記（４）の無秩序なエラー処理は、例外が発生した場合の過度なエラー処理などを含む。

さらに、脆弱性に関する所定の規則あるいは規約としては、アプリケーションプログラム（中間表現２０および対応する実行コード３０）に、いわゆるバックドアが存在しないことを含んでよい。バックドアとは、アプリケーションプログラムの利用者が認識しない方法で、（通常は、悪意のある）第三者がアプリケーションプログラムにアクセスするための機能や接続口などを意味する。中間表現２０に対する検証においては、外部からのアクセス経路が中間表現２０に含まれるか否かが判断されてもよい。

上述したような検証は、脆弱性に関する所定の規則あるいは規約を定義するルールを参照することで実現するようにしてもよいし、いわゆるＡＩ（Artificial Intelligence）などの機械学習を用いて、検証を実現するための検証モデルを逐次更新するようにしてもよい。

上述したような検証内容をより具体化した検証処理としては、以下のようなものが挙げられる。

（ａ）静的バッファオーバーフロー
（ｂ）実行時バッファオーバーフロー
（ｃ）整数オーバーフロー
（ｄ）フォーマット文字列バグ
（ｅ）制御文の不備
（ｆ）未初期化データへのアクセス
（ｇ）未使用関数の抽出
（ｈ）未初期化データへのアクセス
（ｉ）ヌルポインタへの書き込み
（ｊ）ヌルポインタの読み取り
（ｋ）リソースの二重解放
（ｌ）ＯＳコマンドインジェクション
なお、上述した検証処理に限定されるものではなく、任意の検証処理を実装すればよい。また、上述した検証処理のすべてではなく一部のみを実装するようにしてもよい。

次に、いくつかの典型的な検証処理の詳細について説明する。
（ｄ１：静的バッファオーバーフロー）
静的バッファオーバーフローを検証する処理について説明する。

図７は、静的バッファオーバーフローの検証処理を説明するためのコード例を示す図である。図７（Ａ）には、静的バッファオーバーフローを発生させるＣ言語により記述されたソースコードの例を示す。

図７（Ａ）のソースコードにおいて、配列ａ［］のうち１０番目の要素までは定義されているものの、それ以降の要素については未定義である。そのため、実行するたびに異なる結果が出力されることになる。なお、図７（Ａ）のソースコードには、説明の便宜上、「＾＾＾バッファオーバーフローが発生します」とのコメントが付されている。

例えば、コンパイラの一例であるｇｃｃ（9.2.0-Wall-Wextraオプション）を用いて、図７（Ａ）のソースコードをコンパイルした場合には、警告などは出力されずに、コンパイルが完了する。

図７（Ｂ）には、図７（Ａ）のソースコードをコンパイルして生成される中間表現の例（一例として、ＬＬＶＭ ＩＲ形式）を示す。なお、図７（Ｂ）に示す中間表現において、「中略」と記載されている部分のコードの表示は省略されている。

本実施の形態に従う検証エンジン２１２は、（１）固定長配列にインデックスでアクセスするコードを検索、および、（２）配列の要素数を超える定数でアクセスするコードを脆弱性として検出、の２つの処理により、静的バッファオーバーフローを検出する。

図７（Ｂ）に示す中間表現において、４行目の％３から始まる命令の組には、getelementptr命令が規定されている。getelementptr命令は、配列要素のポインタを取得するための命令である。inbounds命令に続く[10 x i64]は、対象の配列が符号付き６４ビット整数を１０個含むものであることを意味する。最後にある「100」は、対象の配列の１００番目の要素にアクセスすることを示す。

このような中間表現を解析することで、１０個の要素しか含まない配列に対して、１００番目の要素にアクセスしようとしていることが分かる。このような解析によって、検証エンジン２１２は、脆弱性として、静的バッファオーバーフローを検出する。

（ｄ２：実行時バッファオーバーフロー）
実行時バッファオーバーフローを検証する処理について説明する。

図８は、実行時バッファオーバーフローの検証処理を説明するためのコード例を示す図である。

一般的に、配列へのアクセスにおいて指定されるインデックスはコンパイル時には確定できない。例えば、図８（Ａ）に示すＣ言語により記述されたソースコードでは、実行時のインデックスの値（変数indexの値）次第でバッファオーバーフローが発生し得る。なお、図８（Ａ）のソースコードには、説明の便宜上、「＾＾＾indexの値次第でバッファオーバーフローが発生します」とのコメントが付されている。

本実施の形態に従うソフトウェア開発システム１における脆弱性に関する規則あるいは規約としては、インデックスの値を事前にチェックすることを要求するようにしてもよい。すなわち、配列へのアクセスに用いるインデックスの値を事前にチャックする処理を含まないソースコードあるいは中間表現は、脆弱性が存在すると評価してもよい。

本実施の形態に従う検証エンジン２１２は、配列へのアクセスに用いるインデックスの値を事前にチェックする処理が存在するか否かを検証する。

より具体的には、本実施の形態に従う検証エンジン２１２は、（１）バッファにインデックスでアクセスするコードを検索、および、（２）検索されたコードのうちインデックスの値を事前にチェックしていないコードを脆弱性として検出、の２つの処理により、実行時バッファオーバーフローを検出する。

図８（Ｂ）には、図８（Ａ）のソースコードをコンパイルして生成される中間表現の例（一例として、ＬＬＶＭ ＩＲ形式）を示す。なお、図８（Ｂ）に示す中間表現において、「中略」と記載されている部分のコードの表示は省略されている。

図８（Ｂ）に示す中間表現において、６行目の％６から始まる命令の組には、getelementptr命令が規定されている。当該行の最後にある「i64 %5」から、具体的な数値ではなく、変数（ソースコード中の変数index）を用いたインデックスでのアクセスが存在していることを見つけることができる。

ここで、ソースコード中の変数indexに対応する「%5」をチェックせずに、バッファにアクセスするためのインデックスとして用いていることが、実行時バッファオーバーフローが発生する要因である。

図９は、図８に示されるコードを本実施の形態に従うソフトウェア開発システム１における脆弱性に関する規則あるいは規約に適合させた場合のコードの一例を示す図である。

図９（Ａ）に示すＣ言語により記述されたソースコードでは、変数indexの値をif式でチェックすることでエラーハンドリングを行っている（３〜６行目参照）。このようなエラーハンドリングの処理を含むソースコードを、ソフトウェア開発システム１における脆弱性に関する規則あるいは規約に適合するコードとみなしてもよい。

図９（Ｂ）には、図９（Ａ）のソースコードをコンパイルして生成される中間表現の例（一例として、ＬＬＶＭ ＩＲ形式）を示す。なお、図９（Ｂ）に示す中間表現において、「中略」と記載されている部分のコードの表示は省略されている。

図９（Ｂ）に示す中間表現において、「%5」の値をチェックして、そのチェック結果が問題無い場合のみ、「BoundsCheckOK」で配列にアクセスするように規定されている（６〜１０行目）。

本実施の形態に従う検証エンジン２１２は、バッファにインデックスでアクセスするコードが存在する場合、そのアクセスに用いるインデックスの値を事前にチェックする処理が存在する場合に限って、脆弱性に関する規則あるいは規約に適合しており、脆弱性が存在しないと評価する。これに対して、バッファへのアクセスに用いるインデックスの値を事前にチェックする処理が存在しなければ、検証エンジン２１２は、脆弱性として、実行時バッファオーバーフローを検出する。

このような中間表現を解析することで、検証エンジン２１２は、脆弱性として、実行時バッファオーバーフローを検出する。

（ｄ３：フォーマット文字列バグ）
フォーマット文字列バグを検証する処理について説明する。

図１０は、フォーマット文字列バグの検証処理を説明するためのコード例を示す図である。

図１０（Ａ）に示すＣ言語により記述されたソースコードでは、printf関数のフォーマット文字列を悪用する攻撃を受けて、任意コードを実行される可能性がある。これは、printf関数などのフォーマット文字列の引数に、外部からの入力文字列をフォーマットのチェックを行わずに渡していることが要因である。

本実施の形態に従うソフトウェア開発システム１における脆弱性に関する規則あるいは規約として、フォーマット文字列を引数とするライブラリ関数に、文字列リテラル以外が入力されている場合には、脆弱性が存在すると評価してもよい。

より具体的には、本実施の形態に従う検証エンジン２１２は、（１）printf関数などのフォーマット文字列を引数に指定するコードを検索、（２）検索されたコードのうち固定長の文字列リテラルを引数が指定されていないコードを脆弱性として検出の２つの処理により、フォーマット文字列バグを検出する。

図１０（Ｂ）には、図１０（Ａ）のソースコードをコンパイルして生成される中間表現の例（一例として、ＬＬＶＭ ＩＲ形式）を示す。なお、図１０（Ｂ）に示す中間表現において、７行目で呼ばれるprintf関数の引数に%7が使用されている。本実施の形態に従う検証エンジン２１２は、引数で使用される%7にどのような値が格納されるかを解析して、固定長の文字列リテラルでなければ、脆弱性として、フォーマット文字列バグを検出する。

このような中間表現を解析することで、検証エンジン２１２は、脆弱性として、フォーマット文字列バグを検出する。

（ｄ４：未使用関数の抽出）
未使用関数を抽出する処理について説明する。

一般的に、未使用関数は、プログラムのアタックサーフェスを増加させる。また、未使用関数は、バックドアの疑いもある。そこで、本実施の形態に従う検証エンジン２１２は、中間表現の静的コールグラフ解析を行うことで、未使用関数を抽出する。

図１１は、未使用関数の抽出する処理を説明するための中間表現のコード例を示す図である。図１１に示すように、関数呼び出しは、ＬＬＶＭ ＩＲ形式の中間表現においてはcall命令が使用される。検証エンジン２１２は、call命令の関係を解析することで、未使用の関数を抽出する。そして、検証エンジン２１２は、抽出した未使用の関数を脆弱性として検出する。

（ｄ５：検証結果４００の一例）
次に、本実施の形態に従うソフトウェア開発装置１００が提供する検証結果４００の一例について説明する。

検証結果４００は、検証サーバ２００の検証エンジン２１２が中間表現２０を解析することで生成可能ではある。但し、より詳細な検証結果４００を生成するためには、ソースコード１０をコンパイルして中間表現２０を生成する際に併せて生成されたデバッグ情報５０も利用することになる。

デバッグ情報５０は、中間表現２０を生成したソースコード１０の属性情報や、中間表現２０に含まれるコードとソースコード１０とを対応付けるための情報を含む。例えば、コンパイラの一例であるｇｃｃでは、「−ｇ」オプションを付与してコンパイルすることで、中間表現２０およびデバッグ情報５０を生成できる。このように、ソースコード１０から中間表現２０の生成時に、デバッグ情報５０を生成する処理が実行されてもよい。

図１２は、本実施の形態に従うソフトウェア開発システム１が提供する検証結果４００の一例を示す図である。図１２には、検証結果４００がレポートの形で提供される例を示すが、どのような形式で提供されてもよい。

また、検証結果４００は、Ｗｅｂを通じて（すなわち、ＨＴＴＰ形式で）提供されてもよいし、テキスト形式あるいはＰＤＦ形式などでメールなどにより提供されてもよい。以下の説明においては、典型的に、Ｗｅｂを通じて検証結果４００が提供される場合を想定する。

図１２を参照して、検証結果４００は、管理部４１０と、検証対象情報部４２０と、解析内容部４３０と、サマリー部４４０とを含む。

管理部４１０には、検証結果４００に再度アクセスするためのパスワード４１２と、検証結果４００を特定するための識別情報４１４とが表示される。例えば、検証サーバ２００は、対応する識別情報４１４に関連付けて検証結果４００を保持しており、保持されている検証結果４００に再度アクセスするためには、識別情報４１４により対象の検証結果４００を特定した上で、パスワード４１２の入力を必要としてもよい。

対象の検証結果４００にアクセスするために、対応する識別情報４１４を含むＵＲＬを用いてもよい。例えば、図１２に示す例では、識別情報４１４として、「F-ELc_cx」が付与されている。この識別情報４１４を含む「https://server.or.jp/F-ELc_cx」のようなＵＲＬを指定することでアクセスできるようにしてもよい。

検証対象情報部４２０には、検証の対象となった中間表現２０に関する情報が表示される。具体的には、検証対象情報部４２０には、ソースファイル名４２２と、メモリレイアウト情報４２４と、コンパイル環境情報４２６とが表示される。

ソースファイル名４２２は、検証対象の中間表現２０の生成元であるソースコード１０のファイル名を示す。ソースファイル名４２２は、デバッグ情報５０が参照できる場合に表示される。メモリレイアウト情報４２４は、アラインメントやエンディアンなどのメモリ上のレイアウトに関する情報を示す。コンパイル環境情報４２６は、ソースコード１０から中間表現２０の生成に用いられたコンパイル環境の情報を示す。

解析内容部４３０は、検出された脆弱性についての解析内容を含む。より具体的には、解析内容部４３０は、脆弱性情報４３２と、ソースコード情報４３４と、中間表現情報４３５と、詳細メッセージ４３６と、結果情報４３８とを含む。

脆弱性情報４３２は、検出された脆弱性の種類を示す情報である。図１２に示す例では、脆弱性情報４３２として、「FormatStringBug」と表示されており、フォーマット文字列バグが脆弱性として検出されたことが分かる。

ソースコード情報４３４および中間表現情報４３５は、検出された脆弱性の種類および位置を特定するための情報を示す。

ソースコード情報４３４は、検出された脆弱性が存在するソースコードの位置を示す情報である。図１２に示す例では、ソースコード情報４３４として、「main() in sample.c at line: 3」と表示されており、ソースコード１０を含むソースファイル「sample.c」中の関数main()の３行目のコードが検知された場所であることを示す。なお、ソースコード１０の行数（位置）を表示するためには、デバッグ情報５０が必要になる。

中間表現情報４３５は、検出された脆弱性が存在する中間表現の位置を示す情報である。図１２に示す例では、中間表現情報４３５には、中間表現のコードスニペットが表示される。図１２に示す例では、右矢印記号->で示されている中間表現中のcall命令が、検出された脆弱性の発生要因になったことが分かる。

詳細メッセージ４３６には、検出された脆弱性に関する詳細を示すメッセージが表示される。図１２に示す例では、詳細メッセージ４３６として、「Format String must be String-Literal」と表示されており、このメッセージにより、フォーマット文字列には、文字列リテラルを指定しなければならないことが分かる。

結果情報４３８として、「1 violation(s) detected in this rule.」と表示されており、対象の中間表現には、フォーマット文字列バグの脆弱性が１件検出されたことが分かる。

サマリー部４４０には、対象の中間表現に対して検出された脆弱性の総数が表示される。より具体的には、サマリー部４４０には、サマリー情報４４２が表示される。サマリー情報４４２としては、「1 violation(s) detected in this rule」と表示されており、検証の結果、検出された脆弱性の総数が１件だったことが分かる。

＜Ｅ．実行環境＞
本実施の形態に従うソフトウェア開発システム１において生成された実行コード３０は、配布先のコントローラ３００を構成するプロセッサあるいはマイクロコンピュータのセキュア領域に格納されることが好ましい。すなわち、中間表現２０に対する認証を条件として生成された実行コード３０に対して、何らかの改ざん行為が行われないように、実行環境において何らかの対処を行うことが好ましい。

また、本実施の形態に従うソフトウェア開発システム１において生成された中間表現２０に対する証明書４０および中間表現２０から生成される実行コード３０のいずれにも共通の署名（例えば、認証された中間表現２０から生成されるハッシュ値）を埋め込んでおき、対応する証明書４０が存在することを条件としてもよい。この場合には、実行コード３０を実行する環境（典型的には、マイクロコンピュータのファームウェア）において、実行コード３０に含まれる署名と、対応する証明書４０に含まれる署名との一致を確認する処理を実装してもよい。

また、実行環境において、実行コード３０を実行するか否かの評価（正当性の判断）は、いずれのタイミングで行ってもよいが、典型的には、実行環境であるコントローラ３００の起動時（ファームウェアの起動中あるいは起動直後のアプリケーション実行開始前）に行うようにしてもよい。すなわち、実行コード３０が実行されるコントローラ３００の起動時に、その実行コード３０を生成した中間表現２０に関連付けて発行された証明書４０に基づいて、その実行コード３０の正当性を評価するようにしてもよい。コントローラ３００の起動時に、アプリケーションプログラムの実行コード３０が認証されていることを確認することで、コントローラ３００などで好ましくない処理が実行される事態を回避できる。

＜Ｆ．変形例＞
本実施の形態に従うソフトウェア開発システム１における検証については、検証サーバ２００で実行するようにしてもよいし、ソフトウェア開発装置１００において実行するようにしてもよい。検証サーバ２００で実行する場合には、クラウドコンピューティングの形態で実装してもよい。さらに、ソフトウェア開発装置１００において検証を実行する場合には、外部の認証機関により認証されたルールを用いるようにしてもよい。

ソフトウェア開発装置１００から検証サーバ２００へ中間表現２０の検証を依頼する際には、対象の中間表現２０を暗号化してもよい。これによって、ソフトウェア開発装置１００と検証サーバ２００との間でやり取りされる中間表現２０に対する改ざんなどを防止できる。

検証サーバ２００が発行する証明書４０には、認証局からの署名などを付与するようにしてもよい。これによって、検証サーバ２００が発行する証明書４０に対する改ざんなどの不正行為を防止できる。

上述の説明においては、ソフトウェア開発装置１００がソースコード１０の生成処理、中間表現２０の生成処理および実行コード３０の生成処理を実行する構成例について説明した、これらの処理を複数のコンピューティングデバイスで分散的に実行するようにしてもよい。

本実施の形態に従う中間表現２０に対する検証および検証結果を示す証明書４０の発行というフレームワークは、アプリケーションを販売あるいは配布する仕組みにも応用可能である。例えば、アプリケーションの開発者がアプリケーションプログラム（実行コード３０）をアプリケーション配布サーバにアップロードする際には、対応する中間表現２０および／または証明書４０を併せてアップロードすることを要求することで、アプリケーション配布サーバ側において、配布予定の実行コード３０を直接的または間接的に検証できる。このように、本実施の形態に従う仕組みを導入することで、バックドアなどが仕組まれたアプリケーションプログラムが配布されるような事態を回避できる。

このように、中間表現２０が脆弱性に関する所定の規則あるいは規約を満たしていることを条件として、中間表現２０から生成された実行コード３０の実行を許可する処理を採用してもよい。

さらに、証明書４０を利用して脆弱性に関する保険の仕組みを構成してもよい。具体的には、実行コード３０がインストールされる任意のデバイスの製造者は、検証エンジン２１２（検証サーバ２００）の利用に際して、所定の対価を支払う。検証エンジン２１２の運営者は、デバイスの製造者から得た対価の一部を保険会社に支払い、あるいは自身の保険金基金に組み入れる。

任意のデバイスで実行される実行コード３０は、検証エンジン２１２（検証サーバ２００）により提供される証明書４０の存在を条件として実行される。万が一、証明書４０の存在を条件として実行されている状態で、何らかのインシデントあるいはセキュリティ事象により、損害が発生した場合には、保険会社あるいは保険金基金から、その損害を補填するための保険金が支払われるようにしてもよい。

このような検証エンジン２１２（検証サーバ２００）が生成する証明書４０を利用して、脆弱性を管理するとともに、万が一の場合には、補償される仕組みを実現することで、検証エンジン２１２の利用を促進する動機付けを与えることができる。

＜Ｇ．利点＞
本実施の形態においては、ソースコード１０ではなく中間表現２０に対する検証を行うことで、ソースコード１０に含まれるノウハウなどを秘匿化した状態で、アプリケーションプログラムに含まれる脆弱性をより効率的に発見できる。

また、中間表現２０を検証することで、ソースコード１０の言語およびターゲットアーキテクチャなどに依存することなく、汎用的な検証が可能となる。

今回開示された実施の形態はすべての点で例示であって制限的なものでないと考えられるべきである。本発明の範囲は上記した説明ではなくて請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１ ソフトウェア開発システム、２ インターネット、４ エッジデバイス、１０ ソースコード、２０ 中間表現、３０ 実行コード、４０ 証明書、５０ デバッグ情報、１００ ソフトウェア開発装置、１０２，２０２ プロセッサ、１０４，２０４ メインメモリ、１０６，２０６ 入力部、１０８，２０８ ディスプレイ、１１０，２１０ ハードディスク、１１４ ソフトウェア開発プログラム、１２０，２２０ 内部バス、１２２，２２２ 通信インターフェイス、２００ 検証サーバ、２１２ 検証エンジン、２１４ 証明書発行エンジン、３００ コントローラ、４００ 検証結果、４１０ 管理部、４１２ パスワード、４１４ 識別情報、４２０ 検証対象情報部、４２２ ソースファイル名、４２４ メモリレイアウト情報、４２６ コンパイル環境情報、４３０ 解析内容部、４３２ 脆弱性情報、４３４ ソースコード情報、４３５ 中間表現情報、４３６ 詳細メッセージ、４３８ 結果情報、４４０ サマリー部、４４２ サマリー情報。

Claims (6)

1. ソースコードから中間表現を生成するステップと、
   前記中間表現が脆弱性に関する所定の規則あるいは規約を満たしているか否かを検証するステップと、
   前記検証するステップにより得られた検証結果を出力するステップとを備える、ソフトウェア検証方法。
2. 前記検証結果は、検出された脆弱性の種類を示す情報を含む、請求項１に記載のソフトウェア検証方法。
3. 前記検証結果は、検出された脆弱性が存在する前記中間表現の位置を示す情報を含む、請求項２に記載のソフトウェア検証方法。
4. 前記ソースコードから前記中間表現の生成時に、デバッグ情報を生成するステップをさらに備え、
   前記検証結果は、検出された脆弱性が存在する前記ソースコードの位置を示す情報を含む、請求項２または３に記載のソフトウェア検証方法。
5. 前記中間表現が前記所定の規則あるいは規約を満たしていることを条件として、前記中間表現から生成された実行コードの実行を許可するステップをさらに備える、請求項１〜４のいずれか１項に記載のソフトウェア検証方法。
6. ソフトウェア開発システムであって、
   ソースコードの作成を支援するソフトウェア開発装置と、
   前記ソフトウェア開発装置からアクセス可能な検証サーバとを備え、
   前記ソフトウェア開発装置は、前記ソースコードから中間表現を生成する手段を備え、
   前記検証サーバは、
   前記中間表現が脆弱性に関する所定の規則あるいは規約を満たしているか否かを検証する手段と、
   前記検証する手段により得られた検証結果を出力する手段とを備える、ソフトウェア開発システム。

Images