JP7218793B2 - プログラムの機能を向上するための制御フローシステム、非一時的可読媒体、および方法 - Google Patents

Description

関連出願の相互参照

この出願は、２０１８年１０月１８日に出願された米国特許出願第１６／１６３９１６号の利益を主張する。上記出願の全開示が、参照によりこの明細書に組み込まれる。

本開示は、一般に、プログラムの制御フローグラフを動的に更新するためのシステムおよび方法に関し、特に、脆弱性の識別および関数の自動計装を通じてプログラムの生成を向上するために、制御フローグラフを動的に提供することに関する。

この欄は、必ずしも公知技術に該当しない、本開示に関連する背景情報を提供する。

ソフトウェアプログラムの開発は複雑な作業になることがある。特に、プログラムが、たとえば、フォーマット、セキュリティ、パフォーマンスなどに関して所望の基準に適合することを保証することは、特にプログラムが比較的堅牢であり、および／または、複雑である場合には、非常に困難であり得る。すなわち、プログラムが長くなり、より複雑なプログラム／データ構造を含むようになると、プログラムの脆弱な態様（たとえば、関数）を識別し、関数がプログラムの他の部分とどのように相互作用するかを識別することが難しくなる。一般に、開発者は、プログラムを最適化するため、および／または、プログラム内の異なる関数／セグメント間の関係をよりよく理解するために、制御フローグラフを参照することがある。しかしながら、制御フローグラフを生成するための既存のアプローチは、プログラムの完了後に機能し、既存のアプローチでは、また、開発者が解釈するには非現実的であり得る大きく複雑なグラフを生成する。したがって、現在のアプローチでは、制御フローグラフをタイムリーに提供することができず、また、プログラムを最初に生成する際に有用であるように解釈することができない。

同様に、プログラムのソースコードに計装を追加すると、開発がさらに複雑になる可能性がある。計装は、コンピュータプログラムの文脈では、一般に、追加機能を提供するためにプログラム内に含まれる追加のコードセグメントを指す。追加機能は、追加の関数フック、セキュリティの確保、トレーサビリティの提供、制御フローの実施などに関連する場合がある。しかしながら、一般にプログラム内に含まれ、その後に検証されなければならない計装の多くの多様なセグメントを考慮すると、計装が正確にコード化されていない場合や、意図せずに省略（消失）されている場合がある。その結果、プログラムフローのような計装制御を行うプログラムの機能が適切に機能せず、脆弱な機能に起因するセキュリティホールのようなさらなる問題が発生する。

この欄は、開示の概要を提供するが、その全範囲またはその全特徴の包括的な開示ではない。

一実施形態では、プログラムの機能を向上することに関する例示的なシステムおよび方法が開示される。前述したように、制御フローグラフを生成する現在のアプローチは、事後にグラフを生成し、また、グラフが複雑で解釈が難しいため、一般に不十分である。その結果、開発者に対する制御フローグラフの有用性は、プログラムの開発時に制限される。さらに、プログラムを手動で計装するプロセスは、プログラムの開発を複雑にし、潜在的に計装が不十分なソースコードや、計装されていても所望の機能を発揮できないコードを生じる虞がある。

したがって、一実施形態では、プログラムの制御フローグラフをリアルタイムで生成する制御フローシステムが開示される。さらに、制御フローシステムは、一実施形態では、制御フローグラフを使用して、プログラムの適切な実行を保証するために、プログラムのソースコードを自動的に計装するなどの追加機能を提供する。たとえば、ひとつのアプローチでは、開示された制御フローシステムは、コードセグメントが、後でプログラムにコンパイルされるソースコードに追加されるときに、コードセグメントの統合開発環境を監視する。制御フローシステムは、コードセグメントの追加の検出に応答して、コードセグメントの制御フロー特性を識別する。

一般に、特性には、たとえば、関数呼び出し、リターンアドレスなど、プログラムの手順内または手順間の制御フローに影響を与える態様が含まれる。制御フロー特性の知識により、システムは、制御フローグラフのセクションを動的に生成／更新できる。たとえば、追加のコードセグメントがソースコードに統合されると、制御フローシステムは、ノード、有向エッジ、および、新たに統合されたコードセグメントに関連する制御フローグラフの他の態様を生成する。一態様では、制御フローシステムは、ソースコードが修正（たとえば、追加、改正など）されるときに、制御フローグラフに新しいセグメントを追加する、および／または、既存のセグメントを修正するように、制御フローグラフをリアルタイムで動的に更新する。

一実施形態では、制御フローシステムは、制御フローグラフを使用して視覚的表現を生成する。すなわち、システムは、ひとつのアプローチでは、プログラムの開発中にプログラムの制御フロー特性を開発者に通知する一態様として、統合開発環境内に制御フローグラフの視覚的表現を電子的に表示する。このように、制御フローグラフをリアルタイムで提供することは、制御フローおよびさらなる態様に関連するプログラムの適切なプログラム構造を確保することを容易にする。このように、制御フローシステムは、プログラムフローのより良い認識を通して、プログラムの機能と開発を向上する。

もちろん、制御フローグラフの視覚的表現が説明されているが、制御フローシステムは、追加機能を容易にするために、制御フローグラフをさらなるモジュール／システムに提供することもできる。たとえば、一実施形態では、制御フローシステムは、ソースコードを自動的に計装するメカニズムとして制御フローグラフを使用する。制御フローシステムは、たとえば、プログラムフローの確保を容易にする計装を含むべき、制御フロー特性をグラフ内で識別する。そのため、計装がソースコードの特定の態様とともに自動的に含まれるように、また、開発者が計装を別個に含むことを忘れずに、プログラムを開発しながら計装を検証できるように、システムは計装をリアルタイムで統合する。このように、制御フローシステムは、ソフトウェアの実行時に適切な制御フローをより確実にすることで、プログラムのセキュリティ、安全な開発、および最終的な機能を向上する。

一実施形態では、プログラムの機能を向上するための制御フローシステムが開示される。制御フローシステムは、ひとつ以上のプロセッサと、ひとつ以上のプロセッサに通信可能に結合されたメモリと、を備える。メモリは、ひとつ以上のプロセッサによって実行されると、ひとつ以上のプロセッサに、プログラムのソースコードに追加されるコードセグメントの検出に応答して、コードセグメントを含むソースコードの制御フロー特性を識別させる命令を含む分析モジュールを格納する。メモリは、ひとつ以上のプロセッサによって実行されると、ひとつ以上のプロセッサに、制御フロー特性にしたがってソースコードの制御フローグラフを更新させる命令を含むグラフモジュールを格納する。制御フローグラフは、ソースコードのブロックを表すノードと、ブロック間の遷移を表すノード間の有向エッジとで構成されるプログラムの実行パスを表す。グラフモジュールは、ソースコードの調整を容易にすることによってプログラムの機能を向上するために、制御フローグラフを提供する命令をさらに含む。

一実施形態では、非一時的コンピュータ可読媒体が開示される。コンピュータ可読媒体は、ひとつ以上のプロセッサによって実行されると、ひとつ以上のプロセッサに、開示された機能を実行させる命令を格納する。命令は、プログラムのソースコードに追加されたコードセグメントの検出に応答して、コードセグメントを含むソースコードの制御フロー特性を識別する命令を含む。命令は、制御フローの特性にしたがってソースコードの制御フローグラフを更新する命令を含む。制御フローグラフは、ソースコードのブロックを表すノードと、ブロック間の遷移を表すノード間の有向エッジとで構成されるプログラムの実行パスを表す。命令は、ソースコードの調整を容易にすることによってプログラムの機能を向上するために、制御フローグラフを提供する命令を含む。

一実施形態では、プログラムの機能を向上する方法が開示される。方法は、プログラムのソースコードに追加されたコードセグメントの検出に応答して、コードセグメントを含むソースコードの制御フロー特性を識別することを含む。方法は、制御フロー特性にしたがってソースコードの制御フローグラフを更新することを含む。制御フローグラフは、ソースコードのブロックを表すノードと、ブロック間の遷移を表すノード間の有向エッジとで構成されるプログラムの実行パスを表す。方法は、ソースコードの調整を容易にすることによってプログラムの機能を向上するために、制御フローグラフを提供することを含む。

この明細書に組み込まれ、その一部を構成する添付図面は、本開示の様々なシステム、方法、および他の実施形態を示している。図中の図示された要素の境界（たとえば、ボックス、ボックスのグループ、または他の形状）は、境界の一実施形態を表すことが理解されるであろう。いくつかの実施形態では、ひとつの要素が複数の要素として設計されてもよく、または複数の要素がひとつの要素として設計されてもよい。いくつかの実施形態では、別の要素の内部コンポーネントとして示される要素は、外部コンポーネントとして実装されてもよく、その逆もあり得る。さらに、要素は縮尺どおりに描かれない場合がある。
プログラムのソースコードに関して制御フローグラフの生成および関連する他の機能の実行に関連する制御フローシステムの一実施形態を示す図である。 プログラムのソースコードの一例を示す図である。 図１のシステムが図２のソースコードから導出する制御フローグラフの一例を示す図である。 制御フローグラフのさらなる一例を示す図である。 制御フローグラフの追加の例を示している。 リアルタイムで制御フローグラフを生成することに関連する方法の一実施形態を示す図である。 ソースコードを自動的に計装することに関連する方法の一実施形態を示す図である。 計装を含むソースコードの一部にタグ付けすることに関連する方法の一実施形態を示す図である。

制御フローグラフの動的生成および計装の自動包含を介してプログラムの機能を向上（改善）することに関連するシステム、方法、および、他の実施形態が開示される。前述したように、制御フローグラフを生成する現在のアプローチは、グラフがいつ利用可能になるかという適時性と、グラフの形式の複雑さに関するグラフの解釈可能性とに関連する問題が発生する。その結果、制御フローグラフは、前述の問題のために、開発時の適用が制限される可能性がある。

さらに、プログラムの開発時には制御フローグラフが一般に利用できないため、制御フローグラフによって容易化（促進）される得る追加機能も、また、遅延または完全に利用できない。たとえば、手動でプログラムを計装するプロセスは、プログラムの開発を複雑にし、潜在的に計装が不十分なソースコードや、計装されていても所望の機能を発揮できないコードを生じる虞がある。

一実施形態では、プログラムの制御フローグラフをリアルタイムで生成する制御フローシステムが開示される。さらに、制御フローシステムは、一実施形態では、制御フローグラフを使用して、制御フローグラフに関連して定義されたポリシーを通じてソースコードを自動的に計装するなどの追加機能を提供する。したがって、プログラムの自動計装を提供することは、プログラムの適切な実行（たとえば、プログラムフロー）を確保することを容易にする。

ひとつのアプローチでは、開示された制御フローシステムは、たとえば、コードセグメントのための統合開発環境内の電子データストリームを監視する。制御フローシステムがコードセグメントまたは既存のコードセグメントへの変更を検出すると、制御フローシステムは、たとえば、コードセグメントを分析し、コードセグメントが存在する場合、コードセグメントが既存のソースコードとどのように統合されているかを分析して、コードセグメントの制御フロー特性（すなわち、コードセグメントがプログラムフローに与える影響）を識別する。

一般に、特性には、たとえば、関数呼び出し、リターンアドレスなど、プログラムの手順内または手順間の制御フローに影響を与える態様が含まれる。制御フロー特性の知識により、システムは、制御フローグラフのセクションを動的に生成／更新できる。たとえば、追加のコードセグメントがソースコードに統合されると、制御フローシステムは、ノード、有向エッジ、および、新たに統合されたコードセグメントに関連する制御フローグラフの他の態様を生成／修正する。一態様では、制御フローシステムは、ソースコードが修正（たとえば、追加、改正など）されるときに、制御フローグラフに新しいセグメントを追加する、および／または、既存のセグメントを修正するように、制御フローグラフをリアルタイムで動的に更新する。

一実施形態では、制御フローシステムは、制御フローグラフを使用して視覚的表現を生成する。ひとつのアプローチでは、制御フローシステムは、プログラムの開発中にプログラムの制御フロー特性を開発者に通知する一態様として、制御フローグラフの視覚的表現を、リアルタイム更新で統合開発環境内に電子的に表示する。このように、制御フローグラフをリアルタイムで提供することは、制御フローおよびさらなる態様に関連するプログラムの適切なプログラム構造を確保することを容易にする。このように、制御フローシステムは、プログラムフローのより良い認識を通してプログラムの開発を容易にし、プログラムの機能（機能性）を向上する。

もちろん、制御フローグラフの視覚的表現が説明されているが、制御フローシステムは、追加機能を容易にするために、制御フローグラフをさらなるモジュール／システムに提供することもできる。たとえば、一実施形態では、制御フローシステムは、ソースコードを自動的に計装するメカニズムとして制御フローグラフを使用する。制御フローシステムは、たとえば、プログラムフローを監視し、確保し、または、他の方法で保証するための計装を含むべき、制御フロー特性をグラフ内で識別する。このように、システムはリアルタイムで計装を統合し、ソースコードの特定の態様とともに自動的に計装が含まれるようにし、開発者がプログラムを開発している間に、明示的に計装を含めることを覚えていなくても、その場で計装を検証できるようにする。このように、制御フローシステムは、適切なプログラムフローをより確実にすることで、プログラムの開発および最終的な機能を向上する。

図１を参照すると、制御フローシステム１００の一実施形態が示されている。この明細書では、制御フローシステム１００に関する構成について説明するが、実施形態は、図示のような単一システムに限定されない。いくつかの実装形態では、制御フローシステム１００は、クラウドコンピューティングシステム、クラスタコンピューティングシステム、分散コンピューティングシステム、サービスとしてのＳａａＳシステムなどとして具現化することができる。ＳａａＳは、software as a serviceの略称である。制御フローシステム１００は、説明の目的で単一の装置として示され、説明されているが、開示された構成要素が構成され得る全体的な可能な構成を制限するものとして解釈されるべきではない。たとえば、別個のモジュール、メモリ、データベースなどは、様々な組み合わせで様々なコンピューティングシステムに分散されてもよい。

制御フローシステム１００は、また、様々な要素を含む。様々な実施形態では、制御フローシステム１００が、図１に示される要素のすべてを有さなくてもよいことが理解される。制御フローシステム１００は、図１に示される様々な要素の任意の組み合わせを有することができる。さらに、制御フローシステム１００は、図１に示される様々な要素に対して追加の要素を有することができる。いくつかの構成では、制御フローシステム１００は、図１に示されるひとつ以上の要素なしで実施されてもよい。さらに、様々な要素は、図１の制御フローシステム１００内に位置するものとして示されているが、これらの要素のうちのひとつ以上が制御フローシステム１００の外部に配置できることが理解される。さらに、示された要素は、長い距離で物理的に分離されてもよい。

さらに、図示の単純化および明確化のために、参照番号が適宜、対応するまたは類似する要素を示すために、異なる図面間で繰り返されていることが理解される。さらに、この明細書に記載の実施形態は、記載された要素の様々な組み合わせを使用して実施できると理解される。この明細書に記載の実施形態の完全な理解を提供するために、多数の具体的な内容を説明する。しかしながら、当業であれば、この明細書に記載された実施形態は、これらの要素の様々な組み合わせを用いて実施され得ることを理解できる。

いずれの場合も、制御フローシステム１００は、プログラムの実行／プログラムフローの改善に関し、この明細書に開示されているような方法、および、他の機能を実行するために実装される。言及された機能と方法は、図のさらなる説明でより明らかになる。さらに、制御フローシステム１００は、プロセッサ１１０を備えるものとして示されている。様々な実施形態において、プロセッサ１１０は、制御フローシステム１００の一部であってもよく、制御フローシステム１００は、データバスまたは別の通信経路を介してプロセッサ１１０にアクセスしてもよく、プロセッサ１１０は、制御フローシステム１００によってアクセス可能なリモートコンピューティングリソースであってもよい。いずれの場合も、プロセッサ１１０は、マイクロプロセッサ、ＡＳＩＣ、グラフィックス処理装置（ＧＰＵ）、または、他の電子デバイスの制御のために使用され得る様々な電子出力をそこから生成するための機械可読命令を実行することが可能な他のコンピューティングコンポーネントのような電子デバイスである。

一実施形態では、制御フローシステム１００はメモリ１２０を備えており、メモリ１２０は、分析モジュール１３０、グラフモジュール１４０、および、計装モジュール１５０を格納している。分析モジュール１３０、グラフモジュール１４０、および、計装モジュール１５０を、以下では、モジュール１３０、１４０、１５０と示すことがある。メモリ１２０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、ハードディスクドライブ、フラッシュメモリ、または、モジュール１３０、１４０、１５０を格納するための他の適切なメモリである。モジュール１３０、１４０、１５０は、たとえば、プロセッサ１１０によって実行されると、プロセッサ１１０に、この明細書に開示される様々な機能を実行させるコンピュータ可読命令である。様々な実施形態では、モジュール１３０、１４０、１５０は、ハードウェアロジック、ＡＳＩＣ、グラフィックス処理装置（ＧＰＵ）、プロセッサ１１０のコンポーネント、電子メモリ内に埋め込まれた命令などを含むことができるが、これらに限定されない様々な態様で実装され得る。

制御フローシステム１００は、一実施形態では、データベース１６０を備える。データベース１６０は、一実施形態では、メモリ１２０、分散メモリ、クラウドベースのメモリ、または、別のデータストアに格納された電子データ構造であり、格納されたデータの分析、格納されたデータの提供、格納されたデータの整理などのためにプロセッサ１１０によって実行され得るルーチンで構成される。一実施形態では、データベース１６０は、様々な決定を実行する際にモジュール１３０、１４０、１５０によって使用されるデータを格納する。一実施形態では、データベース１６０は、グラフ１７０を格納する。さらなる実施形態では、制御フローシステム１００は、グラフ１７０を、メモリ１２０、専用のデータ構造、プロセッサ１１０のキャッシュメモリ、または、別の適切なデータストレージコンポーネントに格納する。

この明細書で使用される場合、「プログラム」という用語は、ソースコードから派生したコンパイルされたマシンコードを指す。したがって、プログラムは、一実施形態では、コンパイルされたプログラムまたはその一部であり、マシンコードである。この明細書で使用される「マシンコード」という語句は、一般に、たとえばプロセッサ１１０のようなマイクロプロセッサによって実行され得る機械語命令で表されるプログラムを指す。さらに、マシンコードは、一般に、関連するハードウェアによって実装される命令セットによって定義されるオペコードで構成されるプリミティブ言語、または、ハードウェア依存言語であると理解される。マシンコード自体は、データ値、レジスタアドレス、メモリアドレスなどでさらに構成される。もちろん、プログラムはマシンコードであると説明されているが、さらなる実施形態では、プログラムは、アセンブリコード、または、ソースコードの別の中間表現である。

プログラムのコンパイル元のソースコードは、たとえば、関数、データ構造、オブジェクト、ステートメント（文）などで構成される。ソースコードの一部として含まれる計装は、さらに同じ要素（たとえば、オブジェクト、ステートメントなど）で構成される。一般に、プログラムは、関数のセット（集まり）として構成されている。様々な例では、関数は、サブ関数として相互にネスト（入れ子）になっている場合がある。さらに、関数は、一般に、ステートメントのセット（たとえば、ループ、Ｉ／Ｏステートメントなど）で構成され、通常は特定の機能に焦点を当てている。すなわち、個々の関数は、一般に、特定のタスクを実行するために実装される。したがって、サブ関数は、親関数のより広範な機能をサポートするサブルーチンを実装することができる。いずれの場合も、関数は、関数自体を構成するステートメントを定義し、関数に関連付けられた機能を実装するためのソースコードが含まれる。

さらに、この明細書で説明するように、記載されたモジュール１３０、１４０、１５０は、統合開発環境へのプラグインとして機能してもよい。統合開発環境（ＩＤＥ）は、ソフトウェアの開発のための環境を提供するプログラムまたはプログラムの集合体である。たとえば、ＩＤＥは、ソースコードエディタ、ビルドツール、デバッガ、コンパイラ、インタプリタ、グラフィカルユーザインタフェース（ＧＵＩ）などを含むことができる。一般に、ＩＤＥは、プログラムの作成を容易にするツールや他の態様を備えた総合的な環境を提供することにより、開発者（すなわち、プログラマ）の効率を向上するメカニズムである。したがって、前述したように、ひとつ以上の態様において、モジュール１３０、１４０、１５０は、追加の機能を提供するためにＩＤＥと統合するプラグインである。したがって、ひとつのアプローチでは、モジュール１３０、１４０、１５０は、たとえば、ＩＤＥに電子的に提供されるコードセグメントを含む電子的な入力および出力ストリームを含むＩＤＥの電子データにアクセスする。モジュール１３０、１４０、１５０は、アクセスを容易にするために、ＩＤＥのアプリケーションプログラムインターフェース（ＡＰＩ）を活用してもよい。さらに、そのようなアクセスは、モジュール１３０、１４０、１５０の統合を自動化する（たとえば、直接統合アクセスを提供する）アプリケーションフックの形で提供されてもよい。いずれの場合も、システム１００、および、モジュール１３０、１４０、１５０は、一般に、ＩＤＥと協調的に機能する。したがって、実行中のＩＤＥは、一般に、プログラムのコンパイル元であるソースコードを管理し、また、ソースコードをプログラムに実際にコンパイルするための機能を提供してもよい。

データベース１６０の要素に続いて、グラフ１７０は、プログラムの実行パスを表す制御フローグラフである。以下では、グラフ１７０を制御フローグラフ１７０と示すことがある。一実施形態では、後でより詳細に説明するように、分析モジュール１３０およびグラフモジュール１４０は、ソースコードが動的にＩＤＥに提供されると、ソースコードからグラフ１７０を導出するように一緒に機能する。グラフモジュール１４０は、ひとつのアプローチでは、ノード、および、ノード間の有向エッジを用いてグラフを形成する。ノードはソースコードのブロック／セグメントを表し、ノード間の有向エッジはブロック間の遷移を表す。ブロックは、コードの原子セグメント（たとえば、途切れのない）、または、ソースコードの少なくとも一体的に関連するセグメントである。一実施形態では、有向エッジは、ブロック／セグメント間の手順内、および／または、手順間の制御フロー転送を示す。すなわち、エッジは、ハンドオーバ、関数呼び出し、具象関数、および／または、シンボリック関数の引数などを表す。一般に、有向エッジは、個別のブロック間のプログラム実行における転送を示す。別の実施形態では、ノードおよび有向エッジは、この明細書に記載されているものとは異なって定義されてもよいことが理解されたい。たとえば、ひとつのアプローチでは、有向エッジを定義するノード、条件を構成するセグメント／ブロックは、グラフポリシーにしたがって指定される。グラフポリシーは、ノードおよびエッジをそれぞれ形成するブロック／セグメントおよび遷移を識別するための、テンプレート、例示的なセグメント／条件、および／または、指標（メトリクス）を定義する。一般に、グラフモジュール１４０は、グラフポリシーを利用して、グラフ１７０を形成するために最適な要素を提供する。したがって、システム１００は、別々の実装にしたがってグラフ１７０の態様を柔軟に定義するように実装することができる。

図２は、プログラムのソースコード２００の例示的なセグメントを示している。また、図３は、制御フローグラフ３００の一例を示している。制御フローグラフ３００は、分析モジュール１３０を介して提供される入力からグラフモジュール１４０によって生成され得るグラフの例である。グラフ３００は、ソースコード２００からのコードのセグメント／ブロックに対応するノード３０５、３１０、３１５、３２０、３２５、３３０、３３５、３４０、３４５を含む。グラフ３００は、ソースコード２００のセグメント間の関係に対応するノード間の有向エッジをさらに示す。さらに、分離されたノードおよび有向エッジは、たとえば、ソースコードの制御フロー特性にしたがって定義される。すなわち、ソースコードのブロック／セグメントが、ブロック／セグメント自体の間の相互関係と区切りは、ソースコードの制御フロー特性にしたがって定義される。後述するように、グラフモジュール１４０は、一般に、プログラムのソースコードから制御フロー特性を識別し、システム１００内に定義されたグラフポリシーにしたがって識別することができる。

図４および図５は、ソースコードの異なるセグメントに対応する制御フローグラフ４００、５００のさらなる例を示す。たとえば、図４に示されるように、グラフ４００は、対応する有向エッジによって示されるように、ｉｆ－ｔｈｅｎ－ｅｌｓｅステートメント（文）を介して別々のパスと相関するソースコードの別々のセグメントに対応する４つの別々のノード４１０、４２０、４３０、４４０を含む。図５は、関連するブロック／関数内のコードのセグメントを表すノード５１０、５２０、５３０、５４０を含むグラフ５００を示す。グラフ５００は、出口ノード５４０につながる別個の有向エッジによって示されているように、ふたつの別個の出口条件を含むループを表す。このように、グラフ１７０は、プログラムの実行フローを表すために、ソースコードの多くの異なる構成を示すことができる。さらに、提供される例は、比較的短いコードセグメントに関するものであり、一般的な傾向として、グラフ１７０は、複数のノードおよびその間の有向エッジを含むことを理解されたい。一例としてグラフ４００、５００に示されているような「出口」ノードは、様々な実施形態において、一般に、実際のプログラムの出口（Ｅｘｉｔ：終了）ではなく、別々のコードセグメントへの遷移を示す。このように、グラフ１７０は、視覚的な形式で付与されると、開発者によるより良い理解を容易にし、また、様々なモジュールへのプログラムフローの理解を提供することによってさらに自動化された機能を容易にすることを提供する。

図１のデータベース１６０に引き続き、計装ポリシー１８０は、後でより詳細に説明するように、計装モジュール１５０がソースコード内に計装を含むソースコードの様々な条件、および／または、セグメントを定義する。一般に、計装は、特定の実装に応じて異なる目的を果たすことができる。たとえば、計装は、プログラムフローの制御（たとえば、プログラムが間違った方向に進んでいないことを保証する）、デバッグ、データ引数の検証、Ｉ／Ｏの検証などを提供するために、関数内に統合することができる。たとえば、プログラムが、道路上で車両がどのように制御されるかを自動的に調整するために高度運転支援システム（ＡＤＡＳ）を制御する例では、計装は、プログラムが悪意のある攻撃によって誤った方向に導かれた場合に、乗客に事故および負傷をもたらす可能性があるプログラムフローの悪意のある操作を防止するためのセキュリティ計装を含んでもよい。

さらなる態様では、計装ポリシー１８０は、計装閾値、または、少なくとも計装閾値を生成するための指標（メトリクス）も定義する。ひとつのアプローチでは、計装ポリシー１８０は、関数の異なるクラスに対して計装閾値を定義する。たとえば、一実施形態では、計装ポリシー１８０は、開発者によってタグ付けされるか、または、コードセグメントに関連付けられた定義された指標にしたがって導出され得るセキュリティレベルにしたがって、関数のクラスを定義する。計装ポリシー１８０は、第１のクラスに対する第１の閾値、第２のクラスに対する第２の閾値、第３のクラスに対する第３の閾値などを示すことができる。一般に、セキュリティレベルのための別個のクラスおよび関連する閾値は、特定の関数の脆弱性（たとえば、操作への暴露）または他の態様に関連してもよい。計装ポリシー１８０は、計装の包含を最適化するために、セグメントが計装されるべきである異なる閾値を示してもよい。このように、実際には、計装モジュール１５０は、たとえば、コードセグメントを評価し、評価にしたがって計装を自動的に含む。

さらに、コードセグメント内に含まれる実際の計装自体は、一実施形態では、前述したグラフポリシー内のテンプレートとして定義される。たとえば、テンプレートは、プログラムフローの制御、Ｉ／Ｏの検証、追加の関数フックの提供などに関する様々な機能を実行する、標準化された計装のセットを定義する。さらに、ひとつのアプローチでは、テンプレートは、計装が含まれる特定のコードセグメントにしたがって、たとえば、計装モジュール１５０によりカスタマイズされる変数をさらに示す。すなわち、計装モジュール１５０は、一例では、関数のリターンアドレスを検証するための計装を含んでもよい。このように、計装モジュール１５０は、テンプレートをベースとして使用することによって、関連するソースコードに対応するようにテンプレートから関連する計装ステートメントの変数を修正し、関連するソースコードセグメントにセキュリティまたは他の機能を提供する。計装ポリシー１８０および計装モジュール１５０のさらなる態様については、後述する。

一実施形態では、分析モジュール１３０は、プロセッサ１１０によって実行されると、コードセグメントがソースコードに追加されるときに、プロセッサにコードセグメントを検出させるコンピュータ可読命令を含む。ひとつのアプローチでは、分析モジュール１３０は、アプリケーションプログラムインターフェース（ＡＰＩ）、または、他のプログラムフックを介してＩＤＥ内部にアクセスし、ＩＤＥ内の電子入力ストリームにアクセスする。電子入力ストリームは、一般に、関連するコンピューティングデバイスの他のシステムコンポーネントを介してＩＤＥに提供される任意の電子入力を含む。たとえば、分析モジュール１３０は、プロセッサ１１０上で実行される他のプロセスからの電子入力、ネットワーク通信インターフェースを介して受信される電子通信、プロセス内（すなわち、ＩＤＥ内）通信、コンピューティングデバイス（たとえば、キーボード）に接続されたマシンインターフェースデバイスからのＩ／Ｏ入力、ファイルシステムリソースなどを監視する。

分析モジュール１３０は、ひとつのアプローチでは、プログラムのソースコードへの追加、および／または、修正のために、言及された電子入力を監視する。すなわち、分析モジュール１３０は、新しいコードセグメント、既存のコードセグメントを修正する入力などについて、ＩＤＥへの入力のストリームを監視する。

さらに、一実施形態では、分析モジュール１３０は、ソースコードの制御フロー特性を識別（特定）するためにソースコードを分析する命令も含む。すなわち、ソースコード内で変更が行われると、分析モジュール１３０は、変更が発生しているときにリアルタイムで変更を能動的（アクティブ）に検出し、ソースコード全体に関する変更を分析して、それに関連する制御フロー特性を識別する。一実施形態では、制御フロー特性は、プログラムの手順内、および／または、手順間の制御フロー転送、たとえば、関数呼び出し、シンボリック名に沿ったリターンアドレス、関数引数および及び戻り値、呼び出し規約等を含む。より一般には、制御フロー特性は、グラフ１７０の形態、および／または、内容に影響を与える任意の態様に関連する。したがって、分析モジュール１３０は、グラフモジュール１４０がグラフ１７０を更新された形式で維持できるように、制御フロー特性を識別するために言及された監視および分析をリアルタイムで行う。

したがって、グラフモジュール１４０は、一実施形態では、プロセッサ１１０によって実行されると、プロセッサ１１０に、制御フロー特性にしたがって制御フローグラフ１７０を更新させるコンピュータ可読命令を含む。グラフモジュール１４０は、一般に、グラフ１７０を、ノードおよび有向エッジを表すためのプログラム要素を含む電子データ構造として生成することに留意されたい。最初に、グラフモジュール１４０は、ヌル値を含むグラフ１７０、または、ソースコードが開発されるときにグラフモジュール１４０が言及された更新を通じて構築するエントリノードのみを生成する。

このように、グラフモジュール１４０は、グラフ１７０に対して調整／修正が行われると、グラフ１７０をリアルタイムで更新する。したがって、グラフモジュール１４０は、一実施形態では、分析モジュール１３０が、新しいコードセグメント、修正されたコードセグメント、ソースコードの態様を修正するための命令などを含む入力Ｉ／Ｏからの特性を決定するときに、制御フロー特性を能動的に使用する。したがって、グラフモジュール１４０は、ソースコードによって定義されたプログラムのリアルタイム評価を提供するために、修正／追加が発生するとグラフ１７０を区分的（断片的）に作成する。

さらに、グラフモジュール１４０は、一実施形態では、ソースコードの調整を容易にすることによってプログラムの機能を向上するために、制御フローグラフ１７０を提供する命令をさらに含む。すなわち、たとえば、グラフモジュール１４０は、変更／追加が発生するときにリアルタイムで変更／追加を含めることにより、グラフ１７０を作成する。グラフ１７０は、プログラムが実行されるときのプログラムの可能な実行パスおよび関連する条件を表す。したがって、グラフ１７０は、ソースコード内の潜在的なエラー（たとえば、無限ループ、公開関数など）についての洞察を提供し、これは、様々なモジュールおよびシステムを活用してソースコードを改善し、コンパイル後のプログラムの問題（たとえば、セキュリティホール、プログラム障害など）を回避することができる。

このように、グラフモジュール１４０は、一実施形態では、制御フローグラフ１７０の視覚的表現を生成し、統合開発環境（ＩＤＥ）内で視覚的表現を動的に表示することにより、グラフ１７０を提供する。したがって、コードセグメントが生成され、ＩＤＥに提供されると、分析モジュール１３０は、制御フロー特性を提供するために、ソースコード全体への影響とともにコードセグメントを識別および分析する。制御フロー特性から、グラフモジュール１４０は、修正の効果が開発者にリアルタイムで視覚的に示されるように、プログラムのリアルタイム表現としてグラフ１７０および視覚的表現を生成する。ひとつ以上の実施形態では、視覚的表現は、ＩＤＥ内のウィンドウに電子的に表示され、グラフ１７０への修正／更新を示す識別子を含む。

したがって、一例として、図２、図３、および図４を参照して、ソースコード２００が、ｉｆ－ｔｈｅｎ－ｅｌｓｅ形式のステートメント（文）を含むように修正されていると考える。分析モジュール１３０は、ソースコードへの修正を検出し、修正されたコードを分析して、制御フロー特性を生成する。次に、グラフモジュール１４０は、制御フロー特性にしたがって、新たに追加されたステートメントためのノードおよび有向エッジを生成し、グラフ３００を、たとえば、ノード３２５でグラフ４００を含むように修正する。このように、グラフモジュール１４０は、視覚的表現内でこの調整をさらにレンダリングして、新しく追加されたセグメントに適応するように元のグラフを調整しながら、変化をグラフィカルに示すことができる。

さらに、別の実施形態では、グラフモジュール１４０は、また、システム１００内のさらなるモジュール／コンポーネント、または、他のものに、グラフを提供する。たとえば、一実施形態では、制御フローシステム１００は、計装モジュール１５０を含む。計装モジュール１５０は、プロセッサによって実行されると、プロセッサ（たとえば、プロセッサ１１０）に、制御フローグラフ１７０にしたがってソースコード内に計装を統合させる命令を含む。たとえば、ひとつアプローチでは、計装モジュール１５０は、グラフ１７０によって反映されるように、ソースコード内の修正に応答して、リアルタイムで、ソースコードに計装を追加する。したがって、計装モジュール１５０は、グラフ１７０の変化、ソースコード内の新しいコードセグメントの包含、既存のコードセグメントへの修正などの特定の状態を監視することができ、これらは、たとえば、ＩＤＥのＡＰＩまたは別の適切なメカニズムを介して計装モジュール１５０への電子的な要求として作用する。電子要求は、一実施形態では、プログラムフローが保証される計装、および／または、計装がソースコードの特定のコードセグメントに関して別個の機能を提供する計装を含むように、計装モジュール１５０を誘導する。

前述したように、計装ポリシー１８０は、ソースコードのどの態様（たとえば、計装の場所およびタイプを識別するための指標または他の条件を介して）を計装するかを識別するための様々なメカニズムを示す。様々な態様において、計装モジュール１５０に含まれる計装は、プログラムの実行が制御フローグラフ１７０にしたがうことを保証することによって、プログラム内でランタイムチェック（実行時チェック）を実施するためのものである。したがって、計装モジュール１５０は、一般に、プログラムフローを実施するための計装を含める方法を知るために、グラフ１７０を介して伝達されるプログラムフローの知識を使用する。さらに、計装モジュール１５０は、さらなる態様では、データフローおよびプログラム内で計装される他の態様を理解するために、グラフ１７０を参照する。このようにして、計装モジュール１５０は、ランタイムチェックを自動的に計装することにより、プログラムのセキュリティを向上する。さらに、計装モジュール１５０は、一実施形態では、アドレスチェック（たとえば、データおよびプログラムフローのためのメモリアドレス）、変数／関数の戻り値の型チェック、データバインドチェック、オペコードチェック、マッチコール－リターンペア（非単一クラス）など、を実行するための計装を含む。

もちろん、計装モジュール１５０は、開発者が新しいコードセグメントを提供し、既存のコードセグメントを調整するように、リアルタイムでソースコード内に計装を動的に含むものとして説明されているが、計装モジュール１５０は、別の構成では、計装を含むように、ソースコードの完成または初期バージョンにわたって実行される。ひとつのアプローチでは、計装モジュール１５０は、プログラムをコンパイルする要求と並行して開始されると、自動的に計装を追加する。

いずれの構成においても、計装モジュール１５０は、ソースコードおよび制御フローグラフ１７０を分析して、ソースコード内に計装を統合する。特に、計装モジュール１５０は、制御フローグラフ１７０とソースコードとの間の相関関係にしたがって計装されるべきソースコードのセグメント、たとえば、グラフ１７０内の有向エッジによって識別されるソースコード内の手続き型遷移（たとえば、ジャンプ、コール、リターンなど）を識別する。さらに、計装モジュール１５０は、ソースコードにしたがってテンプレートの定義された計装をカスタマイズするために、定義された計装のテンプレートを修正することによって、識別（特定）されたセグメントにしたがって、計装を自動的に追加する。このようにして、定義された計装セットを、たとえば、追加された計装が要求どおりに動作することを保証するために、事前にテストして認定することができる。

さらに別の態様では、計装モジュール１５０は、ソースコードのタグ付け／ラベル付けされたセクションにしたがった計装を含む。すなわち、たとえば、一実施形態では、計装モジュール１５０は、ＩＤＥ内、特に、特定のステートメント内、特定のステートメントを識別するソースコードの関数または別のセグメント、計装されるべきソースコードの一部としての関数またはセグメント、の電子入力を監視する。様々なアプローチにおいて、電子入力は、計装の基本的な必要性を示すためにソースコードの部分にタグを付け、さらに別の態様では、入力は、含まれるべき特定の計装または少なくとも計装の特性を指定する。たとえば、提供されるラベルは、制御フロー計装で計装されるべき高感度／高価値の関数を示すことができ、さらなる態様では、提供されるラベル／タグは、計装の特性を指定するものではなく、コードの一部が自動的に計装されるように計装モジュール１５０によって分析されるべきであることを単に示すものであってもよい。

いずれの場合でも、計装モジュール１５０は、電子入力にしたがってソースコードの部分にラベル／タグを付けして、後続の世代の計装にさらに知らせることができる。電子入力の元の形式は、実装に応じて変化し得るが、一般に、ソースコードの一部にタグを提供するものとして、後続の入力の特性を指定するＩＤＥのＧＵＩ内の要素の選択を含む。たとえば、ひとつ以上の属性選択がＧＵＩ内でアクティブ化され、その後、選択されたソースコードの一部分がモジュール１５０によって自動的に属性でタグ付けされる。

制御フローグラフを生成し、そこからさらなる機能を提供する追加の態様が、図６に関連して説明される。図６は、リアルタイムで制御フローグラフを生成することに関する方法６００を示す。方法６００は、図１の制御フローシステム１００の観点から説明される。方法６００は、制御フローシステム１００と組み合わせて説明されるが、方法６００は、制御フローシステム１００内で実施されることに限定されず、代わりに、方法６００を実施することができるシステムの一例であることを理解されたい。

６１０で、分析モジュール１３０は、プログラムのソースコードに追加されるコードセグメントを監視し、定期的に検出する。すなわち、６１０で、コードセグメントを検出したか否か判断し、検出した場合に６２０に進む。この明細書で使用されるように、６１０におけるコードセグメントの追加は、一般に、新しいコードセグメントの追加、および、プログラムのソースコード内の既存のコードセグメントの修正を指すことに留意されたい。より一般には、分析モジュール１３０は、ソースコードへの変更をともなう入力（たとえば、コード、コマンドなど）について、コンピューティングデバイス内の統合開発環境（ＩＤＥ）への電子入力ストリームを監視する。したがって、分析モジュール１３０は、一実施形態では、ソースコードがいつ修正（すなわち、追加または変更）されるかを識別するために、たとえば、ＡＰＩを介してＩＤＥへの入力ストリームを継続的に監視する。その結果、言及された修正を検出すると、分析モジュール１３０は、ブロック６２０で制御フロー特性を識別することに進む。

６２０で、分析モジュール１３０は、グラフ１７０の制御フロー特性を識別（特定）する。一実施形態では、分析モジュール１３０は、ソースコード内のステートメントをトラバース（走査）するために深さ優先探索を使用してソースコードを分析する。さらなる態様では、分析モジュール１３０は、ソースコードをトラバースし、理解され得るような特性を識別するための他の適切なアプローチを実装する。分析モジュール１３０がソースコードをトラバースしているとき、モジュール１３０は、少なくとも関数呼び出し、関数リターンアドレス、関数引数、関数戻り値、およびステートメント間の関係を制御フロー特性として識別するために、ソースコード内のステートメントを解析する。

様々な実施形態において、分析モジュール１３０は、６１０で検出されたコードセグメント／変更に関連するソースコードの影響を受けた部分を分析し、さらなる態様では、分析モジュール１３０は、変更に応答して制御フロー特性を識別するために、ソースコード全体を再分析する。一般に、実行されるアプローチは、ソースコードの全体的なサイズ、修正のサイズ、および分析を実行するために利用可能なリソースに関連する。したがって、一実施形態では、分析モジュール１３０は、示された選好にしたがって制御フロー特性を決定するために、部分的または完全なレビューを選択的に行う。分析モジュール１３０によって実行されるいずれのアプローチであっても、制御フロー特性は、グラフ１７０に表されるプログラムの手順内、および／または、手順間の制御フロー転送に関する情報を提供する。

さらに、分析モジュール１３０は、一実施形態では、制御フロー特性をグラフポリシーと比較することにより、ソースコードのどのステートメントが脆弱性を含むかをさらに識別する。一実施形態では、グラフポリシーは、セキュリティの脆弱性およびパフォーマンスのボトルネックを示す条件を定義する。したがって、脆弱性およびボトルネックに関する追加情報は、また、ソースコードの異なる部分の特性についてのさらなる指標を提供するために、情報がその後グラフ１７０と統合されるように、制御フロー特性内に含めることができる。さらに、様々なアプローチにおいて、分析モジュール１３０は、脆弱性およびボトルネックを識別するために、グラフポリシーによって指定されたさらなる情報を使用する。このように、グラフポリシーは、脆弱性と相関する、データフロー、データ引数、データ消失、およびプログラムフロー、に関連するプログラム内の条件をさらに指定してもよい。いずれの場合も、分析モジュール１３０は、グラフ１７０に含めるために、制御フロー特性内のプログラムフローに直接的および間接的に関連する態様を含むことができる。

６３０で、グラフモジュール１４０は、制御フローグラフ１７０を更新する。一実施形態では、グラフモジュール１４０は、グラフ１７０のノードおよび有向エッジを形成するために、６２０で識別された制御フロー特性を使用する。制御フローグラフは、一般にプログラムの実行パスを表すことを考慮し、したがって、グラフモジュール１４０は、制御フロー特性を使用して、グラフ１７０が形成される異なるコードセグメント（たとえば、ノード）間のパス（たとえば、有向エッジ）を識別する。したがって、グラフモジュール１４０は、コードセグメントに対応するように制御フローグラフの既存のノードおよびエッジを修正しつつ、検出されたコードセグメントに対応する制御フロー特性を追加することにより、制御フローグラフ１７０を更新する。すなわち、たとえば、既存の有向エッジは、追加ノードを追加しながら再ルーティングされてもよく、既存のノードは修正されてもよく、指示された条件は修正されてもよく、または新たな条件が追加されてもよい。

さらに、前述したように、グラフモジュール１４０は、グラフ１７０を更新するためにコードセグメントがソースコードに追加されるときに、リアルタイムで機能する。このように、グラフモジュール１４０は、プログラムの開発を容易にするためにグラフ１７０を直接参照することができるように、グラフ１７０を更新された形式で維持する。

さらに、グラフモジュール１４０は、また、グラフ１７０を先に説明したような追加の特性で更新する。すなわち、グラフモジュール１４０は、ノードに関連付けられたコードセグメントの脆弱性、様々なノードに関連付けられボトルネック、および他の注目すべき特性について、グラフ１７０にタグを付けるかまたは別の方法で、コメント（アノテーション）を提供する。したがって、グラフモジュール１４０は、ソースコードが書き込まれているときにグラフ１７０を能動的に作成するだけでなく、グラフモジュール１４０は、たとえば、特定の特性を強調することによって脆弱性およびボトルネックの緩和を容易にするために、対応するノードのデータ構造内のコードセグメントに関する追加情報も提供する。

６４０で、グラフモジュール１４０は、ソースコードの調整を容易にすることによってプログラムの機能を向上するために、制御フローグラフ１７０を提供する。前述したように、制御フローグラフ１７０は、プログラムの実行がどのように進行するかの表現を提供し、したがって、一般に他の方法では識別できないソースコードについての洞察を提供する。このように、様々なシステムは、ソースコードを操作するために、および／または、開発者にさらなる機能を提供するために、グラフ１７０を活用することができる。

６４０で制御フローグラフ１７０を提供する一態様として、グラフモジュール１４０は、制御フローグラフの視覚的表現を生成し、プログラムのリアルタイム表現を提供するために、コードセグメントが生成されると統合開発環境（ＩＤＥ）内に視覚的表現を動的に表示する。視覚的表現は、たとえば、図３～図５のグラフと同様の方法で、ノード、有向エッジ、およびソースコードの他の記号表現を含むグラフィックとして提供される。さらに、グラフ１７０は、また、言及された脆弱性およびパフォーマンスのボトルネックのような、グラフ１７０および基礎となるソースコードの異なる属性を強調することができる様々な色で表示するように視覚的に表現することができる。このようにして、システム１００は、プログラムがソースコードの開発をよりよく通知することによって、プログラムがパフォーマンスのボトルネックおよびセキュリティの脆弱性を回避することを保証することにより、最終的なプログラムの機能を向上する。前述したように、グラフ１７０は、また、図７に関連して次に説明するように、追加の機能を提供するためにさらなるシステム／モジュールによって利用することもできる。

図７は、プログラムのソースコードを自動的に計装することに関する方法７００を示している。図６同様、方法７００は、図１の制御フローシステム１００の観点から説明される。方法７００は、制御フローシステム１００と組み合わせて説明されるが、方法７００は、制御フローシステム１００内で実施されることに限定されず、代わりに、方法７００を実施することができるシステムの一例であることを理解されたい。

手始めに、方法７００は、図６の方法６００から、ブロック６１０、６２０、６３０を含むように示されている。したがって、上記したブロックについての説明は省略する。さらに、グラフ１７０は、一般に、ブロック６３０の電子出力として、ブロック７１０で方法７００に提供されることを理解されたい。

７１０で、計装モジュール１５０は、ソースコードを計装する要求を監視し、検出する。すなわち、７１０で計装要求を取得（受信）したか否かを判断し、取得した場合に７２０に進む。様々な実施形態では、要求は、異なる形式をとることができる。たとえば、ひとつのアプローチでは、要求は、グラフ１７０が修正されるソースコードに対する修正と一致する。すなわち、ソースコードの修正に応じてグラフ１７０が更新されると、計装モジュール１５０は、また、追加されたコードセグメントまたは既存のコードセグメントに対する変更のために計装が含まれる場合、修正のためにリアルタイムでソースコードを計装するように機能する。

あるいは、計装要求は、ソースコードが完了したとき、または、さらなる態様では、ソースコードがプログラムにコンパイルされるときに、システム１００によって生成される。したがって、ソースコードを計装する要求は、一実施形態では、ＩＤＥ内で生成されたソースコードをコンパイルする要求に応答してシステム１００によって生成され、コンパイルの前に実行される。このように、計装モジュール１５０は、ソースコードが修正されたとき、または、ソースコードがコンパイルされる準備ができたときに、リアルタイムでソースコードを計装するように機能する。

７２０で、計装モジュール１５０は、計装されるべきソースコードのコードセグメントを識別（特定）する。一実施形態では、計装モジュール１５０は、ソースコード内のセグメントに配置された既存のタグ、コードセグメントに関連付けられたグラフ１７０内のラベル付けされた特性、グラフ１７０内で表される識別された制御フロー、および／または、計装ポリシー１８０によって定義されたさらなる指標／特性にしたがって、コードセグメントを識別する。一般に、計装モジュール１５０は、実行中のプログラムの流れを確実にし、たとえば、悪意のあるリダイレクトを防ぐために、ソースコードを計装する。このように、計装モジュール１５０は、関数間の制御の転送、プログラムフローアドレスの調整、および他のそのようなコードセグメントに、直接的または間接的に関与しているコードセグメントを識別する。一般に、言及されたコードセグメントは、グラフ１７０内の有向エッジ、または、有向エッジによって具現化される転送に関連する条件に関連付けられる。

したがって、さらなる態様では、計装モジュール１５０は、制御フローグラフ１７０にしたがってソースコードを分析する。計装モジュール１５０は、また、ひとつ以上の実施形態では、コードセグメントが計装を含むために実装された計装ポリシー１８０を満たすか否かを決定するために、個々のコードセグメントを分析することができる。すなわち、重要度レベル、セキュリティレベルなどに応じた閾値等の様々な条件を識別して、関数内に計装を含めるタイミングを決定することができる。このようにして、プログラムのパフォーマンスとセキュリティを考慮し、不要な場合に計装を不必要に含めることを避けるために、計装をインテリジェントな方法で含めることができる。

いずれの場合も、ソースコード内のすべてのコードセグメント／関数が計装されるわけではないため、７２０でのチェックは、コードセグメントが計装されるべきか否かを評価することを含み得る。すなわち、たとえば、計装モジュール１５０は、コードセグメントが計装を含むか否かを判断するために、新たに追加／調整されたコードセグメントの特性を評価する。計装モジュール１５０が、コードセグメントが計装されるべきであると決定した場合、計装モジュール１５０は、ブロック７３０で説明されるように、計装を統合し続ける。そうでなければ、計装モジュール１５０は、修正されたセグメントのみが考慮されている場合、または、他のセグメント全体が考慮されていない場合に、終了してもよい。

７３０で、計装モジュール１５０は、ソースコード内に計装を統合する。前述したように、一実施形態では、計装モジュール１５０は、プログラムの実行が制御フローグラフ１７０にしたがうことを保証することによってプログラムのセキュリティを向上させるプログラム内のランタイムチェックを実行するために、制御フローグラフ１７０にしたがった計装を含む。すなわち、ソースコードに追加される計装は、プログラムがグラフ１７０によって表されるパスの外に向けられないことを保証する。

さらに、計装を統合するプロセスは、一実施形態では、計装モジュール１５０が、ソースコードにしたがって定義された計装のテンプレートを修正することによって、識別されたセグメントにしたがって計装を自動的に追加することを含む。前述したように、計装モジュール１５０は、計装が統合されているコードセグメントに適合するように、テンプレートの可変アスペクトを調整する。したがって、計装モジュール１５０は、特定の機能を達成するために、含まれる計装をカスタマイズする一方で、たとえば、事前に承認されており、正しく機能することが一般的に知られている計装を使用する。このようにして、計装モジュール１５０は、グラフ１７０を使用して、安全なプログラムフローを保証することにより、最終的に得られるプログラムを改善する追加機能を提供する。

図８は、計装を含むコードセグメントを自動的に識別することに関する方法８００を示す。図６および図７同様、方法８００は、図１の制御フローシステム１００の観点から説明される。方法８００は、制御フローシステム１００と組み合わせて説明されるが、方法８００は、制御フローシステム１００内で実施されることに限定されず、代わりに、方法８００を実施することができるシステムの一例であることを理解されたい。

８１０で、計装モジュール１５０は、コードセグメントにタグ付けするための電子入力の有無を判断する。すなわち、電子入力を検出したか否かを判断する。一実施形態では、計装モジュール１５０は、たとえば、タグ付け動作がいつ開始されたかを識別するために、ＩＤＥのＧＵＩによって生成された電子要求を監視する。タグ付け動作は、最初に、第１の電子入力を介してＩＤＥ内の制御機能を選択し、次いで、タグ付けされるべき関数／コードセグメントを示す第２の電子入力を選択することを含み得る。第１の電子入力は、一実施形態では、タグ付けに関連するＩＤＥ内の機能をアクティブにし、第２の電子入力は、たとえば、どのセグメント／関数がタグ付けされるかを識別する。

ひとつのアプローチでは、ＩＤＥ内の電子入力の組み合わせは、自動化されたソース（たとえば、ＩＤＥ内で実行されるスクリプト）からのものでも、Ｉ／Ｏインターフェース（たとえば、ＨＭＩ入力）を介して受信された電子入力によるものでもよく、電子要求を形成する。したがって、計装モジュール１５０は、一実施形態では、ＩＤＥによって生成される電子要求を監視する。電子要求は、計装される関数／コードセグメント、計装の特性（たとえば、制御フロー、データ検証など）などの様々な態様を示すことができる。

８２０で、計装モジュール１５０は、８１０で電子入力／要求を検出したことに応答して、タグ付けされるソースコードの一部を識別（特定）する。ひとつのアプローチでは、計装モジュール１５０は、タグ付けされるべきコードセグメントを識別する後続の選択を識別するための要求を検出すると、ＨＭＩ入力を追跡する。あるいは、要求自体がコードセグメントを示すので、計装モジュール１５０は、コードセグメントを識別するために要求を解析する。いずれの場合も、コードセグメントは、要求の生成と識別を通じてタグ付けされる高価値のコードセグメントとして識別される。

８３０で、計装モジュール１５０は、識別されたコードセグメント（関数）に計装識別子をタグ付けする。一実施形態では、計装モジュール１５０は、識別されたコードセグメントが計装されることを示すコメントをソースコード内に含むことによって、識別されたコードセグメントにタグを付ける。コメントは、また、コードセグメントに関する特性、および、コードセグメントの計装方法に関する特性を含むことができる。すなわち、コメントは、識別されたセグメントが自動的に計装されることを示すとともに、計装がプログラム制御フロー保護、データ型チェックなどを提供することを指定することができる。さらに、コメントのフォーマットは、一般に、言及された情報を伝達し、その後ソースコードを計装する際にタグを容易に識別するために符号化されるひとつ以上の特定の文字シーケンス（文字列）を含むことを理解されたい。

８４０で、計装モジュール１５０は、タグ付き関数を計装する。前述したように、計装モジュール１５０は、コードセグメントを識別し、自動的に計装することができる。したがって、８４０において、計装モジュール１５０は、一実施形態では、方法７００に関して説明したのと同様のアプローチにしたがう。しかしながら、この場合、コードセグメント／関数は、タグにしたがってすでに識別されているので、計装モジュール１５０は、関数を独立して識別するためにソースコードを個別に分析する必要はない。さらに、計装モジュール１５０は、一実施形態では、識別されたコードセグメントに含まれるタグに応答して、ブロック７３０とともに説明した関数を計装する。

さらに、図１の制御フローシステム１００は、別個の集積回路、および／または、チップを用いて様々な構成によって構成できることが理解されるべきである。そのような実施形態では、分析モジュール１３０は、個別の集積回路として具現化される。さらに、グラフモジュール１４０は、個々の集積回路上に具現化される。さらに、計装モジュール１５０は、個々の集積回路上に具現化される。回路は接続パスを介して接続され、個別の回路間で信号を通信する。もちろん、別個の集積回路が論じられているが、様々な実施形態では、回路は、共通の集積回路基板に統合されてもよい。さらに、集積回路は、より少ない集積回路に組み合わせるか、またはより多くの集積回路に分割することができる。別の実施形態では、モジュール１３０、１４０、１５０は、別個の特定用途向け集積回路に組み合わされてもよい。さらなる実施形態では、モジュール１３０、１４０、１５０に関連する機能の一部は、プロセッサ１１０によって実行可能であり、非一時的メモリに格納されるファームウェアとして具現化されてもよい。さらなる実施形態では、モジュール１３０、１４０、１５０は、プロセッサ１１０のハードウェアコンポーネントとして統合される。

別の実施形態では、説明された方法、および／または、それらの等価物は、コンピュータ実行可能命令で実装されてもよい。したがって、一実施形態では、非一時的なコンピュータ可読媒体は、格納されたコンピュータ実行可能命令とともに構成されている。格納されたコンピュータ実行可能命令は、機械（たとえば、プロセッサ、コンピュータなど）によって実行されると、機械、および／または、関連するコンポーネントに方法を実行させる。

説明を簡単にするために、図に示されている方法論は一連のブロックとして示され説明されているが、いくつかのブロックは異なる順序で実行されることがあり、および／または、図示および説明から他のブロックと同時に実行されることがあり、方法論はブロックの順序によって制限されないことが理解されるべきである。さらに、例示されたブロックのすべてが、例示的な方法論を実装するために使用されてもよい。ブロックは、複数のコンポーネントに結合、または、分離されることがある。さらに、追加の、および／または、代替の方法論は、図示されていない追加のブロックを使用することができる。

制御フローシステム１００は、ひとつ以上のプロセッサ１１０を含むことができる。ひとつ以上の構成では、プロセッサ１１０は、制御フローシステム１００のメインプロセッサであり得る。たとえば、プロセッサ１１０は、電子制御装置（ＥＣＵ）であり得る。制御フローシステム１００は、ひとつ以上のタイプのデータを格納するためのひとつ以上のデータストアを含むことができる。データストアは、揮発性、および／または、不揮発性メモリを含むことができる。適切なデータストアの例には、ＲＡＭ（ランダムアクセスメモリ）、フラッシュメモリ、ＲＯＭ（リードオンリーメモリ）、ＰＲＯＭ（プログラマブルリードオンリーメモリ）、ＥＰＲＯＭ（消去可能プログラマブルリードオンリーメモリ）、ＥＥＰＲＯＭ（電気的消去可能プログラマブルリードオンリーメモリ）、レジスタ、磁気ディスク、光ディスク、ハードドライブ、分散メモリ、クラウドベースのメモリ、開示されたデータを格納するのに適した他の記憶媒体、またはそれらの任意の組み合わせが含まれる。データストアは、プロセッサ１１０のコンポーネントとすることができ、またはデータストアは、使用のためプロセッサ１１０に動作可能に接続することができる。この説明全体を通して使用される「動作可能に接続された」という用語は、直接的な物理的接触のない接続を含む、直接または間接の接続を含みえる。

この明細書では詳細な実施形態が開示されている。しかしながら、開示された実施形態は、例としてのみ意図されていることが理解されるべきである。したがって、この明細書に開示される特定の構造的および機能的詳細は、限定事項として解釈されるべきではなく単に請求項の基礎として、および、実質的に任意の適切な詳細な構造でこの明細書の態様を様々に使用することを当業者に教示するための代表的な基礎としてのみ解釈されるべきである。さらに、この明細書で使用される用語および語句は、限定することを意図するものではなく、可能な実装の理解可能な説明を提供することを意図している。種々の実施形態が図１～図８に示されているが、実施形態は、図示された構造または用途に限定されない。

図中のフローチャート、および、ブロック図は、様々な実施形態による、システム、方法、および、コンピュータプログラム製品の可能な実装のアーキテクチャ、機能、および、動作を示している。これに関して、フローチャート、または、ブロック図の各ブロックは、指定された論理機能を実装するためのひとつ以上の実行可能な命令を含むコードのモジュール、セグメント、または、部分を表すことができる。また、一部の代替実装では、ブロックに記載されている機能が、図に記載されている順序とは異なる順序で発生する場があることにも注意されるべきである。たとえば、連続して示されたふたつのブロックは、実際には実質的に同時実行されてもよいし、関係する機能に応じて、ブロックが逆の順序で実行されることもある。

上記のシステム、コンポーネント、および／または、プロセスは、ハードウェア、または、ハードウェアとソフトウェアの組み合わせで実現でき、ひとつの処理システムで集中方式によって、または、複数の相互接続された処理システムに異なる要素が分散している分散方式によって実現することができる。この明細書に記載の方法を実行するように適合されたあらゆる種類の処理システム、または、別の装置が適している。ハードウェアとソフトウェアの組み合わせは、コンピュータで使用可能なプログラムコードを備えた処理システムであり、読み込まれて実行されると、ここで説明する方法を実行するように処理システムを制御する。システム、コンポーネント、および／または、処理は、たとえば、機械によって読み取り可能であって、ここに記述された処理、および、方法を実行するために機械によって実行可能な指令のプログラムに実体的に実装された、コンピュータプログラム製品の記憶装置、または、他のデータプログラムの記憶装置として、コンピュータによって読み取り可能な記憶装置に埋め込むことができる。これらの要素は、この明細書に記載の方法の実施を可能にし、処理システムにロードされたときにこれらの方法を実行できるすべての機能を含むアプリケーション製品に組み込むこともできる。

さらに、この明細書で説明された構成は、たとえば記憶されるなどして、実施されるコンピュータ可読プログラムコードを有するひとつ以上のコンピュータ可読媒体に具現化されるコンピュータプログラム製品の形をとることができる。ひとつ以上のコンピュータ可読媒体の任意の組み合わせが利用されてもよい。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体であり得る。「コンピュータ可読記憶媒体」という語句は、非一時的な記憶媒体を意味する。コンピュータ可読媒体は、限定されるものではないが、不揮発性媒体および揮発性媒体を含む、形態をとってもよい。不揮発性媒体には、たとえば、光ディスク、磁気ディスクなどが含まれる。揮発性媒体には、たとえば、半導体メモリ、ダイナミックメモリなどが含まれる。そのようなコンピュータ可読媒体の限定的ではない例には、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープ、および、その他の磁気媒体、または、ＡＳＩＣ、または、グラフィックス処理装置（ＧＰＵ）、または、ＣＤ、および、その他の光学媒体、または、ＲＡＭ、または、ＲＯＭ、または、メモリチップ、または、メモリカード、または、メモリスティック、または、他の媒体を含むことができ、これらは、コンピュータ、プロセッ、または、他の電子デバイスが読み取り可能である。この明細書の文脈において、コンピュータ可読記憶媒体は、命令実行システム、機器、またはデバイス（装置）によって、またはそれに関連して使用するためのプログラムを含むか、または、記憶することができる任意の有形の媒体であり得る。

以下の説明は、この明細書で使用される選択された用語の定義を含んでいる。定義には、用語の範囲に含まれ、様々な実装に使用できるコンポーネントの様々な例や形式が含まれている。例は、制限することを意図したものではない。用語の単数形と複数形の両方が定義内にある場合がある。

「ひとつの実施形態」、「一実施形態」、「ひとつの例」、「一例」などへの言及は、そのように説明された実施形態、または、例が、特定の特徴、構造、特性、内部特性、要素、または、制限を含み得ることを示すが、それらの実施形態、または、例が、必須のものとして、特定の特徴、構造、特性、内部特性、要素、または、制限を含むことを示すものではない。さらに、「一実施形態では」という語句の繰り返しの使用は、同じ実施形態を指す場合があるが、必ずしもそうであるとは限らない。

この明細書で使用される「モジュール」は、コンピュータ、または、電気ハードウェアコンポーネント、ファームウェア、命令を格納する非遷移的なコンピュータ可読媒体、および／または、これらのコンポーネントの組み合わせを含み、これらは、機能、または、アクションを実行するか、および／または、別のロジック、方法、および／または、システムに、機能、または、アクションを発揮させるように構成されている。モジュールは、アルゴリズムによって制御されるマイクロプロセッサ、多数の電気素子を含む論理回路（たとえば、ＡＳＩＣ）、アナログ回路、デジタル回路、プログラムされた論理デバイス、実行時にアルゴリズムを実行する命令を含むメモリデバイスなどを含むことができる。モジュールは、ひとつ以上の実施形態では、ひとつ以上のＣＭＯＳゲート、ゲートの組み合わせ、または他の回路構成要素を含む。複数のモジュールが説明される場合、ひとつ以上の実施形態は、複数のモジュールをひとつの物理モジュール構成要素に組み込むことを含む。同様に、単一のモジュールが説明される場合、ひとつ以上の実施形態は、複数の物理的構成要素に、単一のモジュールを分配することを含む。

さらに、この明細書で使用されるモジュールには、タスクを実行したりデータ型を実装したりするルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。さらなる態様では、メモリは一般に、言及されたモジュールを格納する。モジュールに関連付けられたメモリは、プロセッサ、ＲＡＭ、ＲＯＭ、フラッシュメモリ、または、別の適切な電子記憶媒体内に埋め込まれたバッファ、または、キャッシュである場合ある。さらに別の態様では、この開示によって想定されるモジュールは、特定用途向け集積回路（ＡＳＩＣ）、システムオンチップ（ＳｏＣ）のハードウェアコンポーネント、プログラマブルロジックアレイ（ＰＬＡ）、または開示された機能を実行するための定義された構成セット（たとえば、命令）が組み込まれた別の適切なハードウェアコンポーネントとして実装される。

ひとつ以上の構成では、この明細書で説明されるひとつ以上のモジュールは、人工知能要素、または、計算知能要素、たとえば、ニューラルネットワーク、ファジーロジック、または、他の機械学習アルゴリズムを含むことができる。さらに、ひとつ以上の構成では、ひとつ以上のモジュールを、この明細書で説明する複数のモジュール間で分散させることできる。ひとつ以上の構成では、この明細書で説明されているふたつ以上のモジュールを組み合わせて単一のモジュールにすることができる。

コンピュータ可読媒体上で実施されるプログラムコードは、無線、有線、光ファイバ、ケーブル、ＲＦなど、または、前述要素の任意の適切な組み合わせを含むがこれらに限定されない任意の適切な媒体を使用して送信することができる。この構成の態様の動作を実行するためのコンピュータプログラムコードは、Ｊａｖａ（登録商標）、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語、および、Ｃプログラミング言語、同様のプログラミング言語などを含む従来の手続き型プログラミング言語を含むひとつ以上のプログラミング言語の任意の組み合わせで書くことができる。プログラムコードは、完全にユーザのコンピュータにおいて、一部はユーザのコンピュータにおいて、スタンドアロンソフトウェアパッケージとして、一部はユーザのコンピュータにおいて、残る一部はリモートコンピュータにおいて、または、完全にリモートコンピュータ、または、サーバーで実行することができる。後者のシナリオでは、リモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）、または、ワイドエリアネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してユーザのコンピュータに接続されてもよく、または接続は、外部コンピュータ（たとえば、インターネットサービスプロバイダを使用してインターネットを介して）に接続されてもよい。

この明細書で使用される要素の数は、ひとつ、または、ふたつ以上として定義される。この明細書で使用される「複数」という用語は、ふたつ、または、ふたつ以上として定義される。この明細書で使用される「別の」という用語は、少なくとも第２、または、それ以上として定義される。この明細書で使用される「含む」、および／または、「有する」という用語は、「備える」を意味し、すなわち、他の要素の存在を許容する用語として定義される。「・・・と・・・との少なくともひとつ」という表現は、関連付けて列挙された項目のひとつ、または、複数のありとあらゆる可能な組み合わせを指し、それらを包含するものとして解釈されるべきである。一例として、「Ａ、Ｂ、および、Ｃのうちの少なくともひとつ」という語句は、Ａのみ、Ｂのみ、Ｃのみ、またはそれらの任意の組み合わせ（たとえば、ＡＢ、ＡＣ、ＢＣ、または、ＡＢＣ）を含む。

この明細書の態様は、その精神、または、本質的な属性から逸脱することなく、他の形態で具体化することができる。したがって、この明細書の範囲を示すために、前述の明細書ではなく、以下の特許請求の範囲を参照する必要がある。

Claims (24)

1. プログラムの機能を向上するための制御フローシステムであって、
   ひとつ以上のプロセッサ（１１０）と、
   ひとつ以上の前記プロセッサに通信可能に結合されたメモリ（１２０）と、を備え、
   前記メモリは、分析モジュール（１３０）と、グラフモジュール（１４０）と、を格納しており、
   前記分析モジュールは、ひとつ以上の前記プロセッサによって実行されると、ひとつ以上の前記プロセッサに、前記プログラムのソースコードに追加されたコードセグメントの検出に応答して、前記コードセグメントを含む前記ソースコードの制御フロー特性を識別させる命令を含み、
   前記グラフモジュールは、ひとつ以上の前記プロセッサによって実行されると、ひとつ以上の前記プロセッサに、前記制御フロー特性にしたがって前記ソースコードの制御フローグラフを更新させる命令を含み、
   前記制御フローグラフは、前記ソースコードのブロックを表すノードと、前記ブロック間の遷移を表す前記ノード間の有向エッジとで構成される前記プログラムの実行パスを表し、
   前記グラフモジュールは、前記ソースコードの調整を容易にすることによって前記プログラムの機能を向上するために、前記制御フローグラフを提供する命令をさらに含み、
   前記グラフモジュールは、前記制御フローグラフを提供する命令として、前記制御フローグラフの視覚的表現を生成し、前記コードセグメントが前記制御フローグラフを介して前記プログラムのリアルタイム表現を提供するように生成されるときに、統合開発環境（ＩＤＥ）内で前記視覚的表現を動的に表示する命令を含み、
   前記グラフモジュールは、前記制御フローグラフを更新する命令として、前記コードセグメントに対応するように前記制御フローグラフの既存のノードおよびエッジを修正しながら、前記コードセグメントに対応する前記制御フロー特性を前記制御フローグラフに追加する命令を含む、制御フローシステム。
2. プログラムの機能を向上するための制御フローシステムであって、
   ひとつ以上のプロセッサ（１１０）と、
   ひとつ以上の前記プロセッサに通信可能に結合されたメモリ（１２０）と、を備え、
   前記メモリは、分析モジュール（１３０）と、グラフモジュール（１４０）と、を格納しており、
   前記分析モジュールは、ひとつ以上の前記プロセッサによって実行されると、ひとつ以上の前記プロセッサに、前記プログラムのソースコードに追加されたコードセグメントの検出に応答して、前記コードセグメントを含む前記ソースコードの制御フロー特性を識別させる命令を含み、
   前記グラフモジュールは、ひとつ以上の前記プロセッサによって実行されると、ひとつ以上の前記プロセッサに、前記制御フロー特性にしたがって前記ソースコードの制御フローグラフを更新させる命令を含み、
   前記制御フローグラフは、前記ソースコードのブロックを表すノードと、前記ブロック間の遷移を表す前記ノード間の有向エッジとで構成される前記プログラムの実行パスを表し、
   前記グラフモジュールは、前記ソースコードの調整を容易にすることによって前記プログラムの機能を向上するために、前記制御フローグラフを提供する命令をさらに含み、
   前記グラフモジュールは、前記制御フローグラフを提供する命令として、前記プログラムがセキュリティの脆弱性を回避することを保証することでプログラムの機能を向上するために、前記ソースコードが開発される際にリアルタイムで前記制御フローグラフを提供する命令を含む、制御フローシステム。
3. 前記分析モジュールは、前記コードセグメントを検出する命令として、前記コードセグメントを構成するステートメントについて、コンピューティングデバイス内の統合開発環境（ＩＤＥ）への電子入力ストリームを監視することを含み、前記コードセグメントは前記ソースコードの一部を形成する、請求項２に記載の制御フローシステム。
4. プログラムの機能を向上するための制御フローシステムであって、
   ひとつ以上のプロセッサ（１１０）と、
   ひとつ以上の前記プロセッサに通信可能に結合されたメモリ（１２０）と、を備え、
   前記メモリは、分析モジュール（１３０）と、グラフモジュール（１４０）と、を格納しており、
   前記分析モジュールは、ひとつ以上の前記プロセッサによって実行されると、ひとつ以上の前記プロセッサに、前記プログラムのソースコードに追加されたコードセグメントの検出に応答して、前記コードセグメントを含む前記ソースコードの制御フロー特性を識別させる命令を含み、
   前記グラフモジュールは、ひとつ以上の前記プロセッサによって実行されると、ひとつ以上の前記プロセッサに、前記制御フロー特性にしたがって前記ソースコードの制御フローグラフを更新させる命令を含み、
   前記制御フローグラフは、前記ソースコードのブロックを表すノードと、前記ブロック間の遷移を表す前記ノード間の有向エッジとで構成される前記プログラムの実行パスを表し、
   前記グラフモジュールは、前記ソースコードの調整を容易にすることによって前記プログラムの機能を向上するために、前記制御フローグラフを提供する命令をさらに含み、
   前記分析モジュールは、前記ソースコードの前記制御フロー特性を識別する命令として、前記制御フロー特性を、セキュリティ脆弱性を示す条件を定義するグラフポリシーと比較することによって、前記ソースコードのどのステートメントに脆弱性が含まれているかを判断することを含み、
   前記グラフポリシーは、前記脆弱性と相関するデータフロー、データ引数、データ消失、および、プログラムフローに関連する前記プログラム内の条件を指定する、制御フローシステム。
5. 前記グラフモジュールは、前記制御フローグラフを更新する命令として、前記脆弱性の軽減を容易にするために、前記脆弱性を含む前記ステートメントにタグを付ける命令を含む、請求項４に記載の制御フローシステム。
6. プログラムの機能を向上するための制御フローシステムであって、
   ひとつ以上のプロセッサ（１１０）と、
   ひとつ以上の前記プロセッサに通信可能に結合されたメモリ（１２０）と、を備え、
   前記メモリは、分析モジュール（１３０）と、グラフモジュール（１４０）と、を格納しており、
   前記分析モジュールは、ひとつ以上の前記プロセッサによって実行されると、ひとつ以上の前記プロセッサに、前記プログラムのソースコードに追加されたコードセグメントの検出に応答して、前記コードセグメントを含む前記ソースコードの制御フロー特性を識別させる命令を含み、
   前記グラフモジュールは、ひとつ以上の前記プロセッサによって実行されると、ひとつ以上の前記プロセッサに、前記制御フロー特性にしたがって前記ソースコードの制御フローグラフを更新させる命令を含み、
   前記制御フローグラフは、前記ソースコードのブロックを表すノードと、前記ブロック間の遷移を表す前記ノード間の有向エッジとで構成される前記プログラムの実行パスを表し、
   前記グラフモジュールは、前記ソースコードの調整を容易にすることによって前記プログラムの機能を向上するために、前記制御フローグラフを提供する命令をさらに含み、
   ひとつ以上の前記プロセッサによって実行されると、ひとつ以上の前記プロセッサに、前記プログラムを計装する要求に応答して、前記プログラムの実行が前記制御フローグラフにしたがうことを保証することにより、前記プログラムのセキュリティを向上する前記プログラム内のランタイムチェックを実施するために、前記制御フローグラフにしたがって前記ソースコード内に計装を統合させる命令を含む計装モジュール（１５０）をさらに備える、制御フローシステム。
7. 前記計装モジュールは、前記ソースコード内に計装を統合する命令として、ｉ）前記制御フローグラフと前記ソースコードとの間の相関関係にしたがって計装される前記ソースコードのセグメントを識別する命令と、ｉｉ）前記ソースコードにしたがって定義された計装のテンプレートを修正することによって、前記識別されたセグメントにしたがって前記計装を自動的に追加する命令と、を含む請求項６に記載の制御フローシステム。
8. 前記要求は、統合開発環境（ＩＤＥ）を介して生成され、前記プログラムのコンパイル要求と並行して開始される電子要求である、請求項６又は７に記載の制御フローシステム。
9. 前記計装モジュールは、前記ソースコード内の関数を識別する電子入力の検出に応答して、前記関数に、前記関数が自動的に計装されることを指定する計装識別子をタグ付けする命令を含む、請求項６乃至８のいずれか１項に記載の制御フローシステム。
10. 前記分析モジュールは、前記制御フロー特性を識別させる命令として、前記ソースコード内のステートメントを走査し、少なくとも関数呼び出し、関数リターンアドレス、関数引数、関数戻り値、および前記ステートメント間の関係を前記制御フロー特性として識別するために、深さ優先探索を使用して前記ソースコードを分析する命令を含み、
    前記制御フローグラフは、前記プログラムの制御フローの転送手順を表す、請求項１乃至１０のいずれか１項に記載の制御フローシステム。
11. プログラムの機能を向上するための命令を格納する非一時的コンピュータ可読媒体であって、
    前記命令は、ひとつ以上のプロセッサ（１１０）によって実行されると、ひとつ以上の前記プロセッサに、
    前記プログラムのソースコードに追加されたコードセグメントの検出に応答して、前記コードセグメントを含む前記ソースコードの制御フロー特性を識別させ、
    前記制御フロー特性にしたがって前記ソースコードの制御フローグラフを更新させ、
    前記ソースコードの調整を容易にすることによって前記プログラムの機能を向上するために、前記制御フローグラフを提供させ、
    前記制御フローグラフは、前記ソースコードのブロックを表すノードと、前記ブロック間の遷移を表す前記ノード間の有向エッジとで構成される前記プログラムの実行パスを表し、
    前記制御フローグラフを提供する命令は、前記制御フローグラフの視覚的表現を生成し、前記コードセグメントが前記制御フローグラフを介して前記プログラムのリアルタイム表現を提供するように生成されるときに、統合開発環境（ＩＤＥ）内で前記視覚的表現を動的に表示する命令を含み、
    前記制御フローグラフを更新する命令は、前記コードセグメントに対応するように前記制御フローグラフの既存のノードおよびエッジを修正しながら、前記コードセグメントに対応する前記制御フロー特性を前記制御フローグラフに追加する命令を含む、非一時的コンピュータ可読媒体。
12. プログラムの機能を向上するための命令を格納する非一時的コンピュータ可読媒体であって、
    前記命令は、ひとつ以上のプロセッサ（１１０）によって実行されると、ひとつ以上の前記プロセッサに、
    前記プログラムのソースコードに追加されたコードセグメントの検出に応答して、前記コードセグメントを含む前記ソースコードの制御フロー特性を識別させ、
    前記制御フロー特性にしたがって前記ソースコードの制御フローグラフを更新させ、
    前記ソースコードの調整を容易にすることによって前記プログラムの機能を向上するために、前記制御フローグラフを提供させ、
    前記制御フローグラフは、前記ソースコードのブロックを表すノードと、前記ブロック間の遷移を表す前記ノード間の有向エッジとで構成される前記プログラムの実行パスを表し、
    前記命令は、前記プログラムを計装する要求に応答して、前記プログラムの実行が前記制御フローグラフにしたがうことを保証することにより、前記プログラムのセキュリティを向上する前記プログラム内のランタイムチェックを実施するために、前記制御フローグラフにしたがって前記ソースコード内に計装を統合する命令をさらに含む、非一時的コンピュータ可読媒体。
13. 前記制御フロー特性を識別させる命令は、前記ソースコード内のステートメントを走査し、少なくとも関数呼び出し、関数リターンアドレス、関数引数、関数戻り値、および、前記ステートメント間の関係を前記制御フロー特性として識別するために、深さ優先探索を使用して前記ソースコードを分析する命令を含み、
    前記制御フローグラフは、前記プログラムの制御フローの転送手順を表す、請求項１１又は１２に記載の非一時的コンピュータ可読媒体。
14. プログラムの機能を向上する方法であって、
    ひとつ以上のプロセッサ（１１０）が、前記プログラムのソースコードに追加されたコードセグメントの検出に応答して、前記コードセグメントを含む前記ソースコードの制御フロー特性を識別すること、
    ひとつ以上の前記プロセッサが、前記制御フロー特性にしたがって前記ソースコードの制御フローグラフを更新すること、
    ひとつ以上の前記プロセッサが、前記ソースコードの調整を容易にすることによって前記プログラムの機能を向上するために、前記制御フローグラフを提供すること、を含み、
    前記制御フローグラフは、前記ソースコードのブロックを表すノードと、前記ブロック間の遷移を表す前記ノード間の有向エッジとで構成される前記プログラムの実行パスを表し、
    前記制御フローグラフを提供することは、前記制御フローグラフの視覚的表現を生成し、前記コードセグメントが前記制御フローグラフを介して前記プログラムのリアルタイム表現を提供するように生成されるときに、統合開発環境（ＩＤＥ）内で前記視覚的表現を動的に表示することを含み、
    前記制御フローグラフを更新することは、前記コードセグメントに対応するように前記制御フローグラフの既存のノードおよびエッジを修正しながら、前記コードセグメントに対応する前記制御フロー特性を前記制御フローグラフに追加することを含む、方法。
15. プログラムの機能を向上する方法であって、
    ひとつ以上のプロセッサ（１１０）が、前記プログラムのソースコードに追加されたコードセグメントの検出に応答して、前記コードセグメントを含む前記ソースコードの制御フロー特性を識別すること、
    ひとつ以上の前記プロセッサが、前記制御フロー特性にしたがって前記ソースコードの制御フローグラフを更新すること、
    ひとつ以上の前記プロセッサが、前記ソースコードの調整を容易にすることによって前記プログラムの機能を向上するために、前記制御フローグラフを提供すること、を含み、
    前記制御フローグラフは、前記ソースコードのブロックを表すノードと、前記ブロック間の遷移を表す前記ノード間の有向エッジとで構成される前記プログラムの実行パスを表し、
    前記制御フローグラフを提供することは、前記プログラムがセキュリティの脆弱性を確実に回避することを保証することで前記プログラムの機能性を向上するために、前記ソースコードが開発される際にリアルタイムで前記制御フローグラフを提供することを含む、方法。
16. プログラムの機能を向上する方法であって、
    ひとつ以上のプロセッサ（１１０）が、前記プログラムのソースコードに追加されたコードセグメントの検出に応答して、前記コードセグメントを含む前記ソースコードの制御フロー特性を識別すること、
    ひとつ以上の前記プロセッサが、前記制御フロー特性にしたがって前記ソースコードの制御フローグラフを更新すること、
    ひとつ以上の前記プロセッサが、前記ソースコードの調整を容易にすることによって前記プログラムの機能を向上するために、前記制御フローグラフを提供すること、を含み、
    前記制御フローグラフは、前記ソースコードのブロックを表すノードと、前記ブロック間の遷移を表す前記ノード間の有向エッジとで構成される前記プログラムの実行パスを表し、
    前記ソースコードの前記制御フロー特性を識別することは、前記制御フロー特性を、セキュリティ脆弱性を示す条件を定義するグラフポリシーと比較することによって、前記ソースコードのどのステートメントに脆弱性が含まれているかを判断することを含み、
    前記グラフポリシーは、前記脆弱性と相関するデータフロー、データ引数、データ消失、および、プログラムフローに関連する前記プログラム内の条件を指定する、方法。
17. プログラムの機能を向上する方法であって、
    ひとつ以上のプロセッサ（１１０）が、前記プログラムのソースコードに追加されたコードセグメントの検出に応答して、前記コードセグメントを含む前記ソースコードの制御フロー特性を識別すること、
    ひとつ以上の前記プロセッサが、前記制御フロー特性にしたがって前記ソースコードの制御フローグラフを更新すること、
    ひとつ以上の前記プロセッサが、前記ソースコードの調整を容易にすることによって前記プログラムの機能を向上するために、前記制御フローグラフを提供すること、を含み、
    前記制御フローグラフは、前記ソースコードのブロックを表すノードと、前記ブロック間の遷移を表す前記ノード間の有向エッジとで構成される前記プログラムの実行パスを表し、
    前記プログラムを計装する要求に応答して、前記プログラムの実行が前記制御フローグラフにしたがうことを保証することにより、前記プログラムのセキュリティを向上する前記プログラム内のランタイムチェックを実施するために、前記制御フローグラフにしたがって前記ソースコード内に計装を統合することをさらに含む、方法。
18. 前記ソースコード内に計装を統合することは、ｉ）前記制御フローグラフと前記ソースコードとの間の相関関係にしたがって計装される前記ソースコードのセグメントを識別することと、ｉｉ）前記ソースコードにしたがって定義された計装のテンプレートを修正することによって、前記識別されたセグメントにしたがって前記計装を自動的に追加すること、を含む、請求項１７に記載の方法。
19. 前記ソースコード内の関数を識別する電子入力の検出に応答して、前記関数に、前記関数が自動的に計装されることを指定する計装識別子をタグ付けすることをさらに含む、請求項１７又は１８に記載の方法。
20. 前記制御フロー特性を識別することは、前記ソースコード内のステートメントを走査し、少なくとも関数呼び出し、関数リターンアドレス、関数引数、関数戻り値、および、前記ステートメント間の関係を前記制御フロー特性として識別するために、深さ優先探索を使用して前記ソースコードを分析することを含み、
    前記制御フローグラフは、前記プログラムの制御フローの転送手順を表す、請求項１４乃至１９のいずれか１項に記載の方法。
21. １つ以上のプロセッサ（１１０）に、
    ソースコードに追加されたコードセグメントの検出に応答して、前記コードセグメントを含む前記ソースコードの制御フロー特性を識別する機能と、
    前記制御フロー特性にしたがって前記ソースコードの制御フローグラフを更新する機能と、
    前記ソースコードの調整を容易にするために、前記制御フローグラフを提供する機能と、を実現させるプログラムであって、
    前記制御フローグラフは、前記ソースコードのブロックを表すノードと、前記ブロック間の遷移を表す前記ノード間の有向エッジとで構成される前記プログラムの実行パスを表し、
    前記制御フローグラフを提供する機能は、前記制御フローグラフの視覚的表現を生成し、前記コードセグメントが前記制御フローグラフを介して前記プログラムのリアルタイム表現を提供するように生成されるときに、統合開発環境（ＩＤＥ）内で前記視覚的表現を動的に表示する機能を含み、
    前記制御フローグラフを更新する機能は、前記コードセグメントに対応するように前記制御フローグラフの既存のノードおよびエッジを修正しながら、前記コードセグメントに対応する前記制御フロー特性を前記制御フローグラフに追加する機能を含む、プログラム。
22. ひとつ以上のプロセッサ（１１０）に、
    ソースコードに追加されたコードセグメントの検出に応答して、前記コードセグメントを含む前記ソースコードの制御フロー特性を識別する機能と、
    前記制御フロー特性にしたがって前記ソースコードの制御フローグラフを更新する機能と、
    前記ソースコードの調整を容易にするために、前記制御フローグラフを提供する機能と、を実現させるプログラムであって、
    前記制御フローグラフは、前記ソースコードのブロックを表すノードと、前記ブロック間の遷移を表す前記ノード間の有向エッジとで構成される前記プログラムの実行パスを表し、
    前記制御フローグラフを提供する機能は、前記プログラムがセキュリティの脆弱性を回避することを保証することで前記プログラムの機能を向上するために、前記ソースコードが開発される際にリアルタイムで前記制御フローグラフを提供する機能を含む、プログラム。
23. １つ以上のプロセッサ（１１０）に、
    ソースコードに追加されたコードセグメントの検出に応答して、前記コードセグメントを含む前記ソースコードの制御フロー特性を識別する機能と、
    前記制御フロー特性にしたがって前記ソースコードの制御フローグラフを更新する機能と、
    前記ソースコードの調整を容易にするために、前記制御フローグラフを提供する機能と、を実現させるプログラムであって、
    前記制御フローグラフは、前記ソースコードのブロックを表すノードと、前記ブロック間の遷移を表す前記ノード間の有向エッジとで構成される前記プログラムの実行パスを表し、
    前記ソースコードの前記制御フロー特性を識別する機能は、前記制御フロー特性を、セキュリティ脆弱性を示す条件を定義するグラフポリシーと比較することによって、前記ソースコードのどのステートメントに脆弱性が含まれているかを判断する機能を含み、
    前記グラフポリシーは、前記脆弱性と相関するデータフロー、データ引数、データ消失、および、プログラムフローに関連する前記プログラム内の条件を指定する、プログラム。
24. １つ以上のプロセッサ（１１０）に、
    ソースコードに追加されたコードセグメントの検出に応答して、前記コードセグメントを含む前記ソースコードの制御フロー特性を識別する機能と、
    前記制御フロー特性にしたがって前記ソースコードの制御フローグラフを更新する機能と、
    前記ソースコードの調整を容易にするために、前記制御フローグラフを提供する機能と、を実現させるプログラムであって、
    前記制御フローグラフは、前記ソースコードのブロックを表すノードと、前記ブロック間の遷移を表す前記ノード間の有向エッジとで構成される前記プログラムの実行パスを表し、
    前記プログラムを計装する要求に応答して、前記プログラムの実行が前記制御フローグラフにしたがうことを保証することにより、前記プログラムのセキュリティを向上する前記プログラム内のランタイムチェックを実施するために、前記制御フローグラフにしたがって前記ソースコード内に計装を統合させる機能さらに備える、プログラム。

Images