【論文要約】ControlFlag: A Self-Supervised Idiosyncratic Pattern Detection System for Software Control Structures
Abstract of this paper in 2 lines:
The paper presents ControlFlag, a self-supervised machine programming system that aims to detect idiosyncratic pattern violations in software control structures and suggests possible corrections.
ControlFlag has already found and fixed an anomaly in CURL, demonstrating its potential to improve software quality.[1]
Contributions of this paper:
The paper presents ControlFlag, a self-supervised system that automatically identifies potential errors in control structures of the C family of languages, specifically focusing on if statements in CC programs.
ControlFlag is designed to be programming language agnostic, making it applicable to different programming languages.
The system takes a statistical approach to identify programming pattern violations by recasting them as anomalies, providing a novel method for detecting idiosyncratic pattern violations.
ControlFlag has been successfully used to detect anomalies in the CURL open-source project, leading to the correction of programming errors by the CURL development team. [1]
Related papers:
1. Integrating user knowledge into design pattern detection
Mohammad H. Alshira'h • 2015
2 citations
2. AN OVERVIEW OF PATTERN-DIRECTED INFERENCE SYSTEMS
D. A. Waterman+1 others • 1978
132 citations
3. Automatic software code detection method
Cheng Yongxin+2 others • 2018
1 citations
4. Guest Editors' Introduction: Software Patterns
Michael Kircher+1 others • 2007, IEEE Software
7 citations
5. Proceedings of the IEEE/ACM international conference on Automated software engineering
Charles Pecheur+2 others • 2010, Automated Software Engineering
19 citations
Practical implications of this paper:
ControlFlag can automatically detect potential programming errors in software control structures, improving the efficiency of software debugging.[1]
By suggesting possible corrections for detected anomalies, ControlFlag can assist developers in fixing errors and improving software quality.
The system's ability to identify anomalies, even if they are not bugs, can contribute to enhancing software robustness.
ControlFlag's self-supervised approach allows it to learn acceptable idiosyncratic patterns from a large dataset, making it adaptable to different programming languages.[2]
The paper highlights the importance of considering computational resource requirements and potential environmental impacts when developing machine-learning-based systems like ControlFlag.[3]
The paper also discusses the potential for further refinement of ControlFlag, such as breaking down nested expressions to reduce false positives and preserving relationships between subtrees in expression trees.[4]
Introduction of this paper:
Software debugging consumes a significant amount of developers' time, and machine programming (MP) has made progress in automating debugging systems.
MP aims to improve programmer productivity and software quality through automation, utilizing advances in machine learning, formal methods, and data availability.
ControlFlag is a self-supervised MP system designed to detect idiosyncratic pattern violations in software control structures and suggest possible corrections.
The paper highlights the importance of reducing debugging time and improving programmer productivity, and ControlFlag's potential to identify potential programming errors in production-quality software.
ControlFlag has already found and fixed an anomaly in the CURL software, demonstrating its effectiveness in improving software quality.
The paper also discusses future extensions of ControlFlag and its potential to be language-agnostic and learn idiosyncratic signatures of control structures in any programming language.[1][2]
Literature survey of this paper:
Mining code idioms and syntactic fragments from source code repositories has been an active area of research, enabling the extraction of useful information for assisting programmers in writing code.
Techniques like frequent tree mining and probabilistic grammars have been applied to mine idioms from source code repositories.
Code idioms capture semantic concepts that can simplify program synthesis and semantic parsing. They have been used to train program synthesizers and semantic parsers.
Frequent code patterns have been utilized to learn typical API usages and detect API misuses, which can be considered conceptually similar to the problem approached by ControlFlag.
Automated bug detection, program repair, and software defect prediction are growing areas of research in machine programming. ControlFlag's automatic correction suggestions align with these areas.
Approaches like deep learning models and statistical/machine learning models have been used for bug detection, program repair, and software defect prediction.
Techniques like SynFix and DrRepair have been developed to correct syntax errors in programs using machine learning and diagnostic feedback from compilers.
ControlFlag stands out as a self-supervised learning system that identifies typographical anomalies based on idiosyncratic patterns, potentially notifying programmers of anomalies before test cases or program specifications are checked.[1]
Methods used in this paper:
ControlFlag is a self-supervised MP system that detects idiosyncratic pattern violations in software control structures and suggests possible corrections. It utilizes pattern mining and scanning phases to analyze source code repositories for anomalies.
The pattern mining phase involves source repository selection, code parsing, and decision tree construction. It learns common and uncommon idiosyncratic coding patterns from user-specified GitHub repositories.
The scanning phase analyzes a given source code repository against the learned patterns to identify possible anomalies. ControlFlag flags these anomalies and provides alternative coding recommendations.[1]
The paper also mentions the evaluation and analysis of ControlFlag's efficacy in identifying potential programming errors in production-quality software. It highlights the detection of an anomaly in the CURL project that was acknowledged and fixed by its developers.[2]
Additionally, the paper discusses future extensions of ControlFlag and the potential to apply data preprocessing techniques, such as data cleansing, to define and filter out low-quality repositories.[3]
Data used in this paper:
The paper utilizes source code repositories from GitHub for data analysis and pattern mining. The selection of repositories is based on a minimum number of stars as a measure of quality .
The data includes software control structures from production-quality software, such as the CURL project, where ControlFlag detected an anomaly that was acknowledged and fixed by the developers [1] [2].
The paper mentions the mining of patterns from GitHub repositories to learn idiosyncratic coding patterns [3].
The data also includes examples of anomalies and errors found in the scanned repositories, which were used to evaluate ControlFlag's efficacy in identifying potential programming errors [2].
The paper discusses the need for data preprocessing techniques, such as data cleansing, to define and filter out low-quality repositories, indicating the potential use of such techniques in the research [2] [4].
Results of the paper:
ControlFlag, a self-supervised MP system, was developed to detect idiosyncratic pattern violations in software control structures and suggest possible corrections [1].
The system utilized pattern mining and scanning phases to analyze source code repositories for anomalies .
ControlFlag successfully identified an anomaly in the CURL project, which was acknowledged and fixed by its developers, providing concrete evidence of its effectiveness in improving software quality [1].
The paper discusses the results of the scanning phase, showing the number of patterns found and missing at different abstraction levels, as well as the number of flagged anomalies based on different anomaly thresholds [2].
Anomalies flagged in the scans were reported, including those in OpenSSL, which had the highest number of anomalies, and CURL, which led to software changes [2].
The paper also presents tables showing frequently occurring patterns at the L1 abstraction level and patterns with low occurrences, providing insights into coding practices and the need for diverse source repositories [3].
Note: The provided sources do not explicitly mention overall quantitative results or statistical analysis of the system's performance.
ControlFlag Design:
2.1 Pattern Mining
Source repository selection.
実験では、GitHubリポジトリからパターンを採掘しましたが、特定の最小のスター数を持つリポジトリから選びました。つまり、GitHubリポジトリのスター数をその品質の尺度として使用しました。GitHubスター以外に、これらのリポジトリ内のプログラムの品質を測定する簡単で数量的な尺度は存在しなかったため、この選択はデータに対する半信頼を提供していると考えています。ただし、品質は主観的な用語であるため、これは未解決の問題であると考えています。
Parsing control structures.
ソースリポジトリが選択された後、ControlFlagは、興味のある高レベルプログラミング言語でのプログラムのリストを生成します。このリストの各プログラムは、それから解析されます。その結果の解析木は、現在は抽象構文木（AST）の形式であり、不要な詳細を剪定するために、より高レベルな抽象化されたツリーに変換されます。ControlFlagはこれらのプログラムを解析する間、解析エラーを含むプログラムを破棄しません。ControlFlagの目的において、制御構造に解析エラーがないだけで十分です。コードの他の場所に解析エラーがあっても、ControlFlagの機能に影響を与えない可能性があります。私たちは、オープンソースで見つかるC/C++プログラムの大多数がコンパイルできないことを発見したため、ControlFlagのこの特性は重要だと考えています。さらに、このアプローチは、ControlFlagが将来的にライブプログラミング環境または統合開発環境（IDE）で使用できるようにするでしょう。
Levels of abstractions.
TreeSitterのAPI [48] を使用して、制御構造を解析し、そのAST表現を最も低い木の表現として使用しました（L1抽象化レベルと呼ばれます）。ただし、実験中に、AST表現は制御構造内の式の正確な構造を捉えることがわかりました。たとえば、C/C++言語の式（a.b.c & (1 << e)) の場合、ASTは次のようになります： （binary_expr（"&"） （field_expr （field_expr（（identifier）（field_identifier）） （field_identifier）） （parenthesized_expr （binary_expr（"<<"）（number）（identifier））） このような正確な構造形式を捉えることは、後のスキャンフェーズでターゲットパターンと一致する確率を減少させることが観察されました。ASTの上に開発された高レベルの抽象化レベル（L23抽象化レベルと呼ばれる）は、ASTを有限かつ小さな高さに保つことで構造形式の精度を低下させます。そのため、刈り込まれた部分木を表すために新しいツリーノードタイプ（non_terminal）を導入します。前述のASTのための高レベルツリーは次のようになります： （binary_expr（"&"）（non_terminal_expr）（non_terminal_expr）） 上記の高レベルツリーは、&の子供を両方削除し、それらをnon_terminalとしてマークします。これは偽陰性の数を増加させる可能性がありますが、ControlFlagがスキャンフェーズ中に&内の特異的な違反をチェックすることを可能にし、辞書から完全に欠落と宣言する代わりにします。
Decision tree construction.
解析中、L1およびL2の抽象化レベルのパターンは、ツリーの走査を使用してテキスト形式で出力できます。実際、我々は採掘したパターンを内部的に、採掘したパターンのツリーのテキスト文字列上にプレフィックスツリー（またはトライ）を構築して表現しています。プレフィックスツリー内の各パスは、有効なパターンに対応するターミナルノードで終わるもので、そのパターンの出現回数も格納されます。異なる抽象化レベルのテキスト文字列に対して異なるプレフィックスツリーを構築します。これにより、特異なパターンを異なる抽象化レベルに変換し、それらを対応するプレフィックスツリーと照合できます。
2.2 Scanning for Unusual Patterns
ユーザーが異常なパターンをスキャンする対象のリポジトリを指定すると、ControlFlagはまず指定された制御構造内で発生する特異なパターンのリストを取得します。リスト内の各パターンに対して、L1抽象化レベルで解析ツリーを構築し、L1レベルのプレフィックスツリーと照合します。パターンがツリー内に存在する場合、L2レベルのプレフィックスツリーとの照合をスキップします。パターンが見当たらない場合、ControlFlagはL2レベルのプレフィックスツリーと照合します。ControlFlagは、パターンが見つかったか見つからなかったかに関係なく、自動修正フェーズをトリガーします。前者の場合、パターンが見つかったとしても、それは稀である可能性があるためです。後者の場合、パターンは存在しないため、稀であることがわかっています。ControlFlagの自動修正フェーズは、ヒューリスティックに計算された閾値に基づいて、パターンが異常である場合にそのパターンをフラグ付けし、ツリーの類似性基準に基づいて可能な修正案を提案します。
1. はじめに
ソフトウェア開発の時間の50%以上がデバッグに費やされるという研究結果もあります。したがって、デバッグ時間のわずかな削減でも大きなソフトウェア開発コストの節約とプログラマーの生産性向上が期待できます。機械プログラミング（MP）はソフトウェア（およびハードウェア）の開発を自動化することを目指す分野であり、ソフトウェアのデバッグ時間を削減するための手法として示されています。最近、機械学習、形式手法、データの利用可能性、計算効率などの進歩により、MPに関する研究が活発化しています。一般的に、MPシステムはプログラマーの生産性を向上させることや、性能やセキュリティなどのソフトウェアのさまざまな品質特性を改善することを目指しています。最近のMPツールの例としては、自動コード生成器、アセンブリからIRへの変換、コード推奨や類似システム、自動バグ検出システム、静的・動的学習最適化、パフォーマンス回帰テスト生成、統合開発環境（IDE）向けのプログラム構造の自動補完などがあります。
2. プログラミングパターンの違反の自動識別
プログラミングパターンの違反は、基本的なコード構造（プログラミングパターン）の典型的な使用方法から逸脱した、構文的には有効なコードスニペットとして考えることができます。例えば、C言語のforループの典型的な使用方法の可能な違反を考えてみましょう。
cCopy code
for (int i = 0; i < N; i++) { // 何らかのプログラムコード i++; }
この例は、forループの典型的な使用方法の可能な違反であり、1つのループ内でループカウンターを2回増やしています（1行目と3行目）。ループカウンターは通常、1回のパスごとに1回増やされますが、ここでは2回増やされています。同様の違反は他の言語でも見つかります。Verilogの次の違反例を考えてみましょう。
verilogCopy code
reg [1:0] state; always @(state) case (state) 00: // State 0の処理 01: // State 1の処理 10: // State 2の処理 11: // State 3の処理 endcase
この例では、case 10と11（7行目と8行目）は到達不可能です。なぜなら、stateは2ビットのバイナリ変数であり、Verilogのデフォルトの数値基数は10進数だからです。ただし、これらの例はバグであるかどうかは一概には言えません。最初の例ではプログラマーが意図的にループカウンターを2回増やすことを意図していたかもしれず、2番目の例ではバイナリ変数と10進数を組み合わせることを意図していたかもしれません。その点で、プログラミング違反を識別する問題は確率的な性質を持っていると考えられます。
3. ControlFlagの概要
この論文では、C/C++のif文というCファミリーの言語の中核的な制御構造の1つにおける潜在的なエラーを自動的に識別するMPアプローチを提案します。潜在的なエラーを特定するだけでなく、ControlFlagは見つけた潜在的なエラーに対する修正案も提示します。他の高水準言語（CやC++など）の制御構造の例には、選択文（if、else if、else、switch）、繰り返し文（forループ、whileループ、do whileループ）、ジャンプ文（goto、throw文）などがあります。
4. ControlFlagの利用例
例えば、次のC++コードを考えてみましょう。
cppCopy code
if (x = 7) y = x;
上記のコードでは、プログラマーの意図がxが7と等しい場合にのみxの値をyに代入することである可能性が高いです。しかし、if条件式で2番目の=演算子が省略されたため、意図された等号チェックが代入操作に変わってしまいます。その結果、xには値7が代入されます。xの値がゼロでないため、if条件は常にtrueを返します。結果としてtrueの条件は常に満たされ、yにはxに格納されている値（たまたま常に7）が代入されます。xが7と等しいかどうかをチェックするコードは次のようになります。
cppCopy code
if (x == 7) y = x;
先の例と同様に、元のコードがプログラマーの意図を適切に捉えていない可能性があります。したがって、ControlFlagの推奨も確率的なものです。実際、ControlFlagはさまざまなコードリポジトリの分析から、特定の制御構造がコードリポジトリで見つかる特徴的なパターンの再現性に基づいて、特定の制御構造が潜在的なエラーであるかどうかを判断します。
5. 課題
こうしたタイプのタイポグラフィのコーディングエラーを識別することは少なくとも2つの理由で困難です。まず、条件文内での変数の代入はC/C++の正当な構文であるため、この種の意図エラーはコンパイラによって警告されない場合があります。第二に、コンパイラや静的解析ツールはデータフロー解析を使用してそのようなエラーを特定できますが、データフロー解析には自身の制限があります（ローカルスコープとグローバルスコープの解析など）。ただし、GCCやLLVMなどのコンパイラは既にルールベースのアプローチを使用して、さまざまな潜在的に誤ったケースでプログラマーに警告を出しています。
6. 結論
この論文では、プログラミングパターンの違反を異常として捉える統計的アプローチを取り、ControlFlagシステムを異常コード検出器として設計しました。C/C++言語のif文内での特定のパターン（代入など）の使用は比較的稀であると仮定しています。この仮説を検証するため、オープンソースのGitHubリポジトリ内のC/C++プログラムの制御構造に見られる特徴的なパターンを調査しました。これらのパターンは辞書形式に整理され、ユーザーが入力したパターンをチェックし、異常があれば自動的な修正案を提案します。このアプローチの利点は、ラベル付きトレーニングデータが不要であることです。ControlFlagは、半信頼できるGitHubリポジトリから採掘されたパターンをセルフスーパーバイズされた形式で使用し、ラベル付きのコードの異常を必要としません。また、ControlFlagは先に述べた例に加えて、他の多くの特徴的なパターンを学習することができます。
7. 技術的貢献
本論文の技術的な貢献は以下の通りです：
• 当社の知る限り、自己監督型の特異的なプログラミングパターン検出システムであるControlFlagを提示しています。
• C/C++のみでControlFlagを実証していますが、他のプログラミング言語にも適用可能な言語非依存の設計です。
• ControlFlagがC/C++プログラムのif文内の特異的なパターン違反を特定する能力の初期結果を提示しています。
• CURLオープンソースプロジェクトでのControlFlagの具体的な事例を提供し、開発チームが気付かなかったコードの異常を特定し、修正するための情報を提供しました。
1. はじめに
いくつかの研究によると、ソフトウェア開発の時間の50%以上がデバッグに費やされています。したがって、デバッグ時間のわずかな削減でも、大規模なソフトウェア開発のコスト削減が可能になり、同時にプログラマーの生産性が向上します。機械プログラミング（MP）は、ソフトウェア（およびハードウェア）開発の自動化に関心があります。MPは、ソフトウェアのデバッグ時間を短縮するための1つの手法として示されています。最近、機械学習、形式手法、データの利用可能性、コンピューティングの効率などの進歩により、MPに関する研究が活発化しています。一般的に、MPシステムは、プログラマーの生産性やソフトウェアのさまざまな品質特性（パフォーマンスやセキュリティなど）を向上させることを目指しています。最近のMPツールの例には、自動コード生成ツール、アセンブリからIRへの変換ツール、コード推奨システム、および類似性システム、自動バグ検出システム、静的および動的な学習ベースの最適化、パフォーマンス回帰テスト生成、統合開発環境（IDE）のプログラム構成要素の自動補完などがあります。
この論文では、プログラミングパターンの違反を自動的に特定するMPアプローチを提案します。プログラミングパターンの違反は、基礎となるコード構造の一般的な使用法から逸脱した構文的に有効なコードスニペットと考えることができます（つまり、プログラミングパターン）。Cプログラミング言語のforループの一般的な使用法の可能性のある違反の例を考えてみましょう：
- for (int i = 0; i < N; i++) {
- // いくつかのプログラムコード
- i++;
- }
この例は、typical usage（典型的な使用方法）のforループの違反の可能性があります。なぜなら、1つのループパスでループカウンタを2回インクリメントしているからです（1行目と3行目）。ループカウンタの典型的な使用法は、1回のパスごとに1回インクリメントすることです。違反は他の言語でも見つかります。次に、Verilog [45]での違反の例を考えてみてください。
1. reg [1:0] state;
2.
3. always @(state)
4. case (state)
5. 00: // do State 0 stuff
6. 01: // do State 1 stuff
7. 10: // do State 2 stuff
8. 11: // do State 3 stuff
9. endcase
この例では、case 10と11（7行目と8行目）は到達不能です。stateは2ビットのバイナリ変数ですが、Verilogのデフォルトの数値基数は10進数です。ただし、これらの例がバグであるかどうかは必ずしもそうとは限りません。最初の例では、プログラマーがループカウンタを2回インクリメントする意図があったり、2番目の例ではバイナリ変数を10進数の数値と組み合わせるつもりであったりする可能性があります。その点で、我々はプログラミングの独自性を特定する問題は確率的な性質を持つと主張します。この論文では、ControlFlagという、C/C++のif文に潜在的なエラーを自動的に特定する自己教師付きシステムを提案します。Cファミリーの言語のコアコントロール構造の1つです。これらの潜在的なエラーを特定するだけでなく、ControlFlagは見つけた潜在的なエラーの修正案を提案します。CやC++などの高水準言語の制御構造の他の例には、以下のものがあります：
(i) 選択文：if、else if、else、switch、
(ii) 繰り返し文：forループ、whileループ、do whileループ、
(iii) ジャンプ文：goto、throw文。
次に、次のC++コードを考えてみてください：
if (x = 7) y = x;
上記のコードでは、プログラマの意図が、xが7と等しい場合にのみxの値をyに割り当てることである可能性が高いです。残念ながら、if条件式で2番目の = 演算子が省略されているため、意図した等号のチェックが代入操作に変換されます。これにより、xに値7が割り当てられます。xの値がゼロでないため、if条件は常にtrueを返します。その結果、trueの条件が常にyにxに格納されている値（偶然にもifの代入のため常に7）が割り当てられます。xが7と等しいかどうかをチェックするコードは次の通りです：
if (x == 7) y = x;
前述の例と同様に、元のコードがプログラマの意図を適切に捉えていなかったと推測するしかありません。その結果、そしてより一般的には、ControlFlagによるどんな潜在的な推奨も確率的です。実際、ControlFlagが特定の制御構造が潜在的なエラーであるかどうかを判断するのは、解析されたコードリポジトリで見つかった独自のパターンの共通性の再現に基づいています。
このようなタイポグラフィのコーディングエラーを特定することは、少なくとも2つの理由で困難です。第一に、条件文内での変数の代入は、C/C++における合法的な構文です（例えば、if (x = 7)）。そのため、このタイプの意図的なエラーは、コードの構文が実際には合法であるため、コンパイラによってフラグが立てられない可能性があります。第二に、コンパイラや静的解析ツールはデータフロー解析を使用してそのようなエラーを特定できますが、データフロー解析には独自の制限があります（例：ローカルスコープ対グローバルスコープの解析など）。それにもかかわらず、GCCやLLVMなどのコンパイラはすでに、様々な潜在的なエラーケースでプログラマに警告するためのルールベースのアプローチを使用しています。例えば、GCC-10.2.0の -Wall オプションは、上記のコードを次のようにプログラマに警告します：
test.cpp:3:9: warning: suggest parentheses around
assignment used as truth value [-Wparentheses]
if (x = 7) y = x;
^
ただし、ルールベースのアプローチには少なくとも2つの主要な制限があります。第一に、それらは労力がかかる可能性があります。新しい種類の潜在的なエラーをフラグ付けするために、通常、新しいルールを追加する必要があります、特にプログラミング言語の構造の進化によって作成されたものなど。第二に、多くの高度な警告システムは、コンパイル可能なプログラムが必要となる場合があります。たとえば、コンパイラベースの警告 - 上記のGCCの警告など - は、そのような問題をフラグ付けするためにコンパイル可能なコードが必要です。さらに、こうしたコンパイラベースのアプローチが、プログラマがコードを書いている途中に問題を動的に特定しようとする推奨システムが実行されているライブ開発環境で実用的である可能性は低いかもしれません（そのようなコードはしばしば不完全で、コンパイルできません）。
この論文では、プログラミングパターンの違反を統計的なアプローチで特定し、それらを異常として再構築する方法を取ります。同様に、私たちのControlFlagシステムは、異常なコードを検出するために設計されています。私たちは、C/C++言語のif文内で特定のパターン（例えば代入）を使用することが比較的まれであるという仮説を立てています。この仮説を検証するために、オープンソースのGitHubリポジトリで見つかったC/C++プログラムの制御構造から独特なパターンを採掘します。採掘されたパターンは辞書を形成し、ユーザーが入力したパターンをチェックし、異常がある場合は自動的な修正を提案するために使用されます。このようなアプローチの利点の1つは、ラベル付けされたトレーニングデータが不要であることです。ControlFlagは、半信頼であるGitHubリポジトリから採掘されたパターンを自己教師付きの方法で使用し、ラベル付けされたコードの異常の必要性を排除します。
以前に議論された例に加えて、ControlFlagは多くの他の種類の独特なパターンを学習することができます。1つのパターンカテゴリは、プログラミング言語の型付け規則とそれらが適切な数学演算子にどのようにバインディングされるかの領域にあります。これらの規則は、タイプの使用（および誤用）に関連する異常を検出するために使用できます。例えば、我々はControlFlagを使用して、CURLオープンソースプロジェクトで整数とブール型の不一致を検出しました。これにより、CURL開発チームがコードの一部を再設計して問題を修正しました（詳細は後日発表予定です）。もう1つのパターンカテゴリは、メモリ管理プログラミングパターンの周りです。ControlFlagは、NULLポインタがデリファレンスされる前に評価されることが適切であることを学習し、欠落しているNULLポインタのチェックをフラグ付けします。
この論文は、以下の技術的貢献を提供します：
- ・ ControlFlagを提供します。これは、私たちの知る限り、自己教師付きの独特なプログラミングパターン検出システムとして初めてのものです。
- ・ControlFlagの能力を示す初期の結果を提供します。これらの結果は、約6,000のGitHubリポジトリと10億行を超えるコードにわたります。
- ・ControlFlagの能力についての具体的な例を提供します。これは、クライアントURL（CURL）オープンソースプロジェクトで、開発チームが気付かなかったコードの異常を特定できました。CURLチームはControlFlagの調査結果に同意し、問題を解決するための修正を行いました。
2. ControlFlag Design
図1はControlFlagの概要を示しており、主に2つの主要なフェーズから成り立っています：（i）パターンの採掘
（ii）スキャン
パターンの採掘フェーズでは、ユーザーが指定したGitHubリポジトリで見つかった一般的（そして一般的でない）特異的なコーディングパターンを学習します。このフェーズが完了すると、受け入れ可能な特異的なパターンと受け入れられない特異的なパターンを含む優先辞書が生成されます。
スキャンフェーズでは、学習されたパターンに対して与えられたソースコードリポジトリを解析し、異常が発生する可能性のある箇所を検出します。異常なパターンが特定されると、ControlFlagはそれらにフラグを立て、代替のコーディング推奨を提供します。
2.1 Pattern Mining
パターン採掘フェーズは、次のようなサブフェーズにさらに分割されます：
（i）ソースリポジトリの選択
（ii）コード解析
（iii）決定木の構築
ソースリポジトリの選択：
実験では、特定の最小スター数を満たすGitHubリポジトリからパターンを抽出しました。言い換えれば、GitHubリポジトリのスター数をその品質の尺度としました。GitHubスター以外でそれらのリポジトリ内のプログラムの品質を容易かつ数量化できる方法がないため、この選択がデータに対して半信頼性を与えると考えています。ただし、品質は主観的な用語であるため、これは未解決の問題であると考えています。
制御構造の解析：
ソースリポジトリが選択されると、ControlFlagは興味のある高水準プログラミング言語のプログラムのリストを生成します。このリストの各プログラムは解析されます。その結果得られるパース木（現在は抽象構文木（AST）の形式）は、不要な詳細を削除するために、より高いレベルの抽象木に変換されます。ControlFlagはこれらのプログラムを解析する際に、パースエラーを含むプログラムを破棄しません。ControlFlagの目的には、制御構造にパースエラーがないことが必要です。コードの他の部分でのパースエラーは、ControlFlagの機能に影響を与えることはないかもしれません。オープンソースで見つかるC/C++プログラムの大部分がコンパイルできないことがわかっているため、ControlFlagのこの特性は重要だと考えています。さらに、このようなアプローチにより、ControlFlagをライブなプログラミング環境や統合開発環境（IDE）で使用できるようになるでしょう。
抽象化のレベル：
制御構造を解析するためにTreeSitter API [48] を使用し、そのAST表現2を最も低い木の表現（L1抽象化レベルと呼ばれる）として使用しました。ただし、実験中に、AST表現は制御構造内の式の正確な構造を捉えることがわかりました。例えば、C/C++言語の式であるa.b.c & (1 « e))の場合、ASTは次のようになります：
（binary_expr ("&")
(field_expr
(field_expr ((identifier)(field_identifier)))
(field_identifier))
(parenthesized_expr
(binary_expr ("<<")(number)(identifier))))
私たちは、このような正確な構造の捉えは後のスキャンフェーズで目標パターンに一致する可能性を低下させることに気づきました。ASTの上に開発されたより高い抽象化レベル（L23抽象化レベルと呼ばれる）は、ASTを有限かつ小さな高さに保つことで構造の精度を低下させます。この目的のために、この抽象化レベルは剪定されたサブツリーを表すために新しいツリーノードタイプ（non_terminalと呼ばれる）を導入します。上記のASTの場合、このような高レベルのツリーは次のようになります：
（binary_expr ("&") (non_terminal_expr)(non_terminal_expr))
上記の高レベルのツリーは&の子供を両方削除し、non_terminalとしてマークします。これにより、偽陰性(False Negative)の数が直感的に増加しますが、スキャンフェーズでControlFlagが&内の特異的な違反をチェックすることができ、辞書から全体のパターンを欠落と宣言することはありません。
決定木の構築：
パース中に、L1およびL2の抽象化レベルのパターンは、ツリーの走査を使用してテキスト形式でダンプできます。実際には、採掘されたパターンを、採掘されたパターンの木のテキスト文字列上にプレフィックスツリー（またはtrie [10]）を構築することで内部的に表現します。有効なパターンに対応する終端ノードで終わるプレフィックスツリー内のすべてのパスは、そのパターンの出現回数も格納します。さまざまな抽象化レベルのテキスト文字列に対して異なるプレフィックスツリーを構築します。これにより、特異的なパターンを異なる抽象化レベルに変換し、それらをそれぞれのプレフィックスツリーと照合できます。
2.2 Scanning for Unusual Patterns
ユーザーが異常なパターンをスキャンするために対象リポジトリを指定すると、ControlFlagはまず、指定された制御構造内に発生する特異なパターンのリストを取得します。リスト内のすべてのパターンについて、L1抽象化レベルでパース木を構築し、それをL1レベルのプレフィックスツリーと照合します。パターンがツリー内に存在する場合、L2レベルのプレフィックスツリーとのチェックをスキップします。パターンが欠落している場合、ControlFlagはそれをL2レベルのプレフィックスツリーと照合します。ControlFlagは、パターンが見つかったかどうかに関係なく（L1およびL2レベルで）、自動補正フェーズをトリガーします。前者の場合、パターンが見つかったとしても、それがまれである可能性があるため、後者の場合、それが欠落しているため、それがまれであることが分かっています。ControlFlagの自動補正フェーズは、ヒューリスティックに基づいてパターンが異常であるかどうかを判定し、異常である場合は木の類似性基準に基づいて可能な修正を提案します。
自動補正。文字列の自動補正[10]は、コンピュータサイエンスにおけるよく研究された問題です。ControlFlagの最初の実装では、文字列間の編集距離（動的プログラミングアルゴリズムを使用）を使用して、対象文字列の可能な修正を提案します。可能性のある誤った対象パターンの修正を提案するために、3つのアプローチを試しました：ナイーブなアプローチ、Norvigら[36]、およびSymmetric Delete [19] 。実験では、ナイーブなアプローチの時間的および空間的複雑さは、Norvigらのアプローチと対称的な削除と比較して合理的であることがわかりました。そのため、評価ではナイーブなアプローチを使用しました。ただし、次のような明白な方法で最適化しました：（i）自動補正プロセスの結果をキャッシュ化、（ii）固有のツリーノードに短いIDを使用してパースツリーの文字列表現をコンパクト化、（iii）プレフィックスツリーをトラバースする際の並列処理。
自動修正の結果をランキングする。
自動修正プロセスの結果は、可能な修正のリストであり、各修正には辞書内の出現回数と指定された対象文字列からの編集距離が含まれています。ControlFlagが自動修正結果をユーザーに表示する際、まず編集距離の昇順でソートし、次に出現回数でソートします。この単純なヒューリスティックは、1文字のタイポグラフィの違反の方が複数文字の違反よりも確率が高いという直感に基づいています。ControlFlagは自動修正プロセスのソートされた結果を使用して、異常をフラグ付けするための閾値レベルを決定します。
異常の閾値。ControlFlagは、特定のパターンを異常と宣言するための2つの基準を使用します。まず、辞書に欠落しているターゲットパターンは欠落しているため、異常と宣言されます。次に、辞書に欠落していないが、その自動補正結果が次の式を満たすターゲットパターンは異常と宣言されます。
𝑛0 × 100 Í𝑚𝑎𝑥_𝑐𝑜𝑠𝑡 𝑖=0 𝑚𝑎𝑥 (𝑛𝑖) < 𝛼 ∀(𝑝, 𝑛) ∈ 𝐶
𝐶は、すべての結果が修正されたパターン 𝑝 とその出現回数 𝑛 を含む自動補正の結果のセットです。𝛼はユーザー定義の異常閾値であり、𝑚𝑎𝑥は出現回数のリストの最大値を計算する関数です。直感的には、可能な対象文字列の修正が編集距離の小さい（たとえば1）場合に、その対象文字列よりも高い頻度を持っている場合、対象文字列が違反である可能性が高いです。𝛼はデフォルトで5％に設定されるユーザー可変の異常閾値です。
３．実験評価
このセクションでは、C/C++プログラムのif文内での独自のパターン違反を識別するControlFlagの結果を示します。
3.1 Setup
すべての実験は、56コアのIntel Xeon Platinum 8280 CPUを使用し、約200GBのメモリとハイパースレッディングが有効になっています。サーバーは、CentOS-7.6.1810オペレーティングシステムおよびGCC-10.2コンパイラを実行しています。
ソースリポジトリの選択：
パターンマイニングフェーズでは、C/C++を主要なプログラミング言語として使用し、少なくとも100個のスターを受け取ったトップ6000のオープンソースGitHubリポジトリを選択しました。前述のように、ControlFlagはトレーニングに使用されるソースリポジトリの品質（つまり、半信頼）を推測するメカニズムとしてGitHubのスターを使用します。
対象リポジトリの選択：
私たちの実験では、典型的なプログラミングパターンの違反をスキャンするために、以下のオープンソースの人気プロジェクトを使用しました：OpenSSL-1.1.1h、CURL-7.73、FFmpeg-n4.3.1、git-2.30、vlc-4.0、lxc-4.0、lz4-1.9.3、およびreactos-0.4.13。これらのパッケージを選択した特別な理由はなく、それらは広く使用されているオープンソースソフトウェアパッケージであり、基本的にC/C++プログラミング言語を使用して実装されているという事実のみです。
3.2 結果
ソースリポジトリからのパターンの抽出：
パターンマイニングフェーズでは6000のリポジトリを使用し、合計257万行のC/C++プログラムで構成されていました。これらのプログラムには、合計約3800万のパターンがあり、L1抽象化レベルでは約83.1万個のユニークなパターン、L2抽象化レベルでは468個のユニークなパターンがありました。図2は、両方の抽象化レベルでのユニークなパターンの出現回数の累積割合プロットを示しています。予想通り、L1レベルのユニークなパターンの約90%が低頻度（約10に近い）であることがわかります。一方、L2レベルでは、L1レベルで複数のパターンがグループ化されるため、約90%のパターンがより高い頻度を持っています。
表1は、トレーニングデータセットからのL1抽象化レベルでの上位10の頻出パターンを示しています。これらのパターンのほとんどは予想されるものです。また、NULLチェックがリストに含まれていることも良いことです。私たちの意見では、これは良いプログラミングの実践について述べています。一方、表2は、if (x = 7)などの、3800万回の内で1%未満の発生回数を持つパターンを示しています。C/C++でビット演算子（|や∧など）がリストに含まれていることも興味深いです。これらの演算子は、ハードウェアに近い低レベルのコードでより一般的であると考えています。この観察結果は、ソースリポジトリの選択戦略が異なる可能性があることを示唆しています。つまり、異なる技術領域に属するコードを含むリポジトリの一様な混合を意識的に確保することが重要であると考えられます。
56のワーカースレッドを使用して6000のソースリポジトリからパターンを採掘するのに約2時間かかりました。これらのパターンからL1およびL2の抽象化レベルでの接頭辞ツリーを構築するのに約3分かかりました。また、これらのパターンをテキスト形式でファイルにダンプしました。ファイルのサイズは約11GBでした。接頭辞ツリーによる圧縮により、ControlFlagのメモリ消費量は約8GBに減少し、空間のフットプリントが小さくなりました。
対象リポジトリのスキャン：
パターンマイニングフェーズ後、ControlFlagは評価セットのパッケージからC/C++プログラムを取得し、if文でのプログラミングパターンの違反をスキャンしました。これらのパッケージには、数千のファイルが含まれており、FFmpegが最も多く（3670個）、lz4が最も少なかった（51個）です。56のスキャナースレッドを使用して、ControlFlagはFFmpegのスキャンに約4時間、lz4のスキャンに10分かかりました。
図3aと図3bは、スキャンフェーズの結果を示しています。図3aでは、2つの抽象化レベルが接頭辞ツリーで見つかったパターンの数と欠落したパターンの数に与える影響を示しています。図には、異なる抽象化レベルでフラグ付きの異常の数も表示されています。要約すると、すべてのパターンはL2レベルで見つかります（VLCを除く。VLCはL2レベルで10個欠落していました）。一部のパターンがL1レベルで見つからないことがあります。図3bでは、異なる異常の閾値（1%と5%）が異常としてフラグ付けされたパターンの数に与える影響を示しています。予想通り、5%でフラグ付けされた異常の数が1%よりも多いです。これは明らかで深く研究された問題を提起します：異常の閾値はどのように設定すればよいですか？図2がL1レベルで多くのパターンが小さな頻度を持っていることを示しているので、閾値を1%未満の値に設定することができます。ただし、（重複を除いた後の）L1レベルでフラグ付けされた異常の絶対数が手動での検査には合理的であるため、異常の閾値をさらに低くする実験を行わないことにしました。
スキャンでフラグが立てられた異常：
今回、実験で報告された異常のいくつかについて議論します。OpenSSLが最も多くの異常を持っていたため、OpenSSLを分析対象としました。また、ソフトウェアの変更につながったCURLの異常についても議論します。これらの異常の詳細なレポートは付録Aに提供されています。これらの異常がバグであるかどうかはまだ確認していません。これは、自動修正で提案された変更を適用し、検証テストを実行すること（または開発者に連絡すること）によってのみ確認できます。
異常1.
CURLのlib/http_proxy.cでは、359行目でs->keepon > TRUEの式が使用されています。これは異常としてフラグが立てられました。なぜなら、トレーニングデータセットには>内にboolean値TRUEを含むパターンがわずか4つしかなかったからです。ControlFlagのトップの提案された修正であるs->keepon > numberは、編集距離2で127K回出現しました。CURLではs->keeponがint型であり、TRUEはtrueと定義されており、これはC言語では整数1として定義されています。したがって、この式は、符号付き32ビット整数と真偽値の整数値との比較です。そのため、GCCはそれをフラグ付けしませんでした。ただし、> trueの式は2つの理由で曖昧です。1つは、真偽値は通常、論理およびビット演算子とともに使用されることです。もう1つは、C言語では、非ゼロ値はtrueと見なされることです。この曖昧さをCURLの開発者に伝え、より良い式としてs->keepon > 1を提案しました。彼らはこの曖昧さを認識し、keeponの異なる値をモデル化するためにenum型を使用して解決しました。この例は、ControlFlagが異常を見つけ、その後、CURLの堅牢性を向上させることで潜在的な曖昧さを排除したことを示しています。
異常2.
OpenSSLのtest/testutil/tests.cでは、268行目で式(s1 == NULL) ∧ (s2 == NULL)が使用されています。この式は、トレーニングデータセットにわずか8回しか出現しなかったため、異常としてフラグが立てられました。一方、トップの2つの提案された修正、編集距離1の(s1 == NULL) | (s2 == NULL)と編集距離2の(s1 == NULL) || (s2 == NULL)は、それぞれトレーニングデータセットに32回と6808回出現しました。
同様の注記として、OpenSSLが式(m1 == NULL) == (m2 == NULL)を使用していることもわかりました。この式は、辞書にわずか7回しか出現しなかったため、異常としてフラグが立てられました。一方、その可能な修正、編集距離1の(m1 == NULL) != (m2 == NULL)と編集距離2の(m1 == NULL) || (m2 == NULL)は、それぞれ27回と6808回出現しました。
異常3.
OpenSSLのtest/evp_test.cでは、1898行目で式(-2 == rv)が使用されています。この式は、トレーニングデータセットに16529回出現したため、異常としてフラグが立てられました。一方、編集距離1の可能な修正variable == rvは110万回出現しました。基本式の出現回数が少ないのは、そのような形式の等号チェックを行うプログラマーが少ないためだと考えています。ただし、number == variableがvariable == numberよりも優れたスタイルであると考えています。これは、コンパイラのlvalueチェックが定数への代入を防ぐため、可能なタイポグラフィエラーを回避するためです。
異常4.
OpenSSLのcrypto/x509/t_req.cでは、141行目で式(BIO_puts(bp, ":") <= 0)が使用されています。この式は、トレーニングデータセットに475回出現したため、異常としてフラグが立てられました。この式が興味深いのは、関数呼び出しの結果を0および負の値と比較していることです。これはOpenSSLのエラーコードを評価するアプローチです。ControlFlagのトップ2つの提案された修正は、(BIO_puts(bp, ":") == 0)および(BIO_puts(bp, ":") < 0)でした。私たちが分析したデータに基づくと、これらはより適切なパターンを示しているようでした。0は成功したリターンコード（標準のlibcと同様）であり、負の値との比較は誤ったリターンコードのためです。OpenSSLの式は、いくつかの典型的なパターンを組み合わせており、非常に異常な組み合わせになっています。
3.3 結果の分析と今後の方向性
私たちの分析により、報告されたいくつかの異常は無害に見え、誤検知と見なすことができます。ただし、無監督アプローチであるため、異常パターンのリストがないため、それらを誤検知としてタグ付けしませんでした。さらに、このような場合、ControlFlagが提案した修正を適用し、健全性テストを実行することで、これらの異常を確認できる可能性があります。一方で、アプローチの精度と再現率を測定するために既知の異常のリスト（グラウンドトゥルースとして）を作成することもできます。現在のバージョンでは、これを将来の作業として保留しています。報告された異常は、それにもかかわらず、ControlFlagを微調整して拡張するための興味深い観察を示しています。以下でそれについて議論します。
リポジトリの特異性：
実験でフラグが立てられたいくつかの異常は、条件式のリポジトリ固有のコーディングスタイルのように見えます。これらの異常を取り除く潜在的な方法は、リポジトリ固有のスタイル辞書を構築することです。ただし、このようなアプローチは、誤検知の数が増加する可能性があります。第二の選択肢として、複数のリポジトリからの汎用辞書を構築し、後で特定のターゲットリポジトリに合わせて微調整することが考えられます。
ソースリポジトリの選択：
GitHubのスター数は、ソースリポジトリの品質の間接的な指標だと考えています。まず、品質を定義し、その後、低品質のリポジトリをフィルタリングするために、データ前処理技術（例：データクレンジング）の適用可能性を探ることは興味深いでしょう。
入れ子の式：
ControlFlagが持つかもしれないもう1つの重要な機能は、入れ子の式を固定サイズの式に分解することです。ほとんどの高水準言語では、式の木が無限の深さになる可能性があるため、この機能は誤検知の数を減らすことができます。以前に述べたL2抽象化レベル（セクション2）は、ある程度この機能を実現しています。それにもかかわらず、より洗練されたスキームが考案される可能性があります。具体的には、式の木の最小の高さを見つけることが興味深いでしょう。この最小の高さであっても、式の木の複数の部分木間の可能な関係を保持できる高さを見つけることが興味深いでしょう。たとえば、p != NULL && p->fは、ポインターが参照する前にポインターがNULLでないことを確認するためにC/C++で使用される典型的な式です。この式を高さ1の木に分解すると、p != NULLとp->fの間の順序関係が失われます。つまり、p != NULLはp->fの前に発生する必要があります。
4. 関連研究
この論文に関連する機械プログラミングの既存の研究について議論します。
コードパターン/イディオムの採掘：
公開されている大量のオープンソースコードが存在するため、コードから有用な情報を抽出するための研究がいくつか行われています。たとえば、構文フラグメント（またはイディオムとも呼ばれる）の採掘は、研究の活発な分野でした。コードイディオム（例：入れ子のループ、例外ハンドラなど）は、ソースコードエディタ（IDE）がプログラマーをコードの作成を支援するために使用されます。IDEは通常、プログラマーが手動でイディオムをIDEに追加できるようにしますが、プログラマーは最新のイディオムに精通していない場合があります。この問題に対処するために、データマイニング、頻出木の採掘、および確率的文法などの技術が、ソースコードリポジトリからイディオムを採掘するために適用されることがあります。コードイディオムは、概念的にはパターンと考えることができますが、パターンとは異なり、イディオムはプログラマーがコードの作成を支援する「興味深い」および「有用な」コード断片を表します。私たちの研究の焦点は、プログラミングパターンの違反を検出することであり、コードの作成を支援することではありません。言い換えると、頻繁なパターンは、私たちの場合には「興味深い」パターンです。
採掘されたコードイディオムは、他の問題の解決にも使用できます。たとえば、プログラム合成および意味解析の問題では、高レベルの言語プログラムを生成し、しばしば不完全なプログラム仕様を実装することが目標です。このような場合、コードイディオムはプログラム合成を単純化できる意味論的概念を捉えることができます。具体的には、PATOISシステムはプログラム合成器にコードイディオムの使用をトレーニングします。また、自然言語でプログラム仕様がある意味解析の問題では、研究は反復的な方法を提案し、コードイディオムを抽出し、それらを使用して意味解析器をトレーニングします。頻出コードパターンは、典型的なAPIの使用法を学習したり[17、51]、APIの誤用を検出したり[1、35]するためにも使用されています。学習されたAPIの使用パターン（例：呼び出しのシーケンス、メソッドの引数とその順序など）が良い/正しい例と見なされる場合、APIの誤用は異常と見なすことができます。APIの誤用を検出する問題は、原理的にはControlFlagによってアプローチされる問題のサブセットとして考えることができますが、APIの使用パターンがASTを使用して表される場合。ただし、APIの使用パターンのいくつかの他の表現、例えば呼び出しペア[50]、関連ルール[30]、呼び出しシーケンス[47]、木[5]、およびグラフ[34]も存在します。
自動バグ検出、ソフトウェア欠陥予測、およびプログラム修復：
ControlFlagが異常なパターンの自動修正を提案するため、これは自動バグ検出とプログラム修復の問題に近いと考えられます。自動バグ検出とプログラム修復は、MPの成長し、活発な研究分野です。これらの多くの技術は、バグを検出および修正するために学習ベースのアプローチを利用しています。特にHoppityは、JavaScriptコードでバグを検出および修正するために深層学習モデルを使用しています。概念的にバグ検出に近い問題であるソフトウェア欠陥予測は、ソフトウェアが出荷される前にソフトウェアの品質を予測しようとするものです。この問題への一般的なアプローチの1つは、統計的および機械学習モデルを使用することで、さまざまなプログラム機能（または品質メトリクス、例：コード行数）や表現（例：AST N-grams）と組み合わせています。ControlFlagはソフトウェア欠陥予測の問題に対処しようとはしませんが、異常なパターンの存在は、ソフトウェアの品質を予測するための別のプログラム機能として利用できます。
プログラム内の構文エラーを自動的に修正する問題にも、特別な取り組みがなされています。特に、SynFixは、再帰型ニューラルネットワーク（RNN）を訓練して構文的に有効なプログラムをトークンシーケンスとして学習し、入門プログラミング問題での構文エラーを修正します。テストプログラムは、学習されたRNNモデルに対してクエリを実行して構文エラーを検出し、これらのエラーを修正するための可能な修正を予測します。SynFixの学習モデルは、特定の問題向けに意図されたプログラムの構文エラーは、同じ問題を解決するための構文的に有効なプログラムから学習されたモデルによってのみ修正される可能性があると見られます。一方、ControlFlagで使用されている決定木は問題特有ではありません。一方、DrRepairは、有効なプログラムに構文エラーを導入し、コンパイラからの診断フィードバックを使用してそれらを修正する非監視学習アプローチを開発しています。
ControlFlagは、前述のアプローチとは異なり、バグの検出に特化していません。ControlFlagによってフラグが立てられる異常は、バグであるかどうかはそのプログラムのソースコード内で受け入れられた独自のパターンに大きく依存します。この意味では、ControlFlagは、テストケースやプログラム仕様がチェックされる前でも、プログラマーに異常を通知できます。私たちの知る限りでは、ControlFlagは、自己教師付き学習システムに完全に基づいて、誤りである可能性のあるタイポグラフィの異常を特定する初めての取り組みかもしれません。
5. 結論
この研究では、高水準のプログラミング言語の制御構造内の可能なタイポグラフィの誤りを自動的に検出するシステムであるControlFlagを提案しました。ControlFlagは、これらのエラーに対する可能な修正も提案します。ControlFlagが取る基本的なアプローチは、タイポグラフィのエラーを異常として再定義し、十分に大きな信頼性のあるコードでトレーニングされた自己教師付きシステムが、どのような特異なパターンが許容可能であるか（および許容されないか）を自動的に学習することです。複数のオープンソースパッケージからC/C++プログラムをスキャンした結果、ControlFlagは257万のプログラムから興味深い異常（およびいくつかの異例なプログラミングスタイル）を明らかにしました。私たちは、フラグの立てられた異常がバグでなくても、CURLのフラグの立てられた異常が示し、開発者によって認識されたように、ソフトウェアの堅牢性を向上させる可能性があると考えています。
6. 広範囲の影響
ControlFlagは、機械学習を基盤とした自己教師付きの特異なパターン検出システムであり、学習されたパターンをプログラムコードの異常を検出するために適用します。ControlFlagは、特異なパターンを学習するために大量のオープンソースコードを使用するため、GitHubのスターをリポジトリの品質の間接的な指標として利用します。言い換えると、ControlFlagはオープンソースのリポジトリから取得したプログラムコードを信頼性のあるものとして扱います。ただし、ControlFlagは低品質および/または悪意のあるデータから発生する攻撃に対して脆弱である可能性があると考えています。具体的には、攻撃者がトレーニングに使用されるソースコードリポジトリを制御できる場合、ControlFlagは通常は異常なパターンとして学習されるはずのパターンを簡単に学習してしまい、その後、それらの非異常なパターンを異常としてフラグ付けする可能性があります。さらに、パターンの出現回数を使用して異常を決定するため、攻撃者は複数のリポジトリを制御する必要はなく、単に悪意のあるパターンの出現回数が異常に高い1つのリポジトリを制御すれば十分です。同様に、ControlFlagは、複数のリポジトリ（攻撃者）が共謀して異常なパターンを追加してトレーニングデータを破損させる共謀攻撃にも脆弱である可能性があります。ただし、ControlFlagはソースコードリポジトリに対して偏見を持っていません。GitHubスターの基準を満たすすべてのリポジトリがトレーニングに考慮されます。
ControlFlagは機械学習ベースのシステムであるため、その出力はデバッグ、解析、説明が容易です。ただし、その計算要件は概念的には深層学習ベースのバージョンよりも低いはずですが、トレーニングデータセットのサイズが増加すると、計算リソースの需要が増加します。計算リソースの増加は環境への悪影響をもたらし、地球温暖化などの気候関連の問題を引き起こす可能性があります。ただし、これはデータを分析したり学習したりするすべてのソフトウェアシステムに適用されると考えています。
コメント
コメントを投稿